この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第30回です。
第3章では、BGP、QoS、MPLS、SD-WAN、SASEなど、 企業ネットワークを設計するうえで重要となる高度なネットワーク技術を学びます。 今回は、ネットワークの「内側・外側」で信頼を決めるのではなく、 利用者・端末・アクセス先などを確認して必要なリソースだけへアクセスさせるZTNA を学びます。
Zero Trust Network Access（ZTNA）とは？VPNとの違いとゼロトラストの考え方を解説
「社内ネットワークへ接続したから信頼する」という考え方では、 クラウド利用、テレワーク、BYOD、外部委託などが増えた環境を十分に守れません。 ZTNAでは、利用者や端末、アクセス先などを確認し、 必要なアプリケーションだけへ最小限のアクセスを許可します。
従来の企業ネットワークでは、 「社内ネットワークは信頼できる場所、インターネットは信頼できない場所」 という境界型の考え方が多く使われてきました。
しかし現在は、利用者が自宅からSaaSへ接続したり、 クラウド上の業務システムを利用したり、 外部委託先が一部の社内アプリケーションへアクセスしたりします。
そこで重要になるのが、 接続場所だけを理由に信頼せず、アクセスのたびに条件を確認して必要なリソースだけを許可する というゼロトラストの考え方です。
この記事を読み終えるとできること
- ZTNAの基本的な考え方を説明できる
- ゼロトラストとZTNAの違いを区別できる
- 従来型VPNとZTNAの違いを説明できる
- 認証からアプリケーション接続までの流れを説明できる
- ZTNAで確認すべき利用者・端末・リソースを整理できる
- ZTNAのアクセス制御ルールを設計できる
- SASEとZTNAの関係を説明できる
- ZTNAを導入するときの注意点を洗い出せる
ZTNAとは何か
ZTNA（Zero Trust Network Access）とは、 利用者や端末などの条件を確認し、 許可されたユーザーへ必要なアプリケーション・リソースだけを 最小限に公開するアクセス制御の考え方・仕組みです。
ZTNAは、 Zero Trust Network Access の略です。
日本語では「ゼロトラストネットワークアクセス」と呼ばれます。
重要なのは、 「社内だから許可する」「VPNへ接続できたから広くアクセスさせる」 という判断ではありません。
たとえば、営業部の社員がCRMへアクセスするとします。
CRMへアクセスできたからといって、 人事システムやサーバー管理画面までアクセスできる必要はありません。
ZTNAの重要ポイント
「ネットワークへ入れるか」ではなく、 「誰が、どの端末から、どのリソースへアクセスしてよいか」 を細かく判断します。
ゼロトラストとZTNAは同じものではない
「ゼロトラスト」と「ZTNA」は混同されやすい用語です。
| 用語 | 考え方 |
|---|---|
| Zero Trust | ネットワークの場所などを理由に暗黙の信頼を与えず、 利用者・端末・リソースなどを確認してアクセスを制御する セキュリティ上の考え方 |
| ZTNA | Zero Trustの考え方を、 利用者からアプリケーションや業務リソースへのアクセス制御に 適用するための方式・仕組み |
「ZTNA製品を導入した＝企業全体のゼロトラスト化が完了」ではありません。
ゼロトラストでは、ID、端末、ネットワーク、アプリケーション、 データ、監視・運用など複数の領域を考える必要があります。 ZTNAはその中でも、特にアクセス制御を実現する重要な仕組みの一つです。
なぜZTNAが必要なのか
従来の企業ネットワークでは、 オフィスの中にサーバーやPCがあり、 インターネットとの境界にファイアウォールを配置する構成が一般的でした。
従来の境界型セキュリティのイメージ
ところが、現在は企業のIT環境が大きく変わっています。
テレワーク
社員が自宅、出張先、コワーキングスペースなど、 社外から業務システムへアクセスします。
クラウド・SaaS
業務システムが社内データセンターだけでなく、 クラウドやSaaS上にも分散しています。
外部利用者
協力会社や委託先など、 社員以外の利用者へ限定的なアクセスを提供する場面があります。
ネットワークの場所だけでは信頼を判断できない
オフィスにいる社員でも、 アカウントが乗っ取られている可能性があります。
一方、自宅から接続している社員でも、 正規の利用者が会社管理端末から業務システムを利用しているのであれば、 適切な条件のもとでアクセスを許可する必要があります。
「社内IPアドレスだから安全」 「VPNへログインしたから安全」 だけで判断するのは不十分です。
アクセス元の場所だけでなく、 利用者、端末、接続先、認証状態などを組み合わせて判断する必要があります。
ゼロトラストの基本的な考え方
ZTNAを理解するときは、 製品機能より先にゼロトラストの基本的な考え方を理解することが重要です。
暗黙に信頼しない
社内・社外という場所だけで利用者や端末を信頼しません。 アクセスに必要な条件を確認して判断します。
必要最小限だけ許可する
利用者が業務に必要なリソースだけへアクセスできるようにし、 不要なシステムへの通信を減らします。
状態を継続的に確認する
認証した瞬間だけでなく、 利用状況や端末状態などを継続的に評価できる設計を検討します。
「ネットワーク」より「リソース」を守る
境界型の考え方では、 「社内ネットワークへ入れないようにする」ことが重要でした。
ゼロトラストでは、 さらに細かく 「この利用者に、このアプリケーションへのアクセスを許可するか」 を考えます。
ZTNAによるアクセス制御の基本イメージ
重要： ゼロトラストは「すべてを信用しないから全部拒否する」という考え方ではありません。
必要なアクセスを適切に認証・認可し、 業務に必要な通信を安全に提供することが目的です。
ZTNAでアクセスするまでの流れ
実際の製品構成や実装方法は異なりますが、 ZTNAによるアクセスは概念的には次のような流れで考えられます。
- 利用者が業務アプリケーションへアクセスする 社員がPCからCRM、社内Webシステム、クラウドアプリケーションなどへの アクセスを開始します。
- 利用者を認証する ID基盤などと連携し、 誰がアクセスしようとしているのかを確認します。 必要に応じて多要素認証を利用します。
- 端末の条件を確認する 会社管理端末か、OSやセキュリティ状態が条件を満たしているかなどを 判断材料として利用します。
- アクセス先とポリシーを確認する 利用者の所属、役割、端末状態、対象アプリケーションなどから アクセス可否を判定します。
- 許可されたリソースとの接続を確立する 条件を満たした場合、 対象となるアプリケーションへのアクセスだけを許可します。
- アクセス状況を記録・監視する 誰が、いつ、どの端末から、 どのリソースへ接続したかを記録し、 監査やインシデント調査へ利用できるようにします。
例：営業部の社員がCRMへ接続する
| 確認項目 | 条件例 | 結果 |
|---|---|---|
| 利用者 | 営業部所属の有効なアカウント | OK |
| 認証 | MFAを正常に完了 | OK |
| 端末 | 会社管理PC | OK |
| 接続先 | 営業部向けCRM | OK |
| 人事システム | 営業部にはアクセス権なし | 拒否 |
認証と認可を区別してください。
本人であることを確認できても、 すべてのシステムへアクセスできるわけではありません。 「誰なのか」を確認した後、 「その人がそのリソースを利用してよいか」を判断します。
VPNとZTNAの違い
ZTNAを学ぶとき、 最も比較されるのがリモートアクセスVPNです。
ただし、 「VPNは古いから不要」「ZTNAへ変更すれば必ず安全」 という単純な比較ではありません。
それぞれアクセスを提供する考え方が異なります。
| 比較項目 | 従来型リモートアクセスVPN | ZTNA |
|---|---|---|
| 基本的な接続対象 | 社内ネットワークへの接続 | 許可されたアプリケーション・リソース |
| アクセス単位 | ネットワーク・サブネット単位になりやすい | アプリケーション・リソース単位で制御しやすい |
| 判断材料 | VPN認証、接続元など | 利用者、端末、認証状態、対象リソースなど |
| 接続後の範囲 | ルーティング・ACL等で別途制御 | 最初から必要なリソースのみを公開する考え方 |
| 内部ネットワークの公開範囲 | 構成によって内部ネットワークへの到達性が存在する | 不要な内部ネットワークを利用者へ直接公開しない設計が可能 |
| クラウドとの相性 | VPN終端や経路設計が必要になる場合がある | クラウド・SaaS・オンプレミスをリソース単位で統合しやすい |
VPNでも細かなアクセス制御はできる
VPNだから必ず「全ネットワークへアクセス可能」になるわけではありません。
VPN接続後にファイアウォールやACL、 ユーザーグループごとのポリシーなどを設定すれば、 通信範囲を制限できます。
違いを理解するときは、 VPNはネットワーク接続を提供することが中心であり、 ZTNAはリソースへのアクセス制御を中心に考える と整理すると分かりやすくなります。
VPNとZTNAは完全な二者択一とは限りません。
管理通信や特殊なプロトコルなどではVPNを残し、 一般利用者のWebアプリケーションアクセスからZTNAへ移行するなど、 段階的に併用する設計も考えられます。
SASEとZTNAの関係
前の記事では、 SASEの基本 を学びました。
SASEとZTNAも、同じ意味ではありません。
SASEとZTNAの関係イメージ
| 項目 | 概要 |
|---|---|
| SASE | ネットワーク機能と複数のセキュリティ機能を クラウド中心に提供するアーキテクチャの考え方 |
| ZTNA | 利用者や端末などを確認し、 必要なアプリケーションへのアクセスを制御する仕組み |
多くのSASE・SSE系サービスでは、 ZTNAがアクセス制御機能の一つとして提供されます。
SASEは全体のアーキテクチャ、ZTNAはアクセス制御の一要素 と考えると整理しやすくなります。
ZTNAを構成する主な要素
ZTNAは単独の機器だけで成立するとは限りません。 実際の設計では複数の仕組みを連携させます。
1．ID・認証基盤
利用者が誰であるかを確認します。 IdPやディレクトリサービスなどと連携します。
2．多要素認証
パスワードだけに依存せず、 複数の認証要素を使って本人確認を強化します。
3．端末情報
管理端末かどうか、 OSやセキュリティ状態が条件を満たしているかなどを アクセス判断に利用します。
4．ポリシーエンジン
利用者・端末・接続先などの情報から、 アクセスを許可するか判断します。
5．アプリ接続機能
許可された利用者と業務アプリケーションの間に 必要な通信経路を提供します。
6．ログ・監視
誰が、どの端末から、どのアプリケーションへ アクセスしたかを記録します。
ネットワークエンジニアだけでは完結しない
従来のネットワーク設計では、 IPアドレス、ルーティング、VPN、ファイアウォールなどが 主な検討対象でした。
ZTNAでは、それに加えて次の担当者との連携が重要になります。
- ID・認証担当
- Active Directory・IdP担当
- 端末管理担当
- セキュリティ担当
- クラウド担当
- アプリケーション担当
- 情報システム・運用担当
ZTNA設計では、 ネットワークだけでなく「ID＋端末＋アプリ＋セキュリティ」を横断して考える力 が重要になります。
ZTNA設計で決めること
ZTNA製品を選ぶ前に、 「誰に、何を、どの条件で許可するか」を整理します。
1．誰が利用するのか
- 正社員
- 契約社員
- 協力会社
- 運用担当者
- 管理者
- 海外拠点利用者
2．どの端末を許可するのか
- 会社支給PCのみか
- BYODを許可するか
- スマートフォンを許可するか
- OSバージョンを条件にするか
- 端末管理状態を確認するか
- セキュリティソフトの状態を確認するか
3．何へアクセスさせるのか
- 社内Webシステム
- CRM
- ファイル共有
- SaaS
- クラウド上の業務アプリケーション
- サーバー管理画面
4．どの条件なら許可するのか
| 条件分類 | 確認項目例 |
|---|---|
| Identity | 利用者、所属、役割、アカウント状態 |
| Authentication | パスワード、MFA、認証結果 |
| Device | 管理端末、OS、セキュリティ状態 |
| Resource | アクセス対象アプリケーション |
| Context | 必要に応じて接続状況などを判断材料とする |
5．アクセスルールを表にする
設計時は、 「営業部はCRMを利用できる」のような文章だけでなく、 マトリクスにするとレビューしやすくなります。
| 利用者 | 端末条件 | CRM | 人事システム | サーバー管理 |
|---|---|---|---|---|
| 営業部 | 会社管理端末 | 許可 | 拒否 | 拒否 |
| 人事部 | 会社管理端末 | 拒否 | 許可 | 拒否 |
| インフラ管理者 | 管理端末＋MFA | 必要時のみ | 拒否 | 許可 |
| 外部委託先 | 指定端末＋MFA | 対象業務のみ | 拒否 | 拒否 |
製品選定より先にアクセス要件を整理してください。
「ZTNAを導入したい」という要望だけで製品比較を始めると、 実際に必要なポリシー、ID連携、端末管理、 対応プロトコルなどを後から見直すことになります。
6．ログ設計も同時に行う
ZTNAではアクセスを細かく制御するため、 ログも重要な設計要素です。
- 利用者
- 利用端末
- 接続日時
- アクセス先
- 許可・拒否結果
- 拒否理由
- 認証結果
- ポリシー変更履歴
これらをSIEMなどへ集約すれば、 インシデント調査や監査にも活用できます。
ZTNAが向いている利用ケース
テレワーク
自宅や外出先から社内アプリケーションを利用するときに、 利用者と端末を確認して必要なアプリだけを提供します。
外部委託先アクセス
協力会社へ社内ネットワーク全体を公開せず、 作業に必要なシステムだけを利用させたい場合に有効です。
クラウド移行
アプリケーションがオンプレミスと複数クラウドへ分散していても、 利用者視点でアクセス制御を統一しやすくなります。
拠点に依存しない働き方
「本社LANだから許可」という設計から離れ、 利用者の役割を中心にポリシーを作れます。
すべての通信をZTNAへ置き換えられるとは限らない
ZTNA製品によって、 対応するアプリケーションやプロトコル、 エージェントの必要性、 接続方式などが異なります。
たとえば次のような通信は、 製品仕様や要件を十分に確認する必要があります。
- ネットワーク機器の管理通信
- 特殊なTCP・UDPアプリケーション
- サーバー間通信
- 大容量ファイル転送
- レガシーシステム
- 端末へエージェントを導入できない環境
ZTNAは「VPNの置き換え製品」という視点だけで検討せず、 対象アプリケーションの通信要件を整理したうえで適用範囲を決める ことが重要です。
ZTNAでよくある勘違いと設計上の注意点
ZTNAはゼロトラストを実現するための重要なアクセス制御技術ですが、 ID管理、端末管理、データ保護、ログ監視なども必要です。
全通信を拒否することが目的ではありません。 必要な情報を確認し、 条件を満たしたアクセスを適切に許可します。
VPN自体が安全でないという意味ではありません。 VPNでもMFAやアクセス制御を組み合わせられます。 要件に応じてVPNとZTNAを使い分けます。
MFAは本人確認を強化する重要な要素ですが、 ZTNAではさらに端末状態やアクセス先などを含めて 認可を設計します。
既存アプリケーションの通信要件や依存関係によっては、 ZTNAへ適用しにくい場合があります。 対象を選定し、段階的に移行する方法も検討します。
ZTNA設計の中心は製品ではなくアクセス要件です。 利用者、端末、リソース、条件を整理したうえで、 必要な製品機能を選定します。
顧客・上司へZTNAをどう説明するか
技術に詳しくない相手へ説明するとき、 「ゼロトラストなので毎回コンテキストベースで認証・認可します」 と説明しても目的が伝わりにくい場合があります。
従来VPNとの違いから説明する
説明例：
「従来のVPNは、認証した利用者をまず社内ネットワークへ接続し、 その後にファイアウォールなどでアクセス範囲を制御する方式が中心でした。 ZTNAでは、利用者や端末を確認したうえで、 最初から業務に必要なアプリケーションだけへアクセスさせます。 そのため、不要な社内システムへの到達範囲を小さくできます。」
技術をリスクへ変換する
| 技術的な説明 | 業務・リスクの説明 |
|---|---|
| アプリ単位のアクセス制御 | 利用者に不要なシステムを見せない |
| 利用者認証 | 正規利用者か確認して不正利用のリスクを減らす |
| 端末状態の確認 | 条件を満たさない端末から重要システムへ接続させない |
| 最小権限 | アカウント侵害時の影響範囲を小さくする |
| アクセスログ | 事故発生時に利用状況を追跡しやすくする |
上級エンジニアには、 「ZTNAという新しい技術だから採用する」ではなく、 どのリスクを減らし、どの業務要件を満たすために採用するのか を説明する力が求められます。
ZTNAで使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| Zero Trust | ゼロトラスト |
| Zero Trust Network Access | ゼロトラストネットワークアクセス |
| Identity | ID・利用者情報 |
| Authentication | 認証 |
| Authorization | 認可 |
| Least privilege | 最小権限 |
| Access policy | アクセスポリシー |
| Device posture | 端末の状態・セキュリティ状態 |
| Resource | 保護対象となるリソース |
| Continuous verification | 継続的な確認・検証 |
設計・資料で使われる表現
Access should be granted based on user identity and device posture.
アクセスは、利用者のIDと端末状態に基づいて許可する必要があります。
Users should only have access to the applications required for their role.
利用者には、その役割に必要なアプリケーションだけへのアクセスを許可すべきです。
Multi-factor authentication is required for administrative access.
管理アクセスには多要素認証が必要です。
Access attempts should be logged for security monitoring.
アクセス試行はセキュリティ監視のため記録する必要があります。
海外ベンダーのZTNA資料では、 identity、device posture、least privilege、policy といった単語が頻繁に登場します。 単語だけでも覚えておくと公式ドキュメントを読みやすくなります。
理解度チェック
記事の内容を確認するため、 次の5問に答えてください。
問題1．ZTNAの考え方として最も適切なものはどれですか。
- 社内LANからの通信をすべて許可する
- VPN認証に成功した利用者へすべての社内ネットワークを公開する
- 利用者や端末などを確認し、必要なリソースだけへのアクセスを許可する
- インターネット通信をすべて禁止する
解答を見る
ZTNAでは、ネットワークの場所だけを理由に信頼せず、 利用者や端末などを確認し、 許可されたリソースだけへのアクセスを提供します。
問題2．Zero TrustとZTNAの関係として適切なものはどれですか。
- まったく同じ意味である
- ZTNAはZero Trustの考え方をアクセス制御へ適用する仕組みの一つである
- Zero TrustはVPN製品の名称である
- ZTNAはルーティングプロトコルである
解答を見る
Zero Trustはより広いセキュリティの考え方であり、 ZTNAはその原則をアプリケーションアクセスへ適用する 仕組みの一つです。
問題3．ZTNAでアクセスを判断するときに利用できる情報を3つ挙げてください。
解答例を見る
例：
- 利用者ID・所属・役割
- 認証結果
- 端末状態
- 対象アプリケーション
実際に利用できる条件は製品・構成によって異なります。
問題4．「ZTNAを導入すればVPNは必ず廃止できる」は正しいですか。
解答を見る
アプリケーションやプロトコル、 管理通信などの要件によってはVPNを残す場合があります。 ZTNAとVPNを段階的に併用する構成も考えられます。
問題5．営業部の社員がCRMだけを利用する場合、 最小権限の考え方として適切なのはどれですか。
- CRMと同じネットワークにあるすべてのサーバーを許可する
- 社内ネットワーク全体を許可する
- 営業部が必要とするCRMへのアクセスだけを許可する
- 認証を行わずCRMを公開する
解答を見る
業務に必要な範囲だけを許可し、 不要なアクセス権を与えないことが重要です。
実践演習：リモートアクセスをZTNAで設計する
あなたは、ある企業から リモートアクセス環境の見直しを依頼されました。
現在の環境
- 社員数：300名
- テレワーク利用者：約200名
- 現在はリモートアクセスVPNを利用
- VPN接続後は社内の複数ネットワークへ到達可能
- 営業部はCRMを利用
- 人事部は人事システムを利用
- インフラ管理者はサーバー管理システムを利用
- 外部委託先10名には業務Webシステムだけを利用させたい
- 社員PCは会社管理端末
- 外部委託先は指定端末を使用
- 重要システムではMFAを利用したい
課題1．アクセス対象を整理する
次の利用者について、 必要なアクセス先を整理してください。
| 利用者 | 必要なアクセス先 |
|---|---|
| 営業部 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| 人事部 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| インフラ管理者 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| 外部委託先 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
課題1の解答例を見る
- 営業部：CRM
- 人事部：人事システム
- インフラ管理者：サーバー管理システム
- 外部委託先：指定された業務Webシステム
課題2．アクセスポリシーを作る
「利用者」「端末」「認証」「アクセス先」の4項目を使って、 簡易ZTNAポリシーを作成してください。
人事部：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
管理者：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
委託先：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
課題2の解答例を見る
営業部
営業部所属＋会社管理PC＋認証成功 → CRMのみ許可
人事部
人事部所属＋会社管理PC＋MFA → 人事システムのみ許可
インフラ管理者
管理者グループ＋指定管理端末＋MFA → サーバー管理システムのみ許可
外部委託先
委託先アカウント＋指定端末＋MFA → 指定業務Webシステムのみ許可
課題3．現行VPNのリスクを3つ挙げる
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
課題3の解答例を見る
- VPN接続後に業務上不要なネットワークまで到達できる可能性がある
- アカウント侵害時に横方向へ探索される範囲が広くなる可能性がある
- 外部委託先へ必要以上のネットワーク到達性を与える可能性がある
ただし、現行VPNですでにACLやファイアウォールで 十分な制御を行っている可能性もあります。 実際の構成を確認したうえで判断してください。
課題4．移行時に確認すべき事項を挙げる
VPNからZTNAへの移行を検討する場合、 技術的に確認すべき項目を5つ以上挙げてください。
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
課題4の解答例を見る
- 対象アプリケーション一覧
- 利用プロトコル・ポート
- ID基盤との連携方式
- MFAの利用方法
- 端末管理・端末状態の取得方法
- ZTNA製品が対象アプリケーションへ対応できるか
- ログの取得・保管・監視方法
- 既存VPNを残す通信の有無
- 障害時の切り戻し方法
- 利用者への展開・教育方法
課題5．顧客へZTNA導入理由を説明する
顧客から次の質問を受けました。
「今のVPNでも接続できているのに、 なぜZTNAを検討する必要があるのですか？」
説明例を見る
現在のVPNを使い続けること自体が問題なのではありません。 今回確認したいのは、VPN接続後に利用者へ必要以上の ネットワークアクセスを与えていないかという点です。
ZTNAでは、営業部ならCRM、外部委託先なら指定業務システムというように、 利用者と端末を確認したうえで必要なアプリケーションだけを提供できます。 これにより、アカウントが侵害された場合などでも、 不要なシステムへ到達できる範囲を小さくすることが期待できます。
ただし、既存VPNが必要な通信もある可能性があるため、 すべてを一度に置き換えるのではなく、 対象アプリケーションを確認しながら段階的な移行を検討します。
自分の言葉で説明する課題
後輩エンジニアから、 次のように質問されました。
「VPNとZTNAって、結局何が違うんですか？」
説明例を見る
VPNは、離れた場所にいる利用者を 社内ネットワークへ安全に接続するための仕組みとして 広く使われています。
一方ZTNAは、 利用者をネットワーク全体へ接続することよりも、 誰が、どの端末から、 どのアプリケーションを利用してよいかを判断し、 必要なリソースだけへアクセスさせることを重視します。
つまり、 VPNは「ネットワークへどう接続するか」、 ZTNAは「どのリソースへアクセスさせるか」を より中心に考える点が大きな違いです。
まとめ
- ZTNAはZero Trust Network Accessの略で、 利用者・端末などを確認し、必要なリソースだけへのアクセスを許可する
- Zero Trustはセキュリティ全体の考え方であり、 ZTNAはその考え方をアクセス制御へ適用する仕組みの一つ
- 「社内だから信頼する」「VPN接続済みだから信頼する」 というネットワーク位置だけの判断に依存しない
- 利用者ID、認証、端末、アクセス先などを組み合わせて アクセスポリシーを設計する
- 業務に必要なアプリケーションだけを許可する 最小権限の考え方が重要
- VPNとZTNAは必ずしも完全な二者択一ではなく、 要件によって併用や段階移行も検討する
- SASEでは、ZTNAがアクセス制御を担う セキュリティ機能の一つとして利用されることが多い
- ZTNA設計ではネットワークだけでなく、 ID、端末管理、アプリケーション、ログ監視などを横断して考える
- 製品を選ぶ前に、 「誰が・どの端末で・何へ・どの条件でアクセスするか」を整理する
上級エンジニアが覚えるべきなのは 「ZTNAという製品を導入すること」ではありません。 利用者へ必要なアクセスだけを提供し、 不要な到達範囲を減らすという設計思想です。
参考資料
- NIST SP 800-207「Zero Trust Architecture」
- CISA「Zero Trust Maturity Model」
※ZTNAの具体的な構成、機能、対応プロトコル、端末確認方法などは 製品・サービスによって異なります。 実際の設計では利用予定製品の公式ドキュメントを確認してください。
第30回で「第3章：高度なネットワーク技術」の個別記事は完了です。 学んだ技術を実際の要件へ当てはめる章末演習に進みましょう。
コメント