こんにちは！インフラやネットワークの世界へようこそ。
日々、会社の中でパソコンを開き、当たり前のように社内システムやクラウドのサーバーにアクセスしていることと思います。
ところで、皆さんは「社内ネットワーク」という言葉を聞いて、どんな光景を思い浮かべるでしょうか？
多くの人は、「オフィスの分厚い壁に守られた安全な金庫のようなもの」を想像するかもしれません。一度その壁の中にさえ入ってしまえば、あとはパスワード一つですべての部屋（サーバー）に行き来できる……。そんな世界です。
しかし、リモートワークが当たり前になり、クラウドサービスが全盛の今、その「オフィスの壁」という考え方が、実は大きな曲がり角を迎えているんです。今回は、これまでの「境界型防御」から、まったく新しい「ゼロトラスト（何も信じない）」の世界へどうやって歩みを進めていくのか、そのロードマップを一緒に見ていきましょう。一歩ずつ、優しく解説していくので安心してくださいね！
—
1. なぜ「オフィスの壁」だけでは守れないの？
これまでのセキュリティの考え方は、よく「中世のお城」に例えられます。
厚い城壁を築き、門には頑丈な衛兵（ファイアウォール）を置く。そして、「門をくぐってきた人は全員、信頼できる味方です！」として、お城の中（社内ネットワーク）では自由に歩き回らせる――これが境界型防御と呼ばれる仕組みです。
[従来の城壁モデル]
外の世界 (危険) ──> [頑丈な門(ファイアウォール)] ──> お城の中 (安全・フリーパス！)なんだか効率的で良さそうに思えますよね。でも、現代の働き方ではこれが大きな弱点になってしまいます。
- 社員がカフェや自宅から、会社のパソコンで直接クラウドにアクセスする。
- もし、そのパソコンが悪者に乗っ取られていたら？
- 城壁の外から来たはずなのに、門番は「おや、IDとパスワードが合ってますね。どうぞお入りください」と、いとも簡単にお城に通してしまうかもしれません。
お城の中に侵入してしまえば、あとは金庫の中身（機密データ）までノーチェックでたどり着けてしまいます。これではあまりに危険ですよね。
そこで登場するのが、ゼロトラスト（ZTNA：ゼロトラストネットワークアクセス）という考え方です。これは、「社内だから安心」「パスワードが合っているから安全」といった信頼を一切せず、アクセスするたびに、人、場所、デバイスの状態をすべて疑って確認するという、現代のセキュリティの常識なんです。
—
2. 郵便配達員に例えて考えてみよう
ゼロトラストの仕組みを、身近な「郵便配達」でイメージしてみましょう。
- 従来の境界型（お城）：
身分証を見せて一度郵便局の中に入ってしまえば、局内のどの部屋の金庫も自由に見放題、という状態です。
- ゼロトラスト（ZTNA）：
配達員さんがどんなに顔見知りであっても、どこの部署の誰で、今持っている荷物は何か、そして「今日の体調や身だしなみ（＝デバイスの安全性）」に問題がないかを、部屋の扉を開けるたびに毎回チェックする仕組みです。
「毎回チェックされるなんて面倒だな」と思われるかもしれませんが、デジタルの世界では、このチェックをシステムが一瞬で行ってくれます。このZTNAを導入していくには、いきなり全部を変えるのではなく、いくつかの「段階（成熟度モデル）」を踏んで進めていくのが現実的で確実な方法なのです。
—
3. ZTNAへの段階的移行ロードマップ
それでは、レガシーな境界型防御から、完全なゼロトラストの世界へジャンプするための「3つのフェーズ」を順番に見ていきましょう。
[成熟度モデルのステップ]
フェーズ1：足元固めと「人・デバイス」の可視化
↓
フェーズ2：部分的なZTNAの導入（クラウドアプリから）
↓
フェーズ3：レガシーアプリの抱え込みと完全ゼロトラスト化フェーズ1：足元固めと「人・デバイス」の可視化
まずは、「今、誰が、どこから、どんな端末でアクセスしているのか」を正確に把握することから始まります。
ここで重要になるのが、多要素認証（MFA）の徹底と、デバイスの健全性チェック（MDM等による管理）です。パスワードが盗まれたとしても、スマホに飛んでくる確認コード（ワンタイムパスワード）や生体認証がなければログインできない仕組みを作ります。
フェーズ2：部分的なZTNAの導入（クラウドアプリから）
社内にあるすべてのシステムをいきなりゼロトラスト対応にするのは、プログラミングやインフラの観点から見ても至難の業です。
そのため、まずはMicrosoft 365やGoogle Workspace、Salesforceといったクラウド上のサービス（SaaS）へのアクセスからZTNAを適用していきます。
「社外からアクセスする場合、会社が管理している安全なPC以外からはログインを禁止する」といったポリシー（ルール）を定義し、クラウドのゲートウェイで厳しく門番をさせます。
フェーズ3：レガシーアプリの抱え込みと完全ゼロトラスト化
そして、ここが一番の難所であり、多くのインフラエンジニアが頭を悩ませるポイントです。社内には、大昔に作られてクラウドに対応していない、いわゆる「レガシーな社内システム（社内専用のWebアプリやファイルサーバー）」が眠っていますよね。
「これらはどうやってゼロトラストにするの？」という疑問が湧いてきます。
ここで登場するのが、「ZTNAコネクター（またはマイクロプロキシ）」と呼ばれる仕組みです。
—
4. レガシーアプリをゼロトラストに繋ぐ設定例
レガシーアプリを安全に公開するために、モダンなZTNAサービス（例えばCloudflare AccessやZscaler、あるいはオープンソースや各種クラウドネイティブなプロキシ製品）と連携させる構成を考えてみましょう。
イメージとしては、古いお城の門の前に「最新型の受付係」を新しく配置するようなものです。直接インターネットからレガシーアプリに触らせるのではなく、一度ZTNAの認証プロキシを挟みます。
以下は、NGINXなどのリバースプロキシやプロキシサーバーを使って、社内のレガシーアプリ手前に「条件付きアクセス（認証）」を挟む概念的な設定例です。
# /etc/nginx/conf.d/zero_trust_gateway.conf
# レガシーアプリを手前で守るためのリバースプロキシ設定例
server {
listen 443 ssl;
server_name legacy-app.company.internal;
# 企業の安全な証明書を設定
ssl_certificate /etc/ssl/certs/company_server.crt;
ssl_certificate_key /etc/ssl/private/company_server.key;
location / {
# 【重要】直接アプリに行かせず、まず認証ヘッダーやクライアント証明書を検証する
# 例：特定の認証プロキシ（Cloudflare等）から渡されたユーザーIDヘッダーをチェック
if ($http_cf_access_authenticated_user_email = "") {
return 403 "アクセスが拒否されました：ゼロトラスト認証が必要です。";
}
# 条件をクリアした場合のみ、社内のレガシーアプリへパケットを転送する
proxy_pass http://192.168.10.50:8080; # 社内レガシーサーバーのIP
# ヘッダー情報の引き継ぎ
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 誰がアクセスしたかをアプリ側に伝えるカスタムヘッダーの付与
proxy_set_header X-Authenticated-User $http_cf_access_authenticated_user_email;
}
}このように、アプリケーションそのものを今すぐ作り直さなくても、手前に「認証という名の厳格なフィルター（プロキシ）」を置くことで、レガシーアプリであっても段階的にゼロトラストの枠組みに組み込むことができるのです。
—
5. まとめ：一歩ずつ、確実なセキュリティの未来へ
今回は、境界型防御からゼロトラスト（ZTNA）への移行ロードマップについて、身近な例えを交えてお話ししました。
- 従来の「お城の壁」モデルは、リモートワークやクラウド全盛の現代では限界を迎えていること。
- ZTNAは、すべてのアクセスを疑い、毎回「人・場所・デバイス」を確認する仕組みであること。
- いきなりすべてを変えるのではなく、フェーズ1（可視化・MFA）からフェーズ3（レガシーアプリのプロキシ保護）へと、段階的に移行していくことが大切であること。
インフラやネットワークの世界は、時として複雑で難解な用語の壁に阻まれがちですが、「誰が何を確認しているのか」という本質的な流れさえ掴んでしまえば、決して怖くありません。
皆さんの現場でも、まずは身近なクラウドサービスへのアクセス見直しから、小さな一歩を踏み出してみませんか？
それでは、また次回の技術解説でお会いしましょう！
コメント