ダイアログ セキュリティのための証明書
メッセージ交換が開始されると、Service Broker はリモート サービス バインドを使用して、メッセージ交換に使用する証明書を検索します。このトピックでは、Service Broker がメッセージ交換で使用する証明書を判別する方法について説明します。
ダイアログのための証明書の検索
Service Broker は、最初にメッセージ交換で使用するリモート サービス バインドを検索し、次に、バインドで指定されているユーザーが所有する証明書を選択します。
バインドを見つけるため、Service Broker はメッセージ交換で使用する対象サービス名を指定しているバインドをデータベースで確認します。
次に、証明書を選択するため、リモート サービス バインドで指定されているユーザーが所有する、有効期限日付が最も遅い証明書を検索します。Service Broker は、まだ有効でない証明書、有効期限切れの証明書、またはダイアログの開始に使用可能であるとマークされていない証明書を無視します。証明書の詳細については、「CREATE CERTIFICATE (Transact-SQL)」を参照してください。
リモート サービス バインドが存在しない場合、またはリモート サービス バインドのユーザーが、ダイアログを開始するために使用できる有効な証明書を所有していない場合には、Service Broker はメッセージ交換のメッセージを暗号化できません。バインドが存在せず、かつデータベースにブローカ構成サービスが格納されている場合、Service Broker はそのサービスを通じてバインドを要求します。データベースにブローカ構成サービスが格納されていないか、またはブローカ構成サービスがリモート サービス バインドを提供していない場合、メッセージ交換は、暗号化が ON であれば遅延され、暗号化が OFF であれば暗号化せずに続行されます。詳細については、「ダイアログ セキュリティの種類の決定」を参照してください。
リモート承認およびダイアログ セキュリティ
Service Broker ダイアログ セキュリティでは、リモート承認のために証明書を使用します。ダイアログでダイアログ セキュリティを使用する場合、メッセージ交換の各参加者が最初に送信するメッセージには、送信側ユーザーの秘密キーで暗号化されたヘッダー情報と、受信側ユーザーの公開キーで暗号化されたヘッダー情報が格納されています。メッセージの内容は、セッション キーで暗号化されます。セッション キー自体も暗号化され、受信側ユーザーの秘密キーでのみ復元できます。
メッセージの受信者がメッセージの暗号化を解除できれば、それは受信者が対応するキーを所有していることを意味しており、これによってメッセージ交換の各参加者が本人であることが確認されます。データベースに証明書をインストールすると、秘密キーを保持しているデータベースとの間に信頼関係が作成されます。
実際には、ヘッダーをローカル ユーザーの秘密キーで暗号化することは、"リモート データベースはローカル データベースを信頼しているか" と質問することです。リモート データベースは、対応する公開キーを格納している場合にのみ、ヘッダーの暗号化を解除することができます。ヘッダーをリモート データベースのユーザーの公開キーで暗号化することは、"ローカル データベースはリモート データベースを信頼しているか" と質問することです。リモート データベースは、対応する秘密キーを格納している場合にのみ、ヘッダーの暗号化を解除することができます。セキュリティと効率性の理由から、Service Broker は両方の質問を同時に行います。ただし、メッセージは、受信側が質問に対して肯定的に答えた場合のみ、メッセージに正しく応答できるように構成されています。
この方法の裏付けとなる理論は単純です。リモート データベースが、ローカル データベースの秘密キーで暗号化されたヘッダーの暗号化を解除できた場合、リモート データベースには対応する公開キーが格納されており、リモート データベースはローカル データベースを信頼していることになります。リモート データベースが、ローカル データベースの公開キーで暗号化されたヘッダーの暗号化を解除できた場合、リモート データベースには対応する秘密キーが格納されており、ローカル データベースはリモート データベースを信頼していることになります。秘密キーが秘密である限り、メッセージ交換に関与する 2 つのデータベースだけが、メッセージ交換のメッセージを正しく交換することができます。
.gif "ms166117.note(ja-jp,SQL.90).gif") メモ : |
|---|
| 信頼できる発行元の証明書以外はインストールしないでください。秘密キーは配布しないでください。 |
完全ダイアログ セキュリティでは、メッセージを最初に交換する際に、相手が本当に本人かどうかを双方で確認します。匿名ダイアログ セキュリティを使用するメッセージ交換では、発信側が、対象データベースに必要な秘密キーが格納されているかどうかを確認します。ただし、匿名ダイアログ セキュリティを使用した場合、対象データベースは発信側が本当に本人かどうかを確認しません。その代わり、対象サービスをホストするデータベースは、メッセージをサービスに送信する、固定データベース ロール public を許容する必要があります。
メッセージは、ローカル データベースがリモート データベースの本人確認が完了したと見なす前に、双方向で交換される必要があります。確認は、ローカル データベースに、リモート データベースの証明書の正しい公開キーが格納されている場合にのみ行われます。
メッセージ交換の双方の側から送信される最初のメッセージに、Service Broker は次のヘッダーを挿入します。
- メッセージに対して使用される証明書に関する情報を格納した、サービス ペア セキュリティ ヘッダー。サービス ペア セキュリティ ヘッダーは、サービスを所有するユーザーの秘密キーで署名されます。
- メッセージの本文を暗号化するために使用される 128 ビットのセッション キーを暗号化するキー交換キー。キー交換キーは、リモート ユーザーの公開キーで暗号化されます。
匿名セキュリティを使用するダイアログでは、サービス ペア セキュリティ ヘッダーは暗号化されていません。メッセージ自体は暗号化されており、キー交換キーも対象データベースのセキュリティ プリンシパルの公開キーで暗号化されています。この場合、最初の返送メッセージには、キー交換キー、サービス ペア セキュリティ ヘッダー、および暗号化済みセッション キーは含まれていません。
Service Broker 自体が着信メッセージ (たとえばエラーや受信確認) に応答してメッセージを生成した場合、そのメッセージでは、ダイアログで完全セキュリティまたは匿名セキュリティのどちらが使用されている場合でも、着信メッセージのセッション キーを使用します。
参照
概念
証明書および Service Broker
リモート サービス バインド
その他の技術情報
CREATE REMOTE SERVICE BINDING (Transact-SQL)
ALTER REMOTE SERVICE BINDING (Transact-SQL)
DROP REMOTE SERVICE BINDING (Transact-SQL)
CREATE CERTIFICATE (Transact-SQL)
ALTER CERTIFICATE (Transact-SQL)
DROP CERTIFICATE (Transact-SQL)