セキュリティをシンプルに：Unified SASEにおけるセキュリティポリシーの合理化 セキュア・アクセス・サービス・エッジ（SASE）サービスは、関連するアーキテクチャとともに、複数のセキュリティ・コンポーネントの強力な融合で構成されています。 これらには、ステートフル・インスペクション・ファイアウォール、侵入検知防御システム（IDPS）、DNSセキュリティ、DoS/DDoS防御、セキュア・ウェブ・ゲートウェイ（SWG）、ゼロ・トラスト・ネットワーク・アーキテクチャー（ZTNA）、クラウド・アクセス・セキュリティ・ブローカー（CASB）などが含まれます。 これらのコンポーネントは、管理者がポリシーを通じて設定することができ、特定のアクセス要件に準拠しながら、組織の資産を脅威から保護する堅牢なシールドを提供します。

ポリシー設定の役割

ポリシーの設定は、SASEのフレームワークの中でセキュリティを強制するために不可欠な役割を果たします。 不適切に構成されたポリシーの影響は、リソースの脅威やデータ漏洩から、意図しない過度のアクセス許可まで、多岐にわたります。 今日の業界の状況において、組織は、セキュリティポリシー管理に対する2つの主要なアプローチに取り組んでいます：

  1. 単一テーブルアプローチ： SASEの全コンポーネントにわたる脅威管理と様々なアクセス制御シナリオにまたがる無数のポリシーを含む統合ポリシーテーブル。
  2. マルチテーブル・アプローチ：脅威防御、アクセス制御、さまざまなアプリケーション、ユーザーグループなど、特定の側面に対応する複数のポリシーテーブル。

政策運営のバランス

SASEに期待することは明確です。それは、簡単に管理できるセキュリティポリシーと簡素化されたトラブルシューティング手順を提供することです。 これを達成するためには、バランスの取れたアプローチが必要です。 組織の要件に基づいてポリシーの複雑さを緩和する効果的な戦略の1つです。 大規模な組織では、ポリシー・テーブルの粒度をセキュリティ機能、アプリケーション・リソース、対象（ユーザ／グループ）に基づいて定義するマルチテーブル・アプローチによる区分化が必要になるかもしれません。 小規模な組織では、複数のタイプのアクセス制御を組み合わせた、あるいは脅威防御とアクセス制御を組み合わせた、より少ない数のポリシーテーブルによるコンパートメント化を好むかもしれません。 この柔軟なアプローチにより、同時管理が必要なポリシーの数を最小限に抑え、管理しやすくなります。 ただし、過度な区分化には十分な注意が必要です。 管理者は、問題を特定して対処するために複数のポリシー テーブルをナビゲートすることになり、解決に遅れが生じる可能性があります。

主要要件の理解

ポリシー管理の複雑さを深く掘り下げる前に、組織がSASEのフレームワークの中で対処しなければならない特定の要件を理解することが極めて重要です。 主な分野は以下の通りです：

SASE環境における役割ベースのセキュリティ構成管理の必要性

セキュア・アクセス・サービス・エッジ（SASE）のコンポーネントは、従業員、パートナー、ゲストを含む多様な組織の幅広いリソースに対して、脅威防御とアクセス制御を含む包括的なセキュリティを提供します。 このようなセキュリティの枠組みの中で、多くの場合、組織はセキュリティのさまざまな側面を担当する管理者を明確に分類しています。 例えば、ある組織では、ある管理者グループは脅威防御の管理に専念し、別のグループはアクセス制御に専念するとします。 このような大まかな分類の中で、脅威対策やアクセス制御の特定のタイプに合わせたさまざまな管理者ロールを設定するのが一般的です。 では、実際の例をいくつか挙げてみましょう：

脅威防御の役割

  • 侵入検知とファイアウォールの設定：threat-protection-ngfw-role “を持つ管理者は、SASE環境内で侵入検知とファイアウォールの設定を行う権限が与えられます。
  • レピュテーションコントロール：脅威防御レピュテーションコントロール：「脅威防御レピュテーションロール」を持つ管理者は、IPレピュテーションコントロール、URLベースのレピュテーションコントロール、ドメインベースのレピュテーションコントロール、ファイルレピュテーションコントロール、およびクラウドサービスとクラウド組織のレピュテーションコントロールに関連する設定を管理できます。
  • マルウェア保護：マルウェア保護：「threat-protection-malware-protection-role」を持つ管理者は、マルウェア保護制御に特化した設定を構成する権限を持ちます。

アクセス制御の役割：

  • SWG 構成：access-control-Internet-role」に指定された管理者は、Secure Web Gateway (SWG) 構成の管理を担当します。
  • SaaS アプリケーション固有のアクセス制御：access-control-saas1app-role」や「access-control-saasNapp-role」のようなロールは、特定のアプリケーション（SaaS Service 1およびSaaS Service N）に対するアクセス制御ポリシーの設定に重点を置き、きめ細かな制御を保証します。
  • エンタープライズアプリケーション管理：access-control-hostedapp1-role」および「access-control-hostedappM-role」などのロールは、エンタープライズレベルのアプリケーション、app1およびappMのアクセス制御設定を処理する専用です。

組織がマルチテナントのアプリケーションを使用している場合、セキュリティ構成を効果的に管理するために、追加のロールを導入することができます。 例えば、組織の従業員、テナントごとの従業員、さらにはゲストのためのポリシーを構成するために、ロールを確立することができます。 異なる管理者セットによってセキュリティ構成が管理されるアプリケーション「X」を考えてみましょう：

  • オーナーのワークフォースセキュリティaccess-control-hostedappX-role」と「access-control-owner-workforce-role」を持つ管理者は、オーナーのワークフォース用のアプリケーション「X」のアクセス制御設定を共同で管理します。
  • アプリケーションテナントのテナント固有のワークフォース：access-control-hostedAppX-role」や「access-control-owner-tenantA-workforce-role」などのロールにより、管理者はテナントAのワークフォースに対するアクセス制御設定を行うことができます。
  • テナント B のアプリケーションテナント固有の労働力：マルチテナント・アプリケーション「X」の場合、「access-control-hostedAppX-role」や「access-control-owner-tenantB-workforce-role」などのさまざまなロールが、テナントBの従業員に対するアクセス制御設定の管理を容易にします。

さらに、マルチテナントではないエンタープライズアプリケーションでも、従業員セグメントごとに別々の管理者が必要になる場合があります。 例えば

  • エンジニアリング部門：access-control-hostedappY-role」と「access-control-eng-role」を持つ管理者は、技術部門内のアプリケーション「Y」のアクセス制御構成の管理に集中します。
  • セールス＆マーケティングaccess-control-hostedappY-role」や「access-control-sales-role」のようなロールは、営業チームやマーケティングチームのアクセス制御設定を行うために指定されます。
  • IT部門：access-control-hostedappY-role」および「access-control-it-role」を持つ管理者は、IT 部門に関連するアクセス制御設定の責任を持ちます。

役割ベースのセキュリティ構成管理の大きな利点は、特定の責任に合わせたきめ細かな制御を提供できることです。 このアプローチは、単一の包括的なポリシー・テーブルを使用する場合に発生する可能性のある課題と対照的です：

  • エラーが発生しやすい複数の管理者が同じポリシー テーブルで作業し、権限が重複している場合、ポリシーを追加、削除、または変更するときに、不注意でエラーが発生する可能性があります。
  • トラブルシューティングの複雑さ：モノリシックなポリシーテーブル内の問題を解決するのは、時間がかかり、困難な場合があります。
  • ポリシーの過負荷：さまざまなアプリケーションや脅威防御シナリオをカバーするすべてのポリシーを 1 つのテーブルに統合すると、煩雑で扱いにくいポリシー管理になり、ポリシー評価時のパフォーマンスにも問題が生じる可能性があります。

結論として、SASE環境においてロールベースのセキュリティ構成管理を採用することで、組織は、単一テーブルアプローチに関連する複雑さを回避しながら、効率的に責任を委譲し、セキュリティを強化し、ポリシー管理を合理化することができます。

構成変更管理との連携

組織は、SASEコンフィギュレーションを含む全てのコンフィギュレーションに対して、コンフィギュレーションエラーを事前に検出し、実施前に修正するための変更管理方法を採用するようになってきています。 この方法は、安全策としての役割を果たすだけでなく、二次的な監視の層を導入し、コンフィギュレーションが有効になる前に、第二の目でコンフィギュレーションをレビューし、承認することを可能にします。 セキュリティ・ポリシーのコンフィギュレーションは、トラフィック・フローの中で直接適用されるため、ポリシーに誤りがあると、サービスが中断され、直接的な金銭的影響が生じる可能性があります。 セキュリティポリシー構成特有の複雑さに対処するため、変更をシリアライズするのが一般的です。 これは、1 つのタイプの構成を変更すると、前の構成が適用されるか取り消されるまで、同じタイプの他の構成セッションが開始されないことを意味します。 しかし、すべての脅威およびアクセス制御機能を包含する単一のポリシー テーブルを使用する場合、変更をシリアライズすると、他の管理者が実行する構成調整に遅延が生じる可能性があります。 対照的に、マルチテーブルアプローチはこのシナリオに効果的に対処することができ、異なる管理者が別々のテーブルで同時に作業できるため、構成変更プロセスを合理化できます。

すべての組織が同じ要件を共有しているわけではありません：

SASEは通常サービスとして提供され、SASEプロバイダーは複数の組織を顧客としています。 これらの組織は、規模、規制要件、組織内の役割の多様性などの点で大きく異なります。 オンプレミスまたはクラウドで複数のアプリケーションをホストしている組織もあれば、SaaSプロバイダーのサービスだけに依存している組織もあり、両方を組み合わせている組織もあります。 さらに、組織によっては、様々な管理ロールや複数の管理ユーザを必要としない場合もあります。 限られた数のアプリケーションしか持たず、複数の管理者ロールのような複雑さがない場合、より少ないポリシーテーブルを使用することに価値を見出すかもしれません。 SASEは、このような多様なニーズに対応するために必要な柔軟性を提供するように設計されており、複数の関連するセキュリティ機能やアプリケーションに対して統合ポリシーテーブルを使用するオプションも含まれています。

混乱を避けるための設定

ある種のSASEソリューションは、前述したように、簡素化を追求するために、ポリシーが様々なマッチング属性の値で構成できる単一の包括的なポリシーテーブルを選択します。 トラフィック処理の間、ポリシーの選択は、ポリシーで指定された属性値に対して、受信トラフィックと他のコンテキスト情報の値を照合することに基づいています。 しかし、トラフィック処理中、トラフィックのすべての属性がすぐにわかるわけではないことを認識することが重要です。 例えば、ステートフルインスペクションファイアウォールの場合、抽出できるトラフィック値は5タプル情報（送信元IP、宛先IP、送信元ポート、宛先ポート、IPプロトコル）のような限られたセットのみです。 一方、SWG、ZTNA、CASB のようなプロキシベースのセキュリティ・コンポーネントの場合、属性値の抽出はさまざまで、特に TLS 検査前と TLS 検査後の段階など、異なる段階を含むことがあります。 TLS 検査/復号化の前では、多くの HTTP 属性は未知のままです。 アクセス URI パス、HTTP メソッド、リクエストヘッダなどの追加属性が評価可能になるのは、TLS 復号化後です。 セキュリティポリシーの設定を担当する管理者として、管理者がポリシーを定義しながら、パケット処理の様々な段階でどの属性が有効かを追跡することを期待するのは非現実的です。 いくつかのセキュリティ・ソリューションは、無関係な属性はポリシーの評価で考慮されないと主張していますが、複雑なポリシーを検査する場合、どの属性が適切で、どの属性が適切でないかを判断することは困難です。 私たちは、複数の段階にまたがるポリシーのテーブルを単一のテーブルに統合することは、管理者に複雑さと混乱をもたらすと確信しています。 このようなアプローチは、理解するのが難しく、混乱を招く可能性のある構成につながる可能性があります。 明確にするためには、一貫性のあるわかりやすい評価のために、関連する属性のみを含むポリシーを所定のテーブル内に作成することをお勧めします。

拒否と許可ポリシーテーブルの最適化：

ある種のセキュリティ・ソリューションでは、「拒否」と「許可」のポリシー・テーブルを別々に保持する構造を採用しています。 この設定では、「拒否」リストで定義されたポリシーが優先され、最初に評価されます。 Deny」テーブルで一致するポリシーが見つからない場合、評価は「Allow」ポリシーテーブルに進みます。 しかし、ポリシーを 2 つの異なるテーブルに分割することは、管理者にとって課題となります。 私たちは、任意のポリシー テーブルがポリシーの順序付きリストとして表示される、より合理的なアプローチを強く支持します。 この配置では、各ポリシーが、「拒否」、「許可」、またはその他の希望するアクションなど、そのアクションを明示的に指定します。 トラフィック処理中、ポリシーの評価は、一致するポリシーが見つかるまで、最も優先度の高いポリシーから最も優先度の低いポリシーへと論理的な進行に従って行われます。 一致するポリシーが特定されると、対応するアクションがトラフィックに適用されます。 一致するポリシーがない場合は、組織のセキュリティ・ポリシーによって定義された「フェイル・オープン」や「フェイル・クローズ」などのデフォルト・アクションがトリガーされます。 このアプローチでは、ポリシーのアクション値に関係なく、ポリシーを単一の順序付きリスト内に統合することにより、ポリシー管理を簡素化し、管理者のわかりやすさを向上させます。 アクション値に基づいてポリシーテーブルを分離しないことにより、SASEソリューションプロバイダは、将来的に新しいアクション値を比較的容易に導入することができます。

柔軟で表現力豊かな政策の創造：

お分かりのように、管理者は一致する属性の値のセットを定義することによってポリシーを作成します。 従来、トラフィックの評価においてポリシーのマッチングがどのように行われるかについては、ポリシーで指定されたすべての属性値が、入力されるトラフィックセッションの値と完全に一致する場合にのみ、ポリシーがマッチするとみなされるという共通の理解がありました。 これらの値は、トラフィックから直接抽出するか、認証されたユーザーコンテキストやトラフィックを開始したデバイスコンテキストなどのコンテキスト情報から推測することができます。 基本的に、このマッチングプロセスでは、ポリシーのすべての属性にわたって「AND」演算が行われます。 しかし、セキュリティ技術の進化に伴い、多くのセキュリティ・デバイスはより柔軟なアプローチを導入し、管理者に属性に複数の値を割り当てる能力を与えています。 この進化したパラダイムでは、ランタイムコンテキスト情報がポリシー属性に指定された値のいずれかと一致する場合に、一致が確立されます。 要するに、マッチング・プロセスは、属性間の「AND」演算と、それらの属性に関連する値間の「OR」演算を組み合わせるようになりました。 組織は、包括的なポリシーを作成する際に、この柔軟性から大きな利益を得ることができます。 読みやすさを維持しながら、必要なポリシーの総数を減らすことができます。 しかし、これらの多値属性は正しい方向への一歩に過ぎず、組織独自の要件を満たすためには、さらなる機能強化が必要になることがよくあります：NOT」装飾のサポート：NOT “装飾のサポート: 管理者は、”NOT “装飾でポリシー属性値を定義する機能を必要とします。
たとえば、「ソース IP」属性値を「NOT 10.1.5.0/24」と指定し、トラフィック セッションのソース IP が 10.1.5.0/24 サブネットに属さない場合にポリシーが正常に一致することを示すことができます。属性の複数のインスタンスのサポート：従来のセキュリティデバイスの多くは、ポリシー内で指定された属性のインスタンスを 1 つだけサポートしています。 包括的なポリシーを作成するには、1つのポリシー内に同じ属性の複数のインスタンスを含める機能が不可欠です。 たとえば、管理者は10.0.0.0/8サブネット内の任意のIPアドレスからのセッションを許可し、同時に10.1.5.0/24サブネットからのトラフィックセッションを拒否したい場合があります。 これは、おそらく「ソースIP」の値を「ソースIP == 10.0.0.0/8」と「ソースIP == NOT 10.1.5.0/24」のように2回指定することで、1つのポリシー内で達成できるはずです。 これにより、2つのポリシーを別々に作成する必要がなくなり、より直感的なポリシー管理が可能になります。文字列型値の装飾のサポート：URI パス、ドメイン名、多くの HTTP リクエストヘッダなど、文字列値を受け入れる属性は、’exact’、’start_with’、’ends_with’ などの装飾の恩恵を受けます。
これらの装飾は、表現力豊かなポリシーの作成を強化します。正規表現パターンのサポート：場合によっては、ポリシーはトラフィック値内のパターンマッチを必要とします。 例えば、あるポリシーが、’user agent’ リクエストヘッダ値のどこかに特定のパターンが存在する場合にのみ、トラフィックセッションが許可されることを指示するかもしれません。 このようなシナリオでは、正規表現パターンのサポートが不可欠です。動的属性のサポート：従来のポリシーの属性は固定され、事前に定義されていますが、SASE環境では動的な属性が必要になることがあります。 リクエストとレスポンスのヘッダやJWTクレームを考えてみましょう。 SASEは、管理者がカスタムヘッダやクレームに対応したポリシーを作成できるようにする必要があります。 例えば、SASEはリクエストヘッダ’X-custom-header’を属性とし、値’matchme’を持つポリシーの作成を許可するべきです。トラフィック時に、’X-custom-header’をリクエストヘッダの一つとして、’matchme’を値として持つHTTPセッションは、ポリシーにマッチするはずです。オブジェクトのサポート：この機能では、値を即座に指定するのではなく、ポリシーの属性値として使用できる値を持つさまざまなタイプのオブジェクトを作成できます。 オブジェクトは、複数のポリシーで参照することができ、将来の値の変更はオブジェクトレベルで行うことができるため、ポリシーの変更を簡素化し、一貫性を確保することができます。 これらの機能強化により、柔軟で表現力豊かな効率的なセキュリティポリシーの作成が可能になり、組織独自のセキュリティニーズやシナリオに合わせて効果的にポリシーをカスタマイズできるようになります。

トラフィック修正によるポリシー統合の強化

最も一般的な使用例では、HTTP リクエスト/レスポンスヘッダとその値、クエリパラメータとその値、さらにはリクエスト/レスポンスボディの追加、削除、または変更が含まれます。 これらの変更は、管理者の設定によって大きく異なります。 多くの場合、特定の変更は、宛先アプリケーション/サイトサービスなどのトラフィック値と、トラフィック実行時に利用可能なコンテキスト情報に依存します。 トラフィックの変更のために別のポリシーテーブルを維持するよりも、多くの場合、アクセスポリシー自体にこれらの変更オブジェクトを含める方が効率的です。 このアプローチは、ポリシー管理を合理化し、変更がトラフィックの動作を制御するポリシーと直接整合していることを保証します。 トラフィックの変更が不可欠な顕著なシナリオの1つは、クラウド・アクセス・セキュリティ・ブローカー（CASB）ソリューションのコンテキストで、特に組織がマルチテナントの制限を必要とする場合です。 このような制限には、特定のリクエストヘッダと値を追加して、コラボレーション固有のポリシーを適用することがよくあります。 さらに、エンドツーエンドのトラブルシューティングやパフォーマンス分析のためのカスタムヘッダの追加など、トラフィックの変更が重要な役割を果たす場合もあります。 そのため、組織はSASEソリューションが修正オブジェクトとシームレスに統合するポリシーをサポートすることを期待しています。 トラフィック処理中、一致したポリシーが適切な修正オブジェクトに関連付けられた場合、トラフィック修正が実行され、トラフィック管理とポリシー実施への統一された効率的なアプローチが提供されます。

観察力の強化：

観測可能性を目的として、セッションの終了時にすべてのトラフィックセッションをログに記録することが一般的です。 実質的な、または「象」のセッションを含む場合、アクセス情報を定期的にログに記録することも通例です。 これらのセッションログには、通常、トラフィックのメタデータ、セッション中に実行されたアクション、クライアントとサーバ間で転送されたパケットやバイトに関する詳細などの貴重なデータが含まれています。 SASEによって提供される1つの重要な進歩は、セキュリティ機能の統合とシングルパス、ランタイムコンプリートアーキテクチャの採用です。 これは、SASE以外のセキュリティ導入では、個々のセキュリティコンポーネントが、独自のセッションログを生成し、多くの場合、マッチングされたポリシーやマッチングプロセスで使用された重要な属性値に関する情報を含んでいるのとは対照的です。 重要なことは、SASEが単一のログを生成する一方で、重要な情報を含むことに妥協すべきではないという期待です。 トラフィックセッションが、様々なセキュリティ機能とポリシーテーブルにわたる複数のポリシー評価によって許可される場合、結果のログは、マッチした全てのポリシーに関する情報を含むべきです。 さらに、特定のトラフィック属性またはコンテキスト属性の値によってポリシーが一致する場合、ログは、ポリシーの一致につながった属性値に関する正確な詳細を提供する必要があります。 組織が効果的な観測可能性のために包括的なログに依存していることを考えると、SASEソリューションは、管理者がネットワークトラフィックを効果的に監視し、分析するために必要なデータにアクセスできることを保証し、ログの中に完全な情報を提供することが期待されています。

政策管理へのSASEアプローチ：

すべてのSASEソリューションが同じではないことを認識することが重要です。 組織は、特定のSASEソリューションが、ユーザビリティを犠牲にすることなく、組織固有の要件に合致しているかどうかを慎重に評価する必要があります。 組織は、当初は上記の要件をすべて持っていないかもしれませんが、これらの要件が業務にますます関連し、不可欠になるのは時間の問題です。 前述の要件をすべて満たす組織は、SASEポリシーを特定のニーズに合わせて柔軟に調整できるという利点があります。 一方、現在これらの要件をすべて満たしていない組織は、よりシンプルなユーザーエクスペリエンスを求める一方で、要件が進化するにつれて追加機能の導入も視野に入れています。 このアプローチにより、組織は現在のニーズと将来の成長のバランスを取ることができ、SASEソリューションが状況の変化に適応し、対応し続けることができます。 SASEソリューションが完全な柔軟性を提供しない限り、カスタマイズは困難になります。 したがって、SASEソリューションは、以下のコア機能を提供する必要があると考えます：

  1. モジュラーポリシー管理：SASEソリューションは、複数のセキュリティ機能を包含しており、それぞれが独自のポリシー設定を持っています。 これらの設定には、有効/無効のオプション、ポリシーがマッチしない場合のデフォルトアクションの設定、複数のポリシーテーブルの収集管理、各ポリシーテーブル内の複数のポリシーの定義、ポリシーの順序付きリストの確立、各ポリシーのアクション設定、変更オブジェクト、マッチング属性、および値の設定が含まれます。
  2. ポリシーの連鎖：より具体的できめ細かいポリシーを可能にするために、SASEソリューションはポリシーの連鎖をサポートする必要があります。 これは、コレクション内の複数のポリシーテーブルにわたってポリシーの配置を許可することを意味します。 例えば、組織は、異なるアプリケーションのために別々のポリシーテーブルを持つことができ、メインテーブルのポリシーは、適切なポリシーテーブルを選択するためのマッチング基準としてアプリケーション/ドメイン名を使用します。 これは通常、ポリシーの評価を参照するポリシー テーブルにリダイレクトする「ジャンプ」と呼ばれるアクションを備えたポリシーを使用することで実現されます。 ポリシーの連鎖という概念は Linux IPTables で人気を博し、その後多くのセキュリティソリューションがこの機能を取り入れました。

SASEにおけるセキュリティ機能の包括性は、広範囲に及びます：

  • NGFW（次世代ファイアウォール）：L3/L4アクセス制御、DDoS防御、IPレピュテーション、ドメインレピュテーション、侵入検知防御システム（IDPS）を提供します。
  • SWG（セキュア・ウェブ・ゲートウェイ）：TLSインスペクション、プレTLSウェブアクセスコントロール、ポストTLSウェブアクセスコントロール、URLレピュテーション、ファイルレピュテーション、マルウェアプロテクションを提供。
  • ZTNA（Zero Trust Network Access）：SWGと似ていますが、ホストされたアプリケーションのセキュリティに重点を置いています。
  • CASB（クラウドアクセスセキュリティブローカー）：クラウドサービスレピュテーションとクラウドサービスアクセス制御をカバー。
  • DLP（データ損失防止）：個人を特定できる情報（PII）、標準的な機密文書、企業特有の機密文書に基づくアクセス制御の実施。

各セキュリティ機能に対するポリシー管理の柔軟性と、ポリシーの連鎖による複数のポリシーテーブルを介して各機能内のポリシーを管理する機能は、強力な機能です。 さまざまな規制要件を持つ地理的に分散した組織は、この柔軟性から特に恩恵を受けることができます。 しかし、小規模な組織では、ポリシー テーブルを何らかの形で統合することを好むかもしれません。 そのような場合は、以下の方法で構成をカスタマイズできるはずです：

  • 複数のSWG/ZTNAコンポーネントにまたがる、TLS以前のすべてのセキュリティ機能設定を、単一のポリシーテーブルのコレクションに統合。
  • すべてのポストTLSセキュリティ機能設定を、複数のSWG/ZTNAコンポーネントにわたるポリシーテーブルの別の単一のコレクションに統合します。
  • 複雑なポリシー定義を必要とするため、CASB、マルウェア、DLPの各機能を別個のエンティティとして保持します。
  • ポリシー・テーブル・コレクション内の単一のポリシー・テーブルを選択することで、ポリシーの連鎖を避けることができます。

そのため、組織は、柔軟性を提供しながら、関連するセキュリティ機能の設定を統合するカスタムコントロールも提供するSASEサービスを探す必要があります。 このアプローチにより、SASEのポリシーは、組織固有のニーズに合わせられると同時に、管理しやすく、要件が変化してもスケーラビリティを維持することができます。

ユーザーエクスペリエンスと将来を見据えた柔軟性のバランス

セキュリティ・ポリシー管理は、歴史的に複雑な取り組みでした。 多くの製品は、特定のセキュリティアプライアンスのポリシー管理に特化しており、その結果、断片的な状況になっています。 SASEは、複数のセキュリティ・アプライアンスを統合ソリューションに統合することで、この複雑さに対処します。 この統合には利点がありますが、同時に複雑さも伴います。 単一のポリシーテーブルのようなポリシー管理への従来のアプローチは、当初は魅力的に見えるかもしれません。 しかし、これには多くの課題があり、多くの場合、この記事で説明した要件を満たすことはできません。 逆に、過剰な数のポリシー エンジンを持つことも複雑さにつながります。 柔軟性とシンプルさの適切なバランスを取ることが最も重要です。 業界における重要な課題の 1 つは、ポリシーの急増です。 過剰な数のポリシーは、ユーザーとトラブルシューティングのエクスペリエンスを低下させるだけでなく、パフォーマンスにも影響します。 前述したように、マルチテーブルアプローチとポリシーの表現力は、ポリシーテーブル内のポリシーの量を減らすために不可欠な戦略です。 SASEソリューションは、ポリシー管理をより洗練されたものにすることで、ますますこれらの複雑さに対処しています。 SASEソリューションは進化し続け、近い将来、この記事で詳述した要件の多くを実装することになるでしょう。 この進化により、組織は、ユーザエクスペリエンス、柔軟性、およびパフォーマンスの間で最適なバランスを取ることができるようになり、急速に変化する脅威のランドスケープにおいて、セキュリティポリシーが効果的であり続け、適応可能であることが保証されます。

  • CTOインサイトブログ

    Aryaka CTO Insightsブログシリーズは、ネットワーク、セキュリティ、およびSASEのトピックに関するソートリーダーシップを提供します。
    Aryaka製品の仕様については、Aryakaデータシートを参照してください。