本文の内容は、2023年7月18日にDANIEL SIMIONATO が投稿したブログ（https://sysdig.com/blog/architecting-cloud-instrumentation/）を元に日本語に翻訳・再構成した内容となっております。
複雑で多様な企業インフラの保護にクラウド・インストルメンテーションを設計することは、並大抵のことではありません。思い浮かべてみてください。何百台もの仮想マシンがあり、その中には特殊な目的やオーダーメイドの構成を持つものもあります。さまざまなイメージを持つ何千ものコンテナ、多数の公開エンドポイント、パブリックとプライベートの両方のアクセスポリシーを持つS3バケット、セキュアなインターネットゲートウェイを経由してアクセスする必要があるバックエンドデータベースなどがあります。考えを巡らしても知恵が浮かばないなら、今、計画を立て、この混乱を整理するのに役立つセキュリティ・ソリューションを探し始める時です。
そこから今度はまったく新しい課題が出現します： どんなツールが必要なのか？幾つのツールが必要になるのか？クラウドのセキュリティ・インストルメンテーションに何を期待できるのか？
セキュリティ・ソリューション・アーキテクチャー
セキュリティをアーキテクトするためにセキュリティソリューションを評価するとき、そのインスツルメンテーションがどのように機能するかを理解することは有益です。ツールの背後にあるインスツルメンテーションを把握することで、各ソリューションの長所と短所をより適切に評価できるようになります。
クラウドリソースの計測には、主にエージェントレスとエージェントベースの2つの手法があります。最先端のクラウドネイティブ・セキュリティ・ソリューションは、エージェントレスとエージェントベースのインスツルメンテーションの両方が異なるユースケースをカバーしたり、それぞれの検出を強化するために使用されたりして、ハイブリッドなデプロイメント・アプローチを採用しています。
エージェントレス・ソリューションは、基本的なポスチャーと脆弱性管理のためのターンキー・ソリューションを提供します。エージェントレス・ソリューションは、クラウド・リソースが使用するリモート・ストレージ、クラウド API、サービスの監査ログを活用して、本来のワークロードを妨げることなくセキュリティ・イベントをスキャンします。
エージェントベースのソリューションでは、代わりにソフトウェア・プローブをワークロードと並行してデプロイメントし、ワークロードを検査・監視します。この検査にはさまざまな手法がありますが、現在のところ、eBPF（拡張Berkeley Packet Filter）ベースのプローブが望ましいソリューションとして注目されています。
エージェントレスを使い始めるのは素早く簡単ですが、エージェントベースのソリューションに比べると、そのユースケースは限られています。インフラで起きていることをリアルタイムで検知する必要がなければ、エージェントレス・ソリューションで十分かもしれません。しかし、脅威の検知と対応、ほぼリアルタイムのポスチャードリフト、または実行されていることに基づく正確な脆弱性管理が必要な場合は、エージェントベースのソリューションを使用する必要があります。
また、複数のツールを使ってすべての基盤をカバーしようと思うかもしれませんが、予算の制約や、単に異なるツールの動作方法間の互換性がないなどの理由で、必ずしもそうできるとは限りません。異なるツールのデータを統合しようとすると、多くの場合、不十分な結果のために多大な労力を浪費することになります。
難しいデザインにおける妥協
さて、候補となるソリューションがどのように機能するかを大まかに理解したところで、選択の参考となるような特徴的な機能は何でしょうか。
セキュリティ ソリューションが直面する主な課題は、可視性、目立たないこと、パフォーマンスの適切なバランスをとることです。これらの要素の1つを最大化すると、必然的に他の要素に悪影響を及ぼします。例えば、ワークロードの可視性を最大化すると、ある時点で重大なパフォーマンス・ペナルティにつながり、アプリケーションの実行を妨害する可能性があります。一方、パフォーマンスや目立たないことに重点を置くには、インストルメンテーションの可視性の制限について意識的に決定する必要があります。
これらのツールを評価する際には、どこで妥協がなされたのか、そしてその弱点があなたの意図するユースケースに合致しているのかを理解する必要があります。繰り返しになりますが、ツールの背後にある設計上の選択を理解することが、選択プロセスにおける指針となります。
クラウドの複雑性
古典的な設計上の課題は、最新のクラウドインフラのような複雑な環境では、バランスを取るのがさらに難しくなります。
クラウドリソースの規模や多様性に対応する場合、従来の設計では効果がないことがよくあります。クラウド環境向けのセキュリティ・インストルメンテーションは、規模、柔軟性、適応性といった複数の要素を念頭に置いて、意図的に設計する必要があります。
例えば、単一のコンポーネントでデータを収集・集中管理するエージェントレスツールでは、個々のリソース数が数十万ユニットに達することもある中規模または大規模のクラウド環境では対応できません。入ってくるデータを処理するために膨大なリソースが必要になるか、大量のデータをバッチで取り込む際に発生するレイテンシーに悩まされることになります。
異種のリソース（vms、コンテナ、s3バケット、IAMソリューション、データベースサービス、サードパーティのSaaSなど）は、セキュリティツールの柔軟性を試させ、クラウドに新しい抽象化を導入するには、高度な適応性が要求されます。
セキュリティ・ソリューションは、保護すべき本番環境と同等の環境で評価・テストすることが重要です。紙の上では優れているように見えても、実際のシナリオでテストしてみると不十分であることがよくあります。
厳しい選択
適切なセキュリティ・ソリューションを選択するには、単なる技術的能力だけではなく、予算、サポートの質、企業の準備状況など、多くの要素が考慮されます。しかし、優れたインストルメンテーションのデザインは、これまで以上に熟練した悪意のある行為者を測定し、それに対抗するために必要不可欠なものです。
最先端のクラウド・セキュリティ・ソリューションのアーキテクチャーの背後にある設計上の選択について詳しくお知りになりたい方は、当社のホワイトペーパー「クラウドセキュリティにおけるアーキテクチャーの重要性」をご覧ください。