Microsoft SC-200 (Security Operations Analyst)1-10

Q1.Azure サブスクリプションをお持ちです。
Microsoft Graph のアクティビティログをサードパーティのセキュリティ情報およびイベント管理（SIEM）ツールにストリーミングする必要があります。
ソリューションでは、管理作業を最小限にする必要があります。
ログをどこにストリーミングすればよいですか。

A. Azure Event Hubs 名前空間
B. Azure Event Grid 名前空間
C. Azure ストレージアカウント
D. Log Analytics ワークスペース

回答

A. Azure Event Hubs 名前空間: Microsoft Graph のアクティビティログを外部SIEMへ送信する場合、リアルタイムかつスケーラブルなデータ取り込みが必要です。
この要件に最適なのがAzure Event Hubsです。
Event Hubsは大量のログデータをストリーミング処理でき、SIEM製品との連携も容易であり管理作業を最小限に抑えることができます。
一方、Event Gridはイベント通知用途、ストレージはアーカイブ向け、Log Analyticsは分析用途であり、外部SIEM連携の直接的なストリーミングには最適ではありません。
したがってSIEM連携にはEvent Hubsが最適です。
Azure Monitorの診断設定 – Azure Monitor

Q2.Azure Sentinel をデプロイします。
Azure で Microsoft Teams と Linux 仮想マシンを監視するには、Azure Sentinel にコネクタを実装する必要があります。
ソリューションでは、管理労力を最小限に抑える必要があります。
各ワークロードにはどのデータコネクタタイプを使用する必要がありますか。

回答

(下記画像参照): Microsoft Teams は Microsoft 365 サービスの一部であり、ログ収集にはOffice 365 コネクタを使用するのが最も効率的です。
これにより監査ログを統合的に取得できます。
一方、Linux 仮想マシンの監視では、OSレベルのログ収集が必要となるためSyslog コネクタを利用します。
Syslog は Linux 環境で標準的なログ収集方式であり、エージェント経由で容易に Sentinel に取り込めます。
これらの組み合わせにより追加構成を最小化しつつ効率的な監視が可能となります。
Microsoft Sentinel データコネクタ

Q3.100 台の Linux 仮想マシンを含む Azure サブスクリプションがあります。
仮想マシンからイベントログを収集するには、Microsoft Sentinel を構成する必要があります。
どの 3 つのアクションを順番に実行する必要がありますか。

回答

(下記画像参照): Linux 仮想マシンからログを収集するには、まずMicrosoft Sentinel をワークスペースに追加し、監視基盤を有効化します。
次に、Linux 環境では標準的なログ収集方式であるSyslog コネクタを追加してログ取り込みを定義します。
最後に各仮想マシンへLog Analytics エージェントをインストールすることで、実際にログがワークスペースへ送信されます。
この順序により、依存関係を満たしつつ効率的に構成できます。
Microsoft Sentinel データコネクタ

Q4.次の表に示すユーザーを含む Azure サブスクリプションがあります。
また、Azure Firewall のログ構成と Microsoft Copilot for Security のロール割り当ても示されています。
各ユーザーが Copilot for Security セッションで対象の Azure Firewall から情報を取得できるかを判断してください。

回答

(下記画像参照): Copilot for Security ではLog Analytics に保存されたログのみ直接参照可能であり、Event Hubs に送信されたログは対象外です。
また、アクセスには Azure RBAC と Copilot ロールの両方が必要です。
User1 は Contributor と Copilot Owner を持ち AFW1(Log Analytics)へアクセス可能なため取得できます。
User2 は AFW2 が Event Hubs のためCopilot から参照できず取得不可です。
User3 は Reader 権限でも Log Analytics 参照は可能でありAFW3 の情報は取得可能です。
ログ保存先と権限の組み合わせが重要な試験ポイントです。
Microsoft Sentinel データコネクタ

Q5.Sub1 という名前の Azure サブスクリプションがあります。
Sub1 には、SW1 という名前の Microsoft Sentinel ワークスペースと、Windows Server を実行する VM1 という名前の仮想マシンが含まれています。
SW1 は AMA エージェント経由の Windows セキュリティイベントを使用して、VM1 からセキュリティログを収集します。
監査失敗イベントのみが収集されるように、コネクタのフィルター式を完成させてください。

回答

(下記画像参照): Windows セキュリティイベントでは、監査成功・失敗は Keywords フィールドで識別されます。
監査失敗のみを取得するにはSystem セクション内のKeywordsを使用してフィルタリングする必要があります。
EventData はイベントの詳細情報であり監査種別の判定には適しません。
したがってフィルター式は System/Keywords を指定するのが正解です。
これにより失敗イベントのみ効率的に収集でき、不要なログを削減できます。
Microsoft Sentinel データコネクタを見つける

Q6.50 台の仮想マシンを含む Azure サブスクリプションがあります。
Microsoft Defender for Cloud を導入予定です。
40 台の仮想マシンに対してエージェントレススキャンを有効にする必要があります。
また、ディスクスナップショットを作成し、帯域外分析を実行する必要があります。
どのように構成すればよいですか。

回答

(下記画像参照): エージェントレススキャンとディスクスナップショット分析はDefender CSPM プランで提供される機能です。
そのためまず Defender プランとして CSPM を選択する必要があります。
また、特定の仮想マシンのみ対象とする場合は、ポリシーで対象範囲を制御する必要があり、最も簡単なのはタグ付けによる除外設定です。
RBAC はアクセス制御でありスキャン対象の制御には適しません。
したがって CSPM とタグを組み合わせることで必要な VM のみ効率的にスキャンできます。
Virtual Machines のエージェントレススキャンを有効にする – Microsoft Defender for Cloud | Microsoft Learn

Q7.次の環境があります。
Azure Sentinel、Microsoft 365 サブスクリプション、Microsoft Defender for Identity、Azure Active Directory テナント。
すべての Active Directory メンバーサーバーとドメインコントローラーからセキュリティログを収集するように Microsoft Sentinel を構成します。
Defender for Identity センサーを展開し、Active Directory で機密グループがいつ変更されたかを確実に検出する必要があります。
どの 2 つのアクションを実行する必要がありますか。

A. ドメインコントローラーの詳細監査ポリシー構成設定を構成します
B. ドメインコントローラー組織単位 (OU) のアクセス許可を変更します
C. Microsoft 365 コンプライアンスセンターで監査を構成します
D. ドメインコントローラーで Windows イベント転送を構成します

回答

A. ドメインコントローラーの詳細監査ポリシー構成設定を構成します D. ドメインコントローラーで Windows イベント転送を構成します: 機密グループの変更検出には、まずドメインコントローラーで詳細監査ポリシーを有効化し、アカウント管理イベントを記録する必要があります。
これによりグループ変更の監査ログが生成されます。
さらに、それらのログを Sentinel や Defender for Identity に連携するためにWindows イベント転送を構成し、中央で収集できるようにします。
OU の権限変更や Microsoft 365 の監査設定は Active Directory のセキュリティイベント収集には直接関係ありません。
したがってこの 2 つの構成が変更検出の必須要件となります。
Microsoft Sentinel データコネクタを見つける

Q8.ASIM パーサーを含む Microsoft Sentinel ワークスペースがあります。
新しいソース固有パーサー vimProcessCreate を作成し、すべての ProcessCreate パーサーを呼び出し、フィールドをプロセススキーマに標準化する必要があります。
どのパーサーを使用する必要がありますか。

回答

(下記画像参照): ASIM では、統合パーサーとソース固有パーサーを組み合わせて使用します。
すべての ProcessCreate パーサーを呼び出すには_Im_ProcessCreateを使用します。
これは複数のデータソースを横断して標準化された結果を返す統合パーサーです。
一方、フィールドをプロセススキーマへ標準化するにはimProcessCreateを使用します。
これは個別ソースからのデータを ASIM スキーマに正規化します。
したがってこの組み合わせにより統合取得とスキーマ標準化を両立できます。
正規化と高度なセキュリティ情報モデル (ASIM)

Q9.RG1 という名前のリソースグループを含む Azure サブスクリプションがあります。
RG1 には Microsoft Sentinel ワークスペースが含まれています。
User1 は Microsoft Entra テナントにリンクされています。
User1 が Microsoft Sentinel ブックテンプレートを展開およびカスタマイズできることを確認する必要があります。
最小特権の原則に従う必要があります。
どのロールを割り当てるべきですか。

A. ワークブックの投稿者
B. Microsoft Sentinel 寄稿者
C. 貢献者
D. Microsoft Sentinel オートメーションコントリビューター

回答

A. ワークブックの投稿者: Microsoft Sentinel のブック（Workbook）は Azure Monitor の機能であり、テンプレートの展開や編集にはWorkbook Contributor ロールが必要です。
このロールはブックの作成・編集権限のみを付与し、他のリソースには影響しないため最小特権の原則を満たす最適な選択です。
Sentinel Contributor や Contributor は過剰な権限を含み、Automation Contributor はプレイブック用途であり不適切です。
したがってワークブック専用ロールの付与が正解となります。
Azure Workbooks の概要 – Azure Monitor

Q10.UEBA が有効な Microsoft Sentinel ワークスペースがあります。
Server1 で実行されたセキュリティが重要なユーザーアクションに関連するすべてのログエントリを特定する必要があります。
IT 部門以外のユーザーのみに限定し、誤検知を最小限に抑える必要があります。
どのようにクエリを構成すべきですか。

回答

(下記画像参照): UEBA を活用するにはユーザー属性情報を結合する必要があるためIdentityInfo テーブルを使用します。
これにより部署などの属性でフィルタリングできます。
また誤検知を減らすには、共通するユーザーのみを厳密に結合するinner joinを使用します。
leftouter では不要データが含まれる可能性があります。
したがって SecurityEvent と IdentityInfo を inner join で結合し、IT 部門以外に絞ることで精度の高い検出が実現できます。
Microsoft Sentinel ユーザーとエンティティの動作分析 (UEBA) リファレンス

Q3.100 台の Linux 仮想マシンを含む Azure サブスクリプションがあります。仮想マシンからイベント ログを収集するには、Microsoft Sentinel を構成する必要があります。どの 3 つのアクションを順番に実行する必要がありますか。