Der Elastic Stack Terraform-Provider hat einen bedeutenden Meilenstein erreicht. Ab Version v0.13.1 können Sie Ihre Elastic-Sicherheitslage – Erkennungsregeln, Ausnahmelisten und vordefinierte Regeln – zusammen mit ML-Anomalieerkennungsjobs, synthetischen Monitoren und KI-Konnektoren alles als Code verwalten.
Dadurch werden Ihre Erkennungslogik und ML-Jobs in denselben versionierten, von Experten begutachteten Workflow wie Ihre Kerncluster integriert. Es stellt sicher, dass Ihre Sicherheitslage und KI-Konnektoren keine manuellen Ausreißer mehr in einer ansonsten automatisierten Umgebung darstellen.
Die Herausforderung: Sicherheits- und Überwachungskonfiguration im großen Maßstab
Mit dem Wachstum von Elastic-Bereitstellungen steigt auch die Komplexität ihrer Verwaltung. Sicherheitsteams pflegen Hunderte von Erkennungsregeln. SREs konfigurieren die Überwachung über Dutzende von Clustern hinweg. ML-Ingenieure optimieren Anomalieerkennungsprozesse in verschiedenen Umgebungen. Alle diese Konfigurationen müssen konsistent, nachvollziehbar und reproduzierbar sein.
Ohne Infrastruktur als Code stehen Teams vor zwei Problemen:
-
Konfigurationsdrift. Regeln, Richtlinien und Monitore werden manuell über die Kibana-Benutzeroberfläche erstellt. Im Laufe der Zeit weichen Produktion und Inszenierung voneinander ab. Niemand weiß genau, welche Version einer Erkennungsregel wo ausgeführt wird.
-
Versteckter Prüfpfad. Wenn sich eine Erkennungsregel ändert oder eine Ausnahme hinzugefügt wird, gibt es keinen Pull Request zum Überprüfen, keine Commit-Historie zum Nachverfolgen und keinen Rollback-Pfad, falls etwas kaputt geht. Die Nutzer müssen einen zusätzlichen Aufwand betreiben, um auf solche historischen Daten zugreifen zu können.
Der Elastic Stack Terraform Provider löst dieses Problem, indem er diese Konfigurationen in denselben versionskontrollierten, von Kollegen geprüften Workflow integriert, den Teams bereits für die Infrastruktur verwenden.
Sicherheitsartefakte als Code: Erkennungsregeln, Ausnahmen und vordefinierte Regeln
Sie können nun den gesamten Lebenszyklus der Elastic Security-Erkennungsregeln über Terraform verwalten.
Regeln für die Erkennung
Mit der Ressource elasticstack_kibana_security_detection_rule können Sie Erkennungsregeln im HashiCorp Configuration Language (HCL)-Format definieren, versionieren und bereitstellen:
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"]
}Das bedeutet, dass Ihre Erkennungsregeln in Git gespeichert sind, einer Code-Überprüfung unterzogen werden und in allen Umgebungen einheitlich bereitgestellt werden. Das Klicken durch die Kibana-Benutzeroberfläche zum Replizieren von Regeln von der Staging- in die Produktionsumgebung entfällt.
Ressourcendokumente zu Erkennungsregeln
Ausnahmelisten und Elemente
Das Konzept der Sicherheit als Code erstreckt sich auch auf eine vollständige Suite von Ressourcen für das Ausnahmemanagement:
elasticstack_kibana_security_exception_list- Ausnahmelisten erstellen und verwaltenelasticstack_kibana_security_exception_item- Einzelne Ausnahmen innerhalb einer Liste definierenelasticstack_kibana_security_listundelasticstack_kibana_security_list_item- Wertelisten für IP-Zulassungslisten, Dateihashes und andere Indikatoren verwaltenelasticstack_kibana_security_list_data_streams- Listen bestimmten Datenströmen zuordnen
Hier ist ein Beispiel, das die beiden Elemente miteinander verbindet – eine Ausnahmeliste mit Einträgen, die bekannte Fehlalarme einer Erkennungsregel unterdrücken:
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"]
}Die Ausnahmeliste und ihre Elemente sind durch list_id verknüpft, sodass Terraform den Abhängigkeitsgraphen automatisch verwaltet. Das Hinzufügen eines neuen autorisierten Scanners ist ein einzeiliger Pull Request – kein Klicken durch die Kibana-Benutzeroberfläche, kein Risiko, zu vergessen, welche Umgebung das Update erhalten hat.
Vordefinierte Sicherheitsregeln
Mit der Ressource elasticstack_kibana_prebuilt_rule können Sie die vordefinierten Erkennungsregeln von Elastic über Terraform verwalten. Dies ist besonders wertvoll für Organisationen, die nachverfolgen müssen, welche vordefinierten Regeln aktiviert sind, deren Parameter anpassen und eine konsistente Bereitstellung in verschiedenen Umgebungen gewährleisten müssen.
ML-Anomalieerkennung als Code
Die Erkennung von Anomalien im maschinellen Lernen ist eine der leistungsstärksten Funktionen von Elasticsearch – die Verwaltung von ML-Jobs über verschiedene Umgebungen hinweg war jedoch traditionell ein manueller Prozess. Sie erstellen einen Job in der Kibana-Benutzeroberfläche, optimieren die Detektoren, konfigurieren den Datenfeed und hoffen, dass jemand die Einstellungen dokumentiert, damit sie in der nächsten Umgebung repliziert werden können.
Die Ressource elasticstack_elasticsearch_ml_anomaly_detection_job ändert das. Sie können nun die vollständige Konfiguration eines Anomalieerkennungsjobs in HCL definieren – Detektoren, Bucket-Spans, Einflussfaktoren, Datenfeeds und Analysegrenzen – und ihn konsistent über Entwicklung, Staging und Produktion bereitstellen.
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"
}
}Dies ist wichtig für Teams, die auf maschinelles Lernen angewiesen sind, um Infrastrukturanomalien, ungewöhnliches Benutzerverhalten oder Sicherheitsbedrohungen aufzuspüren. Anstatt Jobs beim Hochfahren neuer Cluster oder bei der Wiederherstellung nach Ausfällen manuell neu zu erstellen, befindet sich die gesamte ML-Konfiguration in der Versionskontrolle – überprüfbar, wiederholbar und wiederherstellbar.
Clusterübergreifende Automatisierung mit API-Schlüsseln
Für Organisationen, die mehrere Elasticsearch-Cluster betreiben, unterstützt der Anbieter nun Cluster-API-Schlüssel für die clusterübergreifende Suche (CCS) und die clusterübergreifende Replikation (CCR). Sie können API-Schlüssel erstellen, die speziell für die sichere clusterübergreifende Kommunikation entwickelt wurden und so die durchgängige Automatisierung von Multi-Cluster-Architekturen ermöglichen.
Das bedeutet, dass Sie zwei Cluster bereitstellen, CCS/CCR zwischen ihnen konfigurieren und die erforderlichen Sicherheitsanmeldeinformationen einrichten können – alles in einer einzigen Terraform-Konfiguration.
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"
})
}Wenn type auf cross_cluster gesetzt wird, ist der API-Schlüssel auf CCS/CCR-Operationen beschränkt. Sie definieren, welche Indexmuster für Suche und Replikation zugänglich sind, legen eine Ablaufrichtlinie fest und versehen den Schlüssel mit Metadaten – alles über einen Pull Request überprüfbar.
Mehr über API-Schlüsselressourcen erfahren Sie in der Dokumentation.
KI-Konnektoren als Code
Der Provider unterstützt nun .bedrock und .gen-ai -Konnektoren und integriert so die KI-Infrastruktur in Ihre Terraform-Workflows. Da Teams zunehmend große Sprachmodelle in ihre Elastic-Workflows integrieren – für KI-Assistenten, Angriffserkennung und automatisierte Untersuchungen – wird die Verwaltung dieser Konnektorkonfigurationen als Code unerlässlich.
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
})
}Mit diesen in Terraform definierten Konnektoren können Sie Ihre KI-Integrationskonfiguration zusammen mit dem Rest Ihrer Elastic-Infrastruktur versionieren und Modelle oder Provider über einen einfachen Pull Request austauschen.
Verbesserungen der Beobachtbarkeit
Synthetische Monitore
Die Ressource elasticstack_kibana_synthetics_monitor enthält nun ein Feld labels , was eine bessere Organisation und Filterung synthetischer Prüfungen ermöglicht. Mithilfe von Labels können Sie Monitore nach Team, Umgebung oder Dienst kennzeichnen, wodurch die Verwaltung von synthetischem Monitoring in großem Umfang vereinfacht wird.
Weitere Plattformverbesserungen
Die jüngsten Veröffentlichungen enthielten außerdem mehrere Ressourcen und Attribute, die den Leistungsumfang des Anbieters abrunden:
elasticstack_elasticsearch_alias- Elasticsearch-Aliase als dedizierte Ressource verwaltenelasticstack_kibana_default_data_view- Die Standarddatenansicht für einen Kibana-Bereich festlegensolutionAttribut fürelasticstack_kibana_space- Konfigurieren des Lösungstyps für Kibana Spaces (verfügbar ab Version 8.16)- Verbesserungen der Fleet-Agent-Richtlinien –
host_name_formatfür die Konfiguration von Hostnamen vs. FQDN undrequired_versionsfür die Versionsfixierung
Einrichten der DGA-Erkennung
Wenn Sie bereits den Elastic Stack Terraform-Provider verwenden, aktualisieren Sie auf die neueste Provider-Version, um alle diese Funktionen nutzen zu können:
terraform {
required_providers {
elasticstack = {
source = "elastic/elasticstack"
version = "~> 0.14"
}
}
}Wenn Sie noch keine Erfahrung mit der Verwaltung Ihres Elastic Stack mit Terraform haben, beginnen Sie mit der Provider-Dokumentation in der Terraform-Registry.
Um Elastic Cloud noch heute zu nutzen, melden Sie sich in der Elastic Cloud-Konsole an oder registrieren Sie sich für eine kostenlose Testversion.
Die vollständige Liste der Änderungen finden Sie in den Versionshinweisen auf GitHub.