ネイティブ XML Web サービスを使用する際の推奨事項

この機能は、将来のバージョンの Microsoft SQL Server では削除される予定です。 新しい開発作業では、この機能の使用を避け、現在この機能を使用しているアプリケーションは修正するようにしてください。

このトピックでは、SQL Server 2005 または SQL Server 2008 のネイティブ XML Web サービスをビジネス ソリューションで使用するための計画と評価を行う際に考慮すべき推奨事項についていくつか紹介します。ここで推奨する内容は、次の内容でのユーザー支援を目的としています。

  • SQL Server 2005 または SQL Server 2008 のネイティブ XML Web サービスを使用するときに、SQL Server のインストールをセキュリティで保護する。

  • 使用方法のガイドラインにより、SQL Server のインストールのパフォーマンスを向上させる。ガイドラインを使用すると、ネイティブ XML Web サービスを使用することにより、アプリケーションが効率的に機能しているかどうかを判断できます。

セキュリティに関する推奨事項

ネイティブ XML Web サービスを配置するときは、セキュリティに関する次の推奨事項を考慮してください。

  • Kerberos 認証を使用する。

  • エンドポイントの接続権限を特定のユーザーまたはグループに制限する。

  • Secure Socket Layer を使用して機密データを交換する。

  • ファイアウォールの背後で SQL Server を使用する。

  • Windows の Guest アカウントがサーバーで無効になっていることを確認する。

  • エンドポイントの状態を必要に応じて制御および更新する。

  • 可能な限り、セキュリティで保護されたエンドポイントの既定値を使用する。

Kerberos 認証を使用する

CREATE ENDPOINT (Transact-SQL) を使用してエンドポイントを作成するときは、AUTHENTICATION=KERBEROS または AUTHENTICATION = INTEGRATED を選択し、エンドポイントでの認証の種類として、Kerberos を使った Windows 統合セキュリティが使用されるようにします。最初のオプションでは、エンドポイントの認証のモードとして Kerberos のみが許可されます。2 番目のオプションでは、エンドポイントで NTLM 認証と Kerberos 認証の両方がサポートされます。

認証に使用する Kerberos プロトコルは、相互認証などの組み込みの機能を使用することにより、強化されたセキュリティを提供しています。これは、サーバーとクライアントの両方の ID が認証されることを意味します。

Kerberos 認証を使用している場合、SQL Server では実行対象のアカウントに SPN (サービス プリンシパル名) を関連付ける必要があります。詳細については、「Http.sys を使用した Kerberos サービス プリンシパル名の登録」を参照してください。

エンドポイントの接続権限を特定のユーザーまたはグループに制限する

配置に必要なエンドポイントを作成した後に、GRANT CONNECT や ALTER ON ENDPOINT などの Transact-SQL ステートメントを使用してエンドポイント接続権限を設定することにより、エンドポイントをセキュリティで保護します。接続権限を割り当てるときに、SQL Server へのエンドポイント アクセスのために予約されている特定のユーザーまたは特定のグループのみに限定して権限を与えます。

通常は、権限を制限して、個別のユーザーだけがエンドポイントに接続できるようにしてください。public ロールにアクセス権を与えることはお勧めしません。代わりに、SQL Server の権限のモデルについて完全に理解することをお勧めします。このモデルを使用すると、エンドポイント アクセスを適切に制御できます。

重要な注意事項重要

public ロールとは、すべての SQL Server ユーザーが属している特別なデータベース ロールです。このロールには、データベースにアクセスできるすべてのユーザーの既定のアクセス権が含まれています。このデータベース ロールは SQL Server の組み込みの既定のロールであり、すべてのユーザーにアクセス権を与える方法として使用されます (Windows のアクセス許可にある Everyone または Authenticated Users に似ています)。そのため、SQL Server で権限を構成するときは、注意して使用する必要があります。

詳細については、「GRANT (エンドポイントの権限の許可) (Transact-SQL)」を参照してください。

Secure Socket Layer を使用して機密データを交換する

SSL (Secure Socket Layer) プロトコルでは、セキュリティで保護された TCP/IP ソケット (IP アドレスと TCP ポート番号の組み合わせ) インターフェイス上でデータの暗号化と暗号化解除の両方がサポートされています。SQL Server エンドポイントで SSL 暗号化を提供する場合、最初に証明書を構成する必要があります。

既定の SSL ポート 443 の証明書を登録するとき、他のアプリケーションによって同じ証明書が共有されている可能性があることを考慮してください。たとえば、IIS (インターネット インフォメーション サービス) が同じポート上で SSL トラフィックをホストしている場合、この構成が IIS ユーザーに影響する可能性があります。このように SSL ポートとその証明書が共有されていることで、セキュリティに影響することがあります。

詳細については、「SSL に使用する証明書の構成」を参照してください。

ファイアウォールの背後で SQL Server を使用する

最善のセキュリティを確保するために、ネイティブ XML Web サービスは、ファイアウォールの背後でのみ使用してください。エンドポイントを設定するときは、HTTP アクセスの提供に使用するすべての TCP ポート番号が、ファイアウォールによって保護されていることを確認してください。インターネット クライアントから SQL Server のインストールに直接アクセスできる構成や、ファイアウォールによって保護されていないネットワーク構成はお勧めしません。詳細については、「SQL Server インストールのセキュリティに関する注意点」を参照してください。

Windows の Guest アカウントがサーバーで無効になっていることを確認する

Guest アカウントは、Microsoft Windows のほとんどのバージョンで提供されている組み込みのユーザー アカウントです。Windows Server 2003 では、既定で無効になっています。Windows 2000 Server および Windows NT Server 4.0 では、既定で有効になっています。

エンドポイント使用時の攻撃のリスクを減らすには、SQL Server を実行しているサーバーで Guest アカウントが無効になっていることを確認してください。詳細については、Windows ヘルプの「ローカル ユーザー アカウントを無効または有効にするには」を参照してください。

エンドポイントの状態を必要に応じて制御および更新する

CREATE ENDPOINT (Transact-SQL) を使用して作成したエンドポイントは、STATE = STARTED を指定して明示的に開始しない限り、既定では停止状態になります。既存のエンドポイントの状態を制御するには、ALTER ENDPOINT (Transact-SQL) を使用して、STOPPED、STARTED、または DISABLED を指定します。

たとえば、次のステートメントを使用して、前に作成したエンドポイント sql_endpoint を開始または停止します。

ALTER ENDPOINT sql_endpoint STATE=STARTED

ALTER ENDPOINT sql_endpoint STATE=STOPPED

エンドポイントを無効にするか、エンドポイント上の特定の Web メソッドを削除する必要もあります。また、使用する予定のないエンドポイントがあれば、そのエンドポイントは削除してください。

エンドポイントを無効にする例を次に示します。

ALTER ENDPOINT sql_endpoint STATE=DISABLED

注意注意

エンドポイントを無効にすると、SQL Server サービス (MSSQLServer) が再起動されるまではエンドポイントを再起動できません。

エンドポイントから Web メソッドを削除するには、次の形式に似たステートメントを使用します。

ALTER ENDPOINT sql_endpoint

FOR SOAP

(

DROP WEBMETHOD 'SayHello'

)

エンドポイントを削除するには、DROP ENDPOINT を使用します。

可能な限り、セキュリティで保護されたエンドポイントの既定値を使用する

CREATE ENDPOINT または ALTER ENDPOINT を使用してエンドポイントを作成または変更するとき、次のオプションの値は、明示的に設定しない限り既定値が使用されます。

  • BATCHES = DISABLED

    Transact-SQL エンドポイントで batch モードが無効になります。

  • LOGIN_TYPE = WINDOWS

    エンドポイント ユーザーは Windows 認証だけを使用できます。

目的のアクセスや機能、またアプリケーションの配置に必要なアクセスや機能をサポートするために、これらの設定を変更する必要がない限り、これらのオプションにはできるだけ既定値を使用することをお勧めします。

暗号化アルゴリズムの選択の詳細については、「暗号化アルゴリズムの選択」を参照してください。

パフォーマンスの推奨事項

ネイティブ XML Web サービスを配置するときは、パフォーマンスに関する次の推奨事項を考慮してください。

  • 適切なシナリオに配置する。

  • SOAP ベースのソリューションを計画するときは追加のサーバー リソースを考慮する。

  • 要件に合った適切な WSDL オプションを構成する。

適切なシナリオに配置する

ネイティブ XML Web サービスは、次の要件を持つシナリオに最も適しています。

  • アプリケーションが XML データを返したり、XML データを使用する。

  • アプリケーションがビジネス ロジックのストアド プロシージャに大きく依存している。

  • ビジネス ソリューションの一部として、SQL Server がホストする Web サービス アプリケーションと、他の Web サービス アプリケーションを統合して、SOA (Service Oriented Architecture) の目的を実現する。

  • 同一サーバー上に Web サービスを一緒に配置するために、SQLXML 中間層のソリューションに代わる、より優れたパフォーマンスを提供するソリューションを探している。

  • イントラネット Web サイトの静的レポートを生成およびパブリッシュしようとしているが、SQL Server 2005 Reporting Services (SSRS) 以降の豊富な機能セットおよび追加のオーバーヘッドが要件を上回る可能性がある。

同様に、次の要件を持つシナリオでは、ネイティブ XML Web サービスを使用することはお勧めしません。

  • binary 型、image 型、または text 型の大きな値など、BLOB (バイナリ ラージ オブジェクト) 型データの挿入または取得に、アプリケーションを使用する。

  • アプリケーションが、リアルタイム トランザクション処理およびミッション クリティカルな応答時間を必要としている。

  • TPC Benchmark C (TPC-C) アプリケーションなどの集中的に処理を行う他のアプリケーションと SQL Server を組み合わせて使用している。

SOAP ベースのソリューションを計画するときは追加のサーバー リソースを考慮する

キャパシティ プランニングを行う際、SOAP のパフォーマンスは TDS (表形式のデータ ストリーム) プロトコルとは異なりアプリケーションによって変わるので、サーバー リソースのオーバーヘッドが追加で必要になる場合があることに注意してください。たとえば、SQL Server の製品チームが行った SQL Server 2005 のテストでは、大きな XML ドキュメントを返すシナリオの場合、SOAP ベースのアクセスが、TDS ベースのアクセスよりも 20 ~ 30% 長い時間がかかるという結果になりました。

要件に合った適切な WSDL オプションを構成する

ネイティブ XML Web サービスを配置する前に、ソリューションに必要なすべてのクライアントおよびオペレーティング システムのサポートで使用する、適切な WSDL オプションを決定する必要があります。

Web サービス クライアントに Windows 以外のオペレーティング システムが含まれる異種混在の環境内で相互運用性を最大限に高めるには、単純な WSDL を使用します。MicrosoftVisual Studio 2005 を使用して開発している Windows のみ存在する環境では、既定の WSDL を使用して、Visual Studio 2005 に含まれる豊富な種類のサポートにアクセスできます。

サード パーティの SOAP クライアントによっては、相互運用性のために、カスタマイズされた WSDL が必要になることがあります。詳細については、「カスタム WSDL サポートの実装」を参照してください。