DISPLAY SETTINGS 各種設定
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 サブスクリプションがあります。
このサブスクリプションには、次の表のとおり Azure Firewall のインスタンスが構成されています。
さらに、Microsoft Copilot for Security を利用できる Microsoft 365 E5 サブスクリプションを保有しており、次の表の Copilot for Security ロールが各ユーザーに割り当てられています。
各ユーザーはそれぞれ 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 は Copilot for Security のプロンプトを使って AFW1 の情報を取得できる | |||
| User2 は Copilot for Security のプロンプトを使って AFW2 の情報を取得できる | |||
| User3 は Copilot for Security のプロンプトを使って 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 から取得するイベントの範囲を絞り込み、監査失敗イベントのみが収集されるようにする必要があります。
コネクタのフィルター式はどのように完成させるべきですか。
Security!*[ ① ②='0x8010000000000000']]
解答を見る
Windows セキュリティ イベントの XPath フィルターは EventLog の XML スキーマに沿って記述します。
監査の成功・失敗はSystem セクションの Keywords 属性で区別され、監査失敗は 0x8010000000000000 のビットで表されます。
したがって ① には System[、② には Keywords を指定し、Security!*[System[Keywords='0x8010000000000000']] という式を完成させます。
EventData はイベント固有の詳細値を格納する領域であり、監査種別の判定には使えません。
この指定により監査失敗イベントだけを収集でき、取り込み量とコストを抑えられます。
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
◆ imProcessCreate
ここで vimProcessCreate という名前の新しいソース固有パーサーを作成します。
次の要件を満たすようにパーサーを変更する必要があります。
◆ すべての ProcessCreate パーサーを呼び出す。
◆ フィールドをプロセス スキーマへ標準化する。
各要件を満たすために変更すべきパーサーはどれですか。
選択肢を要件のドロップ欄へドラッグ、またはタップして配置。配置済みの欄をクリックで戻せます（同じ選択肢は複数回使用可）。
imProcessCreate
vimProcessCreate
解答を見る
ASIM は統合（unifying）パーサーとソース固有（source-specific）パーサーの二層構成になっています。
すべての ProcessCreate パーサーをまとめて呼び出す役割を担うのは統合パーサーであるため、_Im_ProcessCreate を変更して新しいパーサーを呼び出し対象に加えます。
一方、生データのフィールドを Process スキーマの標準フィールド名へ対応付けるのはソース固有パーサーの役割です。
そのため、今回作成したvimProcessCreate を変更してフィールドを標準化します。
vim から始まる名前はワークスペースに配置したソース固有パーサーを表す命名規則であり、役割と命名の対応を押さえることが得点の鍵です。
正規化と高度なセキュリティ情報モデル (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 部門に所属していないユーザーによる、セキュリティに関わるアクションのみを対象とする。
◆ 誤検知の件数を最小限に抑える。
クエリをどのように完成させればよいですか。
SecurityEvent
| where EventID in ("4624","4672")
| where Computer == "SERVER1"
①（結合方法） (
②（結合するテーブル）
| summarize arg_max(TimeGenerated, *) by AccountObjectId) on $left.SubjectUserSid == $right.AccountSID
| where Department !~ "IT"
解答を見る
UEBA を有効にすると、部署や役職などのユーザー属性がIdentityInfo テーブルに蓄積されます。
SecurityEvent にこの属性を結合すれば、Department が IT 以外のユーザーだけに絞り込めます。
誤検知を抑えるには、両側に一致があるレコードだけを返すinner 結合を使います。
fullouter は一致しない行も返すため対象外のユーザーが混入し、BehaviorAnalytics には部署情報が含まれないため条件を満たせません。
したがって SecurityEvent と IdentityInfo を inner で結合する構成が最も精度の高い抽出になります。
Microsoft Sentinel ユーザーとエンティティの動作分析 (UEBA) リファレンス