アクセス制御の考慮事項

このトピックでは、Snowflakeアカウントおよびアカウント内に格納されているデータへの安全なアクセスを管理するためのベストプラクティスと重要な考慮事項を提供します。特に、ユーザーのロールに基づいてオブジェクトへのアクセスを制限するロールベースのアクセス制御を構成するための一般的なガイダンスを提供します。

このトピックの内容：

ACCOUNTADMIN ロールの使用

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

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

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

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

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

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

注意

デフォルトでは、アカウントがプロビジョニングされると、最初のユーザーに ACCOUNTADMIN ロールが割り当てられます。このユーザーは、USERADMINロールを割り当てられた1人以上の追加ユーザーを作成する必要があります。残りのすべてのユーザーは、USERADMINロール、またはグローバルのCREATE USER権限が付与されている別のロールのユーザーにより作成する必要があります。

ユーザーに対する ACCOUNTADMIN ロール割り当ての制御

ACCOUNTADMIN のロールをユーザーに割り当てる際には、次の点に注意することを 強く お勧めします。

  • このロールは、組織内の選択された/限られた人数にのみ割り当ててください。

  • ACCOUNTADMIN ロールを割り当てられたすべてのユーザーは、ログインに多要素認証（MFA）を使用する必要もあります（詳細については、 アクセス制御の構成 をご参照ください）。

  • このロールを少なくとも2人のユーザーに割り当てます。ACCOUNTADMIN ロールがあるユーザーのパスワードを忘れたり、紛失したりした場合は、厳格なセキュリティ手順に従ってください。これらの手順には、最長2営業日かかる場合があります。ACCOUNTADMIN ロールを複数のユーザーに割り当てると、ユーザーは互いのパスワードをリセットできるため、これらの手順を実行する必要がなくなります。

ちなみに

また、実際の人物のメールアドレスを ACCOUNTADMIN ユーザーに関連付けると、Snowflakeサポートが緊急の状況で誰に連絡すればよいかがわかります。

ACCOUNTADMIN ロールを使ってオブジェクトを作成しない

ACCOUNTADMIN ロールは、システムで初期セットアップタスクを実行し、アカウントレベルのオブジェクトとタスクを日常的に管理することを意図したものです。そのため、これらのオブジェクトに最高レベルの安全なアクセスを持たせる絶対的な必要性がない限り、アカウントでオブジェクトを作成するために使用しないでください。ACCOUNTADMIN ロールでオブジェクトを作成し、ユーザーにこれらのオブジェクトへのアクセスを許可する場合は、これらのユーザーのロールにオブジェクトに対する権限を明示的に付与する必要があります。

代わりに、組織のビジネス機能に合わせてロールの階層を作成し、最終的にこれらのロールを SYSADMIN ロールに割り当てることをお勧めします。詳細については、このトピックの ビジネス関数とオブジェクトアクセスの整合 をご参照ください。

ちなみに

アカウント管理者がうっかり ACCOUNTADMIN ロールを使用してオブジェクトを作成するのを避けるには、これらのユーザーに追加のロールを割り当て、これらのロールの1つをデフォルトとして指定します（ACCOUNTADMIN をシステムのユーザーの既定のロールにしないでください）。

これにより、ACCOUNTADMIN ロールを使用してオブジェクトを作成することを防ぐことはできませんが、ログインするたびに明示的にロールを ACCOUNTADMIN に明示的に変更するよう強制します。これは、アカウント管理者のタスクを実行する必要がある場合に、システム内のロールの目的/機能を認識し、特定のタスクを実行するために適切なロールに変更するのに役立ちます。

自動スクリプト用に ACCOUNTADMIN ロールを使用しない

自動スクリプトには ACCOUNTADMIN 以外のロールを使用することをお勧めします。推奨されているように、SYSADMIN ロールの下にロール階層を作成する場合、SYSADMIN ロールまたは階層内の下位のロールを使用して、すべてのウェアハウスおよびデータベースオブジェクト操作を実行できます。発生する唯一の制限は、ユーザーまたはロールの作成または変更です。これらの操作は、SECURITYADMIN ロールまたは十分なオブジェクト権限がある別のロールがあるユーザーが実行する必要があります。

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

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

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

データベース

mydb 上での USAGE

スキーマ

myschema 上での USAGE

テーブル

mytable 上での SELECT

カスタムロールの管理

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

重要

デフォルトでは、ACCOUNTADMIN ロールでさえ、カスタムロールによって作成されたオブジェクトの変更やドロップはできません。カスタムロールは、ACCOUNTADMIN ロールに直接付与するか、できれば、SYSADMIN ロールを親とする階層内の別のロールに付与する必要があります。SYSADMIN ロールは ACCOUNTADMIN ロールによって管理されます。

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

ビジネス関数とオブジェクトアクセスの整合

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

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

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

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

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

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

注釈

Snowflakeのオブジェクトアクセスロールと機能ロールの間に技術的な相違はありません。相違は、それらを論理的に使用して、権限のセットを集めてユーザーのグループに割り当てる方法にあります。

例

簡単な例として、アカウント内の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

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

Example: Hierarchy of access and functional roles

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

  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;

  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;

  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;

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

    GRANT ROLE accountant,analyst TO ROLE sysadmin;

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

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

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

データベース内の通常の（管理されていない）スキーマでは、オブジェクト所有者（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アクセス制御モデルに接続されて いません。ACCOUNTADMIN ロールを持つユーザーでさえ、別のユーザーが実行したクエリの結果を表示できません。

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

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

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

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

⇧
最上部に戻る