アクセス制御の概要

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

このトピックの内容:

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

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

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

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

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

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

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

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

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

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

Access control relationships

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

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

Hierarchy of securable database objects

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

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

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

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

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

ロール

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

ロールを他のロールに付与して、ロールの階層を作成することもできます。適切なアクセス権を持つユーザーは、カスタムロールを作成できます。ロールに関連付けられた権限は、階層内でそのロールより上のロールすべてに継承されます。

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

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

システム定義のロール

ACCOUNTADMIN

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

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

SECURITYADMIN

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

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

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

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

USERADMIN

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

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

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

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

    このロールは、所有するユーザーとロールを管理することもできます。オブジェクトのプロパティを変更できるのは、オブジェクト(つまり、ユーザーまたはロール)に対するOWNERSHIP権限を持つロールまたはそれ以上のロールのみです。さらに、ロールは、所有するユーザーまたはロールを変更するために、それぞれグローバル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 が使用されます。

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

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

Primary and Secondary Role Operations

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

セッションの過程で、ユーザーは USE ROLE または USE SECONDARY ROLES コマンドを使用して現在のプライマリまたはセカンダリロールを変更できます。

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

注釈

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