Omer Kushmaro

Gérez votre pile de sécurité Elastic en tant que code avec le fournisseur Elastic Stack Terraform

Des règles de détection aux connecteurs d'IA, les dernières versions des fournisseurs Terraform apportent des capacités de sécurité, d'observabilité et de ML à vos flux de travail d'infrastructure en tant que code.

5 minutes de lectureProduct Updates, Enablement
Gérez votre pile de sécurité Elastic en tant que code avec le fournisseur Elastic Stack Terraform

Le fournisseur Elastic Stack Terraform a franchi une étape importante. À partir de la version v0.13.1, vous pouvez gérer votre posture de sécurité Elastic - règles de détection, listes d'exceptions et règles prédéfinies - avec des tâches de détection d'anomalies ML, des moniteurs synthétiques et des connecteurs d'IA, le tout en tant que code.

Ainsi, votre logique de détection et vos tâches de ML sont intégrées dans le même flux de travail versionné et examiné par les pairs que vos grappes de base. Il garantit que votre posture de sécurité et vos connecteurs d'IA ne sont plus des aberrations manuelles dans un environnement par ailleurs automatisé.

Le défi : configuration de la sécurité et de l'observabilité à grande échelle

La complexité de la gestion des déploiements élastiques s'accroît au fur et à mesure que ceux-ci se développent. Les équipes de sécurité gèrent des centaines de règles de détection. Les SRE configurent la surveillance sur des dizaines de clusters. Les ingénieurs ML mettent au point des tâches de détection d'anomalies dans des environnements multiples. Toutes ces configurations doivent être cohérentes, vérifiables et reproductibles.

Sans l'infrastructure en tant que code, les équipes sont confrontées à deux problèmes :

  1. Dérive de configuration. Les règles, les politiques et les moniteurs sont créés manuellement via l'interface utilisateur Kibana. Au fil du temps, la production et la mise en scène divergent. Personne ne sait exactement quelle version d'une règle de détection s'exécute à quel endroit.

  2. Piste d'audit enfouie. Lorsqu'une règle de détection est modifiée ou qu'une exception est ajoutée, il n'y a pas de demande d'extension à examiner, pas d'historique des livraisons à retracer et pas de voie de retour en arrière si quelque chose ne fonctionne pas. Les utilisateurs doivent faire des efforts supplémentaires pour accéder à cet historique.

Le fournisseur Elastic Stack Terraform résout ce problème en intégrant ces configurations dans le même flux de travail contrôlé par les versions et revu par les pairs que les équipes utilisent déjà pour l'infrastructure.

Les artefacts de sécurité en tant que code : Règles de détection, exceptions et règles préconstruites

Vous pouvez désormais gérer le cycle de vie complet des règles de détection d'Elastic Security via Terraform.

Règles de détection

La ressource elasticstack_kibana_security_detection_rule vous permet de définir, de modifier et de déployer des règles de détection au format 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"]
}

Cela signifie que vos règles de détection sont stockées dans Git, qu'elles font l'objet d'une révision du code et qu'elles sont déployées de manière cohérente dans tous les environnements. Plus besoin de cliquer sur l'interface utilisateur Kibana pour répliquer les règles de la phase d'essai à la phase de production.

Documentation sur les règles de détection

Listes et postes d'exception

L'histoire de la sécurité en tant que code s'étend à une suite complète de ressources de gestion des exceptions :

  • elasticstack_kibana_security_exception_list - Créer et gérer des listes d'exceptions
  • elasticstack_kibana_security_exception_item - Définir des éléments d'exception individuels dans une liste
  • elasticstack_kibana_security_list et elasticstack_kibana_security_list_item - Gérer les listes de valeurs pour les listes d'adresses IP, les hachages de fichiers et d'autres indicateurs
  • elasticstack_kibana_security_list_data_streams - Associer des listes à des flux de données spécifiques

Voici un exemple qui les associe : une liste d'exceptions contenant des éléments qui suppriment les faux positifs connus d'une règle de détection :

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 liste d'exceptions et ses éléments sont liés par list_id, de sorte que Terraform gère automatiquement le graphe de dépendances. L'ajout d'un nouveau scanner autorisé se fait en une seule ligne - pas de clic dans l'interface utilisateur de Kibana, pas de risque d'oublier quel environnement a reçu la mise à jour.

Règles de sécurité prédéfinies

La ressource elasticstack_kibana_prebuilt_rule vous permet de gérer les règles de détection préconstruites d'Elastic via Terraform. Ceci est particulièrement utile pour les organisations qui ont besoin de suivre les règles prédéfinies qui sont activées, de personnaliser leurs paramètres et d'assurer un déploiement cohérent dans tous les environnements.

Détection d'anomalies par ML sous forme de code

La détection d'anomalies par apprentissage automatique est l'une des fonctionnalités les plus puissantes d'Elasticsearch, mais la gestion des tâches d'apprentissage automatique dans les différents environnements est traditionnellement un processus manuel. Vous créez une tâche dans l'interface utilisateur Kibana, vous réglez les détecteurs, vous configurez le flux de données et vous espérez que quelqu'un documente les paramètres afin qu'ils puissent être reproduits dans l'environnement suivant.

La ressource elasticstack_elasticsearch_ml_anomaly_detection_job change la donne. Vous pouvez désormais définir la configuration complète d'une tâche de détection d'anomalie dans HCL - détecteurs, plages de seaux, influenceurs, flux de données et limites d'analyse - et la déployer de manière cohérente dans les phases de développement, de mise en place et de production.

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

Cela est important pour les équipes qui s'appuient sur la ML pour détecter les anomalies de l'infrastructure, les comportements inhabituels des utilisateurs ou les menaces de sécurité. Au lieu de recréer manuellement des tâches lors de la mise en place de nouveaux clusters ou de la reprise après une défaillance, l'ensemble de la configuration ML se trouve sous contrôle de version - elle est révisable, reproductible et récupérable.

Automatisation entre clusters à l'aide de clés API

Pour les organisations qui utilisent plusieurs clusters Elasticsearch, le fournisseur prend désormais en charge les clés API de cluster pour la recherche cross-cluster (CCS) et la réplication cross-cluster (CCR). Vous pouvez créer des clés API spécialement conçues pour des communications sécurisées entre clusters, ce qui permet une automatisation de bout en bout des architectures multi-clusters.

Cela signifie que vous pouvez provisionner deux clusters, configurer CCS/CCR entre eux et mettre en place les identifiants de sécurité nécessaires, le tout dans une seule configuration 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"
  })
}

Lorsque type est défini sur cross_cluster, la clé API est limitée aux opérations CCS/CCR. Vous définissez quels modèles d'index sont accessibles pour la recherche et la réplication, vous établissez une politique d'expiration et vous marquez la clé avec des métadonnées - le tout pouvant être révisé dans une demande d'extraction.

Pour en savoir plus sur les ressources de clés API, consultez la documentation.

Connecteurs d'IA sous forme de code

Le fournisseur prend désormais en charge les connecteurs .bedrock et .gen-ai, ce qui permet d'intégrer l'infrastructure d'IA dans vos flux de travail Terraform. Alors que les équipes intègrent de plus en plus de grands modèles de langage dans leurs workflows Elastic - pour les assistants IA, la découverte d'attaques et les enquêtes automatisées - la gestion de ces configurations de connecteurs en tant que code devient essentielle.

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

Avec ces connecteurs définis dans Terraform, vous pouvez versionner votre configuration d'intégration de l'IA avec le reste de votre infrastructure Elastic - et changer de modèle ou de fournisseur par le biais d'un simple PR.

Amélioration de l'observabilité

Moniteurs synthétiques

La ressource elasticstack_kibana_synthetics_monitor comprend désormais un champ labels, ce qui permet d'améliorer l'organisation et le filtrage des contrôles synthétiques. Les étiquettes vous permettent de marquer les moniteurs par équipe, environnement ou service, ce qui facilite la gestion de la surveillance synthétique à l'échelle.

Améliorations supplémentaires de la plate-forme

Les versions récentes ont également inclus plusieurs ressources et attributs qui complètent la couverture du fournisseur :

  • elasticstack_elasticsearch_alias - Gérer les alias Elasticsearch comme une ressource dédiée
  • elasticstack_kibana_default_data_view - Définir la vue des données par défaut pour un espace Kibana
  • solution attribut sur elasticstack_kibana_space - Configurer le type de solution pour les espaces Kibana (disponible à partir de la version 8.16)
  • Amélioration de la politique des agents de la flotte - host_name_format pour la configuration du nom d'hôte par rapport au FQDN, et required_versions pour l'épinglage des versions

Premiers pas

Si vous utilisez déjà le fournisseur Elastic Stack Terraform, passez à la dernière version du fournisseur pour bénéficier de toutes ces fonctionnalités :

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

Si vous êtes novice dans la gestion de votre pile Elastic avec Terraform, commencez par consulter la documentation sur les fournisseurs dans le registre Terraform.

Pour commencer à utiliser Elastic Cloud dès aujourd'hui, connectez-vous à la console Elastic Cloud ou inscrivez-vous à un essai gratuit.
Pour connaître l'ensemble des changements, consultez les notes de version sur GitHub.

Partager cet article