AI エージェント時代の AWS 認証情報管理 ── アクセスキーをやめて SSO + AssumeRole へ

Claude Code などの AI コーディングエージェントは、開発者の PC 上で AWS CLI を含むシェルコマンドを実行します。~/.aws/credentials に長期アクセスキー（AKIA で始まるキー）が置かれていると、誤操作やプロンプトインジェクションの影響範囲が大きくなります。

目指す状態

• 開発者の PC には有効期限つきの一時認証情報だけを置く
• 権限はアカウントごと・役割ごとの許可セットで管理する
• 本番環境は読み取り専用ロールを基本とし、変更系の操作は別ロールに分ける

設定例

IAM Identity Center（旧 AWS SSO）を有効にしてユーザーと許可セットを作成したら、各開発者は aws configure sso で次のようなプロファイルを作成します。

[sso-session company]
sso_start_url = https://example.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access

[profile dev]
sso_session = company
sso_account_id = 111111111111
sso_role_name = DeveloperAccess
region = ap-northeast-1

[profile prod-readonly]
source_profile = dev
role_arn = arn:aws:iam::222222222222:role/ReadOnly
region = ap-northeast-1

aws sso login --profile dev でブラウザ認証を行うと、一定時間だけ有効な認証情報が発行されます。別アカウントの操作は AssumeRole を経由するため、CloudTrail で誰がどのロールを使ったかも追跡できます。

移行のチェックリスト

• aws sts get-caller-identity で、どの認証情報が使われているかを確認する
• IAM の認証情報レポートで、最終使用日の古いアクセスキーを洗い出す
• CI/CD は OIDC 連携（GitHub Actions など）に切り替え、アクセスキーを使わない
• 移行後に既存のアクセスキーを無効化し、一定期間問題がなければ削除する