統合型の選択 SASE プロバイダー: 実行分離係数

パケットレベルのセキュリティ技術の共有プロセス

ステートフル インスペクション ファイアウォール、IPSEC、ロード バランシングなどのパケット レベルのネットワーキングおよびセキュリティ テクノロジにより、各パケットに必要な CPU サイクル数という点での計算需要が低くなります。 さらに、パケットごとの処理の一貫性が高く、パフォーマンスの予測が容易になります。

今日の状況では、セキュリティ機能 (FWaaS など) は、これらの機能をシステムに展開するサービス プロバイダーによってサービスとして提供されます。 Cloud/プレゼンスのポイント (PoPs）。 複数のテナントに対応するために、基盤となるセキュリティ テクノロジの実装では、仮想ルーティングおよび転送 (VRF) テナント モデルを活用します。 このモデルでは、複数のテナントからのトラフィックが同じセキュリティ デバイスまたはコンテナ/プロセスを通過し、テナント間の IP アドレスの重複に関連する課題に効果的に対処します。 テナントのトラフィックは、トンネル インターフェイスまたはその他のメカニズムを通じて識別され、テナント固有のセキュリティ ポリシーなど、各テナントに合わせた特定の構成がそれに応じて適用されます。

潜在的な「ノイジーネイバー」の問題を軽減するために、テナントごとに入力時にパケット レート制限が適用されます。 この戦略により、個々のテナントのセキュリティ パフォーマンスが他の潜在的に問題のあるテナントのアクティビティの影響を受けないことが保証されます。 一貫したパケットごとの処理を考慮すると、レート制限はすべてのテナントに対して公平な処理を保証するのに効果的であることがわかります。

組織にとってのもう XNUMX つの重大な懸念は、マリによる共有プロセスまたはコンテナ内の脆弱性の悪用によって生じる機密データの漏洩の可能性です。cio他のテナントからのパケット。 セキュリティ サービス プロバイダーによってよく提示される議論の XNUMX つは、パケットごとの処理が簡単であり、脆弱性とそれに伴う悪用の可能性が低減されるというものです。 確かに、パケットレベルのセキュリティ技術の方が単純であり、この議論にはある程度の正当性があります。

前述した両方の課題、つまり「ノイジーネイバー」問題と「共有リソースの脆弱性」は、共有プロセスを利用するパケットレベルのセキュリティ技術にとって重大な問題を引き起こすことはないかもしれません。 ただし、これらの課題は、次の企業にとってより顕著かつ深刻になる可能性があると考えています。 SASE (Secure Access Service Edge) または SSE (Secure Service Edge) セキュリティ テクノロジ。

区別する SASEパケットレベルのセキュリティ技術と課題による /SSE セキュリティ

SASE/SSE (Secure Access Service Edge/Secure Service Edge) セキュリティ テクノロジは、従来のパケット レベルのセキュリティを超え、包括的な機能スイートを提供します。

• 充実したセキュリティ機能： SASE/SSE には、次のような幅広いセキュリティ機能が含まれています。 IDPS (侵入検知および防御), DNS セキュリティ, SWG (セキュアウェブゲートウェイ)、ZTNA (ゼロトラスト ネットワーク アクセス)、 CASB (Cloud アクセス セキュリティ ブローカー) IP/URL/Domain/File レピュテーション ファイアウォール、URI、要求ヘッダー、応答ヘッダー、マルウェア対策、DLP (データ漏洩防止) などの詳細なトラフィック レベル属性によるアクセス制御。 ゼロトラスト ネットワーキング (ZTN) SASE/SSE は基本であり、ID とデバイス コンテキストを考慮しながらアプリケーション リソースをきめ細かく制御して、ユーザーの認証と認可が行われた場合にのみアクセスを保証します。
• ディープコンテンツインスペクション: のコア SASE/SSE のセキュリティは詳細なコンテンツ検査にあります。 クライアント接続の管理、サーバー接続の開始、ストリームの復号化、トラフィックから関連データの抽出、セキュリティ機能の実行、およびマリファナの送信の防止を行うプロキシを利用します。cio私たちのコンテンツ。

ここで、両者の実行の違いを詳しく見てみましょう。 SASE/SSE およびパケット レベルのセキュリティ テクノロジ:

• パケット単位の処理からセッションベースの処理への移行: の文脈で SASE/SSE では、セキュリティの実行はパケットごとのレベルではなく、トラフィック セッション ストリームのレベルで動作します。 パケットごとのテクノロジーとは異なり、使用される計算サイクル数にはばらつきがあります。 SASE/SSE セキュリティ処理はテナント全体で行われます。これは次の理由からです。
  • トラフィック ストリームに適用されるセキュリティ機能はテナントによって異なる場合があります。
  • 同様のセキュリティ機能が適用されている場合でも、交換されるデータの性質により、より集中的な処理が必要になる場合があります。 たとえば、さまざまな種類のファイルからのテキストの抽出、転送されたファイルの解凍、ファイル コレクションの展開などを必要とする、マルウェア対策と DLP が関係するシナリオを考えてみましょう。 一部のテナントでは圧縮ファイルを転送する場合があり、その結果、大規模な処理が発生し、他のテナントのスループットと遅延に影響を与えます。 特定のテナントによって発生するノイズは、感染または重要なイベント中の大量のビジネス トラフィックが原因であるかに関係なく、他のテナントのトラフィック パフォーマンスに影響を与える可能性があります。
• 複雑なセキュリティ処理: SASE/SSE セキュリティ処理は本質的に複雑であり、多くの場合、サードパーティやオープンソース コンポーネントを含むさまざまなライブラリが組み込まれています。 これらには、OIDC (OpenID Connect) クライアント、Kerberos クライアント、認証用の SAMLv2 クライアント、施行用の複雑なポリシー エンジン、脅威インテリジェンス プロバイダーの SDK、データ抽出、JSON/XML デコード、base64 デコード、データ解凍エンジン、テキスト抽出などの機能が含まれます。 Tika などのオープンソース プロジェクトを介して、特にマルウェア対策や DLP などのデータ レベルのセキュリティを実現します。 この複雑さにより、悪用される可能性のある攻撃対象領域が増加します。 それでも SASE/SSE プロバイダーは脆弱性に迅速に対処することを優先しているため、悪用と解決の間には時間のギャップが存在する可能性があります。 複数のテナントに共有プロセスが採用されている場合、攻撃者は脆弱性を悪用し、対象のテナントだけでなく、その実行コンテキストを共有するすべてのテナントのデータからも機密情報にアクセスできる可能性があります。
• 独自のセキュリティ機能を導入します。 一方、 SASE/SSE サービスは、すぐに使える包括的なセキュリティ機能を提供し、Lua モジュールまたは WebAssembly (WASM) モジュールを使用してカスタム セキュリティ機能を導入する柔軟性も組織に提供します。 ただし、このような場合、共有プロセスは慎重に管理しないと他のテナントからのデータ漏洩につながる可能性があるため、重大な課題が生じます。 共有プロセスを使用すると、この問題への対処がさらに複雑になり、これらの制御を回避する潜在的な方法が常に存在する可能性があります。

要約すれば、 SASE/SSE セキュリティは、パケット レベルのセキュリティを超えた包括的なセキュリティ フレームワークを提供しますが、変動するコンピューティングの使用量、複雑な処理、および共有リソースに関連する複雑さと課題が生じます。 このような環境で堅牢なセキュリティを維持することは、パフォーマンスの問題やデータ侵害、プライバシー侵害を防ぐために重要です。

Seek SASE実行分離を提供する /SSE ソリューション

組織は間違いなくその背後にある理論的根拠を重視します SASE複数のテナントに共有プロセスを採用する /SSE プロバイダー。 このアプローチはテナント間のコンピューティング リソースを効率的に利用し、持続可能性と費用対効果に貢献します。 サービスプロバイダーは、これらのコスト削減を顧客に還元できます。

ただし、特定の業界セグメントは、マルチテナンシー アーキテクチャと共有プロセスに関連するセキュリティ リスクを受け入れることに消極的です。 組織によっては、よりリスク回避的なアプローチが将来必要になると予想している場合もあります。 このような場合、組織は次のことを求める必要があります。 SASE/SSE サービスは柔軟性を提供し、共有プロセスと専用プロセス/コンテナーの両方のオプションを提供します。

トラフィック処理用の専用プロセス/コンテナを備えた専用実行コンテキストは、前のセクションで概説した課題に効果的に対処できます。

• パフォーマンスの分離: 破壊的な「騒々しいテナント」を心配することなく、決定論的なパフォーマンスの達成が可能になります。 専用の実行コンテキストを使用すると、専用のコンピューティング リソースを個々のテナントに割り当てるのが比較的簡単になります。 計算ノード内のすべてのリソースを使い果たすノイズの多い近隣ノードからのリソース上限を構成することもできます。
• セキュリティの分離: 専用の実行コンテキストにより、あらゆる悪意のあるセキュリティが保証されます。cio私たちの意図的な、または悪用を試みる内部関係者の脅威 SASEXNUMX つのテナントの /SSE サービスは、専用の実行コンテキストを選択したテナントのデータ漏洩につながることはありません。
• 安心の「独自のセキュリティ機能の導入」: 専用の実行コンテキストにより、Lua スクリプト/WASM モジュールが専用プロセス内で排他的に実行されることが確実に保証されます。 したがって、サービス プロバイダーがこの機能を専用プロセスに対してのみ有効にしている場合、処理やデータの引き出しに関する問題は、カスタム セキュリティ機能を導入しているテナントに限定され、この点に関して他のテナントに安心を提供します。

将来のニーズを予測: Confidential Computing の重要性

今後を見据えて、一部の組織は機密コンピューティングの重要性の増大をますます認識し始めています。 この認識は、TLS インスペクションと、社内のシークレットやパスワードを含む多数の機密データの管理のコンテキストに特に関連します。 SASE/SSE サービス。 繰り返し懸念されているのは、サービス プロバイダーのスタッフを含む、サーバー インフラストラクチャにアクセスできる担当者がプロセスやコンテナのメモリに不正にアクセスする可能性に関するものです。 さらに、サーバー オペレーティング システムの悪用に成功した攻撃者であっても、これらのコンテナーやプロセスのメモリに侵入する可能性があります。 この懸念は、サービスが複数の Point of Presence (POPs）法的な定義と実装のレベルが異なるさまざまな国にまたがっています。

Intel Trust Domain Extensions (TDx) を搭載した最新のプロセッサーは、信頼できる実行のための高度な機能を提供します。 これらのテクノロジーは、メモリの内容が TDx ハードウェアによって安全に暗号化されたままであるため、インフラストラクチャ管理者や高い権限を持つ攻撃者であってもメモリの内容を解読できないようにする上で重要な役割を果たします。

SASE専用の実行コンテキストを提供する /SSE プロバイダーは、他のプロバイダーと比較して、この重要な機密性機能を提供する上で有利な立場にあります。 したがって、組織は、共有プロセスと専用の実行コンテキストの両方の柔軟性を提供するプロバイダーを検討することを強くお勧めします。 この柔軟性は、リスク軽減戦略を将来にわたって保証し、進化する状況において最高レベルのデータ セキュリティを確保するのに役立ちます。

• CTO の洞察ブログ

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