アクセス制御の構成

このトピックでは、システム定義のロール(Snowflakeが提供)とカスタムロール(オプション)を使用してオブジェクトレベルのセキュリティを構成する方法を説明します。

このトピックの内容:

アカウント管理

アカウント管理者としての追加ユーザーの指定

デフォルトでは、各アカウントにはアカウント管理者として指定された1人のユーザーがいます(ユーザーはシステム定義の ACCOUNTADMIN ロールを付与されています)。アカウント管理者として少なくとも1人の他のユーザーを指定することをお勧めします。これにより、アカウント管理者の1人がログインできない場合は特に、アカウントレベルのタスクを実行できる少なくとも1人のユーザーがアカウントに常に存在するようになります。

これらの追加のアカウント管理者については、新しいユーザーを作成するか、既存のユーザーを指定するかを選択できますが、必ず次を指定してください。

  • ユーザーに ACCOUNTADMIN ロールを付与しますが、このロールをデフォルトとして設定 しないで ください。代わりに、下位レベルの管理ロール(例:SYSADMIN)またはデフォルトとしてカスタムロールを指定します。これにより、アカウント管理者が誤って ACCOUNTADMIN ロールを使用してオブジェクトを作成することを防止できます。

  • 各ユーザーに電子メールアドレスが指定されていることを確認します(多要素認証に必要)。

例えば、 user2 という名前の既存のユーザーに ACCOUNTADMIN および SYSADMIN のロールを付与し、既定のロールとして SYSADMIN を指定します。

GRANT ROLE ACCOUNTADMIN, SYSADMIN TO USER user2;

ALTER USER user2 SET EMAIL='user2@domain.com', DEFAULT_ROLE=SYSADMIN;

アカウント管理者ごとに MFA を有効化

Snowflakeアカウントの最高レベルのセキュリティを確保するため、機密データを変更または表示できるユーザーには、多要素認証(MFA)の使用をログインの必須条件とすることを 強く お勧めします。

この推奨事項は特に ACCOUNTADMIN のロールがあるユーザーに適用されますが、SECURITYADMIN および SYSADMIN のロールがあるユーザーを含むように拡張することもできます。

詳細については、 アクセス制御の考慮事項 および 多要素認証(MFA) をご参照ください。

ロール階層の作成

カスタムロールを作成するときは、最終的に高レベルの管理者ロールに割り当てられるロール階層を作成することを検討してください。一般に、SYSADMIN ロールは他のすべてのロールが階層内で割り当てられているロールと同じように機能しますが、十分な権限のあるロールがこの機能を提供できることに注意することが重要です。SYSADMIN ロールは、アカウントでウェアハウス、データベース、およびデータベースオブジェクトを作成し、それらの権限を他のロールに付与する権限があるシステム定義のロールです。デフォルトのシステム階層では、最上位の ACCOUNTADMIN ロールがシステム管理者ロールを管理します。

ロールを2番目のロールに付与して、ロール階層を作成します。その後、その2番目のロールを3番目のロールに付与できます。ロールに関連付けられた権限は、階層内のそのロールの のロール(親ロール)によって継承されます。

例えば、特定のスキーマで すべての 権限があるカスタムロールを作成できます。

  1. このロールに次の権限を付与します。

    • スキーマを含むデータベース上の USAGE

    • クエリするテーブルを含むスキーマ上の ALL

    • スキーマ内のテーブルに対してクエリを実行するために使用されるウェアハウス上の USAGE。

  2. ロールの階層を作成します。カスタムロールを SYSADMIN ロールに付与します。親ロールは、各子ロールに関連付けられたオブジェクト権限を継承します。

  3. 指定された権限を必要とするユーザーにカスタムロールを付与します。

ロールのあるユーザーは、スキーマ内のオブジェクトを作成して使用できます。次の図は、ロール階層の例と各ロールに付与される権限を示しています。

Role hierarchy and privileges granted to each role

注釈

次のセクションでは、基本的なロール階層に custom という名前のカスタムロールを作成するための詳細な手順を説明します。この custom ロールにより、ユーザーはスキーマ内にオブジェクトを作成し、それらのオブジェクトを(オブジェクト所有者として)管理できます。ロールには、スキーマ内の既存のオブジェクトに対する権限はありませんが、スキーマまたはオブジェクトレベルの追加権限を介して付与できます。

このセクションの SQL ステートメントを、SECURITYADMIN ロール以上のユーザーとして実行します。

カスタムロールの作成

  1. custom ロールを作成します。

    CREATE ROLE custom
       COMMENT = 'This role has all privileges on schema_1';
    
  2. custom ロールに次のオブジェクト権限を付与します。

    • スキーマ(database_a)を含むデータベース上の USAGE。スキーマ内のオブジェクトを使用するには、ロールにはコンテナデータベースに対する USAGE 権限も必要です。

    • スキーマ上(schema_1)上の ALL [ PRIVILEGES ]。

    • USAGE クエリの実行に使用されるウェアハウス(warehouse_1)。このロールのあるユーザーは、このウェアハウスを使用してクエリを実行できます。

    GRANT USAGE
      ON DATABASE database_a
      TO ROLE custom;
    
    GRANT ALL
      ON SCHEMA database_a.schema_1
      TO ROLE custom;
    
    GRANT USAGE
      ON WAREHOUSE warehouse_1
      TO ROLE custom;
    

別のロールへのロールの付与

上位レベルの階層のロールにロールを割り当てます。この例では、 custom ロールを SYSADMIN ロールに割り当てています。SYSADMIN ロールは、 custom ロールに付与されたオブジェクト権限を継承します。

GRANT ROLE custom
   TO ROLE sysadmin;

注釈

より複雑な例では、 custom ロールを SYSADMIN の別の子ロール(またはデータベースを作成するための十分な権限があるカスタムロールなどの別の管理者ロール)に割り当てることができます。SYSADMIN ロールは、 custom ロールとその親ロールに割り当てられた結合された権限を継承します。階層内の custom の上のロールがオブジェクトを所有している場合、ロール階層により、SYSADMIN ロールのメンバーもそれらのオブジェクトを(間接的に)所有し、期待どおりに管理できます。

ユーザーへのロールの付与

  1. ALTER USER を使用して、変更するユーザーを無効化します。これにより、ユーザーに変更を加えている間、そのユーザーのすべての既存のセッションが強制的に閉じられます。例えば、次のコマンドによってユーザーBonnie Smith(bsmith)を無効化します。

    ALTER USER bsmith SET DISABLED=TRUE;
    
  2. ユーザーに custom ロールを割り当てます。

    GRANT ROLE custom
       TO USER bsmith;
    
  3. ユーザーの既定のロールを設定します。次のコマンドは、ユーザーBonnie Smithの既定のロールを定義します。

    ALTER USER bsmith
       SET DEFAULT_ROLE = custom;
    
  4. ALTER USER コマンドを使用してユーザーを有効化します。これにより、ユーザーは新しい既定のロールで再度ログインできます。例:

    ALTER USER bsmith SET DISABLED=false;
    

付与された権限の表示

オブジェクトに付与されている現在の権限セットを表示するには、 SHOW GRANTS コマンドを実行します。スキーマの現在の権限を表示するには、次のコマンドを実行します。

SHOW GRANTS ON SCHEMA <database_name>.<schema_name>;

例えば、 カスタムロールの作成 で付与された database_a.schema_1 の権限を表示するには、次のコマンドを実行します。

SHOW GRANTS ON SCHEMA database_a.schema_1;

Snowflakeは次の結果を返します。

+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+
| created_on                    | privilege          | granted_on | name                | granted_to | grantee_name | grant_option | granted_by   |
|-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------|
| 2016-08-24 12:35:08.000 -0700 | OWNERSHIP          | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | SYSADMIN     | true         | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FILE FORMAT | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FUNCTION    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE SEQUENCE    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE STAGE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE TABLE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE VIEW        | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MODIFY             | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MONITOR            | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | USAGE              | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+

SHOW GRANTS コマンドを実行して、ロールに付与された現在の権限セット、またはユーザーに付与された現在のロールセットを表示することもできます。

SHOW GRANTS TO ROLE <role_name>;
SHOW GRANTS TO USER <user_name>;

例えば、次のコマンドを実行して、 カスタムロールの作成 で作成した custom ロールに付与された権限を表示します。

SHOW GRANTS TO ROLE custom;

Snowflakeは次の結果を返します。

+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+
| created_on                    | privilege          | granted_on | name                | granted_to | grantee_name | grant_option | granted_by   |
|-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------|
| 2016-11-22 12:34:29.000 -0800 | USAGE              | DATABASE   | DATABASE_A          | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FILE FORMAT | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FUNCTION    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE SEQUENCE    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE STAGE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE TABLE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE VIEW        | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MODIFY             | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MONITOR            | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | USAGE              | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | USAGE              | WAREHOUSE  | WAREHOUSE_1         | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+

注釈

特定のオブジェクトで SHOW GRANTS コマンドを実行するには、そのオブジェクトタイプに対して SHOW コマンドを実行するのと同じオブジェクト権限が必要です。

例えば、テーブルで SHOW GRANTS コマンドを実行するには、テーブルとコンテナデータベースおよびスキーマに対する次の権限が必要です。

データベース

USAGE

スキーマ

USAGE

テーブル

任意の権限

読み取り専用ロールの作成

特定のスキーマ(database_a.schema_1 など)のテーブルのクエリに限定されたロールが必要だと想定します。このロールを使用してコマンドを実行するユーザーは、テーブルデータを更新したり、追加のデータベースオブジェクトを作成したり、テーブルを削除したりすることはできません。

このシナリオでは、スキーマとそのテーブルへのアクセスを制限したカスタムロールを作成できます。次に、スキーマとテーブルへの読み取り専用アクセスを必要とするユーザーに読み取り専用ロールを付与します。これらのユーザーは、スキーマオブジェクトを誤って変更または削除することを心配することなく、限られた既定のロールで作業できます。

注釈

このセクションの SQL ステートメントを、SECURITYADMIN ロール以上のユーザーとして実行します。

  1. カスタム read_only_rl ロールを作成します。

    CREATE ROLE read_only_rl
       COMMENT = 'This role is limited to querying tables in schema_1';
    
  2. ロール階層を実装したと想定して(推奨)、ロール階層の上位レベルのロールにロールを割り当てます。この例では、 read_only_rl ロールを SYSADMIN ロールに割り当てています。SYSADMIN ロールは、 read_only_rl ロールに付与されたオブジェクト権限を継承します。

    GRANT ROLE read_only_rl
       TO ROLE sysadmin;
    
  3. read_only_rl ロールに次のオブジェクト権限を付与します。

    • スキーマ(database_a)を含むデータベース上の USAGE。

    • クエリするテーブルを含むスキーマ(schema_1)上の USAGE。スキーマ内のオブジェクトを使用するには、ロールにデータベースとスキーマに対する USAGE 権限も必要です。

    • すべての既存のテーブル上の SELECT。

    • テーブル(warehouse_1)でクエリを実行するために使用されるウェアハウス上のUSAGE。このロールのあるユーザーは、このウェアハウスを使用してクエリを実行できます。

    GRANT USAGE
      ON DATABASE database_a
      TO ROLE read_only_rl;
    
    GRANT USAGE
      ON SCHEMA database_a.schema_1
      TO ROLE read_only_rl;
    
    GRANT SELECT
      ON ALL TABLES IN SCHEMA database_a.schema_1
      TO ROLE read_only_rl;
    
    GRANT USAGE
      ON WAREHOUSE warehouse_1
      TO ROLE read_only_rl;
    

    注釈

    GRANT SELECT ON ALL TABLES IN SCHEMA <schema> ステートメントは、 既存の テーブルにのみ適用されます。読み取り専用ロールには、その後スキーマで作成されたすべてのテーブルに対する SELECT 権限を付与する必要があります。例:

    GRANT SELECT
      ON TABLE database_a.schema_1.table_new
      TO ROLE read_only_rl;
    
  4. ALTER USER を使用して、変更するユーザーを無効化します。これにより、ユーザーに変更を加えている間、そのユーザーのすべての既存のセッションが強制的に閉じられます。例えば、次のコマンドによってユーザーBonnie Smith(bsmith)を無効化します。

    ALTER USER bsmith SET DISABLED=TRUE;
    
  5. ユーザーに read_only_rl ロールを割り当てます。

    GRANT ROLE read_only_rl
       TO USER bsmith;
    
  6. ユーザーの既定のロールを設定します。次のコマンドは、ユーザーBonnie Smithの既定のロールを定義します。

    ALTER USER bsmith
       SET DEFAULT_ROLE = read_only_rl;
    
  7. ALTER USER コマンドを使用してユーザーを有効化します。これにより、ユーザーは新しい既定のロールで再度ログインできます。例:

    ALTER USER bsmith SET DISABLED=false;
    

オブジェクトに対する将来の付与の割り当て

To simplify grant management, future grants allow defining an initial set of privileges to grant on new (i.e. future) objects of a certain type in a database or a schema. As new objects are created, the defined privileges are automatically granted to a specified role.

将来の付与では、指定されたタイプの新しいオブジェクトに付与される権限の 初期 セットのみを定義します。個々のオブジェクトが作成されると、管理者は明示的に追加の権限を付与したり、オブジェクトに対する権限を取り消したりできます。これにより、スキーマまたはデータベース内のすべてのオブジェクトに対するきめ細かいアクセス制御が可能になります。

Considerations

  • Future grants defined for an object at the database level apply to all objects of that type created in future. For more information, see Defining Future Grants on Database or Schema Objects (in this topic).

  • You must define future grants on each object type (schemas, tables, views, streams, etc.) individually. For more information, see Defining Future Grants on Existing Database or Schema Objects (in this topic).

  • The privileges defined using future grants are automatically granted at object creation time.

  • When future grants are defined at both the database and schema level, the schema level grants take precedence over the database level grants, and the database level grants are ignored.

  • Database level future grants apply to both regular and managed access schemas. For more information, see Security Privileges Required to Manage Future Grants (in this topic).

Security Privileges Required to Manage Future Grants

The MANAGE GRANTS global privilege is required to grant or revoke privileges on future objects at the database level. By default, only the SECURITYADMIN and ACCOUNTADMIN roles have the MANAGE GRANTS privilege.

In addition, in a managed access schema, the schema owner (i.e. the role with the OWNERSHIP privilege on the schema) can manage future grants on objects in the schema.

Defining Future Grants on Database or Schema Objects

You can assign future grants on database or schema objects using the GRANT <権限> ... TO ROLE command with the ON FUTURE keywords.

Code example for setting future grants at the database level:

use role accountadmin;

-- Grant the USAGE privilege on all future schemas in a database to role R1
grant usage on future schemas in database DB1 to role R1;

Code example for setting future grants at the schema level:

use role accountadmin;

-- Grant the SELECT privilege on all future tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA DB1.schema1 TO ROLE R1;

-- Grants the SELECT and INSERT privileges on all future tables in a schema to R1
grant select,insert on future tables in schema DB1.schema1 to role R1;

Defining Future Grants on Existing Database or Schema Objects

Future grants only pertain to new objects. You must explicitly grant the desired privileges to a role on existing objects using the GRANT <権限> ... TO ROLE command.

Code Example:

use role accountadmin;

-- Grant the USAGE privilege on all existing schemas in a database to role R1
grant usage on all schemas in database DB1 to role R1;

-- Grant the SELECT privilege on all existing tables in a schema to role R1
grant select on all tables in schema DB1.schema1 to role R1

Revoking Future Grants on Database or Schema Objects

You can revoking future grants on database objects using the REVOKE <権限> ... FROM ROLE command with the ON FUTURE keywords.

注釈

Revoking future grants on database objects, only removes privileges granted on future objects of a specified type rather than existing objects. Any privileges granted on existing objects are retained.

Code Example:

use role accountadmin;

-- Revoke the USAGE privilege on all existing schemas in a database from role R1
revoke usage on all schemas in database DB1 from role R1;

-- Revoke the SELECT and INSERT privilages on tables in a schema from the role R1
revoke select,insert on future tables in schema DB1.schema1 from role R1;

Managing Future Grants Using the Web Interface

You can also define future grants using the web interface:

  • For database objects: Click Databases Databases tab » <db_name> » <object_type> » <object_name> » Grant Privileges.

  • For schema objects: Click Databases Databases tab » <db_name> » Schemas » <schema_name> » Grant Privileges.

Restrictions and Limitations

The following restrictions and limitations apply to future grants at database or schema level:

  • Future grants are not supported for:

    • Data sharing

    • Data replication

  • Future grants are supported on named stages with the following restrictions:

    • The WRITE privilege cannot be specified without the READ privilege.

    • The READ privilege cannot be revoked if the WRITE privilege is present.

    • For internal stages, only future grants with the READ or WRITE privilege are materialized.

    • For external stages, only future grants with the USAGE privileges are materialized.

  • Future grants are not applied when renaming or swapping a table.

  • No more than one future grant of the OWNERSHIP privilege is allowed on each securable object type.

  • Database level future grants of OWNERSHIP privilege on the objects of managed access schemas in the database are not affected.

  • When a database is cloned, the schemas in the cloned database copy the future privileges from the source schemas. This maintains consistency with the regular object grants, in which the grants of the source object (i.e. database) are not copied to the clone, but the grants on all the children objects (i.e. schemas in the database) are copied to the clones.

管理アクセススキーマの作成

管理アクセススキーマは、オブジェクトの権限管理をロックダウンすることでセキュリティを向上させます。

通常の(管理されていない)スキーマでは、オブジェクト所有者(オブジェクトに対する OWNERSHIP 権限のあるロール)は、オブジェクトへのアクセスを他のロールに付与できます。

管理アクセススキーマを使用すると、オブジェクトの所有者は付与を決定する機能を失います。スキーマの所有者(スキーマに対する OWNERSHIP 権限があるロール)または MANAGE GRANTS 権限があるロールのみが、スキーマ内のオブジェクトに対する権限を付与できます(将来の付与 を含みます)。

ウェブインターフェイスまたは SQL を使用して、管理アクセススキーマを作成できます。

ウェブインターフェイス

Databases Databases tab » <データベース名> » Schemas » Create Schema をクリックします。

SQL

WITH MANAGED ACCESS キーワードを使用して CREATE SCHEMA ステートメントを実行します。

ウェブインターフェイスまたは SQL を使用して、通常のスキーマを管理アクセススキーマに(またはその逆に)変更できます。

ウェブインターフェイス

Databases Databases tab » <データベース名> » Schemas » <スキーマ名> » Alter a schema をクリックします。

SQL

ENABLE | DISABLE MANAGED ACCESS キーワードで ALTER SCHEMA ステートメントを実行します。

次の表は、通常のアクセススキーマまたは管理アクセススキーマでオブジェクトの権限を管理できるロールを示しています。

ロール

通常のスキーマでオブジェクト権限を付与できます

管理アクセススキーマでオブジェクト権限を付与できます

SYSADMIN

いいえ

いいえ

SECURITYADMIN 以上

はい

はい

データベース所有者

いいえ

いいえ

スキーマ所有者

いいえ

はい

オブジェクト所有者

はい

いいえ

MANAGE GRANTS 権限のある任意のロール

はい

はい

非アカウント管理者の有効化による使用量と請求履歴の監視

Snowflakeは、データストレージ/転送およびウェアハウスの使用/ロードに関する広範なアカウントの使用量と請求情報を提供します。

ウェブインターフェイス

Account Account tab » Billing & Usage をクリックします。

SQL

Query any of the following:

ただし、デフォルトでは、アカウント管理者のみがこの情報にアクセスし、表示できます。アカウント管理者ではないユーザーがこの情報にアクセスし、表示できるようにするために、Snowflakeはグローバルな MONITOR USAGE 権限を提供します。ロールに MONITOR USAGE 権限を付与すると、ロールを付与されたすべてのユーザーがこの履歴/使用量情報にアクセスできます。

さらに、この権限を使用すると、 SHOW DATABASES および SHOW WAREHOUSES コマンドは、他の権限の付与に関係なく、アカウント内のすべてのデータベースとウェアハウスのリストをそれぞれ返します。

例えば、この権限を custom ロールに付与するには、次を実行します。

GRANT MONITOR USAGE ON ACCOUNT TO ROLE custom;