Sysdig Secureにおけるカスタムコントロールの作り方

本文の内容は、2024年10月16日に ashish chakrabortty が投稿したブログ(https://sysdig.com/blog/how-to-build-custom-controls-in-sysdig-secure/)を元に日本語に翻訳・再構成した内容となっております。

クラウドセキュリティポスチャ管理 (CSPM)のコンテキストでは、カスタムコントロールとは、セキュリティチームがポリシーを柔軟に作成および適用できるようにするポリシーまたはルールです。これらは、ポスチャーを管理し、コンプライアンス対策を調整し、Kubernetes、コンテナ、クラウドなどのインフラストラクチャー全体で構成ミスを検出するために必要です。

Sysdigカスタムコントロールの紹介

Sysdig ポスチャーコントロールは、OPA ポリシー言語Regoを使用して、 Open Policy Agent (OPA) エンジン上に構築されます。プラットフォームは、これらのコントロールを作成するために使用されるコードと、それらが評価する入力を公開します。

これらのコントロールは、Sysdig のPosture Controlsライブラリで利用できます。重大度やポリシーなどの基本的な属性が事前に定義されています。以前は、既存のコントロールを複製して特定のラベルをカスタマイズすることしかできませんでした。

Sysdig の新しいカスタムコントロール機能は、AWS、Azure、GCP、IBM などの主要なクラウドサービスプロバイダーで利用できます。企業はこの機能を使用して次のことを行うことができます。

アーキテクチャーとビジネス要件に密接に適合した内部ガイドラインコントロールを定義し、実施する
PCIやHIPAAなどの規制コンプライアンス基準を満たす
Kubernetes、コンテナ、クラウド環境全体でセキュリティの誤った構成を防ぐ

引き続きお読みいただき、次の内容を学びましょう：

Rego を使用してカスタムコントロールを作成します。
SysdigのTerraformプロバイダーで管理およびデプロイする
新しいSysdig APIエンドポイントを使用する
Rego Playgroundを使用してRegoコードを確認する

Regoでカスタムコントロールを作成する

Sysdig Secure の Terraform プロバイダーを使用すると、インフラストラクチャー自動化の一環としてカスタムコントロールを定義、管理、およびデプロイできます。これにより、セキュリティポリシーがバージョン管理され、簡単に保守でき、環境間で一貫性を保つことができます。

始める前に

環境に Terraform と Go の両方がインストールされていることを確認します。

Terraformバージョン 0.12.x 以上
go.modで指定されているバージョンよりも高いGoバージョン (ここの指示に従って $GOPATH を設定してください)
Sysdig 用の Terraform プロバイダー (プロバイダーのインストールと構成については、こちらの手順を参照してください)
Sysdig API トークンとエージェントキー(以下のコードスニペットでこれらの値を置き換えます)

Sysdig Secureによるカスタムコントロール — 図: ワークステーション上の Terraform と Go のバージョン

terraform {

  required_providers {

    sysdig = {

      source = "local/sysdiglabs/sysdig"

      version = "~> 1.0.0"

    }

  }

}

provider "sysdig" {

  sysdig_secure_url="https://secure.sysdig.com"

  sysdig_secure_api_token = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX"

  extra_headers = {

    "Proxy-Authorization": "Basic XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

  }

}

カスタムコントロール用の Terraform リソース

Sysdig Secure の Terraform プロバイダーは、sysdig_secure_posture_control リソースを使用してカスタムコントロールを定義します。リソース属性には次のものが含まれます。

name : カスタムコントロールの名前
description: コントロールの機能の詳細な説明
resource_kind : コントロールが適用されるリソースの種類 (例: AWS S3 バケット、Kubernetes ポッド)
severity度: コントロールの重要性を定義する重大度レベル (例: High, Medium, Low)
rego : コントロールロジックを定義するRegoポリシーコード
remediation_details : コントロールによって特定された問題を修復するための手順

次に、Rego と Terraform を使用してカスタム Sysdig Secure カスタムコントロールを作成します。

バージョン管理なしの S3 バケット

S3 バケットのバージョン管理は、特にデータの保護、回復、管理など、いくつかの理由で重要です。このシナリオでは、Amazon S3 バケットでオブジェクトのバージョン管理が有効になっていることを確認し、上書きされたオブジェクトや削除されたオブジェクトを保存および回復するためのカスタムコントロールを作成します。

こちらのリポジトリからgitファイルをダウンロードして解凍してください
フォルダ内でterraform-provider-sysdig-master、お気に入りのエディタを使用して新しいTerraformファイルを作成します。Visual Studioを使用していてVSCode拡張機能がインストールされている場合はボーナスポイントです。
以下のコードをコピーしてファイルに貼り付けます。RegoコードはTerraformスクリプト内に埋め込まれています。

resource "sysdig_secure_posture_control" "s3_bucket_without_versioning" {

  name = "S3 Bucket without versioning"

  description = "Ensure that S3 object versioning is enabled for your Amazon S3 buckets to protect and recover overwritten and deleted S3 objects."

  resource_kind = "AWS_S3_BUCKET"

  severity = "High"

  rego = <<-EOF

    package sysdig

    import future.keywords.if

    import future.keywords.in

    default risky := false

    # Control fails if no versioning configuration is found

    risky if {

      count(input.Versioning) == 0

    }

    # Control fails if versioning is not enabled

    risky if {

      some version in input.Versioning

      lower(version.Status) != "enabled"

    }

  EOF

  remediation_details = <<-EOF

## Remediation Impact
Enabling versioning for S3 buckets helps preserve and recover previous versions of objects. 
It allows recovery of deleted or overwritten data, and helps ensure data protection. 
Archiving previous versions to Amazon S3 Glacier is also possible for long-term, low-cost storage.

<code>## Remediate Using Command Line</code>
Run the following command to enable versioning for the selected bucket:

```

    aws s3api put-bucket-versioning --bucket <bucket-name> --versioning-configuration Status=Enabled

    ```

    Repeat this command for other buckets in your AWS environment.

  EOF

}

次に、ターミナルからTerraform環境を初期化します。前提条件が適切に構成されている場合は、以下のスナップショットのようなメッセージが表示されます。

環境が初期化された後、次のタスクは、この Terraform スクリプトを Sysdig Secure のカスタムコントロールとしてデプロイすることです。

terraform apply をターミナルから実行する

Terraform は、コードをデプロイするために何を行うかを記述した実行プランを生成し、それを実行して、記述されたインフラストラクチャまたは構成を構築します。

プロンプトはユーザー入力のために一時停止します。この段階で入力しyesて続行します。

図: Terraform プロバイダーがカスタムコントロールを Sysdig Secure にデプロイする

バージョン管理のない新しいカスタムコントロール S3 Bucket without versioning ライブラリに表示され、カスタムポリシーで使用できるようになります。Sysdig Secure ユーザーインターフェイスに移動して確認してください。

Navigate to Posture → Controls
S3 Bucket without versioning を検索する

図: Terraform Sysdig プロバイダーを使用して適用されたカスタムコントロール

カスタムコントロールを適用する

ここから、企業のニーズに基づいて、新しいカスタムコントロールを新規または既存の Sysdig Secure Posture ポリシーに割り当てることができます。以下の例は、次の手順に従って作成されました。

Posture → Policiesに移動し、Custom Controls_S3 Bucket without versioning という新しいポリシーを作成します。
新しいコントロールを適用するインフラストラクチャー範囲を選択します。この例では、Entire Infrastructureを使用します。
下の画像に示すようにカスタムコントロールをリンクして、定義したインフラストラクチャーのポスチャーコンプライアンスを評価します。

ロールバックするには、Terraform ファイルからリソース定義を削除して再適用するだけです。これにより、Posture Controls ライブラリが更新され、定義されたコントロールがポリシーから切り離されます。

少し準備が整ったので、開発ワークフローを効率化するために使用できるツールをいくつか見てみましょう。

Sysdig API エンドポイント

Sysdig APIエンドポイントは、開発者が resource_kind のようなTerraform属性の値をクエリして取得できる機能を提供します。REST APIは、Sysdig Monitor、Sysdig Secure、Sysdig Platformへのプログラム的なアクセスや管理を可能にします。

Sysdig APIエンドポイントでは、「Compliance」、「Cloud Organizations」、「CSPM」などのカテゴリヘッダーと共に、クエリパラメータの詳細が確認できます。例えば、Cloud Resourcesを取得するには、providerType、resourceKind、filterといったパラメータを定義し、GET request でクエリを実行する必要があります。さらに、APIエンドポイントでは、Go、Curl、Node、Java、Pythonなど複数の形式でカスタムクエリを生成することができます。

この演習では、Curlを使用してGET requestをAPIエンドポイントにクエリし、Terraform属性 resource_kind の値を取得します。

Sysdig APIトークンを自分の環境でエクスポートします（私の場合はMacOSです）。Windowsでエクスポートするには、こちらの手順をお読みください。
左側のパネルから CSPM を選択し、下にスクロールして Get Resource Kindsをクリックします (このリンクを使用できます)。
次に、Curlタブに切り替えて GET request をコピーします
その後、ターミナルウィンドウを開いて GET request を貼り付けます。Sysdig APIトークンなどの追加情報を入力します。

curl --request GET \

  --url https://secure.sysdig.com/api/cspm/v1/policy/controls/resource-template/kinds -H "Authorization: Bearer $SYSDIG_SECURE_API_TOKEN" | jq .resourceKinds

JSON 出力には、Sysdig Secure プラットフォーム内でクエリを実行できるすべての正当なリソースの種類のリストが提供されます。

Terraformスクリプトを振り返ると、 resource_kind を AWS_S3_Bucket として定義していました。

Sysdig APIエンドポイントで、Get Resource Exampleをクリックします。
前回と同様に、Curlを選択し、GET requestをコピーして、ターミナルに貼り付けてください。

新しいリクエストは以下のようになります。このリクエストは、AWS_S3_Bucket に関連するすべての値を取得します。

curl --request GET \

  --url https://secure.sysdig.com/api/cspm/v1/policy/controls/resource-template/view/AWS_S3_BUCKET -H "Authorization: Bearer $SYSDIG_SECURE_API_TOKEN" | jq -r .data | jq

この後、結果をコピーして保存します。これは、Rego コードを検証する演習の最後の段階で必要になります。

Regoプレイグラウンド

Rego Playground は、サンドボックス化されたブラウザベースのインターフェースで Rego ポリシーを記述、テスト、デバッグできるオンラインのインタラクティブ環境です。さまざまなシステムにわたるポリシーベースのコントロールを検討している方に最適です。

ブラウザベースのインターフェースは、Rego 式のリアルタイム評価、入出力シミュレーション、ポリシーテストなどの機能を提供するため、完全な Open Policy Agent (OPA) 環境をローカルにセットアップしなくても、ポリシーの学習、開発、共有を行うのに最適なツールとなります。

この演習では、プラットフォームを使用して、Terraform スクリプトで以前に定義した Rego コードロジックを評価します。前回の演習の JSON 出力は、入力変数として必要になります。

以下のコードスニペットをコピーしてエディターセクションに貼り付けます。必要に応じて、Formatをクリックしてコードを揃えます。

注意深く観察すると、ここでのロジックは、フィールドの値に基づいてオブジェクトをリスクがあると評価するものです。

package sysdig

import future.keywords.if

import future.keywords.in

default risky := false

# Control fails if no versioning configuration is found

risky if {

count(input.Versioning) == 0

}

# Control fails if versioning is not enabled

risky if {

some version in input.Versioning

lower(version.Status) != "enabled"

}
Code language: Perl (perl)

以前に保存したJSON出力をINPUTウィンドウに追加します。

フィールドVersioning.Statusは JSON 出力の下部に定義されています。現在は文字列に設定されていることに注意してください。

次に、Evaluate をクリックしてRegoスクリプトをテストします。

OUTPUTウィンドウでは、risky の値が true に設定されていることが確認できます。これにより、クラウドアカウントでバージョンステータスが有効になっていない場合、AWS S3バケットがリスクとしてタグ付けされると推測できます。

次に、Status フィールドを enabled に変更してください。

スクリプトを再度評価し、OUTPUTウィンドウで risky が false に変わることを確認してください。これにより、Regoロジックが正しく機能していることが証明されます。

上記の演習を実行するには、こちらのリンクを使用してください。

カスタムコントロールを実装するためのベストプラクティス

影響の大きいコントロールから始める: 特権コンテナのブロックや S3 のバージョン管理の確保など、重大なセキュリティリスクに対処するカスタムコントロールを優先します。
自動化には Terraform を使用します。Terraform を使用すると、カスタムコントロールをコードとして簡単に管理できるため、環境間で一貫性が確保され、コントロールの展開と更新を自動化できます。
ステージング環境でコントロールをテストする: カスタムコントロールが期待どおりに動作し、誤検知が発生しないことを確認するために、必ず非運用環境でカスタムコントロールをテストしてください。
コントロールを継続的に確認および更新する: インフラストラクチャーが進化するにつれて、新しいセキュリティ上の課題とコンプライアンス要件を反映するために、カスタムコントロールを定期的に確認および更新します。

まとめ

Sysdig Secureのカスタムコントロールは、組織のニーズに合わせたセキュリティポリシーを柔軟に適用できる機能を提供します。ポリシーロジックにはRegoを活用し、自動化にはTerraformを使用することで、クラウドおよびKubernetes環境全体で強力なセキュリティ対策を実装できます。S3バージョニングの確保や特権コンテナのブロックなど、これらのカスタムコントロールによって、一貫したセキュリティとコンプライアンスの基準を適用する力が得られます。

詳細情報と詳細な例については、以下を参照してください。