アクセス制御の概要¶

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

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

• 任意アクセス制御（DAC）: 各オブジェクトには所有者があり、所有者はそのオブジェクトへのアクセス権を付与できます。

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

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

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

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

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

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

Snowflakeモデルでは、セキュリティ保護可能なオブジェクトへのアクセスは、ロールに割り当てられた権限を介して許可され、その権限はユーザーまたはその他のロールに割り当てられます。あるロールを別のロールに付与すると、ロール階層が作成されます。これについては、 ロール階層と権限の継承 セクション（このトピック内）で説明します。

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

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

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

オブジェクトを 所有 するということは、 ロール がオブジェクトに OWNERSHIP 権限 を持っていることを意味します。セキュリティ保護可能な各オブジェクトは、単一のロールによって所有されます。通常はデフォルトで、このロールがオブジェクトの作成に使用されます。このロールがユーザーに割り当てられると、ユーザーはオブジェクトに対する制御を実質的に共有します。 GRANT OWNERSHIP コマンドを使用すると、オブジェクトの所有権をあるロールから別のロール（データベースロールを含む）に譲渡できます。このコマンドは、各コンテナ内のセキュリティ保護が可能なオブジェクトも指定します。

通常のスキーマでは、所有者のロールにはデフォルトでオブジェクトに対するすべての権限があります。これには、オブジェクトに対する権限を他のロールに付与する、または取り消す機能も含まれます。さらに、所有権をあるロールから別のロールに移すことができます。しかし、 管理アクセススキーマ では、オブジェクトの所有者は付与を決定する能力を失います。スキーマの所有者（つまり、スキーマに対する OWNERSHIP 権限があるロール）または MANAGE GRANTS 権限があるロールのみが、スキーマ内のオブジェクトに対する権限を付与できます。

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

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

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

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

ロール¶

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

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

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

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

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

権限¶

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

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

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

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

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

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

ロール階層と権限の継承¶

次の図は、システム定義ロールの階層と、追加のユーザー定義アカウントロールおよびデータベースロールの推奨構造を示しています。サンプル階層の最上位のデータベースロールは、カスタム（つまり、ユーザー定義）アカウントロールに付与されます。次に、このロールは、システム定義の SYSADMIN ロールがカスタムアカウントロールとデータベースロールの権限を継承できるようにする推奨構造の別のカスタムロールに付与されます。

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

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

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

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

このシナリオでは、

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

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

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

施行モデル: プライマリロールおよびセカンダリロール¶

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

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

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

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

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

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

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

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

使用するために1つ以上の権限を必要とするオブジェクトを作成する場合は、それらの権限の付与を検索するときに、プライマリロールと、それが直接的または間接的に継承するロールのみが考慮されます。

1つ以上の権限を必要とするその他のステートメント（例: テーブルのクエリには、データベースとスキーマの USAGE 権限を持つテーブルに対する SELECT 権限が必要）の場合、プライマリロール、セカンダリロール、およびその他の継承されたロールは、それらの権限の付与を検索するときに考慮されます。