アクセス許可 (データベース エンジン)

適用対象:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)Microsoft Fabric の SQL 分析エンドポイントMicrosoft Fabric のウェアハウスMicrosoft Fabric の SQL データベース

SQL Server のすべてのセキュリティ保護可能なリソースには、プリンシパルに付与できるアクセス許可が関連付けられています。 データベース エンジン のアクセス許可は、ログインおよびサーバー ロールに割り当てられたサーバー レベル、およびデータベース ユーザーおよびデータベース ロールに割り当てられたデータベース レベルで管理されます。 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 データベースでは、データベース レベルのユーザーとロールのみがサポートされます。 サーバー レベルのログイン、ロール、 sa アカウントは使用できません。 Microsoft Fabric の SQL データベースでは、データベース ユーザーの 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

  権限を与えられたユーザーに所有権のような権限を与えます。 アクセス許可を与えられたユーザーは、事実上、セキュリティ保護可能なリソースに対する定義済みのすべてのアクセス許可を持っています。 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 の権限を借用できるようにします。

• ユーザーになりすます <ユーザー>

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

• CREATE <Server Securable>

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

• CREATE <Database Securable>

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

• CREATE <Schema に含まれるセキュリティ保護可能なリソース>

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

• VIEW 定義

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

• REFERENCES

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

  オブジェクトを参照するFUNCTION句を使用してVIEWまたはWITH SCHEMABINDINGを作成するには、オブジェクトに対する REFERENCES 権限が必要です。

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

次の図は、アクセス許可とそれらの関連性を示します。 一部の高いレベルの許可 ( CONTROL SERVERなど) は複数回列挙されています。 この記事のポスターは、読み取るには小さすぎます。 データベース エンジン のアクセス許可ポスターは 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 で追加・細分化された新しいアクセス許可に関する記事を参照してください。

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

サーバー レベル:

• VIEW 任意のセキュリティ定義
• VIEW 任意のパフォーマンス定義
• VIEW サーバー セキュリティの状態
• VIEW サーバーのパフォーマンスの状態
• VIEW あらゆる暗号技術で保護された定義

データベース レベル:

• VIEW DATABASE セキュリティの状態
• VIEW DATABASE パフォーマンスの状態
• VIEW セキュリティ定義
• VIEW パフォーマンスの定義
• VIEW 暗号化によってセキュリティで保護された定義

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

サーバー レベル:

• 何でも作成 EVENT SESSION
• いずれかをドロップ EVENT SESSION
• 任意の EVENT SESSION オプションを変更
• ALTER ANY EVENT SESSION ADD イベント
• ALTER ANY EVENT SESSION DROP イベント
• 任意の EVENT SESSION の ALTER を有効化
• 任意の EVENT SESSION の無効化を変更
• 任意の EVENT SESSION ターゲットを追加
• ALTER ANY EVENT SESSION DROP TARGET

これらのアクセス許可はすべて、同じ親アクセス許可の下に存在します。 ALTER ANY EVENT SESSION

データベース レベル:

• あらゆるものを作成 DATABASEEVENT SESSION
• 任意のDATABASEEVENT SESSIONをドロップ
• 任意のDATABASEEVENT SESSIONオプションを変更
• ALTER ANY DATABASEEVENT SESSION ADD イベント
• ALTER ANY DATABASEEVENT SESSION DROP イベント
• 任意のDATABASEEVENT SESSIONの有効化の変更
• 任意の DATABASEEVENT SESSION を無効にする
• ALTER ANY DATABASEEVENT SESSION ターゲットの追加
• 任意の DATABASEEVENT SESSION DROP TARGET を変更

これらすべてのアクセス許可は、同じ親アクセス許可の下に存在します。 ALTER ANY DATABASEEVENT SESSION

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

• 制御 (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• 参考資料 (CREDENTIAL)
• UNMASK (オブジェクト)
• マスク解除 (SCHEMA)
• VIEW 任意のエラー ログ
• VIEW サーバー セキュリティ監査
• VIEW DATABASE セキュリティ監査

台帳のアクセス許可

• LEDGER を変更
• ALTER LEDGER の構成
• Ledger を有効にする
• VIEW 台帳の内容

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

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

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

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

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

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

  • ログイン

  • ユーザー

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

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

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

• アクセス許可領域

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

• 必要なアクセス許可

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

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

  • ストアド プロシージャには、ストアド プロシージャに対する EXECUTE 権限と、ストアド プロシージャによって参照される複数のテーブルに対する INSERT 権限の両方が必要な場合があります。

  • 動的管理ビューには、 VIEW サーバー状態とビューに対する SELECT 権限の両方が必要な場合があります。

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

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

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

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

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

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

   Note

   列レベルのアクセス許可の GRANT は、オブジェクト レベルの DENY をオーバーライドします。 詳細については、「 DENY オブジェクトの権限」を参照してください。

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

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

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

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

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

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

テーブルの DENY は、列の GRANT によってオーバーライドされます。 ただし、テーブルの後続の DENY では、列 GRANTが削除されます。

Examples

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

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

次のステートメントは、fn_builtin_permissions 関数を使用してすべての データベース エンジン のアクセス許可を返します。 詳細については、「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

関連コンテンツ

• アクセス許可の階層 (データベース エンジン)
• sys.database_permissions(Transact-SQL)