「1年に1回のキーローテーション」はもう卒業しよう —— AWS IAMアクセスキー運用のベストプラクティス
はじめに
こんにちは！SREチームの乃万です。
AWS環境でIAMユーザーのアクセスキーを使っていて、「セキュリティのために年1回、新しいキーを作って古いキーを無効化する」という運用をしているチームは多いと思います。
これは何もしないよりはずっと良い運用ですが、実は現在の業界標準からすると**「1年」はかなり長すぎる**周期です。この記事では、
- そもそもアクセスキーをどう扱うべきか
- 適切なローテーション周期と安全な切り替え手順
- SSO(IAM Identity Center)の導入が難しい場合にCLIで長期キーへの依存を減らす方法
を順番に整理します。
1. 大前提:アクセスキー自体を極力使わない
最初に押さえておきたいのは、ローテーション頻度を上げる以前に「そもそもアクセスキーを使うシーンを減らす」ことがベストプラクティスだということです。
- AWS上で動くアプリケーション(EC2、Lambda、ECSなど)にはIAMロールを使う。ロールは一時的な認証情報を発行し、自動的に期限切れ・更新されるため、ローテーションの運用自体が不要になります。
- 人間のCLI/コンソール利用者には、可能であれば**IAM Identity Center(旧AWS SSO)**を導入し、長期アクセスキーを持たせない。
「キーをどう安全にローテーションするか」は、あくまで「キーを使わざるを得ない場合」の次善策だと理解しておくと、運用設計の優先順位を誤りません。
2. それでもキーが必要な場合のローテーション周期
オンプレのバッチ処理や外部SaaS連携など、どうしても長期アクセスキーが必要なケースもあります。その場合の目安は以下の通りです。
| 運用レベル | 推奨ローテーション周期 |
|---|---|
| 一般的なワークロード | 90日以内(CIS AWS Foundations BenchmarkやAWS Configの標準ルールもデフォルト90日) |
| 機密性の高いワークロード | 30〜60日 |
| 現状の「年1回」 | ❌ 長すぎる。攻撃者が漏洩キーを使える期間が長すぎる |
キーは長く存在するほど、開発者のPC・CI/CDのログ・古い設定ファイルなどに残って漏洩するリスクが上がります。ローテーション周期を短くすることは、たとえ漏洩に気づけなくても被害を「時間で区切って」限定する、地味だが効果の高い対策です。
3. ダウンタウンなしで切り替える手順
IAMユーザーは同時に最大2つのアクティブなアクセスキーを持てます。これを利用すると、サービスを止めずに安全にローテーションできます。
- 新しいアクセスキーを作成する(古いキーはまだ有効なまま)
- アプリケーション・CI/CD・環境変数などを新しいキーに更新する
- 新しいキーで正常に動作することを確認する
- 古いキーを Inactive(無効化) にする ※削除と違い即座に戻せる
- 数日〜1〜2週間ほど監視し、エラーが出ないか確認する(
aws iam get-access-key-last-usedで最終利用日時を確認) - 問題がなければ古いキーを 削除する(
delete-access-key。これは不可逆操作)
途中で予期しないエラーが出た場合は、無効化を戻す(Activeに戻す)だけで即座に復旧できるのがこの手順の利点です。
# 1. 新しいキーを作成
aws iam create-access-key --user-name my-service-account
# 4. 古いキーを無効化(削除ではない)
aws iam update-access-key \
--user-name my-service-account \
--access-key-id AKIAIOSFODNN7OLDKEY \
--status Inactive
# 6. 検証後、古いキーを削除
aws iam delete-access-key \
--user-name my-service-account \
--access-key-id AKIAIOSFODNN7OLDKEY
4. 手動運用から自動監視へ
手動でのローテーション管理は漏れが起きやすいため、以下を組み合わせると堅牢になります。
- AWS Config管理ルール
access-keys-rotated:指定日数を超えた未ローテーションキーを自動検知し、コンプライアンス違反としてアラートできる - IAM認証情報レポート(
aws iam generate-credential-report/get-credential-report):全ユーザーのキー作成日・最終使用日を一覧化し、使われていない古いキーも同時に洗い出せる - AWS Secrets Manager + Lambdaによる自動ローテーション:AWS Organizations環境向けに、キーの年齢を監視して自動作成→通知→一定期間後に無効化→削除まで自動化する仕組みをAWSが公式パターンとして提供している
5. SSO化が難しい場合、CLIはどうする?
IAM Identity Centerの導入がすぐには難しくても、長期アクセスキーへの依存を大きく減らす方法があります。
5-1. 長期キーには「AssumeRoleのみ」を許可する
ポイントは、IAMユーザーの長期アクセスキーにはsts:AssumeRoleしか許可しないこと。実際の作業権限はすべて別のIAMロールに持たせ、そのロールの信頼ポリシーでMFA必須を条件にします。
# ~/.aws/credentials
[cli-user]
aws_access_key_id = AKIA...
aws_secret_access_key = ...
# ~/.aws/config
[profile work]
role_arn = arn:aws:iam::123456789012:role/DailyWorkRole
source_profile = cli-user
mfa_serial = arn:aws:iam::123456789012:mfa/your-user
duration_seconds = 43200 # 最大12時間
こうしておけば、万が一cli-userのアクセスキーが漏洩しても、攻撃者はMFAデバイスを持っていないためロールを引き受けられず、実害のある操作を防げます。
補足: MFA認証で一時クレデンシャルを取る際、先に
get-session-tokenをしてからassume-roleする二段階方式だと「ロールチェーン」とみなされ、セッションが最大1時間に制限されてしまいます。get-session-tokenを経由せず直接assume-roleする方が実用的です(最大12時間のセッションを発行できます)。
5-2. 長期キーを平文で置かない
~/.aws/credentialsに長期キーを平文保存する代わりに、AWS CLIのcredential_process機能を使い、パスワードマネージャーやaws-vaultのようなツールに暗号化保管させ、必要な時だけ動的に一時クレデンシャルを取得する方式も有効です。
5-3. 既存の社内IdPを使う
Okta・Azure AD・Google Workspaceなど、社内で既に使っているIDプロバイダーがあれば、IAM Identity Centerをフル構築しなくても、IAMのSAML IDプロバイダー設定 + saml2awsやaws-oktaなどのOSSツールを組み合わせることで、「社内ID+MFAでログイン→一時クレデンシャル発行」という流れをCLIでも実現できます。Identity Center構築より軽量に導入できるケースが多いです。
6. 「ログイン時にアクセスキーを使わない」の整理
ここは少し整理が必要です。
- AWSマネジメントコンソールへのログインは、そもそも最初からアクセスキーを使いません。ユーザー名+パスワード+MFA、またはSSO経由が前提で、アクセスキーはプログラム的アクセス(CLI/SDK/API)専用の認証情報です。
- 「CLI認証にアクセスキーを使いたくない」という意図であれば、前述のMFA必須+AssumeRole構成が現実的な答えです。長期キー単体は無力化され、実質的には「MFAを通した一時トークンでログインしている」状態に近づきます。
- ルートユーザーについては、長期アクセスキーを作成する代わりに
aws loginコマンドを使うことで、ルート認証情報を使ってCLI/SDKを認証しつつ、自動的にローテーションされる一時的な認証情報を得られます。ルートユーザーはそもそもアクセスキーを作らないのが大前提ですが、プログラムアクセスがどうしても必要な場合はこちらを検討すべきです。
まとめ
| 項目 | 見直し前 | 見直し後の推奨 |
|---|---|---|
| ローテーション頻度 | 1年 | 90日以内(機密度が高い場合は30〜60日) |
| 基本方針 | 全IAMユーザーにキーを発行 | まずアクセスキー利用自体を減らす(ロール化・SSO化) |
| 切り替え手順 | (要確認) | 新規作成→検証→旧キー無効化→監視→削除、で無停止切替 |
| 監視 | (要確認) | AWS Config + 認証情報レポートで年齢と利用状況を可視化 |
| SSO導入前のCLI | 長期キーそのままで作業 | 長期キーはAssumeRole専用の最小権限のみ+MFA必須ロールを都度Assume |
| ルートユーザー | アクセスキー作成 | アクセスキーを作らずaws loginで一時認証情報を利用 |
すべてを一度に変えるのは難しくても、まずは
- ローテーション周期を90日以内に短縮する
- AWS Configでキーの年齢を監視してアラート化する
- CLI利用者の長期キー権限をAssumeRoleのみに絞り、MFA必須のロールを経由させる
の3点から始めるのが現実的だと思います。地味な改善の積み重ねですが、漏洩時の被害範囲を大きく減らせるはずです。
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 採用サイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました
