# AWS Glue のアイデンティティベースポリシーの例
デフォルトでは、 ユーザーおよびロールには、AWS Glue リソースを作成または変更するアクセス許可は付与されていません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
AWS Glue で定義されるアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「*サービス認可リファレンス*」の「[AWS Glue のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html)」を参照してください。
**注記**
このセクションで取り上げる例は、すべて `us-west-2` リージョンを使用しています。このリージョンは、ご自身が使用する AWS リージョンに置き換えることが可能です。
**Topics**
+ [ポリシーに関するベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [特定の AWS Glue オブジェクトにのみ適用されるリソースレベルのアクセス許可](#glue-identity-based-policy-limitations)
+ [AWS Glue コンソールの使用](#security_iam_id-based-policy-examples-console)
+ [自分の権限の表示をユーザーに許可する](#security_iam_id-based-policy-examples-view-own-permissions)
+ [テーブルへの読み取り専用のアクセスを許可する](#security_iam_id-based-policy-examples-read-only-table-access)
+ [GetTables アクセス許可によるテーブルのフィルタリング](#security_iam_id-based-policy-examples-filter-tables)
+ [テーブルとすべてのパーティションへのフルアクセスを付与する](#security_iam_id-based-policy-examples-full-access-tables-partitions)
+ [名前のプレフィックスと明示的な拒否によりアクセスを制御する](#security_iam_id-based-policy-examples-deny-by-name-prefix)
+ [タグを使用してアクセスを許可する](#tags-control-access-example-triggers-allow)
+ [タグを使用してアクセスを拒否する](#tags-control-access-example-triggers-deny)
+ [リストとバッチ API オペレーションでタグを使用する](#tags-control-access-example-triggers-list-batch)
+ [条件キーまたはコンテキストキーを使用して設定を制御する](#glue-identity-based-policy-condition-keys)
+ [ID によるデータプレビューセッションの作成を拒否する](#deny-data-preview-sessions-per-identity)
## ポリシーに関するベストプラクティス
アイデンティティベースのポリシーは、ユーザーのアカウントで誰が AWS Glue リソースを作成し、これにアクセスし、これを削除できるかを決定します。これらのアクションでは、AWS アカウント に費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ **AWS マネージドポリシーの使用を開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースのためにアクセス許可を付与する *AWS マネージドポリシー*を使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、CloudFormation などの特定の AWS のサービス を介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## 特定の AWS Glue オブジェクトにのみ適用されるリソースレベルのアクセス許可
AWS Glue の特定のオブジェクトに限り、詳細なコントロールを定義できます。したがって、`Resource` ステートメントの Amazon リソースネーム (ARN) を許可する API オペレーションと ARN を許可しない API オペレーションが混在しないようにクライアントの IAM ポリシーを記述する必要があります。
たとえば、次の IAM ポリシーは `GetClassifier` と `GetJobRun` の API オペレーションを許可します。AWS Glue は分類子とジョブ実行の ARN を許可しないため、このポリシーでは `Resource` を `*` として定義します。ARN は `GetDatabase` や `GetTable` などの特定の API オペレーションに対して許可されるため、ARN はポリシーの後半で指定できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetClassifier*",
"glue:GetJobRun*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"glue:Get*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/default",
"arn:aws:glue:us-east-1:111122223333:table/default/e*1*",
"arn:aws:glue:us-east-1:111122223333:connection/connection2"
]
}
]
}
```
------
ARN を許可する AWS Glue オブジェクトのリストについては、「[AWS Glue リソース ARN の指定](glue-specifying-resource-arns.md)」を参照してください。
## AWS Glue コンソールの使用
AWS Glue コンソールにアクセスするには、最小限のアクセス許可が必要になります。これらのアクセス許可により、AWS アカウント にある AWS Glue リソースの詳細を一覧で表示できます。最小限必要なアクセス許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) ではコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソール権限を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスを許可します。
ユーザーとロールが引き続き AWS Glue コンソールを使用できるようにするには、これらのエンティティに AWS Glue `ConsoleAccess` または `ReadOnly` AWS マネージドポリシーもアタッチします。詳細については、「*IAM ユーザーガイド*」の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
ユーザーが AWS Glue コンソールを使用するには、AWS アカウントで AWS Glue リソースの使用を許可する最小限のアクセス許可セットが必要です。これらの AWS Glue アクセス許可に加えて、コンソールでは次のサービスからのアクセス許可が必要になります。
+ ログを表示するための Amazon CloudWatch Logs のアクセス許可。
+ ロールをリスト化して渡すための AWS Identity and Access Management (IAM) のアクセス許可。
+ スタックを操作する AWS CloudFormation のアクセス許可。
+ Amazon Elastic Compute Cloud (Amazon EC2) が VPC、サブネット、セキュリティグループ、インスタンス、およびその他のオブジェクトをリストするためのアクセス許可。
+ Amazon Simple Storage Service (Amazon S3) が バケットとオブジェクトをリストし、スクリプトを取得および保存するためのアクセス許可。
+ クラスターでの作業に必要な Amazon Redshift のアクセス許可。
+ インスタンスをリスト化するための Amazon Relational Database Service (Amazon RDS) のアクセス許可。
ユーザーが AWS Glue コンソールを表示して操作するために必要なアクセス許可の詳細については、「[ステップ 3: AWS Glue にアクセスするユーザーまたはグループにポリシーをアタッチする](attach-policy-iam-user.md)」を参照してください。
これらの最小限必要なアクセス許可よりも制限された IAM ポリシーを作成している場合、その IAM ポリシーを使用するユーザーに対してコンソールは意図したとおりには機能しません。これらのユーザーが引き続き AWS Glue コンソールを使用できるようにするには、[AWS Glue の AWS マネージド (事前定義) ポリシー](security-iam-awsmanpol.md#access-policy-examples-aws-managed) で述べたとおり `AWSGlueConsoleFullAccess` マネージドポリシーもアタッチします。
## 自分の権限の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI か AWS API を使用してプログラム的に、このアクションを完了するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## テーブルへの読み取り専用のアクセスを許可する
次のポリシーは、データベース `db1` の `books` テーブルに対する読み取り専用アクセス許可を付与します。Amazon リソースネーム (ARN) の詳細については、「[データカタログの ARN](glue-specifying-resource-arns.md#data-catalog-resource-arns)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesActionOnBooks",
"Effect": "Allow",
"Action": [
"glue:GetTables",
"glue:GetTable"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
このポリシーでは `db1` という名前のデータベースにある `books` という名前のテーブルへの読み取り専用許可を付与します。テーブルへの `Get` アクセスを許可するには、カタログとデータベースリソースへのアクセス許可も必要になります。
次のポリシーは、データベース `db1` にテーブル `tb1` を作成するための必要最小限のアクセス許可を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:CreateTable"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:table/db1/tbl1",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:catalog"
]
}
]
}
```
------
## GetTables アクセス許可によるテーブルのフィルタリング
データベース `db1` 内に、`customers`、`stores`、および `store_sales` の 3 つのテーブルがあるとします。次のポリシーは、`GetTables` アクセス許可を `stores` および `store_sales` に付与しますが、`customers` には付与しません。このポリシーで `GetTables` を呼び出すと、結果には 2 つの認可されたテーブルのみが含まれます (`customers` テーブルは返されません)。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesExample",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/store_sales",
"arn:aws:glue:us-east-1:111122223333:table/db1/stores"
]
}
]
}
```
------
`store*` を使用して `store` で始まる任意のテーブル名に一致させることで、前述のポリシーを簡素化できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesExample2",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/store*"
]
}
]
}
```
------
同様に、`/db1/*` を使用して `db1` 内のすべてのテーブルと一致させることで、次のポリシーによって `db1` 内のすべてのテーブルへのアクセスが `GetTables` に付与されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesReturnAll",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/*"
]
}
]
}
```
------
テーブルの ARN を指定しない場合、`GetTables` の呼び出しは成功しますが、空のリストが返されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesEmptyResults",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
ポリシーでデータベースの ARN が欠落している場合は、 `GetTables` の呼び出しが失敗して `AccessDeniedException` が発生します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesAccessDeny",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:table/db1/*"
]
}
]
}
```
------
## テーブルとすべてのパーティションへのフルアクセスを付与する
次のポリシーは、データベース `db1` で `books` という名前のテーブルのすべての許可を付与します。これには、テーブル自体、テーブルのアーカイブされたバージョン、テーブルのすべてのパーティションでの読み込みおよび書き込みアクセス許可が含まれます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessOnTable",
"Effect": "Allow",
"Action": [
"glue:CreateTable",
"glue:GetTable",
"glue:GetTables",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:BatchDeleteTable",
"glue:GetTableVersion",
"glue:GetTableVersions",
"glue:DeleteTableVersion",
"glue:BatchDeleteTableVersion",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetPartition",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:UpdatePartition",
"glue:DeletePartition",
"glue:BatchDeletePartition"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
前述のポリシーは、実際に次のように簡素化できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessOnTable",
"Effect": "Allow",
"Action": [
"glue:*Table*",
"glue:*Partition*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
きめ細かなアクセスコントロールの最小粒度はテーブルレベルであることに注意してください。つまり、テーブル内の一部のパーティションへのアクセス許可をユーザーに付与できませんが、他のパーティションには付与できます。また、一部のテーブルの列には付与できませんが、他のテーブルの列には付与できます。ユーザーはすべてのテーブルへのアクセス許可を持っているか、どのアクセス許可も持っていません。
## 名前のプレフィックスと明示的な拒否によりアクセスを制御する
ここでは、AWS Glue Data Catalog 内にあるデータベースとテーブルが、名前のプレフィックスを使用して整理されていると想定します。開発ステージのデータベースには、名前のプレフィックス `dev-` があります。実稼働環境のデータベースには、名前のプレフィックス `prod-` があります。次のポリシーを使用して、開発者に `dev-` プレフィックスがある、すべてのデータベース、テーブル、UDF などへのフルアクセスを付与できます。ただし、`prod-` プレフィックスを使用して、すべての読み取り専用アクセス許可を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DevAndProdFullAccess",
"Effect": "Allow",
"Action": [
"glue:*Database*",
"glue:*Table*",
"glue:*Partition*",
"glue:*UserDefinedFunction*",
"glue:*Connection*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/dev-*",
"arn:aws:glue:us-east-1:111122223333:database/prod-*",
"arn:aws:glue:us-east-1:111122223333:table/dev-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/dev-*",
"arn:aws:glue:us-east-1:111122223333:table/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/dev-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/dev-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:connection/dev-*",
"arn:aws:glue:us-east-1:111122223333:connection/prod-*"
]
},
{
"Sid": "ProdWriteDeny",
"Effect": "Deny",
"Action": [
"glue:*Create*",
"glue:*Update*",
"glue:*Delete*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:database/prod-*",
"arn:aws:glue:us-east-1:111122223333:table/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:connection/prod-*"
]
}
]
}
```
------
前述のポリシーの 2 番目のステートメントは、明示的な `deny` を使用します。明示的な `deny` を使用して、プリンシパルに付与された任意の `allow` アクセス許可を上書きできます。これにより、重要なリソースへのアクセスをロックダウンして、別のポリシーによって重要なリソースへのアクセスが誤って付与されることを防ぐことができます。
前述の例では、最初のステートメントによって `prod-` リソースへのフルアクセスが付与されていますが、2 番目のステートメントによって明示的にリソースへの書き込みアクセスが取り消され、`prod-` リソースへの読み取りアクセスのみが残されています。
## タグを使用してアクセスを許可する
たとえば、お使いのアカウントの `Tom` という名前の特定のユーザーに対して、トリガー `t2` へのアクセスを制限するとします。その他すべてのユーザー (`Sam` など) は、トリガー `t1` にアクセスできます。トリガー `t1` と `t2` には、以下のプロパティがあります。
```
aws glue get-triggers
{
"Triggers": [
{
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t1",
"Actions": [
{
"JobName": "j1"
}
],
"Schedule": "cron(0 0/1 * * ? *)"
},
{
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t2",
"Actions": [
{
"JobName": "j1"
}
],
"Schedule": "cron(0 0/1 * * ? *)"
}
]
}
```
AWS Glue 管理者は、トリガー `t2`にタグ値 `Tom` (`aws:ResourceTag/Name": "Tom"`) を添付しました。AWS Glue 管理者は、タグに基づく条件ステートメントを使用して Tom に IAM ポリシーも提供しました。その結果、Tom はタグ値 `Tom` を持つリソースを対象とした AWS Glue オペレーションのみ使用できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "glue:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Name": "Tom"
}
}
}
]
}
```
------
Tom がトリガー `t1` にアクセスしようとすると、アクセス拒否メッセージが返されます。一方、トリガー `t2` は正常に取得できます。
```
aws glue get-trigger --name t1
An error occurred (AccessDeniedException) when calling the GetTrigger operation: User: Tom is not authorized to perform: glue:GetTrigger on resource: arn:aws:glue:us-east-1:123456789012:trigger/t1
aws glue get-trigger --name t2
{
"Trigger": {
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t2",
"Actions": [
{
"JobName": "j1"
}
],
"Schedule": "cron(0 0/1 * * ? *)"
}
}
```
この API オペレーションではタグのフィルタリングがサポートされていないため、Tom は、複数の `GetTriggers` API オペレーションを使用してトリガーを一覧表示することができません。
Tom に `GetTriggers` へのアクセス権を与えるには、AWS Glue 管理者はアクセス許可を 2 つのセクションに分割するポリシーを作成します。1 つのセクションでは、`GetTriggers` API オペレーションを使用してすべてのトリガーにアクセスすることを Tom に許可します。2 番目のセクションでは、`Tom` という値でタグ付けされている API オペレーションにアクセスすることを Tom に許可します。このポリシーでは、Tom はトリガー `t2` に対する `GetTriggers` と `GetTrigger` の両方のアクセスが許可されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "glue:GetTriggers",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "glue:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Name": "Tom"
}
}
}
]
}
```
------
## タグを使用してアクセスを拒否する
リソースポリシーのもう 1 つの方法は、リソースへのアクセスを明示的に拒否することです。
**重要**
明示的な拒否ポリシーは、`GetTriggers` など複数の API オペレーションに使用することはできません。
次のポリシー例では、すべての AWS Glue ジョブ操作が許可されています。ただし、2 番目の `Effect` ステートメントでは、`Team` キーと `Special` 値がタグ付けされたジョブへのアクセスが*明示的に*拒否されています。
管理者が次のポリシーをアイデンティティにアタッチすると、このアイデンティティは、`Team` キーと `Special` 値がタグ付けされたジョブを*除く*すべてのジョブにアクセスできます。
## リストとバッチ API オペレーションでタグを使用する
リソースポリシーを書き込む 3 つ目の方法としては、`List` API オペレーションを使用してリソースにアクセスし、タグ値のリソースを一覧表示することを許可します。次に、対応する `Batch` API オペレーションを使用して、特定のリソースの詳細にアクセスすることを許可します。この方法では、管理者は複数形の `GetCrawlers`、`GetDevEndpoints`、`GetJobs`、または `GetTriggers` API オペレーションへのアクセスを許可する必要がありません。代わりに、次の API オペレーションを使用してリソースを一覧表示することを許可できます。
+ `ListCrawlers`
+ `ListDevEndpoints`
+ `ListJobs`
+ `ListTriggers`
また、以下の API オペレーションを使用して、個々のリソースに関する詳細を取得することを許可できます。
+ `BatchGetCrawlers`
+ `BatchGetDevEndpoints`
+ `BatchGetJobs`
+ `BatchGetTriggers`
管理者は、この方法を使用して、次の操作を実行できます。
1. クローラ、開発エンドポイント、ジョブ、およびトリガーにタグを追加します。
1. `GetCrawlers`、`GetDevEndponts`、`GetJobs`、および `GetTriggers` などの `Get` API オペレーションへのユーザーアクセスを拒否します。
1. アクセスできるタグ付きリソースをユーザーが見つけられるようにするには、`ListCrawlers`、`ListDevEndponts`、`ListJobs`、および `ListTriggers` などの `List` API オペレーションへのユーザーアクセスを許可します。
1. `TagResource` や `UntagResource` などの AWS Glue タグ付け API へのユーザーアクセスを拒否します。
1. `BatchGetCrawlers`、`BatchGetDevEndponts`、`BatchGetJobs`、および `BatchGetTriggers` などの `BatchGet` API オペレーションを使用して、リソースの詳細に対するアクセスをユーザーに許可します。
たとえば、`ListCrawlers` オペレーションを呼び出すときに、ユーザー名と一致するタグ値を指定します。結果として、指定したタグ値と一致するクローラのリストが返されます。指定されたタグを持つ各クローラーの詳細を取得するには、`BatchGetCrawlers` に名前のリストを提供します。
例えば、Tom に、`Tom` でタグ付けされたトリガーの詳細の取得のみを許可する場合、管理者は、`Tom` のトリガーにタグを追加し、すべてのユーザーに対して `GetTriggers` API オペレーションへのアクセスを拒否し、`ListTriggers` および `BatchGetTriggers` へのすべてのユーザーのアクセスを許可することができます。
次に示すのは、AWS Glue 管理者が Tom に付与するリソースポリシーです。ポリシーの最初のセクションでは、AWS Glue API オペレーションは `GetTriggers` に対して拒否されています。ポリシーの 2 番目のセクションでは、`ListTriggers` がすべてのリソースに対して許可されています。ただし、3 番目のセクションでは、`Tom` でタグ付けされたリソースは `BatchGetTriggers` アクセスでアクセスが許可されています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "glue:GetTriggers",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"glue:ListTriggers"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"glue:BatchGetTriggers"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Name": "Tom"
}
}
}
]
}
```
------
前の例と同じトリガーを使用して、Tom はトリガー `t2` にはアクセスできますが、トリガー `t1` にはアクセスできません。次の例は、Tom が `BatchGetTriggers` で `t1` と `t2` にアクセスしようとしたときの結果を示しています。
```
aws glue batch-get-triggers --trigger-names t2
{
"Triggers": {
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t2",
"Actions": [
{
"JobName": "j2"
}
],
"Schedule": "cron(0 0/1 * * ? *)"
}
}
aws glue batch-get-triggers --trigger-names t1
An error occurred (AccessDeniedException) when calling the BatchGetTriggers operation: No access to any requested resource.
```
次の例は、Tom が同じ `BatchGetTriggers` 呼び出しでトリガー `t2` とトリガー `t3` (存在しない) の両方にアクセスしようとしたときの結果を示しています。Tom は `t2` をトリガーするアクセス権を持っており、それが存在するため、`t2` のみが返されることに注意してください。Tom はトリガー `t3` へのアクセスを許可されていますが、トリガー `t3` は存在しないため、`t3` はレスポンスの `"TriggersNotFound": []` のリストで返されます。
```
aws glue batch-get-triggers --trigger-names t2 t3
{
"Triggers": {
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t2",
"Actions": [
{
"JobName": "j2"
}
],
"TriggersNotFound": ["t3"],
"Schedule": "cron(0 0/1 * * ? *)"
}
}
```
## 条件キーまたはコンテキストキーを使用して設定を制御する
ジョブを作成および更新する権限を付与する場合は、条件キーまたはコンテキストキーを使用できます。ここでは、キーについて説明します。
+ [条件キーを使って設定を制御するポリシーを制御する](#glue-identity-based-policy-condition-key-vpc)
+ [条件キーを使って設定を制御するポリシーを制御する](#glue-identity-based-policy-context-key-glue)
### 条件キーを使って設定を制御するポリシーを制御する
AWS Glue は `glue:VpcIds`、`glue:SubnetIds`、`glue:SecurityGroupIds` の3 つの IAM 条件キーを提供します。ジョブを作成および更新する権限を付与する場合は、IAM ポリシーで条件キーを使用できます。この設定を使用して、目的の VPC 環境外で実行するジョブまたはセッションが作成されない (または更新されない) ようにすることができます。VPC 設定の情報は、`CreateJob` リクエストから直接入力されるのではなく、AWS Glue 接続を指すジョブの「接続」フィールドから推測されます。
**使用例**
希望する VpcId「vpc-id1234」、SubnetIds、SecurityGroupIds を持つ「traffic-monitored-connection」という名前の AWS Glue ネットワーク型接続を作成します。
IAM ポリシーのアクション `CreateJob` および `UpdateJob` の条件キーを指定します。
```
{
"Effect": "Allow",
"Action": [
"glue:CreateJob",
"glue:UpdateJob"
],
"Resource": [
"*"
],
"Condition": {
"ForAnyValue:StringLike": {
"glue:VpcIds": [
"vpc-id1234"
]
}
}
}
```
同様の IAM ポリシーを作成して、接続情報を指定しない AWS Glue ジョブの作成を禁止する事ができます。
**VPC でのセッションの制限**
指定した VPC 内で実行するように作成済みセッションを強制するには、glue:vpc-id が vpc-<123> と等しくないという条件付きで `glue:CreateSession` アクションに `Deny` effect を追加することで、ロールのアクセス許可を制限します。例えば、次のようになります。
```
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Condition": {
"StringNotEquals" : {"glue:VpcIds" : ["vpc-123"]}
}
```
また、`glue:vpc-id` が NULL であるという条件付きで `glue:CreateSession` アクションに `Deny` 効果を追加しても、VPC 内で実行するように作成済みセッションを強制できます。例えば、次のようになります。
```
{
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Condition": {
"Null": {"glue:VpcIds": true}
}
},
{
"Effect": "Allow",
"Action": [
"glue:CreateSession"
],
"Resource": ["*"]
}
```
### 条件キーを使って設定を制御するポリシーを制御する
AWS Glue は、`glue:CredentialIssuingService= glue.amazonaws.com` でジョブや開発者のエンドポイントから利用できるように、各ロールセッションにコンテキストキー(AWS Glue)を提供します。これにより、AWS Glue スクリプトが実行するアクションに対し、セキュリティ制御を実装できます。AWS Glue は、別のコンテキストキー (`glue:RoleAssumedBy=glue.amazonaws.com`) を各ロールセッションに提供し、そこで AWS Glue が顧客に代わって別のサービス AWS を (ジョブ/デバイスのエンドポイントではなく AWS Glue サービスにより直接) 呼び出します。
**使用例**
IAM ポリシーで条件付きアクセス許可を指定し、これを AWS Glue ジョブが使用するロールにアタッチします。これで、特定のアクションが、ロールセッションが AWS Glue ジョブランタイム環境で使用されているかどうかに基づいて、許可/拒否されます。
```
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"glue:CredentialIssuingService": "glue.amazonaws.com"
}
}
}
```
## ID によるデータプレビューセッションの作成を拒否する
このセクションには、ID によるデータプレビューセッションの作成を拒否するために使用される IAM ポリシーの例が含まれています。このポリシーを ID にアタッチします。ID は、データプレビューセッションの実行中に使用するロールとは別のものです。
```
{
"Sid": "DatapreviewDeny",
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Resource": [
"arn:aws:glue:*:*:session/glue-studio-datapreview*"
]
}
```