Service Broker ダイアログ セキュリティ
ダイアログ セキュリティは、特定のメッセージ交換に対する暗号化、リモート認証、リモート承認を提供します。メッセージ交換でダイアログ セキュリティを使用する場合、SQL Server インスタンスの外部へ送信されるすべてのメッセージが Service Broker によって暗号化されます。Service Broker メッセージ交換では、既定でダイアログ セキュリティが使用されます。
ダイアログ セキュリティの基礎
アプリケーションで Service Broker ダイアログ セキュリティを利用することで、個々のダイアログ メッセージ交換 (またはダイアログ) に対して認証、承認、または暗号化を使用できます。既定では、すべてのダイアログ メッセージ交換がダイアログ セキュリティを使用します。ダイアログの開始時に、BEGIN DIALOG CONVERSATION ステートメントで ENCRYPTION = OFF 句を指定することにより、ダイアログ セキュリティなしでのダイアログの継続を明示的に許可できます。ただし、メッセージ交換の対象となるサービスにリモート サービス バインドが存在する場合は、ENCRYPTION = OFF が指定されても、ダイアログはセキュリティを使用します。
セキュリティを使用するダイアログの場合、Service Broker は、SQL Server インスタンスの外部に送信されるすべてのメッセージを暗号化します。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 を検証できないため、発信側サービスに代わる操作が対象データベースで固定データベース ロール public のメンバとして実行されます。対象データベースは、メッセージ交換を開始したユーザーに関する情報を受け取りません。対象データベースは、メッセージ交換を開始するユーザーの証明書を保持する必要はありません。
匿名セキュリティを使用するダイアログの場合、メッセージ交換の両側が発信側データベースによって生成されたセッション キーを使用します。対象データベースは、発信側データベースに対してセッション キーを返しません。
ダイアログ セキュリティのためのセキュリティ コンテキスト
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 CERTIFICATE (Transact-SQL)」を参照してください。リモート サービス バインドの作成の詳細については、「CREATE REMOTE SERVICE BINDING (Transact-SQL)」を参照してください。
証明書およびリモート サービス バインドを作成するためのもう 1 つの方法は、SQL Server セキュリティを使用して 2 つのデータベース間に信頼関係を確立することです。発信側サービスの所有者は、対象サービスのユーザーの権限を借用します。これには、発信側サービスの TRUSTWORTHY データベース プロパティを ON に設定したり、対象データベースのユーザーに認証権限を許可することが必要になる場合があります。詳細については、「EXECUTE AS の使用によるデータベースの権限借用の拡張」を参照してください。
.gif "注意") 注意 |
|---|
セキュリティ コンテキストが正しく設定されていない場合、ダイアログで送信されたメッセージは発信側サービスの sys.transmission_queue に残り、transmission_status 列には "現在のセキュリティ コンテキストでは、サーバー プリンシパル "%.*ls" はデータベース "%.*ls" にアクセスできません" というエラー メッセージが表示されます。 |