境界型防御における送信元IP制限運用を、ゼロトラストで主役にしてはいけない
ゼロトラストとSASEの時代に、IP制限をどう残すか
恐縮です。
ゼロトラストとSASEの時代に、IP制限をどう残すか
はっきり言います。
送信元IP制限を、ユーザ認証の主役に置く時代はもう苦しいです。
昔はそれで回りました。
社内LAN、拠点回線、VPN終端、データセンター出口。
「どこから来た通信か」が、ある程度そのまま「どの組織の管理下か」を表していたからです。
しかし今は違います。
リモートワーク、BYOD、モバイル回線、SaaS、SASE。
通信の出口は揺れます。
働く場所も揺れます。
この状況で、送信元IPを本人確認の土台にすると、現場は必ず苦しくなる。ここが出発点です。
NISTは、ゼロトラストを**「ネットワークの場所だけでは暗黙に信頼しない」前提で整理しています。CISAも、ゼロトラストをlocation-centric から more data-centric への転換と明確に表現しています。つまり、世界の標準はもう、“場所を信頼の中心に置かない”**ところまで来ています。
参考：※1、※2。
ただし、ここで雑に
「IP制限はもう古い。全廃だ」
と言うと、それはそれで現場を壊します。
なぜか。
現実のSaaSや業務アプリには、今でもIP許可リストが残っているからです。Microsoft Entra Global Secure Access も、現時点で source IP anchoring を提供しています。これは、IP制限が消えたからではなく、まだ相手アプリ側がIPを要求してくる現実があるからです。
だから結論はシンプルです。
IP制限はなくならない。
ただし、役割が変わる。
これからのIP制限は、認証の主役ではなく、
相手アプリに合わせるための互換性制御に下がっていく。
ここを整理できるかどうかで、SASE導入の成否はかなり変わります。
参考：※3。
送信元IP制限は、なぜここまで広まったのか
送信元IP制限は、もともと筋の悪い仕組みではありませんでした。
むしろ、境界型防御の時代には合理的でした。
社内と社外を分ける。
社内ネットワークは比較的信用する。
社外からのアクセスは厳しく見る。
この設計では、IPは「内か外か」を切るための、安くて分かりやすい境界だったわけです。
IPAも、従来のセキュリティ対策は境界型防御が主流であり、社内を「信用できる領域」、社外を「信用できない領域」として扱ってきた、と整理しています。つまり送信元IP制限は、当時の前提では十分に現実的な制御でした。
参考：※4。
その時代の判断軸は単純です。
社内から来たなら通す。
社外から来たなら止める。
この割り切りは、拠点が固定され、回線が固定され、出口が固定されていた時代には強かった。
ところが今は、働く場所も出口も固定されません。
前提が崩れたのに、判定ロジックだけ昔のまま残っている。
だから、送信元IP制限がだんだん苦しくなってきたのです。
世界のトレンドと、日本の立ち位置
世界の流れは、かなりはっきりしています。
NISTは、ゼロトラストを静的なネットワーク境界から、ユーザ・資産・リソース中心へ防御を移す考え方として説明しています。さらに、物理的な場所やネットワーク上の場所だけで、ユーザや資産に暗黙の信頼を与えないとしています。Google BeyondCorpも、ネットワーク境界の制御をユーザー単位へ移し、VPN前提ではなく、どこからでも安全に働ける方向を示しています。
参考：※1、※5。
CISAの言い方も明快です。
ゼロトラストは、場所中心からデータ中心への転換です。
ここで言いたいのは、「ネットワークを無視する」という話ではありません。
ネットワークは補助情報になるが、信頼の主役ではなくなるということです。
参考：※2。
では、日本は遅れているのか。
私はそうは見ていません。
思想は同じ方向です。
ただし、現場が移行期にある。これが実態です。
デジタル庁は2022年に**「ゼロトラストアーキテクチャ適用方針」を公開しています。さらに、2026年3月31日更新の「国・地方ネットワーク」では、2030年頃の将来像として、セキュリティを確保しつつ、一人一台のPCで効率的に業務ができ、テレワーク等の柔軟な働き方が可能になることを掲げています。政策レベルでは、日本ももう“場所で縛る”より、“どこでも安全に使う”**方向へ動いています。
参考：※6、※7。
では、なぜ日本の現場ではまだIP制限が色濃く残るのか。
答えは簡単で、アプリと運用の都合です。
多くのSaaSや業務システムは、いまだにIP許可リストを持っています。
だからこそMicrosoftも、source IP anchoring を提供している。
つまり日本は、ゼロトラストを理解していないのではなく、ゼロトラストへ移る途中で、レガシーな接続要件をまだ大量に抱えているのです。ここを感情で否定しても進みません。現場は現場で、つなぎながら変えるしかない。
参考：※3。
何がいけないのか──IPを認証に使うと運用が壊れる
本質的な問題は一つです。
IPは「本人」ではなく、「ただの出口」にすぎないということです。
自宅回線、出張先Wi-Fi、モバイル回線、委託先ネットワーク。
人が同じでも、出口IPは変わります。
つまり送信元IPで見ているのは、その人自身ではなく、その瞬間にどこから出てきたかです。
Microsoftの条件付きアクセスでも、ネットワークの場所は他の条件と組み合わせて使うシグナルとして扱われています。しかも条件付きアクセスは、第1要素認証が終わったあとに適用されると明記されています。ここが重要です。
少なくともEntraの設計思想では、ネットワークは認証の本体ではない。
最初から主役ではなく、補助条件です。
参考：※8。
だから、送信元IPでユーザ認証しようとすると、現場では何が起きるか。
例外申請が増える。
VPN強制が増える。
出口を合わせる作業が増える。
回線変更のたびに運用が増える。
気が付くと、セキュリティを強くする仕事ではなく、
「場所合わせ」を成立させる仕事が増えていきます。
ここが現場では本当に重い。
しかも重いだけではありません。
ゼロトラストの思想とも真っ向からぶつかります。
NISTは、ゼロトラストをremote users、BYOD、cloud-based assets といった企業ネットワークの変化への応答として説明しています。つまり、アクセス判断は場所そのものではなく、誰が、どの端末で、どの条件でアクセスしているかへ移していくべきだ、という話です。
参考：※1。
さらに、SASE/SSEを通すと、下流サービスから見えるIPはユーザ固有の元IPではなく、クラウドプロキシや既知のエグレスIPに見えることがあります。Microsoftが source IP restoration を用意しているのは、元のエグレスIPを保持して、条件付きアクセスやリスク検出、サインインログの精度を保つ必要があるからです。
ここから分かるのは、固定IP化は接続互換には効くが、本人確認や監査の正確性まで自動で解決するわけではないということです。
参考：※3、※9。
では、何を認証の軸に置くべきか
ここは迷ってはいけません。
順番をはっきり分けるべきです。
①認証の主役はIDです。
②ただ、端末の信頼はデバイス状態で見ます。
③認可はアプリ条件・セッション制御で詰めます。
④IPは最後に補助で使います。★これ重要
この線引きができると、設計が一気に整理されます。
まず、例えばユーザ認証は Entra ID / IdP + MFA です。
「誰なのか」はここで確かめる。
場所ではなく、IDで見る。これが基本です。
次に、端末信頼です。
ここで Intune が出てきます。
ただし、ここも言い方を正しておいた方がいい。
Intune登録済みデバイスは、ユーザ認証そのものではありません。
あくまで、その端末を業務アクセスに使わせてよいかを見るための材料です。
Microsoftは条件付きアクセスで Require device to be marked as compliant を明示しており、少なくとも実務上は、「登録済み」より「準拠デバイス」まで見る設計の方が強いです。
参考：※8、※10。
ここで現場がやりがちな失敗があります。
それは、「会社のIPから来たら通す」と「会社が管理した端末なら通す」を混同することです。
この二つは全然違います。
会社のIPから来ている
会社が信頼できる状態の端末である
前者は場所です。
後者は端末状態です。
ゼロトラストで見るべきなのは、後者です。
SASE時代に、IP制限はどう残すべきか
ここがいちばん大事です。
IP制限は残していい。
ただし、残し方を間違えてはいけない。
残すべきなのは、こういうケースです。
SaaS側がIP許可リストしか持っていない
レガシー業務アプリが固定出口IPを要求する
管理画面やAPI接続元を限定したい
取引先要件として固定IP提出が必要
バッチ連携や特定経路だけ出口を固定したい
このとき、SASE側の固定IPや source IP anchoring は十分に有効です。
Microsoftも、source IP anchoring を**「SaaSアプリに既知のエグレスIPを見せる」**ための機能として案内しています。
つまり、SASE側で持つIPを使うIP制限は、今後も実行可能であり、有効性もある。ここは否定しなくていい。
参考：※3。
ただし、その意味付けが重要です。
これは本人確認ではありません。
これは接続互換のための制御です。
この役割分担を崩した瞬間、設計はまた昔に戻ります。
SASEを入れたのに、結局やっていることが
「クラウド時代の境界型防御」
になってしまう。
一方、Microsoftは 準拠ネットワークチェック も案内しており、これによりエグレスIPアドレスの一覧を維持せずにアクセス制御を管理できること、さらにIPベース条件付きアクセスのためにVPN経由でヘアピンさせる必要を排除できることを示しています。つまり、IPを残すなら残す、減らせるなら減らすという選択肢も、もうベンダー側で用意されているわけです。
参考：※11。
結論はここです。
認証は ID / MFA へ。
端末信頼は Intune 準拠へ。
認可は アプリ条件・セッション制御・DLP へ。
それでも残るIP制限は、SASEの固定IPで吸収する。
この順番に直す。
これが、ゼロトラストとSASEの時代に現場で回る設計です。
現場での判断軸
最後に、実務担当者向けに判断軸を置いておきます。
そのIP制限は、「本人確認」のためなのか。
それとも、「相手アプリ互換」のためなのか。
ここをまず分ける。
ここが曖昧だと、全部崩れます。
次に、こう見てください。
人が日常的に使うSaaSなら、IP制限を認証の主役にしない。
テレワークが前提なら、場所で縛りすぎない。
例外申請が増えているなら、それは設計が苦しいサイン。
SASEの固定IPを使うなら、IdP・SASE・アプリのログ突合まで考える。
要するに、
「通せるかどうか」ではなく、
「何を信頼根拠にして通しているのか」
を見直すべきなのです。
まとめ
送信元IP制限は、境界型防御の時代には合理的でした。
しかし、ゼロトラストとSASEの時代に、それをユーザ認証の軸にしてしまうと、場所の制約が運用を壊します。
だから、設計の主役を戻すべきです。
認証はIDとMFA。
端末信頼はIntune準拠(あるいは近いことを実現できるソリューション)。
認可はアプリ条件。
それでも残るIP制限は、SASEの固定IPで吸収する。
ここまで整理できると、IP制限は「悪」ではなくなります。
ただの脇役になります。
しかも、その脇役はまだ当分必要です。
ただし、主役にしてはいけない。
この線引きが、日本の現場では決定的に重要です。
送信元IP制限の未来は、消滅ではありません。
格下げです。
認証の主役から降ろし、互換性のための補助統制として残す。
この整理ができた組織から、SASEはちゃんと機能します。
恐縮でした。
【補足】
記事内の※番号は、以下の公式情報に対応しています。NISTはゼロトラストを静的なネットワーク境界からユーザ・資産・リソース中心へ移す考え方とし、物理的またはネットワーク上の場所だけで暗黙に信頼しないと明記しています。CISAは、ゼロトラストをlocation-centric から more data-centric への転換と整理しています。
Microsoft Entra の条件付きアクセスでは、ネットワークはシグナルとして扱われ、条件付きアクセスは第1要素認証の完了後に適用されます。さらに、Require device to be marked as compliant が明示されており、source IP anchoring はSaaS側に既知のエグレスIPを見せるための機能として案内されています。
Microsoft は source IP restoration によって、条件付きアクセスのIPベースポリシー、リスク検出、サインインログの正確なソースIP記録を支援すると説明しています。また、Compliant Network Check により、エグレスIP一覧の維持やVPNヘアピンを減らせると案内しています。
日本ではデジタル庁が2022年にゼロトラストアーキテクチャ適用方針を公開しており、2026年3月31日更新の「国・地方ネットワーク」では、2030年頃の将来像として、一人一台PCで効率的に業務ができ、テレワーク等の柔軟な働き方が可能になることを掲げています。IPAも、従来は境界型防御が主流だったと整理しています。Google BeyondCorp は、ネットワーク境界で行っていた制御をユーザー単位へ移し、VPN前提ではなくどこからでも安全に働ける方向を示しています。
※1 NIST SP 800-207 Zero Trust Architecture
※2 CISA Zero Trust Maturity Model
※3 Microsoft Entra Global Secure Access - Source IP Anchoring
※4 IPA ゼロトラストという戦術の使い方
※5 Google BeyondCorp
※6 デジタル庁 サイバーセキュリティ
※7 デジタル庁 国・地方ネットワーク
※8 Microsoft Entra 条件付きアクセス - ネットワーク信号の使用
※9 Microsoft Entra Global Secure Access - Source IP Restoration
※10 Microsoft Entra 条件付きアクセス - Require device to be marked as compliant
※11 Microsoft Entra Global Secure Access - Compliant Network Check
