IAM（Identity and Access Management）の設計は、クラウド環境のセキュリティの基盤です。後から修正しようとすると、既存のシステムへの影響範囲が広く、作業コストが高くなります。最初に決めておくべき3つの項目を整理します。
1. 最小権限の原則をどこまで適用するか ¶
最小権限の原則は正しいですが、適用の粒度を細かくしすぎると、権限管理の運用コストが上がります。サービスアカウントごとに必要な権限を個別に定義するか、ロールをグループ化して管理するかを、チームの規模と運用体制に合わせて決めます。原則として、本番環境と開発環境のIAM設定は分離します。
2. ロールの命名規則と粒度 ¶
ロール名に環境（prod/dev/stg）、機能（read/write/admin）、対象リソースを含める命名規則を最初に決めます。命名規則がないと、ロールが増えるにつれて管理が困難になります。ロールの粒度は、「誰がこのロールを使うか」を具体的に想定して決めます。汎用的なロールは、後から権限過多になりやすいです。
3. 監査ログの収集範囲と保持期間 ¶
CloudTrail（AWS）またはCloud Audit Logs（GCP）で、どのAPIコールを記録するかを決めます。すべてのAPIコールを記録するとログ量が膨大になるため、セキュリティ上重要な操作（IAM変更、ストレージ設定変更、ネットワーク設定変更）を優先します。ログの保持期間は、コンプライアンス要件と保存コストのバランスで決めます。
設計書として残す ¶
IAM設計の決定事項は、設計書として文書化します。誰がどのロールを持つか、ロールの付与・剥奪の手順、定期的な棚卸しのスケジュールを記述します。設計書がないと、担当者が変わった際に設計意図が失われ、権限が肥大化していきます。
IAM設計は、一度決めたら終わりではありません。四半期ごとに棚卸しを行い、不要なロールと過剰な権限を削除する運用が、長期的なセキュリティ維持に必要です。