Lake Formation のタグベースのアクセスコントロール - AWS Lake Formation

Lake Formation のタグベースのアクセスコントロール

Lake Formation のタグベースのアクセスコントロール (LF-TBAC) は、多数の Data Catalog リソースがある場合の Lake Formation 許可の付与に使用することが推奨される方式です。LF-TBAC は、名前付きリソース方式よりもスケーラブルで、許可管理のオーバーヘッドも少なくなります。

Lake Formation のタグベースのアクセスコントロールのしくみ

各 LF タグは、department=salesclassification=restricted などのキーバリューペアです。キーは、department=sales,marketing,engineering,finance など複数の定義された値を持つことができます。

LF-TBAC 方式を使用するには、データレイク管理者とデータエンジニアが以下のタスクを実行します。

タスク タスクの詳細

1. LF タグのプロパティと関係を定義します。

-

2. Lake Formation で LF タグを作成します。

LF タグの作成

3. LF タグを Data Catalog リソースに割り当てます。

Data Catalog リソースへの LF タグの割り当て

4. LF タグをリソースに割り当てる許可 (オプションで grant オプションを使用) を他のプリンシパルに付与します。

LF タグ許可の付与、取り消し、およびリスト化

5. LF タグ式 (オプションで grant オプションを使用) をプリンシパルに付与します。

LF-TBAC 方式を使用した Data Catalog 許可の付与

6. (推奨) プリンシパルが LF-TBAC 方式を使用して正しいリソースにアクセスできることを確認した後、名前付きリソース方式を使用して付与された許可を取り消します。

-

データレイク管理者が、3 個のデータベースと 7 個のテーブルに対する許可を 3 人のプリンシパルに付与する必要がある場合を考えてみましょう。


        左側に 3 人のユーザーが垂直に配置されています。右側には、A、B、および C のラベルが付けられた 3 個のデータベースが垂直に配置されています。データベース A には A.1 および A.2 のラベルが付けられた 2 個のテーブルがあり、データベース B には B.1 および B.2 のラベルが付けられたテーブル、データベース C には C.1、C.2、および C.3 のラベルが付けられた 3 個のテーブルがあります。17 本の矢印は、ユーザーをデータベースとテーブルに結び付けており、データベースおよびテーブルに対する許可のユーザーへの付与を示しています。

上記の図に示されている許可を名前付きリソース方式を使用して実現するには、以下にあるように、データレイク管理者が 17 個の許可を作成する必要があります (擬似コードを使用)。

GRANT CREATE_TABLE ON Database A TO PRINCIPAL 1 GRANT SELECT, INSERT ON Table A.1 TO PRINCIPAL 1 GRANT SELECT, INSERT ON Table A.2 TO PRINCIPAL 1 GRANT SELECT, INSERT ON Table B.2 TO PRINCIPAL 1 ... GRANT SELECT, INSERT ON Table A.2 TO PRINCIPAL 2 GRANT CREATE_TABLE ON Database B TO PRINCIPAL 2 ... GRANT SELECT, INSERT ON Table C.3 TO PRINCIPAL 3

今度は、データレイク管理者が LF-TBAC を使用してどのように許可を付与するかを考えてみます。以下の図は、データレイク管理者が LF タグをデータベースとテーブルに割り当てて、LF タグに対する許可をプリンシパルに付与したことを示しています。

この例では、LF タグが、エンタープライズリソースプランニング (ERP) アプリケーションスイートの異なるモジュールの分析が含まれるデータレイクの領域を表しています。データレイク管理者は、さまざまなモジュールの分析データへのアクセスを制御したいと考えています。すべての LF タグは、module というキーと、SalesOrders、および Customers の可能な値を持っています。LF タグの例は以下のようになります。

module=Sales

この図は LF タグの値のみを示しています。


        前の図と同様に、左側に 3 人のユーザーが垂直に配置されており、右側には A、B、および C のラベルが付けられた 3 個のデータベースが垂直に配置されています。データベース A には A.1 および A.2 のラベルが付けられた 2 個のテーブルがあり、データベース B には B.1 および B.2 のラベルが付けられたテーブル、データベース C には C.1、C.2、および C.3 のラベルが付けられた 3 個のテーブルがあります。ユーザーと、データベースとテーブルの間に矢印はありません。その代わりに、ユーザーの横にあるラベル付けされた「フラグ」が、ユーザー 1 に Sales (売上) および Customers (顧客) の LF タグが付与され、ユーザー 2 には Orders (注文) の LF タグ、ユーザー 3 には Customers (顧客) の LF タグが付与されていることを示しています。データベースとテーブルの横にあるフラグは、データベースとテーブルへの次のような LF タグの割り当てを示しています。データベース A: Sales (売上)。テーブル A.1: 淡色表示のフラグによって、Sales (売上) がデータベース A から継承されたことが示されています。テーブル A.2: Orders (注文)。ただし、淡色表示のフラグによって、Sales (売上) がデータベース A から継承されたことが示されています。データベース B: Orders (注文)。テーブル B.1 と B.2 は Orders (注文) を継承しており、テーブル B.2 には Customers (顧客) があります。データベース C には Customers (顧客) があり、テーブル C.1、C.2、および C.3 は Customers (顧客) を継承しています。C のテーブルに他の割り当てはありません。

Data Catalog リソースへのタグ割り当てと継承

テーブルはデータベースから LF タグを継承し、列はテーブルから LF タグを継承します。継承された値は上書きすることができます。上記の図では、淡色表示の LF タグが継承されています。

継承が行われるため、データレイク管理者は、リソースに対して以下の 5 つの LF タグの割り当てを行うだけで済みます (擬似コードを使用)。

ASSIGN TAGS module=Sales TO database A ASSIGN TAGS module=Orders TO table A.2 ASSIGN TAGS module=Orders TO database B ASSIGN TAGS module=Customers TO table B.2 ASSIGN TAGS module=Customers TO database C

プリンシパルへのタグの付与

データベースとテーブルに LF タグを割り当てた後、データレイク管理者は、以下にあるようにプリンシパルに対して 4 つの付与のみを実行する必要があります (擬似コードを使用)。

GRANT TAGS module=Sales TO Principal 1 GRANT TAGS module=Customers TO Principal 1 GRANT TAGS module=Orders TO Principal 2 GRANT TAGS module=Customers TO Principal 3

これで、LF タグ module=Sales を持つプリンシパルは LF タグ module=Sales を持つ Data Catalog リソース (例えば、データベース A) にアクセスでき、LF タグ module=Customers を持つプリンシパルは LF タグ module=Customers を持つリソースにアクセスできるといった状態になります。

上記の grant コマンドは不完全です。これらは、プリンシパルが許可を持つ Data Catalog リソースを LF タグで示してはいるものの、プリンシパルがそれらのリソースに対してどの Lake Formation 許可 (SELECTALTER など) を持っているかを正確に示していないためです。したがって、以下の擬似コードのコマンドが、LF タグを使用して Data Catalog リソースに対する Lake Formation 許可を付与する方法のより正確な表現になります。

GRANT (CREATE_TABLE ON DATABASES) ON TAGS module=Sales TO Principal 1 GRANT (SELECT, INSERT ON TABLES) ON TAGS module=Sales TO Principal 1 GRANT (CREATE_TABLE ON DATABASES) ON TAGS module=Customers TO Principal 1 GRANT (SELECT, INSERT ON TABLES) ON TAGS module=Customers TO Principal 1 GRANT (CREATE_TABLE ON DATABASES) ON TAGS module=Orders TO Principal 2 GRANT (SELECT, INSERT ON TABLES) ON TAGS module=Orders TO Principal 2 GRANT (CREATE_TABLE ON DATABASES) ON TAGS module=Customers TO Principal 3 GRANT (SELECT, INSERT ON TABLES) ON TAGS module=Customers TO Principal 3

まとめ – 結果として得られたリソースに対するプリンシパルの許可

以下の表は、上記の図のデータベースとテーブルに割り当てられた LF タグと、図の中でプリンシパルに付与された LF タグを前提とした、プリンシパルが持つデータベースとテーブルに対する Lake Formation 許可のリストです。

プリンシパル LF タグを通じて付与された許可
プリンシパル 1
  • データベース A に対する CREATE_TABLE

  • テーブル A.1 に対する SELECTINSERT

  • テーブル A.2 に対する SELECTINSERT

  • テーブル B.2 に対する SELECTINSERT

  • データベース C に対する CREATE_TABLE

  • テーブル C.1 に対する SELECTINSERT

  • テーブル C.2 に対する SELECTINSERT

  • テーブル C.3 に対する SELECTINSERT

プリンシパル 2
  • テーブル A.2 に対する SELECTINSERT

  • データベース B に対する CREATE_TABLE

  • テーブル B.1 に対する SELECTINSERT

  • テーブル B.2 に対する SELECTINSERT

プリンシパル 3
  • テーブル B.2 に対する SELECTINSERT

  • データベース C に対する CREATE_TABLE

  • テーブル C.1 に対する SELECTINSERT

  • テーブル C.2 に対する SELECTINSERT

  • テーブル C.3 に対する SELECTINSERT

結論

このシンプルな例では、5 つの割り当て操作と 8 つの付与操作を使用することで、データレイク管理者が 17 個の許可を指定できました。何十個ものデータベースと、数百個ものテーブルがあるときは、名前付きリソース方式に勝る LF-TBAC 方式の利点が明白になります。すべてのプリンシパルにすべてのリソースへのアクセス権を付与する必要があり、n(P) をプリンシパルの数、n(R) をリソースの数とする仮定上のケースでは、以下のようになります。

  • 名前付きリソース方式では、必要な付与数が n(P) × n(R) 個になります。

  • 単一の LF タグを使用する LF-TBAC 方式では、プリンシパルへの付与とリソースへの割り当ての合計数が n(P) + n(R) 個になります。