← AWSサービスの内部原理 コース
58. ロールは借りる帽子である — 信頼ポリシーと許可ポリシーの2枚で1つ
IAMロールが「パスワードを持たないのに、なぜAWSにアクセスできるのか」を、誰かがロールをかぶってから権限を得るまでの流れを図で追っていきます。
① ロールはパスワードを持たない
IAMユーザー特定の1人に結びつき、長期の資格情報(パスワード/アクセスキー)を持つ
IAMロール「必要な人なら誰でも」引き受けられ、長期の資格情報を一切持たない
パスワードもアクセスキーもない一時認証情報が発行role session の間だけ有効な一時的セキュリティ認証情報
- 公式の言い回し — 「a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.」
- 基礎への接続: OSの setuid と同型。setuid ビットが立った実行ファイルは、動いている間だけ実行者が別ユーザー(例: root)の権限になり、終われば元に戻る。ロールも「かぶっている間だけ」別の権限になり、外せば自分に戻る。
ロールは「かぶる帽子」であり、帽子そのものは資格情報を持たない。誰かがかぶった瞬間だけ、そのセッション用の一時認証情報が発行される。
② 1つのロールに必ず2枚のポリシー
1つのロールアイデンティティであると同時にリソースでもある
信頼ポリシー「誰がこのロールをかぶれるか」= 誰が(who)を決める側
ロール(リソース)に付く = リソースベースポリシー許可ポリシー「かぶった人が何をできるか」= 何を(what)を決める側
アイデンティティに付く = アイデンティティベースポリシー- IAMがサポートするリソースベースポリシーはこの信頼ポリシー1種類だけ。公式: 「The IAM service supports only one type of resource-based policy called a role *trust policy*, which is attached to an IAM role. An IAM role is both an identity and a resource that supports resource-based policies. For that reason, you must attach both a trust policy and an identity-based policy to an IAM role.」
- 信頼ポリシーは必須 — 「A role trust policy is a required resource-based policy that is attached to a role in IAM.」
- 基礎への接続: 認証(authentication=あなたは誰か)と認可(authorization=あなたは何をしてよいか)を別々に扱うのはアクセス制御設計の王道。ロールの2枚のポリシーはこの分離と同じ発想で、「誰がなれるか」を決める紙と「なった後に何ができるか」を決める紙を分けている。
信頼ポリシー=「誰がかぶれるか」、許可ポリシー=「かぶった人が何をできるか」。1つのロールがこの2枚を必ず併せ持つことで、「誰か」と「何ができるか」を分離して設計できる。ロールはアイデンティティであると同時にリソースでもある、唯一の存在。
③ かぶれるのは4種類
信頼ポリシーの Principal「誰を信頼するか」を書く場所
① IAMユーザー同じアカウント / 別アカウントのユーザー
② 別のIAMロール同一アカウントのロール。ロールからロールへ(→ ⑥ロールチェーン)
③ サービスプリンシパルAWSサービスが「コードのために」引き受ける
例: EC2 / Lambda が関数コードのために。S3オブジェクトレプリケーション④ 外部IdPのユーザーSAML 2.0 または OpenID Connect(OIDC)で認証された外部ユーザー(フェデレーション)
- 公式が列挙する引き受け可能な主体 — 「An IAM user in the same AWS account or another AWS account」「IAM roles in the same account」「Service principals」(EC2/Lambdaのようにコードを動かすサービス、S3オブジェクトレプリケーションのように代理で動く機能)、「an external user authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 or OpenID Connect」。
- 基礎への接続: Lambda編で触れた「実行ロール」の答え合わせ。Lambda関数がAWSにアクセスできたのは、Lambdaというサービスプリンシパルがその関数の実行ロールを引き受け、関数コードに一時認証情報を渡していたから。パスワードをコードに埋め込まずに済むのはこの仕組みのおかげ。
「誰がかぶれるか」は人間のユーザーに限らない。EC2やLambdaといったサービス自身が、実行するコードのためにロールを引き受けるのがサービスプリンシパルである。
④ かぶっている間は自分の権限を手放す
User1自分の権限 A を持つ
権限 A を手放す自分の権限はいったん失われる
ロールの使用をやめる / セッション終了
RoleX の権限だけいまはロールの許可ポリシーの権限だけを持つ
元の権限 A が戻る
- 公式の言い回し — 「A user who assumes a role temporarily gives up his or her own permissions and instead takes on the permissions of the role. When the user exits, or stops using the role, the original user permissions are restored.」
ロールをかぶるのは権限の「上乗せ」ではなく「入れ替え」。だから最小権限のロールを用意すれば、普段は強い権限を持つ人でも、その作業中はロールの範囲だけに絞られる。
⑤ クロスアカウント委譲は2枚が揃って成立
アカウントBの RoleX信頼ポリシー:「アカウントAを信頼」+ 許可ポリシー: RoleXが何をできるか
半分① — 信頼する側 / リソース保有アカウントAの User1許可ポリシー:「sts:AssumeRole を RoleX に対して許可」
半分② — 信頼される側 / 呼び出す側assume 成立User1 が RoleX の一時認証情報を得る
- 公式は片方ずつを "one-half" と表現 — 信頼ポリシーは trusting アカウントのロールに付き「one-half of the permissions」、もう半分は trusted アカウント側のユーザーに付く許可ポリシーで「allows that user to switch to, or assume the role」(公式リンク先で示されるのは sts:AssumeRole を許可するポリシー)。
- 補足: 同一組織の管理下にないアカウント間では、混乱した代理(confused deputy)問題への対処として External ID というパラメータを条件に加える。
クロスアカウントは「信頼ポリシー(受け入れる側)」と「sts:AssumeRole許可(呼び出す側)」の2枚が両アカウントに揃って初めて成立する。どちらか一方だけでは扉は開かない。
⑥ ロールチェーンは最大1時間
User1
RoleAの一時認証情報で RoleB を assume(= ロールチェーン)
RoleARoleAの一時認証情報を得る
RoleBこのセッションは最大 1 時間に制限される
個々のロールの最大セッション時間の設定に関わらず- 公式 — 「Role chaining limits your AWS Management Console, AWS CLI or AWS API role session to a maximum of one hour. It applies regardless of the maximum session duration configured for individual roles.」
- 通常の(チェーンでない)AssumeRoleでは DurationSeconds を最大43200秒(12時間)まで指定可(ロールの最大セッション時間設定に依存)。
- チェーン時に1時間超を指定すると操作は失敗する — 「if you assume a role using role chaining and provide a DurationSeconds parameter value greater than one hour, the operation fails」。
ロールを踏み台にしてさらに別のロールへ渡ると、セッションは問答無用で最大1時間に切り詰められる。単発のロール取得なら最大12時間まで設定できるのとは対照的で、チェーンには短い寿命が課される。