アクセス制御の概要

このトピックでは、Snowflakeの主なアクセス制御トピックに関する情報を提供します。

このトピックの内容:

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

アクセス制御に対する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によってこれらのロールに付与された権限は、取り消すことができません。

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

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

注釈

ロール所有者 (ロールに対して OWNERSHIP の権限を持つロール) は、所有ロールの権限を継承 しません。権限の継承は、ロール階層内のみで可能です。

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

Tip

組織のユーザーグループを使用して、組織内のアカウント間で一貫したロールを実装できます。詳細については、 組織ユーザー をご参照ください。

ロールのタイプ

以下のロールタイプは、管理者がアカウント内のオブジェクトへのアクセスを承認および制限できるようにする、そのスコープが異なります。

注釈

製品ドキュメントに記載されている場合を除き、 ロール という用語はいずれかの型を指します。

アカウントロール:

アカウント内の 任意の オブジェクトに対して SQL アクションを許可するには、オブジェクトに対する権限をアカウントロールに付与します。

データベースロール:

SQL アクションを1つのデータベースとデータベース内の任意のオブジェクトに制限するには、オブジェクトに対する権限を 同じデータベース内 のデータベースロールに付与します。

データベースロールは、セッションで直接 アクティブ化 できないことに注意してください。セッションでアクティブ化できるアカウントロールにデータベースロールを付与します。

データベースロールの詳細については、次をご参照ください。

インスタンスロール:

クラス のインスタンスへのアクセスを許可するには、アカウントロールにインスタンスロールを付与します。

クラスは、各ロールに付与される権限が異なる1つ以上のクラスロールを持つことができます。クラスのインスタンスが作成されると、インスタンスロールをアカウントロールに付与して、インスタンスメソッドへのアクセスを付与できます。

インスタンスロールは、セッションで直接 アクティブ化 できないことに注意してください。セッションでアクティブ化できるアカウントロールにインスタンスロールを付与します。

詳細については、 インスタンスロール をご参照ください。

アプリケーションロール:

コンシューマーが Snowflake Native App 内のオブジェクトにアクセスできるようにするには、プロバイダーは セットアップスクリプト 内でアプリケーションロールを作成し、アプリケーションロールに権限を付与します。

ただし、Snowflakeが所有者であるオブジェクトへのアクセス権の付与など、特定の機能に対する特定の機能をサポートするために、Snowflakeは1つ以上の システムアプリケーションロール を提供できます。アカウントロールにシステムアプリケーションロールを任意で付与することができます。

システムアプリケーションロールは、特定の機能のコンテキストで説明されます。なぜなら、システムアプリケーションロールを使用できるのは、その特定の機能だけだからです。例:

サービスの役割:

ロールにサービスエンドポイントへのアクセスを許可するには、そのロールにサービスロールを付与します。アカウントロール、アプリケーションロール、またはデータベースロールにサービスロールを付与できます。詳細については、 サービス関連権限の管理 をご参照ください。

アクティブロール

アクティブロール は、セッションでユーザーが実行するすべてのアクションの承認元として機能します。 プライマリロールとセカンダリロール の両方とも、ユーザーセッションで有効にすることができます。

ロールは、次のいずれかの方法でアクティブロールになります。

  • セッションが最初に確立されると、ユーザーの既定のロールと既定のセカンダリロールが、それぞれセッションのプライマリロールとセカンダリロールとしてアクティブ化されます。

    セッションの確立に使用されるクライアント接続プロパティは、使用するプライマリロールまたはセカンダリロールを明示的に上書きできることに注意してください。

  • USE ROLE または USE SECONDARY ROLES ステートメントを実行すると、それぞれ別のプライマリロールまたはセカンダリロールがアクティブになります。いずれかのコマンドが再度実行されると、これらのロールはセッション中に変更される可能性があります。

システム定義のロール

GLOBALORGADMIN:

(別名: 組織管理者)

アカウントのライフサイクル管理や組織レベルの使用情報の表示など、組織レベルのタスクを実行するロール。このロールは、 組織アカウント にのみ存在します。

ORGADMIN:

通常のアカウントを使用し、組織レベルでの運用を管理するロール。ORGADMIN ロールは将来のリリースで段階的に廃止される予定ですので、組織管理者は代わりに GLOBALORGADMIN ロールを使用することをお勧めします。

ACCOUNTADMIN:

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

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

SECURITYADMIN:

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

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

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

    注釈

    MANAGE GRANTS 権限により、権限の付与と取り消しが可能になります。オブジェクトの作成など、他のアクションを実行する許可が SECURITYADMIN に付与されるわけではありません。オブジェクトを作成するには、 SECURITYADMIN ロールにもオブジェクトの作成に必要な権限が付与されていなければなりません。例えば、データベースロールを作成するには、 CREATE DATABASE ROLE アクセス制御要件 で説明されているように、SECURITYADMIN にもCREATEDATABASEROLE 権限が付与されていなければなりません。

  • システムロール階層を通じて USERADMIN ロールの権限を継承します (つまり、 USERADMIN ロールは SECURITYADMIN に付与されます)。

USERADMIN:

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

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

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

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

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

SYSADMIN:

(別名システム管理者)

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

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

PUBLIC:

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

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

カスタムロール

カスタム アカウントロール は、 USERADMIN ロール(またはそれ以上のロール)、および CREATE ROLE 権限が付与されたロールを使用して作成できます。

カスタムデータベースロールはデータベース所有者(つまり、データベース上で OWNERSHIP 権限を持つロール)によって作成することができます。

デフォルトでは、新しく作成されたロールは、どのユーザーにも割り当てられず、他のロールにも付与されません。

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

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

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

権限

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

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

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

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

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

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

ロール階層と権限の継承

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

ロール階層の例

注釈

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

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

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

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

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

付与されたロールの権限の継承

このシナリオでは、

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

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

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

ロール階層の作成方法については、 ロール階層の作成 を参照してください。

データベースロールおよびロール階層

現在、データベースロールには次の制限が適用されます。

  • 共有 にデータベースロールが付与されている場合は、そのデータベースロールに他のデータベースロールを付与することはできません。たとえば、データベースロール d1.r1 が共有に付与されている場合は、データベースロール d1.r2d1.r1 に付与しようとするとブロックされます。

    さらに、データベースロールが 別の データベースロールに付与されている場合は、被付与者のデータベースロールを共有に付与することはできません。

    共有に付与されたデータベースロールは、アカウントロールだけではなく、他のデータベースロールにも付与できます。

  • ロール階層内のデータベースロールにアカウントロールを付与することはできません。

プライマリ・ロールとセカンダリ・ロールによる権限付与

すべてのアクティブユーザーセッションは、 プライマリロール とも呼ばれる、現在のロールを持っています。セッションが開始されたとき(例えば、ユーザーが 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 権限が必要)の場合、これらの権限の付与を検索する際には、プライマリロール、セカンダリロール、その他の継承されたロールが考慮されます。

注釈

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