「VPNを入れているから安全」——この認識のままで進んでいる企業が、今もたくさんあります。
VPNは「社内ネットワークへのトンネル」を作りますが、そのトンネルに入ったら何でも信頼する、という設計が前提です。攻撃者が一度VPN認証情報を手に入れてしまえば、社内ネットワークを横断されます。実際、国内の大規模侵害事案でVPN起点のものが相次いでいることを考えると、「トンネルの中は安全」という前提の危うさが分かります。
この記事では、ゼロトラストという概念の定義から、情シス担当者が実務で動かせるレベルの「最初の90日チェックリスト」まで整理します。
ゼロトラストとは——「信頼を仮定しない」設計への転換
ゼロトラスト（Zero Trust）は、NIST SP 800-207で定義されている考え方で、「ネットワークの内側だからといって自動的に信頼しない」という原則に基づくセキュリティアーキテクチャです。
「何も信頼しない、常に確認する（Never Trust, Always Verify）」という一言で説明されることが多いですが、実務的に重要なのは以下の3原則です。
| 原則 | 意味 | 実装のキーポイント |
|---|---|---|
| 最小権限 | ユーザー・デバイス・アプリに必要最小限のアクセス権のみ付与 | IDaaSのRBAC・条件付きアクセスポリシー |
| 継続的な検証 | 一度認証したら終わりではなく、アクセスのたびに再評価 | リスクベース認証・セッション管理 |
| 侵害を前提とした設計 | 内部ネットワークも信頼しない。被害を最小化する横断対策 | マイクロセグメンテーション・ログ監視 |
「ゼロトラストに完全移行する」というのは一度に達成するものではありません。既存のVPN・ActiveDirectory環境から段階的に移行していく「改善の旅」と捉えるのが実務的には正確です。
最初の90日チェックリスト——3フェーズで進める
完璧を目指して動けないよりも、小さく始めて測定しながら改善する方が重要です。以下の3フェーズを目安にしてください。
Phase 1（Day 1〜30）: IDと認証の強化
ゼロトラストの土台は「誰が・何に・どこからアクセスしているか」を把握することです。最初の1ヶ月はここに集中します。
必須アクション
□ 全ユーザーへのMFA（多要素認証）強制を設定する → Microsoft Entra ID（旧Azure AD）/ Okta 等の条件付きアクセスポリシーで実施 □ 退職者・休職者アカウントの無効化フローを整備する → 「退職翌日まで有効」を「退職日当日に無効化」へ。属人的なフローは廃止 □ 特権アカウント（管理者権限）の棚卸しを実施する → 実際に使われていない管理者権限を削除。PIM（特権ID管理）の設計を検討 □ IDaaS からのサインインログを確認できる状態にする → まず「見える状態」を作ることが最優先
パスワードを付箋でモニターに貼る文化と戦ってきた身としては、MFA強制は最大の即効策です。実装後の認証成功率・拒否ログを週次で確認するフローをこのフェーズで作ってしまいましょう。
【関連記事】IDとデバイスの認証強化に関しては、パスキー実装の観点からも整理しています。
Phase 2（Day 31〜60）: デバイスコンプライアンスの導入
「認証した人」だけでなく「認証したデバイスが安全か」を確認する段階です。
必須アクション
□ MDM（Mobile Device Management）/ EDR の導入・設定 → Microsoft Intune / Jamf 等でデバイスコンプライアンスポリシーを設定 □ 条件付きアクセスポリシーに「準拠デバイスのみ許可」を追加 → 未登録デバイスからのアクセスをブロック □ OS・アプリのパッチ適用状況を自動チェック → コンプライアンス非適合デバイスをポリシーで弾く設計 □ BYODポリシーの見直し（または廃止検討） → 個人デバイスを業務利用させる場合のリスクと管理コストを整理
「Intune入れたけど条件付きアクセスには繋げてない」という状態は、測定できているが管理に繋がっていない典型です。このフェーズで「デバイスの状態が認証に影響する」設計へ移行します。
Phase 3（Day 61〜90）: ネットワーク・アプリアクセスの最適化
VPNに依存しない、アプリケーション単位のアクセス制御へ移行するフェーズです。
必須アクション
□ アプリケーション単位のアクセスポリシーを設計 → Microsoft Entra Application Proxy / ZTNA ソリューション（Zscaler Private Access等）の検討 □ 社内に直接VPNで入る必要があるシステム・サービスの棚卸し → VPN不要に移行できるアプリと、残さざるを得ないシステムの分類 □ マイクロセグメンテーションの設計（長期計画） → 即時実装は難しいが、設計書レベルで方針を決める □ ログの一元管理（SIEM連携）の準備 → IDaaS・EDR・アプリゲートウェイのログを集約する基盤設計
Phase 3はゴールではなく「継続的改善の起点」です。90日で完成するものではなく、この段階から「測定→改善」のサイクルを回せる状態を作ることがポイントです。
よくある質問（FAQ）
Q: ゼロトラスト移行には莫大なコストがかかるのか？
A: 全部一度にやろうとすればそうなります。ただし、Phase 1（MFA強制・退職者アカウント管理）は既存のIDaaSで追加コストゼロまたは最小限で実施できます。まず「認証の強化」から着手し、投資対効果を測定しながら段階的に拡張する設計が現実的です。
Q: VPNはすぐに廃止すべきか？
A: すぐに廃止する必要はありません。既存のVPNを段階的にゼロトラストネットワークアクセス（ZTNA）に置き換えていくのが一般的です。VPNへのMFA強制・ログ監視を追加しながら、並行してZTNAの設計を進めることをお勧めします。
Q: SMBや中小企業でもゼロトラストは現実的か？
A: Microsoft 365 BusinessやGoogle Workspaceには、ゼロトラストの基本要素（MFA・条件付きアクセス・デバイスコンプライアンス）が含まれています。大企業専用のアーキテクチャではなく、既存SaaSを活用した「ゼロトラスト設計の考え方」は規模を問わず適用できます。
Q: 「ゼロトラスト製品」を購入すれば移行完了か？
A: 製品を買うだけでは移行になりません。ゼロトラストはアーキテクチャの考え方であり、製品は手段です。「誰が・何に・どこからアクセスするか」のポリシーを設計し、運用フローを整備することが本質です。
まとめ——完璧より継続
ゼロトラスト移行で最も避けたいのは、「完璧な設計ができるまで動かない」状態です。
最初の90日で目指すのは「完全なゼロトラスト」ではなく、「VPN依存からの脱却の起点」です。MFA強制だけでも、退職者アカウント即日無効化だけでも、攻撃を防ぐ確率は大きく上がります。
「人間のついうっかり」に頼らず、仕組みで守る。その第一歩として、Phase 1の4アクションから始めてみてください。
【関連記事】DLPとIDaaSを組み合わせた情報保護の設計はこちらで整理しています。
参考情報
- NIST SP 800-207「Zero Trust Architecture」（確認日：2026-06-08）
- Microsoft「ゼロトラストの原則」公式ドキュメント
- IPA「中小企業の情報セキュリティ対策ガイドライン 第3.1版」
