VPNを廃止して、ゼロトラストに置き換えた — 扉の無いネットワークとCI/CDの運用

当社はVPNを廃止しました。拠点間のVPN装置も、リモートアクセス用のVPNも動いていません。代わりにあるのは、利用者・端末・宛先の組で接続の可否を都度判定するゼロトラスト型のアクセス基盤です。社内ではZDRと呼んでいます。

VPNをやめた話は、製品の入れ替えとして語られがちです。実際に時間を使ったのは、置き換えたあとの維持でした。拠点が増え、端末が増え、接続先が増えるたびに、VPNの設定は静かに育ちます。数年経つと、誰も全体像を説明できなくなります。

結論から書きます。当社はネットワークへの入口を作らない構成にし、接続の可否を宛先ごとに判定しています。そのうえで、基盤の定義と更新をGitとCI/CDに載せ、古くならないようにしています。以下、VPNとの違い、いまの構成、CI/CDで回している範囲、そして残っている限界を書きます。

VPNとゼロトラストの違い

VPNは「一度通せば、その先のネットワーク全体に入れる」モデルです。認証は入口で1回。通ったあとの通信は、社内LANにいるのと同じ扱いになります。わかりやすく、設定も単純です。弱いのは、信頼の単位がネットワーク全体になることです。

ゼロトラストは、接続のたびに「誰が・どの端末で・どこへ」を確認します。許可の単位はネットワークではなく宛先です。社内から来たという理由で信用はしません。

• VPN: 認証は入口で1回／許可の単位はネットワーク／通信はゲートウェイ経由／社内から来た通信は信頼する
• ゼロトラスト: 認証は都度／許可の単位は宛先／通信は内側のコネクタ経由／社内から来た通信も信頼しない

もうひとつの違いは、扉の有無です。VPNはどうしても、インターネットに露出したゲートウェイを持ちます。ゼロトラストのコネクタは内向きの待ち受けを持たず、内側から外へ接続を張ります。攻撃者から見ると、叩く扉がありません。

ただし「ゼロトラストを入れれば安全」ではありません。判定に使う材料（ID、端末、権限）が雑であれば、雑な判定が速くなるだけです。ここは後半で書きます。

いまの構成

当社の構成は、コネクタ（Twingate）とEKSの組み合わせで、2023年からこの形で動かしています。コネクタはクラスタ内で稼働し、社内ネットワーク側の宛先への経路を持ちます。端末にはクライアントが入り、統合認証でログインします。接続はクライアント→（必要ならリレー）→コネクタ→宛先という流れです。

許可は「利用者またはグループ × 宛先」の組で持ちます。VPNのように「この人は社内のIPだから全部通す」という判定はしません。同じ人でも、宛先が違えば別の判断になります。

コネクタをEKSに置いたのは、アプリと同じ場所に経路の起点を作れるからです。ノードやPodの入れ替えに追従し、複数レプリカで動かせます。いまは2つのコネクタが並行稼働していて、片方が落ちても接続は維持されます。

入口を作らない設計

アプリ側の受け口も変えました。当社のRedmine環境では、ALBのリスナールールでコネクタの出口IPだけを許可しています。インターネットからそのURLへ来ても、そもそも到達しません。届くのはゼロトラスト基盤を通った通信だけです。

許可元IPの一覧はKubernetesのIngressマニフェストにあり、Gitで差分が追えます。IPが変われば変更はレビューを通ります。設定が「誰かの手元の管理画面」ではなく、レビュー可能なファイルにあることが、この形の効きどころです。

例外は残っています。機器側の都合でゼロトラスト経由にできない対象、移行が終わっていない経路、拠点に残した直接接続です。これらはIP許可で暫定的に通してあり、マニフェストのコメントに「削除予定」と書いています。例外はゼロにできないので、一覧にして減らしていく対象として管理しています。

CI/CDで回すメンテナンス

基盤は、入れて終わりではありません。コネクタのイメージ、許可元IP、権限、宛先の一覧。どれも時間で古くなります。これを人の記憶ではなくパイプラインに載せたのが、当社のやり方です。

定義はGitに置く

ネットワークとアプリの定義はGitに寄せました。Ingress（許可元IP・ヘッダ条件）はマニフェスト、アプリの構成はkustomizeのoverlay、適用はskaffold。環境ごとの差分は「どのファイルが違うか」で説明できます。

コネクタはHelmのリリースとして管理し、イメージは1系を指したまま、起動時に必ず最新を取得する設定（imagePullPolicy: Always）にしています。バージョンを固定して四半期ごとに見直すのではなく、定期的に再起動して最新の1系に追従させます。脆弱性対応のリードタイムを、人のカレンダーから外すのが狙いです。

パイプラインも網から入る

ここがVPN時代と一番違う点です。CI/CDは、踏み台もVPNも使いません。パイプラインがサービスキーでゼロトラスト基盤に参加し、与えられた権限の範囲でkubectlを実行し、終わったら抜けます。

# パイプラインの流れ（要約）
twingate setup --headless=-   # サービスキーで基盤に参加
twingate start
kubectl apply -k overlays/<env>
twingate stop

踏み台サーバを維持する必要がなくなり、人間の作業者と同じ認可の仕組みでCIが動きます。実行主体が「人か機械か」で別の扉を作らないので、監査のときに見る場所が1つで済みます。

AIを使う攻撃とゼロトラスト

2026年1月、IPAは「情報セキュリティ10大脅威 2026」の組織編で「AIの利用をめぐるサイバーリスク」を3位に初選出しました。理由として、AIの悪用による攻撃の容易化と手口の巧妙化が挙げられています。

数字も出ています。Zscalerの2026年の調査では、生成AIで作られた不正サイトが41万件以上確認され、その約1割が明示的に悪意あるものと判定されました。セッションを乗っ取り、多要素認証をリアルタイムで回避するキットも使われ、日本向けのフィッシング試行は約1,567万件に達しています。

これがVPNとどう関係するか。VPNは入口が1つの構造なので、その入口を騙す攻撃（偽のログイン画面、認証情報の窃取、セッションの乗っ取り）が1回成功すると、その先のネットワーク全体に届きます。守るべき境界が集中しているぶん、突破されたときの被害も集中します。

ゼロトラストでは、偽のログイン画面を作られても、得られるのは「その利用者・その宛先」の期限付きの権限です。宛先ごとに認可が分かれているので、1つの資格情報から横に広がれる経路が短くなります。AIで試行回数が増えるほど、「1件あたりの被害を小さくする」設計が効いてきます。

守る側のAI利用も同じ枠組みに入ります。社内システムにAIエージェントや自動化を接続するとき、その機械のIDに人間と同じ認可と記録を適用できます。人間用と機械用で別の入口を作らないことが、AIを入れても説明できる状態を保つ条件になります。

誇張はしません。ゼロトラストは侵害をゼロにする製品ではありません。侵害されたあとにどこまで広がるか、あとから説明できるかを、設計で決めるものです。

減った作業と、増えた前提

減ったのは、VPN装置の保守、拠点ごとの設定追加、接続手順書、IPの台帳、退職時の経路削除です。端末を配った日から同じ手順で、必要な社内システムに入れます。

増えたのは、基盤自体の運用です。コネクタの可用性、宛先とグループの棚卸し、ポリシーのレビュー、CIに渡すサービスキーの管理。中心に置いた仕組みが止まれば業務も止まる、という性質は引き受けています。複数レプリカで緩和していますが、単一障害点がゼロになったわけではありません。

残る限界も書きます。基盤に入れた端末は信頼の起点です。その端末が乗っ取られれば、正規の手順で正規の操作ができてしまいます。だから端末の管理と多要素認証は、別に運用する必要があります。許可の設計が「全社員×全宛先」になればVPNと大差ありません。宛先を絞る作業は導入後も続きます。

環境側の制約も残ります。顧客側にVPNしか用意されていない、レイテンシが厳しい、といった経路では、顧客のVPN装置に接続するための橋渡しをコンテナで持つ案件もあります。ゼロトラストは既存の接続を全部消す魔法ではなく、残す例外を説明できる形にする道具だと考えています。

記録の形も変わりました。誰がいつどこへ入ったかは、基盤側とアプリ側の両方に残ります。VPNの時代は「社内に入ったあと何をしたか」を別のログと突き合わせる必要がありましたが、いまは宛先が単位なので、インシデントのときに「この人が触れた範囲」を記録から列挙できます。統制の資料としてもそのまま使える形です。

ログは、抑止のためというより、事後に説明できるようにするためにある。説明できない運用は、ルールが厳しくても信用されない。

支援できること

当社は、VPNからゼロトラストへの移行と、その後の運用を支援しています。現行構成の棚卸し、宛先と権限の設計、コネクタの配置、CI/CDへの載せ方、例外の一覧化と期限の運用までを含みます。「どのVPN製品に替えるか」ではなく「入口をどう減らすか」から考えます。VPNの維持に限界を感じている方、移行後の運用が回らないと感じている方は、お問い合わせください。

参考

• IPA「情報セキュリティ10大脅威 2026」 — 組織編3位「AIの利用をめぐるサイバーリスク」の位置づけ
• NIST SP 800-207「Zero Trust Architecture」（2020年8月）— ゼロトラストの構成要素と前提
• NIST SP 800-207A「A Zero Trust Architecture Model for Access Control in Cloud-Native Applications」 — クラウドネイティブ環境での適用
• CISA「Zero Trust Maturity Model」Version 2.0（2023年4月）— 成熟度の段階と評価軸
• Zscaler ThreatLabz「2026年版 フィッシングと初期アクセスに関するレポート」（2026年6月発表・日本語抄訳 2026年7月）— 生成AI製サイトとMFA回避の実測値
• Twingate Documentation「Architecture」 — コネクタ・コントローラ・リレーの役割
• Twingate Documentation「How Twingate Works」 — 接続の確立手順とポリシー評価