ゼロトラストとは？基本原則・VPNとの違い・企業の導入手順を解説

「ゼロトラストを導入したい」と考えても、VPNを置き換えるべきなのか、多要素認証を設定すれば十分なのか、何から着手すればよいのかは分かりにくいものです。クラウドサービス、在宅勤務、委託先との共同作業が増えるほど、社内ネットワークの内側と外側だけで安全性を判断する方法では、利用実態を捉えきれません。

ゼロトラストとは、社内にいることや会社所有の端末であることだけで暗黙に信用せず、利用者・端末・アクセス先・状況を確認し、必要な範囲だけ利用を許可するセキュリティの考え方です。単一の製品名ではなく、ID、端末、ネットワーク、アプリケーション、データと、それらを支える監視・運用を組み合わせます。企業では、重要な業務アプリを一つ選び、本人確認、最小権限、端末条件、ログ、緊急時の復旧を小さく検証するところから始められます。

以下はNIST SP 800-207とCISAのZero Trust Maturity Model Version 2.0（2023年版）などを基にした実務上の整理です。特定製品の導入を必須とするものではなく、自社のデータと業務をどのように守るかを判断するための基準として使えます。

---

本記事のポイント

1. ゼロトラストは、社内にいることだけで信用せず、ID・端末・アクセス先・状況を確認して必要な範囲だけ許可する考え方です。
2. VPNは通信経路、ZTNAはアクセス仲介を担うため、導入だけでアプリ内の権限やデータ管理まで完成するわけではありません。
3. 対象アプリを一つ選び、IDと権限の棚卸し、少人数での条件検証、例外・復旧・ログ運用を整えてから段階的に広げます。

---

ゼロトラストの意味と基本原則

従来の境界型防御は、社内ネットワークと外部の間にファイアウォールなどを置き、入口で不正な通信を防ぐことを重視します。境界の防御は現在も必要ですが、「中に入れたから安全」と扱うと、認証情報を盗んだ攻撃者や侵害された端末が、内部の別のシステムへアクセスしやすくなります。

ゼロトラストは、守る対象をネットワークの区画だけでなく、個々のデータ、サービス、業務アプリへ移します。例えば社員が社内Wi-Fiから顧客管理システムを開く場合でも、本人のID、役割、端末の状態、対象データの重要度を踏まえて許可を判断します。接続場所は判断材料の一つですが、それだけで無条件に許可する理由にはしません。

NISTの定義は、ネットワークが侵害されている可能性を前提に、アクセス要求に対して正確で最小権限の判断を行うための概念を示しています。「誰も信用しない」という言い方だけでは、社員への不信や、毎回複雑な手続きを課す仕組みと誤解されがちです。実務では、確認できた条件に応じて、必要なアクセスを限定して認めると捉える方が適切です。

NISTの7原則を業務に置き換える

1. データとサービスを守る対象として扱う：サーバーだけでなく、SaaS、ファイル、API、自動処理が利用するサービスも棚卸しします。
2. 通信は場所に関係なく保護する：社内からの通信にも暗号化などを適用し、「内部だから平文でよい」と決めつけません。
3. 個々のリソースへのアクセスをセッション単位で許可する：一つのアプリへの認証が、別のアプリやデータの利用権限まで自動的に与えないようにします。
4. 状況に応じたポリシーで判断する：ID、アプリ、端末状態、アクセス元など、自社で取得できる情報を組み合わせます。
5. 資産の安全性を監視する：端末の管理状況、更新、保護機能などを継続的に確認し、状態が変わったときの扱いを決めます。
6. 許可前に認証と認可を適用する：「本人か」と「その操作をしてよいか」を分けて確認し、ポリシーに応じて接続中も再評価します。
7. 状態データを集めて改善に使う：ログを保管するだけでなく、過剰権限、異常なアクセス、拒否の誤判定を見直します。

これらは目指すべき原則であり、全てを一度に完全実装することを意味しません。NISTも、実際の戦略では純粋な形ですべてを実現できない場合があると説明しています。古い業務アプリがある企業でも、対応できる対象から進め、残る例外の理由と期限を管理できます。

図の中心は、入口で一度だけ本人確認をして終わる仕組みではなく、アクセス先と条件を結び付ける判断です。ただし、全ての通信パケットでログインし直すという意味ではありません。再認証や再評価のタイミングは、サービスの機能、データの重要度、検知したリスクに応じて設計します。

VPN・ZTNA・SASEとの違い

VPN、ZTNA、SASEは、ゼロトラストと同じ意味ではありません。ゼロトラストがアクセスと運用の設計思想であるのに対し、各用語は通信手段、アクセス方式、サービスの枠組みを示します。比較するときは「どの製品がゼロトラストか」よりも、「何を保護し、どこで許可を判断するか」を確認します。

ゼロトラストと関連する仕組みの役割

用語	主な役割	導入だけでは決まらないこと
ゼロトラスト	場所や所有者だけに頼らず、必要なアクセスを文脈に応じて判断する考え方	製品の組み合わせ、権限設計、監視、例外運用を自社で具体化する必要がある
リモートアクセスVPN	一般に、暗号化トンネルを使って離れた端末から社内ネットワークへ接続する仕組み	接続後にどのアプリへ、どの権限でアクセスできるか
ZTNA	利用者や端末の条件に応じ、アプリやリソースへのアクセスを仲介する方式・製品群	SaaS内のデータ権限、IDの棚卸し、端末管理など全領域の運用
SASE	ネットワーク機能と、ゼロトラストを含むセキュリティ機能を統合するアーキテクチャ	自社に必要な機能範囲、設定の妥当性、運用体制

VPNを廃止すれば完成するわけではない

一般的なリモートアクセスVPNは暗号化した通信経路を作る技術であり、VPN自体がゼロトラストと相いれないわけではありません。問題になるのは、VPNに接続できた利用者へ広いネットワーク権限を与え、その後のアクセス先や端末状態を十分に確認しない構成です。既存VPNを残しながら、アプリごとの権限、認証、通信の制限を改善する方法もあります。

一方、クラウドメールやSaaSを使うためだけに全通信を社内へ戻す必要があるかは見直せます。対象サービスに直接接続し、IDや端末条件で制御できれば、利用経路を整理できます。ただし、社内専用プロトコル、機器管理、拠点間通信には別の要件があるため、Webアプリ向けの仕組みだけで一括置き換えできるとは限りません。

ZTNAはアクセス制御の一部を担う

ZTNAは、利用者のIDや端末状態などのアクセス条件に応じて、アプリ単位の接続を細かく仲介しやすくします。ただし、アプリの内部で全データを閲覧できる設定のままなら、入口を改善しても権限は過剰です。退職者のID削除、共有リンク、APIトークン、データ持ち出しの管理まで含めて確認します。

具体的なWebアプリの接続構成は、Cloudflare AccessとTunnelによる社内Webアプリの保護手順で確認できます。Tunnelは接続経路、Accessは認証・認可の役割を担うため、経路を作ることと利用を許可することを分けて設計します。

企業が点検する5つの領域

CISAの2023年版成熟度モデルは、アイデンティティ、デバイス、ネットワーク、アプリケーションとワークロード、データの5領域でゼロトラストを整理しています。さらに、可視性と分析、自動化とオーケストレーション、ガバナンスという3つの横断的な能力を示しています。これは導入状況の偏りを点検する材料であり、日本の全企業に同じ構成を義務付ける基準ではありません。

ゼロトラスト導入前の確認項目

領域	確認すること	最初の改善例
ID	社員・委託先・管理者・自動処理のアカウントに責任者と期限があるか	退職者と共有IDを棚卸しし、多要素認証と管理者IDの分離を進める
端末	会社端末と私物端末を区別でき、更新・保護・紛失時の対応を確認できるか	対象端末を登録し、まず管理済み端末から条件適用を試す
ネットワーク	接続先、不要な公開ポート、横方向の通信を把握できているか	業務に不要な通信経路を減らし、対象アプリへの経路を限定する
アプリ・ワークロード	アプリ内権限、API、自動処理に最小権限と認証の管理があるか	閲覧と更新を分け、サービス用の認証情報を人のIDから分離する
データ	機密度、共有先、保存先、ダウンロードや外部共有の条件を決めているか	顧客情報・契約書など重要データから共有範囲と操作権限を点検する

全領域で同じ製品を導入する必要はありません。既存のID基盤、端末管理、SaaSの管理機能を使える場合もあります。重要なのは、誰が条件を決め、誰がログを見て、例外をいつ終了させるかを領域横断で揃えることです。IDの削除を行っても、外部共有されたファイルや長期有効のサービス用トークンが残るなら、保護はつながりません。

Google Workspaceで端末やアクセス元の条件を使う場合は、コンテキストアウェアアクセスの条件設計と段階適用が具体例になります。利用できる機能は契約プランや端末の管理方式で変わるため、製品名だけで対応済みと判断せず、対象アプリと必要条件を照合してください。

また、通信を保護する機能と、入口で攻撃を防ぐ機能、利用者の権限を判断する機能は別の役割を持ちます。Web基盤の全体像はCloudflareのDNS・CDN・WAF・Zero Trustの違いを参照すると、境界防御とアクセス制御を組み合わせる理由を整理できます。

ゼロトラストを段階的に導入する手順

1. 守るデータと対象アプリを一つ決める

最初から全社のネットワークを組み替えるのではなく、顧客管理、社内ポータル、契約書共有など、アクセスの実態を把握できる対象を選びます。扱うデータ、利用者、委託先、接続端末、API、管理者操作を一覧にし、漏えい・改ざん・停止のどれが業務に大きな影響を与えるかを整理します。

対象は単に重要度が高いものではなく、検証時の影響を限定できるものを選びます。本番の唯一の管理画面や、停止できない基幹システムを最初の実験対象にするのは避け、テスト環境や限定した利用者で条件を確認します。

2. IDと業務上必要な権限を整理する

「営業部全員」「管理部全員」という所属だけでなく、どのデータを閲覧・更新・出力する必要があるかを分けます。通常利用と管理者操作は別の権限にし、異動、退職、委託終了に伴う権限変更の担当者を決めます。多要素認証は重要ですが、本人確認を強くしても過剰な権限は自動的には減りません。

共有アカウントや自動処理も別途確認します。人のログインIDをバッチ処理へ流用すると、利用者を特定しにくくなり、退職時の停止も難しくなります。サービス用アカウントや短い有効期間の認証方式など、対象サービスが対応する方法を使い、責任者、利用目的、更新・失効の手順を記録します。

3. 端末条件とアクセス経路を少人数で検証する

管理済み端末、OS更新、保護機能、アクセス元などの条件を、一度に厳しくしすぎないようにします。モニターモードなど、許可を止めずに影響を観察できる機能があれば先に使い、次にテストグループへ適用します。出張、在宅勤務、委託先、スマートフォンなど、実際の利用パターンを試すことが重要です。

固定IPだけで制御すると、外出先からの正規利用を止める一方、許可IPの環境に侵入された場合の判断が弱くなります。IP制限を使う場合も、ID、端末、アプリ内権限と組み合わせます。監視できない私物端末に対しては、管理端末と同じ条件を想定せず、閲覧のみ、ダウンロード制限、別環境の利用など、実現可能な制御を検討します。

4. 拒否時と障害時の復旧経路を準備する

正しい利用者が拒否されたとき、どこへ連絡し、誰がログを確認し、どの条件を修正するかを決めます。ID基盤やアクセス仲介サービスの障害、管理者のロックアウト、端末の紛失を想定し、対象業務への影響と復旧手順を試します。

緊急アクセスを用意する場合も、常時開放の裏口にしてはいけません。利用できる人、保管方法、使用条件、監視、期限、使用後の認証情報の変更を決め、通常の管理者IDと分けて管理します。例外の承認は、対象者、アプリ、許可操作、終了日を残して行います。

5. ログと業務影響を評価して対象を広げる

導入後は、対象アプリのアクセス経路が制御を迂回していないか、拒否された正規利用の理由は何か、不要な権限と期限切れ例外が残っていないかを確認します。ログの保存期間や閲覧権限も定め、アラートを誰が処理するかまで担当を割り当てます。

成果は製品の導入数ではなく、過剰権限の削減、管理対象端末の把握、退職者IDの停止、例外の期限管理、復旧手順の実行可能性などで評価できます。同時に、ログインの失敗、問い合わせ、処理遅延、利用不能の時間も見て、守りを強めた結果として業務が滞っていないかを判断します。

既存セッションの保護も別の確認項目です。認証後のCookieが盗まれる問題などは入口の認証だけで対処しきれない場合があるため、Google WorkspaceのDBSCとセッションCookie保護のように、認証後の利用を守る仕組みも対象製品ごとに確認します。

よくある失敗と導入判断のチェックリスト

失敗しやすいのは、製品の購入をゴールにして運用を後回しにする進め方です。認証を統一しても退職者IDが残り、端末条件を導入しても対象外の接続経路が開いたままなら、リスクは別の場所に残ります。データの共有設定やアプリ内部の権限も、アクセス仲介製品だけで解決できるとは限りません。

反対に、全ての利用者へ一斉に厳しい制限をかけると、締め出しが増え、現場が個人アカウントや無許可の共有手段へ逃げる可能性があります。制限が必要な理由を対象データと業務リスクから説明し、利用者が正規の経路を選べる状態を作ることが、継続的な保護につながります。

• 守るデータ、対象アプリ、利用者、サービス用アカウントを説明できるか。
• 本人確認と操作権限の判断を分け、必要な範囲に限定できるか。
• 社内・在宅・出張・委託先の利用を、実際の端末で検証したか。
• 既存の公開URLや別経路から制御を迂回できないか。
• 拒否ログを見て、正規利用の問題を解消する担当者がいるか。
• 例外の責任者と終了日を決め、期限後に確認できるか。
• 認証基盤の障害や管理者の締め出しから復旧できるか。
• 改善結果と業務への影響を同じ対象・期間で評価できるか。

全項目を一度に満たすことより、未対応の項目を認識し、次に改善する対象を決められることが大切です。ゼロトラストは「導入済み」のラベルで完結せず、利用者、端末、アプリ、データの変化に合わせて判断条件を更新する運用です。