TerraformでSysdig脅威検知ポリシーを実装してみた
2025.02.19お疲れさまです。とーちです。
最近、Sysdigの脅威検知ポリシーをTerraformで設定する機会があったので、その方法について紹介したいと思います。
前提知識
Sysdigは、DockerやKubernetesと統合された、クラウド、コンテナ、マイクロサービスに特化したセキュリティ統合プラットフォームです。
Sysdigを利用することで、クラウドの脅威検知やブロックによるコンテナワークロードの保護を実現できます。
Sysdigの脅威検知ポリシーとは、SysdigエージェントをインストールしたEC2やECS Fargate、Kubernetesなどで脅威を検知するための以下のようなルールを定義するものとなっています
- どの範囲（例えばコンテナイメージリポジトリ名やコンテナ名など）に対して脅威検知を行うか
- どのような脅威が発生した際に検知を行うか
- 脅威が発生した際にどのようなアクションを行うか
- 脅威が発生した際にどこに通知を行うか
脅威検知ポリシーの設計方針
Sysdigの脅威検知ポリシーを設定する前に、まずは全体的な方針について考えてみました。
なお、Sysdigの脅威検知ポリシーは以下のようにかなり多くの種類があります。今回は特にコンテナ上のワークロードの脅威を検知することを目的として、ワークロードポリシーの設定を進めていきます。
ポリシータイプについて
脅威検知ポリシーの中でも「ワークロードポリシー」やAWS関連のポリシーではSysdigにより管理された管理ポリシーを使用できるようになっています。
この管理ポリシーが使用できるものについては以下の３種類のポリシータイプがあります
- 管理ポリシー: Sysdig 脅威調査チームによって作成および管理され、Sysdig により定期的に更新されます。管理ポリシーはデフォルトで作成されています。
- 管理ルールセット: 管理ポリシーをコピーして作成したものが管理ルールセットです。こちらもSysdigにより定期的に更新されます。管理ポリシーとの違いとしては、名前やポリシー自体の重要度等をユーザーが変更出来る点、また管理ルールセットは複数作成できるという点に違いがあります
- カスタム ポリシー: 管理ポリシーや管理ルールセットではどの環境でも汎用的に使用できる脅威検知ルール集をSysdigが予め設定し、かつ更新も行ってくれます。それに対してこのカスタムポリシーは、ユーザーが自由に脅威検知ルールを決められますが、どのルールを脅威とするかや、ルールを最新の状態に保つ責任はユーザーにあります。そのためSysdigを十分に理解している管理者が使用するタイプのポリシーとなっています。
管理ルールセットの大きな特徴は、複数作成できる点にあります。この特徴を活かすことで、以下のようなきめ細かな設定が可能です
- チームAには脅威検知時に通知のみを行う
- チームBには脅威検知時にコンテナのkillも実行する
このように、Sysdigが提供する信頼性の高いプリセットポリシーをベースにしながら、各チームや環境に応じて異なるアクションを設定できます。
今回採用した2層構造の設計
これらのポリシータイプを踏まえて、今回は以下のような方針でワークロードポリシーを設計することにしました。
1. 基本ポリシー（全体適用）
- Sysdigの管理ルールセットを使用
- 重要度Highのプリセットポリシーのみをまずは使用
- 検知時は通知のみ（コンテナのkillなし）
- 全システムを対象
- 通知先は全体のシステム管理者
2. チームごとのポリシー（オプション）
- 対象の個別システムの担当チームにも通知を行いたい場合やシステムに固有の要件がある場合に作成
- 管理ルールセットを使用
- システム要件に応じてコンテナのkillも実行する
- スコープ設定で対象システムを限定
- 通知先は各システムの担当チーム
今回は上記のうちの基本ポリシーの部分をTerraformで作成してみます。
Terraformによる実装
利用可能なSysdigリソース
Terraformで作成できるSysdigのリソースは公式ドキュメントで確認できます。
今回必要なリソースは以下の2つです
ディレクトリ構成
Terraformのディレクトリ構成としては以下のようにしてみました。Terragruntを使ってます
.
├── envs
│ └── prod
│ ├── notifications # 通知設定をplan/applyするためのフォルダ
│ │ ├── main.tf
│ │ ├── outputs.tf
│ │ └── terragrunt.hcl
│ ├── threat_policies # 脅威検知ポリシーをplan/applyするためのフォルダ
│ │ ├── main.tf
│ │ ├── terragrunt.hcl
│ │ └── variables.tf
│ ├── env_var.hcl
│ └── prod.hcl # 環境ごとのTerragrunt設定
├── modules
│ ├── notifications # 通知設定モジュール
│ └── policies
│ └── threat # 脅威検知ポリシーモジュール
└── shared
├── providers.tf # プロバイダー設定
└── terraform.tf # required_providers設定
なお、今回のコードは以下に格納しました。
それでは詳細に見ていきましょう。
1. 通知設定の実装
モジュール側
まずは通知設定用のモジュールを作成します
- ポイント
- Sysdigの通知設定用のリソースは通知先の種別（メールやslack）ごとに分かれています。例えばslackに通知したい場合は、
sysdig_secure_notification_channel_slackを使います - 通知設定の詳細についてはこちらを確認してください
- output定義では設定した通知チャンネルIDをmapとして出力しています
- Sysdigの通知設定用のリソースは通知先の種別（メールやslack）ごとに分かれています。例えばslackに通知したい場合は、
呼び出し側
呼び出し側はこんな感じです
2. 脅威検知ポリシーの実装
モジュール側
次に、脅威検知ポリシー用のモジュールを作成します
- ポイント
- 各パラメータの詳細はこちらを確認してください
- inherited_fromパラメータでどの管理ポリシーからコピーするかを指定します
- disabled_rulesには管理ルールセットポリシーの中で無効にしたいルールを指定します。このあたりは実際に運用してみて、どれを無効化すべきか検討すると良いと思います
- actionsのcapture定義で脅威検知時にキャプチャを取得し、詳細に分析できるようにしています
- notification_channelsには通知設定側のtfstateファイルでoutputしたチャンネルIDを入力として指定します
呼び出し側
呼び出し側はこんな感じです
３．Sysdig Provider の設定
最後に、SysdigのTerraform Providerの設定について説明します。
Sysdigをterraformで操作するためには、以下の2つの情報が必要です
- Sysdigエンドポイントのベースとなる URL
- APIトークン（認証用）
これらはproviderブロックで以下のように指定します
APIトークンは機微な情報なのでここではAWS Secrets Managerを使用したうえで、エフェメラルリソースを使っています
なお、APIトークンの取得方法についてはSysdigの公式ドキュメントに詳しい手順が記載されていますので、そちらをご参照ください。
まとめ
今回は、Terraformを使ってSysdigの脅威検知ポリシーを管理する方法を紹介しました。2層構造の設計アプローチと、それをTerraformで実装する方法について解説しました。
Sysdigの他のリソースもTerraformで管理したいと思ってるので、続編も書きたいなと思います。
以上、とーちでした。
![[Terraform]親ドメインからサブドメインへの権限委任 〜 サブドメインのパブリック証明書を取得するまで](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-abb8f6015ca9ca8ce4d38fd37d2ab700/ee9c71478937f038e1364aa400fecf15/amazon-route-53)
