Defender for Cloud Secure Scoreの(DC only)とは？推奨事項が非DC VMに出る理由とExempt除外手順

Microsoft Defender for Cloud の Secure Score で推奨事項を見ていると、タイトル末尾に「(DC only)」が付いていて戸惑うことがあります。結論から言うと、これは“ドメイン コントローラー専用”の意味です。本記事では「DC only」の正しい解釈、DC ではない VM に表示されるときの切り分け、そして Exempt（除外）で実務的に整理する方法までをまとめます。

Secure Score 推奨事項の「(DC only)」の意味

Defender for Cloud の Secure Score 推奨事項に付く「(DC only)」は、Domain Controller（ドメイン コントローラー）だけを対象とした推奨事項であることを示します。つまり、同じ Windows Server / VM であっても、役割が DC でなければ本来は“その推奨事項で評価されるべき対象”ではありません。

表記	対象	対象外（原則）	実務上の読み替え
(DC only)	Active Directory のドメイン コントローラーとして動作しているサーバー/VM	メンバーサーバー、単体サーバー、AD DS 役割を持たない VM	「DC だけが対応すべき設定。非DCに出てもまずは切り分け」
表記なし	推奨事項の種類に応じた一般的な対象（VM/SQL/Storage など）	推奨事項のスコープ外のリソース	「原則として表示対象＝対応候補」

なぜ「Audit Distribution Group Management」は DC 専用なのか

例に挙がっている “Ensure ‘Audit Distribution Group Management’ is set to include ‘Success’ (DC only)” は、Windows の「高度な監査ポリシー（Advanced Audit Policy）」にある Audit Distribution Group Management（配布グループ管理の監査） を “成功（Success）” で記録する設定を求めています。

このサブカテゴリはポイントが重要で、Microsoft の説明でも「イベントはドメイン コントローラーでのみ生成される」ことが明記されています。つまり、メンバーサーバー側で同設定をONにしても、そのサブカテゴリ自体が意味を持たず、ログも出ません。だからこそ Secure Score 側でも “(DC only)” と明示されています。

また、配布グループは「アクセス制御の権限付与に使うグループ」ではなく、あくまで配布（例：メール配布）用途の側面が強いので、監査の重要度が環境依存になりやすいのも特徴です（ただし、役員向け配布グループ等を運用している場合は、変更監査が有効になる場面があります）。

この監査で代表的に記録されるイベント例

Audit Distribution Group Management を有効にすると、配布グループ（Security disabled / Distribution group）の作成・変更・削除や、メンバー追加・削除などのイベントが DC のセキュリティログに記録されます。代表例は次の通りです。

操作の例	代表イベント ID（例）	ログが出る場所	補足
配布グループの作成/変更/削除	4744/4745/4748、4749/4750/4753、4759/4760/4763 など	ドメイン コントローラーのみ	ローカル/グローバル/ユニバーサル等でイベントが分かれます
配布グループへのメンバー追加/削除	4746/4747、4751/4752、4761/4762 など	ドメイン コントローラーのみ	監査サブカテゴリが DC 専用のため

DC ではない VM にも「(DC only)」推奨事項が出る主な原因

“DC only なのに、なぜか自分の VM に出ている” という状況は珍しくありません。実務で多いのは次のパターンです（複数が同時に起きることもあります）。

• 過去に DC だった（降格/demote した）：DC を降格すると役割は外れますが、Defender for Cloud 側の判定や関連メタデータがすぐに追従しないケースがあります。
• 評価のタイムラグ（伝播遅延）：推奨事項や除外（Exemption）は反映まで時間がかかることがあり、即時に表示が切り替わりません（後述）。
• 構成の痕跡が残っている：DC 運用時の設定・サービス・レジストリ等の残存で、誤判定の引き金になることがあります。
• “DC として使っていないつもり”だが AD DS 役割が残っている：機能/役割が入ったまま、または一部コンポーネントが残っていると、運用意図と実態がズレます。
• イメージ複製やテンプレート起因：DC を元にしたイメージから VM を作ったなど、環境整合性が崩れているケース。

ポイント：「(DC only)」推奨事項が出たからといって、即 “非DCでも設定しなければ” にはなりません。まずは DC 判定のズレなのか／本当に DC なのか を機械的に潰すのが最短ルートです。

まずは「本当に DC ではない」を短時間で確認するチェックリスト

切り分けでは、OS 内の状態（役割）とAD 側の状態（コンピュータアカウントの扱い）を分けて見ると迷いにくくなります。

確認項目	確認方法（例）	DC の場合に起きやすい結果	非DC の場合の目安
AD DS 役割の有無	サーバーマネージャー / PowerShell: Get-WindowsFeature AD-Domain-Services	Installed=True	Installed=False（またはそもそも機能なし）
NTDS サービス	PowerShell: Get-Service NTDS	サービスが存在し、稼働していることが多い	サービスが存在しない（見つからない）
ドメイン ロール（OS判定）	PowerShell: (Get-CimInstance Win32_ComputerSystem).DomainRole	4/5（ドメインコントローラー系）	0～3（ワークステーション/メンバーサーバー系）
AD 上の配置（OU）	ADUC でコンピュータアカウントの OU を確認	Domain Controllers OU 配下にいる	Domain Controllers OU 以外
監査ログの発生位置	「配布グループ変更」操作のログがどこに出るか	DC の Security ログに出る	その VM には出ない（DC に出る）

配布グループ管理の監査ログが DC でしか出ないこと自体が、最も強い根拠になります。Microsoft の監査ポリシー解説でも “ドメイン コントローラーでのみイベント生成” とされているため、非DC VM に推奨が出ている場合は「判定や表示の問題」を疑うのが自然です。

もし VM が DC だった場合にやるべきこと

VM が DC と判明した場合は、推奨事項の通り「Audit Distribution Group Management を Success で有効化」します。Microsoft の説明では、このサブカテゴリのイベント量は “DC で低い” とされ、運用上も比較的扱いやすい部類です。

設定の基本方針

• 推奨：ローカル設定ではなく、GPO（Group Policy）で DC に適用（Domain Controllers OU にリンク）
• 理由：DC は複数台構成が一般的で、監査ポリシーは統一が重要
• 合わせ技：ログの保存期間・転送（SIEM / Sentinel など）も同時に設計

手順イメージ（GPO）

1. Group Policy Management を開き、Domain Controllers に適用する GPO を用意する
2. Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Management を開く
3. Audit Distribution Group Management を開き、Success を有効化する
4. 適用後、DC のイベントビューアー（Security）で実際にイベントが記録されることを確認する

監査ポリシーの内容はコマンドでも確認できます。監査全体の状態確認には auditpol.exe が使えます。

auditpol.exe /get /category:*
auditpol.exe /get /subcategory:"Distribution Group Management"

DC ではない VM の場合にやるべきこと

VM が DC ではないと判断できたなら、基本は次のどちらかです。

• 自然解消を待つ：評価更新のタイムラグで、時間経過で消えるケースがあります。
• Exempt（除外/免除）で整理する：明確に “適用対象外” と言えるなら、Secure Score と運用ノイズを減らすために除外を使うのが現実的です。

Defender for Cloud で推奨事項を Exempt（除外）する手順

Defender for Cloud には、推奨事項が自社にとって適用不可・あるいは別手段で軽減済みの場合に、推奨事項や特定リソースを Exempt（除外）できる仕組みがあります。除外後は、該当の推奨事項/リソースが Secure Score に影響しなくなります。

ポータルで個別に除外する（まずはここから）

1. Azure ポータルで Microsoft Defender for Cloud を開く
2. Recommendations（推奨事項）を開き、該当の推奨事項を選択する
3. 詳細画面の Take action から Exempt を選ぶ
4. Exempt 画面で次を設定する
   • Scope（管理グループ/サブスクリプション/Selected resources など）
   • Exemption rule name（ルール名）
   • 必要に応じて有効期限（expiration）
   • Category（Mitigated / Risk accepted など）
   • Description（なぜ除外するのか。監査証跡として重要）
5. Create を押して作成

除外が反映されるまで、最大で 24 時間程度かかる場合があります。反映後は、推奨事項（または対象リソース）が Secure Score に影響しなくなり、対象リソースは推奨事項詳細の “Not applicable” 側に整理されます。

Exempt のカテゴリ（Mitigated / Risk accepted）の選び方

Exempt には “どんな理由で除外するか” を示すカテゴリがあります。運用監査や後日の説明責任まで考えると、ここは適当に選ばないほうが安全です。

カテゴリ	使うとよい状況	説明文に書くと強い根拠	注意点
Resolved through 3rd party（Mitigated）	Defender for Cloud が検知できない別製品/別統制でカバーしている	例：EDR/SIEM/GPO 統制、監査ルール、運用手順書のURL（社内）など	Mitigated で除外した場合のスコアの扱いには注意（仕様を理解して運用）
Risk accepted（Waiver）	リスクを認識した上で、今は対策しないと意思決定した	例：期限、代替策、例外承認者、再評価日	放置に見えないよう、期限と再評価の設計が重要

なお、除外のカテゴリ選択によって Secure Score の見え方が変わることがあります。たとえば Mitigated として除外すると、ポイントの扱いが通常の「対応済み」とは異なる説明があり、結果としてスコアが上がるケースがある旨が案内されています。スコアだけを目的化せず、“なぜ除外するのか” を説明できる状態を優先してください。

複数の VM をまとめて除外したい場合（Exemptions をスケールで作る）

同種の VM が多数あり、個別に推奨事項から除外するのが現実的でない場合は、Defender for Cloud の Environment settings > Exemptions から “まとめて作る” 運用ができます。

1. Azure ポータルで Microsoft Defender for Cloud を開く
2. Environment settings > Exemptions に移動
3. + Create を選ぶ
4. Exemption 名、（任意で）説明、対象クラウド、スコープ（管理グループ/サブスクリプション/リソース）を選択
5. カテゴリ（Mitigated / Waiver）、（任意で）有効期限を設定
6. 除外したい推奨事項（またはカテゴリ）を選択して作成

「DC only が非DCに出る」というケースは、同じ基盤の VM 群で一斉に発生することがあるため、スケール除外のほうが運用が安定する場面もあります（ただし、最初に 1 台で原因切り分けをしてから適用するのが安全です）。

除外したあとに“ちゃんと反映されたか”を確認する方法

除外ルールを作ったら、反映確認までがセットです。Microsoft Learn では、ポータル上で Exempted を絞り込む方法、Inventory での確認、Azure Resource Graph（ARG）での確認例が案内されています。

Recommendations で Exempted を絞り込む

1. Defender for Cloud > Recommendations を開く
2. Recommendation status のフィルターで Exempted を選び、適用する
3. 対象リソースを開き、除外ルールが意図通りか確認する

Inventory で除外が付いたリソースを探す

1. Defender for Cloud > Inventory を開く
2. Add filter から Contains exemptions を選び、Yes で絞り込む

Exempt（除外）を使う前に知っておきたい注意点

除外は便利ですが、やみくもに使うと “セキュリティ運用の見通し” が悪くなります。押さえておきたい注意点をまとめます。

• 機能がプレビュー扱いの場合がある：利用条件や表示が将来変わる可能性があります。
• 権限が必要：除外作成には Owner / Security Admin などの権限や、Azure Policy を編集できる権限が必要です。
• MCSB（Microsoft Cloud Security Benchmark）との依存：除外は MCSB イニシアチブに依存して評価・表示される旨が案内されています。環境側で前提が崩れていると、表示が不完全になることがあります。
• すべての推奨事項が除外対応とは限らない：除外できない推奨事項があること、カスタム推奨は除外できないことが明記されています。
• 複数イニシアチブに含まれる推奨事項は“全部”除外が必要：同じ推奨事項が複数のポリシー/標準に登場する場合、片方だけ除外しても残ることがあります。
• 管理グループで除外する場合の権限設計：管理グループスコープでの除外では、リソースプロバイダーの権限が論点になります（Reader 付与の注意が案内されています）。

結局どう判断する？現場向けの最短フロー

「(DC only) が非DC VM に出ている」問題は、最終的には “誤検知を直す” というより、運用上のノイズを減らしつつ、正しい対象にだけ対策を寄せることが目的になります。

状況	最初にやること	次の一手	おすすめの着地点
DC かどうか曖昧	OS 役割 / DomainRole / NTDS / OU を確認	DC なら監査設定を実装	DC のみで推奨事項を満たす
非DC と断言できる	伝播遅延も考慮して状況を観察	消えない場合は Exempt を作成	Selected resources で除外して Secure Score を整理
どう見ても誤判定・運用に支障	除外＋根拠を記録	改善が必要ならサポートへ	運用継続を優先して例外管理

「(DC only) の推奨事項が出る＝全部の VM を一律にハードニングする」のは、運用コストが跳ね上がる典型パターンです。DC だけが対象であることを前提に、適用対象の切り分け → DC だけ対処 → 非DCは必要なら Exemptの順に進めると、安全性とスピードのバランスが取りやすくなります。