ホテルのセキュリティで理解する2つのポリシーの違い
「誰が」「どんな条件で」
ロールを引き受けられるか？
→ ホテルの
チェックイン受付
と同じ！
「身分証明 + MFA認証」をクリアして初めて鍵がもらえる
ロールを引き受けた
「後」に何ができるか？
→ ホテルの
部屋の鍵
と同じ！
どの施設（部屋・プール・ジム）にアクセスできるかを決める
チェックイン受付
💡
ポイント：
チェックインを通過しないと、どんな高級なルームキーも意味がない！
逆に、チェックインしても、鍵がなければどこにも入れない！
「このロールを使いたいです！」とSTSに申請
「このユーザーは許可されている？条件は満たしている？」
「MFAコードを入力してください」→ 本人確認完了
STSから一時的なアクセスキー・シークレットキー・トークンを受け取る
「S3を読みたい」「EC2を起動したい」などの操作を実行
「この操作は許可されている？」→ 許可なら実行、拒否ならエラー
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { // 誰が引き受けられるか "AWS": "arn:aws:iam::123456789012:user/DevUser" }, "Action": "sts:AssumeRole", "Condition": { // MFA必須の条件 "Bool": { "aws:MultiFactorAuthPresent": "true" } } }] }
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ // 何ができるか "s3:GetObject", "s3:PutObject" ], "Resource": [ // どのリソースに対して "arn:aws:s3:::my-bucket/*" ] }] }
MFAは「本人確認」の一部です。ホテルで言えば、チェックイン時に 「予約確認書 + 身分証明書 + ワンタイムコード」 を求めるようなもの。
ロールを引き受ける
前
に認証を強化するため、
信頼ポリシー
の
Condition
ブロックで設定します。
"aws:MultiFactorAuthPresent": "true"
別のAWSアカウントからリソースにアクセスする
EC2インスタンスがS3にファイルをアップロード
MFA認証後のみ本番環境を操作可能
Lambda関数がDynamoDBにデータを書き込む
A: 信頼ポリシーが先 です。まずロールを引き受けられるかチェックし、引き受けた後に権限ポリシーで各操作の可否が判定されます。ホテルで言えば、チェックインしてからルームキーが使えるのと同じです。
A: 技術的には可能ですが、 一般的ではありません 。MFAは「誰がロールを使えるか」という認証の問題なので、信頼ポリシーで設定するのがベストプラクティスです。
A: はい！ 権限ポリシーは複数アタッチ可能です。一方、信頼ポリシーはロールに1つだけです（ただし、その中に複数のStatementを書けます）。
A: はい！ サービスロールでも信頼ポリシーで「どのサービスがこのロールを使えるか」を定義し、権限ポリシーで「そのサービスが何をできるか」を定義します。
IAMロールの2つのポリシーは、 「入口のセキュリティ」と「中の権限」 という別々の役割を持っています。
ロール引き受けの
「門番」
誰が・どんな条件で入れるか
（MFAもここで設定！）
ロール使用時の
「アクセスカード」
どのリソースに・何ができるか
（実際の操作権限）
ホテルで覚えよう！
信頼 = チェックイン
権限 = ルームキー
Created by SSuzuki1063
AWS SAP Learning Resources