10問中 0問が回答されています
質問:
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
無料レッスン・テストを受講するにはフリーコース(無料)に登録してください。
まず、次の操作を完了する必要があります:
正解数 0/問題数10
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【SCS-2001】ある企業は AWS Organizations で複数のアカウントを運用しており、従業員は AWS IAM Identity Center を通じて各アカウントの権限セットにアクセスしています。組織の証跡は AWS CloudTrail で有効化されています。ある従業員の資格情報が外部に流出した疑いがあり、セキュリティチームはその従業員によるすべてのアカウントへのアクセスを直ちに停止する必要があります。停止後、過去 30 日間に当該従業員のセッションが実行した API アクティビティを期間とユーザーで絞り込んで調査する必要があります。これらの要件を満たすソリューションを選択してください。
従業員のサインインそのものを止めたい場合、権限を与える側と、認証する側のどちらに手を入れるべきでしょうか。権限セットやグループ割り当てを操作すると、同じ権限セットやグループを使う他の従業員にどのような影響が及ぶか考えてみましょう。また、組織の証跡に対して期間とユーザーを組み合わせた柔軟な絞り込みを行うには、どの調査基盤が SQL で直接問い合わせできるかに注目してください。
【SCS-2002】ある企業は、複数の Amazon EC2 インスタンスで IAM インスタンスプロファイルを介してアプリケーションを実行しています。Amazon GuardDuty が特定のインスタンスについて UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration の検出結果を生成しました。調査により、インスタンスプロファイルの一時的認証情報が AWS 外部の IP アドレスから使用されていることが判明しました。セキュリティチームは、外部で既に取得された認証情報による API 呼び出しを直ちに停止する必要があります。この要件を満たす初動対応として最も適切な方法を選択してください。
一時的認証情報がすでに AWS の外部にコピーされている状況を思い浮かべてください。インスタンス側のネットワークを閉じたり、インスタンス自体を停止したりすることで、外部の攻撃者が手元に持っているトークンは使えなくなるでしょうか。トークンの有効期限が切れるまで API 呼び出しが通ってしまうとしたら、IAM 側で何を止めるべきか考えてみましょう。同じロールを使う正常なインスタンスへの影響も併せて検討してください。
【SCS-2003】ある企業のセキュリティチームは、Amazon EC2 インスタンスにアタッチされた IAM ロールの一時的な認証情報が、アプリケーションの脆弱性を通じて外部に流出したことを確認しました。AWS CloudTrail のログから、社外の IP アドレスからその認証情報を用いた API 呼び出しが継続していることが判明しています。当該ロールは複数の本番インスタンスで共有されており、業務を停止させずに、流出済みの認証情報による API 呼び出しを直ちに使用できない状態にする必要があります。これらの要件を満たす方法を選択してください。
EC2 のインスタンスプロファイル経由で発行された一時的な認証情報は、いったん外部にコピーされると有効期限まで使えてしまいます。この「すでに手元を離れた認証情報」を止めるには、何を対象に無効化する必要があるでしょうか。同時に、同じロールを共有する本番インスタンスは動き続けなければなりません。既存セッションだけを狙って拒否できる仕組みがあるかどうかに注目してみましょう。
【SCS-2004】ある企業のセキュリティエンジニアは、開発者に発行された IAM ユーザーのアクセスキーがパブリックのソースコードリポジトリに公開されていたことを検知しました。エンジニアは、そのアクセスキーによる以後の AWS API 呼び出しを直ちに停止させる必要があります。あわせて、キーが公開されていた期間にそのアクセスキーが実際に使用されていたかどうか、また使用されていた場合はどの API がいつ呼び出されたのかを特定し、影響範囲を報告することが求められています。これらの要件を満たす手順の組み合わせを選択してください。(2つ選択)
この問題は「以後の呼び出しを止める」対処と「過去に何が呼ばれたか」の特定という、2つのフェーズを同時に求めています。まず、アクセスキーそのものを無力化する最も直接的な操作は何でしょうか。次に、特定のアクセスキー ID による API 呼び出しを日時付きで追跡できるサービスはどれか考えてみましょう。脆弱性診断や外部共有検出のサービスと、API 監査ログのサービスの役割の違いに注目してください。
【SCS-2005】ある企業は、Amazon EC2 上で稼働する複数のバッチ処理アプリケーションを運用しています。これらのアプリケーションは、設定ファイルに埋め込まれた IAM ユーザーのアクセスキーを使用して外部の AWS アカウントの Amazon S3 バケットにアクセスしています。セキュリティチームは、このアクセスキーが公開されたコードリポジトリに含まれていたことを検知しました。バッチ処理は日中も継続的に実行されており、企業は処理を停止させずに当該アクセスキーを使えない状態にする必要があります。この要件を満たす手順の組み合わせを選択してください。
IAM ユーザーは同時にいくつのアクセスキーを保持できるでしょうか。この上限を思い出すと、切り替え中に新旧両方のキーを併存させられることが見えてきます。
バッチ処理は日中も継続実行されているという前提に注目してください。先に旧キーを止めてしまうと、設定ファイルの更新が完了するまでの間、アプリケーションはどうなるでしょうか。
無停止を実現する順序を考えてみましょう。
【SCS-2006】ある企業のセキュリティチームは、インシデント対応のプレイブックを整備しています。あるアプリケーションが数日前まで問題なく動作していたにもかかわらず、現在は Amazon S3 バケットへのアクセスが拒否されるようになりました。チームは、このアプリケーションが引き受ける IAM ロールにアタッチされたポリシーの設定内容が、障害発生の前後でどのように変化したかを時点ごとに比較して特定する必要があります。この要件を満たすソリューションを選択してください。
「誰がいつ変更したか」という操作の記録と、「ある時点で設定がどうなっていたか」という状態の記録は別物です。今回チームが必要としているのはどちらでしょうか。
障害発生前と後の 2 つの時点のポリシー内容を並べて差分を見るには、リソースの構成そのものをスナップショットとして蓄積しておく仕組みが必要です。
IAM ロールを記録対象に含められるサービスに注目してみましょう。ただし AWS Config は有効化した時点以降の構成変更のみを記録するため、この解決策は平時からIAMリソースタイプの記録を有効化しておくことが前提となります。障害発生後に初めて有効化した場合は、過去の構成には遡れません。
【SCS-2007】ある企業は複数の本番ワークロードを単一の AWS アカウントで運用しています。現在、EC2 インスタンスからの不審な外部通信やマルウェア配信ドメインへのアクセス、侵害された IAM 認証情報による API 呼び出しを検出する仕組みがありません。セキュリティチームは、追加のエージェントをインスタンスに導入せずに脅威を継続的に検出し、重要度が高い検出結果が発生した時点でセキュリティチームの共有メールアドレスへ自動的に通知が届くようにしたいと考えています。これらの要件を満たす手順の組み合わせを選択してください。(3つ選択)
まず「エージェントを入れずに」不審な通信や認証情報悪用を検出できるサービスは何かを考えてみましょう。次に、そのサービスが検出結果をどこへ発行し、それを受け取って重要度で絞り込む仕組みが何かを追ってみてください。最後に、絞り込んだイベントを共有メールアドレスへ届けられるのはどのサービスでしょうか。3 つのリソースが前から後ろへどう繋がるか、その依存関係に注目してください。
【SCS-2008】ある企業は複数の AWS アカウントで Amazon GuardDuty を有効化しています。セキュリティチームは、GuardDuty が特定の検出結果タイプを報告した際に、侵害された Amazon EC2 インスタンスを隔離用セキュリティグループに付け替える AWS Lambda 関数を実行したいと考えています。この Lambda 関数はすでに作成済みで、手動実行では正常に動作することが確認されています。セキュリティチームは、検出結果の発生から Lambda 関数の実行までを人手を介さずに連携させる必要があります。これらの要件を満たす方法を選択してください。
GuardDuty のコンソールを思い出してみてください。検出結果を直接 Lambda や SNS へ送る設定項目は存在するでしょうか。GuardDuty が検出結果をどこへ「イベント」として発行しているかに注目すると、連携のハブとなるサービスが見えてきます。
また「人手を介さず」という条件も重要です。コンソールから操作を選択して実行する仕組みは、この条件を満たせるでしょうか。
【SCS-2009】ある企業は複数の AWS アカウントで Amazon GuardDuty、Amazon Macie、Amazon Inspector を有効化しています。各アカウントの調査結果は AWS Security Hub の管理アカウントに集約されており、ASFF 形式で参照できます。セキュリティチームは、重要度が CRITICAL または HIGH の調査結果が集約された時点で、担当者のメールアドレスに通知を届けたいと考えています。追加のサーバーやポーリング処理を導入せずに実現する必要があります。これらの要件を満たすソリューションを選択してください。
Security Hub に集約された調査結果は、他のサービスへ自動的に送信される仕組みを持っていないでしょうか。その送信先で重要度ラベルを条件にフィルタリングできれば、ポーリング処理は不要になります。
また「集約された時点で」という要件に注目してください。担当者が画面上で操作して初めて動く仕組みや、ファイル配信を経由する仕組みでは、この即時性と自動性を満たせるか考えてみましょう。
【SCS-2010】ある企業は複数の AWS アカウントで Amazon GuardDuty を有効化しています。セキュリティチームは、重要度が高い検出結果をセキュリティ担当者へメールで即時に通知したいと考えています。同時に、すべての検出結果を長期的に蓄積し、ダッシュボードで傾向を分析できるようにする必要があります。セキュリティチームは、既存のアプリケーションコードを変更せずにこの仕組みを構築することを求めています。これらの要件を満たすソリューションを選択してください。
GuardDuty の検出結果はどのサービスへ自動的に送信されるでしょうか。その配信先でイベントパターンによる重要度の絞り込みができれば、判定用のコードを自分で書く必要はなくなります。
また、1 つのルールに複数のターゲットを指定できる点に注目してください。メール通知の経路と、分析基盤への蓄積経路を同時に成立させる構成はどれか考えてみましょう。
⚠️ こちらは教材の操作/UIなど全般に対するリクエストフォームではございません。
個別の問題についての改善リクエストです。
教材全般についての改善リクエストはお問い合わせフォームよりご連絡ください。
CloudTech(クラウドテック)は多くのユーザーの皆様から改善リクエストをご協力いただき運営できております。
あなたの視点での気づきは他の学習者の迷いを解決する手助けとなります。
運営側でもチェックをしておりますが限界があるため、誠に恐縮ではございますが細かい点でもご遠慮なくご指摘をお願いいたします。
※ 匿名での報告となり、内容は一般公開されません。
※ 技術的なご質問への回答を行うフォームではございませんのでご注意ください。
