OpenSearch Security Plugin im Detail: Rollenbasierte Zugriffskontrolle für Magento-Suchcluster

1. Warum Zugriffskontrolle bei Magento-Suchclustern oft zu kurz kommt

In vielen Magento-Installationen läuft der Suchcluster ohne jede Authentifizierung im internen Netz, weil die Einrichtung eines Security Plugins zunächst wie zusätzlicher Aufwand ohne direkten Nutzen wirkt. Sobald jedoch mehrere Systeme auf denselben Cluster zugreifen, etwa der Magento-Indexer, ein Kibana-ähnliches Analyse-Tool und externe Reporting-Skripte, wird die fehlende Trennung schnell zum Risiko, weil jeder Zugriff mit vollen Administratorrechten läuft.

Das OpenSearch Security Plugin adressiert genau dieses Problem, indem es Authentifizierung und Autorisierung direkt in den Cluster integriert, ohne dass ein separates Proxy-System vorgeschaltet werden muss. Für Magento-Betreiber bedeutet das, dass der Indexer-Service-User nur Schreibrechte auf die eigenen Katalogindizes braucht, während ein Reporting-Zugang ausschließlich lesend auf ausgewählte Felder zugreifen darf.

2. Architektur des Security Plugins: Konfigurationsdateien im Überblick

Das Security Plugin speichert seine Konfiguration nicht in der zentralen opensearch.yml, sondern in einem eigenen Satz von YAML-Dateien im Verzeichnis config/opensearch-security/: internal_users.yml für interne Benutzerkonten, roles.yml für die eigentlichen Berechtigungsdefinitionen, roles_mapping.yml für die Zuordnung von Benutzern zu Rollen, action_groups.yml für wiederverwendbare Berechtigungsbündel sowie tenants.yml für die Mandantentrennung in Dashboards.

Diese Dateien werden nicht direkt vom Cluster gelesen, sondern müssen über das Kommandozeilenwerkzeug securityadmin.sh in einen speziellen, versteckten Systemindex namens .opendistro_security geladen werden. Erst danach wirken Änderungen im laufenden Cluster, was ein häufiger Stolperstein ist, wenn Teams die YAML-Dateien anpassen, den Upload aber vergessen.

# config/opensearch-security/roles.yml (Ausschnitt)
magento_indexer_role:
  cluster_permissions:
    - "cluster_composite_ops"
  index_permissions:
    - index_patterns:
        - "magento2_product_*"
        - "catalogsearch_fulltext_*"
      allowed_actions:
        - "indices:data/write/index"
        - "indices:data/write/bulk"
        - "indices:admin/create"
        - "indices:admin/mapping/put"

3. Unterschied zum X-Pack Security Modul von Elastic

X-Pack Security ist seit Elasticsearch 8.x standardmäßig aktiv und fest in den Elastic-Stack integriert, wird aber über eine Elastic-eigene Lizenz vertrieben, deren Basisfunktionen zwar kostenlos, deren erweiterte Funktionen wie Feld-Level-Security in älteren Versionen aber kostenpflichtig waren. Die Konfiguration erfolgt weitgehend über die Kibana-Oberfläche oder die Security-API und wird intern in einem systemeigenen Index verwaltet, der bei Cluster-Upgrades automatisch migriert wird.

Das OpenSearch Security Plugin verfolgt einen dateibasierten, deklarativen Ansatz: Rollen und Zuordnungen liegen als versionierbare YAML-Dateien vor, die sich wie jede andere Konfigurationsdatei in ein Git-Repository und eine CI-Pipeline einbinden lassen. Das ist für Magento-Projekte mit mehreren Umgebungen ein klarer Vorteil, weil sich Staging- und Produktionsrollen identisch aus derselben Quelle deployen lassen, während bei X-Pack Security häufig manuelle Nacharbeit über die Kibana-Oberfläche nötig ist.

4. Ein rollenbasiertes Zugriffsmodell für Magento aufbauen

Ein praxistaugliches Modell für einen Magento-Suchcluster besteht mindestens aus drei Rollen: einer Indexer-Rolle mit Schreibrechten auf die Katalogindizes, einer Read-Only-Rolle für die eigentliche Storefront-Suche und einer Administrator-Rolle für Cluster-Wartung und Mapping-Änderungen. Jede dieser Rollen wird in roles.yml definiert und anschließend in roles_mapping.yml mit konkreten Benutzern oder Backend-Rollen verknüpft.

Wichtig ist, die Rollen so eng wie möglich zu fassen: Der Magento-Anwendungsserver, der die Storefront-Suche ausführt, benötigt ausschließlich lesende Rechte auf die aktiven Katalogindizes, niemals Schreib- oder Administrationsrechte. Wird dieser Benutzer kompromittiert, bleibt der Schaden dadurch auf Leserechte begrenzt, statt dem Angreifer die Möglichkeit zu geben, Indizes zu löschen oder Mappings zu manipulieren.

# config/opensearch-security/roles_mapping.yml (Ausschnitt)
magento_storefront_readonly:
  backend_roles: []
  users:
    - "magento_storefront"

magento_indexer_role:
  backend_roles: []
  users:
    - "magento_indexer_service"

5. Document-Level und Field-Level Security für Katalogindizes

Über Document-Level Security lassen sich Suchergebnisse pro Rolle auf eine Teilmenge der Dokumente einschränken, etwa wenn ein B2B-Magento-Shop mehrere Kundengruppen mit unterschiedlichen Preisstrukturen über denselben Index abbildet und ein Analyse-Team nur Produkte einer bestimmten Website sehen soll. Die Einschränkung erfolgt über eine im Klartext gespeicherte Query, die bei jeder Suche automatisch als zusätzlicher Filter angehängt wird.

Field-Level Security ergänzt das auf Feldebene: Ein Reporting-Zugang kann so konfiguriert werden, dass er Produktnamen und Kategorien sieht, aber keinen Zugriff auf interne Kalkulationsfelder wie Einkaufspreise oder Margen hat, die in manchen Magento-Installationen als zusätzliche indexierte Attribute im Katalogindex landen. Beide Mechanismen wirken auf Ebene der Query-Ausführung und verursachen bei korrekt gebauten Indizes keinen messbaren Performance-Verlust.

{
  "index_permissions": [{
    "index_patterns": ["magento2_product_*"],
    "dls": "{\"term\": {\"website_id\": 2}}",
    "fls": ["name", "sku", "category_ids", "~cost_price", "~margin"],
    "allowed_actions": ["read"]
  }]
}

6. Audit-Logging für Compliance-Anforderungen konfigurieren

Das Audit-Logging protokolliert, welcher Benutzer wann welche Aktion gegen den Cluster ausgeführt hat, und wird über die Datei config/opensearch-security/audit.yml gesteuert. Für produktive Magento-Cluster empfiehlt es sich, mindestens fehlgeschlagene Authentifizierungsversuche und alle Änderungen an Berechtigungen zu protokollieren, während erfolgreiche Lesezugriffe auf die Storefront-Suche wegen der hohen Frequenz meist ausgeschlossen werden.

Die Audit-Logs lassen sich wahlweise in eine eigene Log-Datei, in einen dedizierten OpenSearch-Index oder direkt an ein externes Webhook-Ziel senden. Für Compliance-Anforderungen, etwa im Rahmen einer ISO-27001-Zertifizierung, ist ein separater Index mit eigener Aufbewahrungsfrist sinnvoll, damit Audit-Daten nicht versehentlich denselben Löschregeln wie die eigentlichen Suchindizes unterliegen.

# config/opensearch-security/audit.yml (Ausschnitt)
audit:
  enable_rest: true
  disabled_rest_categories:
    - GRANTED_PRIVILEGES
  enable_transport: false
  resolve_bulk_requests: false
  log_request_body: false
  audit.log_request_body: false
config:
  type: internal_opensearch
  index: "security-auditlog-%{now/d}"

7. Transportverschlüsselung und TLS zwischen den Knoten

Das Security Plugin erzwingt in der Standardkonfiguration Node-zu-Node-Verschlüsselung über TLS, wofür jeder Knoten ein eigenes Zertifikat sowie ein gemeinsames Root-Zertifikat benötigt. Für Magento-Cluster mit mehreren Data-Nodes in unterschiedlichen Netzsegmenten ist das keine optionale Härte-Maßnahme, sondern verhindert, dass Bulk-Indexierungsdaten aus dem Reindex-Vorgang im Klartext über das interne Netzwerk übertragen werden.

Zusätzlich zur Transportverschlüsselung sollte auch die REST-Schnittstelle, über die Magento seine Suchanfragen stellt, per HTTPS abgesichert werden. In der opensearch.yml wird dazu plugins.security.ssl.http.enabled aktiviert, und in der Magento-Konfiguration muss das Elasticsearch-Connection-Schema entsprechend von http auf https umgestellt werden.

# opensearch.yml (Ausschnitt)
plugins.security.ssl.transport.pemcert_filepath: node.pem
plugins.security.ssl.transport.pemkey_filepath: node-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: root-ca.pem
plugins.security.ssl.transport.enforce_hostname_verification: true
plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: node-http.pem

8. Migrationsaspekte beim Wechsel von Elasticsearch mit X-Pack

Beim Umstieg von Elasticsearch mit aktivem X-Pack Security auf OpenSearch mit Security Plugin lassen sich Rollen und Benutzer nicht automatisch übernehmen, weil das interne Speicherformat unterschiedlich ist. In der Praxis bewährt sich ein manueller Neuaufbau: Zunächst werden die bestehenden X-Pack-Rollen über die Security-API von Elasticsearch exportiert, anschließend als OpenSearch-YAML-Dateien nachgebaut und über securityadmin.sh eingespielt.

Ein häufig übersehener Punkt ist, dass Magento selbst keine eigene Benutzerverwaltung für den Suchcluster mitbringt, sondern lediglich Benutzername und Passwort in der env.php hinterlegt. Nach der Migration muss dieser Eintrag auf den neu angelegten OpenSearch-Benutzer angepasst werden, und ein Test der Storefront-Suche in einer Staging-Umgebung ist vor dem produktiven Umschalten unverzichtbar, weil fehlerhafte Rollenzuordnungen sich sonst erst durch leere Suchergebnisse im Livebetrieb bemerkbar machen.

# Neue Sicherheitskonfiguration nach Änderungen der YAML-Dateien einspielen
./plugins/opensearch-security/tools/securityadmin.sh \
  -cd config/opensearch-security/ \
  -icl -nhnv \
  -cacert root-ca.pem \
  -cert admin.pem \
  -key admin-key.pem

9. Best Practices und typische Fallstricke im Betrieb

Der häufigste Fehler ist, Änderungen an den YAML-Dateien vorzunehmen, den Aufruf von securityadmin.sh aber zu vergessen, wodurch der Cluster weiter mit der alten Konfiguration arbeitet, ohne dass ein Fehler sichtbar wird. Ebenso kritisch ist ein zu großzügig konfigurierter kibanaserver-Benutzer, der in vielen Standard-Setups mehr Rechte besitzt als für reine Dashboard-Anzeigen tatsächlich nötig sind.

Für Magento-Betriebe empfiehlt sich zudem, die YAML-Dateien vollständig in Infrastructure-as-Code zu überführen und Änderungen ausschließlich über die CI-Pipeline auszurollen, statt manuell auf dem Server zu editieren. Dadurch bleibt nachvollziehbar, wer wann welche Berechtigung geändert hat, und ein versehentliches Vergessen des Uploads fällt bereits im Pipeline-Schritt auf, statt erst beim nächsten Sicherheitsaudit.

10. Zusammenfassung

11. FAQ: OpenSearch Security Plugin