ブログ

Sysdig Activity auditによるKubernetesにおけるインシデントレスポンス

Sysdig Activity auditによるKubernetesにおけるインシデントレスポンス

本文の内容は、2019年11月12日にSysdigのJorge Salamero Sanzが投稿したブログ(https://sysdig.com/blog/cloud-native-incident-response/)を元に日本語に翻訳・再構成した内容となっております。

Activity auditは、Secure 3.0リリースに含まれる新機能です。この機能により、コンテナとKubernetesのアクティビティを相関させた監査が可能となり、インシデントへの対応が迅速化されます。

Kubernetesにおける監査およびインシデントレスポンスのユースケース

Kubernetesのインシデントレスポンスに関しては、SOCチームは、数限りのないシナリオリストを分析できる必要があります。

  1. 私が所有するbilling namespaceから不明なIPアドレスへのすべてのアウトバウンド接続を表示する
  2. kubectl execユーザーインタラクションをトレースし、ポッド内で発生したすべてのコマンドとネットワークアクティビティを一覧表示します
  3. ホストまたはKubernetesのデプロイメントで発生したすべてのtcpdumpコマンドの実行を表示する

また、SOC2、PCI、ISO、およびHIPAAへの準拠には、Kubernetesで監査証跡を取得することが重要です。これには、コンテナが存在しなくなった場合でも、Kubernetesのすべてのユーザー、アプリケーション、およびポッドアクティビティを調査して保存する機能が必要です。

r01.png

Kubernetesにおいてインシデントレスポンスを行う際の課題

イベントの影響を判断するために必要なデータにアクセスできないため、Kubernetesでのインシデントレスポンスはとても困難です。短時間のみ立ち上がっているコンテナを使用する分散環境では、調査と事後分析は容易ではありません。コンテナの50%以上が5分未満しか生存していない実情からも多くの場合に当てはまるのではないでしょうか?

多くの場合、ログだけではすべての質問に答えることができません。 デベロッパーが事前に計測を施さなかったものはすべてログに反映されません。

サーバーとVMの世界では、チームはホストにSSHで接続してさらに分析を行うことができますが、アセットランドスケープが進化しているため、この概念はコンテナには機能しません。

  • コンテナは数秒以内に立ち上がったり、消えたりします。また、別のノードに再スケジュールされる前に、攻撃によりデータが流出する可能性もあります。コンテナが死ぬと、そのコンテナの記録もすべてなくなります。
  • コンテナはアドホックな仮想ソフトウェア定義ネットワークを介して通信し、内部IPアドレスは頻繁に変更されます。
  • インフラストラクチャとのユーザーおよびアプリケーションの相互作用は分離されています。Kubernetesコントロールプレーンはワークロードから分離されており、オーケストレーション、リソースアクセス、および実行権限を処理します。 Kubernetes API監査イベントは、これらの変更に関する情報を提供しますが、コンテナーアクティビティを可視化することはできません。

Kubernetesユーザーまたはサービスによって行われたクラスター内のすべての変更を理解することはほとんど不可能です。システムアクティビティをユーザーまたはサービスにマッピングする機能がなければ、セキュリティチームはKubernetes内の悪意のある振る舞いや設定ミスを発見する方法がありません。既存のツールは、この情報を相関のない異種のデータポイントとして提供します。その結果、セキュリティチームは可視性が制限され、誰が何をしたのかを把握することは困難を極めます。

Sysdig Secure Activity Auditでインシデントレスポンスをスピードアップ

Sysdig Activity Auditは、インシデントレスポンスを迅速化し、Kubernetesの監査を可能にします。 Sysdigは、次のような関連情報をキャプチャします。

  • コンテナ内で実行されたコマンド
  • ネットワーク接続
  • kubectl execを実行するユーザーのようなKubernetes APIイベント

この情報をKubernetesアプリケーションコンテキストと関連付けることにより、SOCチームは異常なアクティビティを見つけることができます。

サンプルシナリオを見て、Activity Auditを使用してKubernetesのセキュリティ違反を調査する方法を説明します。

r02.png

すぐに使用できるポリシーまたは設定済みのランタイムポリシーは、異常なアクティビティが検出されたときにセキュリティイベントをトリガーできます。 ポリシーイベントページに移動すると、「Terminal shell in a container」ポリシーがトリガーされたことがわかります。

ホストIPおよびMAC、コンテナイメージの詳細、コマンドなど、このインシデントを取り巻く詳細にドリルダウンし、違反が発生したKubernetesインフラストラクチャの特定の部分(特定のNameSpace、Deployment、Pod)を切り分けられます。

より深く掘り下げるには、Activity Auditを利用する事により「誰が」、「何を」、「なぜ」を理解する事が可能です。

r03.png

ここで、Activity Auditは「Terminal shell in a container」違反を特定し、特定の期間にkubectlセッションの一部として生成されたすべてのコマンドとネットワークアクティビティを把握できます。

左側のグループ化により、スコープを変更し、実行中のクラスター内の他のワークロードをナビゲートできます。 タイムナビゲーションを使用すると、監査ログの時間を前後に移動できます。この情報を使用して、アクティビティアクション、異常な振る舞いを特定し、予期しないパターンを調査する事ができます。

この例では、kubectl execが、調査を開始する不審なイベントであった場合を想定します。次のような詳細を確認する事ができます。

r04.png
  • kubectlの実行元のIPアドレス(66.249.64.55)
  • ユーザー情報(John Doe)と彼が属するグループ
  • Kubernetesアクティビティの詳細(リソース、サブリソース、実行されたコマンド)

いくつかの例を挙げると、これらのフィールドのいずれかでフィルタリングして、このポリシー違反以外のJohnからのすべてのアクティビティ、またはこのコンテナで経時的に発生したすべてのアクティビティを表示することもできます。

r05.png

ここから、Sysdigはkubectl exec:コマンドとネットワーク接続が開始された後にコンテナ内で何が起こったかを追跡します。これらはさまざまなデータソースであり、これらをフィルタリングして除外する事もできます。

この例では、Johnがbashコマンドを実行し、次にcurlコマンドを実行してインターネットからファイルをダウンロードし、tarおよびgzipで圧縮解除してbash履歴の痕跡を消したことがわかります。また、curlが接続したネットワークIPアドレスも確認できます。

これは、セキュリティチームがKubernetesにおけるインシデントレスポンスと事後分析を行う方法のほんの一例です。

Activity Auditは、既存のSysdig Secureフォレンジック機能(キャプチャ)を補完します。これにより、攻撃前後のすべてのコンテナアクティビティを記録できます。これにより、チームは発生したすべての事柄を分析できます-インシデント後だけでなく、その前でも、アクティビティの完全なシーケンスを理解できます。Sysdig Secureは、現在利用可能な唯一のKubernetes監査およびインシデントレスポンスソリューションです。

まとめ

Activity Auditは、強力なインシデントレスポンスフレームワークをもたらし、セキュリティ侵害から効果的かつ、迅速に回復させる事に役立ちます。システム/コンテナレベルのアクティビティをkubectlセッションなどのKubernetesアクティビティと相関させることにより、詳細なKubernetes監査証跡を提供するため、SOCチームは異常なアクティビティを発見できます。また、チームが監査証跡を取得できるため、コンテナが存在しなくても、SOC2、PCI、ISO、HIPAAなどのコンプライアンス標準に準拠できます。

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top