セキュリティ対策の基本的な考え方は、城壁を立てたり、検問を作ったりして、境界を設けることで安全を守ろうとするものだ。外敵などの侵入を防げば、境界内は安全とする。もちろんいまでも有効でセキュリティ対策の基本である。

ITやネットワークの世界では、ユーザーにログインアカウントを与えて許可された人間しかシステムやネットワークにアクセスできないようにする。あるいは、ゲートウェイやルーターを利用して、外部のネットワーク（インターネットなど）と内部のネットワーク（イントラネット）を分離させる。ファイアウォール（防火壁）は、インターネットとイントラネットの境界に設置して、不正アクセスや不審な通信をブロックする防壁の役目を果たす。

しかし、防壁による境界防衛だけでは外敵の侵入は100％防げない。そのためにアンチウイルスソフト、次世代ファイアウォール（IPS/IDS）、ログおよびネットワーク監視、リスクベース認証・多要素認証、暗号化通信といった技術が発展してきたわけだ。境界防衛の限界を認識しつつも、ネットワークの外と内を分ける境界そのものは維持する形でセキュリティ対策は進化していった。

この状況を大きく変えたのは、おそらくコロナパンデミックだ。ロックダウン政策により、一般的な業務もオンラインやリモート環境で作業せざるを得ない状況になり、ネットワークの境界に対する考え方を変える必要が生じた。自宅や外出先からイントラネット内の情報資産やシステムにアクセスさせるため、インターネットからの通信の選別が難しくなったからだ。

リモートワークが出張者や限られた社員に限定できれば、VPNのような専用の通信路で管理できる。VPNは原則として1対1通信なので、人数分のコストをかけてVPN回線を用意しなければならない。全社員がリモート接続しなければならないとなると、インターネットからのオープンなアクセスをとりあえず許可しなければならない。

オープンな回線からイントラネットへのアクセスはログイン認証などで保護するしかなくなるが、アカウントによる認証は、フィッシングやパスワードリスト攻撃などによって、もはや安全とはいいきれない。業務サーバーがログイン認証だけで済ませていたのは、外部からのアクセスが限定されたVPNや、会社の建物内のPCを利用しなければならないという制約があって、一定の安全が保たれているからだ。

リモート接続を前提とすると、インターネットとイントラネットを区別してもあまり意味がない。ZTNAでは、ボーダーレスという考え方を採用する。イントラネット内の通信は安全ではない、社内のシステムはファイアウォールの内側で守られているのではなく、インターネット（少なくともDMZ上）に曝されていると考えるべきだ。

ZTNAの考え方が生まれたのは、コロナパンデミックが背景にあるのは確実だが、もうひとつ重要なパラダイムシフトがある。それはITシステムのクラウド化だ。クラウドの動きはかれこれ10年以上になる。ASPやSaaSから始まった変革は、AWSの出現によって、ITシステムの所有・利用形態を一変させた。

以前は（一定以上の規模を持つ）企業のメールサーバーはサーバールームやデータセンターに自社リソースとしてハードウェアを購入して構築することが一般的だった。その他の業務システムも同様だ。現在、業務システムの多くはクラウド上の仮想環境に構築される。一部はプライベートクラウドとして、インターネットに接続していない状態で構築され専用線でアクセスする構成もあるが、パブリッククラウドにインターネット経由でアクセスする構成も少なくない。

イントラネットの安全性の一部が、物理的に隔離されたエリア（建物内）のネットワークだからという理由に由来するなら、クラウドインフラはイントラネットとインターネットの境界をあいまいにする。

クラウドインフラの実体は、大規模データセンターであり堅牢性や信頼性は並みのオンプレミスシステムの比ではない。外部からの侵入は物理的にも電子的にも極めて困難だ。だが、クラウド内の他テナントのリソース、システムとの分離は、基本的に契約アカウントの認証情報とセッションのセキュリティキーに依存する。クラウドシステムのセキュリティインシデントは、アカウントや認証に起因するものが多い。

ZTNAは、ネットワークの状態を原則として信用しない。正規アカウントでログインしているユーザーも、侵入者である可能性を考慮する。ゼロトラストなネットワークとして、以下のような手法により、安全なアクセスを実現することを考える。

・最小権限の原則
・認証の強化（多要素認証など）
・リスクベースの動的なアクセス制御

まず、システムにログインした状態では、どのアカウントも権限を最小にしておく。いわばアカウントのデフォルトはゲストアカウントとするようなものだ。たとえシステム管理者や経営者のアカウントでもこのポリシーを適用する。

アカウントの管理は、ID、パスワードによる認証が原則となるが、それだけの認証では、安全を確保できないので、生体認証や多要素認証を利用する。IDやパスワードの管理は人間が行うため、現実問題として漏洩は防げない。認証キーが漏れた場合の対策として、パスワード以外の認証を併用することになる。

そして、実際にシステムやデータにアクセスする場合、アクセスのコンテキストによって、権限や許可を切り替えていく。部署や職能によってアクセスできるデータやシステムに制限をかけるのは当然として、時間、アクセスしてくる場所、回線の種類、デバイスの種別によっても細かく制御する。

同じアカウントでも、業務時間外のアクセスには念のため追加の認証（本人確認）を行ったり、権限に制限を与えたりする。普段アクセスしないシステムへの操作も同様だ。出張中でもないのに、海外からのアクセスならばブロックする、といった動的かつきめ細かいアクセス制御を適用する。

ここで、冒頭の注意に戻るが、これらZTNAの機能や特徴を定義づけるのは、ネットワークセキュリティの実装方法とその考え方であって、特定の技術のことを指す言葉ではない。

多要素認証やリスクベースのアクセス制御、デバイスやアセットごとのセキュリティ管理、ログやトラフィックの監視、エンドポイントセキュリティ、これらをゼロトラストのポリシーによって統合的に管理することで、ZTNAが実現される。

CASBやSASEという用語（ソリューション）と一緒に語られることが多いが、SASEは、いわゆるUTM（Unified Threat Management）をクラウド上で実現する考え方だ。先ほど述べたZTNAを実現する上記の各種技術やソリューションを実現する場合、いくつかのアプローチが考えられる。

ひとつは、細かいアクセス制御や動的な追加認証、ACL（Access Control List）を既存システムによって個別に自力構成していく方法。あるいは、UTMのような統合ソリューションを活用して実装するかだ。近年は、UTM製品や関連ソリューションでもゼロトラストネットワークを意識して、リモート環境、インターネット接続を前提とした機能も存在する。そして、このような機能やサービスを、それをクラウド上に構成する（SASE）ことも可能だ。

クラウド上に統合したサービスを集約するには、以前からCASBというソリューションがある。ブローカーと呼ばれるエージェントまたはプロキシ機能を介在させ、複数のクラウドサービスを連携させる。これをセキュリティネットワークの構築に拡張したものがSASEだ。

こう表現すると、ならば既存の業務システムごとクラウドに乗せ換えSASEを導入すればすべてが解決するように感じるかもしれない。だが、話はそう簡単ではない。業務要件としてクラウド化が制限される場合もあるし、ZTNAの実装にかかるコストの問題もある。

追加認証や動的なアクセス制御は、設定のバランスを考えないと、業務効率に影響を与える。なにかをするたびに認証を求められるようになっては、セキュリティのためとはいえ本末転倒だ。きめ細かい設定と監視には、セキュリティがわかる人材が必要だ。一般にZTNA環境では、セキュリティ担当者やシステム管理部門の負荷は上がる。

業務システムの効率とセキュリティのバランスを取ったシステム構成と設定は、組織やシステムの要件によってまちまちだ。パッケージソフトの導入のようにはならない。導入にあたっては、サービスプロバイダやセキュリティベンダーとよく話し合うことが肝要である。