Tipps zum kostenlosen Absichern von Elasticsearch-Clustern mit Verschlüsselung, Nutzern und mehr

By
Josh Bressers

Seit den Versionen 6.8 und 7.1 des Elastic Stack sind eine Reihe von Elasticsearch-Security-Features kostenloser Bestandteil der Standarddistribution und damit für jeden frei verfügbar. Wir begrüßen dies außerordentlich, stehen jetzt aber vor der Aufgabe, die gesamte Dokumentation und alle Anleitungen zum Absichern des Elastic Stack auf den neuesten Stand zu bringen. Es reicht heutzutage einfach nicht mehr, dem Stack einfach einen Proxy-Server vorzuschalten, damit er sicher ist.

Ich habe mir noch einmal die meisten unserer alten und beliebten Blogposts zum Thema Security angesehen und werde in diesem Post die dort gegebenen Ratschläge neu bewerten, einige Mythen aufklären, auf ein paar neue Ideen hinweisen und Ihnen Tipps geben, wie Sie Ihren Stack künftig noch besser absichern können.

Mir scheint es sinnvoll, nicht auf die alten Artikel zu verlinken. Einige von ihnen enthalten tatsächlich Tipps, die wir heute als gefährlich einstufen würden, denn der Elastic Stack hat sich im Laufe der Jahre doch ziemlich gewandelt. (Bei Sicherheitstipps in alten Blogs ist stets Skepsis angebracht, da sich ja bekanntermaßen alles ständig ändert.) Wir werden alle Links auf diese Seite umleiten, aber wenn Sie auf eine andere Website stoßen, auf denen aus dem Cache gefischte Versionen der entsprechenden Artikel angezeigt werden, wäre es schön, wenn Sie sie auf diese Seite hinweisen könnten.

TLS-Verschlüsselung

Zu den kostenlosen Security-Features in den Standarddistributionen von Elasticsearch und Kibana gehört auch die TLS-Verschlüsselung. TLS (Transport Layer Security) dient zur Verschlüsselung der Netzwerkkommunikation – der Kommunikation zwischen den Knoten in Ihrem Cluster, der Kommunikation zwischen den Clients und dem Cluster und der Verbindungen von Kibana zu den Nutzern.

Wir verwenden auch TLS-Zertifikate, um dem System anzuzeigen, dass der jeweilige Knoten Bestandteil des Clusters werden darf. Ohne TLS kann jeder jedem Cluster einen Knoten hinzufügen. Dies kann zwar auch für Angriffe missbraucht werden, viel häufiger kommt es aber vor, dass ein Knoten irrtümlich im falschen Cluster landet. TLS kann helfen, diese Probleme zu vermeiden, denn ohne das richtige Zertifikat bleibt dem Knoten der Zugang zum Cluster verwehrt.

Vor der Einführung der kostenlosen TLS-Verschlüsselung in 6.8 und 7.1 mussten alle, die lediglich eine Basic-Lizenz hatten und TLS für ihren Elastic Stack benötigten, mit einem Proxy arbeiten, was mit beträchtlichem Einrichtungsaufwand verbunden war. Auch ohne einen Proxy zwischen den Knoten und den Clients ist das Konfigurieren von TLS alles andere als einfach; kommt dann noch ein Proxy hinzu, wird aus etwas Kompliziertem etwas noch Komplizierteres. Dank der kostenlosen Security-Features können wir aber jetzt von der direkten TLS-Unterstützung im Elastic Stack profitieren.

Die Konfiguration von TLS ist umfangreich dokumentiert. Wenn Sie schon einmal mit TLS gearbeitet haben, wissen Sie bestimmt, dass es niemals einfach ist, Zertifikate einzurichten. Um Ihnen das Leben zu erleichtern, haben wir Tools integriert, die beim Generieren Cluster-weiter Zertifikate und Zertifizierungsstellen helfen.  In künftigen Blogposts werden wir uns eingehender mit den Schritten für eine bestmögliche Konfiguration von TLS in allen Komponenten des Elastic Stack beschäftigen. Es lohnt sich also, immer mal wieder vorbeizuschauen. Wenn Sie die beiden unkompliziertesten Möglichkeiten für einen einfachen Einstieg kennenlernen möchten, lesen Sie diesen Blogpost zu den ersten Schritten mit Elasticsearch Security und sehen Sie sich unseren offiziellen Kubernetes-Operator an.

Authentifizierung

Seit den Elastic Stack-Versionen 6.8 und 7.1 kann jeder die native Authentifizierung nutzen. Sinn und Zweck der Authentifizierung ist es, dass der Elastic Stack die Identität von Clients prüft. Dies erfolgt in der Regel anhand des Nutzernamens und des Passworts, mit denen Sie sich beim System anmelden. Es ist generell keine gute Idee, ein Cluster voller Daten für die gesamte Welt offen zugänglich zu lassen. Besonders gefährlich wird es dann, wenn der Cluster direkt mit dem Internet verbunden ist und so jedermann offensteht, ohne dass für den Zugriff ein Passwort nötig wäre.

Früher wurde empfohlen, zwischen Client und Cluster einen Nginx-Server mit einfacher Authentifizierung zu schalten. Es kann aber unglaublich schwer sein, diese Konfiguration korrekt hinzubekommen. Da jeder Knoten externe Anfragen bedienen kann, kann jedermann ohne Authentifizierung eine Verbindung zum Cluster herstellen, sofern der Knoten nicht durch eine Firewall geschützt wird.

Wir erlauben jetzt kostenlos die Authentifizierung mit den Realms native und file. Das Realm „file“ speichert auf jedem Knoten Nutzerinformationen in einer Datei. Sie müssen sicherstellen, dass die Dateien auf allen Knoten synchronisiert bleiben. Das Realm „native“ ist etwas geradliniger in der Nutzung und tut so ziemlich das, was man erwarten würde: Die Nutzerdaten werden in einem Index auf dem Cluster gespeichert, auf den jeder Knoten zugreifen kann. Damit sich die Nutzer einloggen können, müssen Sie einfach nur über eine REST-API Nutzernamen und Passwörter hinzufügen. Näheres können Sie dem Blogpost zu den ersten Schritten mit Elasticsearch Security entnehmen.

Falls Ihre Authentifizierungsanforderungen komplexer sind, Sie also LDAP, Active Directory, SAML oder etwas anderes benötigen, bieten wir einen Cloud-(SaaS-)Service, der neben anderen kommerziellen Features auch einige dieser Features bereitstellt. Alternativ sind auch verschiedene On-Premise-Lösungen denkbar. Kontaktieren Sie uns einfach. Einen Überblick über die verschiedenen Authentifizierungsoptionen in unserem Angebot finden Sie in der Dokumentation zur Authentifizierung.

Autorisierung

Autorisierung und Authentifizierung gehen in der Regel Hand in Hand und der Elastic Stack ist da keine Ausnahme. Wir verfügen über ein sehr flexibles System, das Autorisierungsregeln für den Cluster und Indizes definieren kann – bis hinunter zu einzelnen Dokumenten und Feldern. Unser Angebot umfasst sogar eine Autorisierungs-Engine, mit der Sie ein eigenes Autorisierungs-Plugin erstellen können.

Die früheren Ratschläge und Tipps zum Thema muten recht ungehobelt an. So wurde vorgeschlagen, ziemlich komplexe Filterregeln mit einem Proxy wie Nginx zu schreiben und dann zu versuchen, gefilterte Aliasse zu nutzen, um zu etwas zu gelangen, das einer Autorisierung annähernd gleichkommt. Aus heutiger Sicht raten wir dringend davon ab, derartige Methoden für die Autorisierung zu verwenden. Sie sind keine Security-Features, dürften in der Regel ihren Zweck verfehlen und lassen sich nur mit größtem Aufwand pflegen. Mit diesen Lösungen erreichen Sie Ihre eigentlichen Ziele nicht mehr, da sich die Zahl der Elasticsearch-APIs im Laufe der Zeit deutlich erhöht hat. Es gibt viele Möglichkeiten, auf Indizes und die in ihnen enthaltenen Daten zuzugreifen und sie abzufragen, und Sie können sich niemals sicher sein, dass es Ihnen gelungen ist, jede einzelne Anfrage zu blockieren oder einzuschränken. Der zweite Grund hat mit dem ersten zu tun, denn die Zahl der zu schützenden Endpunkte ist riesig und wir fügen ständig neue hinzu. All diese Filter auf dem neuesten Stand zu halten, ist einfach viel zu aufwendig.

Aber zum Glück müssen Sie sich darüber keine Gedanken mehr machen. In 6.8 und 7.1 haben Sie Zugriff auf eine große Zahl von Autorisierungsfunktionen – so viele, dass eine genauere Beschreibung den Rahmen dieses Blogposts sprengen würde. Wenn Sie mehr über all die bestehenden Berechtigungen erfahren möchten, sollten Sie sich die Elastic Stack-Security-Dokumentation ansehen. Es ist geplant, in künftigen Blogposts einige der Lösungen zu besprechen, die mit unserem Berechtigungsmodell erstellt werden können.

Wie bei der Authentifizierung gibt es auch bei der Autorisierung weiterführende Funktionen, die auf einzelne Dokumente und Felder angewendet werden können. Sie können eigene Authentifizierungs- und Autorisierungs-Plugins entwickeln und sogar die Sicherheitsereignisse auf dem Cluster protokollieren. Dazu steht Ihnen unser Cloud-Service zur Verfügung, aber wenn Sie On-Premise bevorzugen, ist auch das möglich. Kontaktieren Sie uns.

Stack durch VPN und/oder Firewall absichern

Häufig wurde in der Vergangenheit geraten, den Elastic Stack hinter einer Firewall oder einem VPN zu platzieren. Diese Tipps wurden in den meisten Fällen damit begründet, dass es ohne TLS und Authentifizierung schwer wäre, Cluster nur mit einem Proxy zu schützen. Es schien somit leichter, den Zugang für alle zu sperren, als zu versuchen, die beweglichen Teile richtig zu konfigurieren.

Wenn Sie dies weiterhin tun möchten, selbst mit TLS und Authentifizierung, kann das durchaus sinnvoll sein. Für maximale Sicherheit braucht es mehrere Schichten. Das Schöne ist, dass VPN und Firewall nicht länger die einzige Schicht mehr sind.

Eingeschränkte Skripte

Wir hatten vor langer Zeit mal einen Blogpost, in dem beschrieben wurde, wie man den Skripting-Zugriff in Elasticsearch einschränken kann. Mit der Einführung der Skripting-Sprache Painless ist es mittlerweile viel schwieriger geworden, einen Cluster in die Knie zu zwingen, selbst dort, wo Skripte mit böswilligen Absichten eingeschleust werden – unmöglich ist es aber nicht. Daher verweise ich hier auf unsere Dokumentation zur Skripting-Sicherheit, in der wir Best Practices beschreiben und Auskunft geben, wie wir heute zu diesem Thema stehen. Wie sonst auch, empfiehlt es sich, einen genaueren Blick auf die Umgebung zu werfen und sich für die Schritte zu entscheiden, die für den konkreten Fall am sinnvollsten erscheinen. Für ein Maximum an Sicherheit sollten mehrere Schichten von Maßnahmen zum Einsatz kommen. Das ist aber immer individuell und es gibt kein Patentrezept, das auf alle Fälle zutrifft.

Cluster und Knoten isolieren

Vielfach wurde auch erwähnt, dass es Sinn mache, den Cluster und die Knoten aus Sicherheitsgründen zu isolieren. Das kann so ziemlich alles umfassen, von Containern über Firewalls bis hin zu IP-Filtern.

Dieser Ansatz ist weiterhin voll und ganz gültig: Die Sicherheit profitiert, wenn alles, was isoliert werden kann, auch wirklich isoliert wird. In den letzten Jahren haben wir eine Menge unternommen, um dies einfacher zu machen. Sie können unsere offiziellen Container-Images auf Docker Hub verwenden. Sie können den Elasticsearch Service nutzen und die Schwerarbeit uns überlassen. Und Sie können unseren nagelneuen offiziellen Kubernetes-Operator ausprobieren.

Indizes sichern (vor allem .kibana, da hier leicht Änderungen vorgenommen werden können)

Daten in Backups zu sichern, ist so wichtig wie eh und je. Security-Features ändern daran überhaupt nichts, aber wir können dem alten Hund ein paar neue Tricks beibringen.

Der größte Vorteil ist, dass wir mit Kibana Spaces festlegen können, wer bestimmte Dashboards ändern kann. Auch das gehört zu den Features, die seit Version 6.8 und 7.1 kostenlos zur Verfügung stehen. Früher war es so, dass jemand, der Zugriff auf Kibana hatte, im Prinzip alles nach eigenem Gusto hätte ändern können. Es kam nicht selten vor, dass jemand die Dashboards in Unordnung gebracht oder, im schlimmsten Fall und ganz ohne Absicht, alle Dashboards gelöscht hat. Zum Schutz der Daten wurde geraten, den .kibana-Index regelmäßig zu sichern, um im Notfall schnell wieder alles parat zu haben. Das Wiederherstellen eines Index geht wesentlich schneller, als alle Dashboards neu aufzusetzen. Es ist weiterhin wichtig, .kibana zu sichern, aber dank Spaces und Autorisierung sollte das regelmäßige Wiederherstellen heute nicht mehr auf der Tagesordnung stehen.

Ein weiterer großer Vorteil für die Sicherheit ist die Möglichkeit zu steuern, wer Snapshots erstellen, einen Index anlegen und Daten ändern kann. Ohne die Security-Features kann es passieren, dass jemand, der eigentlich nur Leserechte besitzen dürfte, katastrophale Änderungen an den Daten vornimmt. Die Security-Features erlauben es uns aber, Schritte einzuleiten, die – hoffentlich – ungewollte Änderungen an wichtigen Daten verhindern.

Wie gehts weiter?

In diesem Blogpost haben wir uns einige der Ratschläge und Tipps zur Absicherung von Elastic Stack-Deployments aus der Vergangenheit noch einmal angesehen und sie neu bewertet. In der Welt der Security ist die einzige Konstante der Wandel. Auch die Tipps in diesem Blogpost werden eines Tages veraltet und falsch sein. Die Aufgabe, den Elastic Stack sicher zu machen, kann einen angesichts der Vielzahl möglicher Optionen leicht überwältigen. (Dass es so viele möglichen Optionen gibt, ist aber gewollt und sinnvoll.) Lassen Sie sich nicht kleinkriegen, sondern nutzen Sie die Foren und lesen Sie unsere Blogs und die Dokumentation.

Wenn Sie Ihren Elastic Stack lieber per Knopfdruck absichern möchten, hätten wir da ein paar Optionen für Sie. Bei unserem Elasticsearch Service ist TLS für alle Cluster konfiguriert und sowohl Authentifizierung und Autorisierung als auch unsere Enterprise-Security-Features sind standardmäßig aktiviert. Wenn Cloud Ihnen nicht behagt, können Sie mit Elastic Cloud Enterprise (ECE) viele dieser Features im Elasticsearch Service bei sich im Rechenzentrum nutzen. Wir haben auch einen Kubernetes-Operator, der Ihnen etwas von der Schwerarbeit abnimmt, wie das Aktivieren von TLS und das standardmäßige Konfigurieren der Authentifizierung. Und als Enterprise-Kunde mit eigenem Stack steht Ihnen natürlich auch unser fantastisches Support-Team mit Rat und Tat zur Seite.

Wir haben für die Zukunft noch eine Menge in petto – Sie dürfen gespannt sein. Neben einer Reihe neuer How-To-Anleitungen sind auch etliche neue Security-Features in Planung. Das sind fürwahr aufregende Zeiten!