Seite wählen

Securing Elasticsearch

von | Mrz 3, 2016 | Elastic Stack

The English version of this post is available here.
Woah, was für ein Thema: Datenschutz
Und damit meine ich nicht das allseits bekannte Thema und die seit jeher leidenschaftlich verfochtenen persönlichen Daten. Nein, wovon ich rede sind die Daten, die in Elasticsearch landen. Wobei dort sicher auch bei dem einen oder anderen Personen bezogene Daten hinterlegt sind, keine Frage.
Viele setzen bereits diverse Lösungen ein, um den Zugriff auf Elasticsearch zu steuern. Das geht von einfachen URL-Filtern, über dedizierte Reverse Proxies mit Authentifizierung bis hin zu Elasticsearch’s hauseigener Rundum Lösung „Shield“. Doch was sie alle gemeinsam haben: Sie sind nicht für jeden geeignet, da sie entweder zu eingeschränkt hinsichtlich der Funktionalität oder schlicht zu teuer in der Anschaffung sind.
Deshalb kam eine namhafte Größe aus der Automobil-Branche auf uns zu, und schlug vor eine Opensource Lösung zu entwickeln, um all das in einem Produkt zu integrieren. Heraus kam ein von Grund auf neu geschriebener Reverse Proxy Dienst, welcher Authentifizierung und Autorisation auf Index-, Typ- und Feld-Ebene sowie auf Basis konkreter Funktionalitäten von Elasticsearch’s REST API vereint. Das ganze hat natürlich auch einen Namen: ElasticArmor
In der ersten Version werden zwar vorerst nur normale Anfragen die von Kibana stammen in vollem Umfang berücksichtigt, doch da das Projekt Opensource ist und mit der Absicht leicht zu erweitern zu sein geschrieben wurde, gehen wir davon aus nicht lange auf Erweiterungen warten zu müssen. Außerdem erfordert die Natur des Dienstes die zusätzliche Absicherung des angebundenen Elasticsearch-Cluster mittels eines Sicherheitsperimeters, da nur die Kommunikation zwischen Cient und Elasticsearch eingeschränkt wird, nicht jedoch die Kommunikation der einzelnen Elasticsearch-Nodes.
Doch wie funktioniert der ElasticArmor nun eigentlich? Nun, eigentlich ganz einfach. Ein Client der eine Anfrage an Elasticsearch stellt, muss zuerst am ElasticArmor vorbei. Ein Client ist, per Definition, der Ursprung der Anfrage. Dabei kann es sich um einen weiteren Dienst wie z.B. Kibana oder eine bestimmte Person handeln. Authentifizierung bedeutet allerdings nicht zwingend, dass es sich um eine reale Person mit Namen und Passwort handeln muss, es kann genauso gut ein anonymer Zugriff von einer ganz bestimmten IP sein.
Erhält der ElasticArmor nun letztendlich eine Anfrage von einem authentifizierten Client, werden die ihm zugeordneten Rollen angewendet. Diese definieren was und wie viel er darf. Angewendet werden sie, indem die URL der Anfrage und der Körper der selben analysiert werden. Im Falle der URL ist das nicht weiter schwer, doch der Körper einer Anfrage (z.B. Search-API) ist wesentlich komplexer. Aus diesem Grund ist dem ElasticArmor genau bekannt was für Möglichkeiten ein Client in einer solchen Anfrage hat. Trifft er auf etwas das ihm nicht bekannt ist, (z.B. ein neu eingeführtes Query) wird die Anfrage sofort abgelehnt. Dies verhindert Sicherheitslücken wenn die Version von Elasticsearch aktualisiert wird, ohne Rücksicht auf die Kompatibilität mit dem ElasticArmor zu nehmen.
Verändert wird eine Anfrage nur, wenn sich das Ergebnis nicht grundlegend ändert. Das bedeutet z.B. dass Queries, Filter, Aggregationen o.Ä. nicht verändert werden, die URL potentiell jedoch schon, jedenfalls was Indizes, Dokumente und Felder anbelangt. Auch das Source filtering wird verwendet um sicher zu stellen, dass jemand nur das sieht was er sehen darf.
Einige Features von Elasticsearch sind jedoch nur sehr schwer bis gar unmöglich einzuschränken, (z.B. Fuzzy Like This, Fuzzy Like This Field und More Like This) weshalb bei diesen nur das Recht sie zu benutzen sicher gestellt wird. Man sollte also aufpassen wem man dieses Recht gestattet.
Desweiteren verhält sich der ElasticArmor nach außen hin wie Elasticsearch. Schließlich ist er es mit dem sich ein Client tatsächlich unterhält. Somit sollte eine relativ problemlose Integration in die bereits bestehende Infrastruktur möglich sein.
Das war’s dann auch schon wieder. Ich hoffe ich konnte das Interesse, insbesondere die Vorfreude, bei dem einen oder anderen wecken. Bei Fragen, bitte einfach drauf los kommentieren!

Johannes Meyer
Johannes Meyer
Lead Developer

Johannes ist seit 2011 bei uns und inzwischen, seit er 2014 die Ausbildung abgeschlossen hat, als Lead Developer für Icinga Web 2, Icinga DB Web sowie alle möglichen anderen Module und Bibliotheken im Web Bereich zuständig. Arbeitet er gerade mal nicht, macht er es sich bei schlechtem Wetter am liebsten zum zocken oder Filme/Serien schauen auf dem Sofa gemütlich. Passt das Wetter, geht's auch mal auf eines seiner Zweiräder. Motorisiert oder nicht.

1 Kommentar

  1. Alexandra H

    Hallo Johannes,
    danke für den tollen Blogbeitrag!
    Im Rahmen der Recherche fiel mir auf dass das ElasticArmor veraltet ist. Gibt es denn inzwischen gute Alternativen hierzu? (ausser SearchGuard)
    LG
    Alexandra

    Antworten

Trackbacks/Pingbacks

  1. Securing Elasticsearch › NETWAYS Blog - […] This is the English version of my last week’s post. […]

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Elastic Stack

Kibana Sicherheits-Updates: CVSS:Critical

Und täglich grüßt das Murmeltier. Nein nicht ganz. Heute ist es  aus der Elastic Stack Werkzeugkiste Kibana, für das es ein wichtiges Sicherheits-Update gibt. Es besteht auf jeden Fall Handlungsbedarf! IMHO auch wenn ihr die "Reporting" Funktion deaktiviert habt. Der...