適用対象:
SQL ServerAzure SQL Managed Instance
ダイアログ セキュリティは、特定のメッセージ交換に対する暗号化、リモート認証、リモート承認を提供します。 メッセージ交換でダイアログ セキュリティを使用する場合、SQL Server インスタンスの外部へ送信されるすべてのメッセージが Service Broker によって暗号化されます。 Service Broker メッセージ交換には、既定でダイアログ セキュリティが使用されます。
ダイアログ セキュリティの基本
アプリケーションで Service Broker ダイアログ セキュリティを利用することで、個々のダイアログ メッセージ交換 (またはダイアログ) に対して認証、承認、または暗号化を使用できます。 既定では、すべてのダイアログ メッセージ交換がダイアログ セキュリティを使用します。 ダイアログを開始するときに、ENCRYPTION = OFF ステートメントに BEGIN DIALOG CONVERSATION 句を含めることで、ダイアログのセキュリティなしでダイアログを続行することを明示的に許可できます。 ただし、会話が対象とするサービスに対してリモート サービス バインドが存在する場合、ダイアログは ENCRYPTION = OFF場合でもセキュリティを使用します。
セキュリティを使用するダイアログの場合、SQL Server インスタンスの外部に送信されるすべてのメッセージが Service Broker で暗号化されます。 SQL Server インスタンスの内部のメッセージは、暗号化されません。 ダイアログ セキュリティでは、発信側サービスをホストするデータベース、および対象サービスをホストするデータベースだけが、セキュリティに必要な証明書へのアクセス権を持つ必要があります。 つまり、メッセージ転送を実行するインスタンスは、インスタンスが転送するメッセージを復号化する機能を持っている必要はありません。
Service Broker では、完全セキュリティと匿名セキュリティという 2 種類のダイアログ セキュリティを利用できます。 ダイアログ セキュリティを使用するメッセージ交換の場合、Service Broker では、リモート承認を使用して、メッセージ交換のリモート側をローカル ユーザーにマップします。
メッセージ交換が完全セキュリティまたは匿名セキュリティを使用すると、メッセージはネットワーク上で暗号化されます。 ただし、対象データベースにおいて有効な権限およびメッセージの暗号化に使用される戦略は、2 つの手法で若干異なります。
メッセージ交換が完全セキュリティと匿名セキュリティのどちらを使用しても、メッセージの本文は、特定のメッセージ交換のために生成される対称セッション キーによって暗号化されます。 ダイアログ セキュリティに対して提供される、証明書を使用した秘密キー暗号化によって暗号化されるのは、キーのみです。 メッセージの破損や改ざんの検出に役立つメッセージ整合性チェックも、Service Broker によって実行されます。
ダイアログ セキュリティを使用したメッセージ交換のためのセッション キーが SQL Server で作成されます。 データベースに格納されている間にセッション キーを保護するために、Service Broker はデータベースのマスター キーを使用してセッション キーを暗号化します。 データベース マスター キーを使用できない場合、会話のメッセージは、データベース マスター キーが作成されるまで、または会話がタイムアウトするまで、エラーと共に transmission_status に残ります。そのため、データベースが同じインスタンスでホストされている場合でも、会話に参加する両方のデータベースにマスター キーが含まれている必要があります。 開始データベースにマスター キーが含まれていない場合、ダイアログは失敗します。 ターゲット データベースにマスター キーが含まれていない場合、メッセージは開始データベースの伝送キューに残ります。 これらのメッセージの最後の送信エラーは、メッセージを配信できない理由を示します。
ENCRYPTION = OFF パラメーターを使用して暗号化されていないダイアログを作成するか、次のコマンドを使用してデータベース マスター キーを作成します。
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>';
便宜上、Service Broker では、データベースがマスター キーを含んでいるかどうかにかかわらず、単一のデータベース内ではセキュリティで保護されたメッセージ交換を継続できます。 2 つの異なるデータベースはメッセージ交換の有効期間中に異なる SQL Server インスタンスに移動される可能性がありますが、単一データベース内のメッセージ交換は、常にそのデータベース内に留まります。 したがって、メッセージ交換を継続することができます。
完全セキュリティ
完全セキュリティは、発信側サービスが信頼できないデータベースにメッセージを送信するのを防止し、対象サービスが信頼できないデータベースからメッセージを受信するのを防止する場合に利用できます。 メッセージ交換で完全セキュリティを使用する場合、ネットワークに送信されるメッセージは Service Broker により暗号化されます。
完全セキュリティは、発信側サービスと対象サービスの両方に対して ID を提供します。 完全セキュリティでは、発信側サービスが対象サービスを信頼し、対象サービスが発信側サービスを信頼することが必要です。 たとえば、ベンダーから部品を注文するサービスでは、注文アプリケーションがベンダー サービスを信頼し、ベンダー サービスが注文アプリケーションを信頼する必要がある場合があります。
データベース管理者は、公開キーを含む証明書を交換することで、信頼を確立します。 完全ダイアログ セキュリティの場合、メッセージ交換の各側がローカル ユーザーの秘密キーとリモート ユーザーの公開キーを保持します。 発信側サービスをホストするデータベースには、リモート サービス バインドが含まれます。 このリモート サービス バインドでは、リモート データベース内の秘密キーに対応する証明書を所有するローカル ユーザーが指定されています。 したがって、発信側サービスに代わる操作が、対象データベースで指定されたユーザーとして実行されます。
対象データベースにはユーザーが含まれます。 このユーザーは、開始サービスを所有するユーザーが所有する秘密キーに対応する証明書を所有しています。 したがって、対象サービスに代わって発信側データベースで行われる操作が、発信側サービスを所有するユーザーとして実行されます。
完全セキュリティを使用するダイアログの場合、メッセージ交換の各側がセッション キーを生成します。 「証明書と Service Broker」で説明されているように、各方向の最初のメッセージにはキー交換キーによって暗号化されたセッション キーが含まれます。
匿名セキュリティ
匿名セキュリティは、発信側サービスが信頼できないデータベースにメッセージを送信するのを防止する場合に利用できます。 メッセージ交換で匿名セキュリティを使用する場合、ネットワークに送信されるメッセージは Service Broker により暗号化されます。
匿名セキュリティは、開始サービスに対するターゲット サービスを識別しますが、ターゲット サービスに対する開始サービスは識別しません。
たとえば、作業指示書を送信するアプリケーションでは、作業指示書の受信者が意図したターゲットであることを保証する必要がある場合がありますが、ターゲット データベースは、作業指示書を送信するサービスに特別な特権を提供する必要がない場合があります。 この場合、発信側サービスを含むデータベースは対象サービスに対するリモート サービス バインドを含む必要があります。
ターゲット サービスは開始サービスの ID を確認できないため、開始サービスに代わって操作は、ターゲット データベースの固定データベース ロール パブリック のメンバーとして実行されます。 対象データベースは、メッセージ交換を開始したユーザーに関する情報を受け取りません。 ターゲット データベースには、会話を開始するユーザーの証明書を含める必要はありません。
匿名セキュリティを使用するダイアログの場合、メッセージ交換の両側が発信側データベースによって生成されたセッション キーを使用します。 ターゲット データベースは、開始データベースにセッション キーを返しません。
ダイアログ セキュリティのセキュリティ コンテキスト
Service Broker のリモート承認により、個々のサービスへのリモート アクセスを制御します。 リモート承認は、SQL Server インスタンスへの受信メッセージがサービスに送信されるセキュリティ コンテキストを判別します。
Service Broker は、SQL Server インスタンス内で完全には行われないセキュリティで保護された会話に対して、常にリモート承認を使用します。 会話用に構成されたダイアログ セキュリティによって、Service Broker がリモート承認に使用するセキュリティ コンテキストが決まります。
リモート承認が構成されている場合でも、会話が SQL Server インスタンス内に残っている場合、Service Broker はリモート承認を使用しません。 インスタンス内の会話の場合、SQL Server のセキュリティ プリンシパルは既に SQL Server で使用できるため、リモート承認を使用して Service Broker 操作の正しいセキュリティ コンテキストを判断する必要はありません。 ただし、前に説明したように、メッセージ交換中に 1 つのデータベースが別のインスタンスに移動された場合でもメッセージ交換を継続するために、Service Broker によりセッション キーが作成されます。
匿名セキュリティを使用するメッセージ交換の場合、接続は対象データベースの固定データベース ロール public のメンバーとして実行されます。 この場合、固定データベース ロール public には、サービスにメッセージを送信する権限が必要です。 ただし、このロールはデータベースにおける他の権限は必要ありません。
完全セキュリティを使用するメッセージ交換の場合、メッセージ交換の各側における接続は、リモート サービス バインドで指定されるユーザーの権限で動作します。 たとえば、リモート サービス バインドがサービス名 InventoryService をユーザー InventoryServiceRemoteUserに関連付ける場合、SQL Server は InventoryServiceRemoteUser のセキュリティ コンテキストを使用して、 InventoryService アプリケーションのメッセージを宛先サービスのキューに配置します。
セキュリティ向上のため、通常、サービスの秘密キーを所有するユーザーは、アクティブ化のために指定されるユーザーとは異なるユーザーにします。 秘密キーを所有するユーザーには、キューにメッセージを追加するアクセス許可 (つまり、キューを使用するサービスのアクセス許可 SEND ) のみが必要です。 一方、アクティブ化のために指定されるユーザーは、要求された作業を実行して応答を送信するために必要な権限を持ちます。 前の例では、 InventoryServiceRemoteUser では、インベントリ テーブルのクエリやリターン メッセージの送信に対するアクセス許可は必要ありません。 ユーザーは、 InventoryService が使用するキューにメッセージを送信するためのアクセス許可のみが必要です。 ストアド プロシージャのアクティブ化は、キューで指定されている資格情報を使用して別のセッションで行われます。 メッセージをエンキューするセッションと、メッセージを処理するセッションが、資格情報を共有する必要はありません。
セキュリティで保護されたダイアログを作成する
Service Broker によって 2 つのデータベース間にダイアログが確立されたとき、ターゲット キューにメッセージを配置できるように、発信側サービスが対象データベースのユーザー コンテキストを確立する必要があります。 このユーザー コンテキストにより、対象サービスに対してダイアログを開く権限が発信側サービスに許可されているかどうかが判断されます。
この操作を最も柔軟に行うには、証明書およびリモート サービス バインドを作成します。 証明書の作成の詳細については、「証明書の 作成」を参照してください。 リモート サービス バインドの作成の詳細については、「 CREATE REMOTE SERVICE BINDING」を参照してください。
注
セキュリティ コンテキストが正しく設定されていない場合、ダイアログで送信されたメッセージは開始サービスの sys.transmission_queue に残り、 transmission_status 列に次のエラー メッセージが表示されます。 The server principal '%.*ls' is not able to access the database '%.*ls' under the current security context.