Amazon Web Services ブログ
リソースレベルの IAM アクセス許可とリソースベースのポリシーで、AWS Glue データカタログへのアクセスを制限する
データレイクはあらゆる規模で構造化および非構造化データを格納するために使用できる集中リポジトリを提供します。データレイクには、未加工のデータセットと整理され、クエリ用に最適化されたデータセットの両方を格納できます。未加工のデータセットは本来の形式で、素早く取り込むことが可能で、事前定義されたスキーマに無理矢理押し込める必要がありません。データレイクを使用すると、未加工と整理されたデータセットの両方に異なるタイプの分析を実行できます。データレイクのストレージレイヤーに Amazon S3 を使用することで、バケットとオブジェクトレベルの両方を細かくコントロールできるようになります。レイクのデータセットのアクセスコントロールポリシーを定義するためにこれらを使用できます。
AWS Glue データカタログは、永続型のフルマネージドメタデータストアで、AWS のデータレイクに使用できます。Glue データカタログを使用することで、Apache Hive Metastore で実行するのと同じ方法で AWS クラウドでもメタデータの保存、注釈の付与、共有を実行できます。Glue データカタログはまた、Amazon Athena、Amazon EMR、Amazon Redshift Spectrum などと、シームレスで、細かな設定の不要な統合を実現できます。
AWS Glue を使用することで、ユーザー、ロールをベースにした、または、リソースレベルに適用した、カタログの異なる部分へのアクセスを制限するポリシーの作成も可能です。これらのポリシーを使って、どのユーザーがデータレイク内で種々のメタデータ定義にアクセスできるかを詳細にコントロールできます。
重要: S3 および AWS Glue データカタログのポリシーは、それぞれ、データとメタデータ定義のアクセス許可を定義します。言い換えれば、AWS Glue データカタログのポリシーは、メタデータへのアクセスを定義し、S3 ポリシーはコンテンツそのものへのアクセスを定義します。
GetDatabases、GetTables、CreateTable、およびその他の個人識別ベースのポリシー (IAM) を使用して、どのメタデータを操作できるようにするか制限できます。また、その操作で実行するデータカタログオブジェクトも制限できます。さらに、結果の呼び出しで戻されるカタログオブジェクトを制限できます。ここで言う Glue データカタログの「オブジェクト」とは、データベース、テーブル、ユーザー定義の関数、または Glue データカタログに格納された接続を指します。
データレイクの本番環境のデータベースとテーブルに読み取りアクセスが必要で、他にはリソースを開発するための追加的なアクセス権限があるユーザーがいるとします。また、未加工データのフィードとビジネスインテリジェンス、分析、機械学習などのアプリケーションで使用された整理済みのデータセットの両方を格納するデータレイクがあるとします。これらの構成を簡単に設定でき、AWS Glue データカタログのアクセスコントロールメカニズムを使用して、他のものも多数簡単に設定できるようになります。
注意: 以下の例では、AWS Glue データカタログでポリシーをセットアップする方法について解説します。関連付けられた S3 バケットやオブジェクトレベルのポリシーは設定しません。これは、Athena、EMR、AWS Glue データカタログと統合されるツールの使用時、メタデータが検出できないことを意味します。誰かが S3 オブジェクトに直接アクセスしようとしたときに、S3 ポリシーが強制されることが重要です。データカタログと S3 バケットまたはオブジェクトレベルのポリシーを一緒に使用する必要があります。
きめ細かなアクセスコントロール
組織のニーズに応じて、リソースベースと個人識別ベースのポリシーの両方を使用して、 メタデータへのアクセスを定義できます。リソースベースのポリシーは、ご使用のリソースへのアクセスを許可または拒否する原則をリストします。これにより、アカウントをまたいだアクセスなど、各種ポリシーをセットアップできます。個人識別ポリシーは特に、ユーザー、グループ、IAM 内のロールに接続されます。
ポリシーのきめ細かなアクセス部分は、リソース句の中で定義されます。この部分はアクションを実行可能な AWS Glue データカタログオブジェクトと、操作によって返される結果オブジェクトの両方を定義します。
例を見ていきましょう。あるグループのユーザーが、finegrainacces データベースにのみアクセスできるようにするポリシーを定義するとします。また、このポリシーはユーザーがデータベース内にリストされているすべての表を返せるようにします。GetTables のアクションでは、リソース定義に次のリソースのステートメントが含まれます。
データベースの最初のリソースステートメントでは、Amazon リソースネーム (ARN) は finegrainaccess データベースの操作をユーザーが呼び出すのを許可しています。2 つ目の ARN はデータベース内の全部のテーブルを返せるようにします。
次に、“finegrainaccess” データベースから “dev_” で開始するテーブルのみを返すようにするにはどうしたらいいでしょう? その場合、ポリシーは次のように変わります。
次に、2 つ目のリソース定義で、テーブルの ARN の dev_ as 部分を指定していきます。このアプローチはデータベースのリスト、テーブルのパーティション、カタログでの他の操作の取得のためのアクションと併用することもできます。
試してみましょう
注意: 本投稿は AWS Glue データカタログのポリシーを集中して取り扱います。細部を見ると、これらのデータベースが、世界で読むことのできるすべて同じ S3 の場所をポイントしているのがお分かりになるでしょう。完全な例では、必要な S3 バケットやオブジェクトレベルのアクセス許可、またはその両方も設定する必要があります。
次に、皆さんがご自身で実行できる例をご紹介します。次の例では、データカタログ上で次のものを作成します。
次に示すように、この例では 2 人のユーザーをセットアップします。
AWS マネジメントコンソールで、AWS CloudFormation テンプレートを起動します。
[Next] を選択します。
重要: 作成される IAM ユーザーのパスワードを入力します。これらのユーザーには、Athena クエリの実行、Athena S3 結果バケットへのアクセス、CloudFormation スクリプトが作成する AWS Glue データベースの表示などを実行するアクセス許可が付与されます。これらのアクセス許可は、この例を実行するアカウントの IAM パスワードのポリシーに策定された最低要件に一致する必要があります。
[Next] を作成し、その後、次のページで [Next] をもう一度選択します。
最後に、テンプレートで IAM ユーザーとポリシーが作成されることを確認します。
次に、[Create] を選択します。
CloudFormation ページを最新表示すると、例のリソースを作成するスクリプトが表示されます。
処理が完了するまで待ちます。
このスクリプトは必要な IAM ユーザーと、そのユーザーに設定されるポリシー、また、前述のデータベースとテーブルを作成します。
CloudFormation スクリプトが完了後、管理者ユーザーを使用している場合には次のテーブルが表示されます。
Outputs タブを見ると、IAM のサインイン URL とともに作成された IAM ユーザーが 2 人できているのが分かります。
注意:
同一ブラウザ上でこのサインインリンクをクリックすると、システムによって自動的にログアウトされます。ここで右クリックして、プライベートウィンドウまたはシークレットウィンドウを開いてこの処理を行うとログアウトされるのを回避できます。
入力された IAM パスワードが最低要件を満たしていない場合には、CloudFormation のスクリプトイベントログにこのメッセージが表示されます。
AWS Glue データカタログを見ると、スクリプトによってテーブルが作成されたばかりであるのが分かります。
先程触れた構造がスクリプトによって作成されています。
2 人のユーザーのプロファイルを確認してみましょう。IAM とユーザーをよく見ると、インラインポリシーとして設定されているのが分かります。ユーザーごとに次のように表示されるはずです。
AWS Glue の dev ユーザーの場合、このセクションは dev データベースのすべてにアクセス許可を付与しています。
このセクションでは prod データベースにクエリを発行し、データベースを表示する機能を付与しています。
最後に、このセクションは prod データベースからテーブルとパーティションを取得できるアクセス許可を付与しています。このセクションを構造化することで、セクションがリソース内で blog_prod データベースを明示的にリストし、それのみに許可を与えられるようになります。以下では、誰でも database/* にクエリを発行でき、blog_prod のテーブルのみが返されます。これは実際のところ、コンソールのデフォルトの動作です。
この機能がない場合、ユーザーはそれら 2 つのデータベースに明示的にクエリを発行することはできますが、ポリシーでは以下のようなワイルドカードのクエリは許可されません。
逆に、QA ユーザーは dev データベースにアクセス権を持たず、prod データベースの prod_ で開始するテーブルのみしか見ることができません。要するに、QA ユーザーのポリシーは次のようになります。
prod データベースのクエリは以下のとおりです。
prod_ で始まる表では、GetTables と GetPartitions のみを使用できます。
次のリソース定義の「prod_*」をご覧ください。
異なるユーザーベースにクエリを発行する
AWS CloudFormation 出力タブで作成された異なる IAM ユーザー 2 人と、自分で作成したパスワードでログインすると、違いがあるのがお分かりでしょう。
QA ユーザーは blog_dev データベースのメタデータ定義、または blog_prod データベースの staging_yellow テーブルを一切表示できません。
次に、blog_dev_user としてログインし、Athena コンソールに行きます。ブログユーザーには許可されたデータベースとテーブルのリストしか表示されないのが分かります。
dev ユーザーは blog_dev の下にテーブルを作成できますが、blog_prod データベースでは作成できません。
次に dev_qa_user の下を見ていきましょう。Athena では blog_prod と prod_* の表しか見えていないのが分かります。
QA ユーザーは自分で見ることのできるデータベースにクエリを発行することはできますが、このポリシーではユーザーがデータベースやテーブルを作成する許可を与えていません。
QA ユーザーが Athena を通じてクエリを発行しようとし、手動でコンソールの外にメタデータをプルしても、そのユーザーはその情報を見ることはできません。以下を実行することでこれをテストできます。
結論
データのカタログは多くの分析システムで重要な部分です。AWS Glue データカタログは、多彩なツールと統合できます。データカタログを使用することで、データカタログのオブジェクトに許可を付与するポリシーを指定することもできます。データレイクでは、コンテンツレベルと、コンテンツを記述するメタデータのレベルの両方に、詳細なアクセスコントロールが必要です。この例では、カタログのメタデータにアクセスポリシーを定義する方法を説明しています。
その他の参考資料
参考資料として、harmonize, search, and analyze loosely coupled datasets on AWS をご覧ください。
今回のブログ投稿者について
Ben Snively は、パブリックセクタースペシャリストのソリューションアーキテクトです。 彼は、ビッグデータおよび分析プロジェクトで政府機関、非営利組織、教育機関のお客様と協力し、AWS を使用したソリューションの構築をサポートしています。余暇には、家中に IoT センサーを取り付けて、その分析を実行しています。