SDP、ZTNA、CARTA：ゼロトラストセキュリティの略語を理解する

SDP and ZTNA and CARTA. Oh my!

オズの魔法使いの懐かしい歌を私が歌ってみたところで、曲の雰囲気はまったく再現できませんが、デジタルの世界に置き換えてみれば、不安な気持ちを少しは表現できるでしょう。

ITプロフェッショナルは常に不安を感じながらサイバー攻撃の次々と押し寄せる脅威と闘い、リモートで働く従業員のアクセスを保護し、ビジネスを保護し、個人所有デバイスやIoTによってもたらされる潜在的リスクを軽減するなどの努力を続けています。

So, getting bombarded with one acronym after another, while trying to find the best security solutions and advice for your digital transformation, can quickly become overwhelming. Every vendor starts to sound similar, with pitch decks that blur together, and it gets harder to make a decision on which technology is the best fit for you.

ゼロトラストセキュリティと聞いて、すぐに説明できないとしても、心配する必要はありません。多くの人がそうだからです。CARTAで最近公開されたガートナーのウェビナーで、参加者の70%が「ゼロトラスト」という言葉を聞いたことがあると回答しましたが、23%はその意味がよくわからないと回答しました。

So how do you make sense of all these security acronyms, and what role do they play in securing your move to the cloud?
 

SDP

SDP stands for software-defined perimeter, a term coined by the Cloud Security Alliance. The concept of SDP is that enterprises can now use software, instead of traditional network security appliances, to seamlessly connect remote users to privately managed applications running in private, hybrid, or multi-cloud environments.

It’s important to note that many SDP technologies are client-initiated. This means that a client MUST be installed on the user device for access to private apps to take place. Because of this requirement, they are often not a fit for uses cases in which access from unmanaged devices (e.g., BYOD or third-party users) is important.
 

ZTNA

Zero Trust Network Access（ゼロトラストネットワークアクセス）の略称であるZTNAは、ガートナーが20194月にゼロトラストネットワークアクセスの市場ガイドで初めて紹介した新しいセキュリティ用語です。ZTNAは、2つの異なるアーキテクチャ設計に分解することで、このゼロトラストセキュリティ空間で動作する異なるベンダ間の重要な相違の一部を解決しようとします。

1. Client-initiated architectures – ZTNA solutions in this category closely follow the original Cloud Security Alliance SDP architecture. Basically, an agent installed on authorized devices sends information about its security context to a “controller.” The controller prompts the user on the device for authentication and returns a list of apps the user is allowed to access.
2. サービス始動型アーキテクチャ – ZTNAサービスでは、アプリケーションと同じネットワークにコネクタがインストールされ、コネクタによって、クラウドへの内から外への接続が確立され、アプリとユーザが結び付けられます。このプロセスは、ユーザとデバイスの認証後に実行されます。

Gartner offers a list of evaluation criteria and recommendations for selecting the right ZTNA technology. One of their recommendations is this:

「デジタルビジネスのほとんどのシナリオでは、ZTNAをサービスとして提供することで、導入が容易で可用性が高く、DDoS攻撃からの保護を可能するベンダを選択するべきでしょう。ZTNAのほとんどのas-a-serviceフレーバーでは、サービスのリスン（インバウンド接続）のためにファイアウォールの一部をオープンする必要がありますが、そのような必要がベンダを選択することをお勧めします。
 

CARTA

CARTAは、Continuous Adaptive Risk and Trust Assessment、継続的で適応型のリスクとトラストの評価）の略です。最初の2つの用語がテクノロジであるのに対し、CARTAは、ガートナーによって開発されたセキュリティフレームワークです。この最新のクラウドファーストテクノロジのエコシステムであるフレームワークには、ZTNAサービス、アイデンティティプロバイダ、エンドポイントセキュリティベンダ、MDMやSIEMのプロバイダが含まれ、すべてが連携して動作します。

このフレームワークでは、チームが最初はゼロトラストの状態で開始する必要があると規定されていますが、実際に作業を完了させるには、トラストの確立が不可欠です。また、CARTAでは、（強力なセキュリティ属性ではない）IPアドレスに基づいてユーザを接続するのではなく、ITがコンテキスト（ユーザ、デバイス、アプリ、場所）に基づいてアクセスを提供する必要があると規定されています。そして、このアクセスを継続的に監視し、リスクを継続的に評価することで、攻撃の可能性を最小限にし、修復までの平均時間を短縮する必要があります。重要な点として、このフレームワークは、Forrester Researchによって10年前に最初に作成されたゼロトラストをだけでなく、情報セキュリティに対する継続的に適応型のアプローチを採用するよう企業に求めているに注目するべきでしょう。

ガートナーがCARTA戦略を策定したのは、アプリがクラウドに移行し、クラウドファーストの世界への移行が進み、従来型の黒か白か（ユーザを許可するかブロックするか）という単純な判断では対応できなくなっている立ち行かなくなっているためです。CARTAの考え方であれば、リスクとトラストに基づく判断が可能になります。

CARTAの方法論の主要な概念としては、次のものがあります。

• 決定は継続的で適応型でされなければならない。セキュリティレスポンスは継続的で適応型でなければならない。リスクとトラストは継続的で適応型でなければならない。
• The initial block/allow security assessments for access and protection leave enterprises exposed to zero-day and targeted attacks, credential theft, and insider threats.
• Trust and risk must be dynamic, not static, and assessed continuously as interactions take place and additional context becomes available.
• デジタルのトラストが多次元のリスクとレスポンスの属性のきめ細かい信頼性の尺度として適応型に管理された場合のみ、デジタルビジネスの結果が最適化される。

したがって、SDPあるいはZTNAのどちらであっても、ユーザを識別し、ネットワーク全体ではなく特定のアプリケーションのみへのアクセスを許可することが、CARTAフレームワーク全体において不可欠になります。

 

このことは、ネットワークセキュリティにおいて何を意味するのか？

SDP、ZTNA、CARTAが登場したのは、従来型のハブ&スポークのネットワークと城を堀で囲む形のセキュリティモデルがクラウドとモバイルの世界では十分に機能しなくなったためです。企業がパブリッククラウドのネットワークをコントロールしないのであれば、果たしてネットワークセキュリティを実現できるのでしょうか？その答えが「できない」であるのは明白です。

Backhauling internet-bound traffic (including public cloud and SaaS) to your data center through VPN inbound gateways just adds latency, which degrades the user experience, places users on the network (which can lead to the lateral spread of malware), and exposes IP addresses to the open internet, where they are at risk of DDoS attacks.

With 98 percent of security attacks stemming from the internet, it's become an unacceptable risk to place remote users on the network. Today’s digital employees, who demand the same fast connection to their apps regardless of their location or device, also deserve better.

The classic security perimeter, the data center, has evolved. Now, the user, app, and device are the new virtual perimeters and the internet is the new corporate network. This calls for a new approach to application access.

従業員、従業員が仕事で使うアプリ、そして会社のビジネスのほぼすべてがクラウドに移行したのであれば、セキュリティもまたクラウドを前提に構築するべきではないでしょうか？

It is natural to be a bit apprehensive when embarking on a cloud journey that involves transforming your applications, network, and security. But, just as Dorothy, Tin Man, Scarecrow, and Cowardly Lion persevered, got some help, and completed their journey, you can do the same thing.

Feel free to reach out to me if you have any questions about SDP, ZTNA, or CARTA, or how Zscaler can help with securing access to your private applications: [email protected].

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Chris Hines is head of product marketing for Zscaler Private Access and Z App.