以下に、問題1を指定フォーマットで整理・解説いたします。
■ 問題文
ある企業は、Application Load Balancer (ALB) のアクセスログを分析する必要があります。ALB は、企業のオンラインログインポータルへのトラフィックをルーティングしています。企業は、既知の IP ソースのリストを使用して、ボットによるログイン試行を特定するために視覚化を行う必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
ログを Amazon S3 バケットに直接送信するように ALB を設定します。Amazon Athena を使用してログを分析し、Amazon QuickSight を使用して視覚化します。
B.
ログを Amazon Redshift に直接送信するように ALB を設定します。SQL クエリを使用してログを分析し、カスタムレポートを使用して視覚化します。
C.
ログを Amazon OpenSearch Service に直接送信するように ALB を設定します。OpenSearch Dashboards を使用してログを分析し、カスタム OpenSearch Dashboards を使用して視覚化します。
D.
ログを Amazon CloudWatch Logs に直接送信するように ALB を設定します。CloudWatch Logs Insights を使用して、ログを分析および視覚化します。
■ 正解の選択肢と解説
正解：A.
ログを Amazon S3 バケットに直接送信するように ALB を設定します。Amazon Athena を使用してログを分析し、Amazon QuickSight を使用して視覚化します。
解説：
- ALBアクセスログはS3バケットへの出力が公式にサポートされている。
- Amazon Athena は S3 上の ALB アクセスログに対して直接 SQL クエリを実行でき、IP アドレスの照合やフィルタ処理が簡単に可能。
- Amazon QuickSight は Athena クエリ結果を用いて視覚化が可能で、ボット検出やアクセス傾向の可視化に適している。
- この組み合わせは構成がシンプルでスケーラブルかつフルマネージドである。
■ 不正解の選択肢の理由
| 選択肢 | 誤りの理由 |
|---|---|
| B. Redshift | ALB から直接 Redshift にログ送信はできない。中間処理が必要でコストも高い。 |
| C. OpenSearch | ALB から OpenSearch への直接送信はサポートされていない。ログ転送処理を別途設ける必要がある。 |
| D. CloudWatch Logs | ALB アクセスログは CloudWatch Logs に直接出力できない（NLBでは可）。CloudWatch Logs への転送には Lambda などの介在が必要。 |
■ SCS試験で押さえておくべきポイント
- ALBのアクセスログの出力先はS3のみ。
- 出力を可能にするには、バケットのポリシー設定も正しく行う必要がある。
- Athena + QuickSight の連携は、ログ解析と可視化の代表的ベストプラクティス構成。
- OpenSearch や CloudWatch Logs はログ分析ツールだが、ALB の直接送信先にはならないため、出題の文脈では誤り。
- Athena はサーバーレスの分析基盤で、S3に保存されたログとの相性が良い。
次の問題もお待ちしております。引き続き、出題形式での解説をご希望の場合はそのまま送ってください！
以下に、問題2を指定フォーマットで整理・解説いたします。
■ 問題文
ある企業のセキュリティポリシーでは、すべての Amazon EC2 インスタンスが Amazon Time Sync Service を使用する必要があります。会社のすべての AWS アカウントで AWS CloudTrail の証跡が有効になっています。VPC フローログはすべての VPC で有効になっています。
セキュリティエンジニアは、インターネット上のネットワークタイムプロトコル (NTP) サーバーを使用しようとする EC2 インスタンスを特定する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
Amazon Time Sync Service への API コールについて CloudTrail ログを監視します。
B.
非標準のタイムサーバーへの API コールについて CloudTrail ログを監視します。
C.
Amazon Time Sync Service へのトラフィックについて VPC フローログを監視します。
D.
非標準のタイムサーバーへのトラフィックについて VPC フローログを監視します。
■ 問題文の要件の概要
- すべてのEC2がAmazon Time Sync Serviceを使う必要がある（＝外部NTPサーバー使用はNG）。
- EC2インスタンスが外部NTP（UDP 123）に通信していないか確認したい。
- AWS CloudTrail と VPC Flow Logs はすでに有効。
■ 正解の選択肢と解説
正解：D. 非標準のタイムサーバーへのトラフィックについて VPC フローログを監視します。
解説：
- Amazon Time Sync Service（IP:
169.254.169.123）以外へのUDPポート123（NTP）通信を検出すれば、非標準のNTPサーバー使用が分かる。 - VPCフローログでは、通信先IPアドレス・ポートをログとして取得可能。
- よって「非標準のタイムサーバーへのトラフィック」を監視すれば、企業のポリシーに違反するEC2インスタンスを特定可能。
■ 不正解の選択肢の理由
| 選択肢 | 誤りの理由 |
|---|---|
| A | CloudTrail は API 呼び出しの監視用であり、NTP は API ではなくネットワークプロトコル（UDP 123）で動作。CloudTrail に記録されない。 |
| B | 同様に、非標準タイムサーバーへのアクセスもネットワーク通信であり、CloudTrailでは検出不可。 |
| C | Amazon Time Sync Service（許可されているサービス）への通信を監視しても、問題のある通信は検出できない。必要なのは「非標準」の監視。 |
■ SCS試験で押さえておくべきポイント
- Amazon Time Sync Service
- EC2から
169.254.169.123にUDP 123でアクセス可能。外部NTP不要。
- EC2から
- CloudTrailはAPIコールを記録
- ネットワークプロトコル（NTP, SSH, HTTPなど）ベースの通信は対象外。
- VPCフローログはネットワークメタデータを記録
- 送信元/送信先IP、ポート番号、通信量などの情報をもとに監視できる。
- NTP通信（UDP 123）へのフローをチェック
destination-port = 123かつdestination-address != 169.254.169.123などで特定。
次の問題もお送りください！引き続きフォーマットに沿って解説いたします。
以下に、問題3を指定フォーマットで整理・解説いたします。
■ 問題文
セキュリティチームは、クラウド環境における AWS API コールのアクティビティをレビューして、セキュリティ違反がないか確認する責任があります。これらのイベントは、現在および将来の AWS リージョンの両方で一元化された場所に記録および保持する必要があります。
これらの要件を満たす最も簡単な方法を選択してください。
■ 選択肢
A.
AWS CloudTrail を有効にし、リージョンごとに個別の証跡を作成し、後で分析するためにログファイルを受け取る単一の Amazon S3 バケットを指定します。
B.
AWS コンソールで AWS Trusted Advisor のセキュリティチェックを有効にし、すべてのリージョンのすべてのセキュリティインシデントを報告します。
C.
すべてのリージョンのすべての AWS サービスに対して Amazon CloudWatch ログ記録を有効にし、後で分析できるように単一の Amazon S3 バケットに集約します。
D.
新しい証跡を作成してすべてのリージョンに適用することで AWS CloudTrail を有効にします。保存場所として単一の Amazon S3 バケットを指定します。
■ 問題文の要件の概要
- すべての AWS API コールのアクティビティを監査 したい。
- 現在および将来のリージョンすべてを対象にしたい。
- 一元的に記録・保存したい。
■ 正解の選択肢と解説
正解：D.
新しい証跡を作成してすべてのリージョンに適用することで AWS CloudTrail を有効にします。保存場所として単一の Amazon S3 バケットを指定します。
解説：
- CloudTrail は AWS の API コールを記録するサービス。セキュリティや監査に不可欠。
- 「すべてのリージョンに適用」にチェックを入れて証跡を作成すれば、新しいリージョンが追加されたときにも 自動でカバー。
- 単一の S3 バケットを保存先に指定すれば、ログが 一元的に集約され、Athena などを使った分析も可能。
- 最小限の設定で将来も含めた包括的な監査基盤を構築できるベストプラクティス。
■ 不正解の選択肢の理由
| 選択肢 | 誤りの理由 |
|---|---|
| A | リージョンごとに個別証跡を作成すると、将来の新リージョンは自動的にカバーされないため、手動で追加作業が必要になる。 |
| B | Trusted Advisor はセキュリティの推奨事項を提供するツールであり、API コールの記録・監査はできない。 |
| C | CloudWatch は主にメトリクスとアプリケーションログを監視するもので、API コールの追跡（監査）には不向き。CloudTrailとは用途が異なる。 |
■ SCS試験で押さえておくべきポイント
- AWS CloudTrail は AWS API コールの監査ログを取得・保存する唯一の正式サービス。
- 「すべてのリージョンに適用」設定を使うことで、新リージョンも自動的に追跡可能。
- ログは Amazon S3 に保存され、Athena や CloudWatch Logs Insights で分析可能。
- マルチリージョン＆マルチアカウントのログ集約先として、S3 バケットを統一してセキュリティチームが横断的に分析する設計がベストプラクティス。
次の問題もお待ちしています！引き続き、フォーマットに沿って丁寧に解説いたします。
以下に、問題4を指定フォーマットで整理・解説いたします。
■ 問題文
Amazon CloudWatch Logs エージェントは、CloudWatch Logs サービスにログを正常に配信しています。ただし、関連付けられたログストリームが特定の時間アクティブになると、ログの配信が停止します。
この現象の原因を特定するために必要な手順を選択してください。(2 つ選択)
■ 選択肢
A.
AWS CloudFormation を使用して、CloudWatch Logs エージェントの設定ファイルを動的に作成および管理します。
B.
OS ログローテーションルールがエージェントストリーミングの設定要件と互換性があることを確認します。
C.
CloudWatch Logs エージェントにファイルの読み取りを許可する監視対象ファイルのファイル権限が変更されていないことを確認します。
D.
CloudWatch Logs メトリクスを作成して、ロギングが停止するまでの期間中に少なくとも 1 回は変更される値を分離します。
E.
Amazon Kinesis プロデューサーを設定し、最初にログを Amazon Kinesis Streams に送信するようにします。
■ 問題文の要件の概要
- CloudWatch Logs エージェントはログを配信していたが、一定時間後に配信が停止。
- 原因を特定するために取るべき調査手順を2つ選ぶ必要がある。
■ 正解の選択肢と解説
正解：B. OS ログローテーションルールの互換性確認
正解：C. ファイルのアクセス権限の確認
解説：
- B：OSのログローテーション（例：
logrotate）がエージェントのファイル監視設定と一致しないと、ログファイルが別名になったり削除され、エージェントが新しいファイルを追跡できなくなる。これはログ配信停止の原因として非常に一般的。 - C：ファイルのパーミッションが変更されると、CloudWatch Logs エージェントが対象ログファイルを読み取れなくなり、ログ送信が停止する。たとえば root 専用ログなどで起こり得る。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A | CloudFormation は 構成管理用ツールであり、問題の「原因特定」には寄与しない。設定変更やデプロイは可能だが、現象の診断には不適。 |
| D | CloudWatch Logs メトリクスは、ログに出現する数値情報をグラフ化するためのもので、ログ配信停止の根本原因（ファイルの追跡不能など）を突き止めるには不適。 |
| E | Kinesis に送るのはログ転送方法の一つだが、CloudWatch Logs エージェントそのものの配信停止の原因（ファイル権限・ローテーション）を解決しないため、根本解決にならない。 |
■ SCS試験で押さえておくべきポイント
- CloudWatch Logs エージェントの動作停止には、以下の2つが主要原因：
- ファイルのパーミッション問題（読み取り権限がなくなる）
- ログローテーションとの不整合（ファイル名変更、削除で追跡不能）
- エージェントはファイルパスと inode を監視しているが、ローテーション設定により inode が切り替わると追跡不能になる場合がある。
- エージェントの問題は、CloudWatch 側ではなく、OSレイヤーの挙動に原因があることが多いため、OS設定の見直しが必要。
次の問題もお待ちしています。構造化してわかりやすく解説してまいります！
以下に、問題5をSCS試験対策向けに指定フォーマットで整理・解説します。
■ 問題文
ある企業は AWS Organizations を使用して、Production、Development、Testing の 3 つのワークロード OU で構成される組織を管理しています。企業は AWS CloudFormation テンプレートを使用して、OU に関連付けられた AWS アカウントにワークロードインフラストラクチャを定義およびデプロイしています。各ワークロード OU には異なる SCP がアタッチされています。
企業は Development OU および Testing OU のワークロードに CloudFormation スタックの更新を正常にデプロイしました。しかし、同じ CloudFormation テンプレートを使用して Production OU 内のアカウントでスタックの更新をデプロイしようとすると、更新が失敗します。エラーメッセージには IAM 権限が不足していると報告されています。
この問題をトラブルシューティングするために、セキュリティエンジニアが最初に取るべき手順を選択してください。
■ 選択肢
A.
Production OU にアタッチされているすべての SCP を、Testing OU にアタッチされている SCP と同じにします。
B.
CloudFormation が使用するロールに、CloudFormation テンプレートで参照されるリソースを作成、更新、削除するための十分な権限があることを確認します。
C.
Production OU のアカウントで AWS CloudTrail ログを確認します。デプロイの試行中に CloudFormation から失敗した API コールを検索します。
D.
Production OU にアタッチされているすべての SCP を削除します。CloudFormation スタックの更新を再実行して、SCP が CloudFormation API コールを妨げていたかどうかを判断します。
■ 問題文の要件の概要
- CloudFormation テンプレートのスタック更新が Production OU でのみ失敗している。
- エラーメッセージには「IAM 権限不足」とある。
- 他の OU（Development・Testing）では成功。
- 最初に取るべきトラブルシューティングの手順を問う。
■ 正解の選択肢と解説
正解：C. Production OU のアカウントで AWS CloudTrail ログを確認
解説：
- CloudTrail は、実際に実行された API コールの成功/失敗の記録を確認できる唯一の手段。
- SCP によるブロックか、IAM ポリシーの不足かを区別する最初の手がかりとなる。
- CloudFormation が何をしようとしてどの操作で
AccessDeniedになったかを明確に把握することが、原因特定の出発点。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A | Testing OU の SCP を流用するのは 本番環境のセキュリティ要件を軽視した危険な対処法。ポリシーは環境ごとに設計されるべきであり、コピーは推奨されない。 |
| B | IAM ロールの権限が不足していれば他の OU でも失敗しているはず。問題が Production OU に限定されている時点で SCP の影響が濃厚。 |
| D | SCP を全削除するのはガバナンス上危険。まず CloudTrail による分析など、影響を及ぼさない調査を優先するべき。いきなり削除は非常に危険。 |
■ SCS試験で押さえておくべきポイント
- **SCP（Service Control Policies）**は IAM ポリシーとは異なり、「上限制限（明示許可があってもSCPで deny されれば不可）」である。
- CloudFormation が失敗した場合の基本的な調査手順：
- CloudTrail ログを確認し、何の API が失敗したか把握
- IAM ポリシーや SCP の内容を確認して、制限を見直す
- SCP の確認には CloudTrail が第一歩。
- SCP による影響は、IAM ロールではなく OU ごとに異なる可能性があるため、まず原因を isolate（切り分け）する。
次の問題もお送りください。引き続き丁寧に構造化して解説いたします。
以下に、問題6 を指定の形式で整理・解説します。
■ 問題文
ある企業は、Amazon EC2 インスタンス上で機密データの処理を開始したいと考えています。同社は Amazon CloudWatch Logs を使用して、EC2 インスタンスからのログファイルを監視、保存、アクセスします。
同社の開発者は、トラブルシューティングに CloudWatch Logs を使用しています。セキュリティエンジニアは、開発者が機密データを閲覧できないようにするソリューションを実装する必要があります。このソリューションは、将来アカウント内で作成される新しいロググループにも自動的に適用される必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
CloudWatch Logs データを Amazon S3 バケットにエクスポートします。S3 バケットで Amazon Macie を使用して自動検出を設定します。適切なマネージドデータ識別子を指定します。開発者の CloudWatch Logs へのアクセスを削除し、開発者に Amazon S3 でエクスポートされたログデータを表示する権限を付与します。
B.
CloudWatch Logs データを Amazon S3 バケットにエクスポートします。S3 バケットで Amazon Macie を使用して自動検出を設定します。機密データ用のカスタムデータ識別子を作成します。開発者の CloudWatch Logs へのアクセスを削除し、開発者に Amazon S3 でエクスポートされたログデータを表示する権限を付与します。
C.
CloudWatch Logs アカウント全体のデータ保護ポリシーを作成します。ポリシーに適切なデータ識別子を指定します。開発者に logs:Unmask IAM 権限がないことを確認します。
D.
ロググループごとに CloudWatch Logs データ保護ポリシーを作成します。ポリシーに適切なデータ識別子を指定します。開発者に logs:Unmask IAM 権限がないことを確認します。
■ 問題文の要件の概要
- 機密データを含むログが CloudWatch Logs に送信される。
- 開発者がその機密データを閲覧できないようにしたい。
- さらに、その制御は「将来のロググループにも自動的に適用」される必要がある。
■ 正解の選択肢と解説
正解：C. CloudWatch Logs アカウント全体のデータ保護ポリシーを作成し、logs:Unmask を付与しない
解説：
- CloudWatch Logs のデータ保護ポリシーは、ログ内の機密データ（例：個人情報など）を自動的にマスキング（伏せ字）する機能。
- 「アカウント全体ポリシー」を設定すれば、既存・将来作成されるすべてのロググループに自動的に適用される。
logs:Unmask権限を持たない IAM ユーザーは、マスクされたデータを復号して見ることができない。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A / B | Amazon Macie は S3 上のオブジェクトのスキャンには使えるが、閲覧制御やリアルタイムマスキングは不可。また、S3 にエクスポート後にアクセスを制御するのは煩雑で、CloudWatch Logs の要件に対して不適切。 |
| D | ロググループごとのデータ保護ポリシーは、個別に適用する必要があり、将来作成されるロググループには自動適用されない。手動で適用する手間が発生し、今回の要件に合致しない。 |
■ SCS試験で押さえておくべきポイント
- CloudWatch Logs のデータ保護機能は、PII（個人情報）や機密情報の漏洩リスクを軽減する重要機能。
- アカウントレベルのデータ保護ポリシーを利用することで、新たなロググループにも自動適用が可能。
logs:Unmask権限を付与していないユーザーには、マスクされたログの内容がそのまま伏せ字で表示される。- Macie は CloudWatch Logs には直接使えない。S3 専用のサービスであることを明確に区別する。
次の問題も引き続き送ってください。精度高く解説いたします。
以下に、問題7 を指定の形式で整理・解説します。
■ 問題文
ある企業は、Amazon EC2 インスタンスで公開ウェブサイトをホストしています。HTTPS トラフィックはウェブサイトにアクセスできる必要があります。同社はウェブサーバーの管理に SSH を使用しています。
ウェブサイトはサブネット 10.0.1.0/24 上にあります。管理サブネットは 192.168.100.0/24 です。セキュリティエンジニアは、EC2 インスタンスのセキュリティグループを作成する必要があります。
これらの要件を最も安全な方法で満たす最適な手順の組み合わせを選択してください。（2つ選択）
■ 選択肢
A. ソース 0.0.0.0/0 からのポート 443 を許可します。
B. 192.168.100.0/24 からのポート 22 を許可します。
C. ソース 0.0.0.0/0 からのポート 22 を許可します。
D. 10.0.1.0/24 からのポート 443 を許可します。
E. 10.0.1.0/24 からのポート 22 を許可します。
■ 問題文の要件の概要
- **HTTPS（ポート443）**でウェブサイトに誰でもアクセスできるようにする（＝全世界からのアクセスが必要）
- **SSH（ポート22）**は、管理サブネットからのみアクセスできるように制限したい
- セキュリティを重視し、最小限の許可にすることが重要
■ 正解の選択肢と解説
✅ A. ソース 0.0.0.0/0 からのポート 443 を許可
- 理由：
ウェブサイトが「公開サイト」であるため、インターネット全体から HTTPS (443番ポート) のアクセスを許可する必要があります。0.0.0.0/0は全世界を意味し、これによりすべてのユーザーが HTTPS 経由で接続可能になります。
✅ B. 192.168.100.0/24 からのポート 22 を許可
- 理由：
管理者は SSH (ポート22) を用いて EC2 にログイン・操作を行うため、管理用サブネットからのみ許可することがセキュアな構成となります。IP範囲で制限することで、不要な外部からの接続をブロックできます。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
C. 0.0.0.0/0 からのポート 22 を許可 | 全インターネットから SSH 接続が可能になり、セキュリティリスクが非常に高い（ブルートフォース攻撃など） |
D. 10.0.1.0/24 からのポート 443 を許可 | HTTPS アクセスをそのサブネット内からのみに限定してしまうため、公開ウェブサイトとして機能しない |
E. 10.0.1.0/24 からのポート 22 を許可 | サイトホストと同じサブネットに制限しても、管理用ネットワーク（192.168.100.0/24）からアクセスできない |
■ SCS試験で押さえておくべきポイント
- セキュリティグループはステートフルであり、最小権限の原則に従って設計する。
- 公開アクセスは必要最小限（例：ポート 80/443 のみを 0.0.0.0/0 に許可）
- SSH（ポート22）は極力 IP 制限（CIDR）する：内部管理サブネットのみに許可するのがベストプラクティス
- セキュリティグループは EC2 の重要なセキュリティ境界の1つ。設定ミスによる侵害リスクを常に意識する。
次の問題もどうぞ。引き続き、丁寧に解説します。
