ZTNA（ゼロトラストネットワークアクセス）とは?

ZTNA とは

ZTNA（Zero Trust Network Access）とは、ユーザーとデバイスを信頼せず、アクセス要求が発生するたびに、ユーザーの本人確認、接続元デバイス、要求する業務システム、アクセスがポリシーに適合しているかを検証した上で、必要なアプリケーションだけへのアクセスを許可するセキュリティモデルです。

従来のネットワークセキュリティは VPN とファイアウォールを中心に運用され、ファイアウォールは外部と内部ネットワークの境界を保護し、VPN は外部ユーザーが内部ネットワークへ接続できる暗号化された経路を提供してきました。このセキュリティモデルは、ネットワーク境界が明確な環境では効果的でした。しかし、企業環境は変化し、業務システムはオンプレミスだけでなくクラウドや SaaS へ拡張され、ユーザーはオフィスの外からも複数の業務アプリケーションへアクセスします。その結果、ネットワーク境界が曖昧になり、セキュリティチームは、ユーザーが内部ネットワークへ接続したかどうかだけでアクセスの可否を判断することが難しくなりました。

従来のネットワークセキュリティモデルの限界

従来のネットワークセキュリティモデルは、ファイアウォールと VPN を中心に内部と外部の境界を分け、正規の経路でアクセスしたユーザーを信頼する方式です。ファイアウォールはネットワーク境界でトラフィックを制御し、VPN は外部ユーザーによる内部システムへの安全な接続を支援します。この方式は、企業ネットワークの内部と外部の境界が明確な環境では効果的でしたが、クラウド、SaaS、オンプレミスシステムへ同時にアクセスする業務環境では、ネットワーク境界だけですべてのアクセスを詳細に判断するのは困難です。

従来のセキュリティモデルには、認証後にもセキュリティ上の弱点があります。従来のファイアウォールはネットワークへアクセスしたユーザーを信頼するため、アカウント窃取などによって内部への接続に成功されると、内部での活動を制御することが困難です。そのため、セキュリティチームは、ログインしたかどうかではなく、どのデバイスから接続したか、どのアプリケーションへアクセスするか、そのアクセスが業務目的に合っているかも確認しなければなりません。さらに、1 回の認証で終わるのではなく継続的に検証し、ネットワーク全体ではなく、必要なアプリケーションだけへ接続するように設計します。

Zero Trust に基づくアクセス制御

Zero Trust はすべてのアクセスを信頼しないセキュリティ原則であり、アクセス要求が発生するたびに条件を確認し、必要な範囲に限って権限を付与します。

ZTNA は、この原則をネットワークアクセス制御へ適用します。ユーザーが特定の業務システムへ接続しようとすると、ユーザーの本人確認に加え、デバイスの状態、接続場所、MFA の適用有無、ユーザーの役割、要求したアプリケーションも確認します。条件を満たしていればアクセスを許可し、満たしていなければ遮断または追加認証を要求できます。

ZTNA の中核は、ユーザーをネットワーク全体へ接続せず、ポリシーで許可されたアプリケーションとリソースだけにアクセスを制限することです。たとえば、財務担当者が会計システムへアクセスする場合、ZTNA は会計システムへのアクセスだけを許可します。ユーザーにアクセス権限のない開発サーバー、管理者コンソール、他部署の業務システムは表示されないか、接続できません。この構造により、攻撃者がアカウントを確保した場合でも、内部で移動できる範囲を狭められます。

ZTNA の仕組み

ZTNA は一般的に、ユーザーと業務アプリケーションの間でアクセス要求を検証します。ユーザーが特定のアプリケーションへアクセスしようとすると、ZTNA はその要求が事前定義されたポリシーに適合しているかを確認します。この過程で、Identity Provider、Single Sign-On、MFA、エンドポイントセキュリティソリューション、Mobile Device Management、セキュリティ分析システムと連携して確認できます。

一般的な ZTNA の動作フローは次のとおりです。

• ユーザーが内部の業務アプリケーションへのアクセスを要求

• ZTNA がユーザーの本人確認、または既存の認証セッションが有効かどうかを検証

• システムがユーザーの役割、グループ情報、MFA の適用有無、デバイスの状態、接続場所、ネットワーク環境など、アクセスのコンテキストを確認

• 要求がポリシー条件を満たすと、ZTNA がユーザーと該当アプリケーションの間に限定的な接続を作成

• ユーザーは内部ネットワーク全体ではなく、許可されたアプリケーションだけへアクセス

• セッション中も、場所の変更、デバイスのセキュリティ状態の変化、異常なアクセスパターンなどのリスクシグナルが現れた場合は、アクセスを再評価またはセッションを終了

ZTNA は、アプリケーションアクセスとネットワークアクセスを分離します。ユーザーが認証を完了した場合や特定のネットワークへ接続した場合でも、すべての内部システムへアクセスできるわけではありません。アクセス権限のないアプリケーション、サーバー、内部 IP には接続されないため、攻撃者が侵入しても、内部構造の探索や他のシステムへ移動する経路を最小限に抑えられます。

ZTNA の主な検証要素

ZTNA は単なるログインシステムではありません。アクセス要求時に発生するさまざまなシグナルを確認し、アクセスが業務目的に合っているかを判断します。

ユーザーの本人確認

ZTNA はユーザーの本人確認を行い、従業員、協力会社、管理者などのアカウント権限に応じてアクセスを許可します。同じアプリケーションでも、一般ユーザーと管理者では必要な権限や作業が異なるため、ロールベースのポリシーが必要です。

デバイスの状態

同じアカウントで接続した場合でも、デバイスによってセキュリティ上の弱点が生じる可能性があります。安全な接続のため、デバイスの管理状態、セキュリティパッチの適用状況、エンドポイントセキュリティソリューションのインストール状況などを確認しなければなりません。感染しているデバイスやセキュリティ状態を確認できないデバイスは、正規アカウントでログインした場合でもアクセスを制限する必要があります。

場所と接続環境

ユーザーが普段とは異なる国やネットワークから接続した場合や、通常とは異なる時間帯に機密システムへのアクセスを試みた場合は、追加の検証が必要です。位置情報だけで遮断の可否を決めることはできませんが、デバイスの状態やアカウントなどの追加シグナルと組み合わせて脅威レベルを把握できます。

アプリケーションと権限

アクセスを試みるアプリケーションの権限も重要です。一般的なコラボレーションツールと、管理者コンソール、開発システム、顧客データベースなどの機密システムに、同じレベルのセキュリティを適用すべきではありません。ZTNA は、ユーザーが要求したアプリケーションの重要度とユーザーの役割を検証し、アクセスの可否を決めます。この過程で最小権限の原則を適用し、業務に不要なアクセスを最小限に抑えられます。

セッションとユーザーの行動

アクセスの許可後も、ユーザーの行動を継続して確認しなければなりません。普段使わないシステムへのアクセス、短時間での複数アプリケーションへの接続、管理者機能の繰り返し呼び出しといった行動は、追加確認が必要になる場合があります。ZTNA は、こうした行動がポリシー条件を満たさない場合、追加認証、セッション終了、アクセス記録の確認を要求できます。

ZTNA で対応できる攻撃

ZTNA は、マルウェアを直接検知したり脆弱性を解消したりする技術ではありません。前述の要素を継続的に検証し、攻撃が内部システムへ拡散しないよう制限します。アクセス対象を業務に必要なアプリケーションへ限定し、最小権限の原則に基づいて、攻撃者が侵入した場合でも、その後アクセスできる範囲を大幅に制限することを目的とします。

アカウント窃取攻撃

攻撃者は、フィッシング、認証情報の漏えい、セッション窃取などを通じて正規アカウントを確保する可能性があります。攻撃者がそのアカウントで接続した場合、ログイン自体は正規ユーザーと同じように見えます。ZTNA は、アカウントが認証済みでもネットワーク全体を公開せず、ポリシーで許可されたアプリケーションとリソースだけにアクセスを制限します。そのため、攻撃者がアカウントを確保しても、アクセス可能な範囲が狭まります。

ラテラルムーブメント（Lateral Movement）

ラテラルムーブメント（Lateral Movement）とは、攻撃者が 1 つのアカウントやシステムを足掛かりに、別のサーバー、アプリケーション、管理者コンソールへ移動する過程です。従来のネットワークアクセス方式では、認証後、同じネットワーク内の他のシステムにも容易に接続できます。ZTNA は許可された対象だけへの接続を提供するため、攻撃者が内部構造を確認したり、追加のシステムへ移動したりする経路を最小限に抑えられます。

権限の悪用

業務に不要な権限が広く付与されていると、アカウント窃取、内部脅威、操作ミスによるデータ露出につながる可能性があります。ZTNA は最小権限の原則を適用し、ユーザーが業務に必要なアプリケーションとリソースだけを利用するよう制限します。これにより、攻撃者が窃取したアカウントで利用できる権限を減らし、正規ユーザーや内部関係者が不要なシステムへアクセスする状況も抑えられます。

ZTNA と VPN の違い

ZTNA と VPN は接続対象が異なります。VPN はネットワークへの接続を許可し、必要なシステムを利用する方式です。一方、ZTNA はユーザーを必要なアプリケーションだけへ接続するため、権限のない資産は公開されません。

区分	VPN	ZTNA
アクセス対象	ネットワーク中心	アプリケーション中心
信頼方式	認証後に接続を許可	アクセス要求ごとに条件を確認し、継続的に検証
アクセス範囲	ネットワーク単位で広がる可能性がある	許可されたアプリケーションに限定
主な制御方式	トンネリング、ファイアウォールポリシー、ネットワーク分離	本人確認、デバイスの状態、ポリシー、セッション
アカウント窃取時のリスク	内部探索や移動の可能性が増加	アクセス可能な対象を縮小
適した環境	レガシーシステム、ネットワークレベルの接続	クラウド、SaaS、リモートアクセス、協力会社からのアクセス

こうした違いは、セキュリティの運用方式にも影響します。VPN 環境では、ファイアウォールポリシー、ネットワーク分離、アカウント権限によってアクセスを管理します。ZTNA 環境では、アプリケーション単位でアクセスを許可し、ユーザーとデバイスの状態も併せて確認するため、単にネットワークへの接続に成功したという理由だけで広範な権限を付与することはありません。

ZTNA を導入しても、VPN のすべての機能を代替するわけではありません。レガシーシステム、特殊な管理アクセス、ネットワークレベルの接続が必要な環境では、引き続き VPN が必要です。一方、外部アクセスの多い業務システム、協力会社からのアクセス、クラウドアプリケーション、管理者ポータルなど、アクセス範囲を狭く管理すべき領域には ZTNA がより適している場合があります。

ZTNA の導入方式

ZTNA は環境に応じてさまざまな方式で導入でき、管理対象デバイス、アプリケーションの種類、協力会社からのアクセス有無、クラウド利用の比重に基づいて選択します。

エージェントベース ZTNA

エージェントベース ZTNA は、ユーザーデバイスへ ZTNA エージェントをインストールし、アクセス要求とデバイスの状態を確認する方式です。企業が管理するデバイスへ適用しやすく、管理者アカウントや機密性の高い内部システムへのアクセスを制御する際に役立ちます。デバイスのセキュリティ状態を比較的詳細に確認できる一方、協力会社や外部人材など、企業が直接管理していないデバイスでは適用の負担が生じる可能性があります。

エージェントレス ZTNA

エージェントレス ZTNA は、ユーザーデバイスへ別途エージェントをインストールせずにアクセスを制御する方式です。主に Web ベースのアプリケーションや SaaS のアクセス制御に使われ、協力会社、外部委託スタッフ、一時的なアクセス権限が必要なユーザーにも適用しやすい方式です。ただし、デバイスの状態を直接確認することが難しいため、管理対象端末に比べて、デバイスのセキュリティ状態を詳細に確認・判断する上で限界があります。

クラウドベース ZTNA

クラウドベース ZTNA は、クラウドサービスを利用してアクセスポリシーを適用する方式です。ユーザーとアプリケーションが分散した環境で、一貫したアクセスポリシーを適用しやすいという特徴があります。SaaS、クラウドアプリケーション、リモートワーク環境など、ユーザーが特定のネットワーク内にいなくても業務システムへアクセスする必要がある構造に適しています。ただし、既存のオンプレミスシステムと併用する場合は、連携構造を事前に調整しなければなりません。

ハイブリッド ZTNA

ハイブリッド ZTNA は、オンプレミスシステムとクラウドアプリケーションを併せて保護するために使われる方式です。レガシーシステムを維持しながら、一部のアプリケーションを ZTNA へ移行する必要がある企業にとって、現実的な選択肢となり得ます。オンプレミス環境では、既存のファイアウォール、VPN、IAM、MFA、EDR、SIEM と併用されるケースが多いため、どのシステムから移行し、どのアクセスを従来方式のまま維持するかを整理する必要があります。

ZTNA と SASE

ZTNA を検討する際、SASE（Secure Access Service Edge）という用語も目にします。両者には関連がありますが、同じ意味ではありません。ZTNA はユーザーとアプリケーションまたはリソース間のアクセスを制御するセキュリティアーキテクチャであり、SASE はネットワーク機能とセキュリティ機能をクラウドベースで統合する、より広いフレームワークです。

SASE は、分散したユーザーとアプリケーションを保護するため、さまざまなセキュリティ機能を併用します。ZTNA に加え、SWG（Secure Web Gateway）、CASB（Cloud Access Security Broker）、FWaaS（Firewall as a Service）、SD-WAN などが含まれる場合があります。つまり、ZTNA は SASE においてアプリケーションアクセス制御を担う中核要素の 1 つといえます。

たとえば、ユーザーが SaaS アプリケーションや内部の業務システムへ接続する際、ZTNA はそのユーザーにアクセス権限があるかを検証します。同時に SASE 環境では、Web トラフィックセキュリティ、クラウドアプリケーション制御、ファイアウォールポリシー、ネットワーク経路の管理も適用できます。

企業が ZTNA と SASE を併せて検討するのは、アクセス制御だけでは分散した業務環境全体を保護することが難しいためです。ZTNA が誰にどのアプリケーションへのアクセスを許可するかを判断するのに対し、SASE はどこから接続しても、ネットワークポリシーとセキュリティポリシーを一貫して適用する方法に重点を置きます。

ZTNA 導入前の検討事項

ZTNA の導入では、どのソリューションを導入するかではなく、どのアプリケーションを保護し、どのユーザーがどの権限でアクセスすべきかを整理しなければなりません。こうした基準がなければポリシーが複雑化し、例外ポリシーが増えて、期待するセキュリティ効果を得られなくなります。

保護するアプリケーションとデータの識別

すべてのシステムを一括して移行しようとすると、ポリシー設計が複雑になります。外部からのアクセスが多いアプリケーションや機密データに接続されたアプリケーションとデータを識別し、それに基づいて優先順位を決めます。

ユーザーグループとアクセス権限の整理

従業員、協力会社、外部委託スタッフ、管理者アカウントでは、アクセスの目的と権限の範囲が異なります。ユーザーグループごとに、どのアプリケーションへアクセスすべきかを先に整理します。

IdP、SSO、MFA の連携状況の確認

ZTNA は本人確認に基づいて動作します。既存の IdP、SSO、MFA の仕組みが整備されていなければ、アクセスポリシーも安定して運用できません。

デバイス状態の確認基準を定義

管理対象デバイスと管理対象外デバイスをどのように区別するかを定義します。セキュリティパッチ、ウイルス対策ソフトまたは EDR の動作状況、デバイスの登録状態などをポリシー条件として利用できます。

高リスクのアプリケーションから段階的に適用

管理者ポータル、開発システム、顧客情報システム、協力会社のアクセスシステムなど、リスクの高い領域から適用するのが現実的です。段階的に適用することで、ユーザーの不便や運用停止を最小限に抑えられます。

ログとポリシー例外の確認

ZTNA ポリシーは、一度作成すれば終わりではなく、継続して確認・見直しを行います。アクセスログを確認し、過剰な権限、繰り返し発生する例外、異常なアクセスパターンを継続的に調整しなければなりません。

ZTNA 導入時の注意点

ZTNA はアクセスベースのセキュリティを詳細に適用できますが、導入過程で運用負担が生じる可能性があります。既存のシステム構造やユーザーの業務フローを十分に検討しないと、セキュリティは強化されても業務の遅延が発生するおそれがあります。

最初に確認すべきなのはレガシーシステムです。古い内部アプリケーションには、最新の認証方式やプロキシベースのアクセス制御を適用できない可能性があります。この場合、システム構造の変更、例外ポリシーの設定、VPN と ZTNA の併用などの措置が必要です。

ユーザーエクスペリエンスも重要です。認証や再検証が頻繁に発生しすぎると、業務の継続性を妨げる可能性があります。リスクの低い一般業務と機密性の高い管理者作業に同じレベルの検証を要求すると、運用効率が低下します。そのため、アクセス対象の重要度とリスクレベルに応じて、ポリシーの強度を変えて設計します。

例外ポリシーの管理にも注意が必要です。協力会社、緊急作業、一時的な管理者権限など、例外が必要な状況は常に存在します。しかし、こうした例外が蓄積すると、最小権限の原則が崩れます。例外権限には、有効期限、承認手順、アクセスログ、権限回収の基準も併せて設けなければなりません。

ZTNA は、ファイアウォール、VPN、IAM、MFA、EDR、SIEM を代替する単一の技術ではありません。アクセス制御をより詳細にする役割を担い、他のセキュリティ体制と併用することで効果が高まります。セキュリティチームは ZTNA の導入時に、既存のセキュリティツールとどのようなシグナルを交換し、どのイベントを監視するかも併せて設計します。

FAQ

アンラボの ZTNA ソリューション

アンラボは、次世代ネットワークファイアウォールソリューション AhnLab XTG を基盤とした ZTNA の実装を支援します。AhnLab XTG は、ユーザーとデバイスの本人確認およびセキュリティ状態を継続的に確認し、検証済みのユーザーだけにアクセスを許可する ZTNA 機能により、Zero Trust アーキテクチャの構築を支援します。また、暗号化トラフィック分析とアプリケーション単位のポリシー設定機能によってネットワークの可視性を高め、国内外の主要アプリケーションに対する高度なセキュリティ機能を提供し、さまざまな脅威へ効果的に対応できます。

AhnLab XTG 製品ページへ移動

AhnLab XTG リリース！次世代ファイアウォールを超えるセキュリティ