社員のメールアドレスが載った漏えいの情報をエージェントが毎週確かめ、新しく見つかった社員にパスワードの変更と多要素認証の案内を送って対応を追う

処理の起点を決める

毎週月曜の8時に、Schedule Trigger で動かします。 間隔は Weeks を選び、曜日と時刻を指定します。n8n の Schedule Trigger はワークフローのタイムゾーン（未設定ならインスタンスのタイムゾーン）に従い、セルフホストの既定は America/New York です。ワークフローの設定で Asia/Tokyo を指定します。 公開（publish）したワークフローでなければスケジュールは動きません。

毎日にしない理由は2つあります。 1つは、漏えいの情報の追加は毎日あるわけではなく、週に1回まとめて見れば足りることです。もう1つは、追跡に使う多要素認証の登録状況のレポートが、最大36時間遅れて更新されることです。毎日引いても、社員が登録した直後の状態は反映されていません。

通知のメールを起点にもしません。 APIの結果を先週の結果と比べる方式なら、通知が届かなかった週も取りこぼしません。

入力データを集める

質を決めるのは、いちばん下の2つです。 対応の記録が無いと、同じ漏えいで同じ社員に毎週案内が届きます。例外の一覧が無いと、info@ や support@ のような窓口のアドレスに、個人あての案内を送ることになります。

データの取得方法を決める

ドメインの検索は、HTTP Request ノードで GET https://haveibeenpwned.com/api/v3/breacheddomain/{domain} を呼びます。 ヘッダーに hibp-api-key でAPIキーを入れ、user-agent に自社のワークフローを表す名前を入れます。 公式のページは、User-Agent が無いリクエストを HTTP 403 で拒むとしています。

ユーザーの2つの値は、$select を付けないと返りません。 Graph のユーザーの説明では、accountEnabled と lastPasswordChangeDateTime はどちらも「Requires $select to retrieve」です。付け忘れると値が空で返り、「パスワードを変えていない」と誤って判定します。

登録状況の権限は AuditLog.Read.All です。 Usage and insights には Microsoft Entra ID P1 か P2 が要ります。無効化されたユーザーにはこのAPIが働きません。

差分の鍵には、漏えいの Name を使います。 Name は変わらない識別子で、Title は表示用で変わることがあります。

AIへ渡す前に整形する

1. ドメインを横に並べる … 2つのドメインの結果を alias@domain の形に戻し、1つの一覧にします
2. 差分を取る … 先週の一覧に無かった「アドレス×漏えい（Name）」だけを残します
3. 例外の一覧で外す … 窓口のアドレスと共有のメールボックスは、エージェントに渡さず担当者の一覧へ直接回します
4. 過去の案内と突き合わせる … 同じアドレスに同じ漏えいで案内済みなら外します。別の漏えいなら残します
5. 漏えいの詳細をまとめて引く … 同じ週に同じ漏えいの社員が何人もいるので、/breach/{name} は漏えいごとに1回だけ呼び、結果を使い回します
6. 429 に備える … 上限を超えると HTTP 429 と retry-after が返ります。待ってから引き直します

3番目を軽く見ないでください。 窓口のアドレスは何十もの漏えいに載っており、渡すと毎週同じ「該当者なし」を作り続けます。

AIに処理させる

させるのは、組み合わせごとに道具を使って事実を集め、案内の種類を1つ選び、文面を作ることです。 選ぶ規則はシステムメッセージに書き、エージェントは事実を規則に当てはめます。

パスワードの変更日は、漏えいの日付（BreachDate）ではなく追加日時（AddedDate）と比べます。 公式の説明では、BreachDate は「多くの場合不正確なので目安として扱う」とされています。漏えいが起きた日より後にパスワードを変えていても、変えた先が漏れたパスワードと同じなら意味がないので、日付だけで閉じない規則にします。

3行目は見落とされやすい点です。 ドメイン検索は、公開の検索では返らない「センシティブな漏えい」も返します。 上長へ回すときは漏えいの名前を書きません。

指示内容を固定する

あなたは情報システム部で、社員のメールアドレスが載った漏えいへの対応を
仕分ける立場です。道具で調べた事実だけを使って判断してください。

【入力】
- 対象のアドレス：{email}
- 漏えいの識別子：{breach_name}
- 実行日：{run_date}

【使える道具】
- get_breach(name) …… 漏えいの詳細（DataClasses, AddedDate, BreachDate,
  IsVerified, IsFabricated, IsSpamList, IsStealerLog, IsMalware, IsSensitive）
- get_user(email) …… 社員のアカウント（accountEnabled,
  lastPasswordChangeDateTime, department）
- get_mfa(user_id) …… 多要素認証の登録状況（isMfaRegistered,
  methodsRegistered, lastUpdatedDateTime）
- get_history(email) …… 過去の案内の記録

【案内の種類の選び方】上から順に当てはめ、最初に当たったものを選ぶ
1. 社員が見つからない、または値が引けない → needs_human
2. accountEnabled が false → no_action
3. IsStealerLog または IsMalware が true → device_check
4. DataClasses に Passwords があり、lastPasswordChangeDateTime が
   AddedDate より前 → reset_and_mfa
5. isMfaRegistered が false → mfa_only
6. IsSpamList が true → no_action
7. それ以外 → notice_only

【厳守事項】
- 道具で引けなかった値を推測で埋めないでください。引けなければ
  needs_human にし、reason に引けなかった道具を書いてください。
- BreachDate を判断に使わないでください。日付の比較は AddedDate だけです。
- lastPasswordChangeDateTime が空のとき、「変更していない」と
  扱わないでください。needs_human です。
- 不正アクセスが起きたかどうか、アカウントを止めるべきかを
  書かないでください。
- 文面には漏えいの名前を書いてよいのは本人あての案内だけです。
  manager_note には漏えいの名前を書かないでください。
- 文面の最後に、情報の出典が Have I Been Pwned であることと
  https://haveibeenpwned.com へのリンクを書いてください。
- evidence には、判断に使った値を道具の返した形のまま写してください。

「引けなかった値を推測で埋めない」を明記しないと、空の変更日を「変更していない」と読みます。 空と「古い」を区別させます。

出典のリンクを入れるのは、漏えいの情報が CC BY 4.0 で提供されているためです。 公式のページは、出所の表示とリンクを求めています。

出力形式を固定する

Structured Output Parser で次の形のJSONを受け取ります。

{
  "email": "",
  "breach_name": "",
  "action": "reset_and_mfa | mfa_only | notice_only | device_check | no_action | needs_human",
  "facts": {
    "has_password": true,
    "is_verified": true,
    "is_spam_list": false,
    "is_stealer_log": false,
    "account_enabled": true,
    "last_password_change": "",
    "breach_added": "",
    "mfa_registered": false
  },
  "evidence": [""],
  "reason": "",
  "mail_subject": "",
  "mail_body": "",
  "manager_note": ""
}

1つ目の理由は、facts と action を分けて持てることです。 担当者は facts を見れば、なぜその種類になったかが分かります。規則を変えたときも、facts から action を選び直すだけで過去の判断をやり直せます。

2つ目は、追跡の条件が action で決まることです。

なお、Structured Output Parser はJSONの例から作るとすべての項目が必須になり、$ref は使えません。 空のときも項目そのものは返させます。

システムへ連携する

Graph には読み取りの権限しか付けません。 判断を誤っても、誤った案内が1通届くだけで済みます。

送信の承認は、週の一覧で一度に行います。 n8n の Outlook ノードには Send and Wait for Response の操作があり、道具の呼び出しに人の確認をはさむこともできますが、1通ごとでは60回の承認になります。 エージェントには送信の道具を持たせず、承認された一覧を後段のノードでまとめて送ります。

人が確認する

1. device_check を先に見る … 端末がマルウェアに感染している疑いがあります。社員へ案内を送る前に、端末の管理の担当と連絡を取ります
2. needs_human を見る … 多くは例外の一覧の漏れ（窓口のアドレス、旧姓のアドレス）です。一覧を直します
3. reset_and_mfa の件数を見る … 同じ漏えいで急に何十人も出たら、自社が使っている業務のサービスの漏えいかもしれません。個別の案内とは別に、全社への周知を考えます
4. 一覧を承認する … 承認したものだけが送られます
5. 2回目の催促でも閉じない社員に直接連絡する

3番目を省かないでください。 1人ずつ処理していると、業務のサービスが漏えいしたという事実が、個別の案内に埋もれます。

例外に対処する

上から1行目は、気づかないと毎週「新しい漏えいなし」が続きます。 403 を0件と同じに扱わないように、ステータスコードで分けて通知します。

記録を残す

• 毎週のドメインの検索結果の全文（ドメインごと）と、先週との差分
• 組み合わせごとのエージェントの出力（facts、action、evidence、reason）と、エージェントが呼んだ道具の記録
• 担当者の承認の記録（誰が、いつ、どの一覧を承認したか）
• 送った案内と催促の日時、宛先、種類
• 閉じた日時と、閉じる判定に使った Graph の値
• 人が action を変えた記録 … どれを、どれに変えたか

2つ目で道具の記録を残すのは、facts の値が本当に道具から来たかを確かめるためです。 Tools Agent の Return Intermediate Steps を有効にします。ドメインの検索結果は、保管の期間を決めて消します。