新型コロナウィルス感染症の拡大に伴い多くの方が自宅からのリモートワークを余儀なくされて、"ZTNA"のような何となく理解できるが具体的に何のことかはよくわからない言葉がメディアで散見されるようになってきました。私個人もお客様から"ZTNA"って何のことですか?と質問されて回答に苦慮しています。この記事はZero Trust Network Accessを代表的な2つのモデルに大別して可能な限りシンプルに整理することを試みた実験記事です。
共通する狙い
Zero Trust Network Accessを検討する背景はVPNの置き換えやM＆Aによる組織改編等、様々な背景があると思いますがいくつかの共通する意図があるかと思います。
- 社内で利用している気密性の高いDataを取り扱うApplicationをInternetに公開したくない
- Userの"Context"(例/Identity, 利用しているDevice, アクセスしにきているLocation)に基づいて最小限の権限でApplication/Dataにアクセスさせたい
- アクセスしにきているLocationのIP AddressやDeviceのMac Address等の物理情報は無視して論理情報のみに基づいてアクセスさせたい
- Layer3,4レベル(Network)のアクセスではなくLayer７レベル(Application)のアクセスを実現したい
- Endpoint〜ApplicationまでEndtoEndの暗号化を実現したい
- Application/Dataへの通信内容は常に監視して不正と思われる通信はダイナミックに遮断したい
- UserがいつどこからApplication/Dataにアクセスしても一貫した体験を提供したい
モデル1 - Endpoint-initiated
Endpoint Deviceをからフローを開始するモデルでCloud Security Allianceが提唱している"Software Defined Perimeter"がこのモデルに該当します。Endpoint DeviceにインストールされたAgentがZTNA Controllerに認証リクエストを送信することでフローが開始されます。
このモデルはEndpoint DeviceにAgentがインストールされていることが前提となるため、Endpoint Device Management Solutionで常に管理されていることが必要です。またZTNA GatewayからApplicationへの通信はインバウンドになるため、間にFirewallが存在している場合はFirewallのセキュリティポリシーでインバウンド通信を許可する必要があります。
モデル2 - Service-initiated
Applicationからフローを開始するモデルでGoogle社が提唱している"BeyondCorp"がこのモデルに該当します。ZTNA ConnectorはApplicationと同じデータセンター内にあることを想定していて、ZTNA ConnectorとZTNA Brokerの間の通信はアウトバウンドのみになるため、Endpoint-initiatedモデルにあるFirewallのセキュリティポリシーを変更することは不要になります。更にEndpoint DeviceにAgentをインストールすることも不要なため、Endpoint Device Management Solutionの導入や運用も不要でEndpoint Deviceも会社支給だけでなく個人のデバイスでも適用できます。
このモデルはAgentをインストールしないため、Http/HttpsのプロトコルでアクセスできるApplicationが前提となります。トンネル型のApplication(例/SSH Server, RDP Server)には適用できないため、トンネル型のApplicationの利用が必要なケースはEndpoint-initiatedのモデルとの併用になります。
参考
Market Guide for Zero Trust Network Access
Implementing a Zero Trust Architecture Project Description