アクセス制御の考慮事項¶

ACCOUNTADMIN ロールの使用¶

アカウント管理者（つまり、 ACCOUNTADMIN システムロールを持つユーザー）のロールは、システムで最も強力なロールです。アカウントレベルでパラメーターを設定する責任があるのは、このロールのみです。ACCOUNTADMIN ロールを持つユーザーは、Snowflakeの請求およびクレジットデータを表示および管理でき、実行中の SQL ステートメントを停止できます。

ACCOUNTADMINはスーパーユーザーロール ではない ことに注意してください。このロールは、このロール、または ロール階層 の下位のロールがオブジェクトに対して十分な権限を持っている場合にのみ、アカウント内のオブジェクトの表示と管理を許可します。

システムロール階層では、他の管理者ロールはこのロールの子です。

• ユーザー管理者（USERADMIN）のロールには、ユーザーとロールを作成および管理するための権限が含まれます（これらのロールまたはユーザーの所有権が別のロールに譲渡されていないことを前提としています）。

• セキュリティ管理者（つまり、 SECURITYADMIN システムロールを持つユーザー）のロールには、アカウント内のオブジェクトに対する権限を付与、または取り消すためのグローバルMANAGE GRANTS権限が含まれています。USERADMIN ロールは、デフォルトのアクセス制御階層におけるこのロールの子です。

• システム管理者（SYSADMIN）ロールには、ウェアハウス、データベース、およびすべてのデータベースオブジェクト（スキーマ、テーブルなど）を作成する権限が含まれます。

データベースオブジェクトへのアクセス¶

すべてのセキュリティ保護可能なデータベースオブジェクト（TABLE、FUNCTION、FILE FORMAT、STAGE、SEQUENCE など）は、DATABASE 内の SCHEMA オブジェクトに含まれています。その結果、データベースオブジェクトにアクセスするには、特定のデータベースオブジェクトに対する権限に加えて、ユーザーにコンテナデータベースおよびスキーマに対する USAGE 権限を付与する必要があります。

たとえば、 mydb.myschema で mytable が作成されたとします。 mytable をクエリするには、ユーザーに少なくとも次の権限が必要がです。

データベース

mydb 上での USAGE

スキーマ

myschema 上での USAGE

テーブル

mytable 上での SELECT

カスタムロールの管理¶

カスタムロールが最初に作成されると、孤立した状態にあります。ロールに関連付けられたオブジェクト権限を使用するユーザーにロールを割り当てる必要があります。カスタムロールは、カスタムロールによって作成されたオブジェクトを管理するロールにも付与する必要があります。

ロール階層を作成する手順については、「ロール階層の作成」をご参照ください。

オブジェクトのアクセスとビジネス機能の整合¶

ロール階層を活用して、データベースオブジェクトへのアクセスを組織内のビジネス機能と整合させることを検討します。ロール階層では、継承関係を形成するために、ロールが他のロールに付与されます。下位レベルのロールに付与された権限は、上位レベルのロールに継承されます。

データベースオブジェクトへのアクセスを最適に制御するには、オブジェクトに対して異なる権限を持つオブジェクト アクセスロール の組み合わせを作成し、必要に応じて 機能ロール に割り当てます。

• データベースオブジェクトまたはアカウントオブジェクト（ウェアハウスなど）に対して、ロールにアクセスするためのアクセス権限を付与します。

• 機能ロールにアクセスロールを付与して、ロール階層を作成します。これらのロールは、組織のビジネス機能に対応し、これらの機能に必要なアクセスロールのキャッチオールとして動作します。

  必要に応じて、親子関係の上位レベルの機能ロールに、下位レベルの機能ロールを付与します。親ロールは、子ロールの権限を包含する必要があるビジネス機能にマップされます。

  ロール階層のベストプラクティスに従って、ロール階層における最上位の機能ロールをシステム管理者（SYSADMIN）のロールに付与します。システム管理者は、データベースオブジェクトに対する権限をこの階層の任意のロールに付与できます。

例¶

簡単な例として、アカウント内の2つのデータベース fin と hr に、それぞれ給与と従業員のデータが含まれているとします。組織内の会計士とアナリストは、それぞれのビジネス機能を実行するために、これらのデータベース内のオブジェクトに対して異なる権限を必要とします。会計士には fin に対する読み取り/書き込みアクセス権が必要ですが、 hr に対しては読み取り専用アクセスのみが必要な場合があります。人事担当者が、このデータベースのデータを管理しているからです。アナリストには、両方のデータベースへの読み取り専用アクセスが必要となる可能性があります。

既存のデータベースオブジェクトに対する権限は、アクセスロールと機能ロールの次の階層を介して付与されます。

注釈

各データベースに新しいオブジェクトが追加された場合は、オブジェクト型（例: スキーマ、テーブル、ビュー）に基づいて、オブジェクトに対する権限をロールに自動で付与することを検討してください。詳細については、 将来の付与を使用した、付与管理の簡素化 （このトピック内）をご参照ください。

カスタムロール	説明	権限
db_hr_r	hr データベース内のテーブルに対する読み取り専用アクセスを許可するアクセスロール。	データベース hr 上の USAGE。 データベース hr 内にあるすべてのスキーマの USAGE。 データベース hr 内にあるすべてのテーブルの SELECT。
db_fin_r	fin データベース内のテーブルに対する読み取り専用アクセスを許可するアクセスロール。	データベース fin 上の USAGE。 データベース fin 内にあるすべてのスキーマの USAGE。 データベース fin 内にあるすべてのテーブルの SELECT。
db_fin_rw	fin データベース内のテーブルに対する読み取り/書き込みアクセスを許可するアクセスロール。	データベース fin 上の USAGE。 データベース fin 内にあるすべてのスキーマの USAGE。 データベース fin 内にあるすべてのテーブルの SELECT、 INSERT、 UPDATE、 DELETE。
accountant	組織内の会計士の機能ロール。	N/A
analyst	組織内のアナリストの機能ロール。	N/A

次の図は、この例のロール階層を示しています。

この例のアクセス制御を構成するには、次のようにします。

1. この例では、ユーザー管理者（USERADMIN ロールを持つユーザー）またはアカウントの CREATE ROLE 権限がある別のロールとして、アクセスロールおよび機能ロールを作成します。

   CREATE ROLE db_hr_r;
   CREATE ROLE db_fin_r;
   CREATE ROLE db_fin_rw;
   CREATE ROLE accountant;
   CREATE ROLE analyst;
   

   Copy

2. セキュリティ管理者（SECURITYADMIN ロールを持つユーザー）またはアカウントの MANAGE GRANTS 権限がある別のロールとして、アクセスそれぞれに対して必要となる最低限の権限を付与します。

   -- Grant read-only permissions on database HR to db_hr_r role.
   GRANT USAGE ON DATABASE hr TO ROLE db_hr_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE hr TO ROLE db_hr_r;
   GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE db_hr_r;
   
   -- Grant read-only permissions on database FIN to db_fin_r role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_r;
   GRANT SELECT ON ALL TABLES IN DATABASE fin TO ROLE db_fin_r;
   
   -- Grant read-write permissions on database FIN to db_fin_rw role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_rw;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_rw;
   GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN DATABASE fin TO ROLE db_fin_rw;
   

   Copy

3. セキュリティ管理者（SECURITYADMIN ロールを持つユーザー）またはアカウントの MANAGE GRANTS 権限を持つ別のロールとして、 db_fin_rw アクセスロールを accountant 機能ロールに付与し、 db_hr_r db_fin_r アクセスロールを analyst 機能ロールに付与します。

   GRANT ROLE db_fin_rw TO ROLE accountant;
   GRANT ROLE db_hr_r TO ROLE analyst;
   GRANT ROLE db_fin_r TO ROLE analyst;
   

   Copy

4. セキュリティ管理者（SECURITYADMIN ロールを持つユーザー）またはアカウントの MANAGE GRANTS 権限がある別のロールとして、 analyst ロールおよび accountant ロールの両方をシステム管理者（SYSADMIN）ロールに付与します。

   GRANT ROLE accountant,analyst TO ROLE sysadmin;
   

   Copy

5. セキュリティ管理者（SECURITYADMIN ロールを持つユーザー）またはアカウントの MANAGE GRANTS 権限がある別のロールとして、組織内でこれらの機能を実行するユーザーにビジネス機能ロールを付与します。この例では、 analyst 機能ロールがユーザー user1 に付与され、 accountant 機能ロールがユーザー user2 に付与されています。

   GRANT ROLE accountant TO USER user1;
   GRANT ROLE analyst TO USER user2;
   

   Copy

データベースロールを使用したデータベースオブジェクトへのアクセスの管理¶

データベースロールは、スコープを除いて、アカウントレベルで作成された従来の ロール （つまり、カスタム アカウントロール）と基本的に同じです。データベース内のオブジェクトに対する SQL アクションを許可するために、 同じデータベース内 のデータベースロールに権限を付与できます。

データベースロールは、次のユースケースを満たすことを目的としています。

管理のしやすさ

データベースの所有者は、独自のデータベース内にあるセキュリティ保護が可能なオブジェクトへのアクセスを個別に管理できます。データベースの所有者は、次のアクションを実行できます。

• データベースロールを作成し、管理する。

• データベースロールに権限を付与する。

  データベースロールに付与されるオブジェクトに対する権限は、ロールが存在するデータベースに含まれるオブジェクトに対してスコープを設定する必要があります。あるデータベースのオブジェクト（例: テーブルまたはビュー）に対する権限は、別のデータベースにあるデータベースロールには付与できません。

  OWNERSHIP を含め、 任意の 権限を、データベース内のオブジェクトに対するデータベースロールに付与できます。データベース自体に対する OWNERSHIP 権限を保持できるのは、アカウントロールのみであることに注意してください。

• ロール階層と権限の継承 を作成または拡張します。データベースロールを同じデータベース内の他のデータベースロールに付与してから、データベース内の最高レベルのデータベースロールをアカウントロールに付与します。詳細については、 ロール階層と権限の継承 をご参照ください。

  データベースロールをアカウントロールに付与すると、データベースロールを含むデータベースに対する USAGE 権限がそのアカウントロールに暗黙的に付与されることに注意してください。データベースに対する USAGE 権限を明示的に付与する必要はありません。

データ共有

Snowflakeの Secure Data Sharing のデータプロバイダーは、データベース内に複数のデータベースロールを作成して共有し、データベース内のオブジェクトのサブセットに対する権限を各データベースロールに付与することで、共有内のセキュリティ保護可能なオブジェクトをセグメント化できます。データベースロールを含む共有からデータベースを作成した後、データコンシューマーは、各共有データベースロールを自分のアカウントにある1つ以上のアカウントレベルのロールに付与します。

データベースロールがない場合、データコンシューマーアカウントのアカウント管理者は、単一の権限 IMPORTED PRIVILEGES をロールに付与して、ユーザーが共有内の すべての データベースおよびデータベースオブジェクト（テーブル、セキュアビューなど）にアクセスできるようにします。データコンシューマーアカウント内のさまざまなユーザーグループを、共有オブジェクトのサブセットにアクセスできるようにするオプションはありません。このオールオアナッシングアプローチでは、データプロバイダーが複数の共有を作成して、同じデータベース内のさまざまなオブジェクトへのアクセス権を付与する必要があります。

データベースロールは、セッションで直接 アクティブ化 できないことに注意してください。セッションでアクティブ化できるアカウントロールにデータベースロールを付与します。

管理アクセススキーマを使用した付与管理の一元化¶

データベース内の通常の（管理されていない）スキーマでは、オブジェクト所有者（1つ以上のオブジェクトに対する OWNERSHIP 権限があるロール）は、これらのオブジェクトへのアクセスを他のロールに付与できます。これは、オブジェクト付与を管理する機能をこれらのロールに追加付与するオプションで行います。

オブジェクトセキュリティをさらにロックダウンするには、管理アクセススキーマの使用を検討します。管理アクセススキーマでは、オブジェクトの所有者は付与を決定する能力を失います。スキーマの所有者（つまり、スキーマに対する OWNERSHIP 権限があるロール）または MANAGE GRANTS 権限があるロールのみが、スキーマ内のオブジェクトに対する権限を付与できます（将来の付与 を含みます）。

MANAGE GRANTS グローバル権限を保持するロールは、現在の（付与者）ロールに追加の権限を付与できることに注意してください。

管理アクセススキーマの詳細については、 管理アクセススキーマの作成 をご参照ください。

将来の付与を使用した付与管理の簡素化¶

将来の付与により、指定されたスキーマ内の特定の型のオブジェクト（テーブルまたはビューなど）に対する権限の初期セットを定義できます。新しいオブジェクトが作成されると、定義された権限がロールに自動的に付与され、付与管理が簡素化されます。

次のシナリオを考えてみましょう。特定のロールに、スキーマで作成されたすべての新しいテーブルに対する SELECT 権限が付与されます。後日、このロールから権限を取り消し、代わりに別のロールに付与する決定が下されます。新しいテーブルに ON FUTURE キーワードを使用し、既存のテーブルに ALL キーワードを使用すると、次のように、新しいテーブルと既存のテーブルの権限を付与および取り消すために SQL ステートメントはほとんど必要ありません。例：

-- Grant the SELECT privilege on all new (i.e. future) tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1;

-- / Create tables in the schema /

-- Grant the SELECT privilege on all new tables in a schema to role R2
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r2;

-- Grant the SELECT privilege on all existing tables in a schema to role R2
GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO ROLE r2;

-- Revoke the SELECT privilege on all new tables in a schema (i.e. future grant) from role R1
REVOKE SELECT ON FUTURE TABLES IN SCHEMA s1 FROM ROLE r1;

-- Revoke the SELECT privilege on all existing tables in a schema from role R1
REVOKE SELECT ON ALL TABLES IN SCHEMA s1 FROM ROLE r1;

将来の付与の詳細については、 オブジェクトに対する将来の付与の割り当て をご参照ください。

クエリ結果の表示¶

ユーザーは、別のユーザーが実行したクエリからの結果セットを表示できません。この動作は意図的なものです。セキュリティ上の理由から、クエリを実行したユーザーのみがクエリ結果にアクセスできます。

複製オブジェクトと付与された権限について¶

データベース、スキーマ、またはテーブルを複製すると、ソースオブジェクトのコピーが作成されます。複製オブジェクトには、複製が作成されたときにソースオブジェクトに存在するデータのスナップショットが含まれます。

複製オブジェクトは、Snowflakeでは新しいオブジェクトと見なされます。ソースオブジェクトに付与された権限は、複製オブジェクトには譲渡されません。ただし、複製されたコンテナオブジェクト（データベースまたはスキーマ）は、ソースオブジェクトに含まれるオブジェクトに対して付与された権限を保持します。例えば、複製スキーマは、テーブル、ビュー、UDFs、およびソーススキーマ内の他のオブジェクトに付与された権限を保持します。

複製の詳細については、 クローニングに関する考慮事項 および CREATE <オブジェクト> ... CLONE をご参照ください。