アクセス許可 (Database Engine)

対象:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)Microsoft Fabric の SQL 分析エンドポイントMicrosoft Fabric の WarehouseMicrosoft Fabric の SQL Database

SQL Server のすべてのセキュリティ保護可能なリソースには、プリンシパルに付与できるアクセス許可が関連付けられています。 Database Engine のアクセス許可は、ログインおよびサーバー ロールに割り当てられたサーバー レベル、およびデータベース ユーザーおよびデータベース ロールに割り当てられたデータベース レベルで管理されます。 Azure SQL Database のモデルは、データベース レベルのアクセス許可に関しては同じしくみを採用していますが、サーバー レベルのアクセス許可は使用できません。 この記事は、アクセス許可の一覧を示します。 アクセス許可の一般的な実装については、「 データベース エンジンのアクセス許可の概要」を参照してください。

SQL Server 2022 (16.x) におけるアクセス許可の総数は 292 件です。 Azure SQL Database でも 292 件のアクセス許可が公開されています。 ほとんどのアクセス許可はすべてのプラットフォームに適用されますが、一部は適用されません。 たとえば、多くのサーバー レベルのアクセス許可は Azure SQL Database では付与できず、一部のアクセス許可は Azure SQL Database でのみ機能します。 新しいアクセス許可は、新しいリリースに伴って段階的に追加されています。 SQL Server 2019 (15.x) では 248 件、SQL Server 2017 (14.x) では 238 件のアクセス許可が公開されていました。 SQL Server 2016 (13.x) では 230 件のアクセス許可が公開されていました。 SQL Server 2014 (12.x) では 219 件のアクセス許可が公開されていました。 SQL Server 2012 (11.x) では 214 件のアクセス許可が公開されていました。 SQL Server 2008 R2 (10.50.x) では 195 件のアクセス許可が公開されていました。 sys.fn_builtin_permissions 記事では、最近のバージョンでどのアクセス許可が新しいかが明確に記載されています。

Microsoft Fabric の SQL Database では、データベース レベルのユーザーとロールのみがサポートされています。 サーバー レベルのログイン、ロール、 sa アカウントは使用できません。 Microsoft Fabric の SQL Database では、データベース ユーザーに対する認証方法として Microsoft Entra ID のみがサポートされています。 詳細については、Microsoft Fabric の SQL Database における認可に関する記事を参照してください。

必要なアクセス許可を把握したら、GRANT、REVOKE、DENY ステートメントを使用して、ログインまたはサーバー ロールにサーバー レベルのアクセス許可を、ユーザーまたはデータベース ロールにデータベース レベルのアクセス許可を適用できます。 例えば次が挙げられます。

GRANT SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;
REVOKE SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;

アクセス許可システムの計画に関するヒントについては、「 データベース エンジンのアクセス許可の概要」を参照してください。

アクセス許可の名前付け規則

ここでは、アクセス許可に名前を付ける際に従う一般的な規則について説明します。

• コントロール

  権限を与えられたユーザーに所有権のような権限を与えます。 アクセス許可を与えられたユーザーは、事実上、セキュリティ保護可能なリソースに対する定義済みのすべてのアクセス許可を持っています。 CONTROL を付与されたプリンシパルは、セキュリティ保護可能なリソースに対するアクセス許可も付与できます。 SQL Server セキュリティ モデルは階層構造であるため、特定のスコープの CONTROL には、そのスコープ下のセキュリティ保護可能なすべてのリソースに対する CONTROL が暗黙的に含まれます。 たとえば、データベースに対する CONTROL は、データベースに対するすべてのアクセス許可、データベース内のすべてのアセンブリに対するすべてのアクセス許可、データベース内のすべてのスキーマに対するすべてのアクセス許可、およびデータベース内のすべてのスキーマに含まれているオブジェクトに対するすべてのアクセス許可を意味します。

• ALTER

  セキュリティ保護可能な特定のリソースのプロパティを変更できるようにします。ただし、所有権は変更できません。 スコープに対して付与された場合、ALTER では、そのスコープに含まれているセキュリティ保護可能なすべてのリソースの変更、作成、または削除も行えるようになります。 たとえば、スキーマに対する ALTER アクセス許可には、スキーマのオブジェクトを作成、変更、および削除するアクセス許可が含まれています。

• ALTER ANY <Server Securable>。ここで、Server Securable には、任意のセキュリティ保護可能なサーバーを指定できます。

  Server Securableの個々のインスタンスを作成、変更、削除できるようにします。 たとえば、ALTER ANY LOGIN では、インスタンス内の任意のログインを作成、変更、または削除できます。

• ALTER ANY <Database Securable>。ここで、Database Securable には、データベース レベルの任意のセキュリティ保護可能なリソースを指定できます。

  Database Securableの個々のインスタンスを CREATE、ALTER、DROP できるようにします。 たとえば、ALTER ANY SCHEMA では、データベース内の任意のスキーマを作成、変更、または削除できます。

• 責任を引き受ける

  このアクセス許可が付与されたユーザーは、その対象のセキュリティ保護可能なリソースの所有権を取得できるようになります。

• IMPERSONATE <ログイン>

  権限を与えられたユーザーが、Login の権限を借用できるようにします。

• IMPERSONATE <User>

  権限を与えられたユーザーが、User の権限を借用できるようにします。

• CREATE <Server Securable>

  権限を与えられたユーザーが Server Securableを作成できるようにします。

• CREATE <Database Securable>

  権限を与えられたユーザーが Database Securableを作成できるようにします。

• CREATE <Schema-contained Securable>

  スキーマに含まれているセキュリティ保護可能なリソースを作成できるようにします。 ただし、特定のスキーマ内でセキュリティ保護可能なリソースを作成するには、そのスキーマに対する ALTER アクセス許可が必要です。

• VIEW DEFINITION

  権限を与えられたユーザーがメタデータにアクセスできるようにします。

• 参考文献

  テーブルを参照する FOREIGN KEY 制約を作成するには、そのテーブルに対する REFERENCES アクセス許可が必要です。

  オブジェクトを参照する WITH SCHEMABINDING 句を含む関数またはビューを作成するには、そのオブジェクトに対する REFERENCES アクセス許可が必要です。

SQL Server アクセス許可の一覧表

次の図は、アクセス許可とそれらの関連性を示します。 一部の高いレベルの許可 ( CONTROL SERVERなど) は複数回列挙されています。 この記事のポスターは、読み取るには小さすぎます。 Database Engine のアクセス許可ポスターは PDF 形式のフルサイズ版としてダウンロードできます。

特定のセキュリティ保護可能なリソースに適用できるアクセス許可

次の表に、主なアクセス許可のクラスおよび各アクセス許可を適用できるセキュリティ保護可能なリソースの種類を示します。

SQL Server アクセス許可

次の表に、SQL Server のすべてのアクセス許可の一覧を示します。 Azure SQL Database のアクセス許可は、サポートされている基本のセキュリティ保護可能なリソースに対してのみ有効です。 Azure SQL Database ではサーバー レベルのアクセス許可は付与できませんが、代わりにデータベース レベルのアクセス許可が使用できる場合があります。

SQL Server 2022 で追加・細分化された新しいアクセス許可

SQL Server 2022 には、次のアクセス許可が追加されています。

• システム メタデータへのアクセスを許可する 10 件の新しいアクセス許可が追加されました。

• 拡張イベントに対する 18 件の新しいアクセス許可が追加されました。

• セキュリティ関連オブジェクトに対する 9 件の新しいアクセス許可が追加されました。

• レジャーに対する 4 件のアクセス許可が追加されました。

• その他、3 件のデータベース レベルのアクセス許可が追加されました。

詳細については、PoLP 準拠を強化するために SQL Server 2022 および Azure SQL で追加・細分化された新しいアクセス許可に関する記事を参照してください。

システム メタデータに対するアクセス許可

サーバー レベル:

• セキュリティ定義を表示する
• パフォーマンス定義を表示する
• サーバーのセキュリティ状態の表示
• サーバーのパフォーマンス状態の表示
• 暗号化で保護された定義を表示する

データベース レベル:

• データベースのセキュリティ状態の表示
• データベースのパフォーマンス状態の表示
• セキュリティ定義の表示
• パフォーマンス定義の表示
• 暗号化されたセキュリティで保護された定義を表示する

拡張イベントに対するアクセス許可

サーバー レベル:

• 任意のイベント セッションを作成する
• 任意のイベント セッションを削除する
• 任意のイベントセッションオプションを変更する
• ALTER ANY EVENT SESSION ADD EVENT
• ALTER ANY EVENT SESSION DROP EVENT
• ALTER ANY EVENT SESSION ENABLE
• ALTER ANY EVENT SESSION DISABLE
• ALTER ANY EVENT SESSION ADD TARGET
• 任意のイベントセッションを変更してターゲットをドロップする

これらすべてのアクセス許可は、ALTER ANY EVENT SESSION という同じ親アクセス許可の下にあります。

データベース レベル:

• 任意のデータベース イベント セッションを作成する
• データベース イベント セッションを削除する
• 任意のデータベースイベントセッションオプションを変更
• 任意のデータベース イベント セッションをALTERし、イベントを追加する
• ALTER ANY DATABASE EVENT SESSION DROP EVENT
• ALTER ANY DATABASE EVENT SESSION ENABLE（任意のデータベースイベントセッションを有効化する）
• あらゆるデータベースのイベントセッションを無効にする
• ALTER ANY DATABASE EVENT SESSION ADD TARGET
• すべてのデータベースイベントセッションのターゲット削除を変更

これらすべてのアクセス許可は、ALTER ANY DATABASE EVENT SESSION という同じ親アクセス許可の下にあります。

セキュリティ関連オブジェクトに対するアクセス許可

• CONTROL (CREDENTIAL)
• ログインの作成
• ユーザーを作成する
• 資格に関する参照
• マスクを解除 (オブジェクト)
• アンマスク (スキーマ)
• エラー ログを表示する
• サーバー セキュリティ監査の表示
• データベース セキュリティ監査の表示

レジャーに対するアクセス許可

• ALTER LEDGER
• ALTER LEDGER の構成
• ENABLE LEDGER
• VIEW LEDGER CONTENT

その他のデータベース レベルのアクセス許可

• ALTER ANY EXTERNAL JOB（任意の外部ジョブを変更）
• 任意の外部ストリームを変更する
• 任意の外部エンドポイントを実行する

アクセス許可チェック アルゴリズムの概要

アクセス許可のチェックは複雑な場合があります。 アクセス許可チェック アルゴリズムには、グループ メンバーシップの重複、所有権の継承、明示的および暗黙的なアクセス許可が含まれます。また、セキュリティ保護可能なエンティティを含むセキュリティ保護可能なクラスに対するアクセス許可の影響を受けることもあります。 アルゴリズムの一般的な手順では、関連するアクセス許可がすべて収集されます。 ブロックする DENY が見つからない場合、十分なアクセス権を付与する GRANT が検索されます。 アルゴリズムには、不可欠な要素が 3 つあります。 セキュリティ コンテキスト、 アクセス許可領域、および 必要なアクセス許可です。

• セキュリティ コンテキスト

  これは、アクセス チェックに対してアクセス許可を与えるプリンシパルのグループです。 EXECUTE AS ステートメントを使用してセキュリティ コンテキストが別のログインまたはユーザーに変更されていない限り、現在のログインまたはユーザーに関連したアクセス許可です。 セキュリティ コンテキストには次のプリンシパルが含まれます。

  • ログイン

  • ユーザー

  • ロールのメンバーシップ

  • Windows グループのメンバーシップ

  • モジュール署名が使用されている場合、ユーザーが現在実行しているモジュールの署名に使用された証明書のログインまたはユーザー アカウント、およびそのプリンシパルに関連付けられたロールのメンバーシップ

• アクセス許可領域

  これは、セキュリティ保護可能なエンティティと、それを含むすべてのセキュリティ保護可能なクラスです。 たとえば、あるテーブル (セキュリティ保護可能なエンティティ) が、セキュリティ保護可能なクラスであるスキーマとデータベースに含まれているとします。 この場合のアクセスは、テーブル、スキーマ、データベース、サーバーの各レベルのアクセス許可による影響を受けます。 詳細については、アクセス許可の階層 (Database Engine) に関する記事を参照してください。

• 必要なアクセス許可

  必要とされるアクセス許可の種類です。 INSERT、UPDATE、DELETE、SELECT、EXECUTE、ALTER、CONTROL などがあります。

  次の例のように、アクセスに複数のアクセス許可が必要な場合もあります。

  • ストアド プロシージャでは、ストアド プロシージャ自体に対する EXECUTE アクセス許可に加えて、ストアド プロシージャによって参照されている複数のテーブルに対する INSERT アクセス許可が必要な場合があります。

  • 動的管理ビューでは、ビューに対する VIEW SERVER STATE と SELECT の両方のアクセス許可が必要な場合があります。

アルゴリズムの一般的な手順

セキュリティ保護可能なリソースに対するアクセスを許可するかどうかを判断するためにアルゴリズムが実際に使用する手順は、関連するプリンシパルとセキュリティ保護可能なリソースによって異なる場合があります。 ただし、アルゴリズムは一般に以下の手順を実行します。

1. ログインが sysadmin 固定サーバー ロールのメンバーであるか、ユーザーが現在のデータベースの dbo ユーザーである場合は、アクセス許可チェックを行いません。

2. 所有権の継承が適用され、その継承内でオブジェクトに対するアクセス チェックが以前にセキュリティ チェックに合格している場合は、アクセスを許可します。

3. 呼び出し元に関連付けられたサーバーレベル、データベースレベル、署名付きモジュールの各 ID を集計して、 セキュリティ コンテキストを作成します。

4. その セキュリティ コンテキスト用に、 アクセス許可領域に対して許可または拒否されたアクセス許可をすべて収集します。 アクセス許可は、GRANT、GRANT WITH GRANT、または DENY として明示的に指定される場合と、暗黙アクセス許可または包含アクセス許可の GRANT または DENY である場合があります。 たとえば、スキーマに対する CONTROL を使用した場合、テーブルに対する CONTROL も暗黙的に適用されます。 また、テーブルに対して CONTROL 権限を使用した場合、SELECT 権限も暗黙的に適用されます。 したがって、スキーマに対する CONTROL が付与された場合、テーブルに対する SELECT も付与されます。 テーブルに対する CONTROL 権限が拒否された場合、テーブルに対する SELECT 権限も拒否されます。

   注

   列レベルのアクセス許可の GRANT により、オブジェクト レベルの DENY がオーバーライドされます。 詳細については、オブジェクトに対する DENY アクセス許可に関する記事を参照してください。

5. 必要なアクセス許可を識別します。

6. アクセス許可領域内のオブジェクトについて、必要なアクセス許可が、セキュリティ コンテキストの任意の ID に対し直接または暗黙的に拒否されている場合は、アクセス許可チェックが不合格となります。

7. アクセス許可領域内のすべてのオブジェクトについて、必要なアクセス許可がセキュリティ コンテキストのいずれの ID に対しても直接または暗黙的に拒否されておらず、必要なアクセス許可に GRANT アクセス許可または GRANT WITH GRANT アクセス許可が含まれている場合は、アクセス許可チェックが合格となります。

列レベルのアクセス許可に関する特別な考慮事項

列レベルのアクセス許可は構文 <table_name>(<column _name>) を使用して付与されます。 例えば次が挙げられます。

GRANT SELECT ON OBJECT::Customer(CustomerName) TO UserJoe;

テーブルの DENY は、列の GRANT によりオーバーライドされます。 ただし、その後にテーブルの DENY があると、列の GRANT は削除されます。

例

このセクションでは、アクセス許可に関する情報を取得する例を示します。

A. 付与できるアクセス許可の完全な一覧を返す

次のステートメントは、fn_builtin_permissions 関数を使用してすべての Database Engine のアクセス許可を返します。 詳細については、「sys.fn_builtin_permissions」 を参照してください。

SELECT * FROM fn_builtin_permissions(default);
GO

B. オブジェクトの特定のクラスに対するアクセス許可を返す

次の例では、 fn_builtin_permissions を使用してセキュリティ保護可能なカテゴリに使用できるすべてのアクセス許可を表示します。 この例では、アセンブリに対するアクセス許可を返します。

SELECT * FROM fn_builtin_permissions('assembly');
GO

C. オブジェクトに対する実行中のプリンシパルに付与されたアクセス許可を返す

次の例では、 fn_my_permissions を使用して、指定したセキュリティ保護可能なリソースについて、呼び出し元のプリンシパルが保持している有効なアクセス許可の一覧を返します。 この例では、Orders55 という名前のオブジェクトに対するアクセス許可を返します。 詳細については、「sys.fn_my_permissions」 を参照してください。

SELECT * FROM fn_my_permissions('Orders55', 'object');
GO

D. 指定したオブジェクトに適用できるアクセス許可を返す

次の例は、 Yttriumと呼ばれるオブジェクトに適用できるアクセス許可を返します。 オブジェクト OBJECT_ID の ID を取得するために、組み込み関数 Yttrium が使用されています。

SELECT * FROM sys.database_permissions
    WHERE major_id = OBJECT_ID('Yttrium');
GO

関連するコンテンツ

• アクセス許可の階層 (Database Engine)
• sys.database_permissions (Transact-SQL)