# クロスアカウントアクセス許可の付与
アカウント間で Data Catalog のリソースへのアクセスを許可することで、抽出、変換、ロード (ETL) ジョブで、異なるアカウントからデータをクエリし、そのデータを結合できるようになります。
**Topics**
+ [クロスアカウントのアクセスを許可する AWS Glue のメソッド](#cross-account-how-works)
+ [Data Catalog リソースポリシーの追加または更新](#cross-account-adding-resource-policy)
+ [クロスアカウント API コールの実行](#cross-account-calling)
+ [クロスアカウント ETL コールの実行](#cross-account-calling-etl)
+ [CloudTrail のクロスアカウントロギング](#cross-account-ct-logs)
+ [クロスアカウントリソースの所有権および請求](#cross-account-ownership-and-billing)
+ [クロスアカウントアクセスの制約事項](#cross-account-limitations)
## クロスアカウントのアクセスを許可する AWS Glue のメソッド
自分のデータに対するアクセスを外部の AWS アカウントに許可するためには AWS Glue メソッドまたは AWS Lake Formation クロスアカウント付与を使用する必要があります。AWS Glue メソッドは AWS Identity and Access Management (IAM) ポリシーを使用して、きめ細かなアクセスコントロールを実現します。Lake Formation では、リレーショナルデータベースシステムでの `GRANT/REVOKE` コマンドに類似した、よりシンプルなアクセス許可 (`GRANT/REVOKE`) のモデルを使用します。
このセクションでは、AWS Glue メソッドの使用について説明します。Lake Formation のクロスアカウント付与の使用については、*AWS Lake Formation デベロッパーガイド* の「[Granting Lake Formation Permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/lake-formation-permissions.html)」を参照してください。
リソースにクロスアカウントアクセスを許可するためには、2 つの AWS Glue メソッドが用意されています。
+ Data Catalog のリソースポリシーを使用
+ IAM ロール を使用
**リソースポリシーを使用してのクロスアカウントアクセスの許可**
Data Catalog リソースポリシーを使用してクロスアカウントアクセスを許可するための、一般的な手順を以下に示します。
1. アカウント A の管理者 (または権限付与されたアイデンティティ) が、リソースポリシーをアカウント A 内の Data Catalog にアタッチします。このポリシーは、アカウント A のカタログにあるリソースに対してオペレーションを実行するための、特定のクロスアカウントアクセス許可をアカウント B に付与します。
1. アカウント B の管理者は、アカウント A から受け取ったアクセス許可を委任する、アカウント B の IAM アイデンティティに IAM ポリシーをアタッチします。
これで、アカウント B のアイデンティティは、アカウント A にある指定されたリソースにアクセスできるようになります。
このアイデンティティがこのリソースにアクセスするには、リソースの所有者 (アカウント A) *および* その親アカウント (アカウントB) の *両方* からアクセスを許可される必要があります。
**IAM ロールを使用したクロスアカウントアクセス許可の付与**
以下に、IAM ロールを使用してクロスアカウントアクセスを許可する一般的な手順を示します。
1. リソースを所有するアカウント (アカウント A) 内の管理者 (または権限許可された他のアイデンティティ) が IAM ロールを作成します。
1. アカウント A 内の管理者は、対象のリソースにアクセスするためのクロスアカウントアクセス許可を付与するロールにポリシーをアタッチします。
1. アカウント A 内の管理者により、ロールへの信頼ポリシーのアタッチが行われます。このロールは、別のアカウント (アカウント B) 内の IAM アイデンティティを、そのロールを引き受けることのできるプリンシパルとして識別します。
信頼ポリシーのプリンシパルに、ロールを引き受けるための AWS サービスへのアクセス許可を付与する場合は、このプリンシパルを AWS サービスのプリンシパルとすることができます。
1. これで、アカウント B の管理者はアカウント B の 1 つ以上の IAM アイデンティティにアクセス許可を委任して、ロールを引き受けることを許可します。これにより、アカウント B のこれらのアイデンティティに対してアカウント A のリソースに対するアクセス許可が付与されます。
IAM を使用したアクセス許可の委任の詳細については、*IAM ユーザーガイド* の [アクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) を参照してください。ユーザー、グループ、ロール、アクセス権限の詳細については、*IAM ユーザーガイド* の [ID (ユーザー、グループ、ロール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) を参照してください。
この 2 つの方法の比較については、*IAM ユーザーガイド* の「[IAM ロールとリソースベースのポリシーとの相違点](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)」を参照してください。AWS Glue は両方の方法をサポートしていますが、リソースポリシーが許可できるのはデータカタログリソースへのアクセスのみ、という制限があります。
例えば、アカウント B の `Dev` ロールにアカウント A のデータベース `db1` へのアクセスを許可するときは、次のリソースポリシーをアカウント A のカタログにアタッチします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase"
],
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Dev"
]
},
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
さらに、アカウント B がアカウント A の `db1` に実際にアクセスする前に、アカウント B で次の IAM ポリシーを `Dev` ロールにアタッチする必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
## Data Catalog リソースポリシーの追加または更新
コンソール、API、または AWS Glue (AWS Command Line Interface) により、AWS CLI Data Catalog のリソースポリシーを追加したり、更新したりできます。
**重要**
自分のアカウントの AWS Lake Formation で、既にクロスアカウントのアクセス許可付与を作成済みの場合は、Data Catalog のリソースポリシーを追加または更新するには追加の手順が必要となります。詳細については、*AWS Lake Formation デベロッパーガイド* の「[AWS Glue Glue と Lake Formation の両方を使用したクロスアカウント許可の管理](https://docs.aws.amazon.com/lake-formation/latest/dg/hybrid-cross-account.html)」を参照してください。
Lake Formation クロスアカウント許可が存在するかどうかを確認するときは、`glue:GetResourcePolicies` API オペレーションまたは AWS CLI を使用します。この `glue:GetResourcePolicies` が既存のデータカタログポリシー以外のポリシーを返した場合、Lake Formation の許可は存在します。詳細については、*AWS Lake Formation デベロッパーガイド* の「[Viewing All Cross-Account Grants Using the GetResourcePolicies API](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-getresourcepolicies.html)」(GetResourcePolicies API を使用したすべてのクロスアカウント許可の表示) を参照してください。
**Data Catalog のリソースポリシーを追加または更新するには (コンソール)**
1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) で AWS Glue コンソール を開きます。
`glue:PutResourcePolicy` アクセス許可を持つ AWS Identity and Access Management (IAM) 管理ユーザーとしてサインインします。
1. ナビゲーションペインで **[Settings (設定)]** を選択します。
1. [**Data catalog settings**] (データカタログ設定) ページの [**Permissions**] (アクセス許可) の下にあるテキスト欄に、リソースポリシーを貼り付けます。次に、**[Save (保存)]** を選択します。
ポリシー内のアクセス許可が、Lake Formation を使用して付与されたアクセス許可に追加されることを示す警告がコンソールに表示される場合は、[**Proceed**] (続行する) をクリックします。
**Data Catalog のリソースポリシーを追加または更新するには (AWS CLI)**
+ `aws glue put-resource-policy` コマンドを送信します。Lake Formation・グラントが既に存在する場合には、`--enable-hybrid` オプションに値 `'TRUE'` を設定する必要があります。
このコマンドの使用例については、[AWS Glue のリソースベースのポリシーの例](security_iam_resource-based-policy-examples.md) を参照してください。
## クロスアカウント API コールの実行
すべての AWS Glue Data Catalog オペレーションに `CatalogId` フィールドがあります。クロスアカウントアクセスを有効にするために必要なアクセス許可が付与済みであれば、複数のアカウントをまたいで Data Catalog API を呼び出すことが可能です。呼び出し元は、ターゲット AWS アカウント ID を `CatalogId` で渡すことで、ターゲットアカウントのリソースに対するアクセスを実行します。
`CatalogId` 値を指定しない場合、AWS Glue はデフォルトで発信者自身のアカウント ID を使用するため、コールはクロスアカウントにはなりません。
## クロスアカウント ETL コールの実行
一部の AWS Glue PySpark および Scala API には、カタログ ID フィールドがあります。クロスアカウントアクセスを有効にする、すべての必要なアクセス許可が付与されていれば、ETL ジョブはアカウントをまたがって、PySpark および Scala による API オペレーション呼び出しを行えます。これには、ターゲットアカウント内の Data Catalog リソースにアクセスするように、ターゲットの AWS アカウント ID をカタログ ID フィールドで指定し受け渡す必要があります、
カタログ ID 値を指定しない場合、AWS Glue はデフォルトで発信者自身のアカウント ID を使用するため、コールはクロスアカウントにはなりません。
`catalog_id` をサポートする PySpark API については、[GlueContext クラス](aws-glue-api-crawler-pyspark-extensions-glue-context.md) を参照してください。`catalogId` をサポートする Scala API については、[AWS Glue Scala GlueContext API](glue-etl-scala-apis-glue-gluecontext.md) を参照してください。
次の例は、ETL ジョブを実行するために被付与者に必要となるアクセス許可を示しています。この例で、*grantee-account-id* はジョブを実行するクライアントの `catalog-id`、*grantor-account-id* はリソースの所有者です。この例では、権限付与者のアカウントにあるすべてのカタログリソースに対するアクセス許可を付与します。付与されたリソースの範囲を制限するには、カタログ、データベース、テーブル、および接続の特定の ARN を指定できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetConnection",
"glue:GetDatabase",
"glue:GetTable",
"glue:GetPartition"
],
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Resource": [
"arn:aws:glue:us-east-1:111122223333:*"
]
}
]
}
```
------
**注記**
権限付与者のアカウントのテーブルで Amazon S3 の場所を指しており、この場所が権限付与者のアカウントにも含まれる場合、被付与者のアカウントで ETL ジョブを実行するために使用する IAM ロールには、権限付与者のアカウントからオブジェクトをリスト化し取得するための、アクセス許可が必要となります。
アカウント A のクライアントが ETL ジョブを作成して実行するアクセス許可をすでに付与されている場合、クロスアカウントアクセスのために ETL ジョブをセットアップする基本的な手順は次のとおりです。
1. クロスアカウントのデータアクセスを許可します (Amazon S3 クロスアカウントアクセスがセットアップ済みである場合は、このステップをスキップします)。
1. アカウント B の Amazon S3 バケットポリシーを更新して、アカウント A からのクロスアカウントアクセスを許可します。
1. アカウント A の IAM ポリシーを更新して、アカウント B のバケットへのアクセスを許可します。
1. Data Catalog へのクロスアカウントアクセスを許可します
1. アカウント B の Data Catalog にアタッチされたリソースポリシーを作成または更新して、アカウント A からのアクセスを許可します。
1. アカウント A の IAM ポリシーを更新して、アカウント B の Data Catalog へのアクセスを許可します。
## CloudTrail のクロスアカウントロギング
AWS Glue の抽出、変換、ロード (ETL) ジョブが、AWS Lake Formation クロスアカウント付与を介して共有された Data Catalog テーブルの基板となるデータにアクセスする際には、AWS CloudTrail ログ記録に追加的な動作が発生します。
この点を考えるために、テーブルを共有する AWS アカウントは所有者アカウントであり、テーブルの共有先アカウントは受け取りアカウントとします。受取人アカウントの ETL ジョブが、所有者アカウントのテーブルにあるデータにアクセスすると、受取人アカウントのログに追加された CloudTrail のデータアクセスイベントが所有者アカウントの CloudTrail ログにコピーされます。これは、所有者アカウントが、さまざまな受け取りアカウントによるデータアクセスを追跡できるようにするためです。デフォルトでは、CloudTrail イベントには、人間が読める形式のプリンシパル ID (プリンシパル ARN) は含まれていません。受け取りアカウントの管理者は、ログにプリンシパル ARN を含めるようにオプトインできます。
詳細については、*AWS Lake Formation デベロッパーガイド* の「[CloudTrail のクロスアカウントロギング](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-logging.html)」を参照してください。
**以下の資料も参照してください。**
[AWS Glue でのログ記録とモニタリング](logging-and-monitoring.md)
## クロスアカウントリソースの所有権および請求
例えば、AWS アカウント (アカウント A) のユーザーが、別のアカウント (アカウント B) にデータベースなどの新しいリソースを作成すると、このリソースは、リソースの作成先のアカウントであるアカウント B に所有されます。アカウント B の管理者は、新しいリソースにアクセスする完全なアクセス許可を自動的に取得します。これには、読み取り、書き込み、および第 3 のアカウントに対するアクセス許可の付与が含まれます。アカウント A のユーザーは、アカウント B によって付与された適切なアクセス許可を持っている場合のみ、前の手順で作成したリソースにアクセスできます。
ストレージコストおよび新しいリソースに直接関連するその他のコストは、リソース所有者であるアカウント B に請求されます。リソースを作成したユーザーからのリクエストのコストは、リクエスタのアカウントであるアカウント A に請求されます。
AWS Glue での請求と料金の詳細については、[How AWS Pricing Works](https://d0.awsstatic.com/whitepapers/aws_pricing_overview.pdf) を参照してください。
## クロスアカウントアクセスの制約事項
AWS Glue クロスアカウントアクセスには、次の制約事項があります。
+ リージョンが AWS Glue をサポートする前に、Amazon Athena または Amazon Redshift Spectrum を使用してデータベースとテーブルを作成し、リソースオーナーアカウントが Amazon Athena データカタログを AWS Glue に移行していない場合、AWS Glue へのクロスアカウントアクセスは許可されません。現在の移行ステータスは [GetCatalogImportStatus (get\$1catalog\$1import\$1status)](aws-glue-api-catalog-migration.md#aws-glue-api-catalog-migration-GetCatalogImportStatus) を使用して確認できます。Athena カタログを AWS Glue に移行する方法の詳細については、*Amazon Athena ユーザーガイド* の [AWS Glue Data Catalog ステップバイステップへのアップグレード](https://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html) を参照してください。
+ クロスアカウントアクセスは、データベース、テーブル、ユーザー定義関数、接続などの Data Catalog リソースで *のみ* サポートされています。
+ Athena `DataCatalog` リソースからデータカタログへのクロスアカウントアクセスには、カタログを Athena として登録する必要があります。手順については、*Amazon Athena ユーザーガイド*の [別のアカウントからの AWS Glue Data Catalog の登録](https://docs.aws.amazon.com/athena/latest/ug/data-sources-glue-cross-account.html) を参照してください。