以下に、提示された 問題1 を指定フォーマットに従って整理・解説します。
■ 問題文(文字列を編集せずに出力)
ある企業のデータレイクは、Amazon S3 と Amazon Athena を使用しています。同社のセキュリティエンジニアは、同社のデータ保護要件を満たす暗号化ソリューションの設計を依頼されました。暗号化ソリューションは、Amazon S3 および同社が管理するキーと連携する必要があります。暗号化ソリューションは、連邦情報処理標準 (FIPS) 140-2 レベル 3 で検証されたハードウェアセキュリティモジュールで保護する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢(文字列を編集せずに出力)
A. AWS CloudHSM を使用してキーを保存し、暗号化操作を実行します。暗号化されたテキストを Amazon S3 に保存します。
B. AWS CloudHSM に保存されているキーをインポートするために、Bring Your Own Key (BYOK) 機能を備えた AWS KMS カスタマーマネージドキーを使用します。
C. AWS CloudHSM を使用して、カスタムキーストアによってサポートされる AWS KMS カスタマーマネージドキーを使用します。
D. AWS 暗号化 SDK で実装された AWS KMS カスタマーマネージドキーでクライアント側の暗号化を使用します。
■ 問題文の要件の概要
- Amazon S3 および Athena を使用したデータレイクの暗号化設計
- 企業管理のキーを利用する必要がある
- FIPS 140-2 Level 3 に準拠した HSM でキーを保護
- AWSサービスとの**統合性(Amazon S3と連携)**が必要
■ 正解の選択肢と解説
✅ C. AWS CloudHSM を使用して、カスタムキーストアによってサポートされる AWS KMS カスタマーマネージドキーを使用します。
解説:
- AWS KMS は Amazon S3 とネイティブに統合されており、KMSキーを使ったS3バケットの暗号化が可能。
- カスタムキーストアを使うことで、KMSのキーのキーマテリアル(暗号鍵の実体)を AWS CloudHSM(FIPS 140-2 Level 3 認定) でホストされたHSMに保管可能。
- この構成により、「企業管理のキー」かつ「FIPS 140-2 Level 3 HSMで保護された暗号化」が実現される。
- さらに、Amazon S3 との直接統合が可能であるため、運用上も理想的な構成。
■ 不正解の選択肢の理由
選択肢 | 誤りの理由 |
---|---|
A | AWS CloudHSM は S3 と直接統合できないため、アプリケーション側で暗号化・復号を実装する必要があり、管理性とセキュリティに課題。 |
B | BYOK は KMS にキーをインポートする方法だが、インポート時にキーマテリアルが AWS に渡る。FIPS 140-2 Level 3 HSMでキーが常駐していることを保証できないため不適。 |
D | AWS 暗号化 SDK を使ったクライアント側暗号化では、FIPS 140-2 Level 3 認定 HSMの利用を保証できない。また、S3との連携は自動化されないため運用が複雑。 |
■ SCS試験で押さえておくべきポイント
- ✅ FIPS 140-2 Level 3 が求められたら、AWS CloudHSM を選択肢に入れる。
- ✅ AWS KMS の カスタムキーストア を使えば、CloudHSM によって保護されたキーで KMS を使える。
- ✅ Amazon S3 との統合を考えると、KMS + CloudHSM-backed custom key store がベストプラクティス。
- ❌ AWS CloudHSM 単体では、S3 との直接連携はないため注意。
- ❌ BYOK やクライアント側暗号化は、FIPS 140-2 Level 3 を保証しない点が問われやすい。
この問題は「暗号化方式の選定において、コンプライアンス要求(FIPS 140-2)をどう満たすか」という視点が重要です。KMS のカスタムキーストアと CloudHSM の連携を正しく理解しておきましょう。
以下に「問題2」を指定の形式で整理・解説します。
■ 問題文
セキュリティエンジニアが、Amazon OpenSearch Service (Amazon Elasticsearch Service) のクラスターを新規に作成しています。このクラスターは、データウェアハウスとして機能する予定です。アプリケーションサーバーの別のフリートは、データウェアハウスからレコードを抽出し、これらのレコードを Amazon S3 バケットにアップロードされるレポートに変換します。
セキュリティエンジニアは、アプリケーションサーバーだけがアクセスできるように、Amazon OpenSearch Service (Amazon Elasticsearch Service) クラスターを安全に設定する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
VPC のフローログから、Amazon OpenSearch Service (Amazon Elasticsearch Service) クラスター宛のトラフィックを監視します。フローログを使用して、アプリケーションサーバー以外から発信されたトラフィックを検出します。
B.
アプリケーションサーバーを含む VPC と Amazon OpenSearch Service (Amazon Elasticsearch Service) クラスターを含む VPC の間に VPC ピアリング接続を設定します。
C.
Amazon OpenSearch Service (Amazon Elasticsearch Service) クラスターを VPC アクセスのみに設定します。セキュリティグループを使用して、アプリケーションサーバーのみから Amazon OpenSearch Service (Amazon Elasticsearch Service) クラスターへのアクセスを許可します。
D.
Amazon OpenSearch Service (Amazon Elasticsearch Service) インスタンスをホストするサブネットでネットワーク ACL を設定し、アプリケーションサーバーからのアクセスのみを許可します。
■ 正解の選択肢と解説
✅ C. Amazon OpenSearch Service クラスターを VPC アクセスのみに設定し、セキュリティグループを使用してアプリケーションサーバーのみからアクセスを許可する。
解説:
- OpenSearch Service は VPC内でホスト可能 で、セキュリティグループでアクセス制御ができます。
- 「アプリケーションサーバーだけがアクセスできるようにしたい」という要件を満たすには、VPCアクセスのみとし、セキュリティグループでアクセス元(EC2のENIなど)を制限するのがベストプラクティス。
- セキュリティグループはステートフルであり、VPC内でのアクセス制御を柔軟かつ安全に実施できます。
■ 不正解の選択肢の理由
選択肢 | 誤りの理由 |
---|---|
A | VPCフローログは監視ツールであり、アクセス制御そのものは行えない。アクセス制御の要件を満たせない。 |
B | VPCピアリングは通信可能にする手段だが、アクセス制御は別途必要。単独では要件を満たさない。 |
D | ネットワークACLはステートレスで管理が煩雑。セキュリティグループのほうが適切かつ柔軟な制御が可能。特にOpenSearchとの統合にはSGが推奨される。 |
■ SCS試験で押さえておくべきポイント
- ✅ Amazon OpenSearch ServiceはVPC内に配置可能。その場合、セキュリティグループでアクセスを制限するのが基本。
- ✅ 「アクセスを特定リソースに限定したい」場合は、VPCアクセス + セキュリティグループの組み合わせがセキュリティ対策の王道。
- ❌ フローログやピアリング、ACLだけでは「制御」にならず、補助的役割しか持たない。
- ✅ OpenSearchのようなマネージドサービスにおいても、VPC内ホスティングはセキュリティ確保の第一歩。
この問題では、AWSサービスの**ネットワーク制御の階層(ACL、SG、VPC構成、ログ)**を理解しているかが問われています。VPC内にサービスを閉じ込め、セキュリティグループで通信元を限定する構成は、試験本番でもよく出るベストプラクティスです。
以下に「問題3」を指定の形式で整理・解説します。
■ 問題文
企業は、災害復旧 (DR) 計画の一環として、Amazon RDS スナップショットを 2 つのアカウントに送信しています。スナップショットは暗号化されている必要があります。しかし、各アカウントは、DR イベントの場合にスナップショットを復号化することができる必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
AWS Key Management Service (AWS KMS) カスタマーマネージドキーを使用してスナップショットを生成します。2 つのアカウントに KMS キーをインポートする AWS Lambda 関数を作成します。
B.
デフォルトの AWS Key Management Service (AWS KMS) キーを使用してスナップショットを生成します。各アカウントで適切な KMS アクセス許可を持つ IAM プリンシパルを使用して、KMS キーを 2 つのアカウントと共有します。
C.
デフォルトの AWS Key Management Service (AWS KMS) キーを使用してスナップショットを生成します。KMS 暗号化キーを 2 つのアカウントにコピーする AWS Lambda 関数を作成します。
D.
AWS Key Management Service (AWS KMS) カスタマーマネージドキーを使用してスナップショットを生成します。各アカウントで適切な KMS アクセス許可を持つ IAM プリンシパルを使用して、KMS キーを 2 つのアカウントと共有します。
■ 問題文の要件の概要
- Amazon RDS スナップショットを暗号化したい。
- 2つのアカウント間でスナップショットを共有し、いざというときに 復号可能にしておく必要がある。
- **災害復旧(DR)**用途で、安全かつ復旧可能な構成が求められている。
■ 正解の選択肢と解説
✅ D. AWS KMS カスタマーマネージドキーを使用し、各アカウントに適切なアクセス権を設定して共有する。
解説:
- **AWS KMS カスタマーマネージドキー(CMK)**は、ユーザーがアクセス権をコントロールでき、他アカウントとも共有可能。
- RDSスナップショットの暗号化に使用したCMKを、他アカウントのIAMプリンシパルに対して復号のアクセス許可を付与すれば、復旧先でも利用可能。
- この構成は 公式に推奨されている方法であり、DR計画のベストプラクティス。
■ 不正解の選択肢の理由
選択肢 | 誤りの理由 |
---|---|
A | KMSキーのインポートはできない。LambdaでKMSキーをインポートするという操作自体が誤り。KMSキーの共有はポリシーで制御する。 |
B | デフォルトのKMSキー(AWS管理キー)は共有不可。他アカウントとの共有はカスタマーマネージドキーに限られる。 |
C | KMSキーはコピー不可。一意性・機密性保持のため、クロスアカウントでのコピーやエクスポートは非サポート。 |
■ SCS試験で押さえておくべきポイント
- ✅ KMS カスタマーマネージドキー(CMK)は、他アカウントと共有できる(キーのポリシーまたはIAMで制御)。
- ❌ AWS管理キー(default KMS key)は共有できない。
- ✅ RDSスナップショットなど暗号化リソースの共有には、CMKのポリシー調整が必須。
- ✅ KMSキーのコピー、インポート、Lambdaによる転送などは不可能。鍵はAWSリージョンごとかつ非移動性。
この問題は「KMSキーのスコープと共有」という、SCS試験の頻出かつ実務でも重要なトピックを問うものです。特に、「デフォルトキーは共有不可」「CMKでポリシー制御が必要」というポイントは確実に覚えておきましょう。
以下に「問題4」を指定の形式で整理・解説します。
■ 問題文
セキュリティエンジニアは、AWS Key Management Service (AWS KMS) キーに関連付けられたキーポリシーが最小特権の原則に従わないことを発見しました。このポリシーは、ポリシーにリストされているすべての AWS ID へのフルアクセスを許可します。同社のセキュリティポリシーでは、キーを使用するエンティティには必要なアクセス許可のみを付与する必要があると規定されています。エンティティにフルアクセスを許可してはいけません。
セキュリティエンジニアは、キーポリシーのコンプライアンスを継続的に監視し、キーポリシーが準拠していない場合は直ちにセキュリティエンジニアに通知するソリューションを実装する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
GetKeyPolicy API イベントが発生したときに EventBridge のカスタムルールを作成し、Lambda でキーポリシーを解析し、SNS 通知を送る。
B.
AWS Config カスタムルールを作成して KMS キーポリシーを評価。NON_COMPLIANT 評価が出たときに EventBridge → SNS で通知。
✅ 正解
C.
AWS Config マネージドルール iam-customer-policy-blocked-kms-actions
を使用し、NON_COMPLIANT 評価で通知。
D.
EventBridge で IAM Access Analyzer を定期実行して KMS キーポリシーを解析し、SNS 通知。
■ 問題文の要件の概要
- KMS キーポリシーの最小特権原則違反を自動的に検知したい。
- 継続的な監視が必要。
- 非準拠状態が検出されたときに、セキュリティエンジニアへ即時通知したい。
■ 正解の選択肢と解説
✅ B. AWS Config カスタムルール + EventBridge + SNS
解説:
- AWS Config カスタムルールを用いることで、KMS キーポリシーが「フルアクセスを許可していないか」などの特定の構文条件に準拠しているか評価できる。
- 評価結果が
NON_COMPLIANT
となった際に Amazon EventBridge でルールをトリガーし、SNS 通知でセキュリティチームにアラートが届く構成が正攻法。 - この仕組みは、継続的モニタリングと自動通知を両立できるため、セキュリティ運用の観点からも優秀。
■ 不正解の選択肢の理由
選択肢 | 誤りの理由 |
---|---|
A | GetKeyPolicy は読み取り専用 API。設定変更のイベントは発火せず、またキーポリシーが送られるわけでもないためポリシー監視に使えない。 |
C | iam-customer-policy-blocked-kms-actions は IAM ポリシーを評価するルールであり、KMSキーポリシーの内容は対象外。したがって目的とズレている。 |
D | IAM Access Analyzer は、外部公開の検出にフォーカスしており、最小特権違反や過剰な権限の検出はできない。キーポリシーの文法検査やアクセス範囲の分析には適さない。 |
■ SCS試験で押さえておくべきポイント
- ✅ AWS Config カスタムルールは、細かなポリシー条件に対して準拠チェックを行うことができる。
- ✅ EventBridge + SNS を用いた通知は、監視と通知の定番構成。
- ✅ GetKeyPolicy イベントは、アクセス権の取得であって、変更検出には使えない。
- ❌ Access Analyzer は主に外部公開リスク検出用であり、最小特権の評価目的では使えない。
- ❌ AWS 管理の Config ルールは万能ではなく、ルール内容と評価対象のリソース種別を確認すべき。
この問題では、「構成による継続的セキュリティ監視」がテーマであり、カスタムルール作成力やEventBridgeとの連携知識が問われています。実務でも役立つ知識なので、構成全体(Config → EventBridge → SNS)をセットで理解しておきましょう。
以下に「問題5」の内容を指定の形式で整理・解説します。
■ 問題文
セキュリティエンジニアが Linux ベースのコンテナイメージを us-east-1 リージョンにある Amazon Elastic Container Registry (Amazon ECR) リポジトリにプッシュしようとしています。セキュリティエンジニアは、過去 4 時間以内に aws ecr get-login-password
AWS CLI コマンドを使用して認証トークンを取得しました。セキュリティエンジニアは、コンテナイメージをリポジトリにプッシュするための適切なアクセス許可が設定されていることを確認しました。
セキュリティエンジニアがコンテナイメージをプッシュしようとすると、次のエラーを受け取ります。
no basic auth credentials
このエラーを解決する最適な方法を選択してください。
■ 選択肢
A. 新しい認証トークンを取得します。
B. us-east-1 で AWS Security Token Service (AWS STS) を有効にします。
C. aws-auth-cm.yaml
ファイルを変更して、セキュリティエンジニアの IAM ロールを含めます。
D. us-east-1 を使用するように AWS CLI を設定します。
✅ 正解
■ 問題文の要件の概要
- ECR に対する push 操作で
no basic auth credentials
エラーが発生している。 aws ecr get-login-password
は実行済みで、トークンの期限はまだ有効。- IAM 権限の不足も確認済。
- 原因を突き止めて 最適な解決策 を選ぶ必要がある。
■ 正解の選択肢と解説
✅ D. us-east-1 を使用するように AWS CLI を設定します。
解説:
aws ecr get-login-password
コマンドで取得される認証トークンはリージョン固有。- トークンは us-east-1 用の ECR リポジトリで使用するためには、CLI の操作も 同じ us-east-1 リージョンで行う必要がある。
- トークン自体が有効であっても、CLI の設定リージョンが異なると push 時に無効扱いされてしまい、「
no basic auth credentials
」というエラーが出る。 - AWS CLI で
--region us-east-1
を明示するか、~/.aws/config
にregion = us-east-1
を設定すれば解決。
■ 不正解の選択肢の理由
選択肢 | 理由 |
---|---|
A. 新しい認証トークンを取得 | トークンは最大12時間有効。4時間以内に取得されているなら、有効期限の問題ではない。原因はリージョン不一致。 |
B. STS を有効化 | STS は一時認証情報の発行に使うが、今回の問題とは無関係。ECR 認証には直接関係しない。 |
C. aws-auth-cm.yaml を編集 | これは Amazon EKS 用の設定ファイル。ECR とは無関係。IAM ロールの追加も必要なし。 |
■ SCS試験で押さえておくべきポイント
- ✅ ECR 認証はリージョンごとに管理される → 認証トークンもリージョンに依存。
- ✅
aws ecr get-login-password --region <region>
を実行する際、ECR リポジトリのリージョンと一致していないと認証に失敗。 - ✅
no basic auth credentials
は典型的な「Docker への認証失敗」エラーであり、認証トークン不正・未設定・リージョン不一致が原因の大半。 - ✅ EKS / IAM / STS の設定ミスと混同しないこと。文脈に合う原因を見極める力が問われる。
この問題は「ECR 認証のリージョン依存性」と「エラーメッセージの原因特定力」を問う良問です。AWS CLI で ECR を操作する際は、常に --region
を意識しましょう。
以下に「**問題6(不正解済)」の内容を改めて指定の形式で整理・解説します。
■ 問題文
会社のポリシーでは、Amazon EC2 インスタンスで安全でないサーバープロトコルを使用しないことが求められています。これらのプロトコルには、FTP、Telnet、および HTTP が含まれます。
会社のセキュリティチームは、スケジュールされた Amazon EventBridge (CloudWatch Events) を使用して現在のインフラストラクチャを確認し、定期的なレポートを作成することによって、この要件へのコンプライアンスを評価したいと考えています。会社の EC2 インスタンスのコンプライアンスを確認する最適な方法を選択してください。
■ 選択肢
A. すべての EC2 インスタンスのポート構成をターゲットとする Amazon GuardDuty 脅威検出分析を有効にします。
B. すべての EC2 インスタンスに対して、restricted-common-ports ルールの AWS Config ルール評価を呼び出します。
✅ C. インスタンスに対して Network Reachability のルールパッケージを使用して、Amazon Inspector の評価を実行します。
D. すべての AWS ベストプラクティスのセキュリティチェックのために AWS Trusted Advisor API を照会します。「推奨されるアクション」のステータスを確認します。
■ 問題文の要件の概要
- 禁止したいプロトコル: FTP(21番)、Telnet(23番)、HTTP(80番)
- 監査対象: EC2 インスタンス
- 方式: EventBridge による定期チェック → レポート化(継続的コンプライアンス)
- 求められる結果: ポリシーに準拠しているかどうかを検出できる仕組み
■ 正解の選択肢と解説
✅ C. Amazon Inspector の Network Reachability ルールパッケージを使って評価を実行する
解説:
- Amazon Inspector は EC2 インスタンスやコンテナに対する セキュリティスキャン を提供するサービス。
- Network Reachability のルールパッケージは、インスタンスが外部とどのように通信可能か(例:FTPやTelnetのポートが開いているか)をチェックできる。
- EventBridge を使えばこの評価をスケジュール化して、継続的な監視とレポート生成が可能。
- つまり、会社ポリシー(危険プロトコルの禁止)に対するコンプライアンス監査に最適。
■ 不正解の選択肢の理由
選択肢 | 理由 |
---|---|
A. GuardDuty | GuardDuty は異常な通信やマルウェアのような脅威の検出が主目的。ポートやプロトコルの開放状況を静的に監査する目的には不向き。 |
B. AWS Config の restricted-common-ports | restricted-common-ports はセキュリティグループのルール評価。EC2 のインスタンス上で実際に使われているプロトコルの検出はできない。 |
D. Trusted Advisor | Trusted Advisor はコスト削減やパフォーマンス最適化のためのガイドラインチェックが中心。EC2 のアプリケーションレベルのプロトコル使用までは見ない。 |
■ SCS試験で押さえておくべきポイント
- ✅ Amazon Inspector + Network Reachability は、インスタンスが外部とどのように接続可能かを可視化する強力な手段。
- ✅ 定期的なセキュリティチェックをしたい場合 → EventBridge でスケジュール + Inspector 評価の組み合わせがベストプラクティス。
- ✅ AWS Config、GuardDuty、Trusted Advisor はそれぞれ目的が異なるので、問題文の要件に適したサービス選定が重要。
この問題は「プロトコル制限のコンプライアンス評価」という明確な要件に対して、どのサービスが最も適切かを判断できるかが問われる良問です。選択肢に出てくるサービスの特徴・役割の違いを正確に理解することが合格の鍵です。
以下に「**問題7(不正解済)」の内容を、指定の形式で整理・解説いたします。
■ 問題文
Amazon EC2 インスタンス上で動作するアプリケーションは、レガシーなアプリケーションにアクセスするために、ユーザー名とパスワードを使用する必要があります。開発者は、デフォルトの AWS Key Management Service (AWS KMS) キーを使用して、SecureString タイプで AWS Systems Manager Parameter Store にそれらのシークレットを保存しています。
アプリケーションが API を介してシークレットにアクセスできるようにする構成手順の組み合わせを選択してください。 (2 つ選択)
■ 選択肢
A. Systems Manager サービスロールに、EC2 インスタンスのロールを信頼されたサービスとして追加します。
B. SSM サービスロールを信頼できるサービスとして EC2 インスタンスのロールに追加します。
✅ C. KMS 暗号化キーの復号化を許可するアクセス許可を EC2 インスタンスのロールに追加します。
✅ D. Systems Manager パラメータの読み取りを許可するアクセス許可を EC2 インスタンスのロールに追加します。
E. Systems Manager サービスロールにアクセス許可を追加して、KMS 暗号化キーを復号化できるようにします。
■ 問題文の要件の概要
- EC2 上のアプリケーションから SecureString で保存された認証情報(ユーザー名・パスワード)を読み取りたい。
- シークレットは Parameter Store にあり、KMS で暗号化されている。
- 使用するのは「API 経由で取得」するアプローチ。
- 正しい構成(IAM 権限やアクセス設定)を 2つ選ぶ。
■ 正解の選択肢と解説
✅ C. KMS の復号化を許可するアクセス許可を EC2 のロールに付与
SecureString
型は KMS による暗号化がされているため、復号化権限 (kms:Decrypt
) が必要。- EC2 インスタンスの IAM ロールにこのアクセス許可が必要です。
✅ D. SSM パラメータの読み取りを許可するアクセス許可を EC2 のロールに付与
- パラメータストアから値を取得するには
ssm:GetParameter
などの IAM アクションが必要。 - EC2 のアプリケーションはそのロールを通じてアクセスするため、そのロールに直接付与すべきです。
■ 不正解の選択肢の理由
選択肢 | 理由 |
---|---|
A. Systems Manager のロールに EC2 のロールを信頼サービスとして追加 | 意味のない信頼関係。そもそも EC2 側のロールに必要な権限を与えるべきで、サービス間の信頼関係構成ではない。 |
B. SSM のロールを EC2 のロールの信頼サービスに追加 | 逆向きの信頼関係も同様に無意味。EC2 のロールに必要な権限を付与するのが正解。 |
E. Systems Manager のロールに KMS 復号化権限を付与 | SSM のサービスロールに付与しても、アプリケーションが使う EC2 の IAM ロールに直接権限がないため無意味。アクセスに使われる実体は EC2 側。 |
■ SCS試験で押さえておくべきポイント
- ✅ SecureString パラメータを使うと自動的に KMS 暗号化が関与する →
kms:Decrypt
権限が必要。 - ✅ パラメータへのアクセスは EC2 の IAM ロールに対して明示的に許可が必要。
- ❌ SSM サービスロールとの信頼関係や権限付与は、本件のような「アプリが直接 API で取得」するケースとは無関係。
- ✅ IAM ポリシーは「誰が」「何に対して」「どんな操作を」許可するか、という基本形に沿って判断する。
この問題は「SecureString パラメータ取得時にどんな IAM 権限が必要か」を理解しているかどうかを問う典型的な問題です。
API 経由でアプリケーションがアクセスする = 実行元の IAM ロールに直接アクセス権限を持たせるという基本が重要です。