VPN依存の境界型ネットワークセキュリティから脱却し、BeyondCorp Enterprise ベースのゼロトラスト移行を進める組織では、どのタイミングでVPNを止めるかが実務上の課題になります。この記事では、100名規模の組織を想定し、VPN段階廃止のフェーズ設計と各フェーズの判断基準を整理します。
この記事を読んだほうが良い人
- VPNのリース・ライセンス更新を控えており、ゼロトラスト移行を検討している情シス担当者
- BeyondCorp Enterprise の導入を始めているが、VPNをいつ止めるか判断の軸が定まっていない方
- 「段階移行で進める」と決めているものの、フェーズの区切りと完了条件を整理できていない方
BeyondCorp Enterprise とゼロトラスト移行の前提
BeyondCorp Enterprise は「ネットワーク内にいるから安全」という境界型セキュリティの前提を解体し、「誰が・どのデバイスで・どんな状態からアクセスしているか」を毎回評価するモデルです。Google が自社の内部インフラに10年以上適用してきた手法を企業向けにパッケージ化したもので、数万人規模のVPNを段階廃止した実績が公式技術論文・ブログに記録されています。3つの機能柱はそれぞれ以下の役割を持ちます。
- Context-Aware Access (CAA): Google Workspace コアアプリや SAML/OIDC 連携アプリへのアクセスを、ユーザーのデバイス状態・IPアドレス・場所などのコンテキストで動的に制御する
- Endpoint Verification (EV): デバイスのOSバージョン・暗号化状況・管理登録の有無などをシグナルとして収集し、CAA の条件評価に使う
- Identity-Aware Proxy (IAP): Google Cloud 上のWebアプリや仮想マシンへのアクセスを、VPN不要で制御する Google Cloud の機能
3つの機能には依存関係があります。EV が未展開のままでは CAA の条件評価の精度が下がり、IAP は Web アプリに限定された入り口制御にとどまります。EV → CAA → IAP の順で整備を進めるのが標準的な進め方です。
なお、BeyondCorp Enterprise の機能は現在 Chrome Enterprise Premium として統合・展開されています（旧称: BeyondCorp Enterprise）。本記事では引き続き「BeyondCorp Enterprise」という呼称で統一します。
VPN廃止前の移行可否チェックリスト
フェーズを進み始める前に、以下の項目を確認しておくと後工程でのつまずきを減らせます。
- [ ] Endpoint Verification が全デバイスに展開できるエディション・ライセンスが揃っているか
- [ ] VPN機器のログからセッション単位の接続元・接続先・時刻が取得できるか
- [ ] 管理外デバイス（派遣・業務委託の個人端末）向けのアクセスポリシーを別途定義できるか
- [ ] Chrome ブラウザが主体で業務できる環境か（Internet Explorer / Edge レガシー依存アプリが残っていないか）
- [ ] オンプレリソースの棚卸しに必要な担当者やベンダーと連携できる体制があるか
- [ ] フェーズ完了の判断権限が情シス内で明確になっているか、または経営層との承認フローが設計済みか
このチェックリストは「未対応があれば着手しない」という性質のものではありません。「未対応のまま進むと、どの工程でどのくらいのリスクが発生するか」を先読みするための確認です。たとえば「管理外デバイスのポリシーが未定」であれば、Phase 1 のドライラン中に現場から例外申請が殺到するリスクを事前に把握して、担当者を先手で動かせます。
VPN廃止を段階移行で設計する3フェーズ
VPN廃止を一気に進めようとすると、EV未展開デバイスの一斉ロックアウトや想定外のアプリ依存の発覚で緊急ロールバックが発生します。3つのフェーズゲートを設けて段階的に進めることを推奨します。
Phase 1：可視化と基盤整備（目安 1〜3ヶ月）
この段階では、「VPNを止めるための条件が揃っているか」を確認することに集中します。移行アクションそのものはまだ行いません。
主な作業
- 全ユーザーのデバイスに Endpoint Verification を展開し、デバイスポスチャーの収集を開始する
- CAA をモニタリングモード（ドライラン）で動かし、本番適用した場合にブロックされるシナリオを洗い出す
- VPN経由で使われているアプリ・リソースを一覧化し、IAP移行可能なWebアプリとそうでないオンプレリソースに分類する
- 組織外ユーザー（派遣・業務委託）のデバイスが EV の管理要件を満たすか確認する
VPN接続ログの分析では、「人が手動で使うセッション」だけでなく、CI/CDパイプラインや夜間バッチ処理のような自動化されたVPN依存も含めて棚卸しします。接続元IPと時間帯で絞り込むと、業務時間外の定時アクセスがサービスアカウントやジョブスケジューラーからのものと特定しやすくなります。この分析を Phase 1 でやり切らないと、Phase 3 の廃止宣言後に「基幹バッチが止まった」という障害につながります。
VPN経由リソースの分類観点として、以下の表が整理の起点になります。
| リソース種別 | 例 | CAA/IAP移行可否 | 着手優先度 |
|---|---|---|---|
| Google Workspace コアアプリ | Gmail / Drive / Meet | CAA で制御可 | 最高 |
| SAML/OIDC 連携 SaaS | 勤怠・経費精算ツール等 | CAA で制御可 | 高 |
| 社内 Web アプリ（Google Cloud ホスト） | 社内ポータル・Wiki | IAP で制御可 | 中 |
| 社内 Web アプリ（オンプレ） | レガシー業務システム | コネクタ経由で対応可能（要件確認） | 中〜低 |
| 非HTTPリソース | SMBファイルサーバー・LDAP | CAA / IAP では直接制御不可 | 最後 |
Phase 1 の完了条件（参考目安）
| 指標 | 目安 |
|---|---|
| EV 展開率 | 全デバイスの 80% 以上 |
| CAA ドライランの想定外ブロック | 30日間連続でゼロ件 |
| VPN経由アプリの棚卸し | 一覧作成と移行可否の分類完了 |
この参考目安は組織規模や業務特性によって調整が必要です。重要なのは具体的な数値より、「経営層・現場と事前合意する」という行為そのものです。
Phase 2：VPN依存の段階的縮小（目安 3〜6ヶ月）
Phase 1 のデータをもとに、アプリ単位でVPN経由アクセスをゼロトラスト経路に切り替えていきます。優先順序の考え方は以下の通りです。
- SaaS・Google Workspace アプリ（最初に着手）: CAA アクセスレベルをモニタリングから本番適用に切り替える。Phase 1 のドライランで影響範囲が可視化済みのため最もリスクが低い
- 社内Webアプリ（Google Cloud ホスト）: IAP を前面に設置し、VPN経由のアクセスを段階的に遮断する
- オンプレミスのファイルサーバー・プリンターなど（最後）: CAA / IAP では直接制御できないため、Google の提供するコネクター機能（IAP Connector / App Connector）や別途の代替アクセス経路の整備が必要になる
「VPNセッション占有率」の算出には、VPN機器のセッションログから総接続数を抽出し、ゼロトラスト経路へ移行済みのアプリへの接続数の割合で逆算します。機器によってはセッション単位の詳細ログが出ないケースもあるため、Phase 1 の段階で計測方法を確認しておく必要があります。正確な計測が難しい場合でも、「移行完了済みアプリ一覧の完成度」を代替指標として使うことで、進捗の可視化は可能です。
Phase 2 の完了条件（参考目安）
| 指標 | 目安 |
|---|---|
| VPN セッション占有率 | 全接続セッションの 20% 以下 |
| 残存VPN接続の用途特定 | 全件の用途が特定済み |
| EV 展開率 | 95% 以上 |
Phase 2 では「VPN依存の切り替えが完了したアプリ」と「まだVPN経由が残るアプリ」のリストを常に最新化しておくことが重要です。この状態管理を怠ると、Phase 3 の廃止宣言後に想定外の接続切れが発生したとき、原因の特定に時間がかかります。
Phase 3：VPN完全廃止（6ヶ月以降）
Phase 2 の残存VPN接続が全件特定・代替済みになったタイミングで廃止宣言をします。廃止後も「緊急時の一時接続手段」を残すかどうかはポリシー判断で、残す場合は以下の3点を事前に設計しておく必要があります。
- 申請フロー: 誰が承認し、どの経路で通知するか（チケットシステム・メール等）
- 有効期限管理: 一時接続の最長有効期限を定め、自動失効の仕組みを持つ
- 棚卸しサイクル: 月次または四半期ごとに残存接続の実態を確認するレビューを設ける
廃止後の定期確認として押さえておくべき観点もあります。社内向けDNS解決がVPN経由のままになっていないか、レガシーアプリのHTTPクライアントがVPNを前提とした設定で動いていないかを定期的にネットワークログで確認する習慣を持つと、ゾンビ的なVPN依存の再発を防げます。
Context-Aware Access をVPN代替として使う前に確認すること
CAA をVPNの実質的な代替として運用する前に、以下の制約を押さえておく必要があります。
対応アプリの範囲に注意する
CAA が適用できるのは Google Workspace コアアプリ（Gmail / Drive / Meet など）と SAML/OIDC で連携しているアプリです。HTTP(S) を提供しないオンプレリソース（SMB のファイルサーバー、LDAP など）への直接適用は対象外で、この点を Phase 3 の直前まで見落とすとプロジェクトが足止めになります。
EV の展開前提を確認する
EV のシグナル収集には Chrome ブラウザへの拡張機能インストールが必要で、Internet Explorer 依存のレガシーアプリや Chrome 以外のブラウザが主体の環境では別途対応の検討が求められます。CAA の条件評価には基本的な条件評価と高度な条件評価という2段階があり、利用できる条件の種類はエディションや設定モードによって変わります。高度な条件（詳細なデバイス属性・カスタム属性による制御など）を使う場合は、対応エディションであるかの事前確認が必要です。
管理外デバイスの取り扱いを設計する
業務委託・派遣社員の個人デバイスは EV の「管理デバイス」条件を満たせないケースがあります。例外ポリシーを Phase 1 のうちに設計しておくことが、本番適用後の現場混乱を防ぐ最短経路です。アクセスレベルは柔軟に複数定義できるため、「正社員フルアクセス」「管理外デバイス制限付きアクセス」「外部委託ゲストアクセス」のように3〜4段階のポリシーセットをあらかじめ用意しておくと運用が安定します。
エディション要件を事前確認する
CAA / EV を利用するには Google Workspace または Cloud Identity のエディション要件があります。利用できる機能はエディションによって異なるため、Google の管理コンソールヘルプで確認してください。
よくある失敗パターンと回避策
ドライランなしで本番適用し全社ロックアウト
CAA ポリシーを本番適用した途端、EV 未展開のデバイスを持つユーザーが一斉にアクセス不能になるケースです。モニタリングモードで30日以上の検証期間を必ず設けてください。ドライランのブロック件数がゼロになるまでは本番切り替えを行わない、という完了条件を関係者と合意しておくことが重要です。特に「少数の古いデバイスを見落として大騒ぎになる」パターンが多いため、EV のシグナル未受信デバイスを定期的にレポートして漏れを潰す作業を Phase 1 中に継続する必要があります。
VPN利用アプリの棚卸しを省いた
「廃止宣言後に基幹システムのバッチ処理がVPN経由だったと判明」するケースは珍しくありません。Phase 1 で VPN 接続ログを分析する際、人が使うセッションだけでなく、サービスアカウント・CI/CDパイプライン・定期バッチのVPN依存も洗い出してください。夜間や週次で動く定期バッチは手動確認だけでは見落としやすいため、接続ログを少なくとも1ヶ月分・週単位で全期間集計することを推奨します。
フェーズ完了条件を事前合意していなかった
フェーズを進む判断を情シスが単独で背負うと、経営層や現場との合意形成でつまずいて推進が止まります。上記の参考目安を元に「このKPIを満たしたら次フェーズへ進む」という基準を、キックオフ時点で関係者と握っておくことが長期プロジェクトの推進力を維持する鍵です。プロジェクトが半年を超えると担当者異動のリスクも出てくるため、判断根拠をドキュメント化しておくことも合わせて推奨します。
オンプレリソースの扱いを後回しにした
CAA / IAP で制御できるのは Web アプリまでです。Phase 1 で「IAP 移行不可リソース」を一覧化し、廃止ロードマップに代替手段を最初から組み込んでおかないと、Phase 3 の直前で足止めになります。「オンプレファイルサーバーをどうするか」は IT 部門単独では決められないケースも多く、社内の意思決定を早めに動かす必要があります。
まとめ
BeyondCorp Enterprise を使ったVPN廃止は、以下の3フェーズのゲート管理で進めることが現実的です。
- Phase 1（可視化・基盤整備）: EV 展開と CAA ドライランで「止められる準備が整っているか」を確認する
- Phase 2（段階縮小）: アプリ単位でVPN依存を切り替え、セッション占有率を測定しながら縮小する
- Phase 3（完全廃止）: 全件の代替が確認できたタイミングで廃止宣言し、残存手段のポリシーを整備する
各フェーズの完了条件を KPI で定義し、関係者の合意を取っておくことが後戻りを防ぎます。「VPN廃止」はゴールではなく、ゼロトラスト基盤の定常運用への移行点です。廃止後も定期的なアクセス監査・EVシグナルのレビュー・アクセスレベルの棚卸しを継続することで、BeyondCorp による制御が形骸化しないよう維持する必要があります。
最初の一手として最も現実的なのは、情シスチームのデバイスに Endpoint Verification を先行展開し、CAA のドライランを1ヶ月動かしてみることです。ドライランのブロックログを確認すると、「どのデバイスが先に対応が必要か」「どのアプリから移行できるか」の優先順序が自然と整理されます。Google Workspace を軸にしたゼロトラスト移行の全体像については、DRASENAS公式サイトのBeyondCorp Enterprise 関連記事もあわせてご覧ください。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。