Security: Authentifizierung und Rollen richtig konfigurieren

1. Warum Security ab Tag eins keine Option ist

Ein Elasticsearch- oder OpenSearch-Cluster ohne aktivierte Security-Funktionen ist standardmaessig ueber die REST-API vollstaendig offen: Jeder, der die Netzwerkadresse erreicht, kann Daten lesen, schreiben und ganze Indizes loeschen, ohne sich zu authentifizieren. In der Vergangenheit fuehrten genau solche ungesicherten, aus Versehen oeffentlich erreichbaren Cluster wiederholt zu grossen Datenlecks, weil Elasticsearch standardmaessig auf allen Netzwerkinterfaces lauscht und ohne zusaetzliche Konfiguration keinerlei Zugriffsschutz bietet.

Seit Version 8 aktiviert Elasticsearch Security-Funktionen wie TLS und Passwort-Authentifizierung standardmaessig bei der Erstinstallation, was das Risiko unbeabsichtigt offener Cluster erheblich reduziert hat. Bei OpenSearch ist das OpenSearch Security Plugin ebenfalls von Beginn an vorinstalliert, muss aber je nach Distribution explizit aktiviert und konfiguriert werden. In beiden Faellen gilt: Die Standardkonfiguration ist ein Ausgangspunkt, keine fertige Loesung. Rollen, Nutzer und Netzwerkgrenzen muessen fuer den konkreten Anwendungsfall angepasst werden.

Dieser Artikel behandelt die vollstaendige Kette von Authentifizierungsmethoden ueber rollenbasierte Zugriffskontrolle, API-Keys und TLS zwischen Nodes bis zu Audit-Logging und den haeufigsten Fehlkonfigurationen, die in der Praxis zu Sicherheitsproblemen fuehren.

2. Authentifizierungsmethoden im Ueberblick

Elasticsearch unterstuetzt mehrere Authentifizierungsrealms parallel: das native Realm mit intern gespeicherten Benutzern und Passwoertern, LDAP- und Active-Directory-Realms fuer die Anbindung an bestehende Unternehmensverzeichnisse, SAML und OpenID Connect fuer Single-Sign-On-Szenarien, sowie Kerberos fuer Windows-Umgebungen. Fuer kleinere Deployments reicht das native Realm oft aus, waehrend groessere Organisationen meist LDAP oder SAML nutzen, um Benutzerverwaltung zentral im bestehenden Identity-Provider zu belassen, statt Nutzerkonten doppelt zu pflegen.

Neben Benutzer-Authentifizierung mit Passwort existiert die service-orientierte Authentifizierung ueber API-Keys und Service-Account-Tokens, die speziell fuer maschinelle Zugriffe von Anwendungen gedacht sind, ohne dass ein Anwendungsserver ein persoenliches Benutzerpasswort im Klartext speichern muss. Diese Trennung zwischen menschlichen Nutzern mit vollem Login und Service-Zugriffen mit eingeschraenkten, wiederrufbaren Credentials ist ein zentrales Prinzip fuer eine saubere Security-Architektur.

// Create a native user with the built-in Elasticsearch realm
POST /_security/user/catalog_service
{
  "password": "a-strong-generated-password",
  "roles": ["catalog_writer"],
  "full_name": "Catalog Import Service",
  "email": "ops@mironsoft.de"
}

// Check current realm configuration
GET /_security/_authenticate

3. Rollenbasierte Zugriffskontrolle: Rollen und Privilegien

Rollenbasierte Zugriffskontrolle, kurz RBAC, ist das zentrale Modell fuer Berechtigungen in Elasticsearch und OpenSearch. Eine Rolle definiert Cluster-Privilegien wie das Anlegen von Indizes oder das Verwalten von Snapshots, sowie Index-Privilegien wie Lesen, Schreiben oder Loeschen fuer eine bestimmte Menge an Indizes, definiert ueber Namensmuster. Nutzer oder Service-Accounts erhalten dann eine oder mehrere Rollen zugewiesen, wodurch sich granulare Berechtigungskombinationen abbilden lassen, ohne fuer jede Kombination einen eigenen Nutzertyp anlegen zu muessen.

Ein haeufiger Fehler ist, eine einzige, breit angelegte Administrator-Rolle fuer alle Anwendungen und Dienste zu verwenden, weil das die initiale Einrichtung vereinfacht. Diese Praxis widerspricht dem Prinzip der geringsten Rechte und schafft ein erhebliches Risiko: Ein kompromittierter Anwendungsserver mit Administrator-Rechten kann den gesamten Cluster manipulieren, statt nur die Indizes zu beeinflussen, die diese eine Anwendung tatsaechlich braucht. Der korrekte Ansatz ist, fuer jeden Anwendungsfall eine eigene, eng gefasste Rolle zu definieren, die nur die tatsaechlich benoetigten Privilegien enthaelt.

// Narrow role: read and write only for product-related indices
POST /_security/role/catalog_writer
{
  "cluster": [],
  "indices": [
    {
      "names": ["products-*"],
      "privileges": ["read", "write", "create_index"]
    }
  ]
}

// Read-only role for a reporting dashboard
POST /_security/role/reporting_reader
{
  "cluster": ["monitor"],
  "indices": [
    { "names": ["products-*", "orders-*"], "privileges": ["read"] }
  ]
}

4. Feldbasierte und dokumentbasierte Einschraenkungen

Ueber die reine Index-Ebene hinaus erlaubt Elasticsearch feingranulare Einschraenkungen innerhalb eines Index: Field-Level-Security blendet bestimmte Felder eines Dokuments fuer eine Rolle vollstaendig aus, etwa personenbezogene Daten wie eine E-Mail-Adresse fuer eine Rolle, die nur aggregierte Auswertungen braucht. Document-Level-Security geht noch weiter und filtert, welche einzelnen Dokumente ueberhaupt sichtbar sind, basierend auf einer Query, die als Teil der Rollendefinition hinterlegt wird, etwa nur Bestellungen einer bestimmten Filiale fuer eine filialbezogene Rolle.

Diese beiden Mechanismen sind besonders relevant in Multi-Tenant-Szenarien, in denen mehrere Kunden oder Abteilungen denselben physischen Index nutzen, aber strikt voneinander isolierte Sichten auf die Daten brauchen. Statt fuer jeden Mandanten einen eigenen Index anzulegen, was bei sehr vielen kleinen Mandanten zu einem unpraktikablen Shard-Overhead fuehren wuerde, laesst sich Dokumenttrennung ueber Document-Level-Security elegant in einem gemeinsam genutzten Index abbilden, ohne dass ein Mandant jemals Daten eines anderen sehen kann.

5. API-Keys fuer Anwendungen und Services

API-Keys sind das empfohlene Authentifizierungsmittel fuer Anwendungen, Microservices und automatisierte Skripte, weil sie im Gegensatz zu einem geteilten Benutzerpasswort individuell erstellt, mit einer eigenen Rolle versehen, zeitlich begrenzt und jederzeit einzeln widerrufen werden koennen, ohne andere Zugriffe zu beeintraechtigen. Jeder API-Key erhaelt bei der Erstellung optional eigene, noch weiter eingeschraenkte Privilegien, die niemals ueber die Rechte des erstellenden Nutzers hinausgehen koennen, was verhindert, dass ein API-Key versehentlich mehr Rechte erhaelt als beabsichtigt.

Ein bewaehrtes Muster ist, fuer jede Anwendung und jede Umgebung, also Staging und Produktion getrennt, einen eigenen API-Key mit eigener, minimaler Rolle zu erstellen. Wird ein Key kompromittiert, laesst er sich isoliert widerrufen, ohne dass andere Anwendungen betroffen sind oder ein zentrales Passwort geaendert werden muss, das mehrere Systeme gleichzeitig betrifft. API-Keys mit Ablaufdatum erzwingen zusaetzlich eine regelmaessige Rotation, was das Risiko von langlebigen, in Konfigurationsdateien vergessenen Credentials reduziert.

// Create a scoped, time-limited API key for a specific application
POST /_security/api_key
{
  "name": "catalog-import-prod",
  "expiration": "90d",
  "role_descriptors": {
    "catalog_writer_scoped": {
      "cluster": [],
      "indices": [
        { "names": ["products-2026-*"], "privileges": ["write", "create_index"] }
      ]
    }
  }
}

// Revoke a compromised or unused API key immediately
DELETE /_security/api_key
{
  "ids": ["VuaCfGcBCdbkQm-e5aOx"]
}

6. TLS zwischen Nodes: Transport- und HTTP-Layer absichern

Neben Authentifizierung ist Verschluesselung der zweite tragende Pfeiler jeder Security-Konfiguration. Elasticsearch unterscheidet zwei getrennte Kommunikationsschichten, die jeweils eigene TLS-Zertifikate benoetigen: die HTTP-Schicht, ueber die externe Clients und Anwendungen kommunizieren, und die Transport-Schicht, ueber die die Nodes eines Clusters intern miteinander kommunizieren. Ohne TLS auf der Transport-Schicht koennen Cluster-interne Daten, inklusive sensibler Dokumentinhalte bei Shard-Replikation, unverschluesselt im Netzwerk mitgelesen werden, selbst wenn die HTTP-Schicht nach aussen abgesichert ist.

Fuer die Transport-Schicht reicht in der Regel ein selbstsigniertes Zertifikat aus einer eigenen internen Certificate Authority, da nur die Cluster-Nodes selbst diese Zertifikate pruefen muessen und keine externen Clients involviert sind. Fuer die HTTP-Schicht empfiehlt sich hingegen ein Zertifikat, das von externen Clients ohne manuelle Ausnahmeregeln akzeptiert wird, etwa von einer oeffentlich vertrauenswuerdigen CA oder zumindest einer unternehmensweit verteilten internen CA. Elasticsearch stellt mit elasticsearch-certutil ein Tool bereit, das sowohl eine eigene CA als auch Node-Zertifikate mit wenigen Befehlen erzeugt.

# Generate a certificate authority for internal transport encryption
bin/elasticsearch-certutil ca --out /etc/elasticsearch/certs/ca.p12

# Generate node certificates signed by that CA
bin/elasticsearch-certutil cert \
  --ca /etc/elasticsearch/certs/ca.p12 \
  --out /etc/elasticsearch/certs/node.p12

# elasticsearch.yml: enable TLS on both transport and HTTP layers
# xpack.security.transport.ssl.enabled: true
# xpack.security.transport.ssl.verification_mode: certificate
# xpack.security.http.ssl.enabled: true

7. OpenSearch Security im Vergleich zu X-Pack

OpenSearch nutzt das OpenSearch Security Plugin, das aus dem urspruenglich von Floragunn entwickelten Search Guard hervorgegangen ist und konzeptionell viele Aehnlichkeiten zu Elastic X-Pack Security aufweist: Rollenbasierte Zugriffskontrolle, TLS-Konfiguration und Unterstuetzung fuer LDAP, SAML und OpenID Connect sind in aehnlicher Form vorhanden. Der wesentliche Unterschied liegt darin, dass diese Funktionen bei OpenSearch vollstaendig kostenlos unter Apache 2.0 verfuegbar sind, waehrend bei Elastic bestimmte fortgeschrittene Features wie SAML-Integration oder Field-Level-Security teilweise kostenpflichtigen Lizenzstufen vorbehalten bleiben.

Konfigurationstechnisch unterscheiden sich beide Systeme in Details: OpenSearch Security definiert Rollen und Rollenzuweisungen ueber YAML-Konfigurationsdateien, die mit einem securityadmin.sh-Skript in den Cluster geladen werden, waehrend Elasticsearch Rollen primaer ueber die REST-API oder Kibana-Oberflaeche verwaltet. Wer von Elasticsearch zu OpenSearch wechselt, muss deshalb nicht nur Rollen inhaltlich neu abbilden, sondern sich auch an einen anderen Verwaltungs-Workflow gewoehnen.

# OpenSearch Security roles.yml, loaded via securityadmin.sh
catalog_writer:
  cluster_permissions:
    - "cluster_composite_ops"
  index_permissions:
    - index_patterns:
        - "products-*"
      allowed_actions:
        - "write"
        - "create_index"

8. Audit-Logging und Nachvollziehbarkeit

Audit-Logging protokolliert sicherheitsrelevante Ereignisse wie fehlgeschlagene Authentifizierungsversuche, Rollenaenderungen und verweigerte Zugriffe in einer separaten Log-Datei, unabhaengig vom normalen Anwendungs-Log. Ohne Audit-Logging bleibt ein Einbruchsversuch oder eine missbraeuchliche Rechteausweitung oft unbemerkt, weil weder Cluster-Health noch die normalen Zugriffs-Logs solche Ereignisse gezielt hervorheben. In regulierten Branchen ist Audit-Logging haeufig zusaetzlich eine Compliance-Anforderung, etwa fuer Nachweise im Rahmen einer ISO-27001- oder DSGVO-Pruefung.

Aktiviertes Audit-Logging erzeugt bei hoher Zugriffsfrequenz spuerbares Log-Volumen, weshalb in der Praxis meist nur ausgewaehlte Event-Kategorien protokolliert werden, etwa Authentifizierungsfehler und Autorisierungsverweigerungen, waehrend erfolgreiche, routinemaessige Lesezugriffe ausgeschlossen bleiben, um das Log nicht mit unwichtigen Eintraegen zu fluten. Diese Logs sollten in ein zentrales SIEM-System oder mindestens in einen separaten, besonders geschuetzten Elasticsearch-Index exportiert werden, damit sie im Fall eines Vorfalls unveraendert als Beweismittel zur Verfuegung stehen.

9. Cluster-Haertung: haeufige Fehlkonfigurationen vermeiden

Die haeufigste Fehlkonfiguration ist, den Cluster testweise ohne Security zu betreiben und diesen Zustand versehentlich in Produktion zu uebernehmen, weil das erste Setup schneller ohne Authentifizierung funktioniert. Ein zweiter klassischer Fehler ist, den vordefinierten elastic-Superuser dauerhaft fuer Anwendungszugriffe zu verwenden, statt ihn ausschliesslich fuer die initiale Administration zu nutzen und danach fuer den Tagesbetrieb eng gefasste, dedizierte Rollen anzulegen.

Ein dritter haeufiger Fehler betrifft die Netzwerkexposition: Ein Cluster, der per network.host: 0.0.0.0 auf allen Interfaces lauscht, obwohl nur interne Anwendungen zugreifen sollen, vergroessert die Angriffsflaeche unnoetig. Kombiniert mit einer Firewall-Regel, die nur bekannte Anwendungsserver-IPs zulaesst, und einer strikten RBAC-Konfiguration entsteht ein mehrschichtiges Sicherheitsmodell, bei dem der Ausfall einer einzelnen Schutzschicht nicht sofort zum vollstaendigen Datenzugriff fuehrt.

10. Zusammenfassung

Eine belastbare Security-Konfiguration fuer Elasticsearch und OpenSearch besteht aus mehreren zusammenspielenden Schichten: passende Authentifizierungsrealms fuer menschliche Nutzer, eng gefasste Rollen nach RBAC-Prinzip statt breiter Administrator-Zugaenge, API-Keys mit Ablaufdatum fuer maschinelle Zugriffe, TLS auf sowohl Transport- als auch HTTP-Layer, und Audit-Logging fuer Nachvollziehbarkeit im Ernstfall.

Der wichtigste Grundsatz bleibt das Prinzip der geringsten Rechte: Jede Rolle, jeder API-Key und jeder Service-Account sollte nur genau die Privilegien erhalten, die fuer die konkrete Aufgabe noetig sind, nicht mehr. In Kombination mit Netzwerksegmentierung und regelmaessiger Ueberpruefung bestehender Rollen entsteht ein Sicherheitsmodell, das auch bei Kompromittierung einzelner Komponenten den Schaden begrenzt hält.

11. FAQ: Security, Authentifizierung und Rollen