アクセス制御の概要¶

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

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

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

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

• ユーザーベースのアクセス制御 (UBAC): アクセス権限をユーザーに直接割り当てます。アクセス制御では、 USE SECONDARY ROLE が ALL にセットされている場合のみ、ユーザーに直接割り当てられた権限を考慮します。

二次的ロールの詳細情報については、 USE SECONDARY ROLES および プライマリ・ロールとセカンダリ・ロールによる権限付与 を参照してください。

Snowflakeのアクセス制御を理解する上でキーとなる概念には、次のようなものがあります。

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

• ロール: 権限を付与できるエンティティ。

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

• ユーザー: Snowflake が認識するユーザー ID で、個人またはサービスに関連付けられます。ユーザーはまた、権限を付与できるエンティティでもあります。

Snowflakeでは、ロールまたはユーザーに割り当てられた権限によって、セキュリティで保護されたオブジェクトにアクセスできます。ロールは、ユーザーまたは他のロールに割り当てることができます。ロールに別のロールを付与すると、 ロール階層と権限の継承 で説明するロール階層が作成されます。通常、Snowflakeではセキュリティで保護されたオブジェクトへのアクセスを管理するために RBAC を使用します。

次の図は、 DAC、 RBAC、 UBAC が、さまざまなセキュリティ可能なオブジェクトに適切な権限を割り当てる方法を示しています。この例では、ロール 1 はオブジェクト 1 とオブジェクト 2 の両方で OWNERSHIP 権限を持っています。つまり、ロール1は両方のオブジェクトを所有しています。これは DAC を示しています。

オブジェクト 1 の権限をロール 2 に付与し、それをユーザー 1 とユーザー 2 に付与することができます。言い換えると、ユーザー1とユーザー2は、どちらもロール2が割り当てられているため、これらの権限によって制限されたオブジェクト1にアクセスすることができます。この部分は RBAC を示しています。

オブジェクト 2 の権限は、ユーザー 3 とユーザー 4 に直接付与することができます。この図では、 UBAC を使用して Snowflake アクセス制御フレームワークを拡張し、大幅な制御と柔軟性の両方を提供する方法を示しています。

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

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

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

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

オブジェクトに対して SQL アクションを実行する機能は、ユーザーセッションで アクティブなロール に付与された権限によって定義されます。たとえば、セッションのアクティブロールに、特定の Snowflake データベーススキーマの CREATE、 USAGE、 SELECT、 WRITE 権限が付与されている場合、そのスキーマでウェアハウスの作成、含まれるテーブルのリスト、テーブルへのデータ追加を行うことができます。

ロール¶

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

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

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

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

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

権限¶

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

権限は以下のコマンドで管理します。

• GRANT <権限> ... TO ROLE

• REVOKE <権限> ... FROM ROLE

• GRANT <権限> ... TO USER

• REVOKE <権限> ... FROM USER

通常の（管理されていない）スキーマでは、これらのコマンドの使用は、オブジェクトを所有するロール（オブジェクトに対して 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 が使用されます。

セッションの現在のロールを表示するには、 CURRENT_ROLE 関数を実行してください。

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

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

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

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

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

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