WEB問題集
解説
正解の根拠
S3用のVPCエンドポイント(ゲートウェイエンドポイント)を使用すると、VPC内のEC2からS3への通信がAWSバックボーン経由になり、パブリックインターネットを通過しません。これによりCISOの指示するインターネット非経由要件を満たせ、暗号化済みオブジェクトとの組み合わせで通信経路と保管の両面で保護できます。
機能の役割
| 機能 | 役割 |
|---|---|
| VPCエンドポイント(B) | S3への内部経路を提供 |
| KMS | 暗号化キー管理 |
| プライベートサブネット | パブリックIPなし |
| VGW | VPN/DX用ゲートウェイ |
不正解の理由
- A: KMSは保管時暗号化のためのキー管理で、ネットワーク経路をインターネット非経由にする機能はありません。
- C: プライベートサブネットだけではS3アクセスがNAT Gatewayを介してインターネットに出てしまいます。
- D: 仮想プライベートゲートウェイはオンプレ接続用で、S3との通信経路を提供する機能ではありません。
あるスタートアップは S3 バケットに顧客がアップロードする CSV データを保管しています。アップロードデータに個人識別情報 (PII) やクレジットカード番号が含まれていないかを定期的に検査し、検出された場合は Security Hub に通知したいと考えています。最も適切なサービスはどれですか？
解説
正解の根拠
Amazon Macie は機械学習とパターンマッチングで S3 バケット内のオブジェクトを定期スキャンし、個人識別情報 (PII) やクレジットカード番号などの機微データを自動検出するマネージドサービスです。検出結果は AWS Security Hub に連携でき、一元的に通知・管理できます。独自インフラを構築せずに継続的な機微データ検査と通知の要件を満たせます。
不正解の理由
- A: GuardDuty は脅威検知が目的で、S3 アクセスログから PII の内容を解析する機能は持ちません。
- B: Inspector は EC2/ECR/Lambda の脆弱性スキャン用で、S3 オブジェクト内の PII 抽出はできません。
- D: Config Custom Rule と Lambda の自前解析は構築・保守の負荷が高く、Macie のマネージド検出に劣ります。
参考：Amazon Macie
あるメディア企業は、本番 AWS アカウントで稼働する EC2 インスタンス上のアプリケーションから、別アカウントにある Amazon S3 バケットにレポートをアップロードしています。現在は IAM ユーザーのアクセスキーをアプリケーション設定ファイルに埋め込んでいますが、セキュリティ監査で長期的な認証情報の利用を排除するよう指摘されました。最も適切で運用負荷が小さい方法はどれですか？
解説
正解の根拠
EC2 に IAM ロールをアタッチすると、インスタンスメタデータ経由で短期的な一時認証情報が自動的にローテーションされ、長期キーをコード上に保持する必要がなくなります。クロスアカウントでは、ロール側に対象バケットの権限を付与し、バケットポリシー側で当該ロール ARN を Principal として許可することで双方向の信頼が成立します。
アプローチ比較
| 項目 | IAM ロール + バケットポリシー | IAM ユーザーキー |
|---|---|---|
| 認証情報のローテーション | 自動 (1 時間程度) | 手動または独自実装 |
| 漏えいリスク | 低 (短期トークン) | 高 (長期キー) |
| 運用負荷 | 小 | 大 |
不正解の理由
- B: Secrets Manager に長期キーを保管しても根本的に長期認証情報を排除できず、運用負荷も大きくなります。
- C: 自動ローテーションを組んでも、長期キーの存在自体がセキュリティ要件に反します。
- D: ユーザーデータからの復号は再起動のたびに復号鍵管理が必要で、平文化リスクも残ります。
解説
正解の根拠
マルチアカウントでDynamoDBを共有する標準パターンは、各ビジネスアカウントにDynamoDBアクセス用ロール(BU_ROLE)を作成し、その信頼ポリシーで在庫アプリ用ロール(APP_ROLE)を許可する構成です。アプリはAPP_ROLEからsts:AssumeRoleでBU_ROLEを引き受け一時クレデンシャルでDynamoDBを読み取れるため、長期キーの保管不要かつ最小権限を維持できます。
認証方式比較
| 方式 | セキュリティ |
|---|---|
| クロスアカウントロール+AssumeRole(C) | 高 |
| アクセスキー共有(B) | 低 |
| Secrets Manager+アクセスキー(A) | 長期キーで低 |
| ACM証明書(D) | 非対応 |
不正解の理由
- A: Secrets Managerに保存しても中身はIAMユーザーの長期的なアクセスキーで、ロールの一時的な認証情報より劣ります。
- B: 各アカウントにIAMユーザーを作りキーを共有/手動ローテーションするのは典型的なアンチパターンです。
- D: DynamoDBはACM証明書による認証をサポートしておらず、構成として成立しません。
参考：クロスアカウントロール
あるヘルスケアスタートアップは、複数の AWS アカウントを利用しており、セキュリティ調査結果 (GuardDuty、Inspector、Macie、Config の検出結果) を 1 つの管理アカウントで一元的に確認したいと考えています。さらに業界標準ベンチマーク (CIS や PCI DSS) に対するスコアも自動算出したいと考えています。最も適切なサービスはどれですか？
解説
正解の根拠
AWS Security Hub はマルチアカウントのセキュリティ調査結果を 1 か所に集約するサービスで、GuardDuty、Inspector、Macie、Config 等の検出結果を ASFF 形式で標準化して取り込みます。CIS AWS Foundations Benchmark や PCI DSS、AWS Foundational Security Best Practices などのコントロールを自動評価しスコアを表示するため、本シナリオの要件を最も適切に満たします。
サービス比較
| 項目 | Security Hub | Detective |
|---|---|---|
| 主目的 | 調査結果集約 / ベンチマーク | 検出結果の調査と相関 |
| マルチアカウント | Organizations 連携 | マスター/メンバー方式 |
| ベンチマーク | CIS/PCI/FSBP | 非対応 |
不正解の理由
- B: Trusted Advisor はベストプラクティスチェック中心で、複数セキュリティサービスの集約とベンチマーク評価は対象外です。
- C: Detective は調査と分析の補助で、ベンチマーク自動評価機能は持ちません。
- D: Config Aggregator は構成集約は可能ですが、CIS/PCI のような業界ベンチマークの標準実装は提供しません。