ITDRとは？EDRとの違い・検知の仕組みと導入判断を実装者向けに解説【2026年時点】

ITDR（Identity Threat Detection and Response）は、盗まれた認証情報や乗っ取られたアカウントといった「アイデンティティを起点にした攻撃」を検知して対応する仕組みです。エンドポイント端末を守るEDRとは守備範囲が異なり、Active DirectoryやEntra IDなどのID基盤を監視の対象に据えます。この記事では、ITDRが検知する攻撃の技術的な仕組み、EDR・XDR・ISPM・IAMとの役割分担、SIEMやSOARと連携させた対応の自動化、そして受託開発で自社システムにID監視を組み込むときの設計指針までを、実装する側の視点で整理します。

まとめ：ITDRはアイデンティティ層に検知と対応を足す防御レイヤー

ITDRは、成熟したIAM（ID・アクセス管理）の上に「侵害の検知と対応」を重ねるレイヤーだと捉えると位置づけを掴みやすくなります。IAMが認証と認可の入口を制御するのに対し、ITDRは入口を突破された後の異常—認証情報の窃取、権限昇格、横方向への移動—を捕まえて封じ込める側です。Gartnerが2022年に一つのカテゴリとして提唱した比較的新しい領域で、EDRやEPPを導入済みの組織が次の一手として検討する対象になります。

導入の判断は検索順位やベンダーの宣伝文句ではなく、自組織のID基盤の重要度で決めます。Active DirectoryやEntra IDが業務の中核を担い、外部公開サービスが多く、権限の集約が進んでいる組織ほど費用対効果が出やすい構造です。逆に、監視すべきIDの母数が小さく既存のログ分析で足りている段階では、専用製品より先にIAMとログ基盤の整備を優先したほうが投資が生きます。

ITDRの定義と保護対象＝アイデンティティ基盤を狙う攻撃の位置づけ

ITDRという略語は Identity Threat Detection and Response の頭文字です。名前のとおり、守る対象はエンドポイントでもネットワークでもなく「アイデンティティ」に絞られています。ここでいうアイデンティティには、従業員のアカウントだけでなく、機械IDやサービスアカウントといった人が操作しない資格情報も含まれます。

ITDRがGartnerで2022年に定義された背景と対象範囲

Gartnerは2022年のサイバーセキュリティ動向のなかでITDRを一つのカテゴリとして提示しました。背景にあるのは、攻撃の起点が端末のマルウェアから「正規の認証情報を使った侵入」へ移った変化です。盗んだIDでログインされると、マルウェアを使わないぶんEDRの検知網をすり抜けやすくなります。ITDRはこの死角を埋めるために、認証イベントとID基盤の設定を監視の対象に据えました。対象範囲はオンプレミスのActive Directoryから、クラウドのIDプロバイダーまで広がります。

IAM・認証基盤による防御とITDRが守る領域の具体的な線引き

IAMと混同されやすいので線を引いておきます。IAMは「誰に何を許可するか」を設計・付与する予防の仕組みで、多要素認証やシングルサインオンもここに含まれます。対してITDRは、その予防を通り抜けた不正を「検知して止める」側です。たとえばMFAを設定していても、利用者を疲弊させて承認を押させるMFA疲労攻撃は成立します。IAMだけでは防ぎ切れないこうした侵害の兆候を捉えるのがITDRの領域だ、と役割で分けると整理できます。

ITDRが監視するデータソースと検知できる代表的な攻撃パターン

ITDRの中身を実装の目線で分解すると、「どのログを集めるか」と「どの異常をシグナルにするか」の二層になります。製品ごとに検知エンジンは違っても、見ているデータソースと狙う攻撃技術には共通項があります。

Active Directory・Entra IDのログを起点にした検知の仕組み

検知の起点になるのは、まずディレクトリサービスのログです。オンプレミスならActive Directoryのドメインコントローラが出力する認証イベント、クラウドならEntra IDのサインインログや監査ログが中心になります。ITDRはこれらを継続的に読み込み、ベースラインからの逸脱を評価する構造です。Microsoft Defender for Identityのように、ドメインコントローラにセンサーを置いてKerberosやNTLMの認証フローを直接観測する方式もあります。※エンドポイント側のプロセス挙動の検知はEDRの領域で、両者は別のログを見ています。

認証情報の窃取・権限昇格・横展開を捉える検知ロジックの具体例

代表的な検知対象を挙げると、ディレクトリ複製要求を悪用してパスワードハッシュを抜くDCSync、偽造したチケットで管理者になりすますGolden Ticket、多数のアカウントへ少しずつ試行するパスワードスプレーなどがあります。ITDRはこれらを、単発のイベントではなく「短時間の異常な認証パターン」として捉えます。たとえば普段アクセスしないサーバー群への連続認証が起きれば、横方向への移動の兆候として警告を上げる、という具合です。

MFA疲労攻撃やimpossible travelなど新しい脅威への対応

クラウドIDに特有の異常も検知の材料になります。地理的に離れた二拠点から短時間でログインが成立するimpossible travel、深夜に集中する承認要求、普段と違う端末やIPからの認証などです。ITDRはこうした文脈を組み合わせてリスクスコアを付け、しきい値を超えたらセッション失効やアカウントロックを促します。単一のルールで弾くのではなく、複数の弱いシグナルを束ねて判断する設計が特徴です。

EDR・XDR・IAM・ISPMとの違いとID防御での役割分担

ITDRは単独で完結する製品ではなく、既存のセキュリティ層と組み合わせて効果を出します。似た略語が並ぶため、まず守備範囲を一枚の表で押さえます。

EDR・XDRとの守備範囲の違いと組み合わせて使うときの補完関係

EDRは端末、XDRは複数レイヤーを横断して相関、ITDRはアイデンティティ、と担当が分かれます。下表のとおり、見ているログも検知の起点も異なるため、片方があればもう片方が要らないという関係ではありません。実際、Palo AltoのCortex XDRやCrowdStrike FalconのようにITDRをXDRの一機能として束ねる製品も増えており、統合か単独かは既存環境しだいで選びます。

この分担は、境界型防御からの脱却を掲げるゼロトラストの考え方（境界型防御との違いとNIST7原則）とも重なります。ゼロトラストが「誰も信頼せず都度検証する」思想を示すのに対し、ITDRはその検証を破られた場合の検知役を担う、と読み替えると設計に落とし込みやすくなります。

ISPMによる予防とITDRによる検知の役割分担と併用の判断

ISPM（Identity Security Posture Management）は、休眠アカウントや過剰な権限、設定ミスといった「攻撃される前の弱点」を洗い出して直す予防側の仕組みです。ITDRが動的な脅威をリアルタイムで捕まえるのに対し、ISPMは静的な姿勢を継続点検します。二つを併せると、弱点を減らしつつ突破された兆候も逃さない多層構造になります。予算が一つなら、まず攻撃対象を減らすISPMから入り、監視すべきIDの重要度が高い組織がITDRを重ねる、という順序が現実的です。

ITDR導入を判断する条件と受託開発でID監視を組み込む設計指針

ここからは判断の章です。カタログスペックの比較ではなく、「自組織に要るのか」「作るなら何に気をつけるのか」を条件付きで言い切ります。

ITDRを導入すべき組織の条件と過剰投資になりやすい場面の線引き

ITDRの費用対効果が出やすいのは、Active DirectoryやEntra IDが業務基盤の中心にあり、特権アカウントが多く、外部からアクセスされる資産を抱える組織です。金融や大規模SaaS事業者のように、ID一つの侵害が横展開で全体に波及する構造ほど効果が見合います。一方で、従業員規模が小さくIDの母数が限られ、既存のSIEMで認証ログを十分に見られている段階なら、専用ITDR製品は過剰投資になりがちです。その場合は先にIAMの棚卸しとログ集約を固めるほうが投資が生きます。導入するかどうかは、守るべきIDの数と侵害時の影響範囲で決めるのが実務的な線引きです。

SIEM・SOARと連携させたインシデント対応の自動化の設計指針

ITDRは、検知して終わりでは価値が半分です。検知したシグナルをSIEMに集約し、SOARのプレイブックで「セッションの失効」「パスワードの強制リセット」「アカウントの一時ロック」まで自動で走らせる設計にしてはじめて、対応の速度が攻撃者を上回ります。設計時は、誤検知で正規利用者を締め出さないよう、リスクスコアのしきい値と自動アクションの範囲を段階的に分けます。低リスクは通知のみ、高リスクは即時遮断、という二段構えが破綻しにくい構成です。

受託開発で自社システムにID監視機能を組み込む実装設計の注意点

自社サービスにID監視を作り込む場合、いきなり独自エンジンを書くより、IDプロバイダーが出す監査ログを起点に据えるのが堅実です。Entra IDやAuth基盤のサインインログをイベント基盤へ流し、異常検知は既存のルールとスコアリングから始めて、必要に応じて機械学習に広げます。私たちが受託開発で扱う際も、まず認証ログの取得口と保持期間を設計し、検知後の対応フローを業務側と握ってから実装に入る手順です。こうしたアイデンティティ監視を含むセキュリティ機能の設計と実装は、AIセキュリティ対策の受託開発として相談を受けています。攻撃手口の側から検知要件を洗い出すには、ClickFixのような偽CAPTCHAでコマンドを実行させる手口の実装者向け解説も設計の材料になります。

よくある質問

ITDRの導入や他ソリューションとの違いについて、実装や選定の現場で挙がりやすい質問に答えます。

ITDRとEDRは何が違うのですか？

いちばんの違いは、守る対象です。EDRはエンドポイント端末の挙動やプロセスを監視するのに対し、ITDRは認証情報やID基盤の異常を監視します。マルウェアを使わず正規のIDで侵入する攻撃はEDRの死角になりやすく、その領域をITDRが埋めます。両者は競合ではなく、端末とアイデンティティを別々に見る補完関係です。

小規模な組織にもITDRは必要ですか？

必須ではありません。守るべきIDの母数が小さく、既存のSIEMやログ分析で認証イベントを十分に見られている段階なら、専用製品より先にIAMの整備とログ集約を優先したほうが投資が生きます。特権アカウントが多い、外部公開資産が多い、といった条件が揃ってきたら検討の価値が高まります。

ITDRとIAMは別々に導入する必要がありますか？

役割が異なるため、IAMが前提でITDRを重ねる形になります。IAMは認証と認可を設計・付与する予防、ITDRはそれを突破された後の検知と対応です。IAMが未整備のままITDRだけ入れても、土台となる正規状態の定義が曖昧で誤検知が増えます。まずIAMを固め、その上にITDRを載せる順序が現実的です。

ITDRはクラウドとオンプレミスのどちらに対応しますか？

両方に対応する製品が主流です。オンプレミスのActive Directoryと、クラウドのEntra IDやIDプロバイダーの双方からログを集め、横断してリスクを評価します。ハイブリッド環境では、両者をまたいだ横方向の移動を追えるかどうかが製品選定の見極めどころになります。

ITDRを導入すれば多要素認証は不要になりますか？

不要にはなりません。多要素認証はIAM側の予防策で、ITDRはその予防が破られた兆候を検知する側です。実際、利用者を疲弊させて承認させるMFA疲労攻撃のように、多要素認証を設定していても成立する侵害があります。両方を併用して、予防と検知を二重に持つ構成が守りとして堅くなります。

関連記事

• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説：ITDRが検知で守る一方、攻撃対象を継続的に減らす脅威エクスポージャー管理の枠組みです。
• ClickFixとは？偽CAPTCHAでコマンドを実行させる手口と実装者向けの検知・防御：ITDRが検知対象とするID侵害の入口になる攻撃手口を、防御側の実装目線で解説しています。
• ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説：ITDRの前提となるID中心の防御思想を、設計原則から整理した記事です。