クラウドネイティブにおけるフォレンジック：その課題とベストプラクティス #aqua #コンテナ #クラウド #セキュリティ #CSPM #CWPP #DTA #動的解析
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2021年2月25日に公開された「 Cloud Native Forensics: Challenges and Best Practices 」の日本語翻訳です。
クラウドネイティブにおけるフォレンジック：その課題とベストプラクティス
個人、企業、または政府が次の大規模なサイバー攻撃の犠牲になることは間違いが無いため、インシデントの特定、封じ込め、調査する能力が必要とされています。フォレンジック分析を行うことで、攻撃の封じ込め・軽減するための適切な手順を踏むための貴重な洞察に活用でき、今後の攻撃を予防するために役立てられます。しかし、クラウドネイティブ環境への移行に伴い、フォレンジックプロセスは新たな次元に達しています。
クラウドネイティブ環境ではなぜ従来のフォレンジックではいけないのか
開発者がコードの変更を高速にデプロイするという、ワークロード環境の動的な特徴により、フォレンジックの課題はより根深くなります。物理サーバや仮想マシンが数ヶ月間放置されるのとは対照的に、コンテナは軽量でエフェメラルなコンピュートタスクであり、必要に応じてオーケストレーターによって起動及び停止することができます。コンテナの寿命は非常に短く、コンテナの平均的なライフサイクルは数時間です。典型的な AWS Lambda function の実行時間は、1回の実行で最大15分程度です。
このような非常に短い寿命は、セキュリティ、可視性、およびフォレンジックに大きく影響します。コンテナは一時的なものなので、コンテナファイルシステムに書き込まれたデータは、通常コンテナがシャットダウンすると別の場所に転送していない限り削除されます。Kubernetes のようなオーケストレーションツールは、どのマシンでどのワークロードを実行するかをスケジューリングする役割を果たします。その結果、デプロイされるまでどのホストでアプリケーションを実行するのか、チームはもはや確信を持って知ることができません。
要約すると、クラウドネイティブでフォレンジックを行うためには、以下のことに対処する必要があります。
- 非常に動的な環境
- エフェメラルなワークロード
- 複数のクラウドにまたがるデプロイメント
- 何百、何千もの実行中のコンテナ
今日の企業組織におけるフォレンジックの重要性は、特にクラウドネイティブスタックを標的とした攻撃の巧妙さが増していることからも明らかです。例えば、Tesla は Kubernetes ダッシュボードを介して侵入されたことを特定するのに6ヶ月かかりました。攻撃者がクラウドネイティブアプリケーションを悪用することに成功した場合、攻撃が確認される頃にはコンテナと Pod はおそらく存在せず、インシデント対応と監査はこれまで以上に困難なものになっています。
クラウドネイティブ環境に適切なフォレンジックを適用
コンテナは現代のソフトウェア開発の要ですが、従来のフォレンジックツールではコンテナのワークロードを可視化できません。
攻撃者があなたの環境に侵入した場合、サイバー攻撃のキルチェーンと攻撃のタイムラインを理解するために、まず証拠の収集をはじめる必要があります。悪質な攻撃者が、アプリケーション自体を攻撃する可能性は低く、一般的に、彼らはあなたのインフラを悪用してコンピューティングリソースを盗んだり(クリプトマイニング)、コンテナから脱出してホストを危険にさらしたり、ネットワークを横方向へ移動しようとしています。
クラウドネイティブで従来のフォレンジックツールが役に立たない場合、どうすればよいのでしょうか。アプリケーションからインシデントデータを収集するためのベストプラクティスをいくつか紹介します。
クラウドプロバイダーの機能を活用
手始めに、クラウドプロバイダーのネイティブなログ機能を活用できます。これらのログは、フォレンジック分析に使用できる豊富なデータセットを提供します。環境でこれらの機能が有効になっていることを確認する1つの方法は、Aqua CSPM のようなクラウドセキュリティポスチャマネジメント(CSPM)ソリューションを使用することです。
しかし、クラウドプロバイダーのログは通常、コントロールプレーンと OS のログのみをキャプチャし、アプリケーションログ(コンテナ内で何が行われているか)は含まれていません。攻撃の全体像を再構築するためには、コンテナ内で起こっていることを常に可視化することが最も重要です。
一元化されたロギングメカニズムの確立
ワークロードが持つエフェメラルな性質は、ログやモニターレコードが永続的でないことを意味し、問題の真の原因を特定することをより困難にします。アプリケーションデータを確実に利用できるようにするには、すべてのログを永続的に保存することができる1つの場所収集する必要があります。
例えば Aqua プラットフォームではこれに対処するため、コンテナエンジン上のオーケストレーションツールとユーザの両方が実行するすべてのアクション、コンテナ内のすべてのアクティビティと、サーバーレス function のリアルタイムデータ収集といった継続的な監視を提供しています。成功したコンテナのアクティビティとブロックされたアクションの両方がログに記録され、サイバー攻撃のキルチェーンの深い可視性を提供します。
このデータは Aqua のAudit(監査)コンソールに表示されますが、さらなるインシデント対応のために Splunk のようなサードパーティの SIEM や分析ツールへ送信も可能です。これにより検索と分析が容易になり、悪用されたコンテナがすでになくなっている場合でも、攻撃中に何が起こっていたかを診断するのに役立ちます。
コンテナイメージの動的解析を行う
しかし、攻撃者が従来のブロック型コントロールから逃れて環境に侵入することを可能にする高度な回避テクニックを使用するようになってきているため、それだけでは不十分な場合が多くなってきています。例えば Aqua の脅威調査チームは、最近ファイルレスマルウェア攻撃を実行するように設計された Docker Hub 内の4つのイメージを発見しました。このような攻撃の場合、侵害されたコンテナをなんとか発見することが出来たとしても、従来のソリューションを使用してこのサイバー攻撃のキルチェーンを理解し、どのように発生したのかを理解することは非常に難しいでしょう。
このような巧妙に隠ぺいされた脅威は、脆弱性やマルウェアをチェックする静的イメージスキャンでは見落とされ、コンテナ実行中にその動作を動的に解析することでしか検出できません。Aqua DTA(Dynamic Threat Analysis)はこれを実現できます。これは、安全なサンドボックス環境内でコンテナイメージを実行して挙動を解析することで、イメージ内の悪意のある要素を発見します。多くの企業が DTA を使用して、イメージを本番環境にプッシュする前のビルド時に、イメージ内の功名に隠ぺいされた脅威を特定していますが、違反が疑われた後のフォレンジック目的にも使用できます。
不正なコンテナイメージが攻撃するために使用されたことがわかったら 、DTA を活用することでさかのぼって犯人のコンテナイメージを発見し、コンテナレベルで攻撃がどのように発生し環境全体に広がっていったかを正確に分析できます。DTA によって特定されたセキュリティ侵害インジケーター(IOCs)と関心インジケーター(IOIs)を理解することで、攻撃を回顧的に分析する際にキルチェーン全体を追跡して可視化できます。
まとめ
脅威の状況が刻々と変化する中、フォレンジックはあらゆる企業のセキュリティ戦略において重要な役割を果たすようになっています。クラウドネイティブ環境へ侵入された後に分析するには、コンテナや function の内部で何が起こっているかを常に把握しておくことが不可欠です。OS、クラスタおよびコンテナの各レベルでログを収集するだけでなく、DTA などの動的解析ツールを活用して、コンテナ内の悪意のあるアクティビティの洞察を得たり、サイバー攻撃のキルチェーンに関する手がかりをまとめることができます。
