ロールとクロスアカウント｜基礎を学ぶ

このレッスンを終えると、「誰かにアクセスさせたい」という要件に対して、アクセスキーを渡す案とロールを引き受けさせる案を見分け、後者を選ぶ理由を説明できるようになります。

まず要件から

ある企業が、外部の分析ベンダーに本番アカウントの S3 バケットを読ませたいと考えています。ベンダーは自社の AWS アカウントを持っています。担当者は「ベンダー用の IAM ユーザーを作ってアクセスキーを発行し、メールで渡そう」と言っています。

この案は動きます。動きますが、SAA では確実に誤答になります。理由は次の3つです。第一に、鍵は長期の認証情報なので、漏れたら止めるまで有効であり続けます。第二に、誰がいつ使ったかを追う責任が自社に残ります。第三に、ベンダー側の担当者が交代しても鍵は変わりません。

正解は、本番アカウントにベンダーのアカウントを信頼する IAM ロールを作り、ベンダーに AssumeRole させることです。渡すのはロールの ARN だけで、認証情報は一切渡しません。

ロールを引き受けるとき何が起きているか

ロールには2種類のポリシーが付きます。ここが試験の中心です。

ポリシー	書く場所	決めること
信頼ポリシー	ロールの Trust relationship	誰がこの役を引き受けてよいか
許可ポリシー	ロールにアタッチ	引き受けた人が何をできるか

信頼ポリシーはこう書きます。

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a7f3-vendor-key" }
  }
}

ベンダー側は自社ユーザーに sts:AssumeRole の許可を与え、このロールの ARN を指定して引き受けます。返ってくるのは有効期限付きの一時認証情報で、期限が来れば自動的に使えなくなります。

片側だけでは通らない点に注意します。信頼ポリシーと、引き受ける側の許可ポリシーの両方が必要です。試験では片方しか設定していない選択肢が並びます。

ExternalId は何のためにあるか

第三者にロールを引き受けさせるときは、Condition に ExternalId を入れます。これは「混乱した代理人問題」への対策です。ベンダーが他社の面倒も見ている場合、あなたのロール ARN を知っているだけで別の顧客の操作としてアクセスできてしまう余地が生まれます。あなたが決めた ExternalId を一致条件にしておくと、ARN を知っているだけでは引き受けられなくなります。自社の別アカウント同士では不要で、第三者ベンダーのときに使うと覚えます。

用途ごとの選び方

要件文の言い回し	選ぶもの
EC2 上のアプリから S3 を読む	インスタンスプロファイル(EC2 にロールを付与)
Lambda から DynamoDB を書く	Lambda の実行ロール
別アカウントの管理者に作業させる	クロスアカウントロールと AssumeRole
外部ベンダーに読ませる	クロスアカウントロールと ExternalId
社内の既存 ID 基盤でログインさせる	IAM Identity Center もしくは SAML フェデレーション
モバイルアプリの利用者を認証する	Cognito ID プール経由でロールを引き受けさせる

どの行にも共通するのは、アクセスキーを配る行が1つも無いことです。SAA では「アクセスキーを発行して埋め込む」「環境変数に鍵を置く」といった選択肢は、動くとしても選びません。

よくある引っ掛け

ひとつめは、EC2 のアプリに鍵をファイルで置く案です。動きますが、ロールを付ければ鍵の配置も更新も不要になり、要件語の「運用の手間を最小に」を満たすのは後者です。

ふたつめは、ベンダーに IAM ユーザーを作って「定期的に鍵をローテーションする」案です。一見きちんとしていますが、ローテーションの手間が残る時点で一時認証情報に負けます。

まとめ

外部や別アカウントへのアクセスは、鍵の受け渡しではなくロールの引き受けで設計する
ロールには信頼ポリシー(誰が)と許可ポリシー(何を)の2枚があり、両方要る
引き受ける側にも sts:AssumeRole の許可が必要で、片側だけでは通らない
第三者ベンダーには ExternalId を条件に入れる
EC2 や Lambda からの AWS 呼び出しも、鍵ではなくロールで行う