AWS Certified Security – Specialty 1-10

DISPLAY SETTINGS 各種設定クリックして開くクリックして閉じる

表示モード

画像位置

文字位置

理解度の自動記録

理解度の位置

問題幅 % 60〜100%

AWS Certified Security Specialty

Q1. あるオンラインショップ運営会社で、クラウド担当者が新規のAWSアカウントを構築しています。
担当者は、Amazon S3バケットに格納する顧客データを保護したいと考えています。
加えて、意図しないデータ公開のリスクとS3バケット内オブジェクトの設定ミスの発生をできるだけ抑えたいと考えています。
最も運用負荷が小さく、これらの要件を満たすソリューションはどれですか。

A. AWSアカウント全体に対してS3ブロックパブリックアクセスを設定する。
B. バケット内の個々のオブジェクトごとにS3ブロックパブリックアクセスを設定する。
C. バケット内オブジェクトに設定されているACL（アクセスコントロールリスト）を無効化する。
D. バケットへのアクセス経路としてAmazon S3向けのAWS PrivateLinkを利用する。

解答を見る

正解：A. AWSアカウント全体に対してS3ブロックパブリックアクセスを設定する。

S3ブロックパブリックアクセスをAWSアカウントレベルで有効化することが、最小の運用負荷でデータを保護できる推奨手法です。
アカウントレベルで設定すると、既存および新規に作成されるすべてのバケットとオブジェクトへ自動的に適用され、バケットポリシーやACLの設定ミスによる公開を一括で防止できます。
オブジェクト単位の設定（B）やACLの無効化（C）は個別対応となり漏れが生じやすく、運用負荷はむしろ高くなります。
PrivateLink（D）は接続経路に関する仕組みであり、公開設定を抑止するという要件には合致しません。
予防的かつ一元管理できる点が正答の根拠です。
Amazon S3 のブロックパブリックアクセス（AWS公式ドキュメント）

AWS Certified Security Specialty

Q2. ある製造業の社内システムチームで、開発者がAWS Lambda関数URLを利用して関数を直接呼び出す運用を行っています。
会社は、開発者が本番用アカウントにおいて認証なしの関数を作成・更新できないようにしたいと考えています。
会社はAWS Organizationsを用いてこの制御を実現したい一方、開発者側に追加の作業や意識付けを求めない仕組みが必要です。
この要件を満たすソリューションはどれですか。

A. 関数が別ドメインから呼び出される可能性に備え、すべての関数URLでCORS（クロスオリジンリソース共有）を有効にするよう開発者へ指示する。
B. AWS WAFの委任管理者アカウントを利用し、関数を使用しているアカウントが属するOUに基づいて、本番アカウントの関数URLへの未認証アクセスを検知・ブロックする。
C. lambda:FunctionUrlAuthType条件キーの値がAWS_IAMであるすべてのlambda:CreateFunctionUrlConfigおよびlambda:UpdateFunctionUrlConfigアクションを、SCPで許可する。
D. lambda:FunctionUrlAuthType条件キーの値がNONEであるすべてのlambda:CreateFunctionUrlConfigおよびlambda:UpdateFunctionUrlConfigアクションを、SCPで拒否する。

解答を見る

正解：D. lambda:FunctionUrlAuthType条件キーの値がNONEであるすべてのlambda:CreateFunctionUrlConfigおよびlambda:UpdateFunctionUrlConfigアクションを、SCPで拒否する。

Lambda関数URLの認証タイプにはAWS_IAM（IAM認証あり）とNONE（公開）の2種類があります。
NONEは誰でもアクセス可能になり、本番環境では重大なリスクとなります。
SCP（サービスコントロールポリシー）でFunctionUrlAuthTypeがNONEとなるCreate／UpdateFunctionUrlConfigを明示的に拒否すれば、開発者側の作業なしに未認証関数の作成を組織全体で防止できます。
AWS_IAMを許可するC（Allow）はDenyがない限り他の権限で作成される余地を残すため、予防的なガードレールとしては不十分です。
WAF（B）やCORS（A）は認証タイプそのものを強制する手段にはなりません。
Lambda 関数 URL の認証と認可（AWS公式ドキュメント）

AWS Certified Security Specialty

Q3. あるスタートアップ企業のセキュリティエンジニアが、Amazon EBSベースのストレージを利用するLinux系Amazon EC2インスタンスについて、不審なアクティビティの通知を受け取りました。
調べたところ、そのインスタンスは既知の悪意あるアドレスと通信していることが分かりました。
インスタンスはus-east-1リージョンのVPC内にある開発用アカウントに存在します。
VPCにはインターネットゲートウェイがあり、us-east-1aとus-east-1bの2つのサブネットが構成されています。
各サブネットはインターネットゲートウェイをデフォルトルートとするルートテーブルに関連付けられ、デフォルトのネットワークACLを使用しています。
不審なEC2インスタンスはus-east-1bサブネットで稼働しています。
初動調査の結果、そのサブネットで稼働しているのは当該の不審なインスタンス1台のみであることが判明しました。
攻撃を即座に緩和しつつ、根本原因の調査にも役立つ対応はどれですか。

A. 不審なインスタンスにログインし、netstatコマンドで確立されているリモート接続を特定する。
特定したIPアドレス宛てにインスタンスのセキュリティグループで拒否ルールを作成する。
調査のためインスタンスへ診断ツールを追加インストールする。
調査中の最初のルールとして、us-east-1bサブネットのアウトバウンドネットワークACLを更新し、すべての通信を明示的に拒否する。
B. us-east-1bサブネットのアウトバウンドネットワークACLを更新し、最初のルールとしてすべての通信を明示的に拒否する。
既存のセキュリティグループを、診断用セキュリティグループからの接続のみを許可する新しいものに置き換える。
us-east-1bサブネットのアウトバウンドネットワークACLの拒否ルールを削除する。
診断ツールを備えた新しいEC2インスタンスを起動し、新しいセキュリティグループを割り当てる。
その新インスタンスから不審なインスタンスを調査する。
C. 不審なEC2インスタンスにアタッチされているAmazon EBSボリュームが、インスタンス終了時に削除されないよう設定する。
インスタンスを終了する。
診断ツールを備えた新しいEC2インスタンスをus-east-1aで起動する。
終了したインスタンスのEBSボリュームをその新インスタンスにマウントして調査する。
D. 不審なインスタンスとの間の通信を拒否するAWS WAFウェブACLを作成する。
攻撃を緩和するため、そのウェブACLをインスタンスに関連付ける。
インスタンスにログインし、診断ツールをインストールして調査する。

解答を見る

正解：C. 不審なEC2インスタンスにアタッチされているAmazon EBSボリュームが、インスタンス終了時に削除されないよう設定する。インスタンスを終了する。診断ツールを備えた新しいEC2インスタンスをus-east-1aで起動する。終了したインスタンスのEBSボリュームをその新インスタンスにマウントして調査する。

インシデント対応の基本原則は、即時の封じ込め、証拠保全、安全な環境でのフォレンジックです。
侵害が疑われるインスタンスには直接ログインや追加ツールのインストールを行わず、EBSボリュームを保全したうえでインスタンスを終了し、悪意ある通信を即座に遮断します。
終了時に削除されない設定にすればディスク上の証拠が保持され、別の清浄なインスタンスにマウントして解析できます。
ログインして操作するA・Dは証拠を汚染する危険があります。
WAFはEC2に直接アタッチできないためD自体が不適切です。
Bはネットワークで隔離しますがインスタンスを稼働させ続けるためCより封じ込めが弱くなります。
AWS セキュリティインシデント対応ガイド（AWS公式ドキュメント）

AWS Certified Security Specialty

Q4. ある金融系企業のVPCはインターネットへの経路を持たず、プライベートDNSホスト名オプションが有効になっています。
このVPC内でAmazon Auroraデータベースが稼働しています。
セキュリティエンジニアは、AWS Secrets Managerを利用してAuroraの認証情報を自動的にローテーションさせたいと考えています。
エンジニアは、Secrets Managerの既定のAWS Lambdaローテーション関数を、Auroraと同じVPC内で実行するよう構成しました。
ところが、Lambda関数がSecrets Managerのエンドポイントと通信できず、パスワードのローテーションが正しく行われないことが判明しました。
Lambda関数にSecrets Managerエンドポイントとの通信手段を与える、最も安全な方法はどれですか。

A. Secrets Managerエンドポイントへの経路を確保するため、VPCにNATゲートウェイを追加する。
B. Secrets Managerエンドポイントへの経路を確保するため、VPCにゲートウェイ型のVPCエンドポイントを追加する。
C. Secrets Managerエンドポイントへの経路を確保するため、VPCにインターフェイス型のVPCエンドポイントを追加する。
D. Secrets Managerエンドポイントへの経路を確保するため、VPCにインターネットゲートウェイを追加する。

解答を見る

正解：C. Secrets Managerエンドポイントへの経路を確保するため、VPCにインターフェイス型のVPCエンドポイントを追加する。

Secrets Managerはリージョナルサービスであり、AWS PrivateLinkを基盤とするインターフェイス型VPCエンドポイント経由でプライベートに接続できます。
インターネット経路のないVPCでは、インターフェイスエンドポイントがサブネット内にENIとプライベートIPを作成し、インターネットやNATを経由せずにSecrets Managerと通信できるため最も安全です。
NATゲートウェイ（A）やインターネットゲートウェイ（D）は通信を公共のインターネットへ出してしまうため要件に反します。
ゲートウェイ型エンドポイント（B）はS3とDynamoDBのみに対応しており、Secrets Managerには利用できません。
Secrets Manager の VPC エンドポイントの使用（AWS公式ドキュメント）

AWS Certified Security Specialty

Q5. ある物流会社のセキュリティエンジニアが、Amazon EC2インスタンス上で生成されるカスタムのアプリケーションセキュリティログを、Amazon CloudWatchへ転送したいと考えています。
エンジニアはEC2インスタンスにCloudWatchエージェントをインストールし、対象ログのパスをCloudWatchエージェントの設定ファイルに追記しました。
ところが、CloudWatch側でログが受信されません。
エンジニアが確認したところ、EC2インスタンス上ではawslogsサービスは正常に稼働していました。
この問題を解決するために、エンジニアが次に行うべきことはどれですか。

A. EC2インスタンスの信頼ポリシーにAWS CloudTrailを追加する。
カスタムログの送信先をCloudWatchではなくCloudTrailへ変更する。
B. EC2インスタンスの信頼ポリシーにAmazon S3を追加する。
アプリケーションがカスタムログをS3バケットへ書き込み、CloudWatchがそれを取り込むよう設定する。
C. EC2インスタンスの信頼ポリシーにAmazon Inspectorを追加する。
カスタムログの収集にCloudWatchエージェントではなくAmazon Inspectorを利用する。
D. AWSマネージドポリシーであるCloudWatchAgentServerPolicyを、EC2インスタンスのロールにアタッチする。

解答を見る

正解：D. AWSマネージドポリシーであるCloudWatchAgentServerPolicyを、EC2インスタンスのロールにアタッチする。

CloudWatchエージェントは、ロググループやログストリームの作成、ログイベントの送信のために明示的なIAM権限を必要とします。
エージェントによるログ配信が失敗する最も一般的な原因はEC2インスタンスロールのIAM権限不足であり、CloudWatchAgentServerPolicyをアタッチすればlogs:CreateLogGroup・CreateLogStream・PutLogEventsの権限が付与され解決します。
信頼ポリシーはロールを引き受けられる主体を定義するものであり、S3やInspector、CloudTrailを信頼ポリシーに追加するA・B・Cは意味が異なり、この要件も満たしません。
CloudWatch エージェント用の IAM ロールとユーザーの作成（AWS公式ドキュメント）

AWS Certified Security Specialty

Q6. ある製薬会社が、Amazon EC2インスタンス上でフォレンジック分析を行おうとしていますが、AWS Systems Manager Session Managerを使ってインスタンスに接続できません。
同社はEC2インスタンスにAWS Systems Managerエージェント（SSM Agent）を導入済みです。
このEC2インスタンスは、インターネットゲートウェイがアタッチされていないVPC内のサブネットに配置されています。
EC2インスタンスにはセキュリティグループが関連付けられていますが、インバウンド・アウトバウンドのいずれのルールも設定されていません。
サブネットのネットワークACLは、すべてのインバウンド・アウトバウンド通信を許可する設定です。
フォレンジックデータを損なうことなくEC2インスタンス上でフォレンジック分析を実施できる、アクションの組み合わせはどれですか。（3つ選択）

A. EC2インスタンスのセキュリティグループを更新し、0.0.0.0/0宛てのポート443へのアウトバウンド通信を許可するルールを追加する。
B. EC2インスタンスのセキュリティグループを更新し、VPCのCIDR範囲からのポート443へのインバウンド通信を許可するルールを追加する。
C. EC2キーペアを新規作成し、そのキーペアをEC2インスタンスに関連付ける。
D. EC2インスタンスが配置されているVPC内に、Systems Manager用のVPCインターフェイスエンドポイントを作成する。
E. VPCインターフェイスエンドポイントにセキュリティグループを関連付け、VPCのCIDR範囲からのポート443へのインバウンド通信を許可する。
F. EC2インスタンスが配置されているVPC内に、EC2インスタンス用のVPCインターフェイスエンドポイントを作成する。

解答を見る

正解：A、D、E

Session Managerは、EC2からSystems ManagerのエンドポイントへのHTTPS（443番ポート）によるアウトバウンド通信を必要とします。
インターネット経路のないVPCでは、Systems Manager用のインターフェイスVPCエンドポイントを作成し（D）、EC2のセキュリティグループでポート443のアウトバウンドを許可し（A）、エンドポイント側のセキュリティグループでVPC CIDRからのポート443インバウンドを許可（E）することで、外部公開せず安全に接続できます。
キーペア（C）はSSH用であり不要かつ再起動の恐れから証拠を損ないかねません。
Session Manager自体への受信ルール（B）は不要で、EC2用のエンドポイント（F）はこの接続要件には該当しません。
Systems Manager 用の VPC エンドポイントの作成（AWS公式ドキュメント）

AWS Certified Security Specialty

Q7. ある保険会社のセキュリティチームが、社内のAWS Key Management Service（AWS KMS）カスタマー管理キーを一元管理しています。
このKMSキーを管理できるのはセキュリティチームのメンバーだけに限定されています。
一方、アプリケーションチームには、時折このキーへ一時的にアクセスする必要があるソフトウェアプロセスが存在します。
セキュリティチームは、このソフトウェアプロセスに対してキーへのアクセスを提供する必要があります。
最も運用負荷が少なく、これらの要件を満たすソリューションはどれですか。

A. KMSキーのキーマテリアルをオンプレミスのハードウェアセキュリティモジュール（HSM）へエクスポートし、アプリケーションチームにそのキーマテリアルへのアクセス権を付与する。
B. セキュリティチームにKMSキーへのアクセスを許可しているキーポリシーを編集し、アプリケーションチームをプリンシパルとして追加する。
アクセスが不要になった時点でこの変更を元に戻す。
C. アプリケーションチームがKMSキーを使用できるようにするキーグラントを作成し、アクセスが不要になった時点でグラントを取り消す。
D. オンプレミス側でキーマテリアルを生成して新しいKMSキーを作成する。
アプリケーションチームがアクセスを必要とするたびにキーマテリアルをAWS KMSへインポートし、キーの使用権限を付与する。

解答を見る

正解：C. アプリケーションチームがKMSキーを使用できるようにするキーグラントを作成し、アクセスが不要になった時点でグラントを取り消す。

KMSのキーグラントは、キーポリシーそのものを変更せずに一時的かつ細かい粒度の使用権限を付与できる仕組みです。
グラントはEncryptやDecrypt、GenerateDataKeyなどの権限をプログラム的に動的に付与・取り消しでき、短期間のアクセス要件に最適で運用負荷が最小になります。
キーポリシーの編集（B）は変更と巻き戻しの手間があり、誤設定のリスクも高い方法です。
キーマテリアルのエクスポート（A）はKMSでは不可能であり、インポートキーによる運用（D）は手順が煩雑で、いずれも過剰な対応です。
AWS KMS のグラント（AWS公式ドキュメント）

AWS Certified Security Specialty

Q8. ある広告代理店が、AWS CloudTrailとAmazon CloudWatchを利用してAWSアカウント内のリソースを監視しています。
同社の開発者は、過去3か月にわたってこのアカウントのIAMロールを利用してきました。
セキュリティエンジニアは、当該ロールに最小権限のみを持たせるため、ロールにアタッチされているカスタマー管理IAMポリシーを見直し、絞り込む必要があります。
最も労力が少なく、この要件を満たすソリューションはどれですか。

A. そのIAMロールに対してAWS IAM Access Analyzerのポリシー生成機能を実行する。
B. そのIAMロールに対してAWS IAM Access Analyzerのポリシー検証機能を実行する。
C. CloudWatchのログを検索してロールが呼び出したアクションを洗い出し、必要な権限を評価する。
D. AWS Trusted Advisorを利用し、ロールに割り当てられたポリシーをAWSのベストプラクティスと比較する。

解答を見る

正解：A. そのIAMロールに対してAWS IAM Access Analyzerのポリシー生成機能を実行する。

IAM Access Analyzerのポリシー生成機能は、CloudTrailに記録された実際の利用履歴に基づき、最小権限のポリシーを自動的に生成する機能です。
ロールが3か月間使用されており十分なCloudTrail履歴が蓄積されているため、ポリシー生成によって実際に呼び出されたAPIアクションとリソースのみを含むポリシーを作成でき、最小の労力で最小権限を実現できます。
ポリシー検証（B）は構文やベストプラクティスの確認にとどまり最小権限ポリシーは生成しません。
ログの手動検索（C）は労力が大きく、Trusted Advisor（D）は最小権限ポリシー生成の用途には適しません。
IAM Access Analyzer のポリシー生成（AWS公式ドキュメント）

AWS Certified Security Specialty

Q9. ある教育機関が、SAML 2.0フェデレーションを利用するAWS IAM Identity Centerを運用しています。
この機関は、フェデレーションの参照先アイデンティティプロバイダー（IdP）を、現行のIdPから別のIdPへ切り替えることを決定しました。
両方のIdPが基盤とするディレクトリはいずれもActive Directoryです。
この要件を満たすソリューションはどれですか。

A. 元のIdPとのフェデレーションに含まれていた、IAM Identity Center内の既存ユーザーとグループをすべて無効化する。
B. IAM Identity Centerの信頼関係における属性マッピングを、新しいIdPが送信する情報に一致するよう変更する。
C. 企業のAWSアカウント内にある既存のIAMロールをすべて再構成し、新しいIdPをプリンシパルとして明示的に信頼させる。
D. IAM Identity Centerと新しいIdPのエンドポイント間で、Network Time Protocol（NTP）のクロックスキューが適切に設定されていることを確認する。

解答を見る

正解：B. IAM Identity Centerの信頼関係における属性マッピングを、新しいIdPが送信する情報に一致するよう変更する。

IAM Identity Centerは、SAMLアサーションと属性マッピングを通じて、フェデレーションユーザーをアイデンティティやグループ、許可セットに関連付けます。
基盤ディレクトリを変えずにIdPだけを切り替える場合、属性マッピングを新しいIdPのアサーションに合わせて更新すれば、既存のユーザーやグループの関連付けを維持したまま移行できます。
既存ユーザーの無効化（A）は不要であり、かえってアクセスを失わせます。
IAMロールの信頼変更（C）はIdPフェデレーションではなくロールベースの話であり該当しません。
クロックスキューの確認（D）は接続失敗時の切り分けにすぎず、IdP切り替えという要件そのものは満たしません。
IAM Identity Center の属性マッピング（AWS公式ドキュメント）

Q10

AWS Certified Security Specialty

Q10. ある通信事業者がAWS上でアプリケーションを稼働させています。
この会社はマルチ環境構成を採用しており、各環境をそれぞれ別のAWSアカウントで分離しています。
アカウントはAWS Organizationsの組織を通じて管理されており、組織内には専用のセキュリティアカウントが1つ存在します。
この会社は、組織内の各アカウントにあるAmazon S3バケットに保存されているすべての機密データについて、インベントリを作成する必要があります。
検出結果は単一の場所から確認できなければなりません。
これらの要件を満たすソリューションはどれですか。

A. セキュリティアカウントをAmazon MacieとAWS Security Hubの委任管理者アカウントに設定する。
Macieを有効化・設定し、機密データの検出結果をSecurity Hubへ公開する。
B. セキュリティアカウントをAWS Security Hubの委任管理者アカウントに設定する。
各アカウントでAmazon Inspectorを構成し、S3バケット内の機密データをスキャンする。
機密データの検出結果をSecurity Hubへ公開する。
C. 各アカウントでAmazon Inspectorを構成し、S3バケット内の機密データをスキャンする。
Amazon InspectorとAWS Trusted Advisorの統合を有効化する。
機密データの検出結果をTrusted Advisorへ公開する。
D. 各アカウントでAmazon Macieを有効化・設定し、機密データを検出する。
MacieとAWS Trusted Advisorの統合を有効化する。
機密データの検出結果をTrusted Advisorへ公開する。

解答を見る

正解：A. セキュリティアカウントをAmazon MacieとAWS Security Hubの委任管理者アカウントに設定する。Macieを有効化・設定し、機密データの検出結果をSecurity Hubへ公開する。

Amazon Macieは、S3に保存された機密データの検出・分類・インベントリ作成に特化したサービスです。
Macieは委任管理者アカウントの仕組みを使ってAWS Organizations全体で組織横断的に有効化でき、セキュリティアカウントをMacieとSecurity Hubの委任管理者に設定すれば検出結果を単一の場所へ集約できます。
Amazon InspectorはS3の機密データ検出を行わないため（B・C）要件を満たしません。
Trusted Advisor（C・D）は機密データ検出結果の集約先ではなく、集中的な可視化という要件にも合致しません。
Amazon Macie と AWS Organizations（AWS公式ドキュメント）