AWS Certified CloudOps Engineer - Associate (SOA-C03) #12 Domain 5-1 セキュリティ — IAM·Organizations·マルチアカウント運用

インフラ AWS Certification
読了 5分

#11 までネットワーキングドメインを終えました。最後のドメインは セキュリティとコンプライアンス (16%) です。最初の記事は ID と権限、そして複数のアカウントを標準で治めるマルチアカウントガバナンスを扱います。SAA·DVA で見た IAM を、ここでは 運用者が権限を点検·強制·監査する観点 で見ます。

IAM の権限運用 #

IAM の定義は以前のシリーズで扱ったので、運用でよく問われる点に集中します。

概念運用ポイント
最小権限必要な分だけ付与。過剰な権限を減らすことが常時の課題
Role人·サービスに長期キーの代わりに一時的な認証情報。EC2·Lambda·タスクロール
ポリシー評価デフォルト拒否、明示的な Allow で許可、明示的な Deny が最優先

認証情報レポートと最終使用情報 #

運用者が権限を点検する 2 つのツールです。

  • Credential Report (認証情報レポート): すべての IAM ユーザーのパスワード·アクセスキー·MFA の状態を CSV で一括照会。「古いキー、MFA のないアカウントを探せ」の答え。
  • Access Advisor (最終使用情報): ロール·ユーザーが 実際に使用したサービス を表示します。使っていない権限を回収して最小権限に絞る根拠。

「未使用の認証情報と権限を識別して整理せよ」の答えがこの 2 つです。

IAM Access Analyzer #

リソースポリシーを分析して アカウント外 (外部) に意図せず共有されたリソース を見つけ出します。S3 バケット·IAM ロール·KMS キーなどが外部に公開されているかを点検します。「外部に誤って公開されたリソースを検知せよ」の答えが Access Analyzer です。

MFA の強制 #

運用セキュリティの基本は MFA です。試験は「MFA をどう 強制 するか」を問います。

  • ルートアカウント MFA: 最初に有効化すべきもの。ルートは日常使用を禁止。
  • ポリシーで強制: IAM ポリシーの Condition に aws:MultiFactorAuthPresent を掛けて、MFA なしでは機密操作を拒否。
  • SCP で組織レベルで強制: 下の Organizations で。

「MFA を使わなければ特定の操作を止めよ」の答えが、条件キー aws:MultiFactorAuthPresent を使ったポリシーです。

AWS Organizations: マルチアカウントの土台 #

アカウントが増えると、アカウントごとに個別管理するのは不可能です。Organizations は 複数のアカウントを 1 つの組織にまとめて 治めます。

概念役割
Management アカウント組織のルート。請求·ポリシー管理
OU (Organizational Unit)アカウントを用途別にまとめるグループ (例: prod·dev)
SCP (Service Control Policy)OU·アカウントに適用する 権限の上限
一括請求全アカウントの使用量を合算してボリューム割引

SCP の核心的な性質 #

SCP は試験の常連であり、誤解も多いです。

  • SCP は 権限を付与しません。ただ 上限を定めて制限 します。
  • 実際の権限 = SCP 許可範囲 ∩ IAM ポリシー許可範囲。両方が許可してはじめて可能です。
  • Management アカウントには SCP が適用されません。

「組織のすべてのアカウントで特定リージョンの使用を禁止せよ」「指定したサービス以外の使用を止めよ」の答えが SCP です。逆に「SCP で権限を与えよ」という表現が選択肢にあれば、それは誤答です。

マルチアカウントの標準化 #

ツール役割
Organizations + SCP権限の上限·ガードレール
StackSets#7 で見た標準スタックの一括デプロイ
Control Towerマルチアカウント環境をベストプラクティスで自動構成 (ランディングゾーン)
IAM Identity Center複数アカウントの SSO アクセス (旧 AWS SSO)

「新しいアカウントに自動でセキュリティのベースラインを適用し、SSO でアクセスを統合せよ」の答えが Control Tower + Identity Center です。運用者がアカウントごとに IAM ユーザーを作る代わりに、Identity Center で一度ログインして複数のアカウント·ロールにアクセスする のが推奨パターンです。

試験での出題パターン #

  • 古いキー·MFA 未設定のユーザーを検知 → Credential Report
  • 未使用の権限を回収 → Access Advisor (最終使用情報)
  • 外部に誤って公開されたリソースを検知 → IAM Access Analyzer
  • MFA なしでは操作を拒否 → ポリシー Condition aws:MultiFactorAuthPresent
  • 全アカウントにリージョン·サービスのガードレール → SCP
  • 新規アカウントの自動標準化 + SSO → Control Tower + IAM Identity Center
  • 全アカウントに標準スタック → StackSets

よくある落とし穴 #

1) SCP が権限を付与すると考える #

SCP は 上限 です。権限は IAM ポリシーが与えます。両者の積集合が実際の権限です。

2) Management アカウントも SCP で止まると誤解 #

SCP は Management アカウントに適用されません。だから日常作業はメンバーアカウントで行います。

3) アカウントごとに IAM ユーザーを作る #

マルチアカウントアクセスの定石は IAM Identity Center (SSO) です。アカウントごとにユーザーを複製するのは運用負担が大きいです。

4) ルートアカウントで日常作業 #

ルートは MFA を有効化して封印します。日常はロール·Identity Center で行います。

まとめ #

この記事で押さえたこと:

  • IAM 運用は 最小権限 の維持が常時の課題。Credential Report·Access Advisor で点検
  • IAM Access Analyzer で外部公開リソースを検知
  • MFA の強制はポリシー aws:MultiFactorAuthPresent 条件。ルートは MFA + 封印
  • Organizations + SCP でマルチアカウントのガードレール。SCP は 付与ではなく上限、Management アカウントには非適用
  • Control Tower (ランディングゾーン)·IAM Identity Center (SSO)·StackSets でマルチアカウントの標準化

次: Domain 5-2 検知と監査 #

ID とガバナンスを押さえたので、次は 何が起きたかを追跡·検知するツール です。

#13 Domain 5-2 セキュリティ: Config·CloudTrail·GuardDuty·Security Hub·KMS では、CloudTrail で API を監査する方法、Config で構成の準拠を評価する方法、GuardDuty の脅威検知、Security Hub の統合スコア、そして KMS の暗号化運用まで整理します。

X