ISMS対応で始めた AWS Access Key 整理: Role ベース認証への移行記

ISMSの事後審査対応の過程で、AWSアカウントに蓄積していた Access Key を点検しながら、Role ベース認証へ移行した経験をまとめた記事です。

導入背景

• IAM コンソールを見ると Access Key が複数箇所（CI/CD、デプロイスクリプト、ローカル開発など）に散らばっており、どこでどう使われているのか追跡が難しかった
• Access Key は有効期限なしで維持され、漏えい時には付与された権限がそのまま露出する構造のため、リスクが大きかった
• AWS も長期認証情報（Access Key）ではなく、一時認証情報（Role/STS）の利用を推奨

問題

• キーがあちこちにコピーされて使われることで、「このキーが漏えいしたらどこまで影響するのか？」に答えにくかった
• ローテーションするには分散した設定を同時に変える必要があり、1つの IAM User に複数用途の権限が集約されていて最小権限の適用が難しかった
• 当時は CI/CD 用 IAM User 1つに ECR/S3/SSM/ECS デプロイ権限などがまとめて集中していた

移行した方式（要約）

• Assume Role: 必要なタイミングで別の Role 権限を一時的に借りて使う方式
• OIDC Web Identity: GitHub Actions/EKS（=IRSA）のように外部システムの ID で Role を発行してもらう方式
• Instance Profile: EC2/Lambda などに Role を直接付与して自動的に権限を持たせる方式

実際の移行プロセス

• 1段階: 広範なポリシーが付与された IAM User の権限を用途別 Role に分離（ECR プッシュ/プル、ECS デプロイ、S3 キャッシュなど）
• 2段階: GitHub Actions に OIDC を適用（Identity Provider 登録 → Trust Policy 条件で repo 範囲を制限 → ワークフローで configure-aws-credentials を使用）

効果

• コード/シークレットから Access Key を除去し、一時トークンベースのため漏えいしても有効期限によって被害範囲が限定される
• キーローテーションの負担がなくなり、ワークフロー/作業ごとの権限追跡が明確になった

注意点

• Trust Policy 条件は広く取りすぎず、最小範囲（org/repo、可能ならブランチまで）に制限する
• 既存の Access Key はすぐ削除せず、移行後しばらくは無効化/検証期間を置いてから削除する