← AWSサービスの内部原理 コース
26. 実行ロール — プロセスに一時認証情報を注入する
Lambda関数が秘密鍵をコードに書かずにAWSを操作できる原理を、実行ロールと一時クレデンシャルの流れで図解します。
① なぜ実行ロールが要るのか — 秘密鍵をコードに書かないために
NG: コードにアクセスキーを直書き漏れれば誰でもアカウントを操作可能
代わりに
実行ロール(execution role)IAMロール =『この関数は何をできるか』
認可の器- Lambda関数のコードは1つのmicroVM内のプロセスとして動く(前レッスン)
- そのプロセスがDynamoDBに書けるかどうかを、AWSはこのロールで判断する
SDKがAWSのAPIを呼ぶには署名用のアクセスキーが必要ですが、コードに直書きすると漏れた瞬間に誰でもアカウントを操作できます。その代わりに使うのが実行ロール——『この関数は何をできるか』を定める認可の器です。
② 仕組みの核心 — Lambdaが呼び出しごとにロールを自動assume
Lambdaサービス呼び出しのたびに実行ロールを自動でassume
信頼ポリシーlambda.amazonaws.com を信頼された主体として許可
『代わりに引き受けてよい』という同意の宣言裏側で STS(Security Token Service)を呼ぶ
STS実行ロールに紐づく認証情報を発行
発行
一時セキュリティ認証情報有効期限つき — 恒久的な秘密鍵ではない
- コードが自分で sts:AssumeRole を呼ぶ必要はない(公式も避けるよう明記)
- assumeが成立するのは、信頼ポリシーがLambdaサービスを許可しているから
関数を呼び出すたびに、LambdaがあなたのロールをSTS経由で自動的にassumeし、有効期限つきの一時クレデンシャルを受け取ります。コード側で sts:AssumeRole を呼ぶ必要はなく、公式もそれを避けるよう明記しています。
③ 注入 — 一時クレデンシャルは環境変数でプロセスに渡る
Lambda受け取った一時クレデンシャルを実行環境へ
環境変数として注入(親→子プロセスの仕組み)
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN一時認証であることを示す
AWS SDKが既定で自動読み取り → 署名に使用
DynamoDB / S3 の呼び出しコードにキーを一切書かずに実行
- あわせて AWS_ACCESS_KEY も設定される
- これらはLambdaの予約環境変数で、あなたが上書きすることはできない
- 秘密はコードにもデプロイパッケージにも存在せず、プロセスのメモリ上の環境にだけ、期限つきで存在する
OSの章で学んだ『親プロセスが子プロセスへ環境変数で情報を渡す』仕組みそのものです。SDKが既定でこれらを自動的に読んで署名に使うため、コードには一切キーを書かずにDynamoDBやS3を呼べます。
④ 認証と認可の分離 — 器を小さく保つことが境界になる
認証 = 誰であるかロールをassumeして得た一時クレデンシャル
認可 = 何をしてよいかロールに付いたIAMポリシー
認可の中身(ポリシー)
AWSLambdaBasicExecutionRole既定のマネージドポリシー: CloudWatch Logsへのログ出力のみ
+ DynamoDB書き込み権限必要な分だけ明示的に足す
- 最小権限の原則: 関数が実際に使う操作だけを与える
- 器(ロール)を小さく保つことが、そのままセキュリティの境界になる
『誰であるか』は一時クレデンシャルが、『何をしてよいか』はロールに付いたIAMポリシーが担います。実行ロールには関数が実際に使う操作だけを与えれば、万一コードに脆弱性があってもロールの範囲を超えた被害は出ません。
⑤ 向きの違い — 出ていく認可と入ってくる認可は別物
実行ロール出ていく認可: 関数 → 外のサービス
この関数は外に対して何をできるか同じ『権限』でも向きが逆
リソースベースポリシー入ってくる認可: 外 → 関数
誰がこの関数を呼べるか- S3やAPI GatewayがあなたのLambdaを呼び出す許可は、実行ロールではなくリソースベースポリシー側で与える
実行ロールは『関数→外』の向き、リソースベースポリシーは『外→関数』の向きの権限です。この2つを混同しないことが、Lambdaの権限設計でつまずかないための一番の要点です。