アクセス制御の概要

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

このトピックの内容:

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

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

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

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

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

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

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

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

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

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

Access control relationships

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

すべてのセキュリティ保護可能なオブジェクトは、コンテナーの階層内の論理コンテナー内に存在します。最上位のコンテナーは、顧客の組織です。テーブル、ビュー、関数、ステージなどのセキュリティ保護可能なオブジェクトはスキーマオブジェクトに含まれ、スキーマオブジェクトはデータベースに含まれます。Snowflakeアカウントのすべてのデータベースは、アカウントオブジェクトに含まれています。このオブジェクトとコンテナの階層を以下に示します。

Hierarchy of securable database objects

オブジェクトを 所有 するということは、 ロール がオブジェクトに OWNERSHIP 権限 を持っていることを意味します。セキュリティ保護可能な各オブジェクトは、単一のロールによって所有されます。通常はデフォルトで、このロールがオブジェクトの作成に使用されます。このロールがユーザーに割り当てられると、ユーザーはオブジェクトに対する制御を実質的に共有します。通常のスキーマでは、所有者のロールにはデフォルトでオブジェクトに対するすべての権限があります。これには、オブジェクトに対する権限を他のロールに付与する、または取り消す機能も含まれます。さらに、所有権をあるロールから別のロールに移すことができます。しかし、 管理アクセススキーマ では、オブジェクトの所有者は付与を決定する能力を失います。スキーマの所有者(つまり、スキーマに対する OWNERSHIP 権限があるロール)または MANAGE GRANTS 権限があるロールのみが、スキーマ内のオブジェクトに対する権限を付与できます。

オブジェクトに対して SQL アクションを実行する機能は、ユーザーセッションでアクティブなロールに付与された権限によって定義されます。以下は、Snowflakeにあるさまざまなオブジェクトで使用できる SQL アクションの例です。

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

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

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

ロール

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

Snowflakeアカウントには、少数のシステム定義のロールがあります。システム定義のロールはドロップできません。さらに、Snowflakeによってこれらのロールに付与された権限は、取り消すことができません。

必要な権限を持つロールを付与されたユーザーは、特定のビジネスおよびセキュリティのニーズを満たすカスタムロールを作成できます。

ロールを他のロールに付与して、ロールの階層を作成することもできます。ロールに関連付けられた権限は、階層内でそのロールより上のロールすべてに継承されます。ロールの階層と権限の継承の詳細については、 ロールの階層と権限の継承 (このトピック内)をご参照ください。

システム定義のロールには追加の権限を付与できますが、非推奨です。システム定義のロールは、アカウント管理に関連する権限で作成されます。ベストプラクティスとして、アカウント管理権限とエンティティ固有の権限を同じロールに混在させることはお勧めしません。追加の権限が必要な場合、Snowflakeは、カスタムロールに追加の権限を付与し、システム定義のロールにカスタムロールを割り当てることをお勧めします。

システム定義のロール

ORGADMIN

(別名: 組織管理者)

組織レベルで運用を管理するロール。より具体的には、このロールは、

ACCOUNTADMIN

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

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

SECURITYADMIN

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

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

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

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

USERADMIN

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

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

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

  • アカウントにユーザーとロールを作成できます。

    このロールは、所有するユーザーとロールを管理することもできます。オブジェクトのプロパティを変更できるのは、オブジェクト(つまり、ユーザーまたはロール)に対する OWNERSHIP 権限を持つロールまたはそれ以上のロールのみです。

SYSADMIN

(別名システム管理者)

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

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

PUBLIC

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

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

カスタムロール

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

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

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

カスタムロールを作成する手順については、 カスタムロールの作成 をご参照ください。

権限

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

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

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

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

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

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

ロール階層と権限の継承

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

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

注釈

ORGADMIN は、組織レベルで運用を管理する別個のシステムロールです。このロールは、システムロールの階層には含まれていません。

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

  • ロール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 が使用されます。

さらに、 セカンダリ ロールのセットをユーザーセッションでアクティブ化できます。ユーザーは、プライマリロールとセカンダリロールに付与された集約権限を使用して、セッション内のオブジェクトに対して SQL アクションを実行できます。ロールは、セッションでアクティブ化する前にユーザーに付与する必要があります。セッションには1度に1つのアクティブなプライマリロールが必要ですが、同時に任意の数のセカンダリロールをアクティブ化できます。

CREATE <オブジェクト> ステートメントを実行する認証は、プライマリロールからのみ取得されます。オブジェクトが作成されると、その所有権は現在アクティブなプライマリロールに設定されます。ただし、その他の SQL アクションの場合は、アクティブなプライマリまたはセカンダリロールに付与された権限を使用してアクションを承認できます。たとえば、セカンダリロール階層内のいずれかのロールがオブジェクトを所有している場合(つまり、オブジェクトに対する OWNERSHIP 権限を持っている場合)、セカンダリロールは、オブジェクトに対する DDL アクションの実行を承認します。プライマリロールとすべてのセカンダリロールの両方が、ロール階層の下位にあるロールから権限を継承します。

Primary and Secondary Role Operations

セキュリティモデルに多数のロールが含まれ、それぞれが認証を介して細かく許可されている組織の場合は、セカンダリロールを使用するとロール管理が簡素化されます。ユーザーに付与されたすべてのロールは、セッションでアクティブ化できます。セカンダリロールは、データベース間の結合など、各データベース内のオブジェクトにアクセスするためのアクセス権限を持つロールの親ロールを作成する必要がある SQL 操作に特に役立ちます。

セッションの過程で、ユーザーは USE ROLE または USE SECONDARY ROLES コマンドを使用して現在のプライマリまたはセカンダリロールを変更できます。ユーザーは、 CURRENT_SECONDARY_ROLES 関数を使用して、現在のセッションに対するすべてのアクティブなセカンダリロールを表示できます。

ユーザーがオブジェクトを作成しようとすると、Snowflakeは、ユーザーのセッションで現在のロールに使用できる権限をオブジェクトの作成に必要な権限と比較します。ユーザーが試行したその他の SQL アクションの場合、Snowflakeは、現在のプライマリ および セカンダリロールで使用可能な権限をターゲットオブジェクトでアクションを実行するために必要な権限と比較します。オブジェクトに対して必要な権限がセッションにある場合、アクションは許可されます。

注釈

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