defender-for-identity について
Microsoft Defender for Identity の導入と運用を支援するガイダンススキルです。セキュリティチームがオンプレミスおよびハイブリッドの ID 基盤をカバーし、検知結果や ID セキュリティ態勢のリスクに対応できます。
主な機能
- 01Active Directory の攻撃パターンに関する検知ガイダンス
- 02ID 基盤のセンサー配置計画
- 03Directory Service Account と gMSA の導入ガイダンス
- 04Identity Security Posture 評価のガイダンス
- 05Honeytoken と Defender XDR の運用ガイダンス
活用シーン
- 01DC と AD CS のセンサー配置を計画
- 02Kerberoasting や DCSync の検知を調査
- 03ID セキュリティ態勢評価の指摘事項を優先順位付け
- 04Honeytoken の配置と XDR インシデント確認を計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ vinayaklatthe/ microsoft-security-skills --skill defender-for-identityインストール後、Claude Code で/defender-for-identityを入力して読み込まれたか確認します。
詳細
Microsoft Defender for Identity
Microsoft Defender for Identity(MDI)は、クラウドベースの ID 脅威検出・対応(ITDR)ソリューションです。ドメインコントローラーやその他の ID インフラストラクチャに設置された軽量センサーが、ネットワークトラフィック、ETW イベント、AD オブジェクトの読み取りを解析し、偵察、認証情報の窃取、ラテラルムーブメント、ドメイン支配を検出します。シグナルは相関付けられ、Defender XDR のインシデントにまとめられます。
使用する場面
オンプレミスの Active Directory、AD CS、AD FS、Entra Connect に対する ID ベースの攻撃を検出し、それらの攻撃につながる ID セキュリティ態勢の問題(レガシープロトコル、セキュリティ保護されていないアカウント、リスクの高い委任)を明らかにする場合に使用します。
クラウドのみの Entra ID のリスク検出にはこのスキルを使用しないでください。その場合は Entra ID Protection(entra-id-protection)を使用します。MDI が監視するのは、オンプレミスおよびハイブリッドの ID インフラストラクチャです。
攻撃を検出ソースに対応付ける
攻撃者の行動に該当する行を選び、MDI が適切な対策かどうかと、どのセンサーがシグナルを生成するかを確認します。
| 攻撃者の行動 | MDI の検出ファミリー | センサーの監視対象 |
|---|---|---|
| ユーザー、グループ、SPN を列挙する | 偵察 | DC センサー(LDAP、SAMR) |
| サービスアカウントの TGS チケットをオフラインで解読する | Kerberoasting | DC センサー(Kerberos) |
| ディレクトリのシークレットを複製する(DCSync) | ドメイン支配 | DC センサー(DRSUAPI RPC) |
| Kerberos チケットを偽造する | Golden / Silver Ticket | DC センサー(Kerberos の異常) |
| AD CS の設定ミス(ESC1~ESC8)を悪用する | 証明書ベースの権限昇格 | AD CS センサー |
| AD FS のサインインフローを乗っ取る | トークン / SAML の偽造 | AD FS センサー |
| Entra Connect の同期アカウントの認証情報を窃取する | ハイブリッド ID の侵害 | Entra Connect センサー |
| リスクの高い構成(レガシー SMB、脆弱な SPN など)を調査する | ID セキュリティ態勢管理(ISPM) | すべてのセンサー + クラウド評価 |
経験則: 攻撃者がいずれかの段階でオンプレミスの ID サービスに接触する場合、MDI はその動作を検出するはずです。いずれかのセンサー(計測されていない DC、AD CS、AD FS)が欠けていると、攻撃のキルチェーン全体に死角が生じます。
アプローチ
-
ID インフラストラクチャをマッピングする — すべてのドメインコントローラー(RODC を含む)、すべての AD CS エンタープライズ CA、すべての AD FS サーバー、すべての Entra Connect/Cloud Sync ホストを棚卸しします。 この一覧がセンサーの対象リストです。ここに漏れがあると、後で攻撃経路になります。 確認:
Get-ADDomainController -Filter *の件数が、MDI ポータルの[Settings → Sensors]に表示される展開済みセンサー数と一致することを確認します。 -
デプロイ前に前提条件を確認する — 各センサーホストには、MDI クラウドサービスへの送信 HTTPS 接続、MDI センサー MSI、Directory Service Account(DSA)、さらに(DC では)MDI が必要とする Advanced Audit Policy の設定と Object Access SACL が必要です。 確認:MDI sizing tool を実行して CPU/RAM に余裕があることを確認します。DC では、センサーによる継続的な CPU 使用率の増加が 10% 未満になるようにします。
-
Directory Service Account には gMSA を使用する — グループ管理サービスアカウントはパスワードを自動的にローテーションするため、最も深刻な種類の認証情報漏えいを防げます。パスワードを平文で保持するサービスアカウントは決して使用しないでください。 確認:
Get-ADServiceAccount mdi-gmsa$ -Properties PrincipalsAllowedToRetrieveManagedPasswordを実行し、センサーホストのグループのみが返され、それより広い範囲が含まれていないことを確認します。 -
センサーを段階的にデプロイする — まず DC センサー(最も多くのシグナルを得られます)、次に AD CS、AD FS、Entra Connect の順にデプロイします。各段階の間を 24 時間空けてトラフィックのベースラインを確立し、初めて検出されたアクティビティのアラートで SOC があふれないようにします。
-
アラートを調整してから、セキュリティ態勢に対処する — 初週に発生する無害なアラート(管理ツールによるノイズ)を確認したうえで、Identity Security Posture Assessments(Secure Score パネル)に取り組みます。セキュリティ態勢の問題(例:安全でないアカウント属性、レガシープロトコル、休眠アカウント)は、アラートが発生する前に攻撃者が悪用する弱点です。 確認:1 週目にセキュリティ態勢スコアのベースラインを記録し、日次ではなく月次で変化を追跡します。
-
ハニートークンを配置する — 人が決して使用しないはずの、偽の高権限アカウント(例:
svc-legacy-backup)を 1~2 個配置します。認証が試みられた場合、悪意のある活動である可能性が非常に高いと判断できます。 -
Defender XDR で相関分析する — MDI アラートは MDE および Entra ID Protection と自動的に相関され、単一の XDR インシデントにまとめられます。単独のアラートではなく、インシデントから調査します。
運用上のガードレール
- すべての DC にセンサーを配置してください。 センサーが導入されていない DC が 1 台でもあると、攻撃者に横展開の足掛かりを与えることになります。RODC も含みます。
- 2026 年に AD CS センサーは必須です。 現在のインシデント対応事例で、AD CS の悪用(ESC1~ESC8)は最も一般的な権限昇格経路です。AD CS センサーがなければ、結果(Domain Admin)は確認できても、原因を確認できません。
- DSA には gMSA を使用してください。 固定パスワードを持つ通常のサービスアカウントは使用しないでください。次の Kerberoasting の標的になります。
- アラートは調整し、抑制しないでください。 ノイズをなくすためにアラートの種類を無効化すると、検出機能が失われます。抑制はソース単位で行い、毎月見直してください。
- ハニートークンは慎重に扱ってください。 偵察ツールに見つかる場所(グループメンバーシップ、説明欄など)に配置する一方、SOC が正当なテストによる検知の調査に時間を費やさないよう、配置を記録してください。
よくあるアンチパターン
- 「まず最も重要な DC を対象にします」 — 攻撃者はセンサーが導入されていない DC を選びます。すべての DC に導入するか、まったく導入しないかです。
- 「簡単なので、ドメイン管理者アカウントを DSA に使用しています」 — センサーホストが侵害された場合、攻撃者にドメイン管理者の権限を渡すことになります。常に最小権限の gMSA を使用してください。
- 「セキュリティ態勢のアラートは本物のアラートではないので無視します」 — セキュリティ態勢の問題は攻撃前のシグナルです。これらを解消するほうが、それによって引き起こされるインシデントへの対応よりも低コストです。
- 「証明書をあまり発行しないので、AD CS センサーは導入しませんでした」 — 発行数は関係ありません。標準の AD CS インストールにも ESC1/ESC8 の設定ミスは存在するため、監視が必要です。
- 「MDI アラートを従来の SIEM に直接送っており、Defender XDR は使用していません」 — ワークロードをまたいだ相関分析が失われます。SIEM を主に使う場合でも、攻撃グラフのために XDR を維持してください。
プロンプトの例
Plan Defender for Identity sensor coverage across DCs, AD CS, AD FS, and Entra Connect.Which Defender for Identity detections cover the Kerberoasting kill chain?How do I configure a gMSA Directory Service Account for MDI?Which Identity Security Posture assessments should I fix first?Show me how to deploy a honeytoken account in MDI.Why am I seeing high CPU on a DC after installing the MDI sensor - how do I size it?
Microsoft Learn
- 概要:https://learn.microsoft.com/defender-for-identity/what-is
- 容量の計画(サイジングツール):https://learn.microsoft.com/defender-for-identity/deploy/capacity-planning
- AD CS へのセンサーの配置:https://learn.microsoft.com/defender-for-identity/deploy/active-directory-federation-services
- Directory Service Account(gMSA):https://learn.microsoft.com/defender-for-identity/deploy/directory-service-accounts
- Identity Security Posture の評価:https://learn.microsoft.com/defender-for-identity/security-assessment
- ハニートークンアカウント(エンティティタグ):https://learn.microsoft.com/defender-for-identity/entity-tags
- アラートのリファレンス(Kerberoasting、DCSync、Golden Ticket):https://learn.microsoft.com/defender-for-identity/alerts-overview