進化の SASE アーキテクチャ

一般にネットワーク セキュリティの文脈で複数のアーキテクチャ原則について聞いたことがあるかもしれません。 SASE 特に。 業界で使用されているいくつかのソフトウェア アーキテクチャ原則 SASE コンテキストは次のとおりです。

• シングルパスアーキテクチャ
• XNUMX プロキシ アーキテクチャ
• 実行から完了までのアーキテクチャ
• スケールアウト アーキテクチャ
• シングルパス並列処理アーキテクチャ
• 独自のセキュリティ機能の導入 アーキテクチャ
• Cloud-ネイティブのアーキテクチャ
• 分離アーキテクチャ
• APIファーストのアーキテクチャ
• スライシング (E2E セグメンテーション) アーキテクチャ

上記のアーキテクチャ原則の多くは新しいものではありません。 シングルパス、ワンプロキシ、シングルパス並列処理、および実行から完了までのアーキテクチャ原則は、2000 年代初頭の UTM (統合脅威管理) の時代から人気がありましたが、以前は別の名前で知られていました。

これらのアーキテクチャ原則の主な目的は、次のことを達成することです。

• リソースを効率的に使用することでスループットが向上します。
• エンドツーエンドのレイテンシーの短縮
• ジッターの低減
• セキュリティ サービスに対する DDoS 攻撃の場合でも、より高い弾力性 (スケールアウト) と復元力を実現
• 新しいセキュリティ機能の導入を迅速化（Agility）
• 非効率を生じさせずに複数ベンダーのセキュリティ機能を統合（最良の技術の統合）
• 採用可能性 (どこでも実行可能)
• 一枚ガラス

進化

ネットワーク セキュリティ業界の優れた点の XNUMX つは、動的であることです。 新世代の製品ごとに、新しいソフトウェアと展開アーキテクチャの原則が採用されています。 また、攻撃者の巧妙化に対する保護も維持します。

とはいえ、ネットワーク セキュリティ市場は伝統的に細分化されています。 複数のセキュリティ ベンダーがさまざまなセキュリティ機能を提供しています。 これはイノベーションの観点からは良いことであり、奨励される必要があり、継続する必要があります。 XNUMX つのベンダーがすべてのセキュリティ機能に優れているわけではないことに注意してください。

さらに見てわかるように、各ベンダーがセキュリティ機能の完全なスタックを提供すると、非常に非効率になり、その結果、莫大なコストが発生することになります。 さらに、遅延が増加する可能性があり、一部のアプリケーションにとっては課題となる可能性があります。 したがって、新しいアーキテクチャの原則とベスト プラクティスが適用可能になります。 ソフトウェア アーキテクチャは、非効率性を考慮しながら、最高のサイバーセキュリティを実現するために複数のベンダー テクノロジーの統合を可能にする方法でなければなりません。

収束前

図 1 と図 2 は、以前のネットワーク セキュリティの XNUMX つの代表的な例です。 SASE。 図 1 は安全なインターネット アクセスを示し、図 2 は安全なプライベート アクセスの例を示します。 これらの図のセキュリティ機能の順序は任意であり、実行順序は通常、展開に固有であることに注意してください。

従来、安全なインターネット アクセスは、図 1 に示すように複数のセキュリティ ソリューションを使用して実現されていました。erprise はこれらのセキュリティ機能を購入し、サービス チェーンに組み込みます。 多くのセキュリティ機能は接続のプロキシを必要とするため、このチェーンは業界ではプロキシ チェーンとも呼ばれます。

個別のセキュリティ ソリューションはそれぞれ独立しており、複数のベンダーから提供されているため、共通の機能がこれらのソリューション全体で繰り返されます。 共通の機能には、入力時のトラフィック ポリシング、出力時のトラフィック シェーピング、関連するトラフィックのみがプロキシに送信されるようにするトラフィック フィルタリング、 TCP クライアント接続の終了、新規 TCP 目的地に向かう接続、 SSLTLS 復号化と TLS 暗号化、プロキシ認証 (Kerberos、NTLM、OIDC)、HTTP 1.1/2.0 デコードを含む /TLS インターセプト (それ自体、宛先証明書をエミュレートするオンデマンド証明書生成が必要です)。 ある推定では、各ボックス/仮想アプライアンスのこの共通機能は、セキュリティ ソリューション全体の CPU リソースの 50% を占めます。

セキュアなアプリケーション アクセスも、図 2 に示すように、個別のセキュリティ ソリューションを連鎖させることによって同様の方法で実現されます。ここでも、共通の機能は複数のセキュリティ ソリューション間で同じです。 これは、セキュア インターネット アクセスで使用されるセキュリティ ソリューションの一般的な機能にほぼ似ています。 いくつかの違いとしては、 SSL傍受の代わりに /TLS 終了し、プロキシ認証の代わりに従来の方法でユーザー認証を行います。

セキュリティ ソリューションの一般的な機能の平均オーバーヘッドは、ソリューション全体の 50% に達する可能性があります。 このアーキテクチャによる遅延は、関数の連鎖により数ミリ秒増加する可能性があります。

耳鼻咽喉科が直面するもう一つの大きな課題erp物理アプライアンスと仮想アプライアンスが増加し、スケーリングが進んでいます。 当初、スケーリングは、より大きなアプライアンスを使用するか、より多くの CPU およびメモリ リソースを VM ベースのセキュリティ ソリューションに割り当てることで対応されていました。 これをスケールアップといいます。 トラフィック量が一定であれば、Ent にとっては合理的です。erpより大きな物理/仮想アプライアンスにお金を費やすようになりました。 ただし、トラフィックがバーストしている場合、Enterpライズ派はお金が無駄になるのを見るのを好みません。 トラフィックが増えるのは XNUMX 年のうち数日だけである場合を考えてみましょう。 なぜエントはerp上昇志向の人々は、XNUMX 年を通してこれらの隆起にお金を費やすことを好みますか? それが次の進化につながり、セキュリティ ベンダーは次のような方法でスケールアウト アーキテクチャをサポートし始めました。 cloud-配信サービス。 これは次のような理由です IaaS セクションに Cloud アプリケーションの世界。 スケールアウト アーキテクチャでは、より多くのセキュリティ ソリューションのインスタンスが、トラフィック量の増加や DDoS 攻撃の検出時に自動的に起動され、需要が低下するとインスタンスが停止されます。 写真 3 は、そのスケールアウト アーキテクチャを示しています。

スケールアウト機能が必要であることは間違いありません。 ただし、各セキュリティ ソリューションにロード バランサーが必要です。 このロード バランサーは、セキュリティ ソリューションの複数のインスタンス間でセッションの負荷を分散するために必要です。 複数のロード バランサーのトラバーサルにはより多くのリソースが必要となり、トラフィック セッションのエンドツーエンドの遅延が増加します。

ネットワーク セキュリティ アーキテクチャの次の進化により、次の課題に対処します

• より多くのコンピューティング リソースが必要
• 待ち時間が長くなる

• XNUMX つのプロキシ アーキテクチャ
• シングルパスアーキテクチャ

シングルパスおよび XNUMX プロキシ アーキテクチャ (コンバージド アーキテクチャ)

以下の図 4 に示すように、すべてのセキュリティ機能は、プロキシおよびその他の一般的な機能とともにバンドルされており、一度だけ利用されます。 すべてのセキュリティ関数は、実行から完了までの方式で一度に XNUMX つずつ呼び出されます。 結果として、このアーキテクチャはコンピューティング リソースを効率的に消費します。 すべての関数は同じユーザー空間コンテキストで呼び出されるため、メモリのコピーが回避されます。 また、XNUMX つのユーザー空間プロセス アーキテクチャにより、オペレーティング システムのコンテキストの切り替えが大幅に減少します。 単一のプロキシ インスタンスは、各スレッドがセッションのサブセットを処理するマルチスレッド経由で複数のセッションを同時に処理できるため、マルチコア CPU を効果的に活用できます。 また、マルチスレッド機能により、特定のトラフィック セッションに対して一部のセキュリティ機能を直列ではなく並列で実行できるため、遅延が改善されます。 このアーキテクチャは「シングルパス並列処理」と呼ばれます。

予期せぬ負荷に対処し、DDoS シナリオに対処するために、セッション負荷分散の途中で XNUMX つのロード バランサー インスタンスを使用する自動スケールアウト アーキテクチャが採用されています。

このアーキテクチャでは、プロキシはインターフェイス API を公開します。 すべてのセキュリティ機能はこの API に接続されます。 プロキシは、トラフィック セッションの処理中に、関連するフックされたセキュリティ機能を呼び出します。 すべてのセキュリティ機能が実装されているわけではありません。 SASE ソリューション開発者。 SASE ソリューション開発者は、テクノロジー サプライヤーのエンジンとフィードをプロキシと統合することで、テクノロジー サプライヤーと連携します。 そうすれば、お客様は、 SASE プロバイダーは両方の長所を活用 – 高パフォーマンス SASE 最高のセキュリティ実装を備えています。

ただし、一部のテクノロジー サプライヤーは、プロキシの一部としてセキュリティ機能を開発するための SDK 形式でエンジンを提供しない場合があります。 として持っているのかもしれない。 cloud サービス。 DLP は、多くのテクノロジー プロバイダーがこれを導入している一例です。 cloud サービス。 また、場合によっては、 SASE ソリューションプロバイダーは、 wanメモリ制約、ライセンスの非互換性の回避、ユーザー空間の脆弱化の回避などの理由により、プロキシの同じユーザー空間プロセス コンテキストに一部のセキュリティ機能を統合します。

統合アーキテクチャと独自のセキュリティ機能の導入

次の進化は、 SASE アーキテクチャを以下に示します。 以下の図 6 には XNUMX つの重要な点が示されています。

ICAP (Internet Content Adaptation Protocol) によるセキュリティ サービスのサポート: 耳鼻咽喉科erprise は、他のセキュリティ ベンダーのセキュリティ サービスに慣れている、または使用したいと考えている可能性があります。 ICAP IETF の仕様では、プロキシがセキュリティ サービスを含む外部コンテンツ アダプテーション サービスと通信する方法を指定しています。 外部セキュリティサービスを許可することで、 SASE ソリューションプロバイダーが Ent を有効にしますerpセキュリティ サービスの選択を選択するようになります。

独自のセキュリティ機能を導入します。 IBM のセキュリティー・レポート「2022 年のデータ侵害のコスト・レポート」によると、組織はデータ侵害を検出して封じ込めるまでに平均 277 日かかっています。 けれど SASE は非常に優れたポリシー構成を提供しますが、一部のデータ侵害封じ込めにはプログラムによるルールが必要になる可能性があります。 データ侵害を分析する組織は、これらのプログラムを開発するのに有利な立場にあります。 応じて SASE プロバイダーやセキュリティ サービスと同様に、製品リリースは完全なソフトウェア開発ライフサイクルを経る必要があるため、ベンダーは時間がかかることがあります。 こうした遅延を回避するために、新たに SASE アーキテクチャは Ent のための手段を提供しますerpライズのセキュリティチームは独自にプログラムルールを開発し、展開します。 これらによりプロキシが不安定になることはありませんので、 SASE アーキテクチャは、プログラムによるルールを WASM モジュールとして作成できるようにする WASM ランタイムを提供します。 WASM ランタイムはサンドボックスとして機能するため、WASM モジュールに問題があっても、ホスティング ユーザー スペースやその他のセキュリティ機能プラグインがクラッシュしたり停止したりすることはありません。

統合プロキシ: セキュア インターネット アクセスとセキュア アプリケーション アクセスの両方を XNUMX つの統合プロキシで行うことで、メモリ要件を削減できます。 マルウェア対策や DLP などの一部のセキュリティ機能のエンジンとフィードはメモリを大量に消費します。 各 Ent に対して XNUMX つの異なるプロキシ インスタンスを起動するerpしたがって、サイトが上昇すると費用がかかる可能性があります。 さらに、XNUMX つのモード (順方向、逆方向、透過的) をすべてサポートする XNUMX つのプロキシを持つことは、開発者の生産性の観点からも良い開発方法です。

新しい世代のアーキテクチャでは、追加のアーキテクチャ原則が採用されています。 SASE 建築は

Cloud ネイティブ： ユニバーサルで議論されているように、 SASE これの ブログ投稿, SASE オンプレミスではサービスが必要ですが、 Cloudとエッジ。 そこで、新世代は、 SASE アーキテクチャは「」に従っていますCloud ネイティブが作る原則 SASE どこでも働けます。 けれど Cloud ネイティブと Kubernetes は同義語ではなく、多くの場合、次のようなソリューションになります。 cloud ネイティブは Kubernetes ベースです。 ソリューションを Kubernetes 上で動作させることを選択した理由は、 cloud/edge プロバイダーは Kubernetes-as-a-service を提供します。さらに重要なのは、API インターフェイスがそのままの状態で維持されることです。 cloud/エッジプロバイダー。 Kubernetes の API インターフェイスは一貫しているため、 cloud/edge プロバイダー、K8s ベース SASE ソリューションはシームレスに機能しますssl横方向にy cloud/エッジプロバイダー。

分離アーキテクチャ: 電流プローブ SASE アーキテクチャでは、効率性の理由から、複数のテナント セッションが共有ユーザー スペース プロセスを介して実行できるようになります。 テナント間で IP アドレスが重複している場合でも、ある程度の分離レベルが維持されるように、賢明な方法が使用されています。 複数のテナントの共有ユーザー空間プロセスは、パフォーマンスとセキュリティの分離の観点からは良いことではありません。 共有リソースでは、テナントに対する DDOS 攻撃などの不正行為により、他のテナントのトラフィックにパフォーマンスの問題が発生する可能性があります。 また、共有ユーザー空間プロセスを悪用すると、すべてのテナントのすべてのシークレット/パスワード/キーが公開される可能性があります。 上記のことを念頭に置いて、新しい世代 SASE アーキテクチャでは、専用のユーザー空間プロセスまたは専用のコンテナーを介した専用のプロキシ インスタンスがますます増えています。

API ファーストのアーキテクチャ: 電流プローブ SASE ソリューションは、構成および監視するための CLI とポータルを提供します。 いくつかの SASE ソリューションは CLI/ポータルとバックエンド管理システムの間で API を使用しますが、それらはアドバタイズされません。 場合によっては、API がクリーンではなかった可能性があります。 新しい SASE ソリューションは API ファースト アーキテクチャを採用しており、API は CLI とポータルの実装だけでなく、サードパーティが外部プログラム エンティティを開発するためにも定義されています。 API により、単純なスクリプト開発から複雑なワークフロー開発まで、terraform などを介して SecOps-as-code が可能になります。

RESTful API、OpenAPI ベースのドキュメントを含む JSON ペイロードを使用するのが一般的ですが、セキュリティやネットワーキング オブジェクトとポリシーを構成するために Kubernetes カスタム リソースを公開するものもあります。

API First アーキテクチャでは、実際のバックエンド ロジックを RBAC (Role Based Access Control) の実装から分離することも期待されています。 業界の経験では、RBAC とビジネス ロジックの両方を組み合わせると、かなりの数の脆弱性が存在します。 その結果、業界は RBAC 機能を外部エンティティに分離し、アプリケーションはビジネス ロジックに重点を置く方向に進んでいます。 同じロジックが適用されています SASE 管理システム。 SASE 管理システムは SAE ポリシー/オブジェクトと可観測性に重点を置き、RBAC 機能をイングレス プロキシや API ゲートウェイなどの外部エンティティに任せます。 Ingress プロキシは、すべての認証と認可、および API ルーティングを処理します。 良い点は、XNUMX つのイングレス プロキシが複数のアプリケーションのフロントエンドにできることです。 このため、管理者ユーザーは、多くのアプリケーションにわたる XNUMX つの RBAC エンティティに慣れるだけで済みます。 ビジネス ロジックを RBAC から分離するために、API ファースト アーキテクチャ ソリューションはいくつかのガイドラインに従うことが期待されます。 たとえば、多くのイングレス プロキシと API ゲートウェイは、URI が RBAC のリソースを指すために使用されることを想定しています。 ワークフローベースの自動化の場合、管理システムが構成にタグを付け、古いタグに復元してサガ パターンを有効にできることが期待されます。 API ファーストのアーキテクチャは、業界のベスト プラクティスに従うことが期待されます。

まとめ

ネットワーク セキュリティ アーキテクチャは、物理/モノリシック エンティティから仮想アプライアンスやコンテナへと進化しています。 多くの cloud- アプリケーションの世界で普及したネイティブ原則が、 SASE を得るソリューション cloudスケールアウト/イン、俊敏性、マルチ性などの利点cloud / エッジ対応で、複数のテナント間でリソースを効率的に使用できます。 新しいアーキテクチャの原則とその方法については、このスペースに注目してください。 Aryaka 活用しています cloud- のようなテクノロジー。

• CTO の洞察ブログ

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