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

  • シングルパス・アーキテクチャ
  • ワンプロキシアーキテクチャ
  • ラン・トゥ・コンプリート・アーキテクチャ
  • スケールアウトアーキテクチャ
  • シングルパス並列処理 アーキテクチャ
  • セキュリティ機能の持ち込み アーキテクチャ
  • クラウド・ネイティブ・アーキテクチャ
  • アイソレーション・アーキテクチャ
  • APIファースト・アーキテクチャ
  • スライシング（E2Eセグメンテーション）アーキテクチャ

上記の建築原則の多くは新しいものではありません。 シングルパス、ワンプロキシ、シングルパス並列処理、ラン・トゥ・コンプリートの各アーキテクチャ原則は、以前は別の名前で知られていましたが、2000年代初頭のUTM（統合脅威管理）時代から普及しています。 これらのアーキテクチャ原則の主な目的は、以下を達成することです。

  • リソースの効率的な使用によるスループットの向上
  • エンド・ツー・エンドの待ち時間の短縮
  • 低ジッター
  • より高い弾力性（スケールアウト）と、セキュリティサービスに対するDDoS攻撃にも耐える回復力
  • 新しいセキュリティ機能の迅速な導入（アジリティ）
  • 非効率をもたらすことなく、複数のベンダーのセキュリティ機能を統合（ベストテクノロジーの統合）
  • 採用性（どこでも走れる）
  • 単板ガラス

進化

ネットワーク・セキュリティ業界の素晴らしい点は、ダイナミックであるということです。 新世代の製品ごとに、より新しいソフトウェアとデプロイメント・アーキテクチャの原則を採用しています。 また、攻撃者の高度化に対する防御も維持されます。 とはいえ、ネットワーク・セキュリティ市場は伝統的に細分化されています。 複数のセキュリティ・ベンダーがさまざまなセキュリティ機能を提供しています。 イノベーションの観点からは良いことであり、奨励されるべきですし、今後も続けていかなければなりません。 あるベンダーがすべてのセキュリティ機能を得意としているとは限らないことに注意してください。 さらにお分かりのように、各ベンダーがセキュリティ機能の完全なスタックを提供する場合、非効率性が非常に高くなり、その結果、膨大なコストが発生します。 さらに、アプリケーションによっては、より多くの待ち時間が発生する可能性があります。 したがって、新しいアーキテクチャの原則やベストプラクティスを適用することができます。 ソフトウェア・アーキテクチャは、非効率に配慮しつつ、最高のサイバーセキュリティのために複数のベンダーの技術を統合できるようなものでなければなりません。

コンバージェンス前

図1と図2は、SASE以前の代表的なネットワークセキュリティの例です。 図1はセキュア・インターネット・アクセスを、図2はセキュア・プライベート・アクセスの例を示しています。 これらの写真に写っているセキュリティ関数の順番は任意であり、実行の順番は通常、配置によって異なることに注意してください。 セキュアなインターネット・アクセスは、従来、図1に示すような複数のセキュリティ・ソリューションを用いて実現されてきました。
1.これらのセキュリティ機能を購入し、サービスチェーンに組み込むのは企業です。 多くのセキュリティ機能がコネクションのプロキシを必要とするため、このチェーニングは業界ではプロキシ・チェーニングとも呼ばれています。 個別のセキュリティ・ソリューションはそれぞれ独立したものであり、複数のベンダーから提供されているため、共通の機能はこれらのソリューション間で繰り返されます。 一般的な機能には、イングレス時のトラフィック・ポリシング、イグレス時のトラフィック・シェーピング、関連するトラフィックのみがプロキシに送られるようにするためのトラフィック・フィルタリング、クライアント接続のTCP終了、宛先への新しいTCP接続、TLS復号化およびTLS暗号化を含むSSL/TLS傍受（これ自体、宛先証明書をエミュレートするオンデマンド証明書生成が必要）、プロキシ認証（Kerberos、NTLM、OIDC）、HTTP 1.1/2.0デコードなどがあります。 各ボックス/仮想アプライアンスに共通するこの機能は、セキュリティ・ソリューション全体のCPUリソースの50%を占めるという試算もあります。 セキュアなアプリケーション・アクセスも、図 2 に示すように、個別のセキュリティ・ソリューショ ンを連鎖させることによって、同様の方法で実現されます。
2.ここでも、複数のセキュリティ・ソリューションに共通する機能は同じです。 セキュア・インターネット・アクセスで使用されているセキュリティ・ソリューションの共通機能とほぼ同じです。 いくつかの違いとしては、SSL/TLSが傍受の代わりに終了することや、プロキシ認証の代わりに従来の方法によるユーザー認証があることなどが挙げられます。 セキュリティ・ソリューションの一般的な機能の平均的なオーバーヘッドは、ソリューション全体の50%にもなる可能性があります。 このアーキテクチャによる待ち時間は、関数の連鎖によって数ミリ秒長くなることがあります。 物理アプライアンスと仮想アプライアンスで企業が直面するもう一つの大きな課題は、スケーリングです。 もともとは、より大きなアプライアンスを使用するか、VMベースのセキュリティ・ソリューションにより多くのCPUとメモリ・リソースを割り当てることで、スケーリングに対応していました。 これをスケールアップと呼びます。 トラフィックが一定量であれば、企業がより大きな物理/仮想アプライアンスにお金をかけることは理にかなっています。 しかし、トラフィックが爆発的に増えれば、企業は無駄なお金を使うことを嫌います。 1年のうち数日だけトラフィックが多い場合を考えてみてください。 なぜ企業は、1年を通してこのようなバンプにお金を使いたがるのでしょうか？ そこで、セキュリティ・ベンダーがクラウド・サービスによるスケールアウト・アーキテクチャをサポートするようになりました。 これは、クラウド・アプリケーションの世界におけるIaaSの理由のようなものです。 スケールアウト・アーキテクチャでは、トラフィックの増加やDDoS攻撃を検知すると、より多くのセキュリティ・ソリューションのインスタンスが自動的に立ち上げられ、需要が低下すると、それらを停止します。 写真3は、そのスケールアウト・アーキテクチャです。 スケールアウト機能が求められていることは間違いありません。 しかし、各セキュリティ・ソリューションにロードバランサーが必要です。 このロードバランサーは、セキュリティソリューションの複数のインスタンスにまたがるセッションのロードバランスをとるために必要です。 複数のロードバランサーのトラバーサルはより多くのリソースを必要とし、トラフィックセッションのエンドツーエンドの待ち時間を増やします。 ネットワーク・セキュリティ・アーキテクチャの次の進化は、次のような課題に対応します。

  • より多くの計算リソースが必要
  • より高い待ち時間

と

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

シングルパスおよびワンプロキシ・アーキテクチャ（コンバージド・アーキテクチャ）

下の図4に示すように、すべてのセキュリティ機能は、プロキシや他の一般的な機能が一度だけ登場するように、一緒にバンドルされています。 すべてのセキュリティ関数は、実行完了方式で一度に一つずつ呼び出されます。 その結果、このアーキテクチャはコンピュートリソースを効率的に消費します。 すべての関数は同じユーザースペースコンテキストで呼び出されるため、メモリコピーは回避されます。 また、1つのユーザー空間プロセスアーキテクチャは、オペレーティングシステムのコンテキストスイッチを劇的に削減します。 一つのプロキシインスタンスはマルチスレッディングによって一度に複数のセッションを処理することができ、各スレッドはセッションのサブセットを処理し、それによってマルチコアCPUを効果的に活用します。 また、マルチスレッディング機能により、特定のトラフィック・セッションに対して、一部のセキュリティ機能を直列ではなく並列に実行することができ、それによって待ち時間を改善することができます。 このアーキテクチャは「シングルパス並列処理」と呼ばれています。予期せぬ負荷に対処し、DDoSシナリオに対応するため、セッションの負荷分散に1つのロードバランサーインスタンスが邪魔になるオートスケールアウトアーキテクチャが採用されています。 このアーキテクチャでは、プロキシはインターフェイスAPIを公開します。 すべてのセキュリティ関数はこのAPIにフックします。 プロキシは、トラフィック・セッション処理中に関連するフック・セキュリティ機能を呼び出します。 すべてのセキュリティ機能は、SASEのソリューション開発者によって実装されるとは限りません。 SASEのソリューション開発者は、テクノロジーサプライヤのエンジンとフィードをプロキシに統合することで、テクノロジーサプライヤと連携しています。 そうすることで、SASEプロバイダーの顧客は、高性能のSASEと最高のセキュリティの実装という、両方の利点を得ることができます。 とはいえ、テクノロジー・サプライヤによっては、プロキシの一部としてセキュリティ機能を開発するためのSDK形式でEngineを提供しない場合もあります。 クラウドサービスとして提供しているのかもしれません。 DLPはその一例で、多くのテクノロジープロバイダーがクラウドサービスとして提供しています。 また、場合によっては、SASE ソリューションプロバイダは、メモリの制約、ライセンスの非互換性を避けるため、ユーザ空間を脆弱にすることを避けるため、などの理由で、プロキシの同じユーザ空間のプロセスコンテキストに、いくつかのセキュリティ機能を統合したくないかもしれません。

ユニファイド・アーキテクチャと独自のセキュリティ機能

SASEアーキテクチャの次の進化を以下に示します。 以下の図6に示す3つの重要なポイントがあります。ICAP（Internet Content Adaptation Protocol）を介したセキュリティ・サービスのサポート：企業は、他のセキュリティ・ベンダーのセキュリティ・サービスを使用している、または使用したい場合があります。IETFのICAP仕様は、プロキシがセキュリティサービスを含む外部のコンテンツ適応サービスとどのように通信できるかを規定しています。
外部のセキュリティサービスを許可することにより、SASEソリューションプロバイダーは、企業がセキュリティサービスを選択することができます。独自のセキュリティ機能の導入IBMのセキュリティレポート「Cost of a Data Breach Report 2022」によると、企業はデータ漏洩を検知し、封じ込めるまでに平均277日かかっています。 SASEは非常に優れたポリシー設定を提供しますが、データ漏洩の抑制にはプログラム上のルールが必要な場合もあります。 データ侵害を分析する組織は、これらのプログラムを開発するのに適した立場にあります。 SASEプロバイダーやセキュリティサービスによっては、製品のリリースに完全なソフトウェア開発ライフサイクルを経る必要があるため、ベンダーが時間を要することがあります。 このような遅延を回避するために、新しいSASEアーキテクチャは、企業のセキュリティ・チームが自らプログラム・ルールを開発し、展開する方法を提供します。 これらはプロキシに不安定性を与えてはならないので、SASEアーキテクチャはWASMランタイムを提供し、プログラムルールをWASMモジュールとして作成できるようにしています。 WASMランタイムはサンドボックスとして動作するので、WASMモジュールに問題があっても、ユーザースペースや他のセキュリティ機能プラグインをホストしているWASMがクラッシュしたり、死んだりすることはありません。統一プロキシ：セキュアインターネットアクセスとセキュアアプリケーションアクセスの両方に1つの統一プロキシを使うことで、メモリ要件を減らすことができます。 マルウェア対策やDLPなど、一部のセキュリティ機能のエンジンやフィードはメモリを消費します。 そのため、Enterpriseサイトごとに2つの異なるプロキシインスタンスを立ち上げると、コストがかかります。 さらに、1つのプロキシで3つのモード（順方向、逆方向、透過）すべてをサポートすることは、開発者の生産性の観点からも良い開発手法です。

新世代のSASEアーキテクチャで踏襲されているアーキテクチャの原則は次のとおりです。

クラウドネイティブ：このブログ記事のユニバーサルSASEで説明したように、SASEサービスはオンプレ、クラウド、エッジで必要です。 したがって、新世代のSASEアーキテクチャは、SASEをどこでも使えるようにするために、「クラウドネイティブ」の原則に従っています。 クラウドネイティブとKubernetesは同義語ではありませんが、多くの場合、クラウドネイティブと呼ばれるソリューションはKubernetesベースです。 ソリューションをKubernetes上で動作させることを選択した理由は、すべてのクラウド/エッジプロバイダーがKubernetes-as-a-serviceを提供しており、さらに重要なことは、クラウド/エッジプロバイダーによってAPIインターフェースがそのまま維持されていることです。 クラウド/エッジプロバイダー間でKubernetesのAPIインターフェースが一貫しているため、K8sベースのSASEソリューションはクラウド/エッジプロバイダー間でシームレスに動作します。分離アーキテクチャ：現在のSASEアーキテクチャでは、効率性の観点から、複数のテナントセッションが共有ユーザースペースプロセスを経由して行われます。 テナント間でIPアドレスが重複していても、ある程度の分離が保たれるように巧妙な方法が使われています。 複数のテナントでユーザー空間のプロセスを共有することは、パフォーマンスとセキュリティの分離の観点から良いことではありません。 共有リソースでは、あるテナントに対するDDOS攻撃などの不正行為によって、他のテナントのトラフィックにパフォーマンスの問題が発生する可能性があります。 また、共有ユーザー空間のプロセスを悪用されると、すべてのテナントのすべての秘密/パスワード/キーが公開される可能性があります。 上記のことを念頭に置いて、新しい世代の SASE アーキテクチャは、専用のユーザ空間プロセスまたは専用のコンテナを介して、専用のプロキシインスタンスを使用するようになってきています。APIファーストアーキテクチャ：現在のSASEソリューションは、CLIとポータルを提供し、設定と監視を行います。 SASEのソリューションの中には、CLI/ポータルとバックエンドの管理システム間のAPIを使用するものがありますが、それらは宣伝されていません。 場合によっては、APIはクリーンではなかったでしょう。 新しいSASEソリューションは、CLIとポータルの実装のためだけでなく、サードパーティが外部のプログラムエンティティを開発するためのAPIが定義されているAPIファーストアーキテクチャを採用しています。 APIは、シンプルなスクリプト開発から複雑なワークフロー開発まで、terraformなどを介してSecOps-as-codeを可能にします。 RESTful API、JSONペイロード、OpenAPIベースのドキュメントを使用するのが一般的ですが、Kubernetesのカスタムリソースを公開して、セキュリティとネットワーキングのオブジェクトとポリシーを設定するものもあります。 API Firstアーキテクチャは、実際のバックエンドロジックとRBAC（役割ベースのアクセス制御）の実装を分離することも期待されています。 業界の経験では、RBACとビジネスロジックの両方が組み合わされた場合、かなりの数の脆弱性が存在します。 その結果、業界はRBAC機能を外部エンティティに分離し、アプリケーションをビジネスロジックに集中させる方向に進んでいます。 同じロジックがSASE管理システムにも適用されています。SASE管理システムは、SAEポリシー/オブジェクトと観測可能性に焦点を当て、RBAC機能はイングレスプロキシやAPIゲートウェイなどの外部エンティティに任せています。 イングレスプロキシは、すべての認証と承認、APIルーティングを行います。 良い点は、1つのイングレスプロキシで複数のアプリケーションをフロントエンドにできることです。 このため、管理者ユーザーは、多くのアプリケーションにわたって1つのRBACエンティティに精通するだけでよいのです。 このようにビジネスロジックをRBACから分離するために、APIファースト・アーキテクチャ・ソリューションはいくつかのガイドラインに従うことが期待されています。 例えば、多くのイングレスプロキシやAPIゲートウェイは、URIがRBAC用のリソースを指すために使用されることを期待しています。 ワークフローベースの自動化の場合、管理システムが構成にタグ付けし、古いタグにリストアして佐賀パターンを可能にすることが期待されます。 APIファーストのアーキテクチャは、業界のベストプラクティスに従うことが期待されています。

概要

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

  • CTOインサイトブログ

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