以下に、問題1を指定フォーマットで整理・解説します。
■問題文(文字列を編集せずに出力)
会社は AWS Config と AWS Organizations を使用しています。同社のアカウント管理者の 1 人が最近 AWS Config の記録を無効にしたところ、重要なセキュリティインシデントが適切に記録されませんでした。会社のセキュリティエンジニアは、すべてのユーザーが AWS Config を無効にする機能を拒否する SCP を作成する必要があります。また、SCP は、ApprovedAdministrator ロールに AWS Config 設定の編集を許可する必要があります。
これらの要件を満たす SCP を選択してください。
■選択肢(文字列を編集せずに出力)
A.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"config:DeleteConfigRule",
"config:DeleteConfigurationRecorder",
"config:DeleteDeliveryChannel",
"config:StopConfigurationRecorder"
],
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": "arn:aws:iam::*:role/ApprovedAdministrator"
}
}
}
]
}
B.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"config:DeleteConfigRule",
"config:DeleteConfigurationRecorder",
"config:DeleteDeliveryChannel",
"config:StopConfigurationRecorder"
],
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws : PrincipalArn": "arn:aws:iam::*:role/ApprovedAdministrator"
}
}
}
]
}
C.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"config:DeleteConfigRule",
"config:DeleteConfigurationRecorder",
"config:DeleteDeliveryChannel",
"config:StopConfigurationRecorder"
],
"Resource": "*",
"NotPrincipal": {
"AWS": {
"arn:aws:iam::*:role/ApprovedAdministrator"
}
}
}
]
}
D.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"config:DeleteConfigRule",
"config:DeleteConfigurationRecorder",
"config:DeleteDeliveryChannel",
"config:StopConfigurationRecorder"
],
"Resource": "*",
"Principal": {
"AWS": {
"arn:aws:iam::*:role/ApprovedAdministrator"
}
}
}
]
}
■問題文の要件の概要
- すべてのユーザーに対して AWS Config を無効化する権限を制限したい(Deny)
- ただし例外として、
ApprovedAdministrator
ロールには許可したい(Allow) - SCP(Service Control Policy)で管理
- 必要なアクション:
DeleteConfigRule
,DeleteConfigurationRecorder
,DeleteDeliveryChannel
,StopConfigurationRecorder
■正解の選択肢と解説
正解:A
✅ 解説:
- SCPはデフォルトで「明示的に許可されていないアクションは拒否される」ため、全体に許可を出さなければその操作は無効。
- このポリシーでは、
ApprovedAdministrator
ロールのみに対して AWS Config の無効化に関する操作を許可している。 - 他のすべてのユーザーには明示的な許可がないため、自動的に拒否され、要件通りになる。
■不正解の選択肢の理由
- B.
Deny
で ApprovedAdministrator に制限- ❌ Conditionが一致した場合に拒否されるため、
ApprovedAdministrator
にこそ拒否が適用されてしまう。
- ❌ Conditionが一致した場合に拒否されるため、
- C.
NotPrincipal
を使用- ❌ SCP では
NotPrincipal
はサポートされていない構文。公式ドキュメント明記済み
- ❌ SCP では
- D.
Principal
を使用- ❌ 同様に、SCP では
Principal
句は使用不可。IAMポリシーとは異なり、対象は Organizations 内のエンティティで制御。
- ❌ 同様に、SCP では
■SCS試験で押さえておくべきポイント
- SCP は AWS Organizations で使う上位制御ポリシー
- 各アカウントやOUに対して「何を許可するか/しないか」を制御
- SCP は Allow ベースに設計される(許可されていないものはすべて拒否)
- SCPでは以下の構文が使用できない:
Principal
,NotPrincipal
,NotResource
- Condition による
aws:PrincipalArn
指定は例外的なアクセス許可に使える - AWS Config の重要なアクション(Delete/Stop など)はセキュリティ上の監査と無効化対策として強制的に制限する必要がある
次の問題があればどうぞ送ってください。SCP や Config の制御は出題頻度も高く、理解しておくと高得点に直結します。
以下に、問題2 を指定形式で整理・解説します。
■問題文(文字列を編集せずに出力)
セキュリティエンジニアが AWS WAF の使用方法を調査しています。ウェブアクセスコントロールリスト (ウェブ ACL) によってトリガーされる AWS WAF ルールに関連する正当なイベントソースを選択してください。 (2 つ選択)
■選択肢(文字列を編集せずに出力)
A. Amazon CloudFrontディストリビューション
B. Amazon Route 53
C. Application Load Balancer
D. Amazon S3 静的ウェブホスティング
E. VPC フローログ
■正解の選択肢と解説
正解:A(CloudFront)と C(ALB)
✅ 解説:
AWS WAF(Web Application Firewall)は、以下のサービスに対してWeb ACL(アクセス制御)をアタッチしてルールを適用することができます:
- ✅ Amazon CloudFront
→ グローバルCDNにWAFルールを適用し、エッジロケーションで悪質トラフィックをブロック可能。 - ✅ Application Load Balancer (ALB)
→ Webアプリケーションの入り口でWAFを適用し、アプリケーションに届く前に攻撃を防御。 - (補足)AWS WAF は他にも以下に対応:
- ✅ Amazon API Gateway
- ✅ AWS AppSync(GraphQL)
■不正解の選択肢の理由
- B. Route 53
❌ DNSサービスであり、WAFを直接アタッチできない。DNSトラフィックにはWAF適用不可。 - D. Amazon S3 静的ウェブホスティング
❌ S3自体にはALBやAPI GatewayのようなWAFを直接関連付けることができない。 - E. VPC フローログ
❌ VPC内のネットワークトラフィックのログを記録するものであり、WAFとの統合は存在しない。
■SCS試験で押さえておくべきポイント
覚えておくべき項目 | 内容 |
---|---|
✅ AWS WAFの対象 | CloudFront / ALB / API Gateway / AppSync |
✅ WAFの役割 | アプリケーション層の攻撃(SQLi/XSS/Botなど)から保護 |
❌ 統合できない | Route 53 / S3 static hosting / VPCフローログ |
✅ CloudFrontとの利点 | エッジでフィルタリングして遅延を最小限に |
✅ ALBとの利点 | VPC内のWebアプリに直接適用して保護 |
続けて他の問題もあればお送りください。AWS WAFの出題はサービス連携と機能の適用範囲を正確に理解することがポイントです。
以下に、問題3 を指定フォーマットで整理して解説します。
■問題文(文字列を編集せずに出力)
セキュリティエンジニアが、アプリケーションをサポートするクラウドアーキテクチャを設計しています。このアプリケーションは Amazon EC2 インスタンス上で実行され、クレジットカード番号などの機密情報を処理します。
アプリケーションは、隔離された環境で実行されているコンポーネントにクレジットカード番号を送信します。このコンポーネントは番号を暗号化し、保存し、復号化します。次に、コンポーネントはトークンを発行し、アプリケーションの他の部分で番号を置き換えます。
トークン化プロセスを管理するアプリケーションのコンポーネントは、別の EC2 インスタンスのセットにデプロイされます。アプリケーションの他のコンポーネントは、クレジットカード番号を保存したり、アクセスしたりできないようにする必要があります。
これらの要件を満たすソリューションを選択してください。
■選択肢(文字列を編集せずに出力)
A. トークン化プロセスを管理する EC2 インスタンスをパーティションプレイスメントグループに配置します。
B. EC2 インスタンス上でホストされている AWS Nitro Enclaves にトークン化コードをデプロイします。
C. データのトークン化をサポートするために、別の VPC に新しい EC2 インスタンスを配置します。
D. アプリケーションのトークン化コンポーネントに EC2 ハードウェア専有インスタンスを使用します。
■問題文の要件の概要
- アプリケーションは EC2 上で動作し、機密情報(クレジットカード番号)を処理する
- トークン化処理は分離されたコンポーネントが実施する
- アプリケーションの他の部分から機密データへのアクセスを完全に遮断する必要がある
■正解の選択肢と解説
正解:B. EC2 インスタンス上でホストされている AWS Nitro Enclaves にトークン化コードをデプロイします。
→ AWS Nitro Enclaves は、EC2 内で高度に隔離された実行環境(enclave)を提供し、外部ネットワークや親インスタンスのアプリケーションからのアクセスを遮断できます。
そのため、クレジットカード番号などの機密情報を暗号化・復号化・トークン化する処理を安全に行え、他のコンポーネントからのアクセスを物理的に排除できます。
■不正解の選択肢の理由
- A. パーティションプレイスメントグループ
❌ これは可用性向上や障害分離のための配置戦略であり、セキュリティ上の分離を実現するものではない。 - C. 別のVPCにEC2を配置
❌ VPCを分けても、適切なルーティングやセキュリティグループ設定がなければ他コンポーネントからのアクセスを完全に防げない。アプリケーション内部からの不正アクセスを防ぐには不十分。 - D. EC2ハードウェア専有インスタンス
❌ ハードウェアレベルの専有は提供されるが、同一インスタンス内でのプロセス間隔離はできないため、機密データの保護には適さない。
■SCS試験で押さえておくべきポイント
ポイント | 内容 |
---|---|
✅ AWS Nitro Enclaves | EC2内で隔離された安全な環境。ネットワーク・ストレージ・ユーザーから完全に隔離。 |
✅ トークン化 | セキュリティ設計上、元データへの直接アクセスを避け、トークンによって業務利用する方式。 |
❌ プレイスメントグループ | 可用性や障害分離のための配置設定であり、セキュリティ用途には適さない。 |
❌ 専有インスタンス | ハードウェアレベルの隔離であり、同一インスタンス内のデータアクセス制御には不十分。 |
❌ 別VPC構成 | ネットワークレベルの分離にはなるが、アプリケーション間の信頼性制御には限界がある。 |
次の問題があれば、引き続きどうぞ。AWS Nitro Enclaves は 機密データ処理のベストプラクティスとして非常に重要なトピックです。
以下に、問題4 の解説を指定フォーマットでまとめます。
■問題文(そのまま)
会社は、AWS アカウントの単一の VPC 内で複数のアプリケーションをホストしています。アプリケーションは、AWS WAF のウェブ ACL に関連付けられた Application Load Balancer の背後で実行されています。同社のセキュリティチームは、複数のポートスキャンがインターネット上の特定の範囲の IP アドレスから発信されていることを確認しました。
セキュリティエンジニアは、問題のある IP アドレスからのアクセスを拒否する必要があります。
これらの要件を満たすソリューションを選択してください。
■選択肢(そのまま)
A. IP セット一致ルールステートメントを使用して AWS WAF のウェブ ACL を変更し、IP アドレス範囲からの着信リクエストを拒否します。
B. すべてのセキュリティグループにルールを追加して、IP アドレス範囲からの着信リクエストを拒否します。
C. レートベースのルールステートメントを使用して AWS WAF のウェブ ACL を変更し、IP アドレス範囲からの着信リクエストを拒否します。
D. 正規表現一致条件を使用して AWS WAF のウェブ ACL を設定します。一致条件に基づいて着信リクエストを拒否するパターンセットを指定します。
■正解の選択肢と解説
正解:A. IP セット一致ルールステートメントを使用して AWS WAF のウェブ ACL を変更し、IP アドレス範囲からの着信リクエストを拒否します。
→ IP セット一致ルールステートメントは、特定の IP アドレスや IP レンジに基づいてトラフィックを拒否するのに最適な方法です。AWS WAF のウェブ ACL にこのルールを追加することで、特定の悪意のある IP からのトラフィックをブロックできます。
■不正解の選択肢の理由
- B. セキュリティグループに拒否ルールを追加
❌ セキュリティグループは拒否ルールをサポートしません。デフォルトですべて拒否し、明示的な許可ルールだけを設定できる仕組みのため、本件では対応不可。 - C. レートベースのルールを使用
❌ レートベースルールは「同一IPからのアクセス回数が多すぎる場合に制限をかける」用途です。今回のように特定のIP範囲を即座に拒否したい場合には不適です。 - D. 正規表現一致条件を使う
❌ 正規表現マッチは「URIやヘッダーの文字列パターン」に対して有効であり、IPアドレスのマッチには使用できません。IPブロックの用途には向いていません。
■SCS試験で押さえておくべきポイント
項目 | 内容 |
---|---|
✅ IPセット一致ルール | WAFで特定のIPレンジを拒否するための主要手段。最も直接的な方法。 |
❌ セキュリティグループの仕様 | 許可のみの設定が可能。拒否は不可。ACLとの違いに注意。 |
❌ レートベースルール | リクエスト回数が多いIPをブロック。一時的・条件付きブロック向け。 |
❌ 正規表現一致 | URIやクエリ文字列など文字列パターンに対してのみ適用可能。 |
必要であれば、IPセットのWAFルール作成例もご紹介できます。続けての問題もどうぞ。
以下に、問題5 の内容を指定フォーマットで整理します。
■問題文(そのまま)
ある企業では、AWS の Auto Scaling グループ内の Elastic Load Balancer (ELB) の背後に、プライベートサブネットで数十台のアプリケーションサーバーを配置しています。アプリケーションは、HTTPS でウェブからアクセスされます。データは転送中に常に暗号化されている必要があります。セキュリティエンジニアは、アプリケーションソフトウェアの脆弱性による潜在的なキーの公開を心配しています。
侵害時に外部の証明書を保護しながら、これらの要件を満たすアプローチを選択してください。
■選択肢(そのまま)
A. 外部の証明書を購入し、それを AWS Certificate Manager (ELB で使用するため ) とインスタンスにアップロードします。ELB でトラフィックを復号化し、同じ証明書を使用してルーティングして再暗号化します。
B. Network Load Balancer (NLB) を使用して、インターネットからのポート 443 のトラフィックをインスタンスのポート 443 に通過させます。
C. 内部の自己署名証明書を生成し、インスタンスに適用します。AWS Certificate Manager を使用して、ELB 用の新しい外部の証明書を生成します。ELB にトラフィックを復号化させ、内部の証明書を使用してルーティングして再暗号化します。
D. ロードバランサーに新しい外部の証明書をアップロードします。ELB にトラフィックを復号化させ、ポート 80 でインスタンスに転送させます。
■問題文の要件の概要
- データ転送中は常に暗号化されている必要がある(end-to-end encryption)
- アプリケーションソフトウェアの脆弱性によって証明書キーが漏れるリスクが懸念されている
- 外部証明書のセキュリティ(キー漏洩防止)を保ちつつ通信を暗号化したい
■正解の選択肢と解説
正解:C. 内部の自己署名証明書を使用し、ELB には ACM 管理の外部証明書を使ってHTTPSを終端、内部トラフィックも暗号化(再暗号化)する。
→ この方法は、ELBで外部証明書によるHTTPS通信を終端し、インスタンス側では別の内部用証明書でHTTPS通信を再構成することで、エンドツーエンドの暗号化を保ちつつ、外部証明書の秘密鍵をインスタンスに持たせない構成になります。これにより、インスタンスの侵害時にも外部証明書の漏洩を防げます。
■不正解の選択肢の理由
- A. 同じ証明書をELBとインスタンスで使う
❌ 同じ証明書とキーを使い回すのはベストプラクティス違反です。インスタンスが侵害された場合、外部公開証明書の秘密鍵も漏洩するリスクがあります。 - B. NLBを使用して直接トラフィックを通す
❌ 暗号化は保てますが、ロードバランサーでの復号がないためWAFやセキュリティ制御ができません。また、証明書管理がインスタンス依存になりリスクが高まります。 - D. ELB → HTTP (ポート80) で内部転送
❌ バックエンドの通信が**平文(暗号化されていない)となり、「転送中は常に暗号化」**という要件を満たせません。
■SCS試験で押さえておくべきポイント
観点 | ポイント |
---|---|
🔐 セキュアな証明書管理 | 秘密鍵はできるだけ少ない場所に配置(外部証明書をインスタンスに置かない) |
🔄 再暗号化(re-encryption) | ELBで復号 → EC2へは別証明書で再暗号化する構成がベストプラクティス |
📶 HTTPSバックエンド | 内部通信もHTTPSを使用して「転送中の暗号化」を維持する |
🧾 ACMの利用 | 外部証明書の管理はAWS Certificate Managerで行い、安全かつ自動更新 |
このパターンはSCS試験で頻出の「ELBでのSSL終端+内部再暗号化」の代表例です。次の問題も準備でき次第どうぞ。
以下に 問題6 の内容を指定フォーマットで整理します。
■問題文(そのまま)
ある大企業がマルチアカウント戦略を策定しており、従業員が AWS インフラストラクチャにアクセスする方法を決定する必要があります。
最もスケーラブルなソリューションを提供するソリューションを選択してください。
■選択肢(そのまま)
A. 既存の ID プロバイダーとのフェデレーションを通じて従業員が引き受けることができる IAM ロールを持つ一元化されたアカウントを使用します。クロスアカウントロールを使用して、フェデレーションユーザーがリソースアカウントで目標とするロールを引き受けることができるようにします。
B. Kerberos トークンを使用するように AWS Security Token Service (AWS STS) を設定して、ユーザーが既存の企業ユーザー名とパスワードを使用して AWS リソースに直接アクセスできるようにします。
C. AWS アカウントごとに、既存の ID プロバイダーのグループメンバーシップに基づいてフェデレーションを通じて従業員が引き受けることができる専用の IAM ユーザーを作成します。
D. 各アカウントのロール内で IAM 信頼ポリシーを設定して、企業の既存の ID プロバイダーへの信頼を設定し、ユーザーが SAML トークンに基づいてロールを引き受けることができるようにします。
■問題文の要件の概要
- 大企業が マルチアカウント戦略 を採用
- 従業員が AWSインフラにアクセスする方法を決定したい
- 要件:スケーラブルなソリューション
■正解の選択肢と解説
正解:A. フェデレーション + 中央アカウント + クロスアカウントロールの使用
→ この方法は、中央認証(IDフェデレーション)とIAMロールのクロスアカウント委任を組み合わせた、AWSが推奨する最もスケーラブルな方法です。
- 中央の「認証アカウント」でIDプロバイダー(例:Active Directory, Azure AD, Okta)と連携してログインさせる
- リソースアカウント(各AWSアカウント)では 信頼ポリシー付きロールを定義
- 従業員は必要に応じて
assume-role
によりリソースアカウントにアクセスする
この仕組みは、アカウントの数やユーザー数が増えても、権限の一元管理・動的割り当て・スケール対応が可能です。
■不正解の選択肢の理由
- B. Kerberos トークンを使ったSTSアクセス
❌ Kerberos はオンプレミスの認証方式であり、AWSネイティブでのサポートはなく、SAMLやOIDCに比べ実現性が低い。スケーラビリティにも欠けます。 - C. 各アカウントごとに専用IAMユーザー作成
❌ アカウント数に比例してIAMユーザー管理が煩雑化し、運用負荷が高くスケーラブルでない。 - D. 各アカウントで個別にSAMLフェデレーションを構成
❌ SAMLフェデレーション自体は正しいが、各アカウントごとに設定するのは非効率。一元化アカウントを介した構成の方が運用性に優れる。
■SCS試験で押さえておくべきポイント
観点 | ポイント |
---|---|
🧑💼 フェデレーション認証 | 企業の既存IDプロバイダー(IdP)と統合し、IAMロールに一時的アクセスを与える |
🏢 マルチアカウント構成 | 中央認証 + クロスアカウントロールがベストプラクティス |
🔑 IAMユーザーは最小限に | スケーラブルな管理にはIAMユーザーを避け、ロールとSTSを使う |
🔗 クロスアカウントアクセス | 信頼ポリシーで「どのIdPフェデユーザーが、どのロールを引き受けるか」を制御 |
🧩 スケーラブル構成 | 中央認証アカウントとロールベースのアクセス委任がAWS推奨構成 |
この設問は、AWS SCS試験における **「アイデンティティ統合とアクセススケーラビリティ」**の要の1つです。次の問題があればどうぞお送りください。
以下に 問題7 の内容を指定フォーマットで整理します。
■問題文(そのまま)
ある企業が Amazon GuardDuty を導入したところ、かなりの数の社内の IP アドレスが見つかりました。セキュリティエンジニアは、これらの IP アドレスが信頼できるものであり、許可されていることを確認しました。
これらの IP アドレスの検出結果が生成されないように GuardDuty を設定するための最適な方法を選択してください。 (2 つ選択)
■選択肢(そのまま)
A. 構成ファイルを Amazon S3 にアップロードします。そのファイルを指す新しい信頼済み IP リストを GuardDuty に追加します。
B. 信頼できる IP アドレスを含む JSON の構成ファイルを作成します。
C. 構成ファイルを GuardDuty に直接アップロードします。
D. 構成ファイルのデータを手動でコピーして、GuardDuty の信頼できる IP リストに貼り付けます。
E. 信頼できる IP アドレスを含むプレーンテキストの構成ファイルを作成します。
■問題文の要件の概要
- GuardDuty で社内IPが多数検出された
- セキュリティチームはそれらが 信頼できるIP と確認済み
- 検出対象から 除外(アラート抑制) したい
- 正しい形式で信頼済みIPリストを作成・GuardDutyに登録する方法を問う
- 2つ選択
■正解の選択肢と解説
✅ A. S3 に構成ファイルをアップロードし、信頼済みIPリストとして追加する
✅ E. プレーンテキストの構成ファイルを作成する
解説:
Amazon GuardDuty では、**信頼済みIPリスト(Trusted IP list)**を使って、特定のIPからの通信を検出結果の対象外にできます。
- プレーンテキスト形式でIP/CIDRリストを記述し
- Amazon S3にアップロード
- GuardDuty の「信頼済みIPリスト」として登録
この方法により、社内ネットワーク等の信頼できるIPの誤検知を回避できます。
■不正解の選択肢の理由
❌ B. JSON形式の構成ファイルを作成する
→ GuardDuty が受け付けるのは プレーンテキスト形式。JSONは未対応。
❌ C. GuardDuty に直接アップロードする
→ GuardDuty は S3バケット経由でのファイル指定のみ対応。直接アップロードはできない。
❌ D. 構成ファイルをコピーして手動で貼り付ける
→ GuardDuty の信頼済みIPリストはGUIで手動入力するものではなく、S3経由で一括管理する前提。
■SCS試験で押さえておくべきポイント
観点 | ポイント |
---|---|
✅ GuardDuty 設定 | 検出結果をカスタマイズするには 信頼済みIPリスト / 脅威リストを使う |
✅ フォーマット | GuardDutyの信頼済みIPリストは プレーンテキスト形式(IP or CIDR) |
✅ 登録方法 | S3にアップロードした構成ファイルを GuardDutyで参照登録する |
✅ 除外対象 | 信頼済みIPは VPC Flow LogsやCloudTrail検出結果から除外される(DNSは除外対象外) |
✅ 除外用途 | 誤検知のノイズ削減、重要アラートへの集中を実現 |
この設問は「GuardDuty のチューニングと検出精度の制御」というセキュリティ運用に関する実践的なトピックで、実務にも直結します。
次の問題があれば続けてどうぞ。