ZTNAの本音トーク: ZTNA1.0は最小権限の原則に違反

Jun 23, 2022
1 minutes
... views

ZTNA 2.0のきめ細かなアクセス制御でリスクを削減

この記事は、5部構成シリーズ「ZTNAの本音トーク」の第1部です。ここでは、アクセス保護の新基準であるZTNA 2.0の5つの理念についてさらに詳しく見ていきます。

ゼロ トラストの概念とは、ネットワークやデジタル トランザクションから暗黙的な信頼を全て取り除くことであり、現在、組織の保護に最適なアプローチとして一般的に支持されています。しかし、最近Nir Zukが指摘したように、既存のゼロトラスト ネットワーク アクセス ソリューションには、組織を危険にさらす5つの大きな欠陥が含まれています。

  1. 最小権限の原則に違反している。
  2. 「許可して放置」する。
  3. セキュリティ検査を実施しない。
  4. データ保護に失敗している。
  5. エンタープライズ アプリケーションの一部しか保護しない。

ここでは第1の欠陥について取り上げ、ZTNA 1.0の最小権限の原則の違反について見ていきます。

「最小権限の原則」は情報セキュリティの概念で、「ユーザーまたはエンティティには作業の実施に必要な最小限のアクセスのみを付与する」ことです。この考え方は、アクセスを必要最小限に制限して、異常が発生した場合にセキュリティ侵害を受けるリスクを減らすというものです。

最小権限はゼロ トラスト体制の基礎で、ZTNA 1.0ソリューションの提供ベンダは自社のソリューションに「最小権限を組み込んでいる」と主張することが多いでしょう。しかし、ZTNA 1.0のアーキテクチャには欠陥があるため、実際のこの概念の実現については大きなギャップが残されています。

ZTNA 1.0は最小権限の原則に違反(VPNと大差ない)

ZTNA 1.0の問題点について議論する前に、まず、リモート アクセスVPNについて説明する必要があります。VPNは、企業ネットワークのリモート アクセスの提供に長期間使用されてきました。ネットワーク全体に幅広いアクセスを付与するこのアプローチは、決して理想的ではなかったのですが、ほかに実用的な選択肢がなく、また、一度接続したら「信頼できる」比較的少数のユーザーのみがまれに使用していたので、許容範囲とみなされていました。しかし、ハイブリッド ワークへの急速な移行と最新の脅威の高度化(特にラテラルムーブを伴う攻撃)により、最終的に従来のVPNは時代遅れになりました。

ZTNAは、ネットワーク全体ではなく、ユーザーが必要とする特定のアプリケーションのみにアクセスを制限することで、VPNの最大の課題の1つを解決しようとしたものです。しかし、ベンダによるZTNA 1.0ソリューションの実装方法は、本質的に、アプリケーションをIP(またはFQDN)やポート番号などのレイヤー3またはレイヤー4のネットワーク構成要素に変換するというものでした。この制限により管理者のアクセス制御ポリシーの記述は雑になり、最終的に意図したよりずっと多いアクセスを付与することになりました。

アプリケーション コンポーネントが静的なIPアドレスとポート番号を使用する従来のアプリケーションでは、IPとポートを使用してアプリケーションを特定するアプローチは許容可能でした。しかし、最近はほぼ全ての企業で、複数の機能を提供するクラウドネイティブ アプリケーションを使用しており、その各機能を独立したURLや、同様の高次の概念で実現しています。同じように、ビジネス アプリケーションでは一般的に、動的なIPとポート、サーバー起動型接続などのシナリオを使用しており、IPとポートだけに基づいて静的なアクセス制御ポリシーを作成する方法は完全に破綻しています。

最新アプリのアクセス制御

これまでに述べたように、最小権限の原則というのは、ユーザーが仕事を完了できる最小限の権限を提供することです。動的IPとポートを使用するSaaSおよびその他の最新アプリに対応するために、ZTNA 1.0ソリューションでは、アクセス制御(およびアプリケーション)が機能するように、幅広いIPとポート範囲へのアクセスを許可する必要があります。これは明らかに最小権限の原則に違反しており、ネットワークに大きな穴があき、攻撃者やマルウェアに悪用される可能性があります。

ZTNA 2.0では、アプリが使用するIPやポートに関係なく、システムがApp-IDを使用して、アプリケーションとアプリ内の特定の機能を、あらゆるプロトコルとポートにわたって動的に特定できます。これにより管理者は、ネットワーク構造を考える必要がなくなり、非常にきめ細かなアクセス制御で、本当の意味での最小権限アクセスを実装できます。

サーバー起動型接続を使用するアプリのZTNA 1.0からの離脱

次にZTNA 1.0ソリューションに合わない種類のアプリは、サーバーからクライアントに向かって接続を確立する必要があるアプリです。これには、更新やパッチの管理ソリューションや、デバイス管理アプリ、ヘルプ デスク アプリなどのミッションクリティカル アプリケーションが含まれます。多くのベンダのZTNA 1.0の実装方法は、これらの接続をユーザーが開始する場合にのみ機能させ、アプリやサーバーが開始する接続をまったく許可しません。ZTNA 1.0ソリューションを実装しようとしたものの、この使用事例を解決するためだけに従来のVPNソリューションを維持せざるを得なかったお客様の例は数多く見受けられます。

Prisma AccessのようなZTNA 2.0ソリューションは、App-IDを使用して双方向のアクセス制御を実行して、アプリケーションのアクセス ポリシーを定義でき、サーバー起動型接続を使用するアプリなど、あらゆる種類のアプリで最小権限アクセスを容易に実現できます。

プライベート アプリケーションのサブアプリ制御

多くのプライベート アプリケーションには、最新のSaaSアプリにあるような、きめ細かなアクセス制御機能が組み込まれていません。ユーザーがアプリケーションにアクセスしてデータを表示できるが、アップロードやダウンロードはできないというようなことは、アプリがIPアドレスとポート番号だけで特定されるZTNA 1.0ソリューションでは、単純に不可能です。サブアプリ レベルでこの水準のきめ細かな制御を提供する(たとえば、アプリへのアクセスは指定するが、アップロードやダウンロードは制限する)ことは、App-ID構造を利用してアプリとサブアプリを特定するZTNA 2.0ソリューションであれば容易に行なえます。

最小権限を効果的に実施するには、ZTNA 2.0のきめ細かな制御が必要

アプリケーションやユーザーが場所を問わずに存在する世界において、最小権限の原則を採用することは、ゼロ トラストを効果的に採用し、組織のリスクを削減するために非常に重要です。これまでに述べたように、ZTNA 2.0はIPアドレスやポート番号のようなネットワーク構造に関係なく、あらゆる種類のアプリケーションに対して精緻なアクセス制御を実現します。これは、アクセスを保護し、従来のリモート アクセスVPNから最終的に離脱できるようにするための、大きな一歩です。

ぜひZTNA 2.0のローンチ イベントをご覧ください。ZTNA 2.0でハイブリッド ワークフォースを保護するイノベーションとベスト プラクティスについて説明しています。パロアルトネットワークスの来週のブログもお楽しみに。ZTNA 2.0の第2の原則について説明します。


ZTNA 1.0은 어떻게 최소 권한 원칙을 위반하는가

Jun 15, 2022
1 minutes
... views

ZTNA 2.0의 세분화된 액세스 제어를 통한 리스크 절감

이 포스트는 안전한 액세스의 새로운 표준인 ZTNA 2.0의 5가지 원칙을 자세히 알아보기 위한 5부작 시리즈, "ZTNA 스트레이트 토크"의 1부입니다.

네트워크 및 디지털 트랜잭션의 모든 암시적 신뢰를 없앤다는 제로 트러스트의 개념은 오늘날 기업을 안전하게 보호하기 위한 최고의 접근 방식으로 널리 인정받고 있습니다. 그러나 최근 Nir Zuk가 지적한 바와 같이 기존 제로 트러스트 네트워크 액세스 솔루션은 기업에 리스크를 초래할 수 있는 5가지 불안한 결함을 가지고 있습니다.

1) 최소 권한 원칙을 위반합니다.

2) "허용하고 무시"합니다.

3) 보안 검사를 수행하지 않습니다.

4) 데이터를 보호하지 못합니다.

5) 엔터프라이즈 애플리케이션의 일부만을 보호합니다.

이 중 첫 번째 결함이자 오늘 다룰 주제인, 'ZTNA 1.0은 어떻게 최소 권한 원칙을 위반하는가'에 대해 살펴보겠습니다.

최소 권한의 원칙은 정보 보안 개념으로, 사용자나 기업에 업무를 수행하기 위한 최소한의 액세스 권한만 부여해야 한다는 의미입니다. 이것은 액세스를 최소한으로 제한해야 문제 발생 시 노출도 줄어든다는 생각에서 비롯되었습니다.

최소 권한은 제로 트러스트 태세의 근본이며, ZTNA 1.0 제공업체가 자체 솔루션에 "내장"된 기능이라 주장하기도 합니다. 그러나 ZTNA 1.0 아키텍처 결함은 이 개념을 제공하기 위한 기능에 큰 빈틈을 남깁니다.

ZTNA 1.0은 최소 권한 원칙을 위반함(또한 VPN보다 우수하지 못함)

ZTNA 1.0의 문제를 논하기 전에 먼저 원격 액세스 VPN에 관해 이야기해보아야 합니다. VPN은 기업 네트워크에 대한 원격 액세스를 제공하기 위해 오랫동안 사용되어 왔습니다. 전체 네트워크에 광범위한 액세스 권한을 부여하는 이 접근 방식은 결코 이상적이라 할 수 없지만 실질적인 대안이 없었을뿐더러 상대적으로 소수의 사용자만이 연결된 후 "신뢰받은" 상태에서 드물게 사용했기 때문에 허용할 수 있다고 판단했습니다. 그러나 하이브리드 업무로의 빠른 전환과 정교한 최신 위협(특히 내부망 이동을 포함한 공격)은 결국 기존 VPN을 무력하게 만들었습니다.

ZTNA는 전체 네트워크가 아닌, 필요한 특정 애플리케이션으로만 사용자의 액세스를 제한하여 VPN의 가장 큰 문제 중 하나를 해결하고자 했습니다. 하지만 공급업체에서 ZTNA 1.0 솔루션을 구현하는 방식은 기본적으로 IP(또는 FQDN) 및 포트 번호와 같은 레이어 3이나 레이어 4 네트워크 구조로 애플리케이션을 반영했습니다. 이러한 제한은 관리자가 액세스 제어 정책을 작성할 때 더욱 폭넓은 범위를 적용하도록 하여 결과적으로 의도한 것보다 훨씬 더 많은 액세스 권한을 부여하게 됩니다.

애플리케이션 구성 요소가 정적 IP 주소 및 포트 번호를 사용하는 레거시 애플리케이션의 경우 IP/포트를 사용하여 애플리케이션을 식별하는 접근 방식이 허용됩니다. 그러나 오늘날 거의 모든 엔터프라이즈에서는 다양한 기능을 제공하는 클라우드 네이티브 애플리케이션을 사용하며, 이들은 각각 개별 URL이나 유사한 고차원 개념을 통해 제공됩니다. 마찬가지로, 비즈니스 애플리케이션은 동적 IP 및 포트, 서버 개시 연결 및 IP와 포트만을 기반으로 한 정적 액세스 제어 정책 생성이 완전히 중단되는 기타 시나리오를 사용합니다.

최신 앱에 대한 액세스 제어

앞서 설명한 바와 같이, 최소 권한의 원칙은 사용자가 업무를 수행하기 위해 가능한 최소한의 권한만 제공하는 것입니다. SaaS 그리고 동적 IP 및 포트를 사용하는 기타 최신 앱에 대해서도 ZTNA 1.0 솔루션은 액세스 제어(및 애플리케이션)를 위한 광범위한 IP 및 포트 범위의 액세스를 허용하도록 하며 이는 업무에서도 마찬가지입니다. 이것은 네트워크에 공격자나 멀웨어가 익스플로잇할 수 있는 큰 허점을 남기며 최소 권한 원칙을 명백히 위반하는 것입니다.

ZTNA 2.0을 통해 시스템은 앱이 어떤 IP와 포트를 사용하든 상관없이 App-ID를 사용하여 모든 프로토콜과 포트를 통해 앱 내에서 애플리케이션과 특정 기능을 동적으로 식별할 수 있습니다. 이를 통해 관리자는 네트워크 구조를 생각할 필요가 없으며, 세분화된 액세스 제어를 지원하여 결국 진정한 최소 권한 액세스를 구현할 수 있습니다.

서버 개시 연결을 사용하는 앱의 ZTNA 1.0 사용 중단

ZTNA 1.0 솔루션과 잘 맞지 않는 새로운 유형의 앱은 서버에서 클라이언트로 연결을 설정해야 합니다. 여기에는 업데이트 및 패치 관리 솔루션, 디바이스 관리 앱 및 지원 센터 앱과 같은 미션 크리티컬 애플리케이션이 포함됩니다. 많은 공급업체에서 ZTNA 1.0을 구현한 방식은 사용자가 이러한 연결을 시작한 경우에만 작동하며, 앱 또는 서버 개시 연결은 전혀 허용하지 않습니다. 우리는 고객이 ZTNA 1.0 솔루션을 구현하려고 했지만 이 사용 사례를 해결하기 위해 기존 VPN 솔루션을 유지해야 했던 수많은 사례를 접했습니다!

애플리케이션 액세스 정책을 정의하는 App-ID를 사용하여 양방향 액세스 제어를 허용하는 Prisma Access와 같은 ZTNA 2.0 솔루션은 서버 개시 연결을 사용하는 앱을 포함한 모든 유형의 앱에 대해 최소 권한 액세스를 쉽게 적용할 수 있습니다.

프라이빗 애플리케이션에 대한 하위 앱 제어

많은 프라이빗 애플리케이션은 대부분의 최신 SaaS 앱에 존재하는 세분화된 내장 액세스 제어 기능이 부족합니다. 사용자가 애플리케이션에 액세스하여 데이터를 볼 수 있지만 데이터를 업로드하거나 다운로드할 수는 없는 것과 같은 간단한 기능은 IP 주소 및 포트 번호만으로 앱을 식별하는 ZTNA 1.0 솔루션에서는 불가능합니다. 하위 앱 수준에서 이와 같은 세분화된 제어 수준을 제공하는 것(즉, 앱에 대한 액세스를 지정하지만 업로드/다운로드는 제한함)은 App-ID 구조를 활용하여 앱 및 하위 앱을 식별하는 ZTNA 2.0 솔루션의 경우에는 그리 어려운 일이 아닙니다.

최소 권한의 효과적인 적용을 위해서는 ZTNA 2.0의 세분화된 제어가 필요함

애플리케이션과 사용자가 어디에나 존재하는 환경에서 최소 권한 원칙을 수용하는 것은 제로 트러스트를 효과적으로 도입하고 기업의 리스크를 줄이는 데 매우 중요합니다. 설명한 바와 같이, ZTNA 2.0은 IP 주소 및 포트 번호 같은 네트워크 구조와 관계없이 모든 유형의 애플리케이션에 대한 정밀한 액세스 제어가 가능합니다. 이것은 안전한 액세스를 위한, 궁극적으로는 레거시, 원격 액세스 VPN으로부터 벗어날 수 있기 위한 중요한 도약입니다.


ZTNA 1.0 如何違反最低權限原則

Jun 15, 2022
1 minutes
... views

透過 ZTNA 2.0 的精細存取控制降低風險

「ZTNA 實話實說」包含五個部分,而本文是這個系列的第一部分,其將深入探討 ZTNA 2.0 的五大核心,也就是保護存取的新標準。

零信任的概念 – 也就是從我們的網路和數位交易移除所有隱含的信任 – 已普遍認定為是目前用來保護企業安全的最佳方法。不過,如同 Nir Zuk 最近所指出,現有的零信任網路存取解決方案包含五種警報功能的缺陷,這些缺陷讓企業面臨風險:

1) 違反最低權限原則。

2) 遵循「允許及忽略」模式。

3) 未執行任何安全檢查。

4) 無法保護數據。

5) 只能保護一小部分的企業應用程式。

針對第一個缺陷,也是今天的重點,我們將探討 ZTNA 1.0 如何違反最低權限原則。

最低權限原則是一種資訊安全概念,表明僅授予使用者或實體最少量的必要存取權限來執行他們的工作。此一概念就是將存取權限維持在最低限度,一旦發生問題也能減少暴露的程度。

最低權限也可說是零信任狀況的基礎,ZTNA 1.0 供應商通常也會宣稱已在其解決方案中「內建」此原則。不過,ZTNA 1.0 的架構缺陷也會對其實現概念的能力構成嚴重阻礙。

ZTNA 1.0 違反最低權限原則 (實際表現也沒有比 VPN 更好)

在討論 ZTNA 1.0 發生了什麼問題之前,我們必須先聊聊什麼是遠端存取 VPN。長久以來,VPN 都是用來提供公司網路的遠端存取。雖然這種針對整個網路授予廣泛存取權限的做法絕對稱不上是理想的方式,但實際上也沒有其他替代方法,並且由於只有相對較少的使用者在連線時才會獲得「信任」且使用率不高,因此仍被視為是可接受的方式。不過,快速移轉至混合工作型態以及現代化威脅的複雜化 (尤其是涉及橫向移動的攻擊) 已讓傳統的 VPN 變得過時。

ZTNA 的目的在於限制使用者只能存取他們需要的特定應用程式而非整個網路,藉此解決 VPN 其中一項最大的挑戰。不過,廠商實作 ZTNA 1.0 解決方案的方式基本是將應用程式轉譯成第 3 和第 4 層網路架構,像是 IP (或 FQDN) 和連接埠號碼。這樣的限制會迫使管理員只能制定大範圍、但卻不夠精準的存取控制政策,授予的存取權限往往大幅超過預期。

對於應用程式元件使用靜態 IP 位址和連接埠號碼的舊型應用程式來說,使用 IP/連接埠識別應用程式是仍可被接受的方法。不過,最近幾乎所有的企業都使用能提供數種功能的雲端應用程式,每一種功能都是透過個別 URL 或類似的高層次概念所提供。同樣地,通常使用動態 IP 和連接埠、伺服器啟動連線的商業應用程式,與其他只能根據 IP 和連接埠來建立靜態存取控制政策的情境也完全不相符。

現代化應用程式的存取控制

如同我之前所討論的,總結來說最低權限原則就是僅授予使用者最少量的權限來執行他們的工作。為了因應 SaaS 和其他使用動態 IP 與連接埠的現代化應用程式,ZTNA 1.0 解決方案會需要您將存取權限授予更大範圍的 IP 和連接埠,使存取控制 (和應用程式) 能夠正常運作。但這種做法很明顯地已違反最低權限原則,並且會在網路中產生更大的漏洞而遭到攻擊者或惡意軟體所利用。

透過 ZTNA 2.0,無論應用程式使用哪些 IP 和連接埠,系統都會以動態方式在任何使用 App-ID 的通訊協定和連接埠中識別應用程式以及應用程式的特定功能。因此管理員將不再需要考量網路架構,並可啟用非常精細的存取控制以實作真實的最低權限存取。

ZTNA 1.0 對於使用伺服器啟動連線的應用程式不適用

另一種難以適用 ZTNA 1.0 解決方案的應用程式就是需要從伺服器建立用戶端連線的應用程式。其中包括各種任務關鍵應用程式,例如更新和修補程式管理解決方案、裝置管理應用程式和服務台應用程式等等。即使是已經由許多廠商實作的 ZTNA 1.0 方法,也必須由使用者啟動這些連線,且完全不允許應用程式或伺服器啟動的連線。在我們所觀察許多由客戶嘗試實作 ZTNA 1.0 解決方案的例子中,他們都被迫維持其舊型的 VPN 解決方案,只為了解決這一類的使用案例!

另一方面,像是 Prisma Access 等 ZTNA 2.0 解決方案則會使用 App-ID 進行雙向存取控制以定義應用程式存取政策,可對於所有類型的應用程式輕鬆地啟用最低權限存取,包括使用伺服器啟動連線的應用程式。

私有應用程式的子應用程式控制

許多的私有應用程式都缺乏存在於大部分現代化 SaaS 應用程式的內建、精細存取控制功能。即使是允許使用者存取應用程式以檢視數據但不允許上傳或下載數據的一些簡單功能,在 ZTNA 1.0 解決方案中也幾乎做不到,因為它只能根據 IP 位址和連接埠號碼來識別應用程式。在子應用程式層級上提供這一類的精細控制 (亦即指定應用程式存取權限,但限制上傳/下載) 對於利用 App-ID 架構來識別應用程式和子應用程式的 ZTNA 2.0 解決方案可說是輕而易舉。

需要透過 ZTNA 2.0 的精細控制以更有效率地執行最低權限存取

在應用程式和使用者無所不在的世界中,遵循最低權限原則對於有效採用零信任及降低企業風險來說非常重要。如同先前所討論的,ZTNA 2.0 能夠不受 IP 位址和連接埠號碼等網路架構的影響,對於所有類型的應用程式啟用精準的存取控制。這對於保護存取安全來說等於是往前邁進一大步,且最終能夠讓我們擺脫舊型遠端存取 VPN 的束縛。


ZTNA 1.0 怎样违反了最低权限原则

Jun 09, 2022
1 minutes
... views

利用 ZTNA 2.0 的精细访问控制降低风险

这是“ZTNA Straight Talk”五篇系列文章中的第一篇,我们将详细介绍 ZTNA 2.0 的五个原则,ZTNA 2.0 是用于确保访问安全的新标准。

零信任的概念是指消除网络和数字交易中的所有默认信任,被普遍认为是当今保护企业安全的最佳方法。然而,正如 Nir Zuk 最近所说,现有的零信任网络访问解决方案有五个将企业安全置于风险之中的惊人漏洞:

1) 违反了最低权限原则。

2) 采用“允许并忽略”模式。

3) 不进行安全检查。

4) 数据保护不力。

5) 仅保护企业的应用子集。

本文将主要解释第一个漏洞,探讨 ZTNA 1.0 怎样违反了最低权限原则。

最低权限原则是一个信息安全概念,规定了应向用户或实体授予办公所需的最低限度的访问权限。这一原则的逻辑是,如果出现问题,将访问权限限制在最低限度可减少暴露风险。

最低权限原则是零信任态势的基础,ZTNA 1.0 提供商通常称其为解决方案的“内置”工具。然而,ZTNA 1.0 的架构漏洞导致这些提供商远远无法落实这一概念。

ZTNA 1.0 违反了最低权限原则(与 VPN 不相上下)。

在探讨 ZTNA 1.0 的问题之前,首先需要提到远程访问 VPN。长期以来,VPN 一直用以远程访问企业网络。这种方法会广泛授予整个网络的访问权限,实在不尽理想,但由于没有实用的替代办法,业界只能一直使用这一方法,因为只有少量用户偶尔会使用这种方法,这些用户连接之后就会“获得信任”。然而,向混合办公模式的快速转变和现代威胁的复杂性(尤其是涉及横向移动的攻击)最终导致传统 VPN 过时。

ZTNA 旨在通过限制用户仅访问所需特定应用而非整个网络来解决 VPN 最大的挑战之一。然而,供应商实施 ZTNA 1.0 解决方案的方式基本上是将应用转换为 IP(或 FQDN)和端口号等第 3 层或第 4 层的网络结构。这一局限性要求管理员在编写访问控制策略时只能使用泛泛的说辞,最终授予了远远超出预期的访问权限。

应用组件使用静态 IP 地址和端口号的传统应用可以使用 IP/端口来识别应用。然而,如今几乎每个企业都使用提供多种功能的云原生应用,每个功能均通过单独的 URL 或更高级的概念提供。同样,业务应用通常使用动态 IP 和端口、服务器发起的连接以及创建基于 IP 和端口的静态访问控制策略的其他场景。

现代应用的访问控制

正如上文所述,最低权限原则指尽量为用户提供办公所需的最少权限。为了应对 SaaS 应用和其他使用动态 IP 和端口的现代应用,ZTNA 1.0 解决方案要求您授予大量 IP 和端口的访问权限,以便访问控制(和应用)正常运作。这显然违反了最低权限原则,因为它在您的网络中创建了一个可被攻击者或恶意软件利用的巨大漏洞。

借助 ZTNA 2.0,无论应用使用的是什么 IP 和端口,系统皆可利用 App-ID 在所有协议和端口中动态识别应用和应用中的特定功能。因此,管理员无需考虑网络架构,并实现了非常精细的访问控制,最终实施了名副其实的最低权限访问。

使用服务器发起的连接的应用无法与 ZTNA 1.0 完美配合

需要在服务器和客户端之间建立连接的应用也无法与 ZTNA 1.0 解决方案完美协作。这类应用包括任务关键应用,如更新和补丁管理解决方案、设备管理应用和帮助台应用。许多供应商已经实施了 ZTNA 1.0,但该解决方案仅在您的用户发起此类连接时才起作用,而对于应用或服务器发起的连接根本不起作用。我们发现许多客户尝试实施 ZTNA 1.0 解决方案,但最终被迫保留其传统 VPN 解决方案,而 VPN 的用途却是解决这一新用例的问题!

Prisma Access 等 ZTNA 2.0 解决方案允许使用 App-ID 定义应用访问策略以进行双向访问控制,还可以轻松为所有类型的应用启用最低权限访问,包括使用服务器发起的连接的应用。

针对私有应用的子应用控制

许多私有应用缺乏大多数现代 SaaS 应用中的内置精细访问控制功能。ZTNA 1.0 解决方案仅根据 IP 地址和端口号来识别应用,仅授予用户应用访问权限查看数据而不可上传或下载数据这样的简单操作是无法实现的。而在利用 App-ID 架构识别应用和子应用的 ZTNA 2.0 解决方案中,可轻松在子应用级别提供此类精细控制(即指定应用的访问权限,但限制上传/下载)。

有效实施最低权限需要 ZTNA 2.0 的精细控制功能。

如今,应用和用户无处不在,采用最低权限原则对于有效实施零信任及降低企业风险而言至关重要。如前所述,ZTNA 2.0 支持对所有类型的应用进行精细访问控制,独立于 IP 地址和端口号等网络架构。这是在确保访问安全并最终摆脱传统远程访问 VPN 方面的重大飞跃。

请于 6 月 15 日和 16 日参加我们的特别活动,活动期间我们将讨论利用 ZTNA 2.0 保障混合劳动力安全的创新和最佳实践。请继续关注下周的 Palo Alto Networks 博客,我将在其中介绍 ZTNA 2.0 的第二个原则。


Subscribe to the Blog!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.