Elastic Stack Terraformプロバイダーを使用して、Elasticセキュリティスタックをコードとして管理します。

Elastic Stack Terraform プロバイダーは重要なマイルストーンに到達しました。リリース v0.13.1 以降では、ML 異常検出ジョブ、合成モニター、AI コネクタとともに、Elastic のセキュリティ体制 (検出ルール、例外リスト、事前構築済みルール) をすべてコードとして管理できます。

これにより、検出ロジックと ML ジョブが、コア クラスターと同じバージョン管理され、ピアレビューされたワークフローに組み込まれます。これにより、セキュリティ体制が確保され、AI コネクタが自動化された環境における手動の外れ値ではなくなります。

課題: 大規模なセキュリティと監視の構成

Elastic の導入が拡大するにつれて、管理の複雑さも増します。セキュリティ チームは何百もの検出ルールを管理しています。SRE は数十のクラスターにわたる監視を構成します。ML エンジニアは、複数の環境にわたって異常検出ジョブを調整します。これらの構成はすべて、一貫性があり、監査可能で、再現可能である必要があります。

インフラストラクチャをコードとして利用しないと、チームは次の 2 つの問題に直面します。

1. 構成のドリフト。ルール、ポリシー、モニターは、Kibana UI を通じて手動で作成されます。時間が経つにつれて、プロダクションとステージングは分岐します。検出ルールのどのバージョンがどこで実行されているかは誰にもわかりません。

2. 監査証跡が埋もれています。検出ルールが変更されたり、例外が追加されたりすると、確認するプル リクエストも、追跡するコミット履歴もなくなり、何かが壊れた場合のロールバック パスもなくなります。ユーザーは、そのような履歴にアクセスするには余分な労力を費やす必要があります。

Elastic Stack Terraform プロバイダーは、チームがインフラストラクチャに既に使用しているバージョン管理されたピアレビュー済みのワークフローにこれらの構成を組み込むことで、この問題を解決します。

コードとしてのセキュリティ アーティファクト: 検出ルール、例外、および事前構築されたルール

Elastic Security 検出ルールのライフサイクル全体を Terraform を通じて管理できるようになりました。

検出ルール

elasticstack_kibana_security_detection_ruleリソースを使用すると、 HashiCorp 構成言語(HCL) 形式で検出ルールを定義、バージョン管理、およびデプロイできます。

resource "elasticstack_kibana_security_detection_rule" "suspicious_admin_logon" {
  name        = "Suspicious Admin Logon Activity"
  type        = "query"
  query       = "event.action:logon AND user.name:admin"
  language    = "kuery"
  enabled     = true
  description = "Detects suspicious admin logon activities"
  severity    = "high"
  risk_score  = 75
  from        = "now-6m"
  to          = "now"
  interval    = "5m"
  tags        = ["security", "authentication", "admin"]
}

つまり、検出ルールは Git に保存され、コードレビューを受け、環境間で一貫して展開されます。ステージングから本番環境にルールを複製するために Kibana UI をクリックする必要がなくなりました。

検出ルールのリソースドキュメント

例外リストと項目

コードとしてのセキュリティのストーリーは、例外管理リソースの完全なスイートにまで拡張されます。

• elasticstack_kibana_security_exception_list - 例外リストの作成と管理
• elasticstack_kibana_security_exception_item - リスト内の個別の例外項目を定義する
• elasticstack_kibana_security_list およびelasticstack_kibana_security_list_item - IP 許可リスト、ファイルハッシュ、その他のインジケーターの値リストを管理します
• elasticstack_kibana_security_list_data_streams - リストを特定のデータストリームに関連付ける

これらを結び付ける例として、検出ルールの既知の誤検知を抑制する項目を含む例外リストを以下に示します。

resource "elasticstack_kibana_security_exception_list" "vuln_scanner_exceptions" {
  list_id        = "vuln-scanner-exceptions"
  name           = "Vulnerability Scanner Exceptions"
  description    = "Suppress alerts from authorized vulnerability scanners"
  type           = "detection"
  namespace_type = "single"
  tags           = ["security", "vulnerability-scanning"]
}

resource "elasticstack_kibana_security_exception_item" "nessus_scanner" {
  list_id        = elasticstack_kibana_security_exception_list.vuln_scanner_exceptions.list_id
  item_id        = "nessus-scanner"
  name           = "Nessus Scanner - Authorized"
  description    = "Suppress alerts from authorized Nessus scanner hosts"
  type           = "simple"
  namespace_type = "single"

  entries = [
    {
      type     = "match"
      field    = "source.ip"
      operator = "included"
      value    = "10.0.50.10"
    },
    {
      type     = "match_any"
      field    = "process.name"
      operator = "included"
      values   = ["nessus", "nessusd"]
    }
  ]

  tags = ["nessus", "authorized-scanner"]
}

resource "elasticstack_kibana_security_exception_item" "qualys_scanner" {
  list_id        = elasticstack_kibana_security_exception_list.vuln_scanner_exceptions.list_id
  item_id        = "qualys-scanner"
  name           = "Qualys Scanner - Authorized"
  description    = "Suppress alerts from authorized Qualys scanner subnet"
  type           = "simple"
  namespace_type = "single"

  entries = [
    {
      type     = "match"
      field    = "source.ip"
      operator = "included"
      value    = "10.0.51.0/24"
    }
  ]

  tags = ["qualys", "authorized-scanner"]
}

例外リストとその項目はlist_idによってリンクされているため、Terraform は依存関係グラフを自動的に管理します。新しい承認済みスキャナーの追加は 1 行の PR です。Kibana UI をクリックする必要がなく、どの環境で更新が行われたかを忘れるリスクもありません。

事前構築されたセキュリティルール

elasticstack_kibana_prebuilt_ruleリソースを使用すると、Elastic の事前構築された検出ルールを Terraform 経由で管理できます。これは、どの事前構築済みルールが有効になっているかを追跡し、そのパラメータをカスタマイズし、環境間で一貫した展開を確保する必要のある組織にとって特に役立ちます。

コードとしてのML異常検出

機械学習の異常検出は Elasticsearch の最も強力な機能の 1 つですが、環境間での ML ジョブの管理は従来、手動のプロセスでした。Kibana UI でジョブを作成し、検出器を調整し、データフィードを設定し、誰かが設定を文書化して次の環境で複製できるようにしてくれることを期待します。

elasticstack_elasticsearch_ml_anomaly_detection_jobリソースによってそれが変わります。異常検出ジョブの完全な構成 (検出器、バケット スパン、インフルエンサー、データ フィード、分析制限) を HCL で定義し、開発、ステージング、本番環境全体で一貫してデプロイできるようになりました。

resource "elasticstack_elasticsearch_ml_anomaly_detection_job" "cpu_anomalies" {
  job_id      = "high-cpu-by-host"
  description = "Detect unusual CPU usage patterns"

  analysis_config = {
    bucket_span = "15m"
    detectors   = [{
      function   = "high_mean"
      field_name = "system.cpu.user_pct"
    }]
    influencers = ["host.name"]
  }

  data_description = {
    time_field = "@timestamp"
  }
}

これは、インフラストラクチャの異常、異常なユーザー行動、またはセキュリティの脅威を検出するために ML に依存するチームにとって重要です。新しいクラスターを起動するときや障害から回復するときにジョブを手動で再作成する代わりに、ML 構成全体がバージョン管理され、確認、繰り返し、回復が可能になります。

APIキーを使用したクラスタ間自動化

複数の Elasticsearch クラスターを実行している組織の場合、プロバイダーは、クラスター間検索 (CCS) とクラスター間レプリケーション (CCR) 用のクラスター API キーをサポートするようになりました。安全なクラスター間通信用に特別に設計された API キーを作成し、マルチクラスター アーキテクチャのエンドツーエンドの自動化を実現できます。

つまり、2 つのクラスターをプロビジョニングし、それらのクラスター間で CCS/CCR を構成し、必要なセキュリティ資格情報をすべて単一の Terraform 構成で設定できるということです。

resource "elasticstack_elasticsearch_security_api_key" "ccs_key" {
  name = "cross-cluster-search-key"
  type = "cross_cluster"

  access = {
    search = [{
      names = ["logs-*", "metrics-*"]
    }]
    replication = [{
      names = ["archive-*"]
    }]
  }

  expiration = "90d"

  metadata = jsonencode({
    environment = "production"
    purpose     = "ccs-ccr-between-prod-clusters"
    team        = "platform"
  })
}

typeがcross_clusterに設定されている場合、API キーの範囲は CCS/CCR 操作に限定されます。検索とレプリケーションにアクセスできるインデックス パターンを定義し、有効期限ポリシーを設定し、キーにメタデータをタグ付けします。これらはすべてプル リクエストで確認できます。

ドキュメントでAPI キー リソースの詳細を確認してください。

AIコネクタをコードとして

プロバイダーは現在、 .bedrockおよび.gen-aiコネクタをサポートしており、AI インフラストラクチャを Terraform ワークフローに組み込んでいます。AI アシスタント、攻撃検出、自動調査などの目的で、チームが大規模な言語モデルを Elastic ワークフローに統合することが増えるにつれ、これらのコネクタ構成をコードとして管理することが不可欠になります。

resource "elasticstack_kibana_action_connector" "bedrock" {
  name              = "aws-bedrock"
  connector_type_id = ".bedrock"
  config = jsonencode({
    apiUrl       = "https://bedrock-runtime.us-east-1.amazonaws.com"
    defaultModel = "anthropic.claude-v2"
  })
  secrets = jsonencode({
    accessKey = var.aws_access_key
    secret    = var.aws_secret_key
  })
}

resource "elasticstack_kibana_action_connector" "openai" {
  name              = "openai"
  connector_type_id = ".gen-ai"
  config = jsonencode({
    apiProvider  = "OpenAI"
    apiUrl       = "https://api.openai.com/v1/chat/completions"
    defaultModel = "gpt-4"
  })
  secrets = jsonencode({
    apiKey = var.openai_api_key
  })
}

Terraform で定義されたこれらのコネクタを使用すると、Elastic インフラストラクチャの残りの部分と一緒に AI 統合構成のバージョンを管理し、簡単な PR を通じてモデルやプロバイダーを交換できます。

可観測性の強化

合成モニター

elasticstack_kibana_synthetics_monitorリソースにlabelsフィールドが追加され、合成チェックの整理とフィルタリングがより適切に行えるようになりました。ラベルを使用すると、チーム、環境、またはサービスごとにモニターにタグを付けることができるため、大規模な合成モニタリングの管理が容易になります。

プラットフォームの追加改善

最近のリリースには、プロバイダーの対象範囲を補完するいくつかのリソースと属性も含まれています。

• elasticstack_elasticsearch_alias - Elasticsearchエイリアスを専用リソースとして管理する
• elasticstack_kibana_default_data_view - Kibanaスペースのデフォルトのデータビューを設定する
• solution elasticstack_kibana_space属性 - Kibana スペースのソリューション タイプを設定します (8.16 から利用可能)
• フリート エージェント ポリシーの強化 - ホスト名と FQDN の構成についてはhost_name_format 、バージョン固定についてはrequired_versions

開始する

すでに Elastic Stack Terraform プロバイダーを使用している場合は、最新のプロバイダー バージョンにアップグレードして、次のすべての機能を利用できるようになります。

terraform {
  required_providers {
    elasticstack = {
      source  = "elastic/elasticstack"
      version = "~> 0.14"
    }
  }
}

Terraform を使用して Elastic Stack を管理するのが初めての場合は、まず Terraform レジストリのプロバイダーのドキュメントを参照してください。

今すぐ Elastic Cloud を使い始めるには、 Elastic Cloud コンソールにログインするか、無料トライアルにサインアップしてください。
変更点の全容については、 GitHub のリリース ノートをご覧ください。