次の方法で共有


SQL Server エージェントのセキュリティの実装

適用対象: SQL Server Azure SQL Managed Instance

重要

現在、Azure SQL Managed Instance によって、すべてではありませんが、ほとんどの SQL Server エージェントの機能がサポートされています。 詳細については、Azure SQL Managed Instance と SQL Server の T-SQL の相違点に関するページを参照してください。

SQL Server エージェントを使用すると、データベース管理者は、各ジョブ ステップをそのジョブ ステップの実行に必要なアクセス許可だけがあるセキュリティ コンテキスト内で実行できます。適切なセキュリティ コンテキストは、SQL Server エージェント プロキシによって決まります。 特定のジョブ ステップに対応する権限を設定するには、必要な権限のあるプロキシを作成し、そのプロキシをジョブ ステップに割り当てます。 プロキシは、複数のジョブ ステップに対して指定できます。 同じ権限を必要とするジョブ ステップに対しては、同じプロキシを使用します。

次のセクションでは、ユーザーが SQL Server エージェントを使用してジョブを作成または実行するために、許可する必要のあるデータベース ロールについて説明します。

SQL Server エージェントへのアクセスの許可

ユーザーが SQL Server エージェントを使用するには、次の 1 つ以上の固定データベース ロールのメンバーである必要があります。

  • SQLAgentUserRole

  • SQLAgentReaderRole

  • SQLAgentOperatorRole

上記のロールは、 msdb データベースに格納されています。 既定では、これらのデータベース ロールのメンバーであるユーザーはいません。 これらのロールのメンバーシップは、明示的に許可する必要があります。 sysadmin 固定サーバー ロールのメンバーであるユーザーは、SQL Server エージェントへのフル アクセスが許可されているので、上記の固定データベース ロールのメンバーでなくても SQL Server エージェントを使用できます。 上記のいずれかのデータベース ロールまたは sysadmin ロールのメンバーでないユーザーは、SQL Server Management Studio を使用して SQL Server に接続する際に、SQL Server エージェント ノードを使用できません。

これらのデータベース ロールのメンバーは、自身が所有するジョブの表示および実行に加えて、既存のプロキシ アカウントとして実行するジョブ ステップの作成を行えます。 これらの各ロールに関連付けられている特定の権限の詳細については、「 SQL Server エージェントの固定データベース ロール」を参照してください。

sysadmin 固定サーバー ロールのメンバーには、プロキシ アカウントを作成、変更、および削除する権限があります。 sysadmin ロールのメンバーには、プロキシを指定せずに SQL Server エージェント サービス アカウントとして実行するジョブ ステップを作成する権限があります。このアカウントは、SQL Server エージェントの起動に使用されるアカウントです。

ガイドライン

SQL Server エージェントのセキュリティを向上するには、次のガイドラインに従ってください。

  • プロキシ専用のユーザー アカウントを作成し、ジョブ ステップの実行にはこれらのプロキシ ユーザー アカウントのみを使用します。

  • プロキシ ユーザー アカウントに対し、必要な権限のみを許可します。 特定のプロキシ アカウントに割り当てられたジョブ ステップの実行に実際に求められる権限だけを許可してください。

  • SQL Server エージェント サービスは、Windows Administrators グループのメンバーである Microsoft Windows アカウントで実行しないでください。

  • プロキシの安全性は、SQL Server 資格情報ストアと同程度です。

  • ユーザーの書き込み操作で NT イベント ログへの書き込みが可能な場合は、SQL Server エージェントを介して警告を発行できます。

  • NT 管理者アカウントを、サービス アカウントまたはプロキシ アカウントとして指定しないでください。

  • SQL Server と SQL Server エージェントは、他方の資産にアクセスできます。 この 2 つのサービスは単一の処理領域を共有し、SQL Server エージェントは SQL Server サービスの sysadmin になります。

  • TSX (ターゲット サーバー) を MSX (マスター サーバー) に登録する場合、MSX の sysadmin が SQL Serverの TSX インスタンスを完全に制御します。

  • ACE は拡張機能であり、それ自体を呼び出すことはできません。 Chainer ScenarioEngine.exe (別名 Microsoft.SqlServer.Chainer.Setup.exe) によって ACE が呼び出されます。 他のホスト プロセスでも ACE を呼び出すことができます。

  • ACE は、SSDP によって所有される次の構成 DLL に依存します。理由は、これらの DLL の API は ACE によって呼び出されるためです。

    • SCO: Microsoft.SqlServer.Configuration.Sco.dll。仮想アカウント用の新しい SCO 検証が含まれます。

    • Cluster: Microsoft.SqlServer.Configuration.Cluster.dll

    • SFC: Microsoft.SqlServer.Configuration.SqlConfigBase.dll

    • Extension: Microsoft.SqlServer.Configuration.ConfigExtension.dll

リンク サーバー

Azure SQL Managed Instance などの一部のシナリオでは、リンク サーバー経由でリモート サーバーで Transact-SQL (T-SQL) クエリを実行する SQL Agent ジョブを実行するには、ローカル ログインをリモート サーバー上のログインにマップする必要があります。

sp_addlinkedsrvlogin を使用して、ローカル サーバー上のログインと、T-SQL クエリを実行するために必要なアクセス許可を持つリモート サーバー上のログインとの間のマッピングを作成します。 SQL Agent ジョブは、リンク サーバーを介してリモート サーバーに接続すると、リモート ログインのコンテキストで T-SQL クエリを実行します。

次の表では、Azure SQL Managed Instance の SQL Agent ジョブ所有者に基づいてログインをマップする方法について説明します。

SQL Agent ジョブの所有者 ログインをマップする方法
sysadmin ではないユーザー SQL Agent ジョブを所有する ローカル ユーザー をリモート ログインにマップします。
sysadmin @locallogin パラメーターを NULL に設定してすべてのローカル ユーザーをリモート ログインにマップします。

Note

ローカル サーバーが Azure SQL Managed Instance の場合は、SQL Agent ジョブのリモート サーバーでログインを作成する必要があります。 ユーザーを正しくマップできないと、次の例のようなエラーが発生する可能性があります。

  • Windows logins are not supported in this version of SQL Server
  • Linked servers cannot be used under impersonation without a mapping for the impersonated login