Zero Trust entschlüsselt — Die Definition von Armon Dadgar im Praxis-Check
Im September 2023 präsentierte HashiCorp CTO und Co-Founder Armon Dadgar [1], was er unter Zero Trust versteht und wie man das Sicherheitskonzept mit HashiCorp Produkten umsetzen kann [2]. In diesem Blog analysieren wir die Zero Trust Definition von Armon und stellen verschiedene praxistaugliche Ansätze vor, wie man diese bereits heute mit unterschiedlichen Produkten umsetzen kann.
Autoren: Christian Fehlmann und Ryan Aebi
Was ist Zero Trust?
Gemäss Armon Dadgar besteht Zero Trust aus den folgenden beiden Prinzipien:
- Authentisiere und autorisiere explizit (authenticate and authorize explicitly)
- Unterbinde Zugriffe standardmässig (deny by default)
Weitere Definitionen und Umsetzungsmöglichkeiten von Zero Trust findest du im Kontext GCP von Matthias Hert [4] oder im Kontext Microsoft von Christian Fehlmann und Michael Wachter [5]. Wie diese Ansätze mit dem Open Policy Agent erweitert werden können, erklären Ryan Aebi [7] und Christian Sanabria [8].
Das Prinzip «authentisiere und autorisiere explizit»
Damit ist gemeint, dass keiner Anfrage per se vertraut wird. Es werden nur Anfragen akzeptiert und weiterverarbeitet, nachdem mittels kryptographischer Verfahren überprüft werden konnte, von wem die Anfrage gestellt wurde (Authentisierung) und ob die Anfrage die notwendigen Berechtigungen besitzt (Autorisierung). Es sind weiterhin Vertrauensbeziehungen notwendig (z.B. zu einem Security Token Service), diese sind nun jedoch transparent ersichtlich. Im Kern geht es jedoch darum, dass dem Netzwerk und den Netzwerkkomponenten nicht mehr blind vertraut wird.
Das Prinzip «unterbinde Zugriffe standardmässig»
Vor dem Aufkommen von Zero Trust basierte die Vertrauensarchitektur hauptsächlich auf der Netzwerkebene. Dabei hat man das Netzwerk in verschiedene Segmente aufgeteilt und diese mittels Firewalls voneinander getrennt. Ein Segment entspricht dabei einer Vertrauensdomäne. Das bedeutet, allen Netzwerkteilnehmern innerhalb eines Segments wird grundsätzlich vertraut. Mittels Firewallfreischaltungen hat man zusätzlich die Möglichkeit, Anfragen von anderen Segmenten Zugriff auf einzelne Teile dieser Vertrauensdomäne zu gewähren. Diese Architektur funktioniert nur dann, wenn man davon ausgeht, dass es ein Angreifer niemals schaffen wird, in ein Segment einzudringen. Denn andernfalls ist sofort die gesamte Domäne kompromittiert. Man spricht dabei traditionell vom Perimeter-Schutz (siehe Abb. 1).
Mit dem standardmässigen Unterbinden von Zugriffen können wir den Schweregrad einer Attacke signifikant reduzieren, da nur noch Netzwerkzugriffe erlaubt sind, welche effektiv für den Betrieb notwendig sind. Bei Zero Trust werden Vertrauensbeziehungen feingranular auf Level Applikation gemanagt und nicht mehr auf Segmentebene (siehe Abb. 1). Dies ist besonders relevant beim Wechsel in die Public-Cloud, wo es keinen klar definierten Perimeter mehr gibt.
Implementierung mittels Identity-based Controls
Wie können wir nun diese beiden Prinzipien in die Tat umsetzen? Nach Armon Dadgar geht das am Besten mittels Identity-based controls. Dabei unterscheidet er zwischen persönlichen und unpersönlichen Identitäten, sowie Maschine-Maschine- und Mensch-Maschine-Kommunikation (siehe Abb. 2). Diese vier Aspekte müssen implementiert sein, damit man gemäss Armon von einer erfolgreichen Zero Trust Umsetzung sprechen kann. Im Folgenden gehen wir auf diese vier Aspekte ein und präsentieren Produkte, mit welchen man diese umsetzen kann.
Identitäten
Persönliche und unpersönliche Identitäten bilden zusammen das Fundament für die Mensch-Maschine- und Maschine-Maschine Kommunikation. Nur mit eindeutiger Identität und fälschungssicheren Ausweisen können wir die Vertrauensbasis schaffen, um einer Applikation die Entscheidung zu ermöglichen, ob einer Identität der Zugriff gewährt wird.
Unpersönliche Identität
Da nicht nur persönliche Identitäten Akteure in der IT sind, braucht es zusätzlich Identitäten für unpersönliche Entitäten (Server, Prozesse, Services, etc.). Dabei ist es wichtig, dass sich diese unpersönlichen Identitäten ebenfalls ausweisen können, um sich an einem System zu authentifizieren. Das Format des Authentifizierungsmerkmals z.B. API-Key, JWT-Token oder X509 Zertifikat kann sich von persönlichen Identitäten unterscheiden; zentral ist aber, dass sich eine unpersönliche Identität jederzeit ausweisen kann.
Technologien
Hier eignet sich Hashicorp Vault, da damit Tokens, Passwörter, Zertifikate und private Schlüssel verwaltet und mittels gängigen Tools (UI, CLI oder einer REST API) integriert und verwendet werden können. Ferner erlaubt Vault auch automatisiert Secrets zu rotieren, eine Best Practise. Jakob Beckmann geht in seinem Blog [9] genauer darauf ein.
Die grossen Public Cloud Anbieter haben ihrerseits native Services, mit welchen man diesen Aspekt auch umsetzen kann. Das wären der Azure Key Vault, Google Secret Manager und AWS Secret Manager.
Persönliche Identitäten
Jedem menschlichen / persönlichen Benutzer, der in irgendeiner Art mit den IT Systemen interagiert, muss mindestens eine eindeutige Identität zugewiesen sein. Dabei spielt es keine Rolle, ob der Benutzer ein Mitarbeiter, Partner, etc. der Firma ist. Jedem Benutzer wird ein Authentifizierungsmerkmal zugewiesen, mit welchem er und nur er sich gegenüber den IT Systemen eindeutig ausweisen kann.
Technologien
Zum effizienten Verwalten von menschlichen Entitäten werden oft Produkte basierend auf SAP und Active Directory eingesetzt. Hashicorp hat dafür kein dediziertes Produkt, da es bereits etablierte Produkte auf dem Markt gibt und diese den Zweck erfüllen. Unternehmen, welche nur in der Cloud agieren, können auch cloud-native Produkte verwenden wie Microsoft Entra ID, Google Workspace oder AWS IAM Identity Center.
Kommunikation
Nachdem alle Akteure einen Identitätsnachweis erhalten haben und diesen nach Bedarf vorweisen können, haben wir die Grundlage für eine sichere Kommunikation geschaffen. Wir teilen die Kommunikation in 2 Kategorien auf:
- Maschine zu Maschine
- Mensch zu Maschine
da diese unterschiedliche Herausforderungen mit sich bringen und daher technisch anders gelöst werden müssen.
Maschine-Maschine Kommunikation
Damit wird die Kommunikation zwischen zwei unpersönlichen Identitäten bezeichnet. Als Beispiel nehmen wir einen Cron-Job, welcher regelmässig eine API Abfrage absetzt.
Beide Identitäten benötigen Ausweise, damit einerseits der Cron-Job die Anfrage verschlüsselt an den richtigen API Service macht und andererseits der API Service den Cron-Job authentisieren und autorisieren kann. Als weitere Sicherheitsmassnahme, man spricht hier auch von Defense in depth, erlaubt das Netzwerk dem Cron-Job nur Verbindungen zum API Service aufzubauen. Damit wird verhindert, dass der Cron-Job eine Liste von anderen Netzwerkteilnehmern erstellen kann. Dafür wird oftmals ein Service-Mesh eingesetzt, welches den Netzwerk-Layer für die Systeme sicher abstrahiert [11].
Technologien
Als Technologie wird von Hashicorp das Produkt Consul [10] angeboten, mit welchem man Netzwerkverbindungen sicher verwalten kann. Dabei stellt Consul sicher, dass jede Kommunikation authentisiert und autorisiert ist, wie von Zero Trust gefordert. Als Identitätsnachweise werden Zertifikate verwendet, die für unpersönliche Identitäten ausgestellt wurden.
Es gibt viele alternative Service Mesh Produkte zu Consul, welche wir auch schon bei diversen Kunden integrieren durften, wie z.B. Istio oder Google’s Anthos Service Mesh. Eine schöne Übersicht und Vergleiche zwischen den verschiedenen Service Mesh Produkten wird von Layer5 zur Verfügung gestellt [3].
Mensch-Maschine Kommunikation
Die sichere Kommunikation zwischen Menschen und Maschinen baut auf den persönlichen und unpersönlichen Identitäten auf. Ein klassisches Beispiel ist der Zugriff eines Entwicklers auf eine Datenbank. Da in den meisten Fällen nicht jeder Entwickler auf alle Datenbanken zugreifen darf, muss anhand der Identitäten beider Entitäten explizit überprüft werden, ob der Zugriff legitim ist. Dabei möchte man die Frage beantworten, ob ein Entwickler A vom Gerät B auf der Datenbank C eine Aktion D ausführen darf.
- Auf der Netzwerkebene wird regelbasiert überprüft, ob das Gerät B eine Verbindung mit der Datenbank C herstellen darf. Sofern dies der Fall ist, können das Gerät B und die Datenbank C ihre Identitätsnachweise verwenden, um eine verschlüsselte Verbindung aufzubauen.
- Als nächstes muss die Datenbank C erstens den Sender der Anfrage (Entwickler A) authentisieren und zweitens überprüfen, ob dieser autorisiert ist, Aktion D auszuführen. Für hochsensitive Daten können zusätzliche Zugriffsregeln definiert werden, die mittels Policy Engine [7] erzwungen werden.
Technologien
Hashicorp Boundary [6] ermöglicht den Zugriff auf (kritische) Systeme basierend auf einer fein granularen Autorisierung, nachdem der Benutzer sich gegenüber Boundary authentifiziert hat. Dabei können Berechtigungsnachweise just-in-time ausgestellt (z.B. mittels HashiCorp Vault) und laufende Sessions aufgezeichnet werden.
Für das privilegierte Zugriffsmanagement gibt es diverse Alternativen zu Boundary, unter anderem CyberArk [12], welche in Kombination mit einem Identitätsprovider (IdP) eingesetzt werden können. Für Systeme mit weniger hohen Sicherheitsvorgaben, welche den just-in-time Aspekt und Session-Aufzeichnung nicht zwingend benötigen, kann man Zero Trust auch mit Hilfe eines IdP und eines Service Mesh umsetzen für Mensch-Maschine-Kommunikation.
Unsere Take Aways
Die Umsetzung einer Zero Trust Architektur ermöglicht es Dir, die Sicherheit Deiner Systeme auf das nächsthöhere Level zu heben. Es gibt bereits heute diverse, ausgereifte Produkte, mit welchen man Zero Trust basierend auf Identity-based Controls implementieren kann. Ein solides Identitätsmanagement für Menschen und Maschinen bildet dabei die Grundlage. Darauf aufbauend können wir die Kommunikation zwischen den verschiedenen Akteuren auf verschiedenen Ebenen absichern und nur diejenigen Verbindungen ad hoc aufbauen, welche auch tatsächlich benötigt werden und erlaubt sind.
Wie würdest Du Zero Trust definieren und implementieren? Wir freuen uns auf ein Gespräch mit Dir, in dem wir gemeinsam über konkrete Umsetzungsmöglichkeiten diskutieren können, so dass sich ein Angreifer an Deinen Systemen die Zähne ausbeissen wird.
Quellen
[1]: Armon Dadgar
[2]: Guild42: Zero Trust mit HashiCorp CTO Armon Dadgar
[3]: Service Mesh Landscape
[4]: So schützt Google Cloud die Kunden und deren Daten
[5] 6 Zero-Trust-Empfehlungen aus dem Colonial Pipeline-Angriff
[6] Boundary
[7] Sensitive Daten in Microservice-Architekturen mit konsistenten Policies schützen
[8] Mit dem Open Policy Agent Deine Datenzugänge sicher im Griff haben
[9]: Verbesserte Sicherheit mit weniger Aufwand ist kein Widerspruch!
[10]: HashiCorp Consul service mesh
[11]: Service Mesh - Mehr Produktivität in der Public Cloud
[12]: CyberArk Privileged Access Manager
Abbildung 1, sinngemäss nach: Developer.ibm.com
Über mich
Als IT Architekt fördere ich das Sicherheitsbewusstsein in Cloud-Teams und erschwere Angriffe auf IT-Organisationen mittels Zero Trust. Dabei setze ich auf moderne Kollaborationsansätze wie DevSecOps.
Über mich
Als IT Architect brenne ich für den Bereich Security, und fokussiere mich darauf, komplexe Themen wie Zero-Trust verständlich und praktisch umsetzbar zu machen.