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

ステートフル・インスペクション・ファイアウォール、IPSEC、ロード・バランシングなど、パケット・レベルでのネットワーキングとセキュリティの技術は、各パケットに必要なCPUサイクル数という点で、より低い計算要求しか課しません。
さらに、パケットごとの処理が非常に一貫しているため、性能予測が簡素化されます。
今日の状況では、セキュリティ機能（FWaaSなど）は、クラウド/PoP（Points of Presence）にこれらの機能を展開するサービスプロバイダによってサービスとして提供されます。
複数のテナントに対応するため、基盤となるセキュリティ技術の実装では、VRF（Virtual Routing and Forwarding）テナント・モデルを活用しています。
このモデルでは、複数のテナントからのトラフィックが同じセキュリティ・デバイスまたはコンテナ／プロセスを通過するため、テナント間のIPアドレスの重複に関する課題に効果的に対処できます。
テナント・トラフィックはトンネル・インターフェースまたはその他のメカニズムによって識別され、テナント固有のセキュリティ・ポリシーなど、各テナントに合わせた特定の設定が適宜適用されます。
ノイジー・ネイバー」の潜在的な問題を軽減するため、イングレスではテナントごとにパケット・レート制限が適用されます。
この戦略により、個々のテナントのセキュリティ・パフォーマンスが、他の潜在的に問題のあるテナントの活動によって影響を受けないことが保証されます。
パケットごとの一貫した処理を考えると、レート制限はすべてのテナントに対して公平な処理を保証する上で効果的であることがわかります。
組織にとってのもう1つの重大な懸念は、他のテナントからの悪意のあるパケットによって共有プロセスまたはコンテナ内の脆弱性が悪用された結果、機密データが漏えいする可能性です。
セキュリティ・サービス・プロバイダーがしばしば提示する論拠の1つは、パケット単位での処理は単純であるため、脆弱性とそれに対応する悪用の可能性が低くなるというものです。
確かに、パケットレベルのセキュリティ技術の方が単純であることは事実であり、この議論にはある程度の妥当性があります。
先に述べた2つの課題、すなわち「ノイズの多い隣人」問題と「共有リソースの脆弱性」は、共有プロセスを利用するパケットレベルのセキュリティ技術にとっては重要な問題ではないかもしれません。
しかし、SASE（セキュア・アクセス・サービス・エッジ）やSSE（セキュア・サービス・エッジ）のセキュリティ技術では、これらの課題はより顕著で実質的なものになると考えています。

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

SASE/SSE（Secure Access Service Edge/Secure Service Edge）セキュリティ技術は、従来のパケットレベルのセキュリティを超越し、包括的な一連の機能を提供します：

  • 包括的なセキュリティ機能SASE/SSEは、 IDPS（侵入検知・防御）、DNSセキュリティ、SWG（セキュア・ウェブ・ゲートウェイ）、ZTNA（ゼロ・トラスト・ネットワーク・アクセス）、IP/URL/ドメイン/ファイルのレピュテーション・ファイアウォールを備えたCASB（クラウド・アクセス・セキュリティ・ブローカー）、URI、リクエスト・ヘッダ、レスポンス・ヘッダ、アンチマルウェア、DLP（データ漏洩防止）などの幅広いセキュリティ機能を備えています。 SASE/SSEのZero Trust Networking (ZTN)は、アイデンティティとデバイスのコンテキストを考慮しながら、アプリケーションリソースをきめ細かく制御し、ユーザ認証と承認によってのみアクセスを保証する、基本的なものです。
  • ディープコンテンツ検査：SASE/SSEセキュリティの核心は、ディープコンテンツインスペクションにあります。
    クライアント接続を管理し、サーバー接続を開始し、ストリームを解読し、トラフィックから関連データを抽出し、セキュリティ機能を実行し、悪意のあるコンテンツの送信を防止するプロキシを利用します。

それでは、SASE/SSE とパケットレベルのセキュリティ技術の実行上の違いを掘り下げてみましょう：

  • パケット単位からセッションベースの処理への移行： SASE/SSEのコンテキストでは、セキュリティの実行はもはやパケット単位ではなく、トラフィックセッションストリーム単位で行われます。
    パケット単位の技術とは異なり、SASE/SSE のセキュリティ処理で使用される計算サイクル数は、以下の理由により、テナントによってばらつきがあります：

    • トラフィック・ストリームに適用されるセキュリティ機能は、テナントによって異なります。
    • 同様のセキュリティ機能が適用されている場合でも、交換されるデータの性質によって、より集中的な処理が必要になることがあります。
      たとえば、マルウェア対策やDLPに関連するシナリオを考えてみましょう。これらのシナリオでは、さまざまな種類のファイルからテキストを抽出したり、転送されたファイルを解凍したり、ファイルコレクションの文字列を解除したりする必要があります。
      テナントによっては、圧縮されたファイルを転送するために大規模な処理が発生し、他のテナントのスループットや待ち時間に影響を与える場合があります。
      特定のテナントから発生するノイズは、感染によるものであれ、重要なイベント時にビジネス・トラフィックが集中することによるものであれ、他のテナントのトラフィック・パフォーマンスに影響を与える可能性があります。
  • 複雑なセキュリティ処理： SASE/SSEのセキュリティ処理は本質的に複雑で、多くの場合、サードパーティやオープンソースのコンポーネントを含む様々なライブラリが組み込まれています。
    これらは、OIDC（OpenID Connect）クライアント、Kerberosクライアント、認証のためのSAMLv2クライアント、強制のための複雑なポリシーエンジン、脅威インテリジェンスプロバイダのSDK、データ抽出、JSON/XMLデコード、base64デコード、データ解凍エンジン、Tikaのようなオープンソースプロジェクトを介したテキスト抽出などの機能を包含しています。
    このような複雑さは、潜在的な悪用のための攻撃表面を増加させます。
    SASE/SSEプロバイダーは、脆弱性に迅速に対処することを優先しますが、脆弱性が悪用されてから解決されるまでに時間差が生じる可能性があります。
    複数のテナントに対して共有プロセスが採用されている場合、攻撃者は潜在的に脆弱性を悪用し、目的のテナントだけでなく、その実行コンテキストを共有するすべてのテナントのデータから機密情報にアクセスする可能性があります。
  • 独自のセキュリティ機能の導入：SASE/SSEサービスは、すぐに包括的なセキュリティ機能を提供しますが、LuaモジュールやWebAssembly（WASM）モジュールを使用して、独自のセキュリティ機能を導入する柔軟性も提供します。
    しかし、このような場合、共有プロセスは、注意深く管理されなければ、他のテナントからのデータ流出につながる可能性があるため、重大な課題となります。
    共有プロセスが採用されている場合、この懸念への対処はより複雑になり、これらの制御を回避する潜在的な方法が常に存在する可能性があります。

要約すると、SASE/SSE セキュリティは、パケットレベルのセキュリティを超える包括的なセキュリティのフレームワークを提供しますが、可変的な計算機の使用、複雑な処理、共有リソースに関連する複雑さと課題をもたらします。
このような環境で強固なセキュリティを維持することは、パフォーマンス上の問題やデータ漏洩、プライバシー侵害から保護するために非常に重要です。

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

組織は、SASE/SSEプロバイダが複数のテナントに対して共有プロセスを採用する根拠を間違いなく評価しています。
このアプローチは、テナント間でコンピュートリソースを効率的に利用し、持続可能性と費用対効果に貢献します。
サービス・プロバイダーは、このようなコスト削減を顧客に還元することができます。
しかし、業界によっては、マルチテナンシーアーキテクチャや共有プロセスに伴うセキュリティリスクを受け入れたがらないところもあります。
組織によっては、よりリスク回避的なアプローチが将来必要になることも予想されます。
そのような場合、組織は、共有プロセスと専用プロセス/コンテナの両方のオプションを提供し、柔軟性を提供するSASE/SSEサービスを求めるべきです。
トラフィック処理専用のプロセス/コンテナを持つ専用の実行コンテキストは、前のセクションで概説した課題に効果的に対処することができます：

  • パフォーマンスの分離：決定論的なパフォーマンスの実現が、破壊的な “ノイジー・テナント “を気にすることなく可能になります。
    専用の実行コンテキストがあれば、個々のテナントに専用の計算リソースを割り当てるのは比較的簡単です。
    また、ノイジーな隣接テナントがコンピュートノードのリソースを使い切るのを防ぐために、リソースキャップを設定することもできます。
  • セキュリティの分離：専用の実行コンテキストは、あるテナントのSASE/SSEサービスを悪用しようとする悪意や内部の脅威が、専用の実行コンテキストを選択したテナントのデータ漏洩につながらないことを保証します。
  • 安心の「セキュリティ機能持ち込み」：専用の実行コンテキストは、Luaスクリプト/WASMモジュールが専用プロセス内で排他的に実行されることを保証します。
    その結果、サービスプロバイダが専用プロセスに対してのみこの機能を有効にすれば、処理またはデータ流出の課題は、カスタムのセキュリティ機能を持ち込むテナントだけに限定されるため、他のテナントにとっても安心です。

将来のニーズの予測コンフィデンシャル・コンピューティングの重要性

今後の展望として、機密コンピューティングの重要性が高まっていることを認識するようになった組織があります。
このような意識は、TLS 検査や、SASE/SSE サービス内の秘密やパスワードを含む多くの機密データの管理に特に関連しています。
サービスプロバイダのスタッフを含め、サーバインフラにアクセスできる人員が、プロセスやコンテナのメモリに不正にアクセスする可能性について、繰り返し懸念されています。
さらに、サーバーオペレーティングシステムを悪用する攻撃者も、これらのコンテナやプロセスのメモリに侵入する可能性があります。
この懸念は、法的な定義や実装のレベルが異なるさまざまな国にまたがる複数のPOP（Point of Presence）でサービスが利用可能な状況で、より顕著になります。
Intel Trust Domain Extensions (TDx) を搭載したような最新のプロセッサは、信頼された実行のための高度な機能を提供します。
これらのテクノロジは、TDxハードウェアによってメモリが安全に暗号化されたままであるため、インフラストラクチャ管理者や高い権限を持つ攻撃者であっても、メモリの内容を解読できないことを保証する上で重要な役割を果たします。
専用の実行コンテキストを提供するSASE/SSEプロバイダは、他のプロバイダと比較して、この重要な機密保持機能を提供するのに有利な立場にあります。
したがって、組織は、共有プロセスと専用実行コンテキストの両方の柔軟性を提供するプロバイダを検討することを強くお勧めします。
この柔軟性は、将来的なリスク軽減戦略に役立ち、進化するランドスケープにおいて最高レベルのデータセキュリティを保証します。

  • CTOインサイトブログ

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