Elastic Stack Terraform 공급자를 통해 코드 형태로 Elastic 보안 스택 관리

Elastic Stack Terraform 공급자가 중요한 이정표에 도달했습니다. 릴리즈 v0.13.1부터는 탐지 규칙, 예외 목록, 사전 구축된 규칙 등 Elastic 보안 태세를 ML 이상 징후 탐지 작업, 합성 모니터, AI 커넥터와 함께 모두 코드로 관리할 수 있습니다.

이렇게 하면 탐지 로직과 ML 작업이 핵심 클러스터와 동일한 버전으로 동료 검토를 거친 워크플로로 전환됩니다. 이를 통해 보안 태세와 AI 커넥터가 더 이상 자동화된 환경에서 수동으로 이상 징후를 발견하지 않도록 보장합니다.

과제: 대규모 보안 및 통합 가시성 구성

Elastic 배포가 증가함에 따라 관리의 복잡성도 증가하고 있습니다. 보안팀은 수백 가지의 탐지 규칙을 관리합니다. SRE는 수십 개의 클러스터에서 모니터링을 구성합니다. ML 엔지니어는 여러 환경에서 이상 징후 탐색 작업을 조정합니다. 이러한 모든 구성은 일관성 있고 감사 가능하며 재현 가능해야 합니다.

코드화된 인프라가 없으면 팀은 두 가지 문제에 직면하게 됩니다:

구성 드리프트. 규칙, 정책, 모니터는 Kibana UI를 통해 수동으로 생성됩니다. 시간이 지남에 따라 프로덕션과 스테이징은 서로 다릅니다. 어느 버전의 탐지 규칙이 어디에서 실행되고 있는지 아무도 확신할 수 없습니다.
매몰 감사 추적. 탐지 규칙이 변경되거나 예외가 추가되면 검토할 풀 리퀘스트도 없고, 추적할 커밋 기록도 없으며, 문제가 발생해도 롤백 경로가 없습니다. 사용자는 이러한 기록에 액세스하기 위해 추가적인 노력을 기울여야 합니다.

Elastic Stack Terraform 공급자는 이러한 구성을 팀이 이미 인프라에 사용하고 있는 것과 동일한 버전 제어, 동료 검토 워크플로우로 가져와서 이 문제를 해결합니다.

코드로서의 보안 아티팩트: 탐지 규칙, 예외 및 미리 빌드된 규칙

이제 Terraform을 통해 Elastic Security 탐지 규칙의 전체 수명 주기를 관리할 수 있습니다.

탐지 규칙

elasticstack_kibana_security_detection_rule 리소스에서 해시코프 구성 언어 (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은 종속성 그래프를 자동으로 관리합니다. 새로운 승인된 스캐너를 추가하는 것은 한 줄의 홍보로 이루어지며, Kibana UI를 클릭할 필요도 없고 어떤 환경이 업데이트를 받았는지 잊어버릴 위험도 없습니다.

사전 구축된 보안 규칙

elasticstack_kibana_prebuilt_rule 리소스를 통해 Terraform을 통해 Elastic의 사전 구축된 탐지 규칙을 관리할 수 있습니다. 이는 어떤 사전 구축된 규칙이 활성화되어 있는지 추적하고, 해당 매개변수를 사용자 지정하며, 여러 환경에 걸쳐 일관된 배포를 보장해야 하는 조직에 특히 유용합니다.

코드로서의 ML 이상 징후 탐지

머신 러닝 이상 징후 탐색은 Elasticsearch의 가장 강력한 기능 중 하나이지만, 환경 전반에서 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 키를 생성하여 멀티클러스터 아키텍처의 엔드투엔드 자동화를 구현할 수 있습니다.

즉, 두 개의 클러스터를 프로비저닝하고, 클러스터 간에 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 인프라를 도입합니다. 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에서 릴리스 노트를 확인하세요.

Elastic Stack Terraform 공급자를 사용하여 코드 형태로 Elastic 보안 스택 관리하기