ブログ

分散アプリ クラスターのセキュリティのためのサービス メッシュの制限を克服する

アンカー・シングラ サムネイル
アンクル・シングラ
2020年4月13日公開

これは、 SaaSサービスの構築と運用に必要だったさまざまな側面を取り上げているブログ シリーズの 4 番目のブログです。

  1. 分散Kubernetes PaaSのコントロールプレーン
  2. 分散アプリケーション向けのグローバル サービス メッシュ
  3. 分散インフラストラクチャ、アプリ、データのプラットフォームセキュリティ
  4. 分散クラスタのapplicationとネットワークのセキュリティ
  5. グローバルに分散されたプラットフォーム全体の可観測性
  6. グローバルに分散されたプラットフォームの運用と SRE
  7. 分散マイクロサービス向けの Golang サービス フレームワーク

前回のブログでは、暗号化技術を使用してプラットフォーム（インフラストラクチャ、アプリ、データ）を保護する際の課題について説明しました。 このブログでは、ネットワーク（インターネットと内部）からの標的型攻撃からプラットフォームを保護するために使用する手法について説明します。 アプリは物理的な場所に制限されなくなったため、従来の境界ベースのファイアウォールや署名ベースのセキュリティ ソリューションは効果を発揮しなくなりました。 当社の最初のゼロトラスト セキュリティ実装の欠点と、分散インフラストラクチャとアプリ クラスターを適切に保護するために機械学習とアルゴリズム技術を使用してそれを強化した理由と方法について説明します。

TL;DR (要約)

  1. 当社のプラットフォームでは、複数のクラウド プロバイダー (AWS および Azure)、グローバル ネットワーク、エッジ ロケーションにわたるいくつかのモノリシック アプリに加えて、数百のマイクロサービス (多数の Kubernetes クラスターにわたって) が実行されているため、アプリ間およびグローバル ネットワークとアプリ間のセキュリティ要件は複雑になっています。
     
  2. また、当社の開発者、運用チーム、顧客の開発者、顧客の運用チーム、および顧客のエンドユーザーに共有インフラストラクチャへの選択的アクセスを提供するプロセスを構築し、堅牢なネットワーク + アプリ セキュリティ ソリューションを提供することも求められました。 PCI-DSS、SOC などのコンプライアンス要件を満たす必要があったため、状況はさらに複雑になりました。
     
  3. 当社はすでにグローバル サービス メッシュと API ゲートウェイに基づくゼロ トラスト ソリューションを構築していましたが、システムの脆弱性、リソースの枯渇、ボット/マルウェアによるインターネット攻撃、認証されていないアクセスを提供するいくつかのサービスに対するニーズなど、多くのセキュリティ問題は解決されていませんでした。 また、当社のセキュリティ チームが開発者から API 情報を取得するのが難しい場合もありました。これは、アクセス ホワイトリストに依存する優れたゼロ トラスト展開に不可欠です。
     
  4. これらのニーズに応えるには、当社のプラットフォーム チームがベンダー/クラウド プロバイダーからサービスを調達するか、L3-L7+ データパス (詳細はこちら) にネットワーク ファイアウォール、アプリ ファイアウォール、DDoS 保護、特権アクセス管理などの追加のセキュリティ機能を追加する必要がありました。 既存のベンダーやクラウド プロバイダでは、統一されたポリシー、可観測性、自動 API 検出機能を提供するツールでこれらの問題を解決できないという事実を踏まえ、データパスとコントロール プレーンを拡張する社内プロジェクトに着手するという難しい決断を下さなければなりませんでした。
     
  5. ネットワーク + アプリのセキュリティ機能をデータパスに組み込む一環として、これまでどのネットワーク データパスでも実現できなかった多くの新機能が追加されました。 私たちは、ネットワーク、HTTP、API のスタック全体で機能するプログラム可能なポリシー エンジンとともに、ネットワーク + アプリ トラフィック上のアルゴリズム セキュリティ機能と機械学習を融合しました。 その結果、導入環境、トラフィック モデル、レイテンシのニーズに応じて、さまざまなセキュリティ機能を提供できるようになりました。 これにより、グローバル サービス メッシュのセキュリティが強化され、SOC チームの誤検知数が減り、レイテンシとコンピューティング リソースが大幅に削減されました。

サービスメッシュとゼロトラストアーキテクチャの限界

当社のプラットフォームは、エッジ、グローバル ネットワーク、AWS および Azure パブリック クラウドで独自のクラスターを運用する複数のチームにまたがる多数のアプリを実行します。 ワークロードの大部分は Kubernetes を使用してマイクロサービス オーケストレーションされていますが、Terraform を使用して管理している非常に大規模なモノリス (例: elasticsearch) もいくつかあります。 図 1 は、当社のプラットフォームの分散性を示しています。 たとえば、当社の 18 を超えるグローバル ネットワークPoP (数十台から 100 台強の物理サーバー) のそれぞれで、数千のアプリ ポッドを実行しています。 ただし、エッジでは現在、3,000 を超えるアクティブな場所 (それぞれに 1 ～ 7 台のコンピューティング) で数十のアプリ ポッドを実行する個別の顧客展開が行われています。

メッシュ制限 1
図1: Volterra プラットフォーム全体に分散されたアプリとデータ

このプラットフォームは完全なマルチテナントであり、各ノードは異なる顧客（および当社自身）のワークロードを実行します。 これらのアプリの一部はパブリックインターネットに公開されているため、アプリとの間のすべての通信が安全であることを確認する必要があります。 前回の 2 つのブログで概説したように、私たちはサービス メッシュとAPI ゲートウェイを強化するために使用する独自の L3-L7+ ネットワーク データパス (VoltMesh) とともに、堅牢な ID、認証 + 承認システムを構築しました。 図 2 に示すように、これにより、アプリ クラスター全体 (mTLS)、ユーザー (TLS/mTLS)、従業員 (mTLS) にトランスポート レベルのセキュリティを提供するとともに、認証 + 承認に基づくアクセス制御も実現できるようになりました。

メッシュ制限2
図2: サービス メッシュと API ゲートウェイによるトランスポート セキュリティ

このゼロトラスト実装は多くの利点をもたらしますが、いくつかのセキュリティ問題を自動的に解決するわけではありません。

  1. システムの脆弱性— システムの脆弱性や、権限はあるが悪意のある従業員が原因でアプリが侵害される可能性があります。このような状況を検出し、自動的に是正措置を講じ、SRE チームに警告するメカニズムが必要です。
     
  2. リソースの枯渇— 設計が不十分なために、正当かつ承認されたクライアント アクセスであってもアプリ リソースが徐々に枯渇してしまう状況は数多くあります。 このような状況では、他のユーザーのパフォーマンスが大幅に低下する可能性があります。
     
  3. インターネット攻撃— 当社（およびお客様）のインフラストラクチャとアプリの多くはパブリックインターネットに直接公開されているため、これらのリソースは悪意のあるユーザー、ボット、マルウェアからの攻撃を継続的に受けます。 他のユーザーに良好な応答時間を提供するためには、これらのリソースをサービス拒否攻撃、ボリューム攻撃、侵入攻撃から検出して保護する必要があります。
     
  4. 認証されていないサービス— ほとんどのアプリでは認証が必要ですが (ゼロ トラストにも必要)、アプリを制限できない場合もあります。 そのため、これらのアプリには、ネットワークベースのソリューションを使用した追加の保護が必要になります。

このプラットフォームでの開発の過去 2.5 年間で、開発者がオープンソース アプリを組み込み、コンテナ化して、DevOps チームにプラットフォームへの展開を依頼することがよくあることにも気付きました。 しかし、これらのアプリ内の API レベルのやり取りに関する詳細が不足していることが多く、セキュリティ チームが通信をホワイトリスト化するポリシーを作成する際に必要となります。 これは、アプリが使用する API のみを許可し、他のすべてのトラフィックをブロックするホワイトリスト ポリシーを義務付けるため、ゼロ トラスト セキュリティ実装にとって大きな障害となります。 この要件に例外を設けた場合には、一部のアプリに非常に基本的なネットワーク レベルのセグメンテーションが残り、攻撃対象領域が拡大しました。

ゼロトラスト サービス メッシュの強化

その結果、上記の問題に対処するために、既存のゼロトラスト セキュリティ ソリューションに追加のセキュリティ機能を追加する必要がありました。 プラットフォームに組み込む必要のある追加のセキュリティ機能のリストを特定しました。

  1. API の検出と制御- 実行中のアプリで API を学習し、開発者に依存せずにアプリ/API のホワイトリスト ポリシーの生成を自動化する機能を構築します。
  2. 異常検出- あらゆるソースタイプ（信頼できるまたは信頼できないユーザー/アプリ）からのトラフィックの異常な動作を検出し、保護する機能
  3. 動作プロファイリング- リソース枯渇、アプリ/API攻撃（インターネットまたは内部ネットワークから）からアプリを保護し、インターネットからインフラストラクチャやアプリへのボリューム攻撃から保護します。
  4. ログ記録と可視化- 将来のフォレンジックやコンプライアンスのニーズに備えて、すべてのアクセスをログに記録して追跡する機能

私たちは、これらの問題を解決するために、従来の署名ベースの技術、統計アルゴリズム、およびより動的な機械学習アプローチを組み合わせて使用することにしました。 これには、SaaS バックエンドに変更を加え、ネットワーク データパスに新しい機能を追加する必要がありました。

API の検出と制御のためのディープラーニング

プラットフォームをロックダウンするために、各アプリの API のホワイトリストに基づいてのみネットワーク接続を許可します。そのためには、セキュリティ チームが開発者と連携し、プログラム可能なポリシー エンジンに適切な API 情報が提供されるようにする必要があります。 私たちのサービス フレームワークを使用して構築されていないアプリに対して、開発者がこの情報を提供することは不可能であることにすぐに気付きました。

サービス メッシュ プロキシはアプリへのすべてのアクセスのネットワーク パスにあるため、プロキシを通過するすべてのアクセスの実行時分析を実行して、アプリによって公開される API と静的リソースを学習することにしました。 このアプローチの課題は、URL を検査し、動的に生成されるコンポーネントを分離することで API エンドポイントを識別することです。 たとえば、API「api/user/<user_id>/vehicle/」の場合、プロキシは次のようなアクセスを認識します。

このようなリクエストは数百万件に及ぶ可能性があり、解読するのは非常に困難です。 その結果、これらの関連リクエスト内の動的コンポーネントの識別は、ディープラーニングとグラフ分析を使用して行われます。 URL コンポーネント セット全体をグラフとして表現し、グラフ クラスタリングを実行して、次のような動的に生成されたコンポーネントの特定のプロパティをキャプチャする機能セットを使用して、類似したプロパティを持つサブグラフを見つけます。

  • 構造特性
  • ノードのエントロピー
  • グラフのさまざまな部分間のジャカード類似度
  • よく理解されているディープラーニング手法を使用したシンプルな文字列分類

その結果、動的コンポーネントが分類され、システムからの出力は次のようになります。

この API の機械学習を使用すると、サービス メッシュ プロキシによって適用できるポリシーを簡単に自動的に生成できます。 検出された API エンドポイントに基づいて、どのアプリがどの API を使用して他のアプリと通信するか、これらの API の一般的な動作など、他のプロパティも学習します。 これにより、セキュリティ チームがフォレンジック、検出、API レベルのマイクロセグメンテーションのためにサービス間の相互作用を視覚化するのに役立つサービス グラフを構築できます。

ファイアウォールの欠陥を特定する

残りの 2 つの機能 (異常検出と動作プロファイリング) の追加に着手する前に、既存のソリューションが役立つかどうかを確認することにしました。 市場には境界ファイアウォールや Web アプリケーション ファイアウォール製品が数多く存在しますが、これらのソリューションの大部分はインターネットに接続されたアプリケーションの保護を目的としています。 これらは、処理対象のトラフィックが Web トラフィックであるという一定の前提に基づいて、HTML、JavaScript、SQL、CMS などに的を絞った保護を提供します。これにより、脆弱性や既知のエクスプロイトを検出するためのシグネチャやルールの作成が比較的容易になります。

この機能は Web トラフィックにとって重要ですが、私たちの環境では増加し続ける API およびマシン間トラフィックも処理する必要があります。 これを解決するには、セキュリティ チームが、既知の一般的な Web ルール (OWASP CRS など) に該当しないアプリ固有のルールを作成する必要があります。 通常、セキュリティ管理者はアプリについてあまり知識がなく、環境の動的な性質により、アプリの種類と構造を追跡してアプリ固有のルールを記述することがさらに困難になります。 その結果、当社のプラットフォーム チームはネットワーク データパスでこの機能を提供していますが、セキュリティ チームではあまり使用されていません。

私たちのネットワークから大量のデータが収集されるもう 1 つの問題は、アプリ攻撃が時間の経過とともにますます高度化していることです。 攻撃者は、HTTP/TCP 署名などを調べて、API、アプリ、基盤となるインフラストラクチャ、OS の種類の詳細を判断するために、何日もかけて偵察を行います。 従来の署名とルールベースのアプローチは、このような状況では非常に限られた用途しか持たないため、当社は AI ベースのアプローチを継続して、ユーザーの行動を自動的に学習し、良い行動と悪い行動を区別することにしました。

行動プロファイリングのための機械学習

ほとんどのアプリには特定のワークフロー (API のシーケンス) とコンテキスト (API 内のデータ) があり、それに基づいてさまざまなユースケースやデプロイメントが設計され、通常はアプリのユーザーがそれに従います。 私たちはこれらの特性を活用し、機械学習アルゴリズムをトレーニングして、アプリとの一般的なユーザーインタラクションにおける「有効な」行動パターンをモデル化します。

データパスは、各 API のリクエスト/レスポンスと関連データをサンプリングし、図 3 に示すように中央学習エンジンに送信します。 このエンジンは、有効な動作パターンのモデルを継続的に生成および更新し、データパスで実行されている推論エンジンによって使用され、疑わしい動作を警告/ブロックします。

メッシュ制限3
図3: 学習コアと分散推論エンジン間の相互作用

学習エンジンは、API のシーケンス、リクエスト間のギャップ、同じ API への繰り返しリクエスト、認証の失敗など、多くのメトリックを調べます。 これらの指標はユーザーごとに分析され、集計ベースで良い行動と悪い行動を分類します。 また、行動クラスタリングを実行して、「良い行動」の複数の異なるシーケンスを識別します。 これを説明するために例を見てみましょう。

  • このモデルは、多くのユーザーを分析して、一連の適切な行動を定義します。 各色は個別の異なる API 呼び出しを表します。
メッシュ制限-4
図4: APIの通常のシーケンス

    次の一連のAPIは、システムによって疑わしい/不正な動作としてフラグが付けられ、システムによって自動的に軽減されるか、管理者が介入するためのアラートが生成されます。

メッシュ制限5
図5: 疑わしいAPIシーケンス

このシステムを 1 年以上前に実稼働させて以来、使用状況と顧客からのフィードバックに基づいてモデルを継続的に改良してきました。 私たちは以下の種類の攻撃を特定することに成功しました: 

  • クローラー/スキャナーはアプリの偵察を行い、脆弱性を発見し、アプリによって公開されているすべてのAPIのマップを作成します。
     
  • 脆弱なAPIに対して複数の攻撃ベクトルを仕掛けることによる悪意のある活動を継続する
     
  • リソース枯渇につながる HTTP レベルのサービス拒否攻撃 (例: API へのログイン試行が複数回行われる)
     
  • 情報を収集するように設計されたボットによるデータ漏洩（例：競合他社の電子商取引サイトからの価格情報）
     
  • ブルートフォース攻撃 - ログイン/パスワードの辞書攻撃
     
  • 良いボットの識別（例：Google、Bingクローラー）

とはいえ、このアプローチにはいくつかの問題があることもわかりました。つまり、異常検出技術を適用する必要がある低速で遅い攻撃 (ブルートフォース、アプリのサービス拒否、スキャナー) を発見できないのです。

アルゴリズム+AIベースの異常検出

時には、当社の行動分析技術をすり抜ける大規模な分散ボットネットを使用した、非常に洗練された攻撃が発生することがあります。 このような攻撃の例は次のとおりです。 

  • 分散型ブルート フォース攻撃
  • 分散辞書ベースのアカウント乗っ取り攻撃
  • 複数のクライアントから脆弱性を発見し、それを悪用するための分散スキャナ
  • 高度に分散されたボットネットからの HTTP DoS 攻撃
  • 計算負荷の高い API の小さなサブセットをターゲットとするボットネット
  • 大量のデータを扱うAPIを標的にしてリソースを枯渇させるボットネット

ネットワーク データパスはグローバル ネットワーク全体の各ノードから情報を収集するため、リクエスト レート、エラー レート、応答スループットなどの特定のアプリの集計メトリックの分析を比較的簡単に実行できます。 この分析により、ボットネットの一部である可能性のあるユーザーを特定することで、分散型攻撃を検出し、（すべてのノードで）攻撃を軽減することができます。 リクエスト レートを確認して、さまざまな時間枠 (過去 5 分、30 分、4 時間、24 時間) にわたって異常を検出しようとしている例を見てみましょう。特定の時間枠内でリクエスト レートが高い場合、システムによってアクセス ログの次の詳細な分析が実行されます。 

  • ソース IP アドレスの分散が通常より高いか低いかを分析します。 リクエストが多数の固有のソース IP から送信された場合、それは高度に分散された攻撃を示しており、各ソース IP に対してより積極的なバージョンのユーザー行動分析がトリガーされます。
  • 各ソース IP アドレスに対してより積極的なバージョンのユーザー行動分析を実行し、疑いスコアを割り当てて、構成された緩和アクションを実行します。
  • ほとんどのリクエストが（通常よりも）少数の API エンドポイントに送信された場合、ブルート フォース攻撃または DoS 攻撃を示しています。 APIEPの拡散が通常よりも大きかった場合、分散型クローラー、スキャナー、またはDoS攻撃が行われていることを示しています。

異常検出はファイアウォール アプライアンスの侵入検知および防止 (IDS/IPS) にとって常に重要な技術ですが、これらのアプライアンスではグローバルなアプリ層攻撃を軽減することはできません。 当社のグローバル プラットフォーム全体で API マークアップと学習を実行できるようになったことで、分散ネットワーク全体のソースで攻撃を抑制できるようになりました。

アプリ + ネットワーク セキュリティのための機械学習のメリット

サービス メッシュと API ゲートウェイに基づくゼロ トラストの実装には非常に満足していましたが、分散アプリケーション クラスターを脆弱性や悪意のある攻撃から保護するには包括的ではないことに気付きました。 より優れたセキュリティ ソリューションを提供するために、従来のシグネチャ + ルールベースの手法に加えて、動作分析 + 異常検出のための機械学習を追加する必要がありました。

集中型 SaaS で実行される学習コアに加えて、L3-L7+ ネットワーク データパスに分散推論を追加することで、次の 3 つの大きなメリットが得られました。 

  1. エンドツーエンドのゼロトラスト ネットワーク— プラットフォーム全体にわたって API レベルのマイクロセグメンテーションを実施できるようになりました (100% ギャップなし) — ネットワーク全体が、API レベルのアクセスとネットワーク レベルのアクセスがゼロのグローバルに分散されたプロキシです。
     
  2. モデルを継続的に調整する機能により誤検知が 82% 以上削減され、NOC チームと SOC チームが対処しなければならない誤検知の数が大幅に削減されました。 従来のツールでは、多数の警告が発せられ、まったく役に立たなくなるため、この点が大きな懸念事項でした。
     
  3. 従来のルールと署名ベースのアルゴリズムによって実行されていたタスクを徐々に新しい機械学習コアに移行することで、レイテンシとコンピューティング使用率が大幅に削減されます。

ネットワークとアプリのセキュリティは終わりのない滑走路であり、追加すべき新機能のバックログがまだたくさんあるようです。 近い将来、私たちが実装した増分アルゴリズムとテクニックに関する追加の洞察を共有するために戻ってきます。

つづく…

このブログ シリーズでは、パブリック クラウド、プライベート ネットワーク PoP、エッジ サイトにある多数のアプリ クラスターを使用して、グローバルに分散された SaaS サービスを構築および運用するために必要なさまざまな側面について説明します。 次は「グローバルに分散されたプラットフォーム全体の可観測性」です（近日公開予定）…