アクセス制御の概要

アクセス制御権限により、Snowflakeの特定のオブジェクトにアクセスして操作を実行できるユーザーが決まります。

このトピックの内容:

アクセス制御フレームワーク

アクセス制御に対するSnowflakeのアプローチは、次の両方のモデルの側面を組み合わせたものです。

  • 任意アクセス制御(DAC): 各オブジェクトに所有者がおり、所有者はそのオブジェクトへのアクセスを許可できます。

  • ロールベースのアクセス制御(RBAC): アクセス権限がロールに割り当てられ、ロールはユーザーに割り当てられます。

Snowflakeのアクセス制御を理解するための重要な概念は次のとおりです。

  • セキュリティ保護可能なオブジェクト: アクセスを付与できるエンティティ。付与されない限り、アクセスは拒否されます。

  • ロール: 権限を付与できるエンティティ。次に、ロールがユーザーに割り当てられます。ロールを他のロールに割り当て、ロール階層を作成することもできます。

  • 権限: オブジェクトへの定義されたレベルのアクセス。複数の個別の権限を使用して、付与されるアクセスの粒度を制御できます。

  • ユーザー: Snowflakeによって認識されるユーザーID(個人またはプログラムに関連付けられているかどうか)。

Snowflakeモデルでは、セキュリティ保護可能なオブジェクトへのアクセスは、ロールに割り当てられた権限を介して許可され、その権限は他のロールまたはユーザーに割り当てられます。さらに、各セキュリティ保護可能なオブジェクトには、他のロールへのアクセスを付与できる所有者がいます。このモデルは、各ユーザーまたはユーザーのグループに権利と権限が割り当てられるユーザーベースのアクセス制御モデルとは異なります。Snowflakeモデルは、制御と柔軟性の両方を大幅に提供するように設計されています。

Access control relationships

セキュリティ保護可能なオブジェクト

すべてのセキュリティ保護可能なオブジェクトは、コンテナの階層内の論理コンテナ内に存在します。一番上のコンテナは顧客アカウントで、その中に USER、ROLE、WAREHOUSE、および DATABASEオブジェクトが存在します。他のすべてのセキュリティ保護可能なオブジェクト(TABLE、FUNCTION、FILE FORMAT、STAGE、SEQUENCE など)は、DATABASE 内の SCHEMA オブジェクトに含まれています。このオブジェクトとコンテナの階層を以下に示します。

Hierarchy of securable database objects

すべてのセキュリティ保護可能なオブジェクトは、単一のロールによって所有されます。通常、このロールはオブジェクトの作成に使用されます。このロールがユーザーに割り当てられると、ユーザーは実質的にセキュリティ保護可能なオブジェクトに対する制御を共有します。所有ロールには、デフォルトでオブジェクトに対するすべての権限があります。これには、オブジェクトに対する権限を他のロールに付与する、または取り消す機能も含まれます。さらに、所有権をあるロールから別のロールに移すことができます。

オブジェクトへのアクセスは、ロールに付与された権限によって定義されます。以下は、Snowflakeのさまざまなオブジェクトに対する権限の例です。

  • ウェアハウスを作成する機能。

  • スキーマに含まれるテーブルをリストする機能。

  • テーブルにデータを追加する機能。

ロール

ロールは、セキュリティ保護可能なオブジェクトに対する権限の付与や取り消しができるエンティティです。ロールはユーザーに割り当てられ、ユーザーが組織内のビジネス機能に必要なアクションを実行できるようにします。ユーザーには複数のロールを割り当てることができます。これにより、ユーザーはロールを切り替えて(現在のSnowflakeセッションでアクティブなロールを選択する)、個別の権限セットを使用して異なるアクションを実行できます。

ロールを他のロールに付与して、ロールの階層を作成することもできます。ロールに関連付けられた権限は、階層内でそのロールより上のすべてのロールに継承されます。

Snowflakeアカウントには、少数のシステム定義のロールがあります。適切なアクセスのあるユーザーは、システム定義のロールを変更でき、カスタムロールを作成することもできます。

システム定義のロール

ACCOUNTADMIN

(別名アカウント管理者)

SYSADMIN および SECURITYADMIN システム定義のロールをカプセル化するロール。これはシステムの最上位のロールであり、アカウント内の限られた/制御された数のユーザーにのみ付与する必要があります。

SECURITYADMIN

(別名:セキュリティ管理者)

オブジェクトの付与をグローバルに管理し、ユーザーとロールを作成、モニター、管理できるロール。より具体的には、このロールは、

  • MANAGE GRANTS セキュリティ権限が付与されており、付与の取り消しを含め、あらゆる付与を変更できます。

  • システムロール階層を介して USERADMIN ロールの権限を継承します(例: USERADMIN ロールを SECURITYADMIN に付与)。

USERADMIN

(別名:ユーザーおよびロール管理者)

ユーザーとロールの管理のみに専用のロール。より具体的には、このロールは、

  • CREATE USER および CREATE ROLE のセキュリティ権限が付与されています。

  • アカウントで、ユーザーとロールを作成および管理できます(これらのロールまたはユーザーの所有権が、別のロールに転送されていないと想定)。

SYSADMIN

(別名システム管理者)

アカウントでウェアハウスとデータベース(およびその他のオブジェクト)を作成する権限を持つロール。

推奨 されているように、最終的にすべてのカスタムロールを SYSADMIN ロールに割り当てるロール階層を作成する場合、このロールには、ウェアハウス、データベース、およびその他のオブジェクトに対する権限を他のロールに付与する機能もあります。

PUBLIC

アカウント内のすべてのユーザーおよびすべてのロールに自動的に付与される疑似ロール。PUBLIC ロールは、他のロールと同様にセキュリティ保護可能なオブジェクトを所有できます。ただし、ロールが所有するオブジェクトは、定義上、アカウント内の他のすべてのユーザーとロールが使用できます。

通常、このロールは、明示的なアクセス制御が不要で、すべてのユーザーがアクセスに関して平等であると見なされる場合に使用されます。

カスタムロール

カスタムロール(システム定義のロール以外のロール)は、SECURITYADMIN ロールおよび CREATE ROLE 権限が付与されたロールによって作成できます。デフォルトでは、新しく作成されたロールはどのユーザーにも割り当てられず、他のロールにも付与されません。

システム内のオブジェクトの所有者として機能するロールを作成する場合は、最上位のカスタムロールをシステムロール SYSADMIN に割り当てて、カスタムロールの階層を作成することをお勧めします。このロール構造により、システム管理者は、ウェアハウスやデータベースオブジェクトといったアカウント内のすべてのオブジェクトを管理する一方で、ユーザーとロールの管理を SECURITYADMIN または ACCOUNTADMIN ロールに制限できます。

逆に、カスタムロールがロールの階層を介して SYSADMIN に割り当てられていない場合、システム管理者はロールが所有するオブジェクトを管理できません。MANAGE GRANTS 権限を付与されたロール(通常はSECURITYADMIN ロールのみ)のみがオブジェクトを表示し、アクセス付与を変更できます。

権限

セキュリティ保護可能なオブジェクトごとに、そのオブジェクトに付与できる権限のセットがあります。既存のオブジェクトの場合、個々のオブジェクトに権限を付与する必要があります(例: mytable テーブルの SELECT 権限)。付与管理を簡素化するために、 将来の付与 では、スキーマで作成されたオブジェクトの初期権限セットを定義できます。すなわち、 myschema スキーマで作成されたすべての 新規 テーブルに対する SELECT 権限です。

権限は、 GRANT および REVOKE コマンドを使用して管理されます。

  • 通常の(つまり、管理されていない)スキーマでは、これらのコマンドの使用は、オブジェクトを所有するロール(つまり、オブジェクトに対する OWNERSHIP 権限がある)、またはオブジェクトに対する MANAGE GRANTS グローバル権限があるロール(通常は SECURITYADMIN ロール)に制限されます。

  • 管理アクセススキーマでは、オブジェクトの所有者は付与決定の権限がありません。スキーマの所有者または MANAGE GRANTS 権限のあるロールのみが、将来の付与を含むスキーマ内のオブジェクトに対する権限を付与し、権限管理を一元化します。

詳細については、『アクセス制御権限 』をご参照ください。

ロール階層と権限の継承

次の図は、システム定義のロールの階層と、追加のユーザー定義のカスタムロールの推奨構造を示しています。

../_images/system-role-hierarchy.png

ロール階層と権限の継承のより具体的な例については、次のシナリオを検討してください。

  • ロール3がロール2に付与されました。

  • ロール2がロール1に付与されました。

  • ユーザー1にロール1が付与されました。

Privilege inheritance for granted roles

このシナリオでは:

  • ロール2は権限Cを継承します。

  • ロール1は権限BおよびCを継承します。

  • ユーザー1には3つの権限がすべてあります。

施行モデル

すべてのアクティブなユーザーセッションには「現在のロール」があります。セッションが開始されると(例えば、ユーザーが JDBC/ODBC を介して接続するか、Snowflake ウェブインターフェイスにログインする)、現在のロールは次に基づいて決定されます。

  1. 接続の一部としてロールが指定され、そのロールが接続ユーザーに既に付与されているロールである場合、指定されたロールが現在のロールになります。

  2. ロールが指定されておらず、接続しているユーザーに既定のロールが設定されている場合、そのロールが現在のロールになります。

  3. ロールが指定されておらず、接続しているユーザーに既定のロールが設定されていない場合、システムロール PUBLIC が使用されます。

セッションの過程で、ユーザーは USE ROLE コマンドを使用して現在のロールを変更できます。ロールに他のロールが付与されている場合、ユーザーのセッションには、現在のロールの権限と、ロール階層内の現在のロールに付与されているロールのすべての権限の合計に等しい権限があります。

ユーザーがオブジェクトに対してアクションを実行しようとすると、Snowflakeは、ユーザーのセッションで使用可能な権限と、そのアクションに対してオブジェクトに必要な権限を比較します。オブジェクトに対して必要な権限がセッションにある場合、アクションは許可されます。

注釈

Snowflakeには、認証チェックをバイパスできる「スーパーユーザー」または「スーパーロール」という概念はありません。すべてのアクセスには、適切なアクセス権限が必要です。