アクセス制御の考慮事項

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

このトピックの内容：

ACCOUNTADMIN ロールの使用

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

デフォルトのアクセス制御階層では、他の管理者ロールの両方がこのロールによって所有されています。

  • セキュリティ管理者（SECURITYADMIN）ロールには、ユーザーとロールを作成および管理する権限が含まれています。

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

注意

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

ユーザーに対する 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 ロールによって管理されます。

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

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

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

簡単な例として、2つのデータベース d1 と d2 に、組織のビジネスアナリストが必要とするデータが含まれているとします。職務上の責任に基づいて、エントリーレベルのアナリストは d1 への読み取り専用アクセスが必要ですが、 d2 へのアクセスは上級アナリストに限定する必要があります。これらのデータベースのセキュリティを設定するための推奨アプローチには、最適な制御のために オブジェクトアクセスロール と ビジネス機能ロール の組み合わせを作成することが含まれます。

注釈

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

この例でアクセスを設定するには、次を実行します。

  1. セキュリティ管理者（SECURITYADMIN ロールがあるユーザー）またはアカウントのCREATE ROLE 権限がある別のロールとして、ロール analyst_basic および analyst_adv を作成します。これらのロールは、組織のビジネス機能に対応し、これらの機能に必要なオブジェクトアクセスのロールのキャッチオールとして機能します。上級アナリストには基本的なアナリスト機能も必要であるため、 analyst_basic ロールを analyst_adv ロールに付与します。

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

    CREATE ROLE analyst_basic;
CREATE ROLE analyst_adv;

GRANT ROLE analyst_basic TO ROLE analyst_adv;
GRANT ROLE analyst_adv TO ROLE sysadmin;

  2. ステップ1と同じロールを使用して、オブジェクトアクセスロール db1_read_only および db2_read_only を作成し、これらのロールを必要とするビジネス機能ロールに付与します。この場合、 analyst_basic ロールに db1_read_only を付与し、 analyst_adv ロールに db2_read_only ロールを付与します。

    CREATE ROLE db1_read_only;
CREATE ROLE db2_read_only;

GRANT ROLE db1_read_only TO ROLE analyst_basic;
GRANT ROLE db2_read_only TO ROLE analyst_adv;

  3. セキュリティ管理者（SECURITYADMIN ロールがあるユーザー）またはアカウントのMANAGE GRANTS 権限がある別のロールとして、 db1_read_only および db2_read_only 読み取り専用アクセスを d1 および d2 データベースにそれぞれ付与します。詳細については、「読み取り専用ロールの作成」をご参照ください。これらのロールは、データオブジェクトにアクセスするための一連の付与を定義します。

    GRANT <privileges> TO ROLE db1_read_only;
GRANT <privileges> TO ROLE db2_read_only;

  4. セキュリティ管理者（SECURITYADMIN ロールがあるユーザー）またはアカウントの MANAGE GRANTS 権限がある別のロールとして、これらの機能を実行するユーザーにビジネス機能ロールを付与します。

    GRANT ROLE analyst_basic TO USER user1;
GRANT ROLE analyst_adv TO USER user2;

下位レベル（ロール階層内）のオブジェクトアクセスロール db1_read_only および db2_read_only に付与された権限は、上位レベルのビジネス機能ロールである analyst_basic および analyst_adv ロールにそれぞれ継承されます。また、 analyst_basic は analyst_adv に付与されるため、 db1_read_only または analyst_basic に付与される権限はすべて analyst_adv に継承されます。

../_images/role-hierarchy-practical.png

analyst_adv ロールを付与されたユーザーは、 db1 と db2 の両方にアクセスできます。ただし、 analyst_basic ロールを付与されたユーザーは db1 にのみアクセスできます。

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

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

オブジェクトセキュリティをさらにロックダウンするには、管理アクセススキーマの使用を検討します。管理アクセススキーマでは、オブジェクトの所有者は付与を決定する能力を失います。スキーマの所有者（スキーマに対する OWNERSHIP 権限があるロール）または 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 をご参照ください。