Gestiona tu pila de seguridad Elastic como código con el proveedor Elastic Stack Terraform

El proveedor de Elastic Stack Terraform alcanzó un hito importante. A partir de la versión v0.13.1, puedes gestionar tu postura de seguridad de Elastic —reglas de detección, listas de excepciones y reglas predefinidas— junto con trabajos de detección de anomalías de ML, monitores sintéticos y conectores de IA, todo como código.

Esto reúne tu lógica de detección y los trabajos de ML en el mismo flujo de trabajo versionado y revisado por pares que tus clústeres principales. Garantiza que tu postura de seguridad y los conectores de IA ya no sean casos atípicos manuales en un entorno automatizado.

El reto: Seguridad y configuración de observabilidad a gran escala

A medida que crecen los despliegues de Elastic, también lo hace la complejidad de gestionarlos. Los equipos de seguridad mantienen cientos de reglas de detección. Los SRES configuran la monitorización en decenas de clústeres. Los ingenieros de ML ajustan los trabajos de detección de anomalías en múltiples entornos. Todas estas configuraciones deben ser consistentes, auditables y reproducibles.

Sin infraestructura como código, los equipos se enfrentan a dos problemas:

1. Deriva de configuración. Las reglas, políticas y monitores se crean manualmente a través de la interfaz Kibana. Con el tiempo, la producción y la puesta en escena divergen. Nadie sabe qué versión de una regla de detección se ejecuta y en cada lugar.

2. Historial de auditoría enterrado. Cuando cambia una regla de detección o se agrega una excepción, no hay pull request que revisar, ni historial de commit que rastrear, ni ruta de rollback si algo falla. Los usuarios deben esforzar aún más para acceder a ese historial.

El proveedor Elastic Stack Terraform soluciona esto integrando estas configuraciones en el mismo flujo de trabajo revisado por versiones y revisado por pares que los equipos ya emplean para infraestructura.

Artefactos de seguridad como código: reglas de detección, excepciones y reglas predefinidas

Ahora puedes gestionar todo el ciclo de vida de las reglas de detección de Elastic Security a través de Terraform.

Reglas de detección

El recurso elasticstack_kibana_security_detection_rule te permite definir, versionar y desplegar reglas de detección en el formato HashiCorp Configuration Language (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"]
}

Esto significa que tus reglas de detección están en Git, pasan por revisión de código y se despliegan de forma consistente entre los entornos. Ya no hay que hacer clic en la interfaz de Kibana para replicar las reglas desde la puesta en escena hasta la producción.

Documentos de recursos de reglas de detección

Listas y elementos de excepciones

La historia de la seguridad como código se extiende a un conjunto completo de recursos de gestión de excepciones:

• elasticstack_kibana_security_exception_list - Crear y gestionar listas de excepciones
• elasticstack_kibana_security_exception_item - Definir elementos de excepción individuales dentro de una lista
• elasticstack_kibana_security_list y elasticstack_kibana_security_list_item - Gestionar listas de valores para listas de licencias de IP, hashes de archivos y otros indicadores
• elasticstack_kibana_security_list_data_streams - Asociar listas con flujos de datos específicos

Aquí tienes un ejemplo que los une: una lista de excepciones con elementos que suprimen falsos positivos conocidos para una regla de detección:

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"]
}

La lista de excepciones y sus elementos están enlazados por list_id, por lo que Terraform gestiona automáticamente el grafo de dependencias. Agregar un nuevo escáner autorizado es una línea de PR: no hay que hacer clic en la interfaz de Kibana, ni riesgo de olvidar qué entorno recibió la actualización.

Reglas de seguridad predefinidas

El recurso elasticstack_kibana_prebuilt_rule te permite gestionar las reglas de detección preconfiguradas de Elastic a través de Terraform. Esto es especialmente valioso para las organizaciones que necesitan hacer un seguimiento de qué reglas predefinidas están habilitadas, personalizar sus parámetros y garantizar un despliegue consistente entre entornos.

Detección de anomalías en aprendizaje automático como código

La detección de anomalías por aprendizaje automático es una de las capacidades más poderosas de Elasticsearch, pero gestionar trabajos de ML en diferentes entornos fue tradicionalmente un proceso manual. Creas un trabajo en la interfaz Kibana, ajustas los detectores, configuras el flujo de datos y esperas que alguien documente los ajustes para que puedan replicar en el siguiente entorno.

El recurso elasticstack_elasticsearch_ml_anomaly_detection_job cambia eso. Ahora puedes definir la configuración completa de un trabajo de detección de anomalías en HCL —detectores, cubos de contenido, influencers, fuentes de datos y límites de análisis— y desplegarla de forma consistente en desarrollo, staging y producción.

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"
  }
}

Esto es importante para los equipos que dependen del aprendizaje automático para detectar anomalías de infraestructura, comportamientos inusuales de los usuarios o amenazas de seguridad. En lugar de recrear manualmente los trabajos al crear nuevos clústeres o recuperar de fallos, toda la configuración de ML está en control de versiones: revisable, repetible y recuperable.

Automatización entre clústeres con claves API

Para organizaciones que ejecutan múltiples clústeres Elasticsearch, el proveedor ahora soporta claves API de clúster para búsqueda entre clústeres (CCS) y replicación entre clústeres (CCR). Puedes crear claves API diseñadas específicamente para la comunicación segura entre clústeres, permitiendo la automatización de extremo a extremo de arquitecturas multiclúster.

Esto significa que puedes provisionar dos clústeres, configurar CCS/CCR entre ellos y configurar las credenciales de seguridad necesarias, todo en una única configuración de 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"
  })
}

Cuando el type se configura como cross_cluster, la clave API se asigna a operaciones CCS/CCR. Defines qué patrones de índice son accesibles para búsqueda y replicación, estableces una política de caducidad y etiquetas la clave con metadatos, todo revisable en una solicitud pull.

Aprende más sobre los recursos clave de la API en la documentación.

Conectores de IA como código

El proveedor ahora soporta conectores .bedrock y .gen-ai , incorporando la infraestructura de IA a tus flujos de trabajo de Terraform. A medida que los equipos integran cada vez más grandes modelos de lenguaje en sus flujos de trabajo de Elastic —para asistentes de IA, detección de ataques e investigaciones automatizadas—, gestionar estas configuraciones de conectores como código se vuelve esencial.

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
  })
}

Con estos conectores definidos en Terraform, puedes versionar tu configuración de integración de IA junto con el resto de tu infraestructura Elastic, y cambiar modelos o proveedores mediante una simple comunicación pública.

Mejoras de observabilidad

Monitores sintéticos

El recurso elasticstack_kibana_synthetics_monitor ahora incluye un campo labels , lo que permite una mejor organización y filtrado de las comprobaciones sintéticas. Las etiquetas permiten etiquetar monitores por equipo, entorno o servicio, facilitando la gestión de la monitorización sintética a gran escala.

Mejoras adicionales en las plataformas

Las publicaciones recientes también incluyeron varios recursos y atributos que completan la cobertura del proveedor:

• elasticstack_elasticsearch_alias - Gestionar los alias de Elasticsearch como un recurso dedicado
• elasticstack_kibana_default_data_view - Establecer la vista de datos predeterminada para un espacio Kibana
• solution atributo en elasticstack_kibana_space - Configurar el tipo de solución para los espacios Kibana (disponible desde la versión 8.16)
• Mejoras en la política de agentes de flota - host_name_format para configurar nombre de host frente a FQDN, y required_versions para fijar versiones

Cómo empezar

Si ya usas el proveedor Elastic Stack Terraform, actualiza a la última versión del proveedor para obtener todas estas capacidades:

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

Si eres nuevo gestionando tu Elastic Stack con Terraform, empieza con la documentación del proveedor en el registro de Terraform.

Para empezar a usar Elastic Cloud hoy mismo, inicia sesión en la consola de Elastic Cloud o regístrate para una prueba gratis.
Para ver el conjunto completo de cambios, consulta las notas de lanzamiento en GitHub.