Q1.ある企業で Azure サブスクリプションを運用しています。
Microsoft Graph のアクティビティログを、社外のサードパーティ製セキュリティ情報イベント管理（SIEM）製品へ継続的にストリーミングする必要があります。
運用の手間はできるだけ小さく抑える方針です。
ログの送信先として最適なのはどれですか。
解答を見る
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 つのアクションはどれですか。
左の「選択肢」から必要な数を右の「回答エリア」へドラッグ（またはタップ）。回答エリア内でドラッグして順序を入れ替えられます。
- Syslog コネクタをワークスペースに追加する
- Microsoft Sentinel をワークスペースに追加する
- Linux 仮想マシンに Log Analytics エージェントをインストールする
- Security Events コネクタをワークスペースに追加する
- Microsoft Sentinel ワークブックを追加する
- ここへドラッグ
解答を見る
Linux 仮想マシンからログを収集するには、まずMicrosoft Sentinel をワークスペースに追加し、監視基盤を有効化します。
次に、Linux で標準的なログ収集方式であるSyslog コネクタを追加し、ログの取り込みを定義します。
最後に各仮想マシンへLog Analytics エージェントをインストールすることで、実際にログがワークスペースへ送信されます。
この順序であれば依存関係を満たしつつ効率的に構成できます。
Microsoft Sentinel データ コネクタ
Q4.次の表に示すユーザーが登録された Azure サブスクリプションがあります。(画像1)
このサブスクリプションには、次の表のとおり Azure Firewall のインスタンスが構成されています。(画像2)
さらに、Microsoft Copilot for Security を利用できる Microsoft 365 E5 サブスクリプションを保有しており、次の表の Copilot for Security ロールが各ユーザーに割り当てられています。(画像3)
各ユーザーはそれぞれ Copilot for Security セッションを実行します。
以下の各記述について、正しい場合は「はい」を、正しくない場合は「いいえ」を選択してください。
| ユーザー | ロール | スコープ |
|---|---|---|
| User1 | Contributor | サブスクリプション |
| User2 | Contributor | サブスクリプション |
| User3 | Security Reader | リソース グループ |
| 名前 | ログ構成 | 送信先 |
|---|---|---|
| AFW1 | 非構造化ログ | Log Analytics |
| AFW2 | 構造化侵入検知防止システム(IDPS)ログ | Azure Event Hubs |
| AFW3 | 構造化侵入検知防止システム(IDPS)ログ | Log Analytics |
| ユーザー | Copilot ロール |
|---|---|
| User1 | Copilot Owner |
| User2 | Copilot Contributor |
| User3 | Copilot Owner |
| 問題文 | はい | いいえ | |
|---|---|---|---|
| User1 は AFW1 の情報を取得できる | |||
| User2 は AFW2 の情報を取得できる | |||
| User3 は AFW3 の情報を取得できる |
解答を見る
Copilot for Security ではLog Analytics に保存されたログのみ直接参照できます。
Event Hubs へ送信されたログは対象外となります。
参照には Azure RBAC と Copilot ロールの両方が必要です。
User1 は Contributor と Copilot Owner を持ち、AFW1 が Log Analytics のため取得できます。
User2 は AFW2 が Event Hubs のためCopilot から参照できず取得できません。
User3 は Security Reader でも Log Analytics の参照は可能で、AFW3 の情報を取得できます。
ログの保存先と権限の組み合わせが重要な判断ポイントです。
Microsoft Sentinel データ コネクタ
Q5.Sub1 という名前の Azure サブスクリプションを運用しています。
Sub1 には SW1 という名前の Microsoft Sentinel ワークスペースと、Windows Server が稼働する VM1 という名前の仮想マシンが含まれます。
SW1 は、AMA コネクタ経由の Windows セキュリティ イベントを用いて、VM1 からセキュリティ ログを収集しています。
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 メンバー サーバーおよびドメイン コントローラーからセキュリティ ログを収集するように Azure Sentinel を構成します。
Microsoft Defender for Identity はスタンドアロン センサーを使用して展開します。
Active Directory 上で機密グループが変更されたタイミングを確実に検知できるようにする必要があります。
実行すべきアクションを 2 つ選んでください。
各選択肢はいずれも解決策の一部を表します。
解答を見る
機密グループの変更を検出するには、まずドメイン コントローラーで詳細監査ポリシーを有効化し、アカウント管理イベントを記録する必要があります。
これによりグループ変更の監査ログが生成されます。
さらに、そのログを Sentinel や Defender for Identity へ集約するためにWindows イベント転送を構成し、中央で収集できるようにします。
OU の権限変更や Microsoft 365 の監査設定は、Active Directory のセキュリティ イベント収集には直接関係しません。
したがってこの 2 つが変更検出の必須要件となります。
Microsoft Sentinel データ コネクタを見つける
Q8.次の Advanced Security Information Model (ASIM) パーサーを含む Microsoft Sentinel ワークスペースがあります。
◆ _Im_ProcessCreate（プロセス作成）
◆ 作成中のパーサー
ここで vimProcessCreate という名前の新しいソース固有パーサーを作成します。
次の要件を満たすようにパーサーを変更する必要があります。
◆ すべての ProcessCreate パーサーを呼び出す。
◆ フィールドをプロセス スキーマへ標準化する。
各要件を満たすために変更すべきパーサーはどれですか。
選択肢を要件のドロップ欄へドラッグ、またはタップして配置。配置済みの欄をクリックで戻せます（同じ選択肢は複数回使用可）。
imProcessCreate
vimProcessCreate
解答を見る
ASIM では統合パーサーとソース固有パーサーを組み合わせて使用します。
すべての ProcessCreate パーサーを呼び出すには_Im_ProcessCreateを使用します。
これは複数のデータソースを横断し、標準化された結果を返す統合パーサーです。
一方、フィールドをプロセス スキーマへ標準化するにはimProcessCreateを使用します。
これは個別ソースのデータを ASIM スキーマへ正規化します。
この組み合わせにより統合取得とスキーマ標準化を両立できます。
正規化と高度なセキュリティ情報モデル (ASIM)
Q9.RG1 という名前のリソース グループを含む Azure サブスクリプションがあります。
RG1 には Microsoft Sentinel ワークスペースが配置されています。
このサブスクリプションは、User1 という名前のユーザーを含む Microsoft Entra テナントに関連付けられています。
User1 が Microsoft Sentinel のブック テンプレートを展開し、カスタマイズできることを確認する必要があります。
この構成は最小権限の原則に従う必要があります。
RG1 に対して User1 へ割り当てるべきロールはどれですか。
解答を見る
Microsoft Sentinel のブック（Workbook）は Azure Monitor の機能であり、テンプレートの展開や編集にはワークブックの投稿者（Workbook Contributor）ロールが必要です。
このロールはブックの作成・編集権限のみを付与し、他のリソースには影響しないため最小権限の原則を満たします。
Microsoft Sentinel 寄稿者や貢献者は過剰な権限を含み、オートメーション コントリビューターはプレイブック用途であり不適切です。
したがってワークブック専用ロールの付与が正解です。
Azure Workbooks の概要 – Azure Monitor
Q10.ユーザーおよびエンティティの行動分析 (UEBA) を有効化した Microsoft Sentinel ワークスペースがあります。
Server1 という名前のサーバー上で実行された、セキュリティ上重要なユーザー アクションに関するすべてのログ エントリを抽出する必要があります。
この構成は次の要件を満たす必要があります。
◆ IT 部門に所属していないユーザーによる、セキュリティに関わるアクションのみを対象とする。
◆ 誤検知の件数を最小限に抑える。
クエリをどのように完成させればよいですか。
解答を見る
UEBA を活用するにはユーザー属性情報を結合する必要があるためIdentityInfo テーブルを使用します。
これにより部署などの属性でフィルタリングできます。
また誤検知を減らすには、共通するユーザーのみを厳密に結合するinner joinを使用します。
leftouter では不要なデータが含まれる可能性があります。
したがって SecurityEvent と IdentityInfo を inner join で結合し、IT 部門以外に絞ることで精度の高い検出が実現できます。
Microsoft Sentinel ユーザーとエンティティの動作分析 (UEBA) リファレンス