背景・状況
インフラを引き継いだ直後、IAMユーザーが多数存在している状態でした。
どのユーザーが現在も利用されているのか分からず、不要なものを整理したい状況です。
ただし、IAMユーザーの削除はリスクが高いです。
アクセスキーを使ったバッチ処理や外部連携は表面から見えにくく、誤って削除すると即障害になります。
そのため「削除していいか判断できない」という状態に陥りました。
最初に疑ったこと
最初はシンプルに考えました。
- 最終利用日を確認する
- 一定期間使われていないユーザーを削除する
IAMではCredential Reportで最終利用日が取得できます。
aws iam generate-credential-report
aws iam get-credential-report
これで解決できると思いましたが、実際は不十分でした。
- アクセスキーは使われていても検知が遅れることがある
- 外部システムやCI/CDの利用が見えない
- 削除は元に戻せない
つまり、「未使用っぽい＝削除してよい」ではありませんでした。
方針の転換
削除前提をやめ、段階的に整理する方針に変更しました。
dryrun
↓
backup
↓
disable
↓
様子見
↓
delete
ポイントは「削除しない状態で影響を確認する」ことです。
削除してから復元するのではなく、まずは削除に近い影響を安全に確認できる状態を作る方針にしました。
調べた過程
まずはIAMユーザーの一覧を取得しました。
aws iam list-users --query "Users[*].UserName" --output text
次にCredential Reportから最終利用日を取得し、一定期間以上使われていないユーザーを抽出しました。
今回は例として、100日以上利用がないユーザーを候補にしました。
ただし、ここでいきなり削除はせず、スクリプトで以下を行うようにしました。
- CSVで一覧化
- バックアップ取得
- 復元スクリプト生成
- 必要に応じて無効化
実際にやったこと
1. バックアップの取得
削除や無効化に備えて、ユーザー情報を保存します。
取得対象は以下です。
aws iam get-user
aws iam list-attached-user-policies
aws iam list-user-policies
aws iam get-user-policy
aws iam list-groups-for-user
aws iam list-mfa-devices
aws iam get-login-profile
aws iam list-access-keys
aws iam list-user-tags
ユーザーごとにディレクトリを作り、JSONで保存するようにしました。
例：
backup/
└── userA/
├── user_info.json
├── attached_policies.json
├── inline_policies.json
├── groups.json
├── mfa_devices.json
├── login_profile.json
├── access_keys.json
├── tags.json
└── restore_userA.sh
2. 復元スクリプトの生成
バックアップだけでは復元時に手作業が増えます。
そこで、バックアップ情報から復元用スクリプトも生成するようにしました。
復元スクリプトでは、以下のような処理を行います。
aws iam create-user --user-name userA
aws iam add-user-to-group --user-name userA --group-name groupA
aws iam attach-user-policy --user-name userA --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
これにより、問題が発生した場合でも、手順を見ながら再作成できる状態にしました。
ただし、IAMユーザーは完全復元できるわけではありません。
3. 無効化
削除の代わりに、まずは無効化します。
代表的には、アクセスキーをInactiveにします。
aws iam update-access-key \
--user-name userA \
--access-key-id AKIAXXXXXXXXXXXXXXXX \
--status Inactive
必要に応じて、グループからも外します。
aws iam remove-user-from-group \
--user-name userA \
--group-name groupA
この状態でしばらく運用し、問題が出るか確認します。
結果
この方針により、以下の状態を作れました。
- 非アクティブユーザーをCSVで一覧化
- ユーザーごとのバックアップを取得
- 復元スクリプトを生成
- 削除せずに無効化して影響確認できる
- 問題がなければ、後日削除判断できる
いきなり削除するのではなく、まず安全に止める運用にできました。
やってわかったこと
削除は最後でいい
IAMユーザー整理では、最初から削除しなくてもよいです。
アクセスキーの無効化だけでも、多くの場合は影響確認ができます。
問題が出なければ、後から削除すればよいです。
完全な復元はできない
IAMユーザーは削除後に完全復元できません。
特に以下は注意が必要です。
- 既存アクセスキーのSecretAccessKeyは再取得できない
- 既存のアクセスキーIDは復元できない
- MFAデバイスは再設定が必要
- IAMユーザーの内部IDは変わる
- CloudTrail上の過去ログと完全には一致しない
そのため、「バックアップがあるから削除しても完全に戻せる」とは考えない方がよいです。
バックアップはあくまで、同じような設定のユーザーを再作成するための材料です。
サービスアカウント判定は難しい
ユーザー名だけでサービスアカウントを判定するのは危険です。
例えば、以下のような文字列を含むユーザーを機械的に除外する方法があります。
svcservicesystem
しかし、命名ルールが徹底されていない環境では誤判定します。
本来はタグで管理した方が安全です。
例：
ServiceAccount=true
Owner=xxx
Purpose=ci-cd
今後の改善
今後は以下を進めたいです。
- サービスアカウントにタグを付ける
- 所有者不明のIAMユーザーを棚卸しする
- 無効化後の監視期間を決める
- 削除前チェックリストを作る
- AWS ConfigやCloudTrailと組み合わせて監査する
- IAMユーザーではなくIAMロールへ移行できるものを整理する
まとめ
IAMユーザー整理で重要なのは、いきなり削除しないことです。
特に、引き継ぎ直後やワンオペ環境では、不要かどうかを即断できません。
そのため、以下の流れが現実的です。
dryrun
↓
backup
↓
disable
↓
様子見
↓
delete
まずは一覧化し、バックアップを取り、復元できる材料を残したうえで無効化する。
問題がなければ、最後に削除する。
IAMユーザー整理は「消す作業」ではなく、「安全に止めて、影響を確認する作業」として進めるのがよいと感じました。