セキュリティをシンプルにする: 統合されたポリシーを合理化する SASE
セキュリティ リスクと管理の複雑さを軽減するには、構成と制御のバランスを取ることが重要です
セキュア アクセス サービス エッジ (SASE) サービスは、それに関連するアーキテクチャとともに、複数のセキュリティ コンポーネントの強力な融合で構成されています。 これらには、ステートフル検査ファイアウォール、侵入検知および防止システム (IDPS)、 DNS セキュリティ、DoS/DDoS 保護、セキュア Web ゲートウェイ (SWG)、ゼロトラスト ネットワーク アーキテクチャ (ZTNA)、 Cloud アクセスセキュリティブローカー (CASB）、 などなど。 これらのコンポーネントを使用すると、管理者はポリシーを通じてコンポーネントを構成できるようになり、特定のアクセス要件を遵守しながら組織の資産を脅威から保護するための堅牢なシールドを提供します。
ポリシー設定の役割
ポリシー設定はインドを再生しますisp内部のセキュリティを強化する役割を有効にする SASE フレームワーク。 不適切に構成されたポリシーの影響は、リソースの脅威やデータ漏洩から、意図しない過度に許容的なアクセスまで多岐にわたります。 今日の業界情勢では、組織はセキュリティ ポリシー管理に対する XNUMX つの主要なアプローチに取り組んでいます。
- 単一テーブルのアプローチ: 脅威管理とさまざまなアクセス制御シナリオにまたがる無数のポリシーを含む統合ポリシー テーブル SASE コンポーネント.
- 複数テーブルのアプローチ: 複数のポリシー テーブル。それぞれが脅威保護、アクセス制御、さまざまなアプリケーション、ユーザー グループなどの特定の側面に対応しています。
ポリシー管理のバランスをとる
からの期待 SASE 明確です。管理しやすいセキュリティ ポリシーと簡素化されたトラブルシューティング手順を提供する必要があります。 これを達成するには、バランスの取れたアプローチが必要です。 組織の要件に基づいてポリシーの複雑さを軽減する効果的な戦略の XNUMX つ。 大規模な組織では、ポリシー テーブルの粒度がセキュリティ機能、アプリケーション リソース、およびサブジェクト (ユーザー/グループ) に基づいて定義されるマルチテーブル アプローチによる区分化が必要になる場合があります。 小規模な組織では、複数のタイプのアクセス制御を組み合わせたり、脅威保護とアクセス制御を組み合わせたりする、より少ない数のポリシー テーブルによる区分化を好む場合があります。 この柔軟なアプローチにより、同時管理が必要なポリシーの数が最小限に抑えられ、ポリシーがより管理しやすくなります。
ただし、過度の区画化を避けるために注意することが重要であり、それによって独自の課題が生じる可能性があります。 管理者は、問題を特定して対処するために複数のポリシー テーブルをナビゲートする必要があり、解決が遅れる可能性があります。
主要な要件を理解する
ポリシー管理の複雑さを深く掘り下げる前に、組織がポリシー内で対処する必要がある特定の要件を理解することが重要です。 SASE フレームワーク。 主要な分野は次のとおりです。
ロールベースのセキュリティ構成管理の必要性 SASE 環境
セキュア アクセス サービス エッジ (SASE) これらのコンポーネントは、従業員、パートナー、ゲストを含む、さまざまな組織にわたる幅広いリソースに対する脅威保護とアクセス制御を含む、包括的なセキュリティを提供します。 このセキュリティ フレームワーク内では、多くの場合、組織にはセキュリティのさまざまな側面を担当する管理者の明確なカテゴリが存在します。
たとえば、組織には、脅威からの保護の管理を専門とする管理者のグループがあり、別のグループはアクセス制御に重点を置く場合があります。 これらの広範なカテゴリ内で、組織は特定のタイプの脅威保護とアクセス制御に合わせたさまざまな管理役割を確立するのが一般的です。 いくつかの実際的な例を詳しく見てみましょう。
脅威保護の役割:
- 侵入検知とファイアウォール構成: 「脅威保護」を備えた管理者ngfw-role」には、侵入検知とファイアウォール設定を構成するためのアクセスが付与されます。 SASE 環境。
- 評判の制御: 「threat-protection-reputation-role」を持つ管理者は、IP レピュテーション制御に関連する設定を管理できます。 URLベースのレピュテーション コントロール、ドメイン ベースのレピュテーション コントロール、ファイル レピュテーション コントロール、および cloud-サービスと cloud-組織の評判管理。
- マルウェア保護： 「threat-protection-malware-protection-role」を持つ管理者は、特にマルウェア保護制御に関連する設定を構成する権限を持っています。
アクセス制御の役割:
- SWG 構成: 「access-control-Internet-role」として指定された管理者は、Secure Web Gateway (SWG) 構成の管理を担当します。
- SaaS アプリケーション固有のアクセス制御: 「アクセス制御」のような役割saas1app-role」と「access-control-saasNapp-role」は、特定のアプリケーションのアクセス制御ポリシーの構成に重点を置いています (SaaS サービス1と SaaS サービス N)、きめ細かい制御を保証します。
- 耳鼻咽喉科erpアプリケーション管理の向上: 「access-control-hostedapp1-role」や「access-control-hostedappM-role」などのロールは、ent のアクセス制御設定の処理専用です。erp上位レベルのアプリケーション、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 の従業員のアクセス制御構成の管理が容易になります。 。
さらに、非マルチテナント エンティティであっても、erprise アプリケーションでは、従業員セグメントごとに個別の管理者が必要になる場合があります。 例えば：
- エンジニアリング部門： 「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 部門に関連するアクセス制御構成に対する責任を負います。
ロールベースのセキュリティ構成管理の大きな利点は、特定の責任に合わせたきめ細かい制御を提供できることです。 このアプローチを、単一の包括的なポリシー テーブルを使用する場合に発生する可能性のある課題と比較してください。
- エラーを起こしやすい： 複数の管理者が同じポリシー テーブルを使用し、権限が重複していると、ポリシーを追加、削除、または変更するときに誤ってエラーが発生する可能性があります。
- 複雑さのトラブルシューティング: モノリシックなポリシー テーブル内の問題を解決することは、時間がかかり、困難な場合があります。
- ポリシーの過負荷: すべてのポリシーを XNUMX つのテーブルに統合し、さまざまなアプリケーションや脅威からの保護シナリオをカバーすると、ポリシー管理エクスペリエンスが煩雑で扱いにくくなるだけでなく、ポリシー評価中にパフォーマンス上の問題が発生する可能性があります。
結論として、ロールベースのセキュリティ構成管理を社内に導入することは、 SASE これらの環境により、組織は単一テーブル アプローチに伴う複雑さを回避しながら、効率的に責任を委任し、セキュリティを強化し、ポリシー管理を合理化できるようになります。
構成変更管理管理との連携
組織は、以下を含むすべての構成に対して変更管理管理をますます採用しています。 SASE 構成エラーが実装される前に、事前に検出して修正します。 この慣行は安全策として機能するだけでなく、第 XNUMX の監視層を導入し、構成が有効になる前に第 XNUMX の目で構成を確認して承認できるようにします。
セキュリティ ポリシーの構成はトラフィック フロー内に直接適用されるため、ポリシーにエラーがあるとサービスに支障をきたし、直接的な経済的影響を招く可能性があります。
セキュリティ ポリシー構成に固有の複雑さに対処するために、変更をシリアル化するのが一般的です。 これは、あるタイプの構成を変更する場合、前のセッションが適用されるか取り消されるまで、同じタイプの他の構成セッションは開始されないことを意味します。 ただし、すべての脅威およびアクセス制御機能を網羅する単一のポリシー テーブルを使用する場合、変更をシリアル化すると、他の管理者が実行する構成調整に遅れが生じる可能性があります。
対照的に、複数テーブルのアプローチでは、このシナリオに効果的に対処でき、異なる管理者が別々のテーブルで同時に作業できるため、構成変更プロセスが合理化されます。
すべての組織が同じ要件を共有しているわけではありません:
SASE 通常はサービスとして提供され、 SASE プロバイダーは複数の組織に顧客としてサービスを提供する場合があります。 これらの組織は、その規模、規制要件、組織内での役割の多様性の点で大きく異なる場合があります。 組織によっては、オンプレミスまたは社内で複数のアプリケーションをホストする場合があります。 cloudのサービスのみに依存する人もいます。 SaaS プロバイダーがあり、両方の組み合わせを組み込んでいる場合もあります。
さらに、特定の組織では、さまざまな管理役割や複数の管理ユーザーが必要ない場合があります。 組織が限られた数のアプリケーションしか持たず、複数の管理役割の複雑さが欠けているシナリオでは、使用するポリシー テーブルの数を減らすことに価値があると考えられます。
SASE は、関連する複数のセキュリティ機能やアプリケーションに統合ポリシー テーブルを使用するオプションなど、さまざまなニーズに対応するために必要な柔軟性を提供するように設計されることが期待されています。
混乱を招く構成を避ける:
特定の SASE ソリューションは、前に説明したように簡素化を追求するため、さまざまな一致する属性の値を使用してポリシーを構成できる、単一の包括的なポリシー テーブルを選択します。 トラフィック処理中、ポリシーの選択は、受信トラフィックの値およびその他のコンテキスト情報と、ポリシーで指定された属性値との照合に基づいて行われます。
ただし、トラフィックの処理中に、トラフィックのすべての属性がすぐにわかるわけではないことを認識することが重要です。 たとえば、ステートフル インスペクション ファイアウォールの場合、5 タプル情報 (送信元 IP、宛先 IP、送信元ポート、宛先ポート、および IP プロトコル) など、限られたトラフィック値のセットのみを抽出できます。 一方、SWG、ZTNA、および CASB、属性値の抽出はさまざまであり、異なる段階、特に TLS 前検査フェーズと TLS 後検査フェーズが含まれる場合があります。
TLS 検査/復号化の前には、多くの HTTP 属性が不明のままです。 アクセス URI パス、HTTP メソッド、リクエスト ヘッダーなどの追加属性が評価に使用できるようになるのは、TLS 復号化後です。
セキュリティ ポリシーの構成を担当する管理者として、ポリシーを定義する際に、パケット処理のさまざまな段階でどの属性が有効であるかを追跡することを期待するのは現実的ではありません。 一部のセキュリティ ソリューションでは、無関係な属性はポリシーの評価では考慮されないと主張していますが、複雑なポリシーを検査する場合、どの属性が適切でどの属性が適切でないかを判断するのは困難な場合があります。
私たちは、複数の段階にまたがるポリシー テーブルを XNUMX つのテーブルに統合すると、管理者にとって複雑さと混乱が生じると確信しています。 このようなアプローチは理解するのが難しく、潜在的に問題を引き起こす可能性があります。erpレクシング構成。 明確さを確保するために、一貫性のある直接的な評価に関連する属性のみを含むポリシーを特定のテーブル内に作成することをお勧めします。
拒否および許可ポリシー テーブルの最適化:
特定のセキュリティ ソリューションでは、「拒否」と「許可」のポリシー テーブルを個別に管理する構造が採用されています。 この設定内では、「拒否」リストで定義されたポリシーが優先され、最初に評価されます。 「拒否」テーブルに一致するポリシーが見つからない場合、評価は「許可」ポリシー テーブルに進みます。 ただし、ポリシーを XNUMX つの異なるテーブルに分割すると、管理者にとって課題が生じる可能性があります。
私たちは、特定のポリシー テーブルがポリシーの順序付きリストとして表示される、より合理化されたアプローチを強く主張します。 この構成では、各ポリシーはそのアクション (「拒否」、「許可」、またはその他の必要なアクション) を明示的に指定します。 トラフィック処理中、ポリシー評価は、一致が見つかるまで、最も優先度の高いポリシーから最も低い優先度のポリシーへの論理的な進行に従います。 一致するポリシーが特定されると、対応するアクションがトラフィックに適用されます。 一致するポリシーが見つからない場合は、組織のセキュリティ ポリシーの定義に従って、「フェール オープン」または「フェール クローズ」などのデフォルトのアクションがトリガーされます。
このアプローチでは、ポリシー アクションの値に関係なく、単一の順序付きリスト内にポリシーを統合することで、ポリシー管理が簡素化され、管理者の明確さが向上します。これにより、複雑さが最小限に抑えられ、ポリシー評価プロセスが合理化されます。 アクション値に基づいてポリシー テーブルを分離しないことも有効化 SASE ソリューションプロバイダーは、将来的に新しいアクション値を比較的簡単に導入できるようになります。
柔軟で表現力豊かなポリシーの作成:
ここまで説明したように、管理者は、一致する属性の値のセットを定義することによってポリシーを作成します。 従来、トラフィック評価中にポリシー照合がどのように動作するかについては、共通の理解がありました。ポリシーは、ポリシーで指定されたすべての属性値が受信トラフィック セッションの値と完全に一致する場合にのみ一致するとみなされます。 これらの値は、トラフィックから直接抽出することも、認証されたユーザー コンテキストやトラフィックの開始に関与するデバイス コンテキストなどのコンテキスト情報から推測することもできます。 基本的に、この照合プロセスには、ポリシーのすべての属性にわたる「AND」演算が含まれます。
ただし、セキュリティ テクノロジの進化に伴い、多くのセキュリティ デバイスではより柔軟なアプローチが導入され、管理者が属性に複数の値を割り当てることができるようになりました。 この進化したパラダイムでは、実行時のコンテキスト情報がポリシー属性に指定された値のいずれかと一致する場合に一致が確立されます。 基本的に、一致プロセスでは、属性間の「AND」演算と、それらの属性に関連付けられた値間の「OR」演算が組み合わされます。
組織は、包括的なポリシーを作成する際に、この柔軟性から大きな恩恵を受けることができます。 読みやすさを維持しながら、必要なポリシーの総数が削減されます。 ただし、これらの複数値属性は正しい方向への XNUMX つのステップにすぎず、組織固有の要件を満たすためにはさらなる機能強化が必要になることがよくあります。
「NOT」装飾のサポート: 管理者は、「NOT」装飾を使用してポリシー属性値を定義できる必要があります。 たとえば、「ソース IP」属性値を「NOT 10.1.5.0/24」として指定でき、トラフィック セッションのソース IP が 10.1.5.0/24 サブネットに属さない場合にポリシーが正常に一致することを示します。 。
属性の複数のインスタンスのサポート: 従来のセキュリティ デバイスの多くは、ポリシー内の特定の属性のインスタンスを XNUMX つだけサポートします。 包括的なポリシーを作成するには、単一のポリシー内に同じ属性の複数のインスタンスを含める機能が不可欠です。 たとえば、管理者は次のようにします。 wan10.0.0.0/8 サブネット内の任意の IP アドレスからのセッションを許可しながら、同時に 10.1.5.0/24 サブネットからのトラフィック セッションを拒否します。 これは、おそらく「source IP」の値を 10.0.0.0 回指定することで、単一のポリシー内で実現可能です: 「source IP == 8/10.1.5.0」と「source IP == NOT 24/XNUMX」。 これにより、XNUMX つの個別のポリシーを作成する必要がなくなり、より直感的なポリシー管理が可能になります。
文字列型値の装飾のサポート: URI パス、ドメイン名、多くの HTTP リクエスト ヘッダーなどの文字列値を受け入れる属性は、「exact」、「starts_with」、「ends_with」などの装飾の恩恵を受けます。 これらの装飾は、表現ポリシーの作成を強化します。
正規表現パターンのサポート: 場合によっては、ポリシーでトラフィック値内のパターン マッチングが必要になることがあります。 たとえば、ポリシーでは、「ユーザー エージェント」要求ヘッダー値のどこかに特定のパターンが存在する場合にのみトラフィック セッションが許可されるように指示できます。 このようなシナリオでは、正規表現パターンのサポートが不可欠です。
動的属性のサポート: ポリシーの従来の属性は固定され事前定義されていますが、 SASE 環境では動的属性が必要な場合があります。 標準が多数のカスタム ヘッダーやクレームと共存する、リクエスト ヘッダーと応答ヘッダー、または JWT クレームを検討してください。 SASE 管理者がカスタム ヘッダーとクレームに対応するポリシーを作成できるようにする必要があります。 例えば、 SASE 属性としてリクエスト ヘッダー「X-custom-header」と値「matchme」を使用したポリシーの作成を許可する必要があります。 トラフィック時には、リクエスト ヘッダーの XNUMX つとして「X-custom-header」、値として「matchme」を持つ HTTP セッションがポリシーに一致する必要があります。
オブジェクトのサポート: この機能を使用すると、即時の値を指定するのではなく、ポリシーの属性値として使用できる値を持つさまざまなタイプのオブジェクトを作成できます。 オブジェクトは複数のポリシー間で参照でき、将来の値の変更はオブジェクト レベルで行うことができるため、ポリシーの変更が簡素化され、一貫性が確保されます。
これらの機能強化は、柔軟で表現力豊かで効率的なセキュリティ ポリシーの作成に貢献し、組織が独自のセキュリティ ニーズやシナリオに合わせてポリシーを効果的に調整できるようにします。
トラフィック変更によるポリシー統合の強化
特定のセキュリティ機能ではトラフィックの変更が必要ですが、最も一般的な使用例には、HTTP リクエスト/応答ヘッダーとその値、クエリ パラメータとその値、さらにはリクエスト/応答本文の追加、削除、または変更が含まれます。 これらの変更は、管理者の構成に応じて大きく異なる場合があります。 多くの場合、特定の変更は、宛先アプリケーション/サイト サービスなどのトラフィック値や、トラフィック実行時に利用可能なコンテキスト情報に依存します。
多くの場合、トラフィック変更用に別のポリシー テーブルを維持するよりも、これらの変更オブジェクトをアクセス ポリシー自体に含めた方が効率的です。 このアプローチにより、ポリシー管理が合理化され、変更がトラフィックの動作を管理するポリシーに直接整合することが保証されます。
トラフィックの変更が不可欠となる顕著なシナリオの XNUMX つは、次のような状況です。 Cloud アクセスセキュリティブローカー (CASB) ソリューション、特に組織がマルチテナントの制限を必要とする場合。 これらの制限には、多くの場合、コラボレーション固有のポリシーを強制するための特定のリクエスト ヘッダーと値の追加が含まれます。 さらに、エンドツーエンドのトラブルシューティングやパフォーマンス分析のためのカスタム ヘッダーの追加など、トラフィックの変更が重要な役割を果たす場合もあります。
したがって、組織は次のことを期待しています。 SASE シームレスな政策をサポートするソリューションssly 変更オブジェクトと統合します。 トラフィック処理中に、一致したポリシーが適切な変更オブジェクトに関連付けられるとトラフィックの変更が実行され、トラフィック管理とポリシーの適用に対する統合された効率的なアプローチが提供されます。
可観測性の向上:
可観測性を目的として、セッションの終了時にすべてのトラフィック セッションをログに記録するのが一般的です。 実質的なセッションまたは「象」セッションが関係する場合、アクセス情報を定期的に記録することも一般的です。 これらのセッション ログには通常、トラフィック メタデータ、セッション中に実行されたアクション、クライアントとサーバー間で転送されたパケットとバイトに関する詳細などの貴重なデータが含まれています。
によって提供される XNUMX つの重要な進歩 SASE これは、セキュリティ機能の統合と、シングルパスのランタイム完了アーキテクチャの採用により、統合されたセッション ログが実現されます。 これは非SASE セキュリティ展開では、個々のセキュリティ コンポーネントが独自のセッション ログを生成します。セッション ログには、多くの場合、一致したポリシーに関する情報や、一致プロセスで使用された重要な属性値が含まれます。 重要なのは、一方で SASE 単一のログを生成する場合、重要な情報を含めることに妥協しないことが期待されます。
さまざまなセキュリティ機能およびポリシー テーブルにわたる複数のポリシー評価によりトラフィック セッションが許可される場合、結果のログには、一致したすべてのポリシーに関する情報が含まれる必要があります。 さらに、特定のトラフィックまたはコンテキスト属性の値によりポリシーが一致する場合、ポリシーの一致に至った属性値に関する正確な詳細がログに提供される必要があります。
組織が効果的な可観測性を得るために包括的なログに依存していることを考えると、 SASE ソリューションは、ログに詳細な情報を提供し、管理者がネットワーク トラフィックを効果的に監視および分析するために必要なデータに確実にアクセスできるようにすることが期待されています。
SASE ポリシー管理へのアプローチ:
すべてではないことを認識することが重要です SASE 解決策は同じです。 組織は、特定の状況にあるかどうかを慎重に評価する必要があります。 SASE ソリューションは、使いやすさを犠牲にすることなく、組織固有の要件に適合します。 組織は最初から上記のすべての要件を満たしていない可能性がありますが、それは単なる要件にすぎません。 mattこれらの要件がますます関連性を増し、業務に不可欠なものになるまでには、しばらく時間がかかります。
前述の要件をすべて満たしている組織は、組織をカスタマイズする際に完全な柔軟性を得ることができます。 SASE 特定のニーズに合わせたポリシーを提供します。 一方、現在これらの要件をすべて満たしていない組織は、要件の進化に応じて追加機能の導入に留意しながら、よりシンプルなユーザー エクスペリエンスを求めることがよくあります。 このアプローチにより、組織は現在のニーズと将来の成長の間でバランスをとり、確実に SASE ソリューションは常に適応性があり、状況の変化に対応できます。
そうでない限り SASE ソリューションは完全な柔軟性を提供しますが、カスタマイズは困難になります。 したがって、私たちは信じています SASE ソリューションは次のコア機能を提供する必要があります。
- モジュール式ポリシー管理: SASE ソリューションには複数のセキュリティ機能が含まれており、それぞれが独自のポリシー設定セットを備えています。 これらの設定には、有効化/無効化、ポリシーが一致しない場合のデフォルト アクションの設定、複数のポリシー テーブルのコレクションの管理、各ポリシー テーブル内での複数のポリシーの定義、ポリシーの順序付きリストの確立、およびアクション設定、変更オブジェクトの設定のオプションが含まれている必要があります。各ポリシーの一致する属性と値。
- ポリシーチェーン: より具体的で詳細なポリシーを有効にするには、 SASE ソリューションはポリシーチェーンをサポートする必要があります。 これは、コレクション内の複数のポリシー テーブルにわたってポリシーを配置できることを意味します。 たとえば、組織は、アプリケーション/ドメイン名を一致基準として使用して、適切なポリシー テーブルを選択するメイン テーブル ポリシーを使用して、さまざまなアプリケーションに対して個別のポリシー テーブルを持つことができます。 これは通常、参照されるポリシー テーブルにポリシー評価をリダイレクトする「ジャンプ」と呼ばれるアクションを特徴とするポリシーを使用することによって実現されます。 ポリシー チェーンの概念は Linux IPTables で人気を博し、その後多くのセキュリティ ソリューションにこの機能が組み込まれました。
セキュリティ機能の包括性 SASE 広範囲にわたる可能性があり、次のものが含まれる場合があります。
- NGFW (次世代ファイアウォール): L3/L4 アクセス制御、DDoS 保護、IP レピュテーション、ドメイン レピュテーション、および侵入検知および防御システム (IDPS) を提供します。
- SWG (セキュア Web ゲートウェイ): TLS インスペクション、TLS 前の Web アクセス制御、TLS 後の Web アクセス制御を提供します。 URL レピュテーション、ファイル レピュテーション、マルウェア保護。
- ZTNA (ゼロトラスト ネットワーク アクセス): SWG に似ていますが、ホストされたアプリケーションのセキュリティに重点を置いています。
- CASB (Cloud アクセス セキュリティ ブローカー): カバーする cloud サービスの評判や cloud サービスのアクセス制御。
- DLP (データ損失防止): 個人識別情報 (PII)、標準的な機密文書、およびセキュリティに基づいたアクセス制御の実装erpライズ特有の機密文書。
各セキュリティ機能のポリシー管理の柔軟性と、ポリシー チェーンを備えた複数のポリシー テーブルを介して各機能内のポリシーを管理できる機能は、強力な機能です。 さまざまな規制要件がある地理的に分散した組織は、この柔軟性の恩恵を特に受けられます。
ただし、小規模な組織では、ポリシー テーブルを何らかの形で統合することを好む場合があります。 このような場合は、次の方法で構成をカスタマイズできるはずです。
- すべての pre-TLS セキュリティ機能設定を、複数の SWG/ZTNA コンポーネントにわたるポリシー テーブルの単一のコレクションに統合します。
- すべてのポスト TLS セキュリティ機能構成を、複数の SWG/ZTNA コンポーネントにわたるポリシー テーブルの別の単一コレクションに統合します。
- 保持 CASB、マルウェア、および DLP は、複雑なポリシー定義が必要なため、別個のエンティティとして機能します。
- ポリシー テーブル コレクション内の単一のポリシー テーブルを選択することで、ポリシーの連鎖を回避します。
したがって、組織は次のことを求める必要があります。 SASE これらのサービスは、完全な柔軟性を提供すると同時に、関連するセキュリティ機能の構成を統合するためのカスタム コントロールも提供します。 このアプローチにより、次のことが保証されます。 SASE ポリシーは、要件の進化に応じた管理の容易さと拡張性を維持しながら、組織の特定のニーズに合わせて調整されます。
ユーザーエクスペリエンスと将来を見据えた柔軟性のバランスをとる
セキュリティ ポリシーの管理は、歴史的には複雑な取り組みでした。 多くの製品は特定のセキュリティ アプライアンスのポリシー管理に特化しているため、状況が断片化しています。 SASE は、複数のセキュリティ アプライアンスを統合ソリューションに統合することで、この複雑さに対処します。 この統合には利点もありますが、それ自体の複雑さも生じます。
単一のポリシー テーブルなど、ポリシー管理に対する従来のアプローチは、最初は魅力的に見えるかもしれません。 ただし、これらには多くの課題があり、多くの場合、この記事で概説した要件を満たすことができません。 逆に、ポリシー エンジンの数が多すぎると、複雑さが生じる可能性もあります。 柔軟性とシンプルさの適切なバランスをとることが最も重要です。
業界における重大な課題の XNUMX つは、ポリシーの急増です。 ポリシーの数が多すぎると、ユーザーとトラブルシューティングのエクスペリエンスが低下するだけでなく、パフォーマンスにも影響を及ぼします。 前述したように、複数テーブルのアプローチとポリシーの表現力は、ポリシー テーブル内のポリシーの量を削減するための重要な戦略です。
SASE ソリューションは、より洗練されたポリシー管理を提供することで、これらの複雑さにますます対処しています。 それが私たちの信念です SASE ソリューションは進化し続け、近い将来、この記事で詳しく説明されている要件の多くが実装されるでしょう。 この進化により、組織はユーザー エクスペリエンス、柔軟性、パフォーマンスの間で最適なバランスを取り、急速に変化する脅威環境においてもセキュリティ ポリシーの有効性と適応性を維持できるようになります。
-
CTO の洞察ブログ
Aryaka CTO Insights ブログ シリーズでは、ネットワーク、セキュリティ、およびセキュリティに関するソート リーダーシップを提供します。 SASE トピック。 のために Aryaka 製品仕様を参照してください Aryaka データシート。
著者,
