Zero Trust ist ein kompliziertes Framework, das sich über den gesamten IT-Stack erstreckt. Es gibt Gemeinsamkeiten, aber auch Unterschiede zu Software-defined Perimeter (SDP).
Das erste, was man über Zero Trust wissen muss, ist, dass es ein schlechter Name für ein mächtiges Konzept ist. Es geht nicht darum, nichts und niemandem zu vertrauen. Der springende Punkt ist vielmehr: Es wird kein Vertrauen vorausgesetzt. Alle Vertrauensbeziehungen müssen explizit angegeben werden.
Vielleicht wäre es besser, Zero Trust als Zero Implicit Trust, also als fehlendes implizites Vertrauen zu bezeichnen, unter Berücksichtigung aller Aspekte des impliziten Vertrauens. Dazu zählen:
Niemand besitzt ein implizites Recht, auf ein Netzwerk zuzugreifen – nur explizite Rechte, bestimmte Systeme über das Netzwerk zu erreichen.
Niemand besitzt ein implizites Recht, sich im Netzwerk aufzuhalten – nur ein explizites Recht, das Netzwerk zu nutzen, solange er sich an die Regeln hält und sein System keine Gefährdung darstellt.
Das Konzept des Software-defined Perimeters (SDP) geht auf die Arbeit der Defense Information Systems Agency (DISA) zurück, wurde aber im letzten Jahrzehnt von der Cloud Security Alliance (CSA) formalisiert und populär gemacht.
Ein SDP verkörpert die Prinzipien von Zero Trust auf Netzwerkebene. Damit werden Mechanismen eingeführt, um den Zugriff auf ein System auf Netzwerkebene zu kontrollieren sowie den Zugriff anzufordern und ihn zu gewähren. Ein SDP ist ein endpunktfokussiertes, virtuelles, stark segmentiertes Netzwerk, das über alle anderen bereits vorhandenen physischen und virtuellen Netzwerke gelegt wird.
SDP: Rollen und Aufgaben
Ein SDP stützt sich auf Controlleraußerhalb eines Netzwerks, um den Zugang zu diesem Netzwerk zu verwalten.
Der grundlegende Vorgang sieht so aus:
Eine Entität, die in dem geschützten Netzwerk kommunizieren möchte – ein sogenannter initiierender Host – muss die SDP-Software ausführen und sich bei einem SDP-Controller authentifizieren. Beachten Sie, dass die Authentifizierung mehrere Verifizierungsebenen voraussetzt, die von der Überprüfung eines Gerätezertifikats bis hin zur Integritätsprüfung aktiver Systeme reichen können. Zudem geht man davon aus, dass sie immer auch eine Benutzerauthentifizierung umfasst – vorzugsweise mit mehreren Faktoren.
Nach der Authentifizierung wird dem initiierenden Host mitgeteilt, mit welchen anderen Entitäten – als akzeptierende Hosts bezeichnet – er kommunizieren darf. Diese Hosts werden wiederum angewiesen, dem initiierenden Host zu erlauben, mit ihnen zu kommunizieren. Akzeptierende Hosts sind dem Controller bereits bekannt – sie haben sich bereits authentifiziert. Hosts, die dem Controller noch nicht bekannt sind, stehen nicht auf der Liste der zulässigen Hosts. Die Liste der akzeptierenden Hosts wird durch den Kontext bestimmt, je nachdem, welchen Dienst der initiierende Host zu erreichen versucht und was er mit diesem Dienst tun darf. Die Liste sollte nur die akzeptierenden Hosts enthalten, die für die angeforderte Kommunikation essenziell sind.
Der initiierende Host baut VPN-Tunnel direkt zu den angegebenen akzeptierenden Hosts auf. Beachten Sie, dass der Controller nicht Teil dieses verschlüsselten virtuellen End-to-End-Netzwerks ist.
Ein akzeptierender Host wird die gesamte Netzwerkkommunikation ablehnen oder verwerfen, die von einem Host ausgeht, der nicht auf der Liste der autorisierten initiierenden Hosts steht, die er vom Controller bezogen hat.
Controller und Hosts können sich On-Premises befinden oder nicht. Cloud Controller können die Kommunikation für Hosts überall verwalten, ebenso wie On-Premises Controller. Sogar SaaS-Optionen lassen sich – über Proxys oder Cloud Access Security Broker (CASB) – durch ein SDP schützen.
Einige Architekturen platzieren Gateway Hosts in der Umgebung. Diese fungieren als akzeptierende Hosts für Clients außerhalb der Umgebung – sei es ein Data Center oder eine Cloud – und führen die gesamte Kommunikation mit den Hosts durch, die eigentlich die Services bereitstellen. Initiierende Hosts sehen nur das Gateway und kommunizieren nie direkt mit der Infrastruktur, die Anwendungsdienste zur Verfügung stellt.
Ein wesentlicher Vorteil einer SDP-Implementierung besteht darin, dass akzeptierende Hosts für alle anderen Systeme oder Benutzer im Netzwerk unsichtbar sind, bis der Controller ihnen eine Verbindung erlaubt. Lediglich initiierende Hosts, denen der Controller erlaubt, eine Gegenstelle zu sehen, können sie auch sehen. Für alle anderen ist sie unsichtbar. Dies ist eine extrem gute grundlegende Sicherheitsstrategie und der Hauptgrund, warum DISA diesen Ansatz gefördert hat.
SDP ist (eine Form von) Zero Trust
Da SDP auf einer granularen Verwaltung der Verbindungsberechtigungen basiert, mit der Standardvorgabe Es fließt kein Traffic, der nicht explizit genehmigt wurde, ist SDP eindeutig eine Implementierung von Zero Trust.
Ein SDP verkörpert die Prinzipien von Zero Trust auf Netzwerkebene.
Zero Trust ist jedoch breiter angelegt und beinhaltet Konzepte, die in SDP nicht als essenziell betrachtet werden. Zum Beispiel erfordert Zero Trust eine dynamische Trust Map, die auf das Verhalten reagiert. Bei SDP ist das möglich, wird aber nicht als grundlegend angesehen.
SDP geht auch davon aus, dass die Hosts – gesteuert vom Controller – die einzigen Entitäten sind, die durchsetzen, ob Netzwerkkommunikation stattfindet, und Pakete von nicht genehmigten Kommunikationspartnern verwerfen. Alternativ dazu ermöglicht Zero Trust eine Infrastruktur, die aktiv teilnehmen kann und Traffic verwirft, bevor er überhaupt einen Host erreicht. Unter Zero Trust kann es eine netzwerkbasierte Komponente für das Traffic-Management geben, entweder zusätzlich zu oder anstelle von SDP.
Unternehmen, die eine umfassende Multi-Cloud-Sicherheitsbasis suchen, auf der sie aufbauen können, setzen auf das Konzept von Zero Trust. Sie sollten auch SDP-Tools als Ausdruck dieses Prinzips evaluieren.
