ITDRとは？認証情報の悪用を見つける仕組みとEDR・IAMとの違い
「正しいアカウントでログインしているから、問題はないはず」と考えたくなることがあります。
でも、そのアカウントを使っているのが本人とは限りません。
ITDRは、認証情報やアカウントを狙う脅威を見つけ、調査と対応につなげるための取り組みです。
この記事では、似た対策との違い、ログの見方、導入前に決めておきたい運用を、架空の業務システムの例で整理します。
この記事は以下のような人におすすめ！
- ITDRとIAM・MFA・EDRの関係を知りたい人
- 不審なサインインの通知から、何を調べるか迷っている人
- アカウントの停止などを、安全に判断できる運用を作りたい人
本記事はプロモーション（アフィリエイト広告）を含みます。
ITDRはアカウントや認証の仕組みを狙う脅威に向き合う
1-1. ログイン成功だけでは、本人の利用と決められない
ITDRはIdentity Threat Detection and Responseの略です。
アカウント、認証情報、権限、認証基盤などに関係する脅威を検出し、調査・対応につなげることに重点があります。
例えば、第三者に悪用された認証情報で、業務サービスにアクセスされる場面が考えられます。
MITRE ATT&CKでも、既存アカウントの認証情報を悪用する手法を「Valid Accounts」として整理しています。
攻撃者が目立つマルウェアを動かさず、利用できる権限の範囲で操作する場合もあるため、「不正なプログラムが見つからない」だけでは判断できません。（参考1、参考2）
1-2. 人のアカウント以外も、確認対象になる
業務で使うのは、社員のアカウントだけではありません。
アプリの連携用アカウント、サービスアカウント、機器や自動処理が使う識別情報などもあります。
これらは人以外の主体、つまりNHIと呼ばれることがあります。
使われなくなった権限や、管理者が曖昧な連携が残っていないかも、確認したい点です。
ただし、すべてのITDR製品がすべての種類のIDを扱えるとは限りません。
例えばSophosの公式資料では人と機械のIDを対象として説明していますが、実際の対応範囲や接続条件は製品ごとに確認します。（参考3）
IAM・MFA・EDR・SIEMとは役割が違う
2-1. IAMとMFAは、適切に利用させるための基盤
IAMは、誰にどのリソースへのアクセスを認めるかを管理するための仕組みです。
本人確認やアカウントの作成・変更・削除、権限の管理などが関係します。
MFAは多要素認証で、複数の異なる要素を組み合わせて認証を強化します。
ITDRはこれらを不要にするものではなく、設定されたアカウントや権限が不正に使われていないかを確認し、対応を支援する観点です。
認証の方式によって、フィッシングへの耐性は異なります。
MFAという名前だけで安全性を一括りにせず、方式と運用を確認する必要があります。（参考1、参考4）
2-2. EDRは端末、SIEMはログを横断して見る
EDRは、PCやサーバーなどの端末で起きる動作を監視し、脅威への対応を支援するものです。
SIEMは、複数の仕組みから集めたログを分析・関連付けて調査するために使われます。
ITDRでは、その中でもIDや権限、認証基盤の情報を深く見ることに重点があります。
例えば、端末の不審な動作と、同じ利用者の権限変更が同時に起きていたら、それぞれの情報を合わせて調べる方が状況をつかみやすくなります。
2-3. まず既存の仕組みで何が見えるか確認する
新しい製品を増やす前に、現在の認証基盤や監視ツールで得られる情報を並べてみましょう。
ログインの成功・失敗、管理操作、権限の変更、端末の状態など、すでに確認できるものがあるかもしれません。
そのうえで、情報のつながりが足りないのか、検出の条件が足りないのか、対応する担当が決まっていないのかを分けます。
製品名を増やすことよりも、自社の調査で困っている部分を具体的にすることが先です。
| 観点 | 主に確認したいこと | ITDRとの関係 |
|---|---|---|
| IAM・MFA | 誰に利用を認め、どう認証するか | 管理・認証情報を調査や対応へ活かす |
| EDR | 端末上の不審な動作 | IDの利用状況と合わせて調べる |
| SIEM | 複数のログの相関 | IDに関する検出や調査結果を連携する |
| ITDR | ID・権限・認証基盤を狙う脅威 | 既存の予防・監視・対応を補う |
不審な通知は、出来事をつないで調べる
3-1. 同じ利用者の認証と操作を時系列で見る
架空の社員Aのアカウントを例にします。
午前9時に認証が失敗し、1分後に成功、その直後に権限の変更が記録されたとしましょう。
これだけで不正利用とは断定できませんが、時刻と対象をそろえて確認するきっかけになります。
認証の結果、端末や接続元の情報、変更した権限、対象サービスの操作などを合わせて見ます。
時刻の記録方式やタイムゾーンが異なる場合は、出来事の前後を取り違えないようにしてください。
3-2. いつもと違う接続元でも、攻撃とは限らない
接続元のIPアドレスや推定された地域が変わると、気になりますよね。
ただし、会社のVPN、モバイル回線、拠点の変更などでも、外から見える接続元は変わります。
利用者の予定や管理者の変更作業、端末の状態も確かめ、検出の理由が正しい前提に基づいているかを確認します。
連絡を取るときは、不審なメールに書かれた連絡先ではなく、社内で確認済みの経路を使いましょう。
通知の文字列だけを利用者へ転送して終わらせず、「何の操作を、いつ、どの端末で行ったか」を具体的に確認すると、調査を進めやすくなります。
3-3. 検出の理由と、確認できた事実を分ける
例えば、次のように記録を整理できます。
| 種類 | 説明用の記録例 |
|---|---|
| 検出の理由 | 普段と異なる接続元から認証が成功した |
| 確認できた事実 | 対象アカウントと時刻、成功の記録がある |
| 未確認事項 | 本人の利用か、VPN経由か、端末の状態は正常か |
| 追加確認 | 管理済みの連絡経路で本人と担当者に確認する |
| 対応の判断 | 必要な範囲を決め、承認された手順で実施する |
正当な利用だった場合も、その理由と確認方法を残しておくと、次に似た通知が出たときの参考になります。
ただし、一度正当だった接続元を、将来も無条件で許可するという意味ではありません。
導入前に、取得範囲と対応のルールを決める
4-1. どのIDとログを確認できるか調べる
認証基盤、業務サービス、人のアカウント、サービスアカウントを、最初に整理します。
対象の種類ごとに、接続できる製品や取得できる記録が変わる可能性があります。
ログの取得が遅れる、保管期間が短い、権限不足で一部しか見えない、といった条件も確認してください。
通知がないときも、監視対象が安全なのか、単に情報を取得できていないのかを区別します。
製品の説明に含まれる対象例を、自社ですべて利用できるという意味に読み替えないことが大切です。（参考3）
4-2. 試す条件と誤検知を先に考える
評価では、何を見つけたいのかを具体的に決めます。
例えば、使われていないアカウントの利用や、想定外の権限変更を、必要な情報と合わせて担当者へ渡せるか、という観点です。
実際に不正アクセスを行うのではなく、許可された検証環境や製品が用意する安全なテスト方法を使って確認します。
検出できた件数だけでなく、正当な業務を誤って止めないか、調査に必要な情報がそろうかも評価してください。
4-3. 停止・再認証・セッション対応の権限を決める
不正利用が疑われるときは、アカウントの制限、再認証、セッションの失効、端末の調査などが対応候補になります。
ただし、操作の効果や必要な権限は、対象のサービスや認証の仕組みによって異なります。
パスワードを変えればすべての利用が直ちに止まる、と決めつけないでください。
既存のセッションや連携先への影響を、対象サービスの公式手順で確認する必要があります。（参考4）
特に、共有アカウントやサービスアカウントの停止は、複数の業務を止める可能性があります。
緊急時の承認者、連絡先、代替手段、戻す判断まで事前に整理しておくと、慌てて広い範囲を止める失敗を避けやすくなります。
通知だけを根拠に、全利用者のアカウント停止や、認証方式の変更を自動実行しないでください。
対象と影響を確認し、組織で承認された対応手順に従います。
4-4. 監視する情報の扱いと保管を確認する
認証や操作の記録には、利用者を識別できる情報や、勤務・利用の状況に関係する情報が含まれます。
業務上必要な範囲で取得し、目的、閲覧できる担当者、保管期間、外部への送信先を確認しましょう。
パスワードやトークンの実値を、調査メモや共有資料へ貼り付けることは避けます。
相談時には、対象アカウントの識別情報や時刻など、必要な情報に絞り、秘密情報をそのまま再配布しないようにします。
また、監視対象が増えたときに、対応の担当人数や保管量がどう変わるかも、運用と費用の評価に含めてください。
4-5. 試用で何を確かめるかを決めておく
製品を試すときは、通知が出ることだけを合格条件にしない方が、運用を具体的に評価できます。
例えば、次のような確認項目を用意できます。
| 確認する場面 | 評価したいこと |
|---|---|
| 正当なVPN利用で接続元が変わる | 必要な情報を見て正当利用か調査できるか |
| 許可された検証用アカウントの権限を変える | 対象と変更内容を、担当者へ正しく渡せるか |
| 連携が止まり情報を取得できなくなる | 安全になったと誤認せず、収集停止に気付けるか |
| 承認された範囲で対応する | 記録・再確認・業務影響の確認まで追えるか |
これは評価の考え方を示す例で、この記事で実施した試験や、すべての製品で使える操作を示すものではありません。
本番で無断の検証や権限変更をせず、管理者と合意した安全な環境・方法で確認してください。
評価中に分からなかった点も一覧に残し、設定不足なのか、製品の対象外なのか、別の運用で補うのかを分けて検討します。
不正利用が疑われる出来事が起きても、記録の読み方や調べる範囲が分からず、社内だけでは結論を出せないことがあります。
そのようなときは、外部の調査会社に侵入の経路や影響の範囲の調査を依頼する方法があります。
相談先の候補の一つが、法人のサイバー攻撃被害や社内不正の調査を扱う「デジタルデータフォレンジック」で、広告主の案内では相談や見積もりは無料とされています。
- 不審なサインインのあと、権限の変更やデータの持ち出しが疑われる
- どのアカウントや端末まで影響したか、社内で判断できない
- 取引先や監督官庁へ説明するために、調査の記録が必要になる
ITDRについてよくある質問
5-1. 認証と監視の組み合わせで迷いやすいこと
Q1. MFAがあれば、ITDRは不要ですか？
MFAは重要な予防策ですが、それだけで全てのIDの悪用がなくなるとは限りません。
認証方式、端末、既存セッション、運用上の権限も含め、監視や調査で補う範囲を考えます。
Q2. ITDRはEDRの代わりになりますか？
単純な代替ではありません。
端末の動作とIDの利用を合わせることで、片方だけでは分かりにくい状況を調べやすくなります。
Q3. 不審な地域からのログインは、不正利用ですか？
その情報だけでは断定できません。
VPNや回線、本人の利用状況、ほかの操作記録などを確認します。
Q4. 自動対応は必ず有効にするべきですか？
必ずではありません。
まず検出と調査の結果を確認し、停止の影響が分かる範囲から、組織の承認に沿って検討します。
Q5. 最初にどこから始めればよいですか？
重要な業務サービスを一つ選び、対象ID、取得できる記録、通知を受ける担当、対応の承認者を整理するところから始められます。
まとめ：認証の成功だけで終わらず、利用の中身を確認する
ITDRは、アカウントや認証基盤を狙う脅威を検出し、調査と対応につなげるための観点です。
IAMやMFAによる予防、EDRによる端末の監視、SIEMによるログ分析と役割を分けて考えると、導入の目的が明確になります。
まずは、何を取得でき、何がまだ分からないのかを把握しましょう。
そのうえで、確認と対応を担当者へつなぐ流れを作ることが、通知を出すだけの運用から一歩進む助けになります。
