For english content please see the blog post by Chris Jenkins at https://www.redhat.com/en/blog/openshift-security-hardening-healthcare-industry which essentially presents the same information as this post. Because of the importance of the topic and the ask from our german-language customers we wanted to also present this information in german.

“Security is not a product, it itself is a process”
Bruce Schneier

Der Schutz sensibler Daten bleibt eine stete Herausforderung, die nur durch die Berücksichtigung von Sicherheitsaspekten in allen Phasen einer Anwendung zufriedenstellend gelöst werden kann – von der Entwicklung bis zum produktiven Betrieb.

Im vorliegenden Artikel konzentriere ich mich auf den Aspekt des OpenShift-Betriebs. Tipps zum Anwendungsdesign bleiben außen vor, es geht hier nur um den reinen Betrieb von OpenShift. Ebenso außen vor bleibt die Verteidigung gegen DDOS (Distributed Denial of Service) Angriffe. Außen vor bleiben für diesen Post auch zusätzliche Tools wie z.B. “Advanced Cluster Security”.

Zunächst macht es uns OpenShift aus dem Blickwinkel der Security leicht, weil es mit dem Anspruch “secure-by-design” entwickelt wurde.

OpenShift abzusichern erfordert mehrere Maßnahmen, im Folgenden konzentriere ich mich darauf, was für Anwendungen im Gesundheitsumfeld besonders interessant ist. Die Maßnahmen sind je nach Umfeld häufig identisch, lediglich die Priorisierung verändert sich.

Auf welche Art von Szenarien müssen wir uns also einstellen?

Verhindern von Datenlecks
Reduktion der Angriffsfläche für externe Angriffe
Absichern gegen “Evil Admin”
Absichern gegen Supply Chain Angriffe

Zunächst sollte das OpenSCAP Profil “CIS Red Hat OpenShift Container Platform 4 Benchmark” angewandt werden, damit eine vernünftige Grundlage gegeben ist auf der wir im folgenden weiterarbeiten können.

Verhindern von Datenlecks

Gesundheitsdaten sind (nicht nur nach DSGVO oder HIPAA) besonders schützenswert. Was kann also im Kontext OpenShift getan werden?

Infrastruktur

Um zu verhindern, daß Daten in Richtung des OS exponiert werden, kann man self-encrypting disks (SED), verschlüsselten Enterprise-Storage oder verschlüsselten Block Storage bei einem externen Cloud Provider verwenden
Red Hat CoreOS unterstützt außerdem LUKS (Linux Unified Key Setup) mit TPM v2 (Trusted Platform Module) oder NBDE (Network Bound Disk Encryption, benötigt einen Tang Server)
OpenShift Container Storage bietet eine nach FIPS-140-2 zertifizierte Verschlüsselung
Die Nutzung eines Service Meshes wie Istio kann dabei helfen, Services und Daten zu sichern. Istio kann außerdem Zertifikate nach X.509 managen.

Im wesentlichen ist die Sicherheit von Daten abhängig davon, daß Daten gegen Veränderungen gesichert werden (“Data Integrity”). Manipulierte Daten sind ein mögliches Einfallstor für Angreifer.

Die Kern-Bestandteile von OpenShift

etcd (Key-Value-Store für alle Resource-Objekte)
API Server
Kubernetes Configuration Files
Container Runtime Binaries
Container Images
Kubernetes Binaries

sind durch folgende Maßnahmen geschützt

TLS ist generell der Schutz gegen Datenmanipulation für “Data in-transit”
Sämtliche Kommunikation mit dem API Server ist via TLS geschützt
Nur der OpenShift API Server darf mit etcd kommunizieren
Alle OpenShift Komponenten von Red Hat werden durch Kubernetes Operatoren verwaltet, dadurch wird “Configuration Drift” verhindert
Die Container-Laufzeitumgebung wird geschützt durch SELinux (Security-Enhanced Linux), Kernel- und Netzwerk-Namespaces, Cgroups und – optional – seccomp (Security Computing) Profile
OpenShift SCCs (Security Context Constraints) ermöglichen die Nutzung von RHEL Sicherheits-Features durch den Admin, z.B. um den direkten Zugriff auf das Filesystem oder das Netzwerk zu verhindern oder auch den Start privilegierter Container

Zusätzlich verbessern die folgenden Maßnahmen die Sicherheit der Daten im OpenShift Cluster

Einschränkung des Zugriffs auf die Control Plane durch einen separaten Ingress Controller
Einschränkung des Zugriffs auf Repositories durch OpenShift Configuration Files
Bootstrapping via SSH und sicheres Aufbewahren der SSH Keys
Einschränkung des Zugriffs auf die Image Registry und weitere Repositories
Verschlüsselung des etcd Datastore
Einführung eines Review Prozesses für den Sicherheits-Kontext von Pod-Manifesten, um unnötige Privilegien zu vermeiden

Obwohl das OpenShift Sicherheitsmodell durchgängig TLS vorschreibt, kann es nur so sicher sein wie die Ausgabestelle für Zertifikate (CA). Ein Kompromiß an dieser Stelle führt zum Aushebeln der TLS Sicherheit.

Best Practise ist es, die interne CA von OpenShift zu nutzen
Eine andere Best Practise ist es, Custom Certificates zu nutzen, jeweils unterschiedliche Zertifikate für interne Komponenten und externe Endpunkte
automountServiceAccountToken auf false setzen für Pods, die nicht mit dem API Server sprechen müssen
Nutzen von Secrets, um Zertifikate in Pods zu injizieren, welche die Pod Authentizität bestätigen
Nutzen externer Security Vaults zum Management von Application Secrets
Werden Service Token genutzt, auf jeden Fall expirationSeconds und audience setzen

Anwendungsentwicklung

DevOps abzusichern ist komplex, besonders wegen der ständigen Veränderungen. Container fügen weitere Komplexität hinzu und eröffnen neue Angriffsmöglichkeiten. Deswegen muß Sicherheit ein integraler Bestandteil des Entwicklungsprozesses sein.

Um das Risiko eines Datenabflusses zu verringern, sollten die in OpenShift vorhandenen Mittel ausgeschöpft werden. Als Beispiel dienen Pod Security Policies, Network Traffic Controls, Cluster Ingress und Egress Controls, RBACs (Role-Based Access Controls), integriertes Zertifikats-Management und Micro-Segmentation von Netzwerken.

Reduktion der Angriffsfläche für externe Angriffe

Aus den USA liegen Zahlen zu den erfolgreichen Angriffen der letzten zwei Jahre ( https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf ) vor. Daraus geht hervor, daß ca. zwei Drittel dieser Angriffe Hacking oder IT Vorfälle waren.

Um die Menge der erfolgreichen Angriffe zu reduzieren, muß Sicherheit ein integraler Bestandteil von Design, Implementierung und Weiterentwicklung jedes Systems sein, das besonders schützenswerte Daten enthält.

Infrastruktur

Einfaches Kubernetes erlaubt es Pods, ungehindert miteinander zu kommunizieren; Network Policies sollten dazu genutzt werden, einem Angreifer das Weiterkommen in einer Container-Umgebung zu erschweren. Der höchste Gewinn an Sicherheit entsteht durch die Anwendung von Ingress Policies; deswegen sollten diese an erster Stelle bei der Implementierung stehen. In einem weiteren Schritt sollten dann Egress Policies definiert werden. Beispielsweise hätte ein Log4Shell Angriff durch eine passende Egress Policy bereits im Vorfeld eingedämmt werden können. Nähere Details hierzu unter https://cloud.redhat.com/blog/log4shell-practical-mitigations-and-impact-analysis .

Network Policies stellen ein einfaches Mittel zur Filterung des Traffics dar. Paßt ein Pod zu den Selektoren, geht nur erlaubter Traffic zum Pod. Die folgenden Optionen können bei Network Policies gesetzt werden

Deny all traffic
Only allow connections from the ingress controller
Only accept connections within the same project
Only allow HTTP/HTTPS traffic based on pod labels
Accept connections by using namespace and pod selectors

Für weiter Informationen zu Ingress Policies siehe auch Guide to Kubernetes Ingress Policies.

Anwendungsentwicklung

Um die Vorteile einer schnelleren Entwicklung mit Hilfe von Containern und Kubernetes zu nutzen, muß Sicherheit ein integraler Bestandteil des Entwicklungsprozesses werden (“Shift-Left-Security”), um bereits während der Build Phase möglichst viele Risiken aus dem Weg zu räumen. Dadurch entsteht ein höheres Grundniveau an Sicherheit der erstellten Software. Dieser Ansatz macht auf Sicherheit spezialisierte Teams nicht überflüssig, sondern ergänzt ihre Arbeit.

Absichern gegen “Evil Admin”

Zwei Drittel aller Organisationen halten Angriffe durch Insider für wahrscheinlicher als durch externe Hacker. Die Anzahl interner Angriffe hat in den letzten Jahren um 47% zugenommen.

Ein Beispiel für den “Evil Admin” im Gesundheitswesen ist Jesse William McGraw, auch als “GhostExodus” bekannt. McGraw hat sich in 2010 schuldig bekannt, auf mehreren Rechnern eines Hospitals in Texas Malware installiert zu haben, darunter war auch ein Arbeitsplatz mit Zugriff auf Patientendaten. Er wurde zu 9 Jahren und 2 Monaten Gefängnis wegen der Installation der Malware verurteilt.

Mit Technologie allein kann man diese Art von Angriff nicht verhindern, aber Technologie kann dabei helfen, den Schaden zu begrenzen. Etablierte Praxis ist es mittlerweile, privilegierte Nutzer bzw. Aktionen über einen zweiten Faktor abzusichern (“2FA”, “Second Factor Authentication”); hierfür können sowohl Hardware Token als auch Mobile Apps zum Einsatz kommen. Privilegierte Aktionen sollten jederzeit nachvollziehbar sein, sowohl aus Sicherheits- als auch aus Compliance-Gründen. Dabei ist es egal, ob ein sicherheitsrelevanter Vorfall aus Absicht oder aus Versehen ausgelöst wird.

Infrastruktur

IAM (Identity and Access Management) und RBAC (Role-based Access Control) sind Kernbestandteile von OpenShift. In diesem Abschnitt geht es um die Absicherung des Zugriffs auf OpenShift selbst durch Admins oder Entwickler, nicht um die Absicherung einzelner Anwendungen wie sie z.B. für Web-Anwendungen üblich sind.

In OpenShift bestimmen RBAC Objekte die Art des Zugriffs für einen Nutzer. Cluster Admins haben verschiedenen Hilfsmittel zur Hand, um für Nutzer den Zugriff innerhalb von OpenShift zu freizugeben:

Regeln – erlaubte Operationen auf einer Menge von Objekten
Rollen – Gruppe von Regeln
Bindings – Zuweisungen zwischen Nutzern und Gruppen zu einer Rolle

Generell ist die Zuweisung von Rechten zu einer Gruppe der Zuordnung zu einem Nutzer vorzuziehen.

OpenShift legt im Rahmen der Installation automatisch einen Cluster Admin (“kubeadmin”) an. Dieser Nutzer ist automatisch cluster-admin für den erzeugten Cluster.

Nachdem ein Identity Provider definiert wurde und die cluster-admin Rolle entsprechend zugewiesen wurde, kann der kubeadmin Nutzer entfernt werden. Achtung: Wird der kubeadmin Nutzer vorher entfernt, muß der Cluster neu installiert werden.

Anwendungsentwicklung

Authentisierung und Autorisierung z.B. via OpenId Connect in einer Applikation zu implementieren kann sehr mühsam sein, ist aber wichtig zur Erhöhung der Sicherheit und zur Verringerung von Risiken.

Wird eine Anwendung neu für OpenShift entwickelt, kann dieser Bestandteil an Keycloak oder SSO ausgelagert werden.

Absichern gegen Supply Chain Angriffe

Vor allem durch den Angriff auf SolarWinds sind Supply Chain Attacks bekannt geworden. Sie setzen bei der CI/CD Pipeline eines Software-Herstellers an, so daß in der Folge potentiell alle Folge-Releases als kompromittiert betrachtet werden müssen. Wird ein solches kompromittiertes Release beim Kunden des Herstellers installiert, kann sich die Schad-Software in der Regel zunächst ungestört ausbreiten; dem Update des Software-Herstellers wird normalerweise vertraut.

Um sich gegen diese Art von Angriffen verteidigen zu können, müssen eine Reihe von Maßnahmen getroffen werden. Im Container-Umfeld bedeutet das z.B.:

nur vertrauenswürdige Container zuzulassen
eine eigene Container Registry innerhalb des Unternehmens zu betreiben
den Bau von Container zu kontrollieren und zu automatisieren
Sicherheit in die Build Pipeline integrieren

Zusammenfassung

Sensible Daten zu schützen ist immer wichtig, egal in welcher Industrie wir uns bewegen. Aber im Gesundheitswesen tragen wir eine besondere Verantwortung, weil der durch Datenlecks entstehende Schaden häufig nicht reparabel ist. In diesem Artikel wurden einige Maßnahmen vorgestellt, die zur Absicherung einer OpenShift-Umgebung beitragen können. Die wichtigste Erkenntnis muß jedoch bleiben, daß Sicherheit nur dann funktionieren kann, wenn allen Beteiligten ihre Wichtigkeit bewußt ist.