Sysdigでコンテナセキュリティをコードとして管理するためにTerraformを使用する

Sysdig Platform（MonitorとSecureの両方）

• ユーザーおよびアクセス管理: ユーザー、ロール、サービスアカウントを管理します（例: sysdig_user、sysdig_custom_role）。
• IPフィルタリング: プラットフォームへのアクセスに対するIP制限を設定します（例: sysdig_ip_filter）。

Sysdig Secure

• ポリシー: ランタイムおよび脆弱性ポリシーを作成します（例: sysdig_secure_policy）。
• コンプライアンス制御: ポスチャー制御を定義します（例: sysdig_secure_posture_control）。
• ルール: Falco構文を使用してランタイムルールを実装します（例: sysdig_secure_rule）。
• 通知チャネル: メール、Slack、その他の連携向けのアラートを設定します（例: sysdig_secure_notification_channel_slack）。
• マクロとリスト: 複数のFalcoルール間でロジックを再利用します（例: sysdig_secure_macro、sysdig_secure_list）。

Sysdig Monitor

• アラート: メトリクス、PromQLクエリ、または異常行動から検出されたアノマリーによってトリガーされるアラートを作成します（例: sysdig_monitor_alert_metric）。
• ダッシュボードとチーム: コードでダッシュボードとユーザーチームを管理し、表示設定をコードとして構成します（例: sysdig_monitor_dashboard）。
• 通知チャネル: PagerDuty、webhook、メールなど、アラートの連携を設定します（例: sysdig_monitor_notification_channel_email）。

設定複製の自動化

組織では、開発、ステージング、本番など複数の環境を使用することがよくあります。Sysdig Terraformプロバイダーは、これらの環境間で設定を効率的に複製し、テストするのに役立ちます。たとえば:

• カスタムFalcoルール: 本番に昇格する前にステージングでランタイム検知ルールをテストして検証し、障害やノイズを減らします。
• コンプライアンスポリシー: Terraformを使用してRegoベースのポリシーを段階的に展開し、環境をまたいで改善・検証します。

Terraformはproviderブロックとstateファイルを使用して、各環境が一貫した設定でプロビジョニングされるようにし、ドリフトを回避します。宣言的モデルにより、望ましい最終状態を定義でき、Terraformがその状態に一致させるための下層の手順を処理します。これにより手作業のミスが減り、プロセスの効率が向上します。さらに、必要な状態はコードとして定義されるため、Gitのようなバージョン管理システムに保存して過去の変更を追跡し、新しい変更をレビューし、必要に応じてロールバックできます。

デバッグ

設定のトラブルシューティングやTerraform実行のデバッグのために、環境変数TF_LOG=DEBUGを設定して詳細ログを有効化できます。これによりAPI呼び出しやその他の詳細が表示され、問題の特定に役立ちます。

ポリシー

組織内のコンテナでターミナルシェルが実行されることを検知したいとします。このイベントは通常セキュリティリスクであり、本番コンテナでシェルが生成されることは、不正アクセス、設定ミス、またはコンテナ環境を悪用しようとする試みを示している可能性があります。

まずはポリシーの作成から始められます:

resource "sysdig_secure_custom_policy""terminal_shell_in_container" {
  depends_on = [sysdig_secure_rule_falco.terminal_shell_in_container]
  name = "Terminal shell in container"  description = "Detected a terminal shell being open within a container"  severity = 4  enabled = true
  actions {
    capture {
      name = "terminal-shell.scap"      seconds_before_event = 5      seconds_after_event = 10    }
  }
}

ポリシー全体を定義しましたが、ポリシーはルールの束に追加の振る舞いを付与したものにすぎません。この例では、イベント前後のすべてのsyscallをキャプチャしています。これ単体では何も検知しないため、ルール（または複数のルール）を与える必要があります。

ルール

Falcoルール構文に従い、TerraformでSysdig Secureにカスタムルールを作成できます。Falcoはシステムコールデータを活用して、不審なアクティビティを高精度に検知します。このケースでは、コンテナ内でターミナルシェルが開かれることを検知するカスタムルールを作成します。現時点で構文を理解する必要はありません。Sysdigはすでに1400以上のルールを提供しているため、デフォルトのものを参照して独自のルールを作成できます。

resource "sysdig_secure_rule_falco""terminal_shell_in_container" {
  name        = "Terminal shell in container"// ID  description = "A shell was used as the entrypoint/exec point into a container with an attached terminal."  tags        = ["container", "shell"]

  condition = "(evt.type in (execve, execveat) and evt.dir=<) and (container.id != host) and (proc.name in (ash, bash, csh, ksh, sh, tcsh, zsh, dash))"  output    = "A shell was spawned in a container with an attached terminal (user=%user.name %container.info shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty container_id=%container.id image=%container.image.repository)"  priority  = "notice"  source    = "syscall"}

ご覧のとおり、ルールのconditionは複数のFalcoフィールドイベントを指定しており、望むほど読みやすくない場合があります。さらに、変更が必要になるたびに、そのロジックを再解釈しなければなりません。また、検知対象のシェルがルール内にハードコードされている点も、改善の余地があります。

ここでFalcoの listsとmacrosという概念が役立ちます。