ZTNA（Zero Trust Network Access）は、アクセス方針に基づいて業務アプリへの接続を制御する技術です。導入を検討するときは、「誰が、どの端末から、どのアプリへ、どの条件で接続するか」を一つずつ整理します。CloudflareのZTNA解説
企業のIT担当者が最初に作る資料は、製品の機能一覧よりも、対象アプリの接続条件表が適しています。本記事では、その記入項目と試行時の確認手順を整理します。以下の確認表と判定手順は、公開資料を踏まえた導入検討用の提案です。
ZTNAとゼロトラスト・VPNの関係
ゼロトラストは、社内ネットワークにいる、会社所有の端末である、といった理由だけで信頼を与えない考え方です。NISTは、資源へのセッションを確立する前に、利用主体と端末の認証・認可を扱うと説明しています。NIST SP 800-207
ZTNAの検討では、この考え方を業務アプリへのアクセス条件へ落とし込みます。全体の考え方を先に整理したい場合は、ゼロトラストの基本も参照してください。
VPNからの移行を考える場合も、製品名だけで比較せず、現行環境で許可している接続先を洗い出します。「営業担当者は販売管理を使えるが、サーバーの管理画面には接続させない」という要件を、現行構成と候補のZTNAでそれぞれ説明できるかが比較の軸です。
移行対象は「VPN利用者全員」と一括りにせず、利用者とアプリの組み合わせで決めます。許可する接続先が決まらない段階では、対象アプリの棚卸しから始めましょう。
接続条件を端末・認証・経路に分ける
端末：クライアントを入れられるか、何を確認したいか
会社管理のPCと委託先のPCは、別の条件として記録します。OS、端末管理の有無、ソフトウェアを導入できる権限、接続時に確認したい端末の状態を挙げてください。
方式の例として、Cloudflareは利用者の端末にソフトウェアを入れず、ブラウザーからWebアプリやSSH・RDPの接続を利用するクライアントレス方式を説明しています。一方、端末クライアントには詳細な端末状態の検査などを追加できるとしています。Cloudflareのクライアントレス方式
「ソフトを入れなくてよいか」と「必要な端末条件を判定できるか」は、別々に確認します。ブラウザー経由で行う業務と、専用アプリから行う業務も分け、候補製品でそれぞれ試す対象にしましょう。
認証：本人確認と利用許可を具体化する
利用者の本人確認を担うIdP（IDプロバイダー）、接続を認めるグループ、多要素認証の条件、委託終了時の権限削除を整理します。
製品例では、Microsoft Entra Private Accessはアプリへユーザー・グループを割り当て、Conditional Accessでアクセスを制御する構成を説明しています。Microsoft Entra Private Accessの概要
検討時は「認証できたら全員許可」になっていないか、アプリごとに点検してください。アプリ内の閲覧・更新・承認権限についても、どこで設定するかを記録し、接続の許可とは分けて試験します。
経路：接続先の名前からアプリまでを追う
前述のMicrosoftの資料では、内部資源をFQDN（完全修飾ドメイン名）やIPアドレスで指定し、コネクターがサービスと内部資源の接続を仲介する構成が示されています。
このような構成を検討する際は、アプリ名だけでなく、実際の接続先、名前解決、通信プロトコル・ポート、中継点を記入します。DNSの用語を整理する必要があれば、DNSレコードの種類と役割を確認してください。
画面が表示できることに加え、ログイン後の別画面、ファイルの取得、外部システムへの連携までを確認対象にします。それぞれの操作で使う接続先をアプリ担当者に確認し、許可範囲へ追加する必要があるか判断しましょう。
アプリごとの導入前確認表
次の表は、アプリごとに一枚作る想定です。「対応済み」だけで終わらせず、設定値か確認相手を残します。空欄は導入不可と即断せず、検証前に解消する事項として扱ってください。
| 確認軸 | 記入する内容 | 自社の記入欄 |
|---|---|---|
| 業務と責任者 | アプリ名、必要な操作、業務責任者 | ［記入］ |
| 利用者 | 社員・委託先の区分、許可グループ、利用終了日 | ［記入］ |
| 端末 | OS、管理状況、クライアント導入可否、要求する端末条件 | ［記入］ |
| 認証 | IdP、多要素認証の条件、権限付与・削除の担当 | ［記入］ |
| 接続先 | FQDN/IP、プロトコル、ポート、追加の通信先 | ［記入］ |
| 経路 | DNSの参照先、コネクター等の配置、既存経路との関係 | ［記入］ |
| アプリ内権限 | 閲覧・更新・管理権限を設定する場所と担当 | ［記入］ |
| 運用 | ログ確認者、問い合わせ先、障害時の対応者 | ［記入］ |
| 未確認事項 | 確認内容、確認相手、回答期限 | ［記入］ |
表を作ったら、端末・ID・ネットワーク・アプリの担当者で突き合わせます。委託する場合も、この表を使って「自社が決める許可条件」と「委託先に確認・構築を依頼する範囲」を明確にできます。
小さく試し、許可と拒否の両方を確認する
最初は、業務責任者と必要な通信先を特定できるアプリを選びます。対象者、試行期間、合格条件、切り戻しの責任者を決めてから検証に入る手順が適しています。
| 試験 | 確認する結果 |
|---|---|
| 許可された利用者・端末で接続 | ログインから必要な業務操作まで完了する |
| 対象外の利用者で接続 | 対象アプリへのアクセスを拒否する |
| 必須の端末条件を満たさず接続 | 定義した方針どおりに拒否する |
| グループから削除し、再接続・既存セッションを確認 | 許可が失効する条件と反映時間を把握できる |
| 名前解決や中継点の障害を想定 | 調査の担当と復旧手順を説明できる |
| 既存経路との併用を確認 | 別経路から同じアプリへ接続できる条件を把握する |
権限を削除した後の既存セッションの扱いは、推測せず検証結果を残します。障害試験も、業務影響を抑えられる検証環境や範囲で行ってください。
移行可否は、「必要な業務ができる」「許可していないアクセスを拒否できる」「担当者が障害対応を行える」の三点で整理します。条件を満たせないアプリは未解決事項を残し、条件が整ったアプリから対象を広げる進め方が考えられます。
ZTNA導入の第一歩は、対象アプリを一つ選び、確認表の空欄を埋めることです。製品比較へ進む前に、自社が必要とするアクセス条件と、その条件を検証する方法を揃えましょう。