脆弱性は前提：セキュリティのためのマイクロサービス挙動監視

2023年1月のKubernetes Blogの投稿で、IBM Research LabsのDavid Hadas氏は、開発者はマイクロサービスが本質的に脆弱であることを受け入れる必要があると主張しました。彼は、侵入不可能なシステムを構築することから、攻撃の試みを示唆する異常な挙動の監視へと焦点を移すことを提案しました。

何が起きたか

サイバーセキュリティへの投資は毎年増加していますが、成功したサイバーインシデントの数も増え続けています。Hadas氏は、あらゆる弱点を排除することに重点を置いた従来の戦略が失敗していることをこの傾向が示唆していると指摘しました。攻撃ツールはより洗練されており、攻撃者にとっての金銭的報酬があるため、入口が存在すれば必ず見つけ出されます。その結果、完全に脆弱性のないサービスを作成することに依存することは、もはや実行可能な戦略ではありません。

記事では、組織は自社のサービスに未知の弱点が含まれていることを意識的に認めるべきだと述べています。実践的には多くの場合不可能であるすべての脆弱性を除去しようとする代わりに、チームはその脆弱性が悪用されるのを防ぐことに注力すべきです。攻撃者が弱点を成功裏に利用できなければ、リスクは実現したものではなく、あくまで理論上のものにとどまります。この考え方の変換により、防御の境界線はコードの完全性からランタイムの挙動へと移動します。

Hadas氏は、この新しいアプローチの主要なメカニズムとして「Security-Behavior Analytics（セキュリティ行動分析）」という概念を導入しました。クライアントがサービスとどのようにやり取りし、サービスがどのように応答するかを分析することで、チームは攻撃が進行中であることを示す不規則性を検出できます。この手法では、具体的な脆弱性を事前に知る必要はありません。現在のやり取りが期待される規範から逸脱していることを認識するだけで十分です。

仕組み

セキュリティ行動監視は、マイクロサービス間のやり取りの予測可能性に基づいています。よく設計されたシステムでは、クライアントは定期的かつ構造化されたリクエストを送信し、サービスは一貫した方法で応答します。SQLインジェクションなどのエクスプロイトは、システムに不規則な挙動を強制します。例えば、悪意のあるクライアントは、正規ユーザーが行わないようなスペースや等号などの特殊文字を含むユーザー名を送信するかもしれません。同様に、サービスはこうしたリクエストを処理する際に応答時間が長くなったり、異常に大きなデータセットを返したりすることがあります。

これらの逸脱を監視することで、セキュリティツールは複数の段階で攻撃をブロックできます。クライアント側の監視では、アプリケーションロジックに到達する前に不規則なリクエストパターンを検出します。サービス側の監視では、異常な内部呼び出し、応答時間、またはデータ出力を識別します。両方の層を組み合わせることで、基盤となるコードに欠陥が残っていても、多くの脆弱性を悪用不能にする堅牢な防御が生まれます。攻撃者は通常の挙動を完璧に模倣するエクスプロイトを作成する必要があり、これはコードバグを見つけるよりもはるかに困難です。

このアプローチは、モノリスと比較してマイクロサービスアーキテクチャにおいて特に有効です。モノリシックなアプリケーションはさまざまな機能を絡み合わせ、異なる種類のリクエストや内部挙動を区別することを難しくします。一方、マイクロサービスは設計上、限定されたコンテキストと明確なインターフェースを持っています。このモジュール性は内部トラフィックを可視化し、各コンポーネントに対する厳格な期待値を定義するため、観察者は無関係なプロセスからのノイズなしに、特定のサービスにおける異常を見つけやすくなります。

主要な詳細

• 記事では、異なる監視戦略が必要となるサービスのライフサイクルの4つの段階を特定しています。通常運用、既知のCVEの存在、アクティブなエクスプロイトの利用可能状態、およびPodの誤用です。
• 「Vulnerable（脆弱）」段階では、CVEが公開されパッチ適用に数週間かかる間、監視により特定の脆弱性パターンに一致するリクエストをブロックできます。
• 「Exploitable（悪用可能）」段階では、ツールは既知のエクスプロイトシグネチャに基づいて受信トラフィックをフィルタリングし、実行を防ぐことができます。
• 攻撃者がPodを誤用した場合、システムは侵害されたインスタンスを識別し、健全なPodを実行させながらそれを再起動できます。
• CNCF Knativeプロジェクトの下にあるオープンソースプロジェクトであるGuardは、Kubernetes HTTPワークロードに対してこのスタンドアロン型のセキュリティ行動監視を提供するツールとして引用されています。
• マイクロサービスアーキテクチャは、そのモジュール性が明確な境界と予測可能なやり取りパターンを露呈させるため、この監視に本質的により適しています。

なぜ重要なのか

ソフトウェアエンジニアや技術リードにとって、この視点により、しばしば非現実的な目標である完璧なコードセキュリティの達成に対する圧力が軽減されます。代わりに、運用レジリエンス（回復力）が強調されます。脆弱性が存在することを受け入れることで、チームは検出および対応メカニズムをインフラストラクチャに組み込むことを優先できます。これは、信頼を一切仮定せず検証を継続するZero Trust原則と一致します。

行動ベースのセキュリティを実装することは、チームがインシデント対応を見る方法も変えます。既知のCVEを修正するためのパッチを待つ代わりに、行動ルールを展開して脅威を直ちに緩和できます。これにより、セキュリティチームが根本原因に対処している間も、サービスはオンラインかつ機能したまま維持できます。これはセキュリティをゲートキーピング機能から、継続的な運用上の安全装置へと変革します。

さらに、このアプローチはマイクロサービスの既存の利点を活用します。チームはすでにパフォーマンス上の理由からオブザーバビリティと監視に投資しています。これらのツールを拡張してセキュリティ行動分析を含めることは、完全なアーキテクチャの再構築を要求せずに保護層を追加します。標準的なテレメトリデータをセキュリティ資産に変え、オブザーバビリティへの投資が二重の配当をもたらします。

あなたができること

• 現在の監視設定を監査し、行動分析に必要な詳細なリクエストおよびレスポンスのメタデータを捕捉しているかどうかを確認してください。
• 典型的なリクエスト構造、応答時間、データ量など、重要なマイクロサービスのベースライン挙動を定義してください。
• 入力フィールド内の異常な文字セットやレスポンスペイロードサイズの急増など、これらのベースラインからの逸脱に対するアラートを導入してください。
• Kubernetesクラスタに専用のセキュリティ行動監視を追加するために、KnativeプロジェクトのGuardのようなツールを検討してください。
• 誤用が検出された際に侵害されたPodを自動的に再起動し、サービスの連続性を確保するためのプレイブックを開発してください。
• 静的コード解析だけでなく、潜在的な悪用経路を特定するための行動リスク評価も含めて、セキュリティレビューをシフトしてください。