ブログ

効果的な API セキュリティに ML が必須である理由

F5 サムネイル
F5
2020年8月26日公開

過去 10 年間、開発サイクルの高速化、高可用性、選択的なオンデマンド スケーリング、および一般的な分離の追求により、テクノロジー主導の組織はマイクロサービス アーキテクチャへと移行してきました。 その結果、モノリシック ソフトウェア内の多くの安全な関数呼び出しが、安全でないネットワークを介したマイクロサービス間の API 呼び出しに変わりました。 つまり、この移行により多くの運用上およびビジネス上の課題は解決されましたが、いくつかの新たなセキュリティ上の課題も生まれました。

オープン ソース ソフトウェア、コンテナ化、Infrastructure-as-Code (IaC) の普及により、セキュリティ状況は悪化しています。 マイクロサービスのオンボーディングや変更が 15 分のタスクになる可能性があるため、セキュリティ チームにはマイクロサービスのセキュリティを適切に分析する機会が十分にない可能性があります。 デプロイメント パイプラインのゲーティング フェーズとして包括的なセキュリティ評価を導入すると、DevOps チームから否定的な反応が返ってくることがほとんどです。 たとえデプロイメントを効率的にゲートすることに成功したとしても、多くのセキュリティ問題、特にランタイム攻撃はデプロイメント時に特定できません。

セキュリティはもはや同じではない

開発者や DevOps チームにはマイクロサービスへの移行を積極的に受け入れる理由がある一方で、セキュリティ チームは、増加する API の量、API の定義と動作の変更、API ドキュメントの不足 (特にオープン ソース コンポーネント)、多様なプロトコル、ペイロード構造に対応するのにますます苦労しています。 現在、モジュール間の多くの内部関数呼び出しがマイクロサービス間の API 呼び出しになっているため、攻撃対象領域が爆発的に拡大し、セキュリティの管理が急速に困難になっています。

マイクロサービス環境の中規模であっても、マイクロサービスがデプロイまたは更新される前に、各 API エンドポイントの正常かつ許容可能な動作のリストを定義して維持することは、不可能ではないにしても、非常に困難です。 これには、各 API エンドポイントの承認ポリシーの維持も含まれます。 新しいマイクロサービスの追加、非推奨のマイクロサービスの削除、トラフィックの季節性などが、「正常かつ許容できる」定義が変化し続ける理由として予測できます。 また、断続的なネットワーク停止、DDoS 攻撃、アップストリームの停止、セキュリティの脆弱性など、予測しにくい理由も大きな役割を果たす可能性があります。

適切なセキュリティのために考慮すべきすべての要素を考慮すると、合理的かつタイムリーなセキュリティ決定を行うには、大量のデータをほぼリアルタイムで収集、相関付け、処理、学習する必要があります。 この要件により、従来のソリューションと制御は不十分になります。 幸いなことに、過去 10 年間の機械学習 (ML) の進歩と学習モデルの成熟により、これらの新しいセキュリティ課題に取り組むための非常に強力なプラットフォームが提供されています。

MLが救助に駆けつけます!

ML の力により、セキュリティ制御の定義、改良、実装の方法を再考できるようになります。 これにより、API のやり取りの動的な性質に対応しながら、効果的な API セキュリティを提供できるようになります。 ここでは、包括的かつ効果的な ML ベースのソリューションを実現するための 3 つの主なステップについて説明します。

1. ML にスコープを発見させましょう...フィードしないでください

前述したように、API の動的な性質と膨大な量により、開発者やセキュリティ チームが API 定義を意味のある形で定義し、API エンドポイントを保護するシステムに提供することは現実的ではありません。 ML ベースのモデルを使用すると、オフラインのトレーニング データを入力し、API エンドポイント (HTTP の場合は URL パス)、呼び出し元、ペイロードなどに基づいて、システムが API 呼び出しを自動的に検出、識別、分類、説明、許可/拒否できるようになります。 たとえば、API の検出は ML ベースの URL グラフを使用して実行され、コンポーネントの分類はディープラーニングを使用して実行できます。 これにより、システムは時間の経過とともに API 通信の範囲と性質を構築、成長、学習できるようになります。

このようなスコープの検出用に適切に調整されたシステムでは、更新された各デプロイメントにかかる数日、場合によっては数週間相当の人的労力を、数時間以内に置き換えることができます。

2. 学び、調整し、繰り返す

これは、あらゆる ML ベースのセキュリティ ソリューションの中核となる部分です。 優れたソリューションにより、セキュリティ制御によってシステムの動作を観察し、動作プロファイルを作成し、現在のモデル(過去の観察結果を使用して構築)を調整できるようになります。 これは継続的なプロセスであり、明確に実装されたソリューションにより、制御を意味のある方法とタイムリーに適用できるようになります。 たとえば、過去のプロファイルで特定の API 呼び出しシーケンスが通常のフローであることが示されている場合、フロー内にいくつかの追加呼び出しを実装するapplicationの更新されたビルドを数時間で学習し、プロファイルに追加できます。

動作のプロファイリングと調整が実質的に可能な限りリアルタイムで行われるため、ML ベースのソリューションの議論は非常に理解しやすいものです。

mlセキュリティ1
図1. MLベースのプロファイリング

3. 検出する

最初の 2 つのステップにより、システム内で「正常かつ許容可能な」動作と見なされるべき動作を学習し、最新の状態に保つことができます。 最後のステップは、その範囲外の行動パターンを検出して指摘することです。 たとえば、数百人のユーザーの通常の動作を学習した後、システムが特定のユーザーからのログインやデータのダウンロード試行が突然急増したこと、または複数のユーザーが短時間に同じネットワーク アドレスからログインを試みたことに気付いた場合、これらの動作はすぐに異常として検出されます。 API 異常検出は、順次的な教師なしディープラーニングを使用して実行できます。

ここで注目すべき重要な点は、フィードバック遅延は、悪意のある行為者が行動を調整して「レーダーの下を飛ぶ」ことを防ぐために、学習サイクル全体の中で非常に重要な部分であるということです。

図 2 は、システムによって正常かつ許容可能とプロファイルされた API 呼び出しのシーケンスを示しています。

mlセキュリティ2
図2: API呼び出しの通常のシーケンス

図 3 は、システムによって検出されフラグが付けられる API 呼び出しの異常なシーケンスを示しています。

ミリセキュリティ3
図3: API 呼び出しの異常なシーケンス

ここで注目すべき重要な点は、フィードバック遅延は、悪意のある行為者が行動を調整して「レーダーの下を飛ぶ」ことを防ぐために、学習サイクル全体の中で非常に重要な部分であるということです。

これらのソリューションが実装され、成果が出始めると、それらを活用して、HTTP ベースのトラフィックに対する Webapplicationファイアウォール (WAF) などの既存の制御を強化できます。

まとめ

ML は強力であり、ML ベースのソリューションはマイクロサービス ベースの環境における全体的なセキュリティの不可欠な部分として急速に普及しました。 Volterra では、社内業務に ML が必要であることを非常に早い段階で認識し、また、お客様が最新のapplicationsに効果的、安全、効率的に移行するための重要な機能として ML を提供してきました。