Athena を使用して Lake Formation に登録されたデータをクエリするときの考慮事項と制限 - Amazon Athena
一部の状況で、列に対するデータ許可がないユーザーに列メタデータが表示されるビューに対する Lake Formation 許可の使用Lake Formation のきめ細かなアクセス制御と Athena ワークグループLake Formation に登録されていない Amazon S3 の Athena クエリ結果の場所Athena Workgroups を使用してクエリ履歴へのアクセスを制限するクロスアカウントアクセスLake Formation に登録された CSE-KMS Simple Storage Service (Amazon S3) を Athena でクエリできないLake Formation に登録されているパーティションされたデータの場所がテーブルのサブディレクトリ内にある必要があるCreate Table As Select (CTAS) クエリに Simple Storage Service (Amazon S3) の書き込み許可が必要になるデフォルトデータベースに DESCRIBE 許可が必要になる

Athena を使用して Lake Formation に登録されたデータをクエリするときの考慮事項と制限

Athena を使用して Lake Formation に登録されたデータをクエリするときは、以下の点を考慮します。詳細については、「AWS Lake Formation デベロッパーガイド」の「AWS Lake Formation の既知の問題」を参照してください。

Avro とカスタム SerDe を使用する一部の状況で、許可されていないユーザーに列メタデータが表示される

Lake Formation の列レベルの承認は、ユーザーが Lake Formation の許可がない列のデータにアクセスできないようにします。ただし、特定の状況では、ユーザーがデータに対する許可がない列を含めた、テーブル内のすべての列を説明するメタデータにアクセスできます。

これは、Apache Avro ストレージ形式を使用するか、SerDe 定義と共にテーブルプロパティにテーブルスキーマが定義されているカスタムシリアライザー/デシリアライザー (SerDe) を使用して、列メタデータがテーブルのテーブルプロパティに保存されたときに発生します。Athena で Lake Formation を使用するときは、Lake Formation に登録するテーブルプロパティの内容を確認し、可能な場合はテーブルプロパティに保存される情報を制限して、機密のメタデータがユーザーに表示されないようにすることをお勧めします。

ビューに対する Lake Formation 許可の使用

Lake Formation に登録されたデータについて、Athena ユーザーが VIEW を作成できるのは、VIEW の基礎であるテーブル、列、および Simple Storage Service (Amazon S3) のソースデータの場所に対する Lake Formation の許可がある場合のみです。VIEW が Athena で作成されたら、Lake Formation 許可を VIEW に適用できます。列レベルのアクセス許可は、VIEW では使用できません。VIEW に対する Lake Formation の許可はあるが、ビューの基礎であるテーブルと列に対する許可はないというユーザーは、データのクエリに VIEW を使用できません。ただし、この許可の組み合わせを持つユーザーは、DESCRIBE VIEW、SHOW CREATE VIEW、および SHOW COLUMNS を使用して VIEW メタデータを表示できます。このため、各 VIEW に対する Lake Formation 許可は、基盤となるテーブルの許可と合致させておくようにしてください。テーブルで定義されているセルフィルターは、そのテーブルの VIEW に適用されません。リソースリンク名は、元となるアカウントのリソースと同じ名前である必要があります。クロスアカウント設定でビューを操作するとき、他にも制限があります。アカウント間での共有ビューの許可のセットアップの詳細については、「データカタログへのクロスアカウントアクセス」を参照してください。

Lake Formation のきめ細かなアクセス制御と Athena ワークグループ

同じ Athena ワークグループのユーザーは、Lake Formation のきめ細かなアクセス制御によりワークグループがアクセスできるように設定したデータを見ることができます。Lake Formation でのきめ細かいアクセス制御の使用について詳しくは、「AWS ビッグデータブログ」の「AWS Lake Formation を使用したきめ細かなアクセス制御の管理」を参照してください。

Lake Formation に登録されていない Amazon S3 の Athena クエリ結果の場所

Amazon S3 にある Athena のクエリ結果の場所を Lake Formation に登録することはできません。Lake Formation 許可は、これらの場所へのアクセスを制限しません。アクセスを制限しない限り、Athena ユーザーは、データに対する Lake Formation の許可がなくてもクエリ結果ファイルとメタデータにアクセスできます。この問題を回避するには、ワークグループを使用してクエリ結果の場所を指定し、ワークグループのメンバーシップを Lake Formation の許可と合致させることが推奨されます。その後、IAM 許可ポリシーを使用して、クエリ結果の場所へのアクセスを制限できます。クエリ結果の詳細については、「クエリ結果、最近のクエリ、および出力ファイルの使用」を参照してください。

Athena Workgroups を使用してクエリ履歴へのアクセスを制限する

Athena クエリ履歴は、保存されたクエリと完全なクエリ文字列のリストを公開します。ワークグループを使用してクエリ履歴へのアクセスを分離しない限り、Lake Formation のデータをクエリする権限がない Athena ユーザーが、列名や選択条件などを含めた、そのデータに対して実行されるクエリ文字列を表示することができます。ワークグループを使用してクエリ履歴を分離し、Athena ワークグループのメンバーシップを Lake Formation 許可に合致させてアクセスを制限することが推奨されます。詳細については、「ワークグループを使用してクエリのアクセスとコストを制御する」を参照してください。

データカタログへのクロスアカウントアクセス

別のアカウントのデータカタログにアクセスするには、Athena のクロスアカウント AWS Glue 機能を使用するか、Lake Formation でクロスアカウントアクセスをセットアップします。

データカタログへの Athena クロスアカウントアクセス

Athena のクロスアカウント AWS Glue カタログ機能を使用して、アカウントにカタログを登録できます。この機能は Athena エンジンバージョン 2 以降でのみ使用でき、アカウント間の同一リージョンでの使用に制限されています。詳細については、「別のアカウントからデータカタログを登録する」を参照してください。

共有するデータカタログのリソースポリシーが AWS Glue で設定されている場合、次の例のように AWS Resource Access Manager へのアクセスを許可し、アカウント B へ許可を付与して、アカウント A のデータカタログを使用するように、更新する必要があります。

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "Service": "ram.amazonaws.com"
        },
        "Action": "glue:ShareResource",
        "Resource": [
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:table/*/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:database/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:catalog"
        ]
    }, 
    {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::<ACCOUNT-B>:root"
        },
        "Action": "glue:*",
        "Resource": [
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:table/*/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:database/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:catalog"
        ]
    }
    ]
}

詳細については、「AWS Glue データカタログへのクロスアカウントアクセス」を参照してください。

Lake Formation でのクロスアカウントアクセスのセットアップ

AWS Lake Formation では、単一のアカウントを使用して中央データカタログを管理できます。この機能を使用して、データカタログメタデータと基盤となるデータにクロスアカウントアクセスを実装します。例えば、所有者アカウントは、テーブルに対する SELECT 許可を別の (受信者) アカウントに付与できます。

共有のデータベースまたはテーブルを Athena クエリエディタに表示するには、Lake Formation で共有のデータベースまたはテーブルへのリソースリンクを作成します。Lake Formation の受信者アカウントが所有者のテーブルをクエリすると、CloudTrail が受信者アカウントと所有者アカウントの両方のログにデータアクセスイベントを追加します。

共有ビューの場合は、次の点に注意してください。

  • クエリは、ソーステーブルまたはビューではなく、ターゲットリソースリンクで実行され、出力がターゲットアカウントと共有されます。

  • ビューだけを共有するだけでは不十分です。ビューの作成に関与するすべてのテーブルは、クロスアカウント共有の一部である必要があります。

  • 共有リソースで作成されたリソースリンクの名前は、所有者アカウントのリソースの名前と一致する必要があります。名前が一致しない場合、「Failed analyzing stored view 'awsdatacatalog.my-lf-resource-link.my-lf-view': line 3:3: Schema schema_name does not exist」のようなエラーメッセージが表示されます。

Lake Formation でのクロスアカウントアクセスの詳細については、「AWS Lake Formation デベロッパーガイド」の以下のリソースを参照してください。

クロスアカウントアクセス

Lake Formation でのリソースリンクの仕組み

CloudTrail のクロスアカウントロギング

Lake Formation 登録済みの CSE-KMS で暗号化された Amazon S3 の場所

以下の特性を持つ Apache Iceberg などの Open Table Format (OTF) テーブルを Athena でクエリすることはできません。

  • テーブルが Lake Formation 登録済みの Amazon S3 の場所に基づいている。

  • Amazon S3 内のオブジェクトがクライアント側の暗号化 (CSE) を使用して暗号化されている。

  • 暗号化が AWS KMS カスタマーマネージドキー (CSE_KMS) を使用している。

CSE_KMS キーで暗号化されている OTF 以外のテーブルをクエリするには、CSE 暗号化に使用している AWS KMS キーのポリシーに、以下のブロックを追加します。<KMS_KEY_ARN> は、データを暗号化する AWS KMS キーの ARN です。<IAM-ROLE-ARN> は、Lake Formation で Amazon S3 を登録する IAM ロールの ARN です。

{
    "Sid": "Allow use of the key",
    "Effect": "Allow",
    "Principal": {
        "AWS": "*"
    },
    "Action": "kms:Decrypt",
    "Resource": "<KMS-KEY-ARN>",
    "Condition": {
        "ArnLike": {
            "aws:PrincipalArn": "<IAM-ROLE-ARN>"
        }
    }
}

Lake Formation に登録されているパーティションされたデータの場所がテーブルのサブディレクトリ内にある必要がある

Lake Formation に登録されているパーティションされたテーブルは、パーティションされたデータが Amazon S3 にあるテーブルのサブディレクトリであるディレクトリに置かれている必要があります。例えば、場所が s3://DOC-EXAMPLE-BUCKET/mytable で、パーティションが s3://DOC-EXAMPLE-BUCKET/mytable/dt=2019-07-11、s3://DOC-EXAMPLE-BUCKET/mytable/dt=2019-07-12 などにあるテーブルは、Lake Formation に登録し、Athena を使用してクエリできます。反対に、場所が s3://DOC-EXAMPLE-BUCKET/mytable で、パーティションが s3://DOC-EXAMPLE-BUCKET/dt=2019-07-11、s3://DOC-EXAMPLE-BUCKET/dt=2019-07-12 などにあるテーブルを Lake Formation に登録することはできません。このようなパーティションは s3://DOC-EXAMPLE-BUCKET/mytable のサブディレクトリではなく、それらを Athenaから読み込むこともできないからです。

Create Table As Select (CTAS) クエリに Simple Storage Service (Amazon S3) の書き込み許可が必要になる

Create Table As Statements (CTAS) には、テーブルの Amazon S3 の場所への書き込みアクセス権が必要です。Lake Formation に登録されたデータに対して CTAS クエリを実行するには、Athena ユーザーに、データの場所を読み込むための適切な Lake Formation 許可に加えて、テーブルの Amazon S3 の場所に書き込むための IAM 許可が必要です。詳細については、「クエリ結果からのテーブルの作成 (CTAS)」を参照してください。

デフォルトデータベースに DESCRIBE 許可が必要になる

Lake Formation が default データベースを表示できるようにするには、そのデータベースで Lake Formation DESCRIBE 許可が必要です。以下の AWS CLI コマンドの例では、AWS アカウント 111122223333 のユーザー datalake_user1 に、default データベースに対する DESCRIBE アクセス許可を付与しています。

aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Database": {"Name":"default"}}

詳細については、「AWS Lake Formation デベロッパーガイド」の「DESCRIBE」を参照してください。