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

Jun 23, 2022
1 minutes
4 views

This post is also available in: English (英語) 简体中文 (簡体中国語) 繁體中文 (繁体中国語) 한국어 (韓国語)

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の原則について説明します。


Subscribe to the Newsletter!

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