Service Broker のユーザーレベル権限
複数のインスタンスを持つ多くの Service Broker アプリケーションは、アプリケーションのために作成されたデータベース プリンシパルのセキュリティ コンテキストで実行されます。データベース プリンシパルは、アプリケーションで実行するタスクを完了せるための最小限の権限を必要とします。
Service Broker アプリケーションのために作成したデータベース プリンシパルには、次の注意点があります。
- リモート Service Broker アプリケーションが SQL Server に接続してメッセージをインスタンスに配信する際、Service Broker のリモート承認が適用されます。リモート承認用に指定されるデータベース プリンシパルには、発信側サービスをホストするデータベースの CONNECT 権限と、発信側サービス自体の SEND 権限が必要です。ユーザーは認証に使用する証明書を所有する必要があります。ユーザーは、他のオブジェクトや権限を所有したり他のメカニズムでログインできる必要はありません。
- メッセージ交換を開始するデータベース プリンシパルには、発信側サービスのキューに対する RECEIVE 権限が必要です。
- 発信側サービスを所有するデータベース プリンシパルには、対象サービスに対する SEND 権限が必要です。
- サービスにメッセージを送信するデータベース プリンシパルには、サービスに対する SEND 権限が必要です。別のインスタンスにホストされるサービスの場合、Service Broker ダイアログ セキュリティがリモート インスタンスのデータベース プリンシパルを決定します。詳細については、「Service Broker ダイアログ セキュリティ」を参照してください。Service Broker は、SEND 権限をチェックする際に Windows ロールのメンバシップを考慮しないので注意してください。
- アクティブ化ストアド プロシージャのユーザーとして指定されたユーザーには、そのプロシージャを実行する権限が必要です。一般に、指定されたユーザーは、プロシージャ内のステートメントを実行するための権限を持っています。ただし、ストアド プロシージャ自体が EXECUTE AS 句と共に定義されている場合、ストアド プロシージャ内のステートメントはそのストアド プロシージャにより定義されたセキュリティ コンテキストを使用して実行されることに注意してください。SQL Server は、まず、セキュリティ コンテキストをキューに対し指定されたユーザーに設定します。次に SQL Server はストアド プロシージャを実行し、ストアド プロシージャがセキュリティ コンテキストをプロシージャに対し指定されたユーザーに変更します。
- Service Broker トランスポート セキュリティで SSPI を使用する際、リモート データベースのサービス アカウントは、master の CONNECT 権限を必要とし、ログインにも対応する必要があります。したがって、リモート SQL Server インスタンスの実行に使用するアカウントには、Windows 認証を使用して SQL Server にログインする権限が必要です。ログインには、他の権限やどのデータベース内のオブジェクトも所有する必要はありません。
参照
その他の技術情報
GRANT (Service Broker の権限の許可) (Transact-SQL)
クエリ通知の権限