データエンジニアリングの IAM

データパイプラインでは、人より先にサービスがデータへアクセスします。ジョブがを読み、がへ書き、が S3 からし、がそれらを作ります。 DEA では、それぞれの処理に「誰として動くか (どのロールか)」を正しく与え、長期のを使わずに認証させる設計が問われます。

Point

IAM = Identity and Access Management の略です。
STS = Security Token Service の略で、ロールを引き受けたときに一時的な認証情報を発行します。
サービスロールは「AWS のサービスが利用者の代わりに動くためのロール」です。
和訳
- Identity: 身元
- Assume: 引き受ける
- Weblio英和辞書「assume」

概要

は「誰が (プリンシパル)」「何に (リソース)」「何をしてよいか (アクション)」を決めるサービスです。データエンジニアリングでは、プリンシパルの多くが人ではなく AWS のサービスです。サービスには IAM ロールを渡し、ロールのでほかのサービスを呼ばせます。

見るポイント	代表的な判断
アクセスするのは人か、サービスか	サービスには IAM ロール、人にはやを使います。
認証情報をどこに置くか	をコードや環境変数に置かず、ロールの一時的な認証情報を使います。
誰がロールを使えるか	ロールので、引き受けてよいサービスやアカウントを決めます。
何ができるか	ロールの権限ポリシーで、必要なアクションとリソースだけを許可します。

主要技術

①IAM ユーザー・グループ・ロールの使い分け

アイデンティティ	認証情報	データエンジニアリングでの使い道
ユーザー	長期 (パスワード、)	原則として新規の作業者には作りません。AWS の外のツールがどうしてもキーを必要とする場合に限ります。
IAM グループ	なし (ユーザーのまとまり)	同じ職務のユーザーへまとめて権限を付けます。グループはプリンシパルではないため、ポリシーの `Principal` に書けません。
IAM ロール	一時的 ( が発行)	・・・などのサービス、別アカウント、した人が引き受けます。
	一時的 (許可セット経由)	複数アカウントにまたがる人のアクセスを一元管理します。

データエンジニアのチームに権限を与える場合、人ごとに IAM ユーザーを作ってグループに入れるより、IAM Identity Center の許可セットでロールを引き受けさせる構成が推奨されます。ただし試験では「同じ職務の複数ユーザーへ同じ権限を付けるにはグループ」という基本も問われます。

⚠️ 頻出: アクセスキーをスクリプト・Glue ジョブのパラメーター・環境変数に書く選択肢は誤りです。サービスにはロールを関連付けます。

②信頼ポリシーと権限ポリシー

ロールには2種類のポリシーがあります。

ポリシー	書く内容	例
(trust policy)	誰がこのロールを引き受けてよいか	`"Principal": {"Service": "glue.amazonaws.com"}`
権限ポリシー (permissions policy)	ロールを引き受けた後に何ができるか	`s3:GetObject` を特定ののプレフィックスに許可

信頼ポリシーにサービスが書かれていないと、権限ポリシーが正しくてもジョブは開始時に失敗します。逆に、信頼ポリシーが正しくても権限ポリシーに s3:GetObject がなければ、読み取りの段階で AccessDenied になります。どちらの段階で失敗したかで、直すポリシーが分かります。

別アカウントのロールを引き受ける場合は、相手のロールの信頼ポリシーに自分のアカウント (またはロール) を書き、自分側の権限ポリシーで sts:AssumeRole を許可します。第三者に引き受けさせる場合は外部 ID (sts:ExternalId) を条件に加え、混乱した代理 (confused deputy) を防ぎます。

③サービスごとのアクセス用ロール ⚠️ 頻出

サービス	ロールの付け方	注意点
(ジョブ、)	ジョブ・クローラーにロールを指定します。	のデータ、Data Catalog、 Logs、必要ならの権限を含めます。内の接続を使うならの作成権限も要ります。
	実行ロールを関数に関連付けます。	イベントソースマッピング (、、 Streams) で読む場合は、ソースの読み取り権限も実行ロールに必要です。
	バックエンドの AWS サービスを直接呼ぶ統合では、API Gateway が引き受けるロールを指定します。	Lambda を呼ぶ場合は、Lambda 側ので API Gateway からの呼び出しを許可する方法もあります。
/	名前付きプロファイルで `role_arn` と `source_profile` を指定し、ロールを引き受けます。	や CloudShell 上ではインスタンスプロファイルなどの認証情報を自動で使います。
	スタックにサービスロールを指定すると、CloudFormation はそのロールの権限でリソースを作ります。	操作する人には `iam:PassRole` と CloudFormation の権限だけを渡し、リソース作成の権限はサービスロールに集めます。
	クラスターや名前空間に IAM ロールを関連付け、・・で使います。	`COPY ... IAM_ROLE` に指定するロールに S3 の読み取り権限が必要です。
	サービスロールと、EC2 インスタンスプロファイル (クラスター内の処理が使うロール) を分けて持ちます。	S3 を読むのはインスタンスプロファイル側の権限です。
/	ステートマシンの実行ロール、MWAA の実行ロールを指定します。	呼び出す Glue ジョブや Lambda を起動する権限を含めます。

サービスにロールを渡すときは、渡す人に iam:PassRole が必要です。 iam:PassRole の対象を * にすると、強い権限のロールを任意のサービスに渡せてしまうため、渡してよいロールの ARN に絞ります。

④ポリシーの種類と評価の順序

ポリシー	付ける場所	役割
	ユーザー、グループ、ロール	主体側から許可します。
	、キー、関数、キューなど	リソース側から、どの主体に許可するかを書きます。別アカウントの主体も指定できます。
アクセス許可の境界 (permissions boundary)	ユーザー、ロール	アイデンティティベースポリシーで付けられる権限の上限です。
(サービスコントロールポリシー)	の、アカウント	アカウント内の主体が使える権限の上限です。
RCP (リソースコントロールポリシー)	Organizations の OU、アカウント	アカウント内のリソースへのアクセスの上限です。
セッションポリシー	ロールを引き受けるときに渡す	そのセッションだけ権限を狭めます。
ポリシー	VPC エンドポイント	エンドポイントを通るリクエストを制限します。

同じアカウント内では、アイデンティティベースポリシーとリソースベースポリシーのどちらかで許可されていればアクセスできます。一方、アカウントをまたぐ場合は、リソース側 (バケットポリシーなど) と呼び出し側 ( ポリシー) の両方で許可が必要です。KMS で暗号化したデータなら、キーポリシーの許可も加わります。

⚠️ 頻出: 「ジョブのロールに S3 の権限を付けたのに AccessDenied になる」場合は、バケットポリシーの Deny、SCP、KMS のキーポリシー、VPC エンドポイントポリシー、の権限を順に確かめます。

⑤IAM で作る・更新するものとエンドポイント

試験ガイドの「グループ、ロール、、サービスを作成・更新する」は、権限の更新を伴う作業全体を指します。

作業	押さえること
新しいパイプラインのロールを作る	でサービスを限定し、権限ポリシーはやテーブルの ARN に絞ります。
既存のロールに権限を足す	マネージドポリシーで足りなければカスタムポリシーを追加します (「認可の方式と」の章)。
複数のロールで共有する権限を更新する	カスタマー管理ポリシーにまとめて各ロールに付けます。編集すると新しい版が作られ (最大5つまで保存)、既定の版を前のものに戻せば、付けている全ロールの権限を切り戻せます。インラインポリシーには版がなく、AWS マネージドポリシーは利用者が編集できません。
エンドポイント経由に切り替える	エンドポイントポリシーとバケットポリシーの `aws:SourceVpce` 条件をそろえます (「データのネットワークセキュリティ」の章)。
ロールをで管理する	やでロールとポリシーを定義し、手作業の変更を減らします。

IAM の変更は全へ反映されるまで少し時間がかかることがあります。ロールを作った直後のジョブ実行が一時的に失敗する場合がある点も知っておきます。

試験対策

DEA では、処理を担うサービスごとに「どのロールに何の権限を付けるか」を判断します。まず実行主体 (、、、、) を特定し、そのサービスのロールを直す選択肢を選びます。

①判断マトリクス

問題文のキーワード	選ぶもの	理由
ジョブからを読みたい	Glue ジョブにロールを指定し、S3 の権限を付ける	ジョブはロールので動きます。
がから読めない	Lambda の実行ロールに Kinesis の読み取り権限	イベントソースマッピングは実行ロールの権限で読みます。
のが S3 で失敗する	クラスターに関連付けた IAM ロールの S3 権限	`IAM_ROLE` に指定したロールが S3 を読みます。
の実行者に強い権限を渡したくない	CloudFormation のサービスロール	リソース作成の権限をサービスロールに集めます。
開発者が任意のロールをサービスへ渡せてしまう	`iam:PassRole` の対象を特定のロール ARN に限定	権限昇格を防ぎます。
別アカウントのへ書き込みたい	相手のバケットポリシー + 自分のロールの IAM ポリシー	アカウントをまたぐ場合は両側の許可が必要です。
同じ職務の複数ユーザーに同じ権限	IAM グループ (または Identity Center の許可セット)	個別に付けると管理が崩れます。
外部ベンダーにロールを引き受けさせる	に外部 ID の条件	混乱した代理を防ぎます。

②よくある誤答

と権限ポリシーを取り違えること。「サービスがロールを引き受けられない」は信頼ポリシー、「引き受けた後の操作が拒否される」は権限ポリシーの問題です。
のクラスター内の処理がサービスロールの権限でを読むと考えること。読むのはインスタンスプロファイルのロールです。
明示的な Deny を、別のポリシーの Allow で上書きできると考えること。明示的な Deny は常に優先されます。
グループをポリシーの Principal に書けると考えること。書けるのはユーザー、ロール、アカウント、サービスなどです。