Engineering

Authentifizierung und Autorisierung in Elasticsearch ohne Geheimnisse

Von
Gabriel Moskovicz

Ich arbeite seit mehr als vier Jahren für Elastic, davon dreieinhalb Jahre in den Bereichen Support und Consulting und das letzte halbe Jahr im Vertrieb. Unabhängig von der Abteilung, in der ich arbeite, geht es bei einem Großteil der Fragen von Benutzern um die Sicherheit in Elasticsearch. Welche Authentifizierungsarten unterstützt Elasticsearch? Wie funktioniert die Einrichtung? Wie kann ich sicherstellen, dass die Benutzer keine Daten sehen, die nicht für sie bestimmt sind? In diesem Blogeintrag möchte ich diese Fragen beantworten und Sie bei einigen der häufigsten Probleme im Zusammenhang mit der Sicherheitskonfiguration unterstützen.

Zunächst etwas zur Vorgeschichte. Falls Sie schon Erfahrung mit Elasticsearch haben, wissen Sie, dass früher das Plugin Shield für die Sicherheit zuständig war, das über X-Pack angeboten wurde. Inzwischen wurden die Sicherheitsfunktionen in den Elastic Stack verschoben (zusammen mit dem Rest von X-Pack), und die am häufigsten verwendeten Funktionen sind kostenlos in der Standarddistribution enthalten. Die Sicherheitsfunktionen sind zuständig für verschlüsselte Kommunikation (TLS/SSL), Authentifizierung (nativ, LDAP, SSO usw.), Autorisierung (RBAC, ABAC usw.), IP-Filterung, Audit-Logging und vieles mehr. Dieser Blogeintrag befasst sich mit den Bereichen Authentifizierung und Autorisierung.

Authentifizierung in Elasticsearch

Kurz gesagt muss sich jeder Benutzer und jede API für den Zugriff auf Elasticsearch authentifizieren.

Elasticsearch unterstützt verschiedene Sicherheitsmethoden nativ, zum Beispiel:

Sie können sogar eigene Integrationen erstellen, wenn diese Methoden für Sie nicht zutreffen. Wir empfehlen jedoch normalerweise, eine der vorhandenen Integrationen zu verwenden, die geprüft wurden und ständig von uns weiterentwickelt werden, um einen korrekten Support zu gewährleisten.

Die grundlegende zum Auflösen und Authentifizieren von Benutzern verwendete Sicherheitskomponente wird in Elasticsearch als Realm bezeichnet. Jede der oben aufgelisteten Authentifizierungsmethoden ist ein Realm. Elasticsearch verwendet intern sogenannte Realm-Ketten. Eine Realm-Kette ist eine priorisierte Liste von Realms (1 bis N Realms) in aufsteigender Präferenzreihenfolge. Wenn ein Benutzer versucht, auf Elasticsearch zuzugreifen, durchläuft die Anforderung diese Liste sequenziell, bis die Authentifizierung erfolgreich war oder keine weiteren Realms mehr vorhanden sind.

Der Prozess probiert also den ersten konfigurierten Realm in der Liste aus. Bei einem Fehler wird der nächste Realm ausprobiert, bis entweder die Authentifizierung bei einem Realm erfolgreich war oder die gesamte Liste durchlaufen wurde. Der erste Schritt beim Zugriff auf Elasticsearch ist die Authentifizierung.

Nachdem sich ein Benutzer authentifiziert hat, versucht Elasticsearch, dem Benutzer eine oder mehrere Rollen zuzuweisen. Die Rollen können bei der Authentifizierung anhand der Eigenschaften des Benutzers entweder statisch oder dynamisch zugewiesen werden. Je nach Art des Realms, der den Benutzer authentifiziert hat, können für die Zuweisung der Rolle verschiedene Benutzereigenschaften verwendet werden, zum Beispiel Gruppenmitgliedschaften in externen Systemen, das Suffix des Benutzernamens in Elasticsearch usw. Elasticsearch verfügt außerdem über eine Ausführen als-Funktion, mit der Benutzer Anforderungen im Namen von anderen Benutzern übermitteln können, ohne sich erneut authentifizieren zu müssen.

Nach Abschluss der Authentifizierungsphase folgt die Autorisierung. Das folgende Diagramm zeigt den kompletten Workflow:

Realm-Verkettung in Elasticsearch

Autorisierung in Elasticsearch

Nach der erfolgreichen Authentifizierung wird der Benutzer zum zweiten Sicherheits-Checkpoint weitergeleitet: der Autorisierung. Bei der Autorisierung wird ermittelt, ob der Benutzer bestimmte Anforderungen ausführen darf. Dazu werden die Benutzer zu vordefinierten und/oder benutzerdefinierten Rollen zugeordnet. Bestimmte Rollen sind standardmäßig in Elasticsearch enthalten, und Sie können eigene Rollen für Ihren Anwendungsfall erstellen.

Jede Rolle besteht aus:

  • Eine Liste der Benutzer, die Zugriff erhalten
  • Cluster-Privilegien
  • Globale Privilegien
  • Index-Privilegien
  • Anwendungsprivilegien

In dieser zweiten Phase verwendet Elasticsearch eines der folgenden Elemente:

  • Die role_mapping-API. Dies ist die bevorzugte Methode, da Sie die Zuordnungen der einzelnen Rollen API-gesteuert und zentralisiert verwalten können. Diese Methode ist der einzige Weg, um Rollenzuordnungen im Elasticsearch Service in der Elastic Cloud zu konfigurieren.
  • Die Rollenzuordnungsdatei (role_mapping.yml) im Konfigurationsordner auf den einzelnen Knoten.

Die role_mapping-API muss von einem Benutzer mit den erforderlichen Berechtigungen zum Verwalten von Rollen aufgerufen werden. Die superuser-Rolle des Benutzers Elastic ist ein Beispiel für eine solche Rolle. Sie können jedoch auch eigene Rollen für diesen Zweck erstellen.

Realms und Rollen sind definitionsgemäß zwei völlig unterschiedliche Objekte. Realms und Realm-Ketten werden für die Authentifizierung verwendet, und nach der Authentifizierungsphase ordnen wir Rollen zu Benutzern zu. Während sich jeder Benutzer immer nur mit einem einzigen Realm aus der Realm-Kette authentifiziert, können den Benutzern in der zweiten Phase eine oder mehrere Rollen zugewiesen werden. Dieses Modell wird auch als rollenbasierte Zugriffssteuerung bezeichnet.

Fehlerbehebungsschritte für Authentifizierungs- und Autorisierungsprobleme

Nach den Grundlagen zu Authentifizierung und Autorisierung werden wir uns jetzt einige der Schritte ansehen, mit denen Sie eventuell auftretende Probleme lösen können.

401 Unauthorized

Wenn Sie sich mit keinem der Realms authentifizieren können, erhalten Sie eine Antwort mit dem Statuscode 401 Unauthorized. Der einfachste Weg, um Ihre Anmeldeinformationen bei einer Liste von konfigurierten Realms auszuprobieren, ist cURL mit einem Flag, das eine Inspektion der Ausgabe ermöglicht (zum Beispiel -v). Die Antwort sieht möglicherweise wie folgt aus: 

curl https://xxxxxx:9200 -u test:test -v 
> User-Agent: curl/7.54.0 
> Accept: */* 
> 
< HTTP/1.1 401 Unauthorized 
< Content-Type: application/json; charset=UTF-8 
< Date: Tue, 10 Sep 2019 15:59:33 GMT 
< Www-Authenticate: Bearer realm="security" 
< Www-Authenticate: ApiKey 
< Www-Authenticate: Basic realm="security" charset="UTF-8" 
< Content-Length: 455 
< Connection: keep-alive 
< 
* Connection #0 to host 06618318cff64c829af1cd5a2beb91a5.us-east-1.aws.found.io left intact 
{"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}}],"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}},"status":401}%

Mit dieser Fehlermeldung können Sie der Problemursache auf den Grund gehen. Für bestimmte Realms wie etwa SAML muss die Interaktion mit Elasticsearch und dem Identitätsanbieter mit Kibana oder einer speziellen Webanwendung ausgeführt werden.

Aktivieren der Fehlerprotokollierung

Wenn Sie der Einrichtung von Realms, Realm-Kette, Rollen und Rollenzuordnung immer noch Probleme auftreten, können Sie Ihre Logging-Konfiguration erweitern, um weitere Informationen zu den bereits behandelten Authentifizierungs- und Autorisierungsprozessen zu erhalten.

In der Logging-Konfiguration in der Clustereinstellungs-API können Sie beliebige Loggingstufen für einzelne Realms definieren.

Das folgende Beispiel verwendet den LDAP-Realm. Wenn bei der Authentifizierung oder Autorisierung von Benutzern Probleme auftreten, können Sie die folgende Loggingstufe verwenden, um weitere Informationen zu erhalten: 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap":"DEBUG", 
     "logger.org.elasticsearch.xpack.security.authz":"DEBUG" 
   } 
}

Damit wird die Loggingstufe für das LDAP-Paket von der Standardeinstellung zu DEBUG erhöht. Mit der Loggingstufe TRACE erhalten Sie noch mehr Informationen, darunter sämtliche LDAP-Aufrufe an den Server und die jeweiligen Antworten. Sie finden die Paketnamen zum Aktivieren der einzelnen REALMS in unserem GitHub-Repository. Hier ist beispielsweise der Code für den LDAP-Realm. In der ersten Codezeile finden Sie das entsprechende Paket für die Loggingstufe: 

package org.elasticsearch.xpack.security.authc.ldap;

Wenn Sie diese Einstellung aktivieren, erhalten Sie eine große Menge an Log-Zeilen, wie im folgenden Beispiel gezeigt: 

[2019-09-12T08:41:20,628][DEBUG][o.e.x.s.a.l.LdapRealm   ] [xxxxxxx] user not found in cache, proceeding with normal authentication
[2019-09-12T08:41:21,180][TRACE][o.e.x.s.a.l.s.LdapUtils ] LDAP Search SearchRequest(baseDN='dc=xxx,dc=xxxx,dc=domain,dc=com', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(cn=vchatzig)', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=2, entriesReturned=1, referencesReturned=0) ([SearchResultEntry(dn='cn=xxxxxxx,ou=xxxxx,dc=intc,dc=xxxx,dc=domain,dc=com', messageID=2, attributes={}, controls={})])

Hier sehen wir, dass der LDAP-Realm zunächst versucht, den Benutzer im (möglicherweise veralteten) Cache zu finden. Anschließend stellt er eine LDAP-Suchanforderung an den Server mit der Konfiguration, die wir angegeben haben. Dies ist nur ein Beispiel für die zahlreichen Log-Zeilen, die Sie erhalten werden.

Hinweis: Das Logging ist zwar hilfreich für Diagnosen, kann aber die Leistung beeinträchtigen. Wir empfehlen, die Loggingstufe mit der folgenden Konfiguration wieder auf den Standardwert zurückzusetzen, wenn Sie sich vergewissert haben, dass alles funktioniert: 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap": null, 
     "logger.org.elasticsearch.xpack.security.authz": null 
   } 
}

Beachten Sie, dass sich die verwendeten Pakete von Version zu Version ändern können. Daher sollten Sie immer die Dokumentations-Links für Ihre jeweilige Elasticsearch-Version überprüfen, zusammen mit den Links zu den GitHub-Klassen für diese Version.

Gängige SAML-Probleme

Der SAML-Realm benötigt einen Identitätsanbieter (z. B. Okta oder Auth0) und eine Webanwendung (standardmäßig Kibana), die zusammen mit Elasticsearch als Dienstanbieter eingesetzt wird. Hier sind die am häufigsten auftretenden Probleme:

  • Ungültige „Assertion Consumer Service“-URL in der Konfiguration des Identitätsanbieters (IdP). Der Endpunkt, den Sie für den Identitätsanbieter konfigurieren müssen, ist normalerweise https://kibana.xxxx.com/api/security/v1/saml.
  • Die Metadaten des Identitätsanbieters sind nicht über das Internet erreichbar. Der Konfigurationswert für „idp.metadata.path“ in Elasticsearch entweder lokal oder in der Elastic Cloud muss für das Netzwerk erreichbar sein, in dem Elasticsearch/Kibana ausgeführt wird. Andernfalls müssen Sie die Metadaten von einem Host mit entsprechenden Zugriff herunterladen oder sich die Metadaten von einem IdP-Administrator beschaffen, als lokale Datei in Elasticsearch hinzufügen und dort referenzieren. In diesem Fall wird der folgende Fehler angezeigt: 
    Caused by: net.shibboleth.utilities.java.support.resolver.ResolverException: net.shibboleth.utilities.java.support.resolver.ResolverException: Non-ok status code 404 returned from remote metadata source https://xxxx.xxxx/xxx/yyyyyyyy/sso/saml/metadata
  • Sie können sich zwar authentifizieren, aber der Benutzer kann Kibana nicht öffnen. In diesem Fall sollten Sie die Rollenzuordnungen der Benutzer überprüfen, um sicherzustellen, dass mindestens eine der zugeordneten Rollen Zugriff auf Kibana hat.

Die Konfiguration des Identitätsanbieters ist genauso wichtig wie die Elasticsearch-/Kibana-Konfiguration, und Sie sollten stets auf Schreibfehler und Abweichungen zwischen erwarteten und konfigurierten Einstellungen achten. Obwohl jeder IdP eigene Einstellungen verwendet, sollten Sie sich trotzdem die Dokumentation für die einzelnen benötigten Einstellungen genau ansehen.

Weitere Informationen zu gängigen SAML-Problemen und deren Behebung finden Sie in unseren Tipps zur Fehlerbehebung, die mit jeder Version aktualisiert werden.

Fazit

Die Einrichtung der Authentifizierung in Elasticsearch ist kinderleicht, sobald wir die zugrunde liegenden Konzepte verstanden haben. Es ist auch nicht immer einfach zu verstehen, welcher Teil funktioniert oder nicht funktioniert, und warum, aber in diesem Blogeintrag haben Sie verschiedene Methoden kennengelernt, um genauer hinzusehen. Verwenden Sie unsere Dokumentation für Ihre ersten Schritte mit Sicherheit in Elasticsearch, oder lesen Sie unsere Tipps zur Fehlerbehebung zum Thema Sicherheit in unserer Dokumentation. Sehen Sie sich eine ausführliche Beschreibung der ersten Schritte von unserem Senior Product Manager für Elastic Security an.

Außerdem empfehlen wir Ihnen einen Besuch auf unserer Abonnement-Seite, um mehr über den Funktionsumfang der einzelnen Ebenen erfahren. Falls Sie spezifische Fragen haben, können Sie sich außerdem an Ihren Supportmitarbeiter wenden oder unsere Diskussionsforen besuchen.

Frohe Sicherheit!