次の方法で共有

Service Broker のセキュリティの概要

  • [アーティクル]

Service Broker を使用すると、安全性と信頼性も兼ね備えた、拡張性の高いデータベース アプリケーションを作成できます。Service Broker のセキュリティにより、異なる SQL Server インスタンスでホストされるサービスが互いに安全に通信できます。これは、他の信頼関係が一切ない別のコンピュータにインスタンスがある場合や、送信元と送信先のコンピュータが同じネットワークに同時に接続していない場合についても同様です。

Service Broker のセキュリティは、証明書に依存しています。全体の流れとしては、まず、証明書を使用してリモート データベースの資格情報を確立し、その後、リモート データベースからの操作をローカル ユーザーにマップします。リモート サービスに代わってローカル ユーザーの権限がすべての操作に適用されます。証明書はデータベース間で共有されます。ユーザーに関するその他の情報は一切共有されません。

Service Broker には、ダイアログ セキュリティとトランスポート セキュリティという 2 種類のセキュリティがあります。この 2 種類のセキュリティの違いと、それらが連携するしくみを理解しておくと、Service Broker アプリケーションを設計、配置、および管理するうえで役に立ちます。

  • ダイアログ セキュリティ — 個々のダイアログ メッセージ交換のメッセージを暗号化し、ダイアログの参加者の ID を検証します。ダイアログ セキュリティでは、このほか、リモート承認やメッセージの整合性チェックも利用できます。ダイアログ セキュリティは、2 つのサービス間の通信の認証と暗号化を実現します。
  • トランスポート セキュリティ — 許可されていないデータベースからローカル インスタンスのデータベースに Service Broker メッセージが送信されるのを防ぎます。トランスポート セキュリティは、2 つのデータベース間のネットワーク接続の認証を実現します。

ダイアログ プロトコルやそれに隣接するブローカ プロトコルは、リモート データベースでのコマンドの実行ではなく、データベース間のメッセージの受け渡しを軸に設計されていることに注意してください。このスタイルの通信によって、Service Broker では、SQL Server のログインや Windows のセキュリティ資格情報をデータベースで共有しなくてもサービスを提供できるようになっています。

SQL Server 2005 の証明書の詳細については、「CREATE CERTIFICATE (Transact-SQL)」を参照してください。

Adventure Works Cycles のセキュリティ シナリオ

このサンプル ビジネス シナリオでは、架空の企業 Adventure Works Cycles が、仕入先に部品の注文を配信するための Service Broker サービスを作成します。このサービスでは、Adventure Works と仕入先の両方のセキュリティが必要です。各仕入先では、既存の顧客以外は注文を送信できないようにする必要があります。Adventure Works の側では、資格のある仕入先だけが注文を受け取れるようにする必要があります。AdventureWorks のデータベースと仕入先の間でやり取りされるメッセージは、第三者に読み取られないように暗号化する必要があります。最大限のセキュリティを確保するために、資格のある仕入先以外は AdventureWorks のデータベースに接続できないようにします。

メッセージの暗号化の要件を満たすために、Adventure Works と仕入先で Service Broker のダイアログ セキュリティを使用します。

  1. ダイアログ セキュリティを設定するには、まず AdventureWorks の管理者が、VendorOutgoing という名前のローカル ユーザーを作成し、そのユーザーのキー ペアを作成します。
  2. 管理者は、キー ペアの公開キーを含む証明書を、サービスにアクセスする必要がある仕入先に配布します。
  3. 各仕入先では、Adventure Works Cycles からの証明書をデータベースにインストールし、証明書を所有するユーザーを作成します。
  4. 続いて仕入先はキー ペアを作成し、仕入先のサービスのサービス名の情報とキー ペアの公開キーを含む証明書を AdventureWorks の管理者に送信します。
  5. AdventureWorks の管理者は、各仕入先のためのユーザーを作成し、仕入先からの証明書を関連付けます。
  6. また管理者は、各仕入先のリモート サービス バインドを作成して、仕入先のサービスの名前と仕入先のために作成したユーザーを関連付けます。

資格のある仕入先以外は AdventureWorks のデータベースに接続できないようにするという要件を満たすために、AdventureWorks の管理者は Service Broker のトランスポート セキュリティを使用します。

  1. トランスポート セキュリティを設定するには、AdventureWorks の管理者が、メッセージを送信する SQL Server インスタンスの master データベースに証明書を作成します。
  2. AdventureWorks の管理者は、その証明書を各仕入先に送信します。
  3. 各仕入先の管理者は、証明書を所有するユーザーを master データベースに作成し、メッセージを受信する SQL Server インスタンスに証明書をインストールします。
  4. 続いて仕入先の管理者は、そのインスタンスの master データベースに証明書を作成し、そのユーザーの公開キーを AdventureWorks の管理者に送信します。
  5. 最後に、AdventureWorks の管理者が、各仕入先の公開キー証明書を所有するユーザーを master データベースに作成し、各仕入先の証明書をデータベースにインストールします。

AdventureWorks の管理者は、トランスポート セキュリティとダイアログ セキュリティを組み合わせることによって、このアプリケーションのセキュリティの要件を満たすことができます。このシナリオでは、仕入先が AdventureWorks のデータベースにログオンしたり、Adventure Works の管理者が仕入先のデータベースにログオンしたりはできない点に注意してください。ここで許可されているのは、データベース間での Service Broker メッセージの交換だけです。

参照

概念

Service Broker 通信プロトコル

その他の技術情報

CREATE CERTIFICATE (Transact-SQL)

ヘルプおよび情報

SQL Server 2005 の参考資料の入手