AWS Security Specialty (SCS-C02) 模擬試験 65問

A) GuardDutyの検出結果をSNSに送信し、オペレーターが手動で対処する B) EventBridgeルールでGuardDutyの検出結果をキャプチャしてLambda関数をトリガーし、SGを変更して隔離しEBSスナップショットを作成する C) CloudTrailログを分析して手動でIPをブロックする D) AWS ConfigルールでコンプライアンスのないインスタンスをDetectする

答え: B

解説: EventBridge → Lambdaパターンは、GuardDuty検出結果への自動対応の標準です。Lambdaはインスタンスのセキュリティグループを隔離専用SG(全トラフィックを拒否)に置き換え、CreateSnapshot APIを呼び出してフォレンジック用EBSスナップショットを作成します。SSM Run Commandでメモリダンプも収集できます。

A) EC2インスタンスにBitcoinマイニングソフトウェアがインストールされている B) EC2インスタンスがBitcoinマイニングプールに関連するIPアドレスと通信している C) アカウントで異常なコストが発生している D) IAMユーザーが暗号通貨関連のAPIを呼び出している

答え: B

解説: CryptoCurrency:EC2/BitcoinTool.BはEC2インスタンスが既知のBitcoin関連活動と関連するIPアドレスまたはドメインと通信していることを示します。GuardDutyは脅威インテリジェンスフィードを使用して、既知の悪意あるIP/ドメインとの通信を検出します。

A) 各アカウントでGuardDuty S3エクスポートを設定し、中央バケットにレプリケートする B) GuardDutyの委任管理者アカウントを指定し、Organizations全体のメンバーアカウントを自動登録する C) Security HubでGuardDutyの検出結果を集約する D) CloudWatch Eventsを使用して検出結果を中央アカウントに転送する

答え: B

解説: AWS OrganizationsでGuardDutyの委任管理者を指定すると、全メンバーアカウントの検出結果が管理アカウントに自動集約されます。Organizationsに新しいアカウントが追加されると、自動的にGuardDutyが有効化されます。Security Hubも検出結果を集約しますが、GuardDuty自体のマルチアカウント機能がより完全なソリューションです。

A) VPC Flow Logs B) CloudTrailログ C) GuardDutyの検出結果 D) AWS Configの変更履歴

答え: D

解説: Amazon DetectiveはVPC Flow Logs、CloudTrailログ、GuardDuty検出結果を自動的に収集・分析します。AWS Configの変更履歴はDetectiveのデータソースではありません。Detectiveはグラフベース分析を使用してエンティティ(IP、AWSアカウント、EC2インスタンス)間の関係を可視化します。

A) アカウントを即座に削除する B) 該当インスタンスを終了させる C) インスタンスを隔離セキュリティグループに移動し、スナップショットを作成してから調査する D) AWS Supportに連絡してインスタンスのブロックを要請する

答え: C

解説: インスタンスを即座に終了するとフォレンジック証拠が破壊されます。正しいアプローチは、すべてのインバウンド/アウトバウンドトラフィックをブロックする隔離SGにインスタンスを移動し、フォレンジック分析用にEBSスナップショットを作成して保存することです。SSM Session Manager(VPCエンドポイント経由)でインスタンスの分析を継続できます。

A) ルートアカウントでMFAが有効化されているか B) CloudTrailのマルチリージョンが有効化されているか C) VPC Flow Logsが有効化されているか D) EC2インスタンスが最新のAMIを使用しているか

答え: D

解説: CIS AWS Foundations BenchmarkはIAM、ロギング、モニタリング、ネットワーキングに関する基本的なセキュリティ設定を確認します。ルートMFA、CloudTrailマルチリージョン、VPC Flow LogsはすべてCISベンチマーク項目です。最新AMIの使用確認はAmazon Inspectorの領域です。

A) S3バケットにアップロードされたファイル B) EC2インスタンスおよびコンテナワークロードに接続されたEBSボリューム C) Lambda関数のコード D) RDSデータベースファイル

答え: B

解説: GuardDuty Malware ProtectionはEC2インスタンスおよびECS/EKSコンテナワークロードに接続されたEBSボリュームをスキャンしてマルウェアを検出します。エージェントなしでEBSボリュームスナップショットを作成し、隔離された環境でスキャンします。S3オブジェクトスキャンは別のGuardDuty S3 Protection機能です。

A) 管理イベント(Management Events) B) データイベント(Data Events) C) インサイトイベント(Insights Events) D) ネットワークアクティビティイベント

答え: B

解説: CloudTrailデータイベントは、S3バケット内のオブジェクトレベルの操作(GetObject、PutObject、DeleteObject)やLambda関数の呼び出し、DynamoDB操作などリソースへの直接操作をログに記録します。管理イベントはアカウントのコントロールプレーン操作(インスタンス作成、IAMポリシー変更など)をログに記録します。

A) 悪意あるIPからのAPI呼び出し B) IAMポリシー違反 C) API呼び出し頻度の異常な急増または減少 D) 失敗した認証試行

答え: C

解説: CloudTrail Insightsはアカウントのいつも通りのAPI使用パターンを分析し、異常な活動(例: DeleteSecurityGroupの突然の急増)を検出します。正常なベースラインを自動学習し、逸脱した場合にInsightsイベントを生成します。GuardDutyは悪意あるIP検出を、IAM Access Analyzerはポリシー分析を担当します。

A) 内部システム間の正常な通信 B) インターネットからEC2インスタンスへのRDPアクセスが許可されている — 潜在的なセキュリティ脆弱性 C) VPNを介したリモートアクセス D) NAT Gatewayを介したアウトバウンドトラフィック

答え: B

解説: 203.0.113.1はパブリックIPアドレスで、dstport 3389はRDP(リモートデスクトッププロトコル)です。ACCEPTはこのトラフィックが許可されたことを意味します。インターネットから直接RDPアクセスが許可されているのは深刻なセキュリティ脆弱性です。RDPはVPNまたはSession Manager経由でのみアクセスすべきです。

A) S3サーバーアクセスログ B) CloudTrail S3データイベント C) CloudWatchメトリクス D) VPC Flow Logs

答え: B

解説: CloudTrail S3データイベントはDeleteObjectを含むS3バケットのオブジェクトレベル操作をログに記録し、誰が(IAMユーザー/ロール)、いつ、どこから(IP)、どのオブジェクトを削除したかの正確な監査証跡を提供します。S3サーバーアクセスログも削除を記録しますが、CloudTrailほど詳細なIAMコンテキストを提供しません。

A) SQLインジェクション攻撃 B) DNSトンネリングによるデータ漏洩 C) ネットワークポートスキャン D) バッファオーバーフロー攻撃

答え: B

解説: DNSクエリログを分析することで、DNSトンネリング(DNSクエリ/レスポンスにデータをエンコードして送信)、C2(コマンド＆コントロール)サーバーとの通信、既知の悪意あるドメインへのアクセスを検出できます。異常に長いDNSクエリ名や高いクエリ頻度はDNSトンネリングの兆候です。

A) filter userIdentity.type = "Root" で始まるクエリのみ有効 B) CloudWatchメトリクスフィルターのみ有効 C) S3上のCloudTrailログに対するAthenaクエリのみ有効 D) 上記すべての方法が可能

答え: D

解説: ルートアカウント使用の検出は複数の方法で可能です。CloudWatch Logs Insightsはリアルタイムのインタラクティブクエリに適し、CloudWatchメトリクスフィルターは継続的なモニタリングとアラームに適し、Athenaは大規模な長期ログ分析に適しています。CISベンチマークはルートアカウント使用時にアラームを設定するよう推奨しています。

A) WAFルールの優先順位エラー B) ALBの前にCloudFrontがなく、WAFはCloudFrontレベルにのみ適用されている C) WAFがALBではなくAPI Gatewayに関連付けられている D) IPセットの更新がまだ伝播されていない

答え: C

解説: WAFは特定のリソース(ALB、CloudFront、API Gateway、AppSync)に関連付けられます。WAFがAPI Gatewayにのみ関連付けられている場合、ALBは保護されません。ALBを保護するにはWAF Web ACLをALBに直接関連付ける必要があります。また、WAFはリージョナル(ALB用)またはグローバル(CloudFront用)に区別されます。

A) NACLはステートフルでSGはステートレス B) SGはステートフルでNACLはステートレス。NACLはアウトバウンドのエフェメラルポート(1024-65535)を明示的に許可する必要がある C) 両サービスともステートフルで動作する D) SGはサブネットレベル、NACLはインスタンスレベルで適用される

答え: B

解説: セキュリティグループはステートフル(stateful)で、返信トラフィックを自動的に許可します。NACLはステートレス(stateless)で、インバウンドとアウトバウンドをそれぞれ別々に設定する必要があります。クライアントが80番ポートにリクエストを送信すると、サーバーの応答はクライアントのエフェメラルポート(1024-65535)に戻るため、NACLアウトバウンドでこの範囲を許可する必要があります。

A) ALLOW tcp any any -> 10.0.0.0/8 80 B) alert http any any -> any any (msg:"Blocked User-Agent"; http.user_agent; content:"BadBot"; sid:1000001;) C) DENY UDP 0.0.0.0/0 53 any any D) block tcp external any to internal 443

答え: B

解説: AWS Network FirewallのステートフルルールエンジンはSuricata互換ルールをサポートします。正しいSuricataルール形式は: action protocol src_ip src_port direction dst_ip dst_port (options)です。例Bは特定のUser-Agentを含むHTTPリクエストを検出するルールです。

A) AWS SupportにDDoS攻撃を報告する B) Shield Advancedコンソールでコスト保護機能を有効化し、DRT(DDoS Response Team)の介入を要請する C) AWS Cost Explorerで異常検出を有効化する D) Trusted Advisorのコスト最適化推奨事項を確認する

答え: B

解説: Shield AdvancedはDDoS攻撃によるEC2、ELB、CloudFront、Route 53のコスト急増に対するサービスクレジットを提供します。対象リソースにShield Advanced保護が有効化されており、DRTが攻撃を確認する必要があります。DRTはリアルタイムの攻撃緩和を支援する専門チームです。

A) IAMポリシーでimds:GetTokenを拒否する B) EC2インスタンス起動時にHttpTokens=requiredを設定するか、既存インスタンスでmodify-instance-metadata-optionsコマンドを実行する C) VPCエンドポイントでメタデータサービスへのアクセスを制限する D) セキュリティグループで169.254.169.254へのトラフィックをブロックする

答え: B

解説: IMDSv2はセッション指向の方式で、最初にPUTリクエストでトークンを取得し、GETリクエストにそのトークンを含める必要があります。これによりSSRF(サーバーサイドリクエストフォージェリ)攻撃からメタデータを保護します。既存インスタンスは aws ec2 modify-instance-metadata-options --http-tokens required コマンドで強制適用できます。

A) すべてのアカウントでAWS Configを有効化する B) AWS Organizationsの有効化、Firewall Manager管理者アカウントの指定、各アカウントでAWS Configの有効化 C) Security Hubの有効化とCIS標準の適用 D) GuardDutyの有効化と委任管理者の指定

答え: B

解説: AWS Firewall Manager使用の前提条件: 1) AWS Organizationsの有効化、2) Organizations管理アカウントからFirewall Manager管理者アカウントの指定、3) ポリシーを適用するすべてのアカウントでAWS Configの有効化。AWS ConfigはFirewall Managerがリソース設定を評価してポリシーを適用するために必要です。

A) Webアプリケーションのロードバランシング B) サードパーティのネットワーク仮想アプライアンス(IDS/IPS、ファイアウォール)を透過的に挿入してトラフィックを検査する C) API Gatewayリクエストの分散 D) データベース接続プーリング

答え: B

解説: Gateway Load BalancerはGENEVEプロトコルを使用して、トラフィックをサードパーティのネットワーク仮想アプライアンス(Palo Alto、Fortinetなど)に送って検査した後、元の宛先に転送します。パケットレベルの透過的なトラフィック検査が可能で、アプライアンスの水平スケーリングをサポートします。

A) NAT Gatewayを使用する B) S3ゲートウェイエンドポイントを作成し、ルーティングテーブルに追加する C) VPN接続を設定する D) CloudFrontでS3の前にキャッシングレイヤーを構成する

答え: B

解説: S3ゲートウェイエンドポイントは無料で、VPCからS3へのトラフィックがAWSネットワーク内のみで移動するようにします。ルーティングテーブルにS3エンドポイントのルートを追加すると、インターネットゲートウェイやNAT Gatewayを経由しません。バケットポリシーに aws:SourceVpce 条件を使用して、特定のVPCエンドポイントからのみアクセスを制限することもできます。

A) Allow → Deny → デフォルト拒否 B) 明示的Deny → Organizations SCP → 権限境界 → セッションポリシー → IDベースポリシー → リソースベースポリシー → デフォルト拒否 C) リソースポリシー → IAMポリシー → SCP → デフォルト許可 D) 権限境界 → SCP → IAMポリシー → デフォルト拒否

答え: B

解説: IAMポリシー評価ロジック: 1) 明示的Denyがあれば即座に拒否、2) Organizations SCPが許可する必要がある、3) 権限境界(Permission Boundary)が許可する必要がある、4) セッションポリシーが許可する必要がある、5) IDベースポリシーまたはリソースベースポリシーのいずれかが許可すれば許可(同一アカウント)、6) 上記条件を満たさない場合はデフォルト拒否。

A) 開発者のアカウントにのみIAMポリシーを設定する B) ターゲットアカウントのロール信頼ポリシーに開発者アカウントをPrincipalとして指定し、開発者のIAMユーザー/ロールにsts:AssumeRoleを許可する C) 2つのアカウント間でVPCピアリングを設定する D) AWS Direct Connectで2つのアカウントを接続する

答え: B

解説: クロスアカウントアクセスには双方向の信頼が必要です: 1) ターゲットアカウントのIAMロール信頼ポリシー(Trust Policy)にソースアカウントまたは特定のIAMエンティティをPrincipalとして指定、2) ソースアカウントのIAMユーザー/ロールにターゲットロールへのsts:AssumeRole権限を付与。両方の条件が満たされる必要があります。

A) IAMユーザーが最大で受け取れる権限を定義し、権限境界内のすべての操作が自動的に許可される B) IAMエンティティに付与できる最大権限を定義する高度な機能で、実効権限は権限境界とIDベースポリシーの積集合 C) リソースへのアクセスを許可する追加の権限付与メカニズム D) Organizations SCPと同じ機能

答え: B

解説: 権限境界はIAMユーザーまたはロールに付与できる最大権限の上限を設定します。実効権限は権限境界とIDベースポリシーの積集合(AND)です。権限境界だけでは権限が付与されず、IDベースポリシーと一緒に使用する必要があります。開発者にIAM管理権限を委任しながら過剰な権限付与を防ぐのに有用です。

A) ユーザープールはAWSリソースアクセス用の一時認証情報を提供し、IDプールはユーザーディレクトリを管理する B) ユーザープールはユーザー認証とディレクトリ管理(ログイン、登録、MFA)を担当し、IDプールは認証済みユーザーにAWSの一時認証情報を付与する C) ユーザープールはモバイルアプリ専用、IDプールはWebアプリ専用 D) 両機能は同一でユースケースによって選択する

答え: B

解説: Cognitoユーザープールはユーザー認証サービスです(JWTトークン発行、ユーザー登録/ログイン、MFA、ソーシャルログイン連携)。Cognito IDプールはユーザープールのトークンやソーシャルIdPのトークンを受け取り、AWS STSを通じてAWSの一時認証情報(アクセスキー、シークレットキー、セッショントークン)に交換します。2つのサービスは通常一緒に使用されます。

A) はい、SCPはすべてのエンティティに適用される B) いいえ、SCPは管理アカウントには適用されない C) はい、ただしルートユーザーはSCPを回避できる特権がある D) Organizations設定によって異なる

答え: B

解説: SCPはメンバーアカウントのIAMユーザー、ロール、ルートユーザーに適用されます。ただし、OrganizationsのManagement Account(マスターアカウント)にはSCPは適用されません。これが管理アカウントで機密操作を行わないよう推奨される理由の一つです。管理アカウントはOrganizations管理目的にのみ使用すべきです。

A) IAMポリシーの構文エラーの検出 B) 外部エンティティ(他のアカウント、インターネット)と共有されているAWSリソースの識別 C) 使用されていないIAM権限の識別 D) ルートアカウントアクティビティのモニタリング

答え: B

解説: IAM Access Analyzerは、信頼ゾーン(信頼するアカウントの範囲)外部のエンティティがアクセスできるリソースを識別します。S3バケット、IAMロール、KMSキー、Lambda関数、SQSキュー、Secrets Managerシークレットなどが分析対象です。公開アクセス可能なS3バケットや他のアカウントがAssumeできるIAMロールなどを検出します。

A) ユーザー → AWS → ADFS → 認証情報検証 → AWSコンソール B) ユーザー → ADFS認証 → SAMLアサーション → AWS STS AssumeRoleWithSAML → 一時認証情報 → AWSコンソール C) ユーザー → Cognito → ADFS → AWSコンソール D) ユーザー → AWS IAM → ADFS → コンソール

答え: B

解説: SAMLフェデレーションのフロー: 1) ユーザーがADFSで認証、2) ADFSがSAMLアサーション(ロール情報を含む)を発行、3) ユーザーのブラウザがSAMLアサーションをAWS STSのAssumeRoleWithSAMLエンドポイントに送信、4) STSが一時認証情報を発行、5) AWSコンソールにアクセス。AWS IAMでIdPをSAMLプロバイダーとして登録する必要があります。

A) IAMポリシーだけでCMK使用権限を付与できる B) キーポリシーが優先され、IAMポリシーは無視される C) キーポリシーでIAMの使用を明示的に許可することで、IAMポリシーによるCMKのアクセス制御が可能になる D) キーポリシーとIAMポリシーは独立して動作する

答え: C

解説: KMS CMKのアクセスは、キーポリシーなしではIAMポリシーだけでは制御できません。キーポリシーに "Principal": {"AWS": "arn:aws:iam::ACCOUNT-ID:root"} と kms:* の許可がある場合に限り、そのアカウントのIAMポリシーでCMKを制御できます。デフォルトキーポリシーはルートアカウントへの完全アクセスを許可し、IAMポリシーの使用を可能にします。

A) データを2つの異なるKMSキーで二重暗号化する B) KMS CMK(データキー暗号化キー)でデータキーを暗号化し、データキーで実際のデータを暗号化して、暗号化されたデータキーをデータと一緒に保存する C) データをS3に保存してからKMSでバケットを暗号化する D) SSL/TLSで転送中のデータを保護する

答え: B

解説: エンベロープ暗号化のフロー: 1) KMS GenerateDataKey APIで平文データキーと暗号化されたデータキーを取得、2) 平文データキーでデータを暗号化、3) 平文データキーをメモリから即座に削除、4) 暗号化されたデータキーを暗号化されたデータの隣に保存。復号化時はKMS Decryptでデータキーを復号化してからデータを復号化します。大容量データをKMSで直接暗号化すると4KBの制限に引っかかるため、エンベロープ暗号化を使用します。

A) s3:PutObject権限のみ必要 B) s3:PutObjectとkms:GenerateDataKeyの両方が必要 C) s3:PutObject、kms:GenerateDataKey、kms:Decryptの3つすべてが必要 D) kms:Encrypt権限のみ必要

答え: B

解説: SSE-KMS暗号化でS3にオブジェクトをアップロードする際: 1) s3:PutObject - S3にオブジェクトを書き込む権限、2) kms:GenerateDataKey - KMSでデータキーを生成する権限。ダウンロード時は s3:GetObject と kms:Decrypt が必要です。

A) コストを最小化する必要がある場合 B) FIPS 140-2 Level 3認定ハードウェア、シングルテナントHSM、キーへの完全な制御が必要な場合、またはOracle TDE、PKCS#11が必要な場合 C) 簡単なS3暗号化が必要な場合 D) 自動キーローテーションが必要な場合

答え: B

解説: CloudHSMを選択する場合: 1) FIPS 140-2 Level 3認定が必要(KMSはLevel 2)、2) シングルテナント専用HSMが必要、3) AWSがキーマテリアルにアクセスできないようにする規制要件、4) OracleデータベースのTDE(透過的データ暗号化)、5) PKCS#11、JCE、CNG APIサポートが必要。KMSは管理の容易さとAWSサービスとの統合に強みがあります。

A) クレジットカード番号 B) AWSアクセスキー C) 社会保障番号(SSN) D) 暗号化されたパスワードハッシュ

答え: D

解説: Amazon Macieは機械学習を使用してS3の機密データを自動検出します。検出可能なタイプ: PII(SSN、パスポート番号、運転免許証番号)、財務情報(クレジットカード番号、銀行口座番号)、認証情報(AWSアクセスキー、APIキー、OAuthトークン)、医療情報など。暗号化されたハッシュは元のデータを識別できないため、機密データに分類されません。

A) Secrets ManagerだけがKMS暗号化をサポートする B) Secrets Managerは自動ローテーション、クロスアカウントアクセス、RDS/Redshift/DocumentDBのネイティブ統合を提供し有料で、Parameter Store SecureStringは無料だが自動ローテーション機能なし C) Parameter Storeの方が多くのサービスと統合されている D) 2つのサービスは機能が同一で価格のみ異なる

答え: B

解説: Secrets Managerの主な利点: 1) 自動シークレットローテーション(Lambda関数を使用)、2) RDS、Redshift、DocumentDBのパスワード自動ローテーションのネイティブサポート、3) クロスアカウントアクセスのサポート、4) シークレットバージョン管理。コストはシークレットあたり月約0.40 USD。Parameter Store SecureStringは無料(標準パラメーター)、KMS暗号化サポート、ただし自動ローテーション機能なし。データベースパスワードはSecrets Manager、設定値はParameter Storeを推奨。

A) 2つのS3バケットに同時にデータを保存する場合 B) CNSSI 1253およびFIPS 200で要求される二重暗号化レイヤーが必要な場合(S3オブジェクトを2つの独立した暗号化レイヤーで保護) C) クライアント側とサーバー側の暗号化を同時に適用する場合 D) 複数のAWSリージョンにデータをレプリケートする場合

答え: B

解説: DSSE-KMSはS3オブジェクトに2つの独立したKMS暗号化レイヤーを適用します。米国政府機関など特定のコンプライアンス要件(CNSSI 1253、DoD Mission Assurance Category)で二重暗号化が要求される場合に使用します。各レイヤーは独立したデータ暗号化キー(DEK)を使用します。

A) AWS Configが直接リソースを修正する B) ConfigルールがSSM自動化ドキュメントをトリガーして修復アクションを実行する C) Lambda関数が直接呼び出される D) CloudFormation StackSetsで修復する

答え: B

解説: AWS Configの自動修復はSSM(Systems Manager)自動化ドキュメントを使用します。Configルールに修復アクションを関連付けると、コンプライアンスのないリソースが検出された際に指定されたSSM自動化ドキュメントが実行されます。例: s3-bucket-public-read-prohibitedルール違反時にAWS-DisableS3BucketPublicReadWrite自動化ドキュメントを実行してパブリックアクセスをブロックします。

A) EC2インスタンスOSの脆弱性(CVE) B) ECRコンテナイメージの脆弱性 C) Lambda関数コードの脆弱性 D) S3バケット設定の脆弱性

答え: D

解説: Amazon Inspector v2のスキャン対象: 1) EC2インスタンス - OSパッケージの脆弱性(CVE)とネットワーク露出、2) ECRコンテナイメージ - イメージのOSパッケージの脆弱性、3) Lambda関数 - 関数コードとレイヤーのソフトウェア脆弱性。S3バケット設定はAWS ConfigやSecurity Hubで確認します。

A) 予防的ガードレールはAWS Configルールを使用し、検出的ガードレールはSCPを使用する B) 予防的ガードレールはSCPで特定のアクションを完全にブロックし、検出的ガードレールはAWS Configルールでコンプライアンスのない状態を検出して報告する C) 2つのタイプは同一で名前だけが異なる D) 予防的はCloudWatchアラーム、検出的はEventBridgeルールを使用する

答え: B

解説: Control Towerガードレールのタイプ: 1) 予防的(Preventive) - SCPを使用してコンプライアンスのないアクション自体をブロック(例: ルートアカウントアクセスキーの作成禁止)、2) 検出的(Detective) - AWS Config管理ルールを使用してコンプライアンスのない状態を検出して通知(例: S3バケットのパブリック読み取りアクセスを検出)。予防的の方が強力ですが、すべてのポリシーを予防的に実装することは難しいです。

A) セキュリティ脆弱性の自動修復 B) 監査証拠を継続的に自動収集し、PCI-DSS、HIPAA、SOC 2などのコンプライアンスレポート作成を簡素化する C) アカウントのコスト分析と最適化 D) ネットワークトラフィック分析

答え: B

解説: AWS Audit ManagerはAWS Config、CloudTrail、Security Hubなどから監査証拠を自動収集して、コンプライアンスレポート作成を自動化します。PCI-DSS、HIPAA、GDPR、SOC 2、ISO 27001などの主要なフレームワークに対して事前構築された評価テンプレートを提供します。監査チームが手動で証拠を収集する時間を大幅に削減します。

A) IAMロールの権限を他のアカウントと共有する B) AWSリソース(サブネット、Transit Gateway、License Manager設定など)をOrganizations内の他のアカウントと共有し、重複リソースの作成を防ぐ C) S3バケット間のデータレプリケーション D) マルチアカウントCloudWatchダッシュボードの作成

答え: B

解説: AWS RAMはVPCサブネット、Transit Gateway、Route 53 Resolverルール、License Manager設定、AWS Glueカタログなどを、AWS Organizationsの他のアカウントや特定のアカウントと共有します。例: 中央ネットワーキングアカウントのVPCサブネットをアプリケーションアカウントと共有すると、各アカウントが同じサブネットにリソースをデプロイでき、中央集中型のネットワーク管理が可能になります。

A) 各アカウントで手動で設定する B) AWS Firewall Managerを使用して中央セキュリティポリシーを定義し、自動適用する C) CloudFormation StackSetsで各アカウントに設定をデプロイする D) AWS Config集約機能(Aggregator)でコンプライアンスのないアカウントを検出し、手動で修正する

答え: B

解説: AWS Firewall ManagerはOrganizations全体に一貫したセキュリティポリシーを自動的に適用します。サポートするポリシータイプ: 1) WAFポリシー(ALB、API GW、CloudFront)、2) Shield Advanced、3) VPCセキュリティグループポリシー、4) Network Firewall、5) Route 53 DNS Firewall、6) S3バケットポリシー。Organizationsに新しいアカウントが追加されると自動的にポリシーが適用されます。

A) UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B B) UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS C) Policy:IAMUser/RootCredentialUsage D) Recon:IAMUser/UserPermissions

答え: B

解説: GuardDutyは、EC2インスタンスメタデータを通じて発行された一時認証情報がそのインスタンス外部(異なるIP)で使用されるのを検出します。UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWSは、EC2ロール認証情報がAWS外部のIPで使用された際に発生します。これは認証情報の盗用(SSRF、インスタンス侵害など)の強力な指標です。

A) 待機期間中、データへのアクセスが即座に不可能になる B) 待機期間中はキーが無効化されて新しい暗号化は不可能だが、既存データの復号化は可能。キー削除後は永続的に復号化不可能 C) キー削除後、S3の自動キーローテーションで新しいキーに再暗号化される D) キー削除前にデータが自動的にSSE-S3に移行される

答え: B

解説: KMSキー削除の待機期間(7〜30日)中: キーは無効化状態になり、新しい暗号化操作には使用できませんが、このキーで暗号化された既存データの復号化は引き続き可能です。待機期間は誤った削除を防ぐための安全装置です。キーが完全に削除された後は、そのキーで暗号化されたデータを復号化する方法がありません。キーの無効化(Disable)はいつでも再有効化できるため、まず無効化を試みるべきです。

A) ssmエンドポイントのみ必要 B) com.amazonaws.region.ssm、com.amazonaws.region.ssmmessages、com.amazonaws.region.ec2messagesの3つのインターフェースエンドポイントが必要 C) S3ゲートウェイエンドポイントのみ必要 D) NAT Gatewayがあれば VPCエンドポイントは不要

答え: B

解説: PrivateサブネットでSSM Session Managerを使用するためのVPCエンドポイント: 1) com.amazonaws.region.ssm - SSMサービスの主要エンドポイント、2) com.amazonaws.region.ssmmessages - Session Managerチャネルの作成/管理、3) com.amazonaws.region.ec2messages - SSM AgentとSSMサービス間の通信。パッチ管理のために com.amazonaws.region.s3 ゲートウェイエンドポイントも推奨されます。

A) GitHub Actionsが自動的に管理者権限を取得する B) 長期間有効なAWS認証情報(アクセスキー)をGitHub Secretsに保存する必要なく、短期の一時認証情報を動的に取得できる C) AWSアカウント情報がGitHubと共有される D) すべてのGitHubワークフローに同じAWS権限が付与される

答え: B

解説: OIDC(OpenID Connect)連携によるGitHub ActionsのAWSアクセス: GitHubをIAM OIDCプロバイダーとして登録しIAMロールを設定することで、ワークフロー実行時にGitHubが発行したJWTトークンでAssumeRoleWithWebIdentityを呼び出して短期の一時認証情報を取得します。長期間有効なアクセスキーをGitHub Secretsに保存しないため、認証情報の漏洩リスクがありません。IAMロール信頼ポリシーで特定のリポジトリ/ブランチへのアクセスを制限できます。

A) aws:SourceVpc B) aws:SourceVpce C) aws:VpcId D) s3:VpcEndpoint

答え: B

解説: aws:SourceVpce は特定のVPCエンドポイントIDを通じたアクセスのみを許可します。aws:SourceVpc は特定のVPC IDを通じたアクセスを許可します。バケットポリシーでDeny all + Allow only via VpceIDパターンで、特定のVPCエンドポイントからのみアクセス可能なバケットを構成できます。

A) 永続的なアクセス権限が必要な場合 B) 一時的またはプログラム的に特定のAWSサービス(EBS、RDSなど)にキー使用権限を委任する場合 C) 他のアカウントからキーを管理する場合 D) キーの削除を防ぐ場合

答え: B

解説: KMSグラントは特定のプリンシパルにキーの特定操作(Decrypt、Encryptなど)のみを許可する一時的な権限です。AWSサービス(EBS、RDS、Redshift)がサービスリンクロールでカスタマーKMSキーを使用する際に自動的にグラントが作成されます。グラントはプログラム的に作成/取り消しできるため、柔軟なアクセス制御が可能です。RetireGrantまたはRevokeGrantで取り消します。

A) S3サーバーアクセスログを分析する B) AthenaでCloudTrailログにクエリを実行してDeleteObject/DeleteObjectsイベントを検索する C) CloudWatchメトリクスでS3削除操作を確認する D) VPC Flow Logsを分析する

答え: B

解説: CloudTrail + Athenaの組み合わせは大規模なログ分析に効果的です。CloudTrail S3データイベントが有効化されている必要があります。AthenaでCloudTrailログが保存されているS3をテーブルとして作成し、SELECT userIdentity.arn, eventTime, requestParameters.bucketName, requestParameters.key FROM cloudtrail_logs WHERE eventName IN ('DeleteObject', 'DeleteObjects') AND eventTime BETWEEN '...' AND '...' というようにクエリします。

A) インターネット信頼チェーンが自動的に含まれる B) 内部マイクロサービス間のmTLS、内部アプリケーション用のプライベート証明書発行が可能で、プライベートCA階層の管理ができる C) 無料で使用できる D) すべてのパブリックドメインに証明書を発行できる

答え: B

解説: ACMプライベートCA(Certificate Authority)は組織内部のPKIインフラを構築します。内部サービス間のmTLS(相互TLS)、内部APIの認証、IoTデバイスの証明書管理に使用されます。パブリック信頼チェーンがないため、インターネットユーザーは信頼しませんが、内部システムでルートCAを信頼するよう設定できます。

A) 強力なIDの基盤を実装する B) トレーサビリティを有効にする C) 単一のセキュリティレイヤーを適用して管理を簡素化する D) セキュリティイベントに備える

答え: C

解説: AWS Well-Architected Frameworkセキュリティの柱の7つの設計原則: 1) 強力なIDの基盤を実装する、2) トレーサビリティを有効にする、3) すべてのレイヤーにセキュリティを適用する(多層防御)、4) セキュリティのベストプラクティスを自動化する、5) 転送中および保管中のデータを保護する、6) データへの人のアクセスを最小化する、7) セキュリティイベントに備える。「単一セキュリティレイヤー」は多層防御の原則に反します。

A) EC2インスタンスから悪意あるDNSサーバーへのトラフィック B) EC2インスタンスがDNSクエリを通じてデータを外部に漏洩している C) DNSサーバーがDDoS攻撃を受けている D) Route 53 Resolverが悪意あるクエリを受信している

答え: B

解説: DNSデータ漏洩はデータをDNSクエリのサブドメイン部分にエンコードして悪意あるDNSサーバーに送信する手法です。例: dGhpcyBpcyBzZWNyZXQ.malicious.com 形式のクエリ。ファイアウォールがHTTP/HTTPSをブロックしてもDNS(53番ポート)は大抵許可されるため、よく使用されます。Route 53 DNS FirewallまたはNetwork Firewallで既知の悪意あるドメインをブロックできます。

A) すべてのアカウントに同じConfigルールを自動デプロイする B) 複数のアカウント/リージョンのAWS Configデータを単一のアカウントに集約し、一元的なコンプライアンス状況の確認を可能にする C) コンプライアンスのないリソースを自動修復する D) Configルール実行コストを削減する

答え: B

解説: AWS Config集約機能は、OrganizationsのメンバーアカウントまたはOrganizationsの複数のメンバーアカウントや特定アカウントのConfig リソース設定とコンプライアンスデータを単一の集約アカウントで一元確認できるようにします。組織全体のコンプライアンス状況ダッシュボード、リソースインベントリ確認に便利です。ただし、集約機能自体には自動修復やルールデプロイ機能はありません。

A) IAMロールを削除してハードコードされた認証情報を使用する B) 最小権限の原則を適用: アプリケーションが実際に必要とするサービスと操作のみを許可するカスタムポリシーを作成し、権限境界を設定する C) EC2ロールにMFAを追加する D) ロールセッション期間を最小化する

答え: B

解説: 最小権限の原則はセキュリティの基本です。IAM Access Analyzerの「ポリシー生成」機能を使用すると、CloudTrailログを分析して実際に使用されたAPIコールのみに基づいて最小権限ポリシーを自動生成できます。また、権限境界(Permission Boundary)を追加することで、将来ロールに過剰な権限が付与されるのを防ぎます。

A) 環境変数に平文パスワードを保存する B) KMSで暗号化した値をLambda環境変数に保存するか、Secrets Managerから実行時に動的に取得する(キャッシング戦略を含む) C) Lambda関数のコードにハードコードする D) S3バケットに暗号化したファイルとして保存する

答え: B

解説: 推奨方法: AWS Secrets Managerでパスワードを保存し、Lambda実行時にSDKで取得します。Lambda実行環境(1回の呼び出し中)でキャッシュして、毎回の呼び出しでSecrets Manager APIを呼び出さないよう最適化します。AWS Parameter Store SecureStringも代替手段です。Lambda環境変数はKMSで暗号化されていますが(転送中)、Secrets Managerは自動ローテーション、監査証跡などの追加セキュリティ機能を提供します。

A) 物理データセンターのセキュリティ B) ハイパーバイザーのパッチ適用 C) オペレーティングシステムのパッチ適用、IAM設定、セキュリティグループの設定、データ暗号化 D) グローバルインフラストラクチャの可用性

答え: C

解説: AWS共有責任モデル: AWSの責任(クラウドのセキュリティ) - 物理インフラ、ハイパーバイザー、グローバルネットワーク、マネージドサービスのパッチ適用。顧客の責任(クラウドにおけるセキュリティ) - ゲストOSのパッチ適用、IAM設定、セキュリティグループ/NACL、データ暗号化、ネットワークトラフィックの保護、アプリケーションセキュリティ。IaaS(EC2)は顧客の責任範囲が広く、SaaS(S3)はAWSの責任範囲がより広いです。

A) 構文エラーがある B) すべてのS3操作をすべてのS3リソースに許可する過剰な権限 - 最小権限の原則の違反 C) S3のみに制限されていて権限が少なすぎる D) Resourceワイルドカードはs3では必須

答え: B

解説: s3:*ワイルドカードはs3:DeleteBucket、s3:DeleteObjectを含むすべてのS3操作を許可します。Resource:*はアカウント内のすべてのS3バケットを含みます。最小権限の原則に従い、特定のバケットARNと必要な特定の操作のみを許可すべきです。例: {"Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*"}

A) S3バケット暗号化を有効化する B) S3バージョニング + MFA Delete + 不変バックアップ(S3 Object Lock) + 最小権限IAM + GuardDuty + オフラインバックアップ C) CloudTrailログを有効化する D) VPC Flow Logsを有効化する

答え: B

解説: ランサムウェアへの多層防御: 1) S3バージョニングで削除されたファイルを復旧、2) MFA Deleteでバージョン削除を防止、3) S3 Object Lock(WORM)で特定期間削除不可にする、4) 最小権限IAMで大量削除権限を制限、5) GuardDutyで異常な削除パターンを検出、6) AWS Backupで定期バックアップ + Vault Lock(不変バックアップ保管庫)。マルチリージョン/マルチアカウントバックアップも推奨されます。

A) 10年有効期限の自己署名証明書を使用する B) ACM管理証明書を使用(自動更新)し、ACMの有効期限近接時のEventBridge通知を設定し、サードパーティ証明書の場合は90日前に更新通知を設定する C) すべての証明書を手動で管理する D) CloudFrontでのみ証明書を使用する

答え: B

解説: ACM管理証明書は有効期限前に自動更新されます(ドメイン検証証明書)。ACMはEventBridgeを通じて証明書の有効期限の45日、30日、15日、7日、3日、1日前に通知を送信します。ACMにインポートされた(サードパーティの)証明書は自動更新されないため、別途モニタリングが必要です。

A) ログファイルの暗号化 B) ログファイルの整合性検証(Log File Validation) - SHA-256ハッシュとRSA署名でログファイルの整合性を検証 C) リアルタイムログストリーミング D) ログファイルの自動削除

答え: B

解説: CloudTrailのログファイル整合性検証を有効にすると、CloudTrailは毎時ダイジェストファイルを生成します。ダイジェストファイルには過去1時間のログファイルのハッシュリストと前のダイジェストファイルのハッシュが含まれます。aws cloudtrail validate-logs CLIコマンドでログファイルが削除または改ざんされていないことを検証できます。

A) ルートアカウントを削除する B) IAM管理者ユーザーを作成し、ルートアカウントにMFAを有効化し、ルートアクセスキーを削除し、日常業務にはIAMロール/ユーザーを使用する C) ルートアカウントのパスワードを変更する D) ルートアカウントにIPアドレス制限を適用する

答え: B

解説: AWSルートアカウントのセキュリティのベストプラクティス: 1) ルートアカウントにMFAを有効化(ハードウェアMFA推奨)、2) ルートアクセスキーを削除または無効化、3) 日常業務のためのIAM管理者ユーザー/ロールを作成、4) ルートアカウントは特定のタスク(Organizations管理、ルートアクセスが必要なサービスの設定)にのみ使用、5) ルートアカウント使用時のCloudWatchアラームを設定。

A) 特定のAWSリージョンの使用禁止 B) 特定のEC2インスタンスタイプの使用制限 C) IAMロールの作成許可 D) メンバーアカウントのIAMユーザーへの権限付与

答え: D

解説: SCPは組織のメンバーアカウントで使用可能な最大権限の上限を設定するガードレールです。SCPは権限を付与するのではなく制限するだけです。実際の権限付与は各アカウントのIAMポリシーで行われます。SCPでできること: 特定のリージョンの使用禁止、特定のサービス/操作の禁止、特定のリソースタグの要求、ルートアカウントアクセスの禁止。

A) IAMロールの自動作成 B) 適応型認証(Adaptive Authentication) - リスクスコアに基づいてMFAを要求またはログインをブロック、侵害された認証情報の保護 C) S3バケットの自動暗号化 D) CloudTrailログの自動分析

答え: B

解説: Cognito高度なセキュリティ機能: 1) リスクベースの適応型認証 - 異常なログインパターン(新しいデバイス、新しい場所、異常な時間)を検出した際にMFAを要求またはブロック、2) 侵害された認証情報の保護 - 既知の漏洩パスワードの使用をブロック、3) セキュリティイベントのログと監視。これによりアカウント乗っ取り(Account Takeover)攻撃を防御します。

A) AWS Systems Manager Session Manager - エージェントベースでSSHポート(22)なしに暗号化されたセッションを提供 B) AWS Direct Connect C) VPN接続 D) CloudShell

答え: A

解説: SSM Session Managerの利点: 1) SSHキー管理が不要、2) 22番ポートのインバウンドが不要(アウトバウンドHTTPSのみ必要)、3) すべてのセッションがCloudTrail/S3に自動ログ記録、4) IAMベースのアクセス制御、5) VPC内のインターネットのないインスタンスもVPCエンドポイント経由でアクセス可能。ポートフォワーディング、SSHトンネリングもサポートします。

A) 従来のVPN + ファイアウォール B) IAM Identity Center(SSO) + 条件付きアクセス + VPCエンドポイント + mTLS(ACM Private CA) + Network Firewall + GuardDuty C) VPCピアリングだけで十分 D) パブリックインターネットをブロックする

答え: B

解説: ゼロトラストの原則「決して信頼せず、常に検証する」をAWSで実装: 1) IAM Identity Centerで中央集中型のID確認、2) 条件付きアクセスポリシー(デバイス状態、場所ベース)、3) VPCエンドポイントでAWSサービスへのプライベートアクセス、4) ACM Private CAでmTLSサービス間認証、5) Network Firewall/SGでマイクロセグメンテーション、6) GuardDuty + Detectiveで継続的な異常検出。

A) 各アカウントで手動でS3パブリックアクセスブロックを有効化する B) Organizations SCPでs3:PutBucketPublicAccessBlockの削除を拒否 + AWS ConfigルールでDetect + Firewall ManagerでS3パブリックアクセスブロックポリシーを自動適用 C) S3バケットポリシーですべてのパブリックアクセスを拒否する D) VPCエンドポイントでS3へのアクセスを制限する

答え: B

解説: 多層的アプローチ: 1) SCPでメンバーアカウントがパブリックアクセスブロック設定を削除することを禁止(予防的)、2) AWS Configルールs3-bucket-level-public-access-prohibitedでコンプライアンスのないバケットを検出(検出的)、3) AWS Firewall ManagerのS3ポリシーですべてのアカウントの新規/既存バケットにパブリックアクセスブロックを自動適用(自動化)。この3つを組み合わせると予防-検出-自動化をすべて満たします。