Sicherheit

• PKI in Elasticsearch
• Daten bei der Übertragung schützen
• Zertifikate
• Ruhende Daten schützen
• Rollenbasierter Zugriff
• Sensible Daten

PKI in Elasticsearch

Ab Version 5.0 war das alte Plug-in für die TLS-Aktivierung veraltet und wurde durch ein neues Plug-in mit dem Namen X-Pack ersetzt. X-Pack bietet eine Reihe von zusätzlichen Funktionen, die an Benutzer in Unternehmen vertrieben werden; es ist jedoch eine Lizenz erforderlich. Die Funktionen sind für einen Zeitraum von 30 Tagen eingeschränkt nutzbar und kostenlos; danach werden alle X-Pack-Funktionen inaktiviert.

Search Guard ist ein weiteres Produkt, das sicherheitsrelevante Plug-ins für den ELK-Stack bietet. Im Gegensatz zu X-Pack werden einige zugehörige Funktionen in der Kategorie Community Edition angeboten, wodurch sie keiner eingeschränkten Nutzung unterliegen. Wie in der Readme-Datei angegeben, bietet Search Guard alle grundlegenden Sicherheitsfunktionen kostenlos an. Die Community Edition von Search Guard kann für alle Projekte, einschließlich kommerzieller Projekte, absolut kostenfrei genutzt werden. Die TLS-Verschlüsselung mit PKI ist eine dieser Community Edition-Funktionen.

Der IBM Cloud Private-ELK-Stack verwendet standardmäßig Search Guard, um PKI bereitzustellen. Wenn Sie bereits über eine Lizenz für X-Pack verfügen oder den Erwerb einer solchen planen, können Sie während der Bereitstellung die folgenden Parameter angeben, um den ELK-Stack für die Verwendung der PKI-Bereitstellung von X-Pack zu konfigurieren. Für die Installation der Lizenz nach Bereitstellung ist der Kunde verantwortlich.

   logging:
     security:
       provider: xpack

Daten bei der Übertragung schützen

Jede Bereitstellung des Elasticsearch-Stacks wird standardmäßig durch die gegenseitige Authentifizierung über TLS geschützt. Der verwaltete ELK-Stack ist außerdem so konfiguriert, dass die vom Stack verwendeten Zertifikate von der IBM Cloud Private-Zertifizierungsstelle unterzeichnet werden. Für alle anderen ELK-Stacks gilt als Standard, dass bei der Bereitstellung eine eigene Zertifizierungsstelle erstellt wird. Um die Sicherheit für weitere ELK-Stacks ein- oder auszuschalten, inaktivieren Sie die Sicherheit in der Katalogbenutzerschnittstelle oder die Werteüberschreibungsdatei für die Helm-Bereitstellung.

• Helm

Das folgende Snippet kann einer Datei mit Überschreibungswerten für die Helm-Bereitstellung hinzugefügt werden, um die Sicherheit ein- bzw. auszuschalten.

  security:
    enabled: true|false

Zertifikate

Alle Verbindungen zu Elasticsearch müssen so konfiguriert werden, dass bei eingeschalteter Sicherheit ordnungsgemäß signierte Zertifikate ausgetauscht werden. Die IBM Cloud Private-Architektur des ELK-Stacks generiert eine Anzahl Zertifikate, die auf unterschiedliche Rollen angewendet werden. Alle werden in demselben geheimen Kubernetes-Schlüssel gespeichert und verwenden die folgende Namenskonvention: <release_name>-ibm-icplogging-certs.

Ruhende Daten schützen

Der Elasticsearch-Stack bietet intern keine Datenverschlüsselung für ruhende Daten. Das Unternehmen Elastic empfiehlt zum Erreichen dieses Ziels Lösungen anderer Anbieter. IBM Cloud Private enthält Anweisungen für unterstützte Methoden, wie Daten auf Platte verschlüsselt werden können. Weitere Informationen finden Sie unter Von IBM Cloud Private verwendete Datenträger verschlüsseln.

Rollenbasierter Zugriff

Mit Version 2.0.0 des Helm-Diagramms ibm-icplogging (in IBM Cloud Private 3.1.0 enthalten) wurde ein neues Modul eingeführt, von dem die rollenbasierte Zugriffssteuerung (RBAC) für alle Aufrufe der Elasticsearch-REST-API bereitgestellt wird. Das neue Modul ist nur für verwaltete ELK-Stacks verfügbar.

Das RBAC-Modul ist eigentlich ein Proxy, der den einzelnen Elasticsearch-Client-Pods vorgeschaltet ist. Für alle Verbindungen ist Voraussetzung, dass die zugehörigen Zertifikate von der Zertifizierungsstelle für Elasticsearch-Cluster signiert sind. Hierbei handelt es sich standardmäßig um die IBM Cloud Private-Stammzertifizierungsstelle. Vom RBAC-Modul werden die Anforderung nach einem Berechtigungsheader (authorization) untersucht und an diesem Punkt rollenbasierte Steuerungen erzwungen. Die Regeln für die rollenbasierte Zugriffssteuerung lauten im Allgemeinen wie folgt:

1. Ein Benutzer mit der Rolle Clusteradministrator kann auf beliebige Ressourcen (Prüf- oder Anwendungsprotokolle) zugreifen.
2. Einem Benutzer mit der Rolle Prüfer wird der Zugriff auf Prüfprotokolle nur in den Namensbereichen erteilt, für die dieser Benutzer berechtigt ist. Wenn Prüfprotokolle an ELK und nicht an das vorgeschlagene vorhandene Enterprise-SIEM-Tool weitergeleitet werden, lesen Sie die Informationen im Abschnitt Integration der IBM Cloud Private-Prüfprotokollierung mit SIEM-Tools für Unternehmen.
3. Ein Benutzer mit einer beliebigen anderen Rolle kann auf Anwendungsprotokolle nur in den Namensbereichen zugreifen, für die dieser Benutzer berechtigt ist.
4. Abgelehnt werden alle Versuche eines Prüfers, auf Anwendungsprotokolle zuzugreifen, bzw. eines Benutzers, bei dem es sich nicht um einen Prüfer handelt, auf Prüfprotokolle zuzugreifen.

Die RBAC-Regeln bieten eine grundlegende Datenabrufsteuerung für Benutzer, die auf Kibana zugreifen. Von den Regeln wird nicht verhindert, dass Metadaten wie z. B. Protokollfeldnamen oder gespeicherte Kibana-Dashboards angezeigt werden.

Sensible Daten

Möglicherweise ist es erforderlich, dass Sie sensible Daten maskieren, bevor diese Elasticsearch erreichen. Logstash wird mit einem hilfreichen Plug-in mit dem Namen 'mutate' bereitgestellt, das viele Funktionen zum Suchen von Daten bietet, die als sensibel betrachtet werden. Wenn diese Masken hinzugefügt werden sollen, muss die Logstash-Konfiguration angepasst werden, die sich in der Regel in einer Konfigurationszuordnung (configmap) mit dem Namen <release_name>-ibm-icplogging-logstash-config befindet; hierbei ist release_name der Releasename, mit dem die angegebene Helm-Diagramm-Bereitstellung bezeichnet wird.

Änderungen an der Logstash-Konfiguration werden nach einer kurzen Verzögerung automatisch an die bereitgestellten Container weitergegeben.

Änderungen an Konfigurationszuordnungen gehen verloren, wenn Sie das Protokollierungsdiagramm erneut bereitstellen. Beispiel: Sie führen ein Upgrade auf eine neue Version durch.