Was ist eine Zero Trust Architektur (ZTA) und warum ist sie wichtig

Es gibt einige Definitionen von Zero Trust bzw. Zero Trust Architektur. Schauen wir uns die Definition an, die vom amerikanischen Institute of Standards and Technology (NIST) herausgegeben wird:

“Zero trust provides a collection of concepts and ideas designed to minimize
uncertainty in enforcing accurate, least privilege per-request access decisions in
information systems and services in the face of a network viewed as compromised.
ZTA is an enterprise’s cybersecurity plan that uses zero trust concepts and
encompasses component relationships, workflow planning, and access policies.
Therefore, a zero trust enterprise is the network infrastructure (physical and virtual)
and operational policies that are in place for an enterprise as a product of a ZTA plan.
”[1]

Oder einfach gesagt, “vertraue niemals, verifiziere immer“ sprich, gehe davon aus, dass die eigenen Dienste und Anwendungen immer in einer potenziell kompromittierten Umgebung laufen. Während das Konzept an sich nicht neu ist, Wikipedia nennt Stephen Paul’s Doktorarbeit aus dem Jahr 1994 als Ursprung der ersten Erwähnung von Zero Trust, hat es jedoch gerade in letzter Zeit einiges an Aufmerksamkeit auf sich gezogen.

Man betrachte die heutzutage typischerweise stark vernetzten Systemlandschaften, wo Unternehmen und Organisationen auf Software-as-a-Service Dienste verschiedenster Anbieter zurückgreifen, die dann wiederum oftmals eng verknüpft sind mit den eigenen Diensten, welche eventuell selbst gehostet werden. Eine typische Anforderung an diese Dienste und Anwendungen ist es mittlerweile, sie kontrolliert Nutzern zugänglich zu machen, egal von wo diese Nutzer auf die Dienste zugreifen müssen. Man denke da beispielsweise an Mitarbeiter*innen, die vom Home-Office aus Zugriff benötigen, als auch vom Büro. Oder externe Partner und Dienstleister, welche ebenfalls auf diverse Dienste und Anwendungen zugreifen sollen.

Diese Komplexität ist das neue „Normal“ und diese gilt es einfach und sicher zu verwalten und zu kontrollieren.

Die Tage, wo es im Grunde nur das firmeneigene „Intranet“ gab, welches oftmals nur über VPN oder über das Bürointerne Netzwerk erreichbar war und als „sichere“ Umgebung galt, indem auch mal gerne der ein oder andere Dienst komplett ohne Zugangsbeschränkungen bzw. Kontrollen lief, diese Tage sind längst vorbei. Man stelle sich nur vor, was passieren würde, wenn es einem Angreifer gelingen würde, den VPN Zugang bzw. die Firewall zu überwinden, sei es, weil dieser sich kritische Sicherheitslücken bzw. fehlerhafte Konfigurationen der Firewall/VPNs zu eigen macht. Eine entsprechende „Zero Trust Architektur“ kann helfen, potenziellen Schaden in solchen Fällen zu minimieren und die Angreifer signifikant zu verlangsamen.

Die amerikanische Cybersecurity und Infrastructure Security Agency (CISA) definiert ein Zero Trust Maturity Modell, welches Unternehmen bei ihrer Transformation hin zur „Zero Trust Architektur“ unterstützen soll. [1]

Dieses Modell setzt dabei auf fünf Säulen. Eine der Säulen ist „Identitätsverwaltung“ welches als Ziel beschreibt, „… vom Unternehmen verwaltete Identitäten zu nutzen, um Zugriff auf die Anwendungen gewähren, welche für tägliche Arbeit nötig sind. Dieses Personal soll durch Phishing resistente Mehr-Faktor-Authentifizierungen vor ausgefeilten online Phishing-Attacken geschützt werden.“

Identity@ThingsRock bietet genau das, einen mächtigen, zentral zu administrierenden Identitäts- und Zugriffsverwaltungsdienst.

Dieser erlaubt schnell und einfach das Ausrollen von Mehr-Faktor-Authentifizierung für Nutzer und/oder Gruppen von Nutzern. Es werden Gesichtserkennung oder Fingerabdruck auf den Endgeräten der Nutzer unterstützt. Identity@ThingsRock kann außerdem Hardwaretoken verwenden, als auch durch OTP generierte Einmalpasswörter. All diese unterschiedlichen Faktoren können flexibel in individuellen Anmeldeworkflows konfiguriert werden, die dann einfach für individuelle Anwendungen oder alle Dienste ausgerollt werden können. Flexibilität und einfache Anwendung sind die Grundpfeiler unseres Dienstes.

Aber es gibt noch einen weiteren wichtigen Aspekt, der auf keinen Fall vergessen werden sollte. Dies ist die Verwaltung der Identität von Diensten und Anwendungen und deren Zugriffsrechte.

Hier bei ThingsRock nutzen wir dutzende, größtenteils selbst entwickelte, Microservices und die Anzahl steigt kontinuierlich. Identity@ThingsRock liefert uns dafür alles, was wir benötigen, um die Identität und die Zugriffsrechte dieser Dienste zu verwalten, d.h. wir nutzen Identity@ThingsRock um unsere APIs abzusichern. Jeder unserer Dienste verfügt individuelle Zugriffsrechte. Mit einem Zugriffsrecht definiert ein Dienst, was ein Nutzer oder anderer Dienst tun darf, wenn das Zugriffsrecht entsprechend vergeben wurde, wie bspw. das Lesen der Nutzerliste, limitiert auf einen Mandanten oder das Senden einer E-Mail über eine API. Identity@ThingsRock erlaubt es uns all diese verschiedenen Zugriffsrechte auf verschiedenen Ebenen zu verwalten, sei es je Nutzer, Nutzergruppe(n) oder je Dienst.

Wie bereits erwähnt, wir nutzen Identity@ThingsRock, um die Zugriffsrechte für unsere APIs zu verwalten. Es ist sogar möglich, eine API dahingehend abzusichern, dass ein Nutzer nicht nur das entsprechende Zugriffsrecht benötigt, sondern sich auch mittels eines zweiten Faktors authentifiziert haben muss (Level of Authentication). Alle diese mächtigen Optionen erlauben es uns, unsere Dienste exakt unseren Anforderungen entsprechend abzusichern.

Mit Identity@ThingsRock sind wir in der Lage auch Ihr Unternehmen auf seiner digitalen Transformation hin zu einer „Zero Trust Architektur“ zu unterstützen.

Falls Sie mehr über Identity@ThingsRock erfahren möchten, probieren Sie es doch einfach selbst aus: Melden Sie sich kostenlos an oder kontaktieren Sie uns einfach direkt: info@thingsrock.com.

1: NIST SP 800-207: Zero Trust Architecture. 2020. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf