WEB問題集
ある企業はAWS Organizationsで複数のAWSアカウントを運用しています。セキュリティ部門は、メンバーアカウントに含まれるすべてのIAMユーザーがルートアカウントのアクセスキーを作成できないように、組織全体で予防的な統制を実装したいと考えています。最も少ない運用負荷でこの要件を満たす方法はどれですか。
正解：B
正解の根拠
SCPはOrganizationsでメンバーアカウントのアクションを予防的に制御する唯一のメカニズムであり、aws:PrincipalArnの条件キーでrootユーザーのみを対象にiam:CreateAccessKeyを拒否することで、APIコール自体をブロックできます。
SCPでのroot制御例
| 要素 | 値 |
|---|---|
| Effect | Deny |
| Action | iam:CreateAccessKey |
| Condition | StringLike aws:PrincipalArn /root |
不正解の理由
- A: Configルールは検出後の事後対応であり、作成自体を防止できないため予防的統制になりません。
- C: ログインの通知のみで、アクセスキー作成のAPI呼び出しを防止しません。
- D: Control Towerが個別CFNでスクリプト実行する仕組みではなく、削除運用は事後的です。
セキュリティエンジニアはAWS Control Towerを使用して新しいランディングゾーンを構築しました。組織内のすべてのアカウントで、CloudTrailのログファイル検証が無効化されないように制御したいと考えています。最も適切な方法はどれですか。
正解：C
正解の根拠
Control Towerの必須コントロールDisallow changes to logging configuration for AWS CloudTrailは、すべての登録済みOUに自動適用され、ログファイル検証を含むCloudTrail設定の変更を予防的にブロックします。これがControl Towerの設計上正しい統制方法です。
Control Towerコントロール種別
| 種別 | 動作 |
|---|---|
| 予防的 | SCPでアクション拒否 |
| 発見的 | Configルールで違反検出 |
| プロアクティブ | CFNフックで作成前阻止 |
不正解の理由
- A: 暗号化設定のコントロールであり、ログファイル検証保護の目的とは異なります。
- B: Configルールは発見的検出のみで、変更自体を予防的に阻止することができません。
- D: 自動修復の運用負荷が高く、アクション競合のリスクもあり推奨されません。
ある企業はAWS Organizationsを利用しており、ProductionとSandboxの2つのOUを保有します。Sandbox OU内のアカウントでは、コスト管理のためEC2のインスタンスタイプをt3.microおよびt3.smallのみに制限したいと考えています。どのSCPが最も適切ですか。
正解：C
正解の根拠
SCPはDeny戦略が一般的で、ec2:InstanceTypeの条件キーをStringNotEqualsで使うと、許可リスト以外のタイプを起動するAPIコールが組織レベルで拒否されます。これはAWSが推奨するガードレール設計パターンです。
SCP条件キー例
| 項目 | 値 |
|---|---|
| Effect | Deny |
| Action | ec2:RunInstances |
| Condition | StringNotEquals ec2:InstanceType |
不正解の理由
- A: SCPのAllow戦略はFullAWSAccessとの組み合わせが必要で、設計が複雑化します。
- B: SCPを削除すると組織レベルのガードレールが失われ、IAM制御では一貫性がありません。
- D: ec2:RunInstancesのResourceにインスタンスタイプは記述できず、構文として無効です。
ある企業はAWS Organizationsで200以上のアカウントを管理しています。すべてのアカウントの全リージョンでConfigルールの評価結果を一元的に確認したいと考えています。最も少ない運用負荷でこれを実現する方法はどれですか。
正解：A
正解の根拠
AWS ConfigのAggregatorは、Organizations統合により全アカウント・全リージョンの評価結果を委任管理者アカウントに集約する目的のために設計されており、最も少ない運用負荷で実現できます。
Aggregatorのソース種別
| ソース | 用途 |
|---|---|
| 個別アカウント | 少数アカウント向け |
| Organizations | 全アカウント自動集約 |
不正解の理由
- B: カスタム集約パイプラインの構築・運用負荷が高く、Aggregatorの再実装が必要となります。
- C: Security HubはConfig評価を統合しますが、Configの一元参照にはAggregatorが適切です。
- D: Audit Managerはコンプライアンス評価用途で、Config一元参照には過剰な機能となります。
セキュリティエンジニアは、AWS Organizations配下の全アカウントに対してPCI DSSコンプライアンスを継続的にモニタリングする必要があります。すべてのアカウントで一貫した管理項目を評価し、結果を委任管理者で集約する最も効率的な方法はどれですか。
正解：D
正解の根拠
AWS Configの組織コンフォーマンスパックは、Organizations配下の全アカウントに同じパックを一括展開でき、PCI-DSS Operational Best Practicesなどのサンプルテンプレートをそのまま使えるため最も効率的です。
サンプルパック例
| パック | 用途 |
|---|---|
| PCI-DSS | カード情報処理 |
| HIPAA Security | 医療情報 |
| NIST CSF | サイバー保護 |
| FedRAMP Moderate | 政府機関 |
不正解の理由
- A: カスタムスクリプトで運用負荷が高く、コンフォーマンスパックの再実装になります。
- B: Audit Managerは目的に近いですが、個別有効化と手動集約は運用効率が劣ります。
- C: Security Hubも有効ですが、Config組織パックがPCI評価項目を統一展開する点で優位です。