業務で使っている正規サイトへのリンクがSafe Linksで「危険」と判定されても、Safe Links全体を無効化する必要はありません。管理者は、対象URLをMicrosoftへ提出して再評価を依頼できます。
ただし、URLをMicrosoftへ提出することと、Tenant Allow/Block Listに許可エントリを作成することは別の操作です。まずは分析のみを依頼し、業務継続のために即時解除が必要で、かつ安全性を確認できた場合に限って、対象URLと期限を絞った一時許可を検討します。
Safe Linksは、メール配信時のURL検査に加え、利用者がリンクをクリックした時点でもURLを確認する仕組みです。全体を無効化すると、今回の業務サイトだけでなく、他のメールに含まれる不正リンクへの保護まで弱めてしまいます。([Microsoft Learn][1])
Safe Linksで正規URLがブロックされたときの管理者対応
基本的な対応順序は次のとおりです。
- 利用者から発生時刻、対象URL、元メールなどを回収する
- 管理者がリンク先の安全性を確認する
- Microsoft DefenderポータルからURLをMicrosoftへ提出する
- 分析のみで待つか、一時的な許可エントリも作成するかを判断する
- 提出結果とTenant Allow/Block Listを再確認する
- 不要になった許可エントリを削除する
判断の目安は次のとおりです。
| 状況 | 選ぶ対応 | 許可エントリ |
|---|---|---|
| 正規サイトと思われるが、安全性を断定できない | It appears cleanとして分析を依頼 | 作成しない |
| 管理者側で安全性を確認済みだが、緊急性は低い | I've confirmed it's cleanとして提出 | 原則として作成しない |
| 安全性を確認済みで、業務停止を早急に解消する必要がある | 提出に加えてAllow this URLを選択 | URLと期限を限定して作成 |
| ドメイン全体を許可すれば簡単に解決できそう | 個別URLの原因調査と提出を優先 | 広範囲の許可は避ける |
重要なのは、「業務で使っているサイトだから安全」と判断しないことです。正規サイトでも、アカウント侵害、改ざん、不正なリダイレクト、広告配信経路の悪用などが発生する可能性があります。
最初に利用者から回収する情報
管理者が調査を始める前に、利用者から必要な情報をまとめて回収します。情報が不足したまま許可すると、別のURLを誤って許可したり、インシデントの痕跡を失ったりするおそれがあります。
| 回収する情報 | 確認内容 |
|---|---|
| 発生日時 | 日付、時刻、タイムゾーンを記録する |
| 利用者 | 氏名、メールアドレス、所属、端末 |
| 対象URL | 省略せず、パスやクエリ文字列を含むURLを保存する |
| 元メール | 件名、送信者、受信日時、Message ID、可能なら元メールファイル |
| 警告画面 | 表示された警告内容、検出時刻、エラーや追跡情報 |
| 利用環境 | Outlook、Teams、Webブラウザーなど、どこから開いたか |
| 影響範囲 | 1人だけか、複数人で再現するか |
| 業務上の用途 | 何の業務で、どの操作を行うためのURLか |
元メールは転送だけで済ませず、可能であれば.emlや.msgなど、ヘッダー情報を保持した形式でも保存します。ただし、個人情報や機密情報を含む場合は、組織のインシデント対応手順や情報管理ルールに従って扱ってください。
警告画面だけで安全性を判断しない
警告が誤検知に見えても、すぐに許可してはいけません。少なくとも次の点を確認します。
- URLのドメイン名にスペル違いがないか
- 表示文字列と実際のリンク先が一致しているか
- リダイレクト後の最終到達先が想定どおりか
- 当該サイトの管理者やサービス提供元がURLを正式に案内しているか
- サイト管理者側で改ざんや侵害が確認されていないか
- 通常と異なるログイン画面やファイルダウンロードが表示されないか
- メール送信者とURLの業務上の関係が説明できるか
一般利用者の端末から警告を回避して何度もアクセスするのではなく、組織で利用しているセキュリティ調査環境や隔離環境で確認します。
Microsoft DefenderポータルからURLを提出する手順
Microsoft Defenderポータルでは、メール、添付ファイル、URLなどをMicrosoftへ提出し、分析を依頼できます。URL提出は、Safe Linksの誤検知を修正するための正規の手段です。
URL提出画面を開く
- Microsoft Defenderポータルを開く
Actions & submissionsを選択するSubmissionsを開くURLsタブを選択するSubmit to Microsoft for analysisを選択する- Submission typeが
URLになっていることを確認する - 対象の完全なURLを入力する
Microsoftのドキュメントでは、1回の操作で複数のURLを入力できます。ただし、原因調査や変更記録を明確にするため、関連性のないURLを一度に大量提出する運用は避けた方が管理しやすくなります。([Microsoft Learn][2])
「It appears clean」と「I’ve confirmed it’s clean」を使い分ける
URLを入力すると、そのURLをどのような理由で提出するかを選択します。
It appears clean
正規URLと思われるものの、管理者側では安全性を断定できず、Microsoftの判定を求める場合に選択します。
この選択では、基本的に分析依頼だけを送信します。リンク先の安全性を確認できていない段階で、許可エントリを作成してはいけません。
I’ve confirmed it’s clean
サイト管理者への確認、リダイレクト先の確認、セキュリティ調査などを行い、組織として安全と判断できた場合に選択します。
この選択後は、次の画面で以下のいずれかを選べます。
SubmitAllow this URL
安全性を確認済みであっても、Microsoftの評価結果を待てる場合はSubmitだけを選択できます。I've confirmed it's cleanを選んだからといって、必ず許可エントリを作成する必要はありません。([Microsoft Learn][2])
提出理由は社内記録にも残す
画面構成や表示項目は、ライセンス、言語設定、ポータルの更新状況によって異なる場合があります。自由記述の理由欄が常に表示されるとは限りません。
そのため、ポータルへの入力とは別に、社内の変更記録へ次の内容を残します。
対象URL:
https://portal.example.jp/account/login
発生日時:
2026年9月19日 09:40 JST
利用者:
営業部3名
元メール:
取引先から送付された業務案内メール
安全性の確認:
業務サイト管理者にURLを確認
リダイレクト先を確認
不審なダウンロードなし
提出区分:
I've confirmed it's clean
許可エントリ:
作成なし
対応責任者:
情報システム担当者名
再確認予定日:
2026年9月22日これは説明用の社内記録例です。実際の分析結果やポータルの実測値を示すものではありません。
分析のみの提出と「Allow this URL」は別の操作
Safe Linksの誤検知対応で最も間違えやすいのが、分析提出と許可エントリの混同です。
| 項目 | Microsoftへの分析提出 | Allow this URL |
|---|---|---|
| 主な目的 | MicrosoftにURLの再評価を依頼する | テナント内でURL判定を上書きする |
| Tenant Allow/Block List | 通常は追加しない | URLのAllowエントリを作成する |
| セキュリティ検査への影響 | 判定結果の確認・改善を依頼 | 対象URLに関連するURLベース検査を迂回する |
| 適した場面 | 誤検知の疑いがある場合 | 安全性確認済みで緊急解除が必要な場合 |
| 主なリスク | 結果が出るまで利用できない可能性 | 悪意あるURLを許可すると防御を回避される |
Allow this URLを選ぶと、対象URLがTenant Allow/Block Listへ登録されます。許可されたURLが再び検出された場合、Safe Linksのデトネーション、URLレピュテーション、そのほかのURLベースフィルターが上書きされ、利用者がURLへアクセスできる状態になります。([Microsoft Learn][2])
つまり、Allow this URLは単なる「Microsoftへの情報提供」ではありません。テナントの保護動作を変更するセキュリティ設定です。
AllowにしてもSafe Links形式のURLが消えるとは限らない
Tenant Allow/Block ListのURL許可は、URLに関連する検査結果を上書きしますが、Safe LinksによるURLの書き換え自体を必ず停止するものではありません。
そのため、リンクがSafe Links形式のURLとして表示されていても、許可が失敗しているとは限りません。反対に、URLが書き換えられていないからといって、安全性が保証されたわけでもありません。([Microsoft Learn][3])
Allow this URLを選ぶ判断基準
次の条件をすべて満たせない場合は、分析提出だけにとどめます。
- サイトの管理者またはサービス提供元にURLを確認できた
- ドメインだけでなく、パスやリダイレクト先も確認できた
- 不審なログイン画面やファイル配布がない
- URLが業務上必要であることを説明できる
- 業務影響が大きく、Microsoftの分析結果を待てない
- 許可するURLの範囲を必要最小限にできる
- 有効期限を設定できる
- 変更責任者と削除予定日を記録できる
一つでも確認できない場合は、It appears cleanとして分析を依頼し、許可エントリは作成しないのが安全です。
Tenant Allow/Block Listはユーザー単位の許可ではない
Tenant Allow/Block Listは、その名前のとおりテナント単位で管理されるリストです。特定の利用者だけに許可するための機能ではありません。
したがって、「影響を受けた利用者が1人だけだから、この人だけ許可する」という設定はできません。影響範囲を抑えるには、次の3点を絞ります。
- 許可するURL
- 許可するパス
- 許可する期間
利用者を限定できない分、URLの指定範囲を広げすぎないことが重要です。
ドメイン全体ではなく、必要なパスを指定する
次のような広い許可は避けます。
https://example.jp/*業務上必要なのが特定の画面だけなら、より具体的なURLを提出します。
https://example.jp/customer/loginTenant Allow/Block Listでは、許可エントリにサブパスが自動的に含まれるとは限りません。たとえば、example.jpを許可しても、example.jp/accountまで同じ条件で許可されるとは限らないため、実際にブロックされたURLを基準に指定します。Microsoftは、可能な場合にはリダイレクト先も含めて確認するよう案内しています。([Microsoft Learn][3])
「業務ドメインだから丸ごと許可」は危険
ドメイン全体を許可すると、将来そのサイト内に作成された別ページや、侵害されたページまで許可対象に含まれる可能性があります。
特に次のようなサイトは、広範囲の許可を避けるべきです。
- 利用者がファイルをアップロードできるサイト
- 外部ユーザーがページを作成できるサービス
- URL短縮サービス
- クラウドストレージの共有URL
- 複数企業が同じドメインを利用するSaaS
- リダイレクト用URLを発行するサービス
URL許可を定常的な問い合わせ処理にしてしまうと、Tenant Allow/Block Listが例外設定だらけになります。「問い合わせが来たら許可する」ではなく、「安全性を確認し、Microsoftへ提出し、必要なときだけ一時許可する」という順序を標準手順にします。
許可期限は最短にする
Microsoftの案内では、URLの許可エントリについて、次のような期限を選択できます。
- 1日
- 7日
- 30日
- 特定の日付
- 既定の条件による自動削除
既定では、フィルタリングシステムが対象を安全と判断してから一定期間保持される方式が使われます。明確な終了日がある暫定対応では、既定値のままにせず、具体的な期限を指定した方が管理しやすくなります。([Microsoft Learn][2])
判断例は次のとおりです。
| 業務状況 | 期限の目安 |
|---|---|
| 当日の作業だけを継続させたい | 1日 |
| Microsoftの分析結果を待つ間の暫定対応 | 1日または7日 |
| システム改修やURL変更まで時間が必要 | 必要日数を確認し、7日または特定日 |
| 終了時期が分からない | 無期限にせず、短い期限で定期再確認 |
「あとで削除する」という運用は、担当者の異動や引き継ぎ漏れで残り続ける原因になります。原則として、作成時点で期限を設定してください。
Allow entry noteに残す内容
Allow this URLを選択した場合は、任意の注記欄に少なくとも次の内容を記載します。
業務システムの正規URLであることを管理者へ確認済み。
Microsoftへの再評価依頼中。
インシデント番号: INC-2026-0919-01
変更責任者: 情報システム担当
期限到来前に再確認する。パスワード、個人情報、秘密鍵、認証トークンなどは入力しないでください。
提出結果を確認する
URLを提出したら、送信して終わりにせず、Microsoftの分析結果を確認します。
- Microsoft Defenderポータルを開く
Actions & submissionsからSubmissionsを開くURLsタブを選択するPendingまたはCompletedで絞り込む- 該当するURLを選択する
StatusとResultを確認する- Submission IDを社内記録へ保存する
URL提出の詳細画面では、提出ステータスと結果を確認できます。結果には、ブロックすべきだったか、ブロックすべきではなかったかといった判定が表示される場合があります。([Microsoft Learn][2])
結果が「安全」でも再確認する
Microsoftから問題なしと判定された場合も、次の点を確認します。
- 影響を受けた利用者の環境で警告が解消したか
- 元メールから開いた場合に正常に遷移するか
- リダイレクト後のURLが想定どおりか
- 同じドメインの別URLまで意図せず許可されていないか
- 暫定的な許可エントリを残す必要があるか
Microsoft側の判定が修正され、通常の検査でアクセスできるようになった場合は、暫定許可を削除します。
Tenant Allow/Block Listを確認する
Allow this URLを選択した場合は、Tenant Allow/Block ListのURLsタブに許可エントリが作成されます。
確認すべき主な項目は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| Value | 許可したURLが正しいか |
| Action | Allowになっているか |
| Override verdicts | どの判定まで上書きするか |
| Modified by | 誰が変更したか |
| Last updated | 最終更新日時 |
| Last used date | 実際に許可処理で使われた日時 |
| Remove on | 削除予定日 |
| Notes | 対応理由や管理番号 |
Microsoft Defenderポータルでは、URLエントリについて、変更者、最終更新日、最終使用日、削除予定日、注記などを確認できます。([Microsoft Learn][3])
不要になった許可エントリを削除する
暫定許可が不要になったら、次の手順で削除します。
- Microsoft Defenderポータルを開く
Email & collaborationを開くPolicies & rulesを選択するThreat policiesを開くTenant Allow/Block Listsを選択するURLsタブを開く- 対象エントリを選択する
Deleteを選択する- 警告画面で削除を確定する
複数の許可エントリを一括削除する場合は、対象URLを取り違えないよう、Value、Action、Notes、Remove onを確認してから実行します。([Microsoft Learn][3])
「Do not rewrite」とURL許可を混同しない
Safe Linksポリシーには、URLを書き換えないためのリストがあります。しかし、これはTenant Allow/Block ListのURL許可とは目的が異なります。
| 設定 | 主な目的 | 誤検知解除との関係 |
|---|---|---|
| Do not rewrite the following URLs | Safe LinksによるURLの書き換えを抑える | クリック時にブロックされる可能性が残る |
| Tenant Allow/Block ListのAllow | URL判定を上書きしてアクセスを許可する | URLベースの保護を迂回する効果がある |
| MicrosoftへのURL提出 | Microsoftに評価の見直しを依頼する | 恒久的な誤検知修正につながる可能性がある |
「URLが長く書き換えられて見づらい」という問題と、「危険なURLとしてブロックされた」という問題は分けて考えます。
Microsoftは、Safe Linksの書き換え除外リストへ登録したURLでも、クリック時にブロックされる可能性があると説明しています。また、Tenant Allow/Block Listで許可しても、URLの書き換えが停止するとは限りません。([Microsoft Learn][1])
必要な管理者権限を確認する
Submissionsページの利用やTenant Allow/Block Listの変更には、適切な権限が必要です。
環境によっては、次のようなロールが関係します。
- Security Administrator
- Security Reader
- Organization Management
- Security Operator
- Microsoft Defender XDRの統合RBACで割り当てられた権限
閲覧権限だけでは、許可エントリの追加や削除ができない場合があります。また、Microsoft Defender XDRの統合RBACを有効にしている環境では、従来のロールと実際の操作権限が異なることがあります。
グローバル管理者を日常的なURL提出作業に使うのではなく、必要最小限の権限を割り当てるのが適切です。Microsoftも、Global Administratorは緊急時などに限定し、最小権限の原則を採用するよう案内しています。([Microsoft Learn][2])
よくある失敗と対策
Safe Links全体を一時的に無効化する
1件の誤検知を解消するためにSafe Links全体を無効化すると、他の利用者やメールに含まれる不正URLへの保護まで停止します。
対策: URL提出を行い、必要な場合だけ対象URLを一時許可します。
安全確認前にAllow this URLを選ぶ
業務サイトに見えるという理由だけで許可すると、侵害済みサイトや偽装URLを通してしまう可能性があります。
対策: 安全性を断定できない場合はIt appears cleanを選び、分析のみを依頼します。
ドメイン全体を許可する
特定ページの誤検知に対してドメイン全体を許可すると、許可範囲が必要以上に広がります。
対策: 実際にブロックされたURLとパスを基準に、最小限の範囲を指定します。
許可期限を設定しない
暫定対応のつもりでも、担当者が削除を忘れると恒久的な例外設定になります。
対策: 1日、7日、特定日などの期限を設定し、削除予定日を変更管理へ登録します。
Microsoftへの提出だけで直ったと思い込む
URLを提出しても、直ちに利用者の警告が解消するとは限りません。
対策: SubmissionsのStatusとResultを確認し、実際の利用環境でも再確認します。
URL許可を安全性の証明として扱う
Tenant Allow/Block ListのAllowは、管理者が保護機能を上書きした結果です。MicrosoftがURLの安全性を保証したことを意味しません。
対策: 許可した理由、確認者、確認方法、期限を必ず記録します。
URL誤検知対応の記録テンプレート
実務では、次の項目をチケットや変更管理台帳へ残しておくと、後日の見直しが容易になります。
受付番号:
発生日時:
利用者:
対象URL:
元メールの件名:
送信者:
警告内容:
業務上の用途:
サイト管理者への確認:
リダイレクト先の確認:
セキュリティ確認結果:
Microsoftへの提出日時:
Submission ID:
提出区分:
Microsoftの分析結果:
Allow this URLの有無:
許可したURL範囲:
許可期限:
変更実施者:
承認者:
再確認日:
削除日時:
最終確認結果:特に、Submission ID、許可期限、変更実施者、削除日時の4項目は省略しないようにします。
Safe Linksを無効化せずに誤検知を解消する流れ
業務サイトへのリンクがSafe Linksで危険扱いされた場合は、次の順序で対応します。
- 発生時刻、利用者、対象URL、元メール、警告画面を保存する
- サイト管理者やセキュリティ担当者がURLの安全性を確認する
- Defenderポータルの
Actions & submissionsからURLをMicrosoftへ提出する - 安全性を断定できない場合は
It appears cleanとして分析のみを依頼する - 安全性を確認済みで緊急性が高い場合だけ
Allow this URLを検討する - URL範囲、期限、変更責任者を記録する
- SubmissionsでMicrosoftの分析結果を確認する
- Tenant Allow/Block Listに不要な許可が残っていないか確認する
- 暫定許可が不要になった時点で削除する
Safe Linksの誤検知対応では、「アクセスできるようにすること」だけを目的にしてはいけません。Microsoftへの再評価依頼と、テナント内の一時的な許可を分けて管理することが、業務継続とセキュリティを両立させるポイントです。
[1]: https://learn.microsoft.com/en-us/defender-office-365/safe-links-about “Complete Safe Links overview for Microsoft Defender for Office 365 – Microsoft Defender for Office 365 | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/defender-office-365/submissions-admin “Submit messages, URLs, and attachments for analysis in the Microsoft Defender portal – Microsoft Defender for Office 365 | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-urls-configure “Allow or block URLs using the Tenant Allow/Block List – Microsoft Defender for Office 365 | Microsoft Learn”
コメント