権限 (データベース エンジン)

すべての SQL Server セキュリティ保護可能なリソースには、プリンシパルに付与できるアクセス許可が関連付けられています。 このトピックでは、次の情報を提供します。

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

• 特定のセキュリティ対象に関する権限

• SQL Server のアクセス許可

• アクセス許可チェック アルゴリズム

• 例

権限の命名規則

次に、アクセス許可の名前付けに従う一般的な慣例について説明します。

• コントロール

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

• 変更する

  特定のセキュリティ保護対象の所有権を除くプロパティを変更する機能を付与します。 スコープに対して付与されると、ALTER は、そのスコープ内に含まれるセキュリティ保護可能なリソースを変更、作成、または削除する機能も付与します。 たとえば、スキーマに対する ALTER 権限には、スキーマからオブジェクトを作成、変更、および削除する機能が含まれます。

• ALTER ANY <Server Securable>、Server Securable は任意のサーバーで利用可能なセキュリティ保護対象です。

  サーバー セキュリティ保護可能なサーバーの個々のインスタンスを作成、変更、または削除する機能を付与します。 たとえば、ALTER ANY LOGIN は、インスタンス内のログインを作成、変更、または削除する機能を提供します。

• ALTER ANY <データベース内の保護可能なオブジェクト>。データベース内の保護可能なオブジェクトは、データベースレベルで任意の保護対象となり得ます。

  データベース保護対象リソースの個々のインスタンスを作成、変更、または削除することを可能にします。 たとえば、ALTER ANY SCHEMA は、データベース内のスキーマを作成、変更、または削除する機能を提供します。

• 責任を引き受ける

  権限付与対象ユーザーが、付与されているセキュリティ保護可能なリソースの所有権を取得できるようにします。

• IMPERSONATE <ログイン>

  権限付与対象ユーザーがログインを偽装できるようにします。

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

  権限付与することで対象ユーザーが他のユーザーになりすますことが可能になります。

• CREATE <Server Securable>

  権限付与対象ユーザーに 、サーバー セキュリティ保護可能なリソースを作成する権限を付与します。

• CREATE <Database Securable>

  権限付与対象ユーザーにデータベース保護可能項目を作成する権限を付与します。

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

  スキーマに含まれるセキュリティ対象のリソースを作成する機能を付与します。 ただし、特定のスキーマ内でセキュラブルを作成するには、スキーマに対する ALTER 権限が必要です。

• ビューの定義

  権限付与対象ユーザーがメタデータにアクセスできるようにします。

• 参考文献

  テーブルを参照する FOREIGN KEY 制約を作成するには、テーブルに対する REFERENCES 権限が必要です。

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

SQL Server のアクセス許可のグラフ

pdf 形式のすべてのデータベース エンジンのアクセス許可のポスター サイズのグラフについては、 https://github.com/microsoft/sql-server-samples/blob/master/samples/features/security/permissions-posters/Microsoft_SQL_Server_2017_and_Azure_SQL_Database_permissions_infographic.pdfを参照してください。

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

次の表に、アクセス許可の主要なクラスと、それらが適用されるセキュリティ保護可能なリソースの種類を示します。

SQL Server と SQL Database のアクセス許可

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

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

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

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

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

  • ログイン

  • ユーザー

  • ロール メンバーシップ

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

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

• アクセス許可領域

  これは、セキュリティ保護対象のエンティティと、セキュリティ保護対象を含むセキュリティ保護対象のクラスです。 たとえば、テーブル (セキュリティ保護可能なエンティティ) は、スキーマのセキュリティ保護可能なクラスとデータベースのセキュリティ保護可能なクラスに含まれます。 アクセスは、テーブル、スキーマ、データベース、およびサーバー レベルのアクセス許可の影響を受ける可能性があります。 詳細については、「 権限階層 (データベース エンジン)」を参照してください。

• 必要なアクセス許可

  必要なアクセス許可の種類。 たとえば、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 をオーバーライドします。

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

6. 必要なアクセス許可が、アクセス許可空間内のオブジェクトのセキュリティ コンテキスト内のいずれかの ID に対して直接または暗黙的に拒否された場合は、アクセス許可チェックを失敗します。

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

例示

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

ある。 許可可能なアクセス許可の完全な一覧を返す

次のステートメントは、 fn_builtin_permissions 関数を使用して、すべてのデータベース エンジンのアクセス許可を返します。 詳細については、「 sys.fn_builtin_permissions (Transact-SQL)」を参照してください。

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 (Transact-SQL)」を参照してください。

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

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

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

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

こちらもご覧ください

権限の階層 (データベース エンジン)
sys.database_permissions (Transact-SQL)