EC2 に S3 権限を渡すなら Access Key 配布は禁止｜IAM Role と iam:PassRole を整理する
EC2 から S3 にアクセスさせたいとき、まだ Access Key をサーバーに置く 方向で考えてしまう人がいます。
ですが、これは AWS ではかなり筋の悪い設計です。鍵の配布、ローテーション、漏えい時の追跡、不要になった後の回収まで、全部あとで自分の首を絞めます。
この記事では、EC2 に S3 権限を安全に渡す基本形 を整理します。結論から言うと、使うのは長期 Access Key ではなく IAM Role です。そして、その Role を EC2 に渡す操作を許可する権限が iam:PassRole です。
まず結論
先に結論を書くと、考え方はシンプルです。
- EC2 に S3 権限を渡すなら IAM Role を使う
- EC2 に長期 Access Key を埋め込まない
- その Role を EC2 に関連付ける権限として iam:PassRole が必要になる
つまり、
- 何の権限を持たせるか → IAM Role
- 誰がその Role を EC2 に渡せるか �� iam:PassRole
この 2 つは別の論点です。ここを混ぜると、試験でも実務でも簡単に事故ります。
なぜ Access Key 配布が危ないのか
EC2 インスタンスに Access Key と Secret Access Key を直接置く方式は、動くことは動きます。ですが、運用としてはかなり危ないです。
たとえば次の問題が出ます。
- サーバー内に長期認証情報が残る
- 誰が使った鍵か追いにくい
- ローテーションが面倒
- AMI や設定ファイルに鍵が残る事故が起きやすい
- 複数台構成だと配布と回収が地味に破綻する
たとえば Auto Scaling で EC2 が増減する構成だと、毎回鍵を配って整合を取る運用はかなり不格好です。AWS らしく設計するなら、インスタンス自身が一時認証情報を受け取る 形に寄せるべきです。
IAM Role を使うと何が変わるのか
IAM Role を EC2 に付与すると、EC2 はインスタンスメタデータ経由で一時的な認証情報を取得できます。
これにより、アプリケーションは Access Key をベタ書きしなくても、SDK や CLI の標準認証フローで S3 にアクセスできます。
たとえば EC2 側では、次のように普通に AWS CLI を使えます。
aws s3 ls s3://example-bucket
コードや設定ファイルに鍵を埋めなくてよいので、かなり健全です。
IAM Role を使うメリット
- 長期 Access Key を配布しなくてよい
- 認証情報が自動でローテーションされる
- インスタンス単位で役割を分けやすい
- 最小権限で設計しやすい
- 漏えい面積を減らしやすい
要するに、鍵を配る設計から、役割を割り当てる設計へ切り替える のがポイントです。
インスタンスプロファイルも一緒に押さえる
実務や試験で少しややこしいのが、IAM Role とインスタンスプロファイル の関係です。
EC2 に Role を関連付けるとき、裏側ではインスタンスプロファイルが使われます。細かい内部構造まで毎回意識する必要はありませんが、少なくとも次の整理はしておくと迷いません。
- IAM Policy：何をしてよいかを定義する
- IAM Role：その権限の入れ物
- Instance Profile：EC2 に Role をひも付けるための仕組み
試験では細かい API 名より、EC2 に権限を持たせるならユーザーではなく Role という軸を持っておく方が大事です。
iam:PassRole は���を許可するのか
ここがよく混同されるポイントです。
iam:PassRole は、ある IAM Role を AWS サービスへ渡すことを許可する権限です。EC2 の場合なら、特定の Role をインスタンスにアタッチす���ときに関係します。
つまり、iam:PassRole が見ているのは S3 へのアクセス権そのもの ではありません。
見ているのは、その Role を渡してよいかどうか です。
たとえばこう分けて考える
| 論点 | 使うもの |
|---|---|
| EC2 から S3 を読ませたい | S3 権限を持つ IAM Role |
| その Role を EC2 に付けさせたい | iam:PassRole |
この切り分けができると、問題文で「EC2 に権限を付与したい」と「管理者がその Role を割り当てたい」が別の話だと見抜けます。
最小構成のイメージ
たとえば、EC2 から特定バケットのオブジェクトを読むだけなら、次のような構成が基本です。
- S3 読み取り権限を持つ IAM Policy を作る
- その Policy を IAM Role に付与する
- その Role を EC2 に関連付ける
- EC2 上のアプリは SDK / CLI の標準認証を使う
S3 側の権限イメージはたとえばこうです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::example-bucket/*"]
}
]
}
本番では s3:* のような雑な権限ではなく、���要なバケットと必要な操作だけに絞るべきです。ここを雑にすると、Role を使っていても普通に危ないです。
試験で迷いやすいポイント
AWS 認定試験では、次のようなひっかけがよく出ます。
1. Access Key を EC2 に保存させる選択肢
- 一見すぐ動きそうですが、基本的には外れ寄りです
- 正解は IAM Role を選ばせたいケースが多いです
2. iam:PassRole を S3 権限と勘違いする
- iam:PassRole は Role を渡すための権限 です
- S3 そのものを読む権限は Role に付いた Policy で決まります
3. IAM User を EC2 用に作る
- 人の認証とワークロードの認証を混ぜると荒れます
- EC2 のような AWS リソースには Role を使う のが基本です
問題文で「安全に AWS サービスへアクセスしたい」「認証情報の管理を簡素化したい」「長期キーを避けたい」と書いてあれば、まず Role を疑うべきです。
実務で見るべきチェックポイント
実務では、Role を使えば終わりではありません。少なくとも次は確認したいです。
- Role の権限が広すぎないか
- 対象バケットが限定されているか
- CloudTrail で利用状���を追えるか
- インスタンス起動時に正しい Role が付くか
- 不要になった Role が放置されていないか
たとえば開発環境では雑に通っても、本番で AdministratorAccess 相当の Role を EC2 に付けるのは、さすがに雑すぎます。Role を使うこと と 最小権限で設計すること はセットです。
まとめ
EC2 に S3 権限を渡したいとき、長期 Access Key をサーバーへ配るのは、もう古くて危ないやり方です。
- EC2 に権限を持たせるなら IAM Role
- Role を EC2 に渡す操作の制御は iam:PassRole
- S3 権限そのものは Role に付いた Policy で決まる
この 3 つを分けて理解しておくと、試験でも実務でもかなり強いです。
AWS では、鍵を配るより役割を渡す。まずはこの基本を崩さないのが正解です。