ポリシーに関するベストプラクティスリソースレベルの認可の制限事項コンソールを使用する自分の権限の表示をユーザーに許可する読み取り専用のテーブルアクセステーブルをフィルタリングフルテーブルアクセス拒否の名前のプレフィックスタグを使用したアクセスコントロールの例タグを使用してアクセスを拒否するリストとバッチ API オペレーションでタグを使用する条件キーを使って設定を制御するポリシーを作成する ID によるデータプレビューセッションの作成を拒否する

AWS Glue のアイデンティティベースポリシーの例

デフォルトでは、ユーザーおよびロールには、AWS Glue リソースを作成または変更するアクセス許可は付与されていません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。

これらサンプルの JSON ポリシードキュメントを使用して、IAM アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド」の「IAM ポリシーを作成する (コンソール)」を参照してください。

AWS Glue で定義されるアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「サービス認可リファレンス」の「AWS Glue のアクション、リソース、および条件キー」を参照してください。

注記

このセクションで取り上げる例は、すべて us-west-2 リージョンを使用しています。このリージョンは、ご自身が使用する AWS リージョンに置き換えることが可能です。

トピック

ポリシーに関するベストプラクティス
特定の AWS Glue オブジェクトにのみ適用されるリソースレベルのアクセス許可
AWS Glue コンソールの使用
自分の権限の表示をユーザーに許可する
テーブルへの読み取り専用のアクセスを許可する
GetTables アクセス許可によるテーブルのフィルタリング
テーブルとすべてのパーティションへのフルアクセスを付与する
名前のプレフィックスと明示的な拒否によりアクセスを制御する
タグを使用してアクセスを許可する
タグを使用してアクセスを拒否する
リストとバッチ API オペレーションでタグを使用する
条件キーまたはコンテキストキーを使用して設定を制御する
ID によるデータプレビューセッションの作成を拒否する

ポリシーに関するベストプラクティス

アイデンティティベースのポリシーは、ユーザーのアカウントで誰が AWS Glue リソースを作成し、これにアクセスし、これを削除できるかを決定します。これらのアクションを実行すると、AWS アカウントに料金が発生する可能性があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:

AWS マネージドポリシーの使用を開始し、最小特権のアクセス許可に移行する – ユーザーとワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースのためにアクセス許可を付与する AWS マネージドポリシーを使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、IAM ユーザーガイド の AWS マネージドポリシーまたはジョブ機能の AWS マネージドポリシーを参照してください。
最小特権を適用する – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、IAM ユーザーガイド の IAM でのポリシーとアクセス許可を参照してください。
IAM ポリシーで条件を使用してアクセスをさらに制限する - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。例えば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、CloudFormation などの特定の AWS のサービスを介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、IAM ユーザーガイド の IAM JSON ポリシー要素:条件を参照してください。
IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス権限を確保する - IAM Access Analyzer は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、IAM ユーザーガイド の IAM Access Analyzer でポリシーを検証するを参照してください。
多要素認証 (MFA) を要求する – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、IAM ユーザーガイド の MFA を使用した安全な API アクセスを参照してください。

IAM でのベストプラクティスの詳細については、IAM ユーザーガイド の IAM でのセキュリティのベストプラクティスを参照してください。

特定の AWS Glue オブジェクトにのみ適用されるリソースレベルのアクセス許可

AWS Glue の特定のオブジェクトに限り、詳細なコントロールを定義できます。したがって、Resource ステートメントの Amazon リソースネーム (ARN) を許可する API オペレーションと ARN を許可しない API オペレーションが混在しないようにクライアントの IAM ポリシーを記述する必要があります。

たとえば、次の IAM ポリシーは GetClassifier と GetJobRun の API オペレーションを許可します。Resource は分類子とジョブ実行の ARN を許可しないため、このポリシーでは * を AWS Glue として定義します。ARN は GetDatabase や GetTable などの特定の API オペレーションに対して許可されるため、ARN はポリシーの後半で指定できます。

ARN を許可する AWS Glue オブジェクトのリストについては、「AWS Glue リソース ARN の指定」を参照してください。

AWS Glue コンソールの使用

AWS Glue コンソールにアクセスするには、最小限のアクセス許可が必要になります。これらのアクセス許可により、AWS アカウントにある AWS Glue リソースの詳細を一覧で表示できます。最小限必要なアクセス許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) ではコンソールが意図したとおりに機能しません。

AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソール権限を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスを許可します。

ユーザーとロールが引き続き AWS Glue コンソールを使用できるようにするには、これらのエンティティに AWS Glue ConsoleAccess または ReadOnly AWS マネージドポリシーもアタッチします。詳細については、「IAM ユーザーガイド」の「ユーザーへのアクセス許可の追加」を参照してください。

ユーザーが 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 にアクセスするユーザーまたはグループにポリシーをアタッチする」を参照してください。

これらの最小限必要なアクセス許可よりも制限された IAM ポリシーを作成している場合、その IAM ポリシーを使用するユーザーに対してコンソールは意図したとおりには機能しません。これらのユーザーが引き続き AWS Glue コンソールを使用できるようにするには、AWS Glue の AWS マネージド (事前定義) ポリシーで述べたとおり 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": "*"
        }
    ]
}

テーブルへの読み取り専用のアクセスを許可する

次のポリシーは、データベース books の db1 テーブルに対する読み取り専用アクセス許可を付与します。Amazon リソースネーム (ARN) の詳細については、「データカタログの ARN」を参照してください。

このポリシーでは db1 という名前のデータベースにある books という名前のテーブルへの読み取り専用許可を付与します。テーブルへの Get アクセスを許可するには、カタログとデータベースリソースへのアクセス許可も必要になります。

次のポリシーは、データベース tb1 にテーブル db1 を作成するための必要最小限のアクセス許可を付与します。

GetTables アクセス許可によるテーブルのフィルタリング

データベース db1 内に、customers、stores、および store_sales の 3 つのテーブルがあるとします。次のポリシーは、GetTables アクセス許可を stores および store_sales に付与しますが、customers には付与しません。このポリシーで GetTables を呼び出すと、結果には 2 つの認可されたテーブルのみが含まれます (customers テーブルは返されません)。

store* を使用して store で始まる任意のテーブル名に一致させることで、前述のポリシーを簡素化できます。

同様に、/db1/* を使用して db1 内のすべてのテーブルと一致させることで、次のポリシーによって db1 内のすべてのテーブルへのアクセスが GetTables に付与されます。

テーブルの ARN を指定しない場合、GetTables の呼び出しは成功しますが、空のリストが返されます。

ポリシーでデータベースの ARN が欠落している場合は、 GetTables の呼び出しが失敗して AccessDeniedException が発生します。

テーブルとすべてのパーティションへのフルアクセスを付与する

次のポリシーは、データベース db1 で books という名前のテーブルのすべての許可を付与します。これには、テーブル自体、テーブルのアーカイブされたバージョン、テーブルのすべてのパーティションでの読み込みおよび書き込みアクセス許可が含まれます。

前述のポリシーは、実際に次のように簡素化できます。

きめ細かなアクセスコントロールの最小粒度はテーブルレベルであることに注意してください。つまり、テーブル内の一部のパーティションへのアクセス許可をユーザーに付与できませんが、他のパーティションには付与できます。また、一部のテーブルの列には付与できませんが、他のテーブルの列には付与できます。ユーザーはすべてのテーブルへのアクセス許可を持っているか、どのアクセス許可も持っていません。

名前のプレフィックスと明示的な拒否によりアクセスを制御する

ここでは、AWS Glue Data Catalog 内にあるデータベースとテーブルが、名前のプレフィックスを使用して整理されていると想定します。開発ステージのデータベースには、名前のプレフィックス dev- があります。実稼働環境のデータベースには、名前のプレフィックス prod- があります。次のポリシーを使用して、開発者に dev- プレフィックスがある、すべてのデータベース、テーブル、UDF などへのフルアクセスを付与できます。ただし、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 オペレーションのみ使用できます。

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 の両方のアクセスが許可されます。

タグを使用してアクセスを拒否する

リソースポリシーのもう 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

管理者は、この方法を使用して、次の操作を実行できます。

クローラ、開発エンドポイント、ジョブ、およびトリガーにタグを追加します。
GetCrawlers、GetDevEndponts、GetJobs、および GetTriggers などの Get API オペレーションへのユーザーアクセスを拒否します。
アクセスできるタグ付きリソースをユーザーが見つけられるようにするには、ListCrawlers、ListDevEndponts、ListJobs、および ListTriggers などの List API オペレーションへのユーザーアクセスを許可します。
TagResource や UntagResource などの AWS Glue タグ付け API へのユーザーアクセスを拒否します。
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 アクセスでアクセスが許可されています。

前の例と同じトリガーを使用して、Tom はトリガー t2 にはアクセスできますが、トリガー t1 にはアクセスできません。次の例は、Tom が t1 で t2 と BatchGetTriggers にアクセスしようとしたときの結果を示しています。


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 * * ? *)"
    }
}

条件キーまたはコンテキストキーを使用して設定を制御する

ジョブを作成および更新する権限を付与する場合は、条件キーまたはコンテキストキーを使用できます。ここでは、キーについて説明します。

条件キーを使って設定を制御するポリシーを制御する
条件キーを使って設定を制御するポリシーを制御する

条件キーを使って設定を制御するポリシーを制御する

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*"
      ]
 }

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

AWS Glue のアクセスコントロールポリシーの例

リソースベースのポリシーの例