AWS Lake Formation による効果的なデータレイクの構築パート 4:セルレベルと行レベルのセキュリティを実装する

本記事は Amazon Web Services, Senior Analytics Specialist である Deenbandhu Prasad と Senior Big Data Architect である関山宜孝によって投稿されたものです。

AWS re:Invent 2020 で AWS Lake Formation のトランザクション、セルレベルと行レベルのセキュリティ、およびアクセラレーションのプレビューを発表しました。このシリーズのパート 1、パート 2、およびパート 3 では、governed table のセットアップ、ストリーミングおよびバッチデータの追加、および ACID トランザクションの使用方法について説明しました。この記事では、セルレベルと行レベルのセキュリティに焦点を当て、特定の行へのアクセスを制限してビジネスニーズを実現する方法について説明します。

効果的なデータレイクの構築

パート 1: governed table を作成する
パート 2: ストリーミングデータソース用の governed table を作成する
パート 3: governed table での ACID トランザクションを使用する
パート 4: セルレベルと行レベルのセキュリティを実装する
パート 5: 行レベルのアクセス制御でデータレイクを保護する

モダンなデータレイクの目標は、幅広いデータセットへのアクセスを民主化して、データアナリストとビジネスユーザーを支援することです。これらのシナリオでは、データレイクのセキュリティがかつてないほど重要になっています。エンタープライズのお客様は、コンプライアンスとセキュリティのニーズを両立しながら、グループ、部門、組織全体でデータを共有したいと考えています。多くのエンタープライズのお客様が使用される一般的な方法は、ユーザープロファイルまたは所属する組織に基づいてアクセスできるデータの範囲を制限することです。以前は、データを複製するか、フィルタリングされたデータセットに基づいてデータのマテリアライズドビューと非マテリアライズドビューを作成することによって実現する必要がありました。しかし、これらのソリューションはしばしば、信頼できる唯一の情報源（Single Source of Truth）のコンセプトを壊し、書き込みの増加につながり、ストレージに必要な容量を2倍、3倍にします。必要なコピー数が多いと、必要な管理作業も増加します。

Lake Formation は、シンプルな行レベルのセキュリティとセルレベルのセキュリティをサポートしています:

基本的な行レベルのセキュリティでは、ユーザーにテーブルの特定の行へのアクセスを制限するフィルタ式を指定できます。
セルレベルのセキュリティは、行レベルセキュリティに加えて、特定カラム群へのアクセス制御を用いることによって実現します。

この記事では、A社が米国とカナダでビジネスを行うユースケースの例について説明します。同社は、Amazon Simple Storage Service（Amazon S3）にエンタープライズカスタマーデータハブを構築しました。このハブは、両国の顧客をこの一元的な場所に集め、全社的な分析とマーケティングを行っています。

A社のマーケティング部門は、プロモーションキャンペーンを企画し、見込み客にサービスや製品を宣伝するためのコミュニケーションコンテンツの開発を担当しています。チームは、このエンタープライズカスタマーデータハブのデータを使用して、ターゲットキャンペーンを行います。

マーケティングチームのデータアナリストは国ごとに分割され、要件は自国の顧客データへのアナリストのアクセスに制限することです。米国のアナリストは米国からの顧客のみを参照でき、カナダのアナリストはカナダからの顧客のみにアクセスできます。さらに、カナダのアナリストは、現地の会社のポリシーにより、生年月日（DoB 列）を表示することはできません（この制限はセルレベルのセキュリティの一例です）。

この記事に使用するデータセットは人工的に生成されます。次のスクリーンショットは、データの例を示しています。

ソリューションの概要

Lake Formation の行レベルのセキュリティ機能を使用して、S3 データレイク内のデータに A 社の要件を実装する方法を見てみましょう。行レベルのセキュリティは、governed table または Lake Formation の標準テーブルに適用できます。この記事では、標準の Lake Formation テーブルに対して行レベルのセキュリティを適用します。governed table についても同様のプロセスに従うことができます。

次のハイレベルな手順を順を追って説明します:

データベース (lf_rls_blog) とテーブル (customer) を作成します。
ユーザーに lf-rls-blog-analyst-us および lf-rls-blog-analyst-ca に SELECT 権限 (行と列) を付与します。
米国およびカナダのアナリストとして Amazon Athena でクエリを実行し、ユーザーのそれぞれの国からの行（および適切な列）のみが表示されることを確認します。

AWS CloudFormation でリソースを準備する

この記事には、すばやくセットアップするための AWS CloudFormation テンプレートが含まれています。ニーズに合わせてカスタマイズできます。

CloudFormation テンプレートは次のリソースを生成します:

AWS Identity and Access Management (IAM) ユーザー、ロール、ポリシー:
- 3人のユーザーには、lf-rls-blog-manager（データレイク管理者）、lf-rls-blog-analyst-us（米国データアナリスト）、 lf-rls-blog-analyst-ca（カナダのデータアナリスト）が含まれます
Lake Formation データレイクの設定とリソース:
- プレフィックス lf-rowlevel-security-blog-* が付く S3 バケットと、この記事で使用される顧客データファイルが含まれます。

この記事の執筆時点では、これらの Lake Formation のプレビュー機能は us-east-1 および us-west-2 でのみ利用できます。この記事の手順に従うときは、リージョン us-east-1 を使用してください。今後他のリージョンで機能が使用可能かどうかを確認してください:

リソースを作成するには、次の手順を実行します:

us-east-1 リージョンで AWS CloudFormation コンソールにサインインします。
Launch Stack を選択します:
3 人のユーザーのパスワードを作成します。
ページの詳細を確認し、I acknowledge that AWS CloudFormation might create IAM resources （AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。）を選択します。
Create（スタックの作成） を選択します。

データベースとテーブルを作成する

データベースとテーブルを作成するには、次の手順を実行します:

データレイク管理者 (lf-rls-blog-manager) として AWS マネジメントコンソールにサインインします。
Lake Formation コンソールで、ナビゲーションペインで Databases を選択します。
Create database を選択します。
Name に lf_rls_blog と入力します。
Use only IAM access control for new tables in this database が選択されている場合は、チェックボックスをオフにします。
Create database を選択します。

次に、新しいデータレイクテーブルを作成します。

ナビゲーションペインで、Tables を選択します。
Create table を選択します。
Name に customer と入力します。
Database に、作成したデータベース (lf_rls_blog) を選択します。
Browse を選択して、CloudFormation テンプレートで作成された（lf-rowlevel-security-blog-* で始まる） S3 バケット内の datafiles の下にある customers フォルダーを選択します。
Classification で、CSV を選択します。
Delimiter で、Comma: , を選択します。
Upload Schema を選択します。

次の JSON コードを入力します:

[
{
"Name": "customer_id",
"Type": "bigint"
},
{
"Name": "prefix",
"Type": "string"
},
{
"Name": "first_Name",
"Type": "string"
},
{
"Name": "middle_Name",
"Type": "string"
},
{
"Name": "last_Name",
"Type": "string"
},
{
"Name": "suffix",
"Type": "string"
},
{
"Name": "gender",
"Type": "string"
},
{
"Name": "dob",
"Type": "string"
},
{
"Name": "phone",
"Type": "string"
},
{
"Name": "building_number",
"Type": "bigint"
},
{
"Name": "street_Name",
"Type": "string"
},
{
"Name": "city",
"Type": "string"
},
{
"Name": "cust_zip",
"Type": "bigint"
},
{
"Name": "country",
"Type": "string"
}
]

Upload を選択します。
Submit を選択します。

データフィルタを作成してパーミッションを設定する

列レベル、行レベル、およびセルレベルのセキュリティを実装するには、まずデータフィルタを作成します。次に、テーブルに対する Lake Formation のパーミッションを付与しながら、そのデータフィルタを選択します。このユースケースでは、米国のデータアナリスト用とカナダのデータアナリスト用の 2 つのデータフィルタを作成します。

許可されるフィルタ式は、 PartiQL の WHERE 句文法のサブセットに従う述語です。比較演算子を使用して、列を定数と比較できます。サポートされている演算子は次の通りです:

比較演算子 – =, >, <, >=, <=, <>, BETWEEN, IN, LIKE
論理演算子 – AND, OR

まず、米国アナリストのデータフィルタを作成してみましょう。

Lake Formation コンソールで、ナビゲーションペインから Data filters を選択します。
Create new filter を選択します。
Data filter name に US Filter と入力します。
Target database で、lf_rls_blog データベースを選択します。
Target table で、customer テーブルを選択します。
Column-level access で、Access to all columns を選択します。
Row filter expression に、country='US' と入力します。
Create filter を選択します。

米国のアナリストは、米国の顧客のすべての列にアクセスできます。

それでは、カナダのアナリストのデータフィルタを作成してみましょう。

Data filters ページで、Create new filter を選択します。
Data filter name に Canada Filter と入力します。
Target database で、lf_rls_blog データベースを選択します。
Target table で、customer テーブルを選択します。
Column-level access では、Exclude columns を選択します。
Select columns で、dob 列を選択します。
Row filter expression に、country='Canada' と入力します。
Create filter を選択します。

カナダのアナリストは、カナダの顧客の dob (生年月日) を除くすべての列にアクセスできるようになりました。

Data filters ページをチェックして、両方のデータフィルタが作成されていることを確認します。

これで、テーブルと列のパーミッションを付与できます。

Tables ページで、customer テーブルを選択します。
Actions メニューで、Grant を選択します。

IAM users and roles については、lf-rls-blog-analyst-us を選択します。
Named data catalog resources を選択します。
Databases で、lf_rls_blog を選択します。
Tables で、customer を選択します。
Table and column permissions で、Select を選択します。
Data permissions で Advanced cell-level filtersを選択します。
US Filter を選択します。
Grant を選択します。
lf-rls-blog-analyst-ca ユーザーに対してこれらの手順を繰り返し、 lf_rls_blog データベースと customerテーブルを選択し、Select 権限を付与します。
Advanced cell-level filters を選択します。
Data permissions セクションで、Canada Filter を選択します。
Grant を選択します。

クエリを実行してパーミッションレベルをテストする

Athena で Lake Formation のプレビュー機能を使用するには、クエリを実行する前に AmazonAthenaLakeFormationPreview という名前の新しいワークグループを作成し、そのワークグループに切り替える必要があります。詳細については、「ワークグループの管理」を参照してください。さらに、プレビューでは、次の例に示すように、データベース名とテーブル名に lakeformation 修飾子を使用します:

select * from lakeformation.<databasename>.<tablename>

Lake Formation は、テーブル作成者にすべての権限を暗黙的に付与します。このユースケースでは、lf-rls-blog-manager は、customer テーブルのすべての行と列に対する SELECT 権限を持ちます。まず、Athena を使用して customer テーブルにクエリを実行して、lf-rls-blog-manager の権限を検証しましょう。

Athena コンソール (us-east-1 リージョン) で、クエリエディタを開きます。
set up a query result location in Amazon S3 （Amazon S3 でクエリ結果の場所を設定する） を選択します。
lf-rowlevel-security-blog-* で始まる S3 バケットに移動し、anthenaqueryresults フォルダを選択します。
Save （保存） を選択します。
クエリエディタの Data source （データソース） で、AWSDataCatalog を選択します。
Database （データベース） で、lf_rls_blog を選択します。
AmazonAthenaLakeFormationPreview ワークグループを作成して、切り替えます。

Tables （テーブル） の下に customer テーブルが表示されます。

次のクエリを入力します:

SELECT * FROM lakeformation."lf_rls_blog"."customer"

Run query （クエリの実行） を選択します

lf-rls-blog-manager ユーザーには両方の国の行が表示されます。

次に、このテーブルの lf-rls-blog-analyst-us および lf-rls-blog-analyst-ca ユーザーのパーミッションを検証してみましょう。

lf-rls-blog-analyst-us としてコンソールにサインインします。
Athena コンソール (us-east-1) で前の手順を繰り返して、クエリ結果の場所を設定します。
AmazonAthenaLakeFormationPreview ワークグループに切り替えます。

次のクエリを実行します:

SELECT * FROM lakeformation."lf_rls_blog"."customer"

米国のデータアナリストのクエリ実行結果には、米国の顧客のみが表示されます。

次に、カナダのデータアナリストでも同じことを検証します。

lf-rls-blog-analyst-ca としてコンソールにサインインします。
Athena コンソール (us-east-1) で前の手順を繰り返して、クエリ結果の場所を設定します。
AmazonAthenaLakeFormationPreview ワークグループに切り替えます。

次のクエリを実行します:

SELECT * FROM lakeformation."lf_rls_blog"."customer"

カナダのデータアナリストには、カナダの顧客のみが表示されます。さらに、lf-rls-blog-analyst-ca ユーザーは dob 列にアクセスできません。

クリーンアップ

最後のステップとして、作成したリソースをクリーンアップします:

lf-rls-blog-manager としてコンソールにサインインします。
Lake Formation コンソールで、ナビゲーションペインで Databases を選択します。
データベース lf_rls_blog を選択します。
Action メニューの Delete を選択します。
プレフィックス lf-rowlevel-security-blog-* が付いた Amazon S3 バケットから anthenaqueryresultsフォルダーを削除します。
この記事で CloudFormation スタックを起動したユーザーとしてログインします。
AWS CloudFormation コンソールで、スタック lf-rowlevel-security-blog を削除します。

スタックを削除すると、スタックが作成したリソースは自動的に削除されます。

まとめ

この記事では、Lake Formation の新しい行レベルのセキュリティ機能を使用して、データレイクテーブルにきめ細かなアクセス制御を実装する方法を説明しました。この機能を使用すると、プライバシー規制やコーポレートガバナンスを実現するデータアクセスのルールを簡単にデータレイクに適用できます。

Lake Formation について更に調べて、これらの機能を使用して Amazon S3 でセキュアなデータレイクを構築してください。よろしければ、コメント欄にご意見や質問をお願いいたします。

原文はこちらです。
本ブログは Solutions Architect の宮田が翻訳しました。

Amazon Web Services ブログ

AWS Lake Formation による効果的なデータレイクの構築 パート 4:セルレベルと行レベルのセキュリティを実装する