{"id":12465,"date":"2026-08-18T10:09:22","date_gmt":"2026-08-18T08:09:22","guid":{"rendered":"https:\/\/www.psw-group.de\/blog\/?p=12465"},"modified":"2026-08-18T10:09:22","modified_gmt":"2026-08-18T08:09:22","slug":"zero-trust-architektur-erklaert","status":"publish","type":"post","link":"https:\/\/www.psw-group.de\/blog\/zero-trust-architektur-erklaert\/","title":{"rendered":"Zero Trust Architektur: Komponenten und Funktionsweise erkl\u00e4rt"},"content":{"rendered":"<p>Zero Trust ist kein einzelnes Produkt, das Unternehmen installieren und anschlie\u00dfend als erledigt betrachten k\u00f6nnen. Vielmehr handelt es sich um ein Sicherheitsmodell, dessen Prinzipien sich durch die gesamte IT-Architektur ziehen. Der zentrale Gedanke: Kein Benutzer, Ger\u00e4t oder Workload erh\u00e4lt allein aufgrund seines Netzwerkstandorts automatisch Vertrauen. Zugriffe werden stattdessen explizit gepr\u00fcft, m\u00f6glichst restriktiv vergeben und anhand relevanter Sicherheitssignale bewertet.<\/p>\n<p>Eine <strong>Zero Trust Architektur<\/strong> verbindet daf\u00fcr verschiedene technische und organisatorische Komponenten. Identit\u00e4tsmanagement, Multi-Faktor-Authentifizierung, Ger\u00e4tesicherheit, Zugriffskontrollen, Segmentierung, PKI, Verschl\u00fcsselung und Monitoring liefern gemeinsam die Informationen und Kontrollmechanismen, die f\u00fcr sichere Zugriffsentscheidungen ben\u00f6tigt werden.<\/p>\n<p>Doch wie greifen diese Komponenten ineinander? Wer entscheidet, ob ein Zugriff erlaubt wird? Und was passiert, wenn sich das Risiko w\u00e4hrend einer bestehenden Sitzung ver\u00e4ndert?<\/p>\n<h2>Was ist eine Zero-Trust-Architektur?<\/h2>\n<p>Eine Zero-Trust-Architektur ist die technische und organisatorische Umsetzung der Zero-Trust-Prinzipien innerhalb einer IT-Infrastruktur. Sie l\u00f6st sich von der Vorstellung, dass allein der Standort innerhalb eines Unternehmensnetzwerks ausreichendes Vertrauen begr\u00fcndet.<\/p>\n<p>Klassische Sicherheitsarchitekturen waren lange stark perimeterorientiert: Das interne Netzwerk wurde gegen\u00fcber externen Netzen abgeschirmt. Wer sich innerhalb dieser Grenze befand, konnte \u2013 abh\u00e4ngig von der jeweiligen Architektur und den vergebenen Berechtigungen \u2013 vergleichsweise weitreichende Zugriffsm\u00f6glichkeiten erhalten.<\/p>\n<p>Zero Trust ver\u00e4ndert dieses Vertrauensmodell. Ob sich eine Person oder ein Ger\u00e4t im B\u00fcro, im Homeoffice oder in einer Cloud-Umgebung befindet, reicht allein nicht aus, um einen Zugriff als vertrauensw\u00fcrdig einzustufen.<\/p>\n<p>Im Mittelpunkt stehen stattdessen die konkret zu sch\u00fctzenden Ressourcen: Anwendungen, Daten, Dienste, Workloads und andere IT-Ressourcen. F\u00fcr einen Zugriff muss gepr\u00fcft werden, <strong>welche Identit\u00e4t unter welchen Bedingungen auf welche Ressource zugreifen m\u00f6chte und ob dieser Zugriff den festgelegten Sicherheitsrichtlinien entspricht<\/strong>.<\/p>\n<p>Eine Zero Trust Architektur setzt dabei drei zentrale Prinzipien praktisch um:<\/p>\n<ul>\n<li><strong>Explizit verifizieren:<\/strong> Zugriffe werden anhand verf\u00fcgbarer Informationen und definierter Richtlinien gepr\u00fcft.<\/li>\n<li><strong>Least Privilege:<\/strong> Benutzer, Ger\u00e4te und Dienste erhalten m\u00f6glichst nur die Berechtigungen, die sie tats\u00e4chlich ben\u00f6tigen.<\/li>\n<li><strong>Assume Breach:<\/strong> Die Architektur ber\u00fccksichtigt, dass einzelne Konten, Ger\u00e4te oder Systeme bereits kompromittiert sein k\u00f6nnten, und soll die m\u00f6glichen Auswirkungen begrenzen.<\/li>\n<\/ul>\n<p>Die grundlegenden Prinzipien und die schrittweise Einf\u00fchrung des Sicherheitsmodells erl\u00e4utern wir ausf\u00fchrlich in unserem Beitrag zu <a href=\"https:\/\/www.psw-group.de\/blog\/zero-trust-kein-blindes-vertrauen\/\">Zero Trust Security<\/a>.<\/p>\n<h2>Wie ist eine Zero-Trust-Architektur aufgebaut?<\/h2>\n<p>Damit Zero Trust nicht nur ein abstraktes Sicherheitsprinzip bleibt, muss eine Architektur Zugriffsentscheidungen treffen und technisch durchsetzen k\u00f6nnen. Das Referenzmodell des US-amerikanischen National Institute of Standards and Technology (NIST) unterscheidet daf\u00fcr mehrere logische Komponenten.<\/p>\n<p>Besonders wichtig sind die <strong>Policy Engine (PE)<\/strong>, der <strong>Policy Administrator (PA)<\/strong> und der <strong>Policy Enforcement Point (PEP)<\/strong>. Vereinfacht l\u00e4sst sich die Architektur au\u00dferdem in eine Control Plane f\u00fcr Entscheidungen und eine Data Plane f\u00fcr die eigentliche Kommunikation unterteilen.<\/p>\n<h3>Control Plane \u2013 wo Zugriffsentscheidungen entstehen<\/h3>\n<p>In der Control Plane werden die Informationen verarbeitet, die f\u00fcr eine Zugriffsentscheidung ben\u00f6tigt werden. Hier kommen Unternehmensrichtlinien und Sicherheitssignale zusammen.<\/p>\n<p>Das k\u00f6nnen beispielsweise Informationen aus dem Identity &amp; Access Management, Ger\u00e4temanagement, Monitoring oder aus Risiko- und Bedrohungsanalysen sein.<\/p>\n<p>Die Control Plane entscheidet damit sinngem\u00e4\u00df:<\/p>\n<p><strong>Darf diese Identit\u00e4t unter den aktuellen Bedingungen auf diese konkrete Ressource zugreifen?<\/strong><\/p>\n<p>Die eigentlichen Anwendungsdaten des Benutzers laufen dagegen \u00fcber die Data Plane.<\/p>\n<h3>Policy Engine \u2013 Zugriff erlauben oder verweigern?<\/h3>\n<p>Die <strong>Policy Engine<\/strong> ist die zentrale Entscheidungsinstanz. Sie bewertet eine Zugriffsanfrage anhand der hinterlegten Unternehmensrichtlinien und der verf\u00fcgbaren Sicherheitssignale.<\/p>\n<p>Dabei kann beispielsweise ber\u00fccksichtigt werden:<\/p>\n<ul>\n<li>Wer fordert den Zugriff an?<\/li>\n<li>Welche Rolle und Berechtigungen besitzt die Identit\u00e4t?<\/li>\n<li>Ist eine erforderliche MFA erfolgreich durchgef\u00fchrt worden?<\/li>\n<li>Von welchem Ger\u00e4t erfolgt der Zugriff?<\/li>\n<li>Entspricht das Ger\u00e4t den Sicherheitsrichtlinien?<\/li>\n<li>Welche Ressource wird angefordert?<\/li>\n<li>Wie hoch ist deren Schutzbedarf?<\/li>\n<li>Gibt es aktuelle Hinweise auf ein erh\u00f6htes Risiko?<\/li>\n<\/ul>\n<p>Aus diesen Informationen leitet die Policy Engine eine Entscheidung ab. Ein Zugriff kann beispielsweise erlaubt oder verweigert werden. \u00c4ndert sich die Sicherheitslage, kann eine bereits bestehende Zugriffsentscheidung auch neu bewertet werden.<\/p>\n<h3>Policy Administrator \u2013 Entscheidungen technisch umsetzen<\/h3>\n<p>Der <strong>Policy Administrator<\/strong> setzt die Entscheidung der Policy Engine technisch um beziehungsweise steuert die daf\u00fcr erforderlichen Ma\u00dfnahmen.<\/p>\n<p>Hat die Policy Engine einen Zugriff freigegeben, sorgt der Policy Administrator daf\u00fcr, dass die entsprechenden Kommunikationswege eingerichtet werden k\u00f6nnen. Wird ein Zugriff nicht mehr erlaubt, kann er die Beendigung einer bestehenden Verbindung veranlassen.<\/p>\n<p>Policy Engine und Policy Administrator bilden damit gemeinsam die logische Entscheidungs- und Steuerungsebene.<\/p>\n<h3>Data Plane und Policy Enforcement Point \u2013 Zugriff tats\u00e4chlich kontrollieren<\/h3>\n<p>In der <strong>Data Plane<\/strong> findet die eigentliche Kommunikation zwischen dem anfragenden Subjekt \u2013 beispielsweise einem Benutzer oder Ger\u00e4t \u2013 und der gesch\u00fctzten Ressource statt.<\/p>\n<p>Eine zentrale Rolle spielt dabei der <strong>Policy Enforcement Point (PEP)<\/strong>. Er setzt die getroffene Zugriffsentscheidung durch und kontrolliert die Verbindung zur Ressource.<\/p>\n<p>Vereinfacht l\u00e4sst sich das Zusammenspiel so darstellen:<\/p>\n<p><strong>Benutzer\/Ger\u00e4t \u2192 Policy Enforcement Point \u2192 Anwendung\/Ressource<\/strong><\/p>\n<p>Die Entscheidung dar\u00fcber, ob dieser Weg ge\u00f6ffnet werden darf, entsteht dagegen in der Control Plane:<\/p>\n<p><strong>Identit\u00e4t + Ger\u00e4t + Kontext + Risiko + Richtlinien \u2192 Policy Engine \u2192 Policy Administrator \u2192 Policy Enforcement Point<\/strong><\/p>\n<p>Damit sind Entscheidung und eigentliche Datenkommunikation logisch voneinander getrennt.<\/p>\n<h2>Welche Informationen flie\u00dfen in eine Zugriffsentscheidung ein?<\/h2>\n<p>Eine Zero Trust Architektur sollte ihre Entscheidung nicht ausschlie\u00dflich auf ein einzelnes Signal st\u00fctzen. Ein korrektes Passwort sagt beispielsweise noch nichts dar\u00fcber aus, ob das verwendete Ger\u00e4t kompromittiert ist oder ob der angeforderte Zugriff zur Rolle des Benutzers passt.<\/p>\n<p>Je mehr relevante und verl\u00e4ssliche Kontextinformationen zur Verf\u00fcgung stehen, desto differenzierter kann ein Zugriff bewertet werden.<\/p>\n<h3>Identit\u00e4t und Berechtigungen<\/h3>\n<p>Zun\u00e4chst muss feststehen, wer beziehungsweise was den Zugriff anfordert. Dabei kann es sich nicht nur um einen Menschen handeln. Auch Anwendungen, Dienste, APIs und andere Workloads ben\u00f6tigen Identit\u00e4ten und Berechtigungen.<\/p>\n<p>Relevante Informationen k\u00f6nnen sein:<\/p>\n<ul>\n<li>Benutzer- oder Maschinenidentit\u00e4t<\/li>\n<li>Rolle im Unternehmen<\/li>\n<li>zugewiesene Berechtigungen<\/li>\n<li>Authentifizierungsstatus<\/li>\n<li>MFA-Status<\/li>\n<\/ul>\n<p>Eine erfolgreiche Authentifizierung beantwortet dabei zun\u00e4chst die Frage nach der Identit\u00e4t. Ob diese Identit\u00e4t auch auf die gew\u00fcnschte Ressource zugreifen darf, ist eine separate Autorisierungsentscheidung.<\/p>\n<h3>Ger\u00e4t und Sicherheitszustand<\/h3>\n<p>Auch ein legitimer Benutzer kann ein Risiko darstellen, wenn der Zugriff von einem kompromittierten oder unzureichend gesch\u00fctzten Ger\u00e4t erfolgt.<\/p>\n<p>Eine Zero Trust Architektur kann deshalb Informationen \u00fcber den Ger\u00e4tezustand ber\u00fccksichtigen:<\/p>\n<ul>\n<li>Ist das Ger\u00e4t bekannt?<\/li>\n<li>Wird es zentral verwaltet?<\/li>\n<li>Ist das Betriebssystem aktuell?<\/li>\n<li>Sind erforderliche Sicherheitspatches installiert?<\/li>\n<li>Sind vorgeschriebene Sicherheitsma\u00dfnahmen aktiv?<\/li>\n<li>Entspricht das Ger\u00e4t den Compliance-Vorgaben des Unternehmens?<\/li>\n<\/ul>\n<p>Damit wird nicht nur gepr\u00fcft, <strong>wer<\/strong> zugreift, sondern auch, <strong>womit<\/strong> der Zugriff erfolgt.<\/p>\n<h3>Standort und Netzwerk<\/h3>\n<p>Auch Standort- und Netzwerkinformationen k\u00f6nnen weiterhin relevant sein. Zero Trust bedeutet nicht, dass der Standort ignoriert werden muss. Er verliert lediglich seine Funktion als alleinige Vertrauensgrundlage.<\/p>\n<p>Ein Zugriff aus dem Unternehmensb\u00fcro kann deshalb anders bewertet werden als eine Anmeldung aus einem Land, aus dem sich derselbe Benutzer normalerweise nicht anmeldet.<\/p>\n<p>Der Standort ist damit ein <strong>Kontextsignal unter mehreren<\/strong>, aber kein automatischer Vertrauensnachweis.<\/p>\n<h3>Verhalten und aktuelles Risiko<\/h3>\n<p>Zus\u00e4tzlich k\u00f6nnen Informationen aus Monitoring, Threat Intelligence oder Verhaltensanalysen ber\u00fccksichtigt werden.<\/p>\n<p>Interessant sind beispielsweise Fragen wie:<\/p>\n<ul>\n<li>Weicht das aktuelle Verhalten deutlich vom \u00fcblichen Muster ab?<\/li>\n<li>Gibt es Hinweise auf kompromittierte Zugangsdaten?<\/li>\n<li>Werden ungew\u00f6hnlich gro\u00dfe Datenmengen heruntergeladen?<\/li>\n<li>Greift die Identit\u00e4t pl\u00f6tzlich auf untypische Ressourcen zu?<\/li>\n<li>Gibt es aktuelle Sicherheitswarnungen f\u00fcr das verwendete Ger\u00e4t?<\/li>\n<\/ul>\n<p>Solche Informationen erm\u00f6glichen risikobasierte Zugriffsentscheidungen.<\/p>\n<h3>Ressource und Schutzbedarf<\/h3>\n<p>Nicht zuletzt ist entscheidend, <strong>worauf<\/strong> zugegriffen werden soll.<\/p>\n<p>Der Zugriff auf eine allgemein verf\u00fcgbare interne Anwendung muss nicht zwangsl\u00e4ufig denselben Anforderungen unterliegen wie der Zugriff auf eine Datenbank mit sensiblen Kundeninformationen oder eine administrative Oberfl\u00e4che.<\/p>\n<p>Daten und Anwendungen m\u00fcssen deshalb nach ihrem Schutzbedarf bewertet werden. Je kritischer eine Ressource ist, desto strenger k\u00f6nnen die Anforderungen an Identit\u00e4t, Ger\u00e4t, Authentifizierung und Kontext ausfallen.<\/p>\n<h2>Wie arbeiten IAM, MFA, PKI, Ger\u00e4temanagement und Monitoring zusammen?<\/h2>\n<p>Eine Zero Trust Architektur entsteht nicht dadurch, dass Unternehmen m\u00f6glichst viele Sicherheitsprodukte einsetzen. Entscheidend ist vielmehr, dass die einzelnen Komponenten verl\u00e4ssliche Informationen liefern und aufeinander abgestimmt sind.<\/p>\n<h3>IAM \u2013 Identit\u00e4ten und Berechtigungen bereitstellen<\/h3>\n<p>Das <strong>Identity &amp; Access Management (IAM)<\/strong> bildet eine wichtige Grundlage f\u00fcr identit\u00e4tsbasierte Zugriffsentscheidungen. Es verwaltet Benutzer und weitere Identit\u00e4ten sowie Rollen und Berechtigungen.<\/p>\n<p>Das IAM liefert damit Antworten auf Fragen wie:<\/p>\n<ul>\n<li>Wer ist die anfragende Identit\u00e4t?<\/li>\n<li>Welche Rolle besitzt sie?<\/li>\n<li>Welche Berechtigungen sind ihr zugeordnet?<\/li>\n<li>Ist das Konto noch aktiv?<\/li>\n<li>Wurden Berechtigungen k\u00fcrzlich ge\u00e4ndert?<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>Gerade f\u00fcr das Least-Privilege-Prinzip ist eine saubere Verwaltung der Berechtigungen unverzichtbar.<\/p>\n<h3>MFA \u2013 Identit\u00e4tspr\u00fcfung verst\u00e4rken<\/h3>\n<p>Die <strong>Multi-Faktor-Authentifizierung (MFA)<\/strong> erg\u00e4nzt beispielsweise ein Passwort um mindestens einen weiteren Authentifizierungsfaktor.<\/p>\n<p>Dadurch reicht ein gestohlenes Passwort allein nicht zwangsl\u00e4ufig f\u00fcr eine erfolgreiche Authentifizierung aus. Je nach Risiko und Richtlinie kann eine zus\u00e4tzliche Authentifizierung auch gezielt f\u00fcr besonders sensible Zugriffe verlangt werden.<\/p>\n<p>MFA st\u00e4rkt damit die Identit\u00e4tspr\u00fcfung, ersetzt jedoch nicht die anschlie\u00dfende Entscheidung dar\u00fcber, auf welche Ressourcen eine erfolgreich authentifizierte Identit\u00e4t zugreifen darf.<\/p>\n<h3>PKI und digitale Zertifikate \u2013 Ger\u00e4te und Maschinenidentit\u00e4ten authentifizieren<\/h3>\n<p>Zero Trust betrifft nicht nur menschliche Benutzer. In modernen IT-Infrastrukturen kommunizieren zahlreiche Ger\u00e4te, Anwendungen, APIs, Container, Server und Cloud-Workloads miteinander.<\/p>\n<p>Eine <strong>Public-Key-Infrastruktur (PKI)<\/strong> und digitale Zertifikate k\u00f6nnen dabei eine wichtige Rolle spielen. Zertifikate erm\u00f6glichen es, Identit\u00e4ten kryptografisch nachzuweisen und verschl\u00fcsselte Verbindungen aufzubauen.<\/p>\n<p>Besonders relevant ist dies bei Maschinenidentit\u00e4ten und bei der gegenseitigen Authentifizierung \u00fcber <strong>Mutual TLS (mTLS)<\/strong>. Dabei authentifizieren sich beide Kommunikationspartner mithilfe digitaler Zertifikate.<\/p>\n<p>Wichtig ist jedoch die Abgrenzung zwischen Authentifizierung und Autorisierung: Ein g\u00fcltiges Zertifikat kann die Identit\u00e4t eines Ger\u00e4ts oder Dienstes beziehungsweise den Besitz des zugeh\u00f6rigen privaten Schl\u00fcssels nachweisen. Es entscheidet aber nicht automatisch dar\u00fcber, auf welche Unternehmensressourcen diese Identit\u00e4t zugreifen darf. Diese Entscheidung bleibt Aufgabe der jeweiligen Zugriffsrichtlinien.<\/p>\n<h3>Ger\u00e4temanagement \u2013 Sicherheitsstatus verf\u00fcgbar machen<\/h3>\n<p>Endpoint- und Device-Management-Systeme liefern Informationen dar\u00fcber, ob ein Ger\u00e4t die Sicherheitsanforderungen des Unternehmens erf\u00fcllt.<\/p>\n<p>Dazu geh\u00f6ren beispielsweise:<\/p>\n<ul>\n<li>Patchstand<\/li>\n<li>Betriebssystemversion<\/li>\n<li>Ger\u00e4testatus<\/li>\n<li>Verschl\u00fcsselung<\/li>\n<li>vorhandene Sicherheitssoftware<\/li>\n<li>Einhaltung definierter Compliance-Regeln<\/li>\n<\/ul>\n<p>Diese Informationen k\u00f6nnen unmittelbar in Zugriffsentscheidungen einflie\u00dfen. Ein Ger\u00e4t, das die Anforderungen nicht mehr erf\u00fcllt, kann beispielsweise nur eingeschr\u00e4nkten Zugriff erhalten oder vollst\u00e4ndig abgewiesen werden.<\/p>\n<h3>Monitoring und SIEM \u2013 Ver\u00e4nderungen und Risiken erkennen<\/h3>\n<p>Eine Zero Trust Architektur ben\u00f6tigt Transparenz dar\u00fcber, was innerhalb der IT-Umgebung geschieht. Monitoring-Systeme erfassen daf\u00fcr sicherheitsrelevante Ereignisse. Ein Security Information and Event Management (SIEM) kann Informationen aus verschiedenen Quellen zentral sammeln und korrelieren.<\/p>\n<p>Dadurch lassen sich beispielsweise ungew\u00f6hnliche Anmeldeversuche, auff\u00e4llige Datenzugriffe oder Ver\u00e4nderungen im Verhalten einer Identit\u00e4t erkennen.<\/p>\n<p>Diese Informationen dienen nicht nur der nachtr\u00e4glichen Analyse eines Sicherheitsvorfalls. Sie k\u00f6nnen auch neue Signale f\u00fcr weitere Zugriffsentscheidungen liefern.<\/p>\n<h2>Vom Sicherheitssignal zur Zugriffsentscheidung: ein Praxisbeispiel<\/h2>\n<p>Wie die verschiedenen Komponenten zusammenspielen, l\u00e4sst sich an einem Beispiel verdeutlichen.<\/p>\n<p>Eine Mitarbeiterin aus der Finanzabteilung m\u00f6chte aus dem Homeoffice auf eine sensible Finanzanwendung zugreifen.<\/p>\n<p><strong>1. Identit\u00e4t feststellen<\/strong><\/p>\n<p>Das IAM best\u00e4tigt die Benutzeridentit\u00e4t und liefert Informationen \u00fcber ihre Rolle und Berechtigungen.<\/p>\n<p><strong>2. Authentifizierung absichern<\/strong><\/p>\n<p>Die Richtlinie verlangt f\u00fcr die Finanzanwendung eine Multi-Faktor-Authentifizierung. Die Mitarbeiterin best\u00e4tigt den zus\u00e4tzlichen Faktor erfolgreich.<\/p>\n<p><strong>3. Ger\u00e4t \u00fcberpr\u00fcfen<\/strong><\/p>\n<p>Das Ger\u00e4temanagement erkennt das verwendete Notebook als verwaltetes Unternehmensger\u00e4t. Patchstand und Sicherheitsstatus entsprechen den festgelegten Anforderungen.<\/p>\n<p><strong>4. Ger\u00e4teidentit\u00e4t pr\u00fcfen<\/strong><\/p>\n<p>Ein auf dem Ger\u00e4t vorhandenes Zertifikat kann zus\u00e4tzlich zur Authentifizierung des verwalteten Ger\u00e4ts eingesetzt werden.<\/p>\n<p><strong>5. Kontext bewerten<\/strong><\/p>\n<p>Die Policy Engine erh\u00e4lt die relevanten Informationen. Die Identit\u00e4t ist berechtigt, das Ger\u00e4t erf\u00fcllt die Anforderungen und es liegen keine auff\u00e4lligen Risikosignale vor.<\/p>\n<p><strong>6. Zugriffsentscheidung treffen<\/strong><\/p>\n<p>Die Policy Engine erlaubt den Zugriff entsprechend der Unternehmensrichtlinie. Der Policy Administrator veranlasst die technische Umsetzung der Entscheidung.<\/p>\n<p><strong>7. Zugriff durchsetzen<\/strong><\/p>\n<p>Der Policy Enforcement Point erm\u00f6glicht die freigegebene Kommunikation mit der Finanzanwendung. Andere Anwendungen oder Netzwerkbereiche werden dadurch nicht automatisch zug\u00e4nglich.<\/p>\n<p><strong>8. Zugriff \u00fcberwachen<\/strong><\/p>\n<p>Monitoring und Sicherheitsanalysen beobachten relevante Ereignisse. Entstehen neue Risikosignale, k\u00f6nnen diese in eine erneute Bewertung einflie\u00dfen.<\/p>\n<p>Das Beispiel verdeutlicht den eigentlichen Architekturgedanken: <strong>Nicht ein einzelnes Sicherheitssystem entscheidet \u00fcber Vertrauen. Mehrere Komponenten liefern Informationen, aus denen anhand definierter Policies eine konkrete Zugriffsentscheidung entsteht.<\/strong><\/p>\n<h2>Warum Zugriffe kontinuierlich neu bewertet werden<\/h2>\n<p>Ein Benutzer kann zu Beginn einer Sitzung alle Sicherheitsanforderungen erf\u00fcllen. Die Situation muss jedoch nicht w\u00e4hrend der gesamten Sitzung unver\u00e4ndert bleiben.<\/p>\n<p>Denkbar ist beispielsweise:<\/p>\n<ul>\n<li>Das Ger\u00e4t wird nachtr\u00e4glich als kompromittiert erkannt.<\/li>\n<li>Der Standort ver\u00e4ndert sich auf ungew\u00f6hnliche Weise.<\/li>\n<li>Das Benutzerverhalten weicht deutlich vom Normalfall ab.<\/li>\n<li>Es werden ungew\u00f6hnlich gro\u00dfe Datenmengen abgerufen.<\/li>\n<li>Berechtigungen werden durch einen Administrator ge\u00e4ndert.<\/li>\n<li>Neue Bedrohungsinformationen erh\u00f6hen die Risikoeinstufung.<\/li>\n<\/ul>\n<p>Eine moderne Zero Trust Architektur kann solche Ver\u00e4nderungen ber\u00fccksichtigen und eine erneute Bewertung ausl\u00f6sen.<\/p>\n<p>Abh\u00e4ngig von Risiko und Richtlinie kann die Reaktion unterschiedlich ausfallen:<\/p>\n<ul>\n<li>Zugriff unver\u00e4ndert fortsetzen<\/li>\n<li>zus\u00e4tzliche Authentifizierung verlangen<\/li>\n<li>Zugriffsrechte einschr\u00e4nken<\/li>\n<li>Zugriff auf eine Ressource verweigern<\/li>\n<li>bestehende Sitzung beenden<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Kontinuierliche \u00dcberpr\u00fcfung bedeutet dabei nicht zwangsl\u00e4ufig eine permanente vollst\u00e4ndige Neuauthentifizierung.<\/strong> Entscheidend ist vielmehr, dass eine einmal getroffene Zugriffsentscheidung nicht automatisch f\u00fcr unbegrenzte Zeit als unver\u00e4nderlich betrachtet wird.<\/p>\n<p>Neue sicherheitsrelevante Signale k\u00f6nnen zu einer Anpassung f\u00fchren.<\/p>\n<h2>Warum Zero Trust kein einzelnes Produkt ist<\/h2>\n<p>Die einzelnen Komponenten zeigen bereits, warum Unternehmen <strong>Zero Trust nicht einfach kaufen<\/strong> k\u00f6nnen.<\/p>\n<p>IAM verwaltet Identit\u00e4ten. MFA st\u00e4rkt die Authentifizierung. PKI und digitale Zertifikate k\u00f6nnen Ger\u00e4te und Maschinenidentit\u00e4ten authentifizieren und verschl\u00fcsselte Kommunikation erm\u00f6glichen. Endpoint Security bewertet Ger\u00e4te. Segmentierung begrenzt Kommunikationswege. Monitoring und SIEM liefern Risiko- und Verhaltensinformationen.<\/p>\n<p>Zus\u00e4tzlich kann <a href=\"https:\/\/www.psw-group.de\/blog\/ztna-erklaert-zero-trust-network-access\/\">Zero Trust Network Access (ZTNA)<\/a> Zugriffe gezielt auf freigegebene Anwendungen und Ressourcen beschr\u00e4nken. Wie ZTNA funktioniert und worin sich der Ansatz von klassischen VPN-Zug\u00e4ngen unterscheidet, erkl\u00e4ren wir ausf\u00fchrlich im verlinkten Beitrag.<\/p>\n<p>Keine dieser Technologien bildet f\u00fcr sich allein eine vollst\u00e4ndige Zero Trust Architektur.<\/p>\n<p>Entscheidend ist das Zusammenspiel aus:<\/p>\n<ul>\n<li>IAM<\/li>\n<li>MFA<\/li>\n<li>PKI und Zertifikatsmanagement<\/li>\n<li>Endpoint Security und Ger\u00e4temanagement<\/li>\n<li>Netzwerk- und Mikrosegmentierung<\/li>\n<li>ZTNA<\/li>\n<li>Monitoring und SIEM<\/li>\n<li>Risiko- und Bedrohungsinformationen<\/li>\n<li>Zugriffsrichtlinien<\/li>\n<li>Governance und klaren Verantwortlichkeiten<\/li>\n<\/ul>\n<p>Welche Komponenten ben\u00f6tigt werden und wie sie miteinander verbunden werden, h\u00e4ngt von der vorhandenen Infrastruktur, den Gesch\u00e4ftsprozessen und dem Schutzbedarf eines Unternehmens ab.<\/p>\n<h2>Zentrale Sicherheitsbereiche einer Zero-Trust-Architektur<\/h2>\n<p>F\u00fcr die Planung einer Zero Trust Architektur ist es hilfreich, die verschiedenen Sicherheitsfunktionen in zentrale Bereiche zu gliedern. Dabei existiert allerdings kein universelles Modell mit einer verbindlichen Anzahl von S\u00e4ulen. Verschiedene Zero-Trust-Frameworks verwenden unterschiedliche Gliederungen.<\/p>\n<p>F\u00fcr die praktische Betrachtung lassen sich insbesondere folgende Sicherheitsbereiche unterscheiden.<\/p>\n<h3>Identit\u00e4ten und Zugriffsmanagement<\/h3>\n<p>Identit\u00e4ten bilden einen zentralen Ausgangspunkt f\u00fcr Zugriffsentscheidungen. Das betrifft Benutzer ebenso wie administrative Konten, Ger\u00e4te, Dienste und andere Maschinenidentit\u00e4ten.<\/p>\n<p>Unternehmen ben\u00f6tigen deshalb transparente Prozesse f\u00fcr:<\/p>\n<ul>\n<li>Identit\u00e4tsverwaltung<\/li>\n<li>Authentifizierung<\/li>\n<li>Rollen und Berechtigungen<\/li>\n<li>privilegierte Zugriffe<\/li>\n<li>Vergabe und Entzug von Rechten<\/li>\n<li>regelm\u00e4\u00dfige \u00dcberpr\u00fcfung bestehender Berechtigungen<\/li>\n<\/ul>\n<p>Eine Zero Trust Strategie kann nur funktionieren, wenn klar ist, welche Identit\u00e4ten existieren und welche Zugriffe sie tats\u00e4chlich ben\u00f6tigen.<\/p>\n<h3>Ger\u00e4te und Endpunkte<\/h3>\n<p>Ger\u00e4te m\u00fcssen nicht nur identifiziert, sondern auch hinsichtlich ihres Sicherheitszustands bewertet werden.<\/p>\n<p>Ein verwaltetes und vollst\u00e4ndig gepatchtes Unternehmensger\u00e4t kann beispielsweise anders behandelt werden als ein unbekanntes privates Endger\u00e4t. Endpoint Security und Device Management liefern die daf\u00fcr notwendigen Informationen.<\/p>\n<p>Wird ein Ger\u00e4t als kompromittiert erkannt, k\u00f6nnen seine Zugriffsrechte eingeschr\u00e4nkt oder vollst\u00e4ndig entzogen werden.<\/p>\n<h3>Netzwerk und Segmentierung<\/h3>\n<p>Auch in einer ressourcenorientierten Zero Trust Architektur verliert das Netzwerk nicht seine Bedeutung. Es \u00fcbernimmt jedoch nicht mehr allein die Rolle einer gro\u00dfen Vertrauensgrenze.<\/p>\n<p>Segmentierung und Mikrosegmentierung k\u00f6nnen Netzwerke und Kommunikationsbeziehungen in kleinere Bereiche unterteilen. Ziel ist es, nur die tats\u00e4chlich erforderlichen Verbindungen zuzulassen.<\/p>\n<p>Wird ein System kompromittiert, soll ein Angreifer dadurch nicht automatisch weitere Systeme erreichen k\u00f6nnen. Segmentierung kann laterale Bewegungen erschweren und die m\u00f6glichen Auswirkungen einer Kompromittierung begrenzen.<\/p>\n<h3>Anwendungen, APIs und Workloads<\/h3>\n<p>Nicht nur Benutzer ben\u00f6tigen Schutz und \u00fcberpr\u00fcfbare Identit\u00e4ten. Moderne Anwendungen bestehen zunehmend aus miteinander kommunizierenden Diensten, APIs, virtuellen Maschinen, Containern und Cloud-Workloads.<\/p>\n<p>Auch diese Kommunikation sollte authentifiziert und autorisiert werden.<\/p>\n<p>Gerade in dynamischen Cloud-Umgebungen gewinnen deshalb Maschinenidentit\u00e4ten, kurzlebige Credentials, Zertifikate und automatisierte Richtlinien an Bedeutung.<\/p>\n<h3>Daten und Verschl\u00fcsselung<\/h3>\n<p>Letztlich dient eine Zero Trust Architektur dem Schutz von Unternehmensressourcen und insbesondere sensiblen Daten.<\/p>\n<p>Daf\u00fcr m\u00fcssen Unternehmen zun\u00e4chst wissen, welche Daten vorhanden sind und welchen Schutzbedarf sie besitzen. Klassifizierung und Kennzeichnung schaffen daf\u00fcr eine wichtige Grundlage.<\/p>\n<p>Abh\u00e4ngig vom Schutzbedarf kommen unter anderem folgende Ma\u00dfnahmen infrage:<\/p>\n<ul>\n<li>Verschl\u00fcsselung gespeicherter Daten<\/li>\n<li>Verschl\u00fcsselung w\u00e4hrend der \u00dcbertragung<\/li>\n<li>granulare Zugriffsrechte<\/li>\n<li>Data Loss Prevention<\/li>\n<li>Protokollierung von Zugriffen<\/li>\n<li>Verwaltung kryptografischer Schl\u00fcssel und Zertifikate<\/li>\n<\/ul>\n<p>Zero Trust bedeutet damit nicht nur zu entscheiden, <strong>wer<\/strong> auf Daten zugreifen darf, sondern auch zu kontrollieren, wie diese Daten gespeichert, \u00fcbertragen und verwendet werden.<\/p>\n<h3>\u00dcberwachung, Analytik und Automatisierung<\/h3>\n<p>Die genannten Sicherheitsbereiche ben\u00f6tigen eine gemeinsame Sicht auf Ereignisse und Risiken. Monitoring und Analytik liefern daf\u00fcr die notwendige Transparenz.<\/p>\n<p>Protokolle aus IAM, Endpoints, Anwendungen, Netzwerkkomponenten und anderen Sicherheitssystemen k\u00f6nnen zusammengef\u00fchrt und ausgewertet werden. So lassen sich Ver\u00e4nderungen erkennen, die eine neue Zugriffsentscheidung erforderlich machen.<\/p>\n<p>Mit zunehmendem Reifegrad k\u00f6nnen Unternehmen Teile dieser Reaktion automatisieren \u2013 beispielsweise indem ein als kompromittiert erkanntes Ger\u00e4t unmittelbar isoliert oder f\u00fcr eine riskante Anmeldung zus\u00e4tzliche Authentifizierung verlangt wird.<\/p>\n<p>Zero Trust entwickelt sich dadurch von statischen Zugriffsregeln hin zu einem Sicherheitsmodell, das auf aktuelle Informationen reagieren kann.<\/p>\n<h2>So entwickeln Unternehmen eine Zero Trust Strategie<\/h2>\n<p>Eine vollst\u00e4ndige Zero Trust Architektur entsteht selten in einem einzigen Projekt. Besonders in historisch gewachsenen IT-Landschaften empfiehlt sich eine schrittweise Einf\u00fchrung.<\/p>\n<h3>1. Kritische Ressourcen und Schutzbedarf bestimmen<\/h3>\n<p>Unternehmen sollten zun\u00e4chst identifizieren, welche Daten, Anwendungen, Systeme und Gesch\u00e4ftsprozesse besonders kritisch sind. Nicht jede Ressource ben\u00f6tigt dieselben Kontrollen.<\/p>\n<h3>2. Identit\u00e4ten erfassen<\/h3>\n<p>Im n\u00e4chsten Schritt muss Transparenz \u00fcber Benutzer, Ger\u00e4te, Dienste, Anwendungen und Maschinenidentit\u00e4ten geschaffen werden.<\/p>\n<p>Dabei sollte nicht nur gekl\u00e4rt werden, welche Identit\u00e4ten existieren, sondern auch, welche davon privilegierte oder besonders sensible Zugriffe besitzen.<\/p>\n<h3>3. Daten- und Zugriffsfl\u00fcsse analysieren<\/h3>\n<p>Unternehmen m\u00fcssen verstehen, wie Benutzer, Ger\u00e4te, Anwendungen und Workloads miteinander kommunizieren.<\/p>\n<p>Welche Anwendung ben\u00f6tigt Zugriff auf welche Daten? Welche Systeme kommunizieren untereinander? Welche externen Dienstleister greifen auf interne Ressourcen zu?<\/p>\n<p>Erst diese Transparenz erm\u00f6glicht sinnvolle Least-Privilege-Regeln.<\/p>\n<h3>4. Least-Privilege-Policies definieren<\/h3>\n<p>Auf Basis der tats\u00e4chlichen Anforderungen lassen sich Zugriffsrichtlinien entwickeln.<\/p>\n<p>Dabei sollte der Grundsatz gelten: So viel Zugriff wie f\u00fcr die jeweilige Aufgabe notwendig \u2013 aber nicht mehr.<\/p>\n<h3>5. Kontrollpunkte etablieren<\/h3>\n<p>An geeigneten Stellen m\u00fcssen Zugriffsentscheidungen technisch durchgesetzt werden. Je nach Architektur k\u00f6nnen dazu beispielsweise ZTNA-Komponenten, Identity-Systeme, Netzwerkkomponenten, API-Gateways oder andere Policy Enforcement Points geh\u00f6ren.<\/p>\n<h3>6. Monitoring und R\u00fcckkopplung aufbauen<\/h3>\n<p>Zugriffsentscheidungen ben\u00f6tigen aktuelle Sicherheitssignale. Deshalb m\u00fcssen relevante Ereignisse protokolliert, zentral ausgewertet und bei Bedarf in weitere Entscheidungen zur\u00fcckgef\u00fchrt werden.<\/p>\n<h3>7. Mit klar abgegrenzten Bereichen beginnen<\/h3>\n<p>Eine Zero Trust Strategie muss nicht sofort das gesamte Unternehmen erfassen.<\/p>\n<p>Ein sinnvoller Startpunkt kann beispielsweise eine besonders kritische Anwendung, eine ausgew\u00e4hlte Benutzergruppe oder ein konkreter Remote-Access-Anwendungsfall sein.<\/p>\n<p>So lassen sich Policies testen und technische sowie organisatorische Erfahrungen sammeln.<\/p>\n<h3>8. Architektur kontinuierlich weiterentwickeln<\/h3>\n<p>Zero Trust ist kein Projekt mit einem endg\u00fcltigen Abschlussdatum. IT-Infrastrukturen, Benutzer, Anwendungen und Bedrohungen ver\u00e4ndern sich.<\/p>\n<p>Unternehmen m\u00fcssen deshalb regelm\u00e4\u00dfig \u00fcberpr\u00fcfen:<\/p>\n<ul>\n<li>Sind die Zugriffsrichtlinien noch angemessen?<\/li>\n<li>Existieren unn\u00f6tige Berechtigungen?<\/li>\n<li>Werden neue Ger\u00e4te und Workloads vollst\u00e4ndig erfasst?<\/li>\n<li>Liefern die Sicherheitssysteme ausreichende Informationen?<\/li>\n<li>K\u00f6nnen weitere Entscheidungen automatisiert werden?<\/li>\n<li>Gibt es neue kritische Ressourcen oder Gesch\u00e4ftsprozesse?<\/li>\n<\/ul>\n<p>Eine langfristige Zero Trust Strategie verbindet deshalb technische Weiterentwicklung mit kontinuierlicher Governance.<\/p>\n<h2>Zero Trust entsteht durch das Zusammenspiel vieler Komponenten<\/h2>\n<p>Eine <strong>Zero Trust Architektur<\/strong> ersetzt pauschales Vertrauen durch ressourcenbezogene, richtlinien- und kontextabh\u00e4ngige Zugriffsentscheidungen. Nicht der Netzwerkstandort allein entscheidet dar\u00fcber, ob ein Zugriff erlaubt wird. Stattdessen werden Identit\u00e4t, Ger\u00e4t, Ressource, Kontext und aktuelle Risikosignale ber\u00fccksichtigt.<\/p>\n<p>Im NIST-Referenzmodell bilden <strong>Policy Engine, Policy Administrator und Policy Enforcement Point<\/strong> das technische Herzst\u00fcck dieser Entscheidungs- und Durchsetzungslogik. Damit diese Komponenten fundierte Entscheidungen treffen k\u00f6nnen, ben\u00f6tigen sie jedoch Informationen aus verschiedenen Sicherheitssystemen.<\/p>\n<p>IAM und MFA unterst\u00fctzen die Identit\u00e4tspr\u00fcfung. PKI und digitale Zertifikate k\u00f6nnen Ger\u00e4te und Maschinenidentit\u00e4ten authentifizieren und verschl\u00fcsselte Kommunikation absichern. Endpoint-Systeme liefern Informationen \u00fcber den Ger\u00e4tezustand. Monitoring und SIEM machen Ver\u00e4nderungen und Risiken sichtbar. Segmentierung und ZTNA helfen wiederum dabei, erlaubte Kommunikationswege auf die tats\u00e4chlich ben\u00f6tigten Ressourcen zu begrenzen.<\/p>\n<p>Eine einmal erteilte Zugriffsberechtigung muss dabei nicht dauerhaft gelten. \u00c4ndert sich der Sicherheitskontext, kann der Zugriff neu bewertet, eingeschr\u00e4nkt oder beendet werden.<\/p>\n<p><strong>Zero Trust ist deshalb keine einzelne Technologie und kein einzelnes Produkt. Eine belastbare Zero Trust Strategie entsteht erst, wenn Identit\u00e4ten, Ger\u00e4te, Anwendungen, Daten, Richtlinien und Sicherheitssignale zu einer gemeinsamen Architektur verbunden werden \u2013 und diese Architektur kontinuierlich weiterentwickelt wird.<\/strong><\/p>\n<div class=\"shariff\"><ul class=\"shariff-buttons theme-default orientation-horizontal buttonsize-medium\"><li class=\"shariff-button facebook shariff-nocustomcolor\" style=\"background-color:#4273c8\"><a href=\"https:\/\/www.facebook.com\/sharer\/sharer.php?u=https%3A%2F%2Fwww.psw-group.de%2Fblog%2Fzero-trust-architektur-erklaert%2F\" title=\"Bei Facebook teilen\" aria-label=\"Bei Facebook teilen\" role=\"button\" rel=\"nofollow\" class=\"shariff-link\" style=\"; background-color:#3b5998; color:#fff\" target=\"_blank\"><span class=\"shariff-icon\" style=\"\"><svg width=\"32px\" height=\"20px\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 18 32\"><path fill=\"#3b5998\" d=\"M17.1 0.2v4.7h-2.8q-1.5 0-2.1 0.6t-0.5 1.9v3.4h5.2l-0.7 5.3h-4.5v13.6h-5.5v-13.6h-4.5v-5.3h4.5v-3.9q0-3.3 1.9-5.2t5-1.8q2.6 0 4.1 0.2z\"\/><\/svg><\/span><span class=\"shariff-text\">teilen<\/span>&nbsp;<\/a><\/li><li class=\"shariff-button twitter shariff-nocustomcolor\" style=\"background-color:#595959\"><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fwww.psw-group.de%2Fblog%2Fzero-trust-architektur-erklaert%2F&text=Zero%20Trust%20Architektur%3A%20Komponenten%20und%20Funktionsweise%20erkl%C3%A4rt\" title=\"Bei X teilen\" aria-label=\"Bei X teilen\" role=\"button\" rel=\"noopener nofollow\" class=\"shariff-link\" style=\"; background-color:#000; color:#fff\" target=\"_blank\"><span class=\"shariff-icon\" style=\"\"><svg width=\"32px\" height=\"20px\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 24 24\"><path fill=\"#000\" d=\"M14.258 10.152L23.176 0h-2.113l-7.747 8.813L7.133 0H0l9.352 13.328L0 23.973h2.113l8.176-9.309 6.531 9.309h7.133zm-2.895 3.293l-.949-1.328L2.875 1.56h3.246l6.086 8.523.945 1.328 7.91 11.078h-3.246zm0 0\"\/><\/svg><\/span><span class=\"shariff-text\">teilen<\/span>&nbsp;<\/a><\/li><li class=\"shariff-button xing shariff-nocustomcolor\" style=\"background-color:#29888a\"><a href=\"https:\/\/www.xing.com\/spi\/shares\/new?url=https%3A%2F%2Fwww.psw-group.de%2Fblog%2Fzero-trust-architektur-erklaert%2F\" title=\"Bei XING teilen\" aria-label=\"Bei XING teilen\" role=\"button\" rel=\"noopener nofollow\" class=\"shariff-link\" style=\"; background-color:#126567; color:#fff\" target=\"_blank\"><span class=\"shariff-icon\" style=\"\"><svg width=\"32px\" height=\"20px\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 25 32\"><path fill=\"#126567\" d=\"M10.7 11.9q-0.2 0.3-4.6 8.2-0.5 0.8-1.2 0.8h-4.3q-0.4 0-0.5-0.3t0-0.6l4.5-8q0 0 0 0l-2.9-5q-0.2-0.4 0-0.7 0.2-0.3 0.5-0.3h4.3q0.7 0 1.2 0.8zM25.1 0.4q0.2 0.3 0 0.7l-9.4 16.7 6 11q0.2 0.4 0 0.6-0.2 0.3-0.6 0.3h-4.3q-0.7 0-1.2-0.8l-6-11.1q0.3-0.6 9.5-16.8 0.4-0.8 1.2-0.8h4.3q0.4 0 0.5 0.3z\"\/><\/svg><\/span><span class=\"shariff-text\">teilen<\/span>&nbsp;<\/a><\/li><li class=\"shariff-button linkedin shariff-nocustomcolor\" style=\"background-color:#1488bf\"><a href=\"https:\/\/www.linkedin.com\/sharing\/share-offsite\/?url=https%3A%2F%2Fwww.psw-group.de%2Fblog%2Fzero-trust-architektur-erklaert%2F\" title=\"Bei LinkedIn teilen\" aria-label=\"Bei LinkedIn teilen\" role=\"button\" rel=\"noopener nofollow\" class=\"shariff-link\" style=\"; background-color:#0077b5; color:#fff\" target=\"_blank\"><span class=\"shariff-icon\" style=\"\"><svg width=\"32px\" height=\"20px\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 27 32\"><path fill=\"#0077b5\" d=\"M6.2 11.2v17.7h-5.9v-17.7h5.9zM6.6 5.7q0 1.3-0.9 2.2t-2.4 0.9h0q-1.5 0-2.4-0.9t-0.9-2.2 0.9-2.2 2.4-0.9 2.4 0.9 0.9 2.2zM27.4 18.7v10.1h-5.9v-9.5q0-1.9-0.7-2.9t-2.3-1.1q-1.1 0-1.9 0.6t-1.2 1.5q-0.2 0.5-0.2 1.4v9.9h-5.9q0-7.1 0-11.6t0-5.3l0-0.9h5.9v2.6h0q0.4-0.6 0.7-1t1-0.9 1.6-0.8 2-0.3q3 0 4.9 2t1.9 6z\"\/><\/svg><\/span><span class=\"shariff-text\">teilen<\/span>&nbsp;<\/a><\/li><\/ul><\/div>","protected":false},"excerpt":{"rendered":"<p>Zero Trust ist kein einzelnes Produkt, das Unternehmen installieren und anschlie\u00dfend als erledigt betrachten k\u00f6nnen. Vielmehr handelt es sich um ein Sicherheitsmodell, dessen Prinzipien sich durch die gesamte IT-Architektur ziehen. Der zentrale Gedanke: Kein Benutzer, Ger\u00e4t oder Workload erh\u00e4lt allein aufgrund seines Netzwerkstandorts automatisch Vertrauen. Zugriffe werden stattdessen explizit gepr\u00fcft, m\u00f6glichst restriktiv vergeben und anhand relevanter Sicherheitssignale bewertet. Eine Zero Trust Architektur verbindet daf\u00fcr verschiedene technische und organisatorische Komponenten. Identit\u00e4tsmanagement, [&hellip;]<\/p>\n","protected":false},"author":67,"featured_media":12466,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[379],"tags":[1039,1526],"class_list":["post-12465","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-security","tag-zero-trust","tag-zero-trust-architektur"],"_links":{"self":[{"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/posts\/12465","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/users\/67"}],"replies":[{"embeddable":true,"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/comments?post=12465"}],"version-history":[{"count":3,"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/posts\/12465\/revisions"}],"predecessor-version":[{"id":12469,"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/posts\/12465\/revisions\/12469"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/media\/12466"}],"wp:attachment":[{"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/media?parent=12465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/categories?post=12465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.psw-group.de\/blog\/wp-json\/wp\/v2\/tags?post=12465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}