令和に IAM ユーザーみたいな古代文明を使うとか...
「令和に IAM ユーザーみたいな古代文明を使うとか、FAX使っている年寄りみたいな扱いされるぞ。人間は IAM Identity Center に統一して、他は OIDC や IAM ロールを使うべき。」
先日、このようなツイートを見て、IAMユーザーによってAWSアカウントの運用しか行ったことの無かった僕は
「ぎくり。」
となりまして。この度、色々と調査してみました。
調査した結果、上記ツイートはAWSの現在のベストプラクティスにかなり沿っているようです。
AWSは現在、可能な限り長期クレデンシャルではなく短期クレデンシャルを使うこと、人間のアクセスにはIAM Identity Center やフェデレーションを、ワークロードにはIAMロールやOIDC連携を使うことを推奨しています。
この記事では、なぜIAMユーザー中心の運用が2026年の今日に避けられがちなのかを、設計原理ベースで整理します。
目次
- 結論
- IAMユーザー運用が避けられる理由
- 1. 長期クレデンシャル前提になりやすい
- 2. 人の管理がAWSアカウントごとに分散しやすい
- 3. マルチアカウント運用と相性が悪い
- 4. 監査と責任追跡が崩れやすい
- 5. ワークロードにIAMユーザーを使うのはさらに悪い
- IAMユーザーは完全に悪なのか
- 実務での標準パターン
- まとめ
- おまけ: 小規模組織でもIAM Identity Centerへ移行する価値はあるか
結論
まずは結論からです。
結論から言うと、 IAMユーザーという機能そのもの に問題があるのではなく、
人間やワークロードに長期クレデンシャルを持たせる運用 に問題があります。
現在のAWSで推奨される基本方針は、概ね次の通りです。
- 人間: IAM Identity Center または外部IdP連携でログインし、ロールを引き受ける
- ワークロード: IAMロールまたはOIDC連携で短期クレデンシャルを使う
- IAMユーザー: 例外的・限定的な用途に寄せる
AWS自身も、長期アクセスキーの代替を優先して検討するよう案内しています。
IAMユーザー運用が避けられる理由
1. 長期クレデンシャル前提になりやすい
IAMユーザーを人間やアプリに割り当てると、実務では次のものを持たせがちです。
- コンソール用パスワード
- アクセスキー
- 個別MFA
- ローテーション運用
これはつまり、秘密情報そのものを配る設計になりやすいということです。
一方で、IAM Identity Center や IAMロールは、必要なときだけ短期クレデンシャルを払い出す設計です。
漏えい時の被害継続時間を抑えやすく、失効管理や棚卸しも相対的に楽になります。AWSは temporary credentials の利用を明確に推しています。
2. 人の管理がAWSアカウントごとに分散しやすい
IAMユーザー中心の運用では、入社・異動・退職・委託終了のたびに、AWS側で個別に
- ユーザー作成
- 権限変更
- MFA管理
- 削除
をやることになります。
小規模だと回っているように見えても、人数やアカウントが増えるほど
- 削除漏れ
- 権限剥奪漏れ
- 使われていないアクセスキー放置
が起きやすくなります。
IAM Identity Center は、ユーザーやグループに対して permission set を割り当て、各AWSアカウントには対応するロールを配る仕組みです。
つまり、人の管理は中央、各アカウント側はロール管理 に寄せられます。
3. マルチアカウント運用と相性が悪い
今のAWSは、Organizations配下で複数アカウントを分けて管理する構成が一般的です。
その前提で各アカウントにIAMユーザーを生やしていくと、かなり煩雑になります。
- 誰がどのアカウントにいるのか
- どの権限がどこにあるのか
- どのMFAがどのユーザーに対応しているのか
が分散するからです。
IAM Identity Center は、複数アカウントに対するアクセス権を一元的に割り当てる前提の仕組みです。
要するに、
- IAMユーザー運用: アカウントごとに人を管理する
- Identity Center運用: 人に対して複数アカウントの権限をまとめて配る
という違いがあります。
4. 監査と責任追跡が崩れやすい
IAMユーザーでも厳密に個人単位で分ければ追跡は可能です。
ただし現場では、shared admin user や共有アクセスキー、雑な使い回しが混ざりやすいです。
中央IdPやIAM Identity Centerを経由したアクセスなら、
- 誰が認証したか
- どのロールを引き受けたか
- どのAWSアカウントに入ったか
を一貫したモデルで扱いやすくなります。
監査面でも説明しやすく、属人的運用を減らしやすいです。
5. ワークロードにIAMユーザーを使うのはさらに悪い
人間だけでなく、アプリケーションやCI/CDにIAMユーザーのアクセスキーを配る設計も、今ではかなり避けられます。
たとえば固定アクセスキーを
- GitHub Secrets
- ローカルのcredentialsファイル
- コンテナイメージ
- 各種設定ファイル
に置くと、漏えい面積が一気に広がります。
その代わりに、現在の標準は次のような形です。
- EC2 → IAMロール
- ECS → task role
- Lambda → execution role
- 外部CI → OIDCでAssumeRole
AWSも、プログラムアクセスに対して可能な限りIAMロールや一時クレデンシャルを使うよう案内しています。
では、IAMユーザーは完全に悪なのか
そこまで言うと不正確です。
AWSはIAMユーザー自体を廃止していませんし、今もドキュメント上でサポートされています。
ただし現在のメッセージは明確で、
禁止ではないが、標準の選択肢ではなくなっている
という理解が適切です。
特にアクセスキーについては、AWSは作成前に長期アクセスキーの代替を検討するよう案内しています。
実務での標準パターン
人間
- IAM Identity Center または外部IdPで認証
- グループに permission set を付与
- 各AWSアカウントではロールを引き受ける
- 短期クレデンシャルを利用
ワークロード
- EC2 / ECS / Lambda などはIAMロール
- 外部CIはOIDC連携
- 固定アクセスキーは極小化
例外
- rootユーザーは最小利用
- IAMユーザーは限定用途のみ
- 使うならMFA・最小権限・棚卸しを前提にする
まとめ
IAMユーザーが「古い」と言われる理由は、単に新しいサービスが出たからではありません。
本質は、IAMユーザー中心の運用が長期クレデンシャル配布・分散した人管理・権限剥奪漏れ・監査性低下・マルチアカウント非効率を招きやすいことにあります。
そのため現在のAWSでは、
- 人間は IAM Identity Center / federation
- ワークロードは IAMロール / OIDC
- 長期クレデンシャルはできるだけ減らす
という方向が、かなり筋の良いベストプラクティスになっています。
以上、AWSアカウント管理をめぐる、ベストプラクティスを調査した結果でした。
以下、参照したソースと、参考にした技術記事を貼っておきます。
おまけ: 小規模組織でもIAM Identity Centerへ移行する価値はあるか
結論だけ言うと、常に必須ではないが、思ったより元は取りやすいです。
価値が高いケース
- 2人以上でAWSを使う
- 今後も継続利用する
- 権限変更や退職・異動がありうる
- 将来複数アカウントに増える可能性がある
この場合、人を中央で管理し、アカウント側はロールに寄せるモデルの価値はかなり高いです。後からIAMユーザー運用を剥がすより、早めに寄せた方が楽です。
後回しでもよいケース
- 1人運用
- 単一アカウント
- 短命な検証環境
- 組織変更がほぼない
この場合、直ちに移行しなくても致命的とは言いにくいです。
ただしそれは「IAMユーザーでよい」からではなく、まだ負債が顕在化していないだけであり、AWSの推奨軸自体はIdentity Center側にあります。