Bei Zero Trust entscheidet nicht allein die Identit\u00e4t eines Benutzers dar\u00fcber, ob ein Zugriff erlaubt wird. Selbst ein korrekt authentifizierter Mitarbeiter kann ein Sicherheitsrisiko darstellen, wenn er von einem kompromittierten Laptop, einem ungepatchten Rechner, einem privaten Smartphone oder einem unbekannten Endger\u00e4t auf Unternehmensressourcen zugreift.<\/p>\n
Genau hier setzt Device Trust<\/strong> an. Vor einem Zugriff wird nicht nur betrachtet, wer<\/strong> auf eine Anwendung oder auf Daten zugreifen m\u00f6chte, sondern auch, welches Ger\u00e4t<\/strong> daf\u00fcr verwendet wird und ob dieses die definierten Sicherheitsanforderungen erf\u00fcllt.<\/p>\n Damit erg\u00e4nzt Ger\u00e4tevertrauen die Benutzeridentit\u00e4t um eine weitere wichtige Ebene. Ein erfolgreiches Login oder eine bestandene Multi-Faktor-Authentifizierung reichen nicht zwangsl\u00e4ufig aus, wenn das verwendete Ger\u00e4t selbst ein erh\u00f6htes Risiko darstellt.<\/p>\n Doch wann gilt ein Ger\u00e4t \u00fcberhaupt als vertrauensw\u00fcrdig? Welche Rolle spielen Device Posture, Ger\u00e4temanagement und digitale Zertifikate? Und wie f\u00fcgt sich Device Trust in eine Zero-Trust-Architektur ein?<\/p>\n Device Trust<\/strong> beziehungsweise Ger\u00e4tevertrauen beschreibt die Bewertung der Identit\u00e4t und des Sicherheitszustands eines Ger\u00e4ts im Zusammenhang mit einer Zugriffsentscheidung.<\/p>\n Ein Ger\u00e4t erh\u00e4lt dabei nicht automatisch weitreichenden Zugriff, nur weil sich ein legitimer Benutzer darauf erfolgreich authentifiziert hat. Unternehmen k\u00f6nnen vielmehr festlegen, welche Voraussetzungen ein Endger\u00e4t erf\u00fcllen muss, bevor es auf bestimmte Anwendungen, Daten oder Dienste zugreifen darf.<\/p>\n Dabei sollte Device Trust nicht als dauerhaftes Label nach dem Muster \u201edieses Ger\u00e4t ist vertrauensw\u00fcrdig\u201c verstanden werden. Der Sicherheitszustand eines Endger\u00e4ts kann sich ver\u00e4ndern. Ein Notebook, das heute vollst\u00e4ndig gepatcht und richtlinienkonform ist, kann morgen durch eine neue Schwachstelle, eine ver\u00e4nderte Konfiguration oder eine erkannte Kompromittierung ein anderes Risikoprofil besitzen.<\/p>\n Auch der jeweilige Anwendungsfall spielt eine Rolle. Ein privates Smartphone k\u00f6nnte beispielsweise f\u00fcr den Zugriff auf weniger sensible Informationen akzeptiert werden, w\u00e4hrend f\u00fcr eine kritische Unternehmensanwendung ausschlie\u00dflich zentral verwaltete und besonders abgesicherte Ger\u00e4te zugelassen werden.<\/p>\n Device Trust ist deshalb idealerweise richtlinien-, risiko- und kontextabh\u00e4ngig<\/strong>. Dieses Prinzip passt unmittelbar zu Zero Trust: Vertrauen wird nicht dauerhaft vorausgesetzt, sondern f\u00fcr einen konkreten Zugriff anhand verf\u00fcgbarer Informationen bewertet.<\/p>\n Wie dieses Sicherheitsmodell grunds\u00e4tzlich funktioniert, erl\u00e4utern wir ausf\u00fchrlich in unserem Beitrag zu Zero Trust Security<\/a>.<\/p>\n Wie Device Trust praktisch in eine Zugriffsentscheidung einflie\u00dfen kann, l\u00e4sst sich anhand eines typischen Beispiels verdeutlichen: Ein Mitarbeiter m\u00f6chte aus dem Homeoffice auf eine interne Unternehmensanwendung zugreifen.<\/p>\n Zun\u00e4chst wird gepr\u00fcft, wer den Zugriff anfordert. Hier greifen \u00fcblicherweise Mechanismen des Identity & Access Managements. Der Mitarbeiter meldet sich mit seiner Benutzeridentit\u00e4t an und muss \u2013 abh\u00e4ngig von den Sicherheitsrichtlinien \u2013 zus\u00e4tzlich eine Multi-Faktor-Authentifizierung durchf\u00fchren.<\/p>\n Damit kann die Identit\u00e4t des Benutzers mit h\u00f6herer Sicherheit \u00fcberpr\u00fcft werden. Die Benutzeridentit\u00e4t beantwortet jedoch noch nicht die Frage, ob auch das verwendete Endger\u00e4t den Sicherheitsanforderungen entspricht.<\/p>\n Im n\u00e4chsten Schritt wird deshalb betrachtet, von welchem Ger\u00e4t die Anfrage stammt. Ist das Notebook dem Unternehmen bekannt? Ist es registriert und zentral verwaltet? Besitzt es eine \u00fcberpr\u00fcfbare Ger\u00e4teidentit\u00e4t?<\/p>\n Eine Ger\u00e4te-ID allein ist dabei nicht zwangsl\u00e4ufig ein starker kryptografischer Identit\u00e4tsnachweis. F\u00fcr eine belastbarere Authentifizierung k\u00f6nnen deshalb beispielsweise digitale Ger\u00e4tezertifikate<\/strong> eingesetzt werden.<\/p>\n \u00dcber eine Public Key Infrastructure l\u00e4sst sich eine Ger\u00e4teidentit\u00e4t mit kryptografischen Schl\u00fcsseln verbinden. Das erm\u00f6glicht es dem Ger\u00e4t, seine Identit\u00e4t gegen\u00fcber einem Dienst oder einer Infrastruktur nachzuweisen.<\/p>\n Zu wissen, welches Ger\u00e4t zugreift, reicht ebenfalls noch nicht aus. Zus\u00e4tzlich muss bewertet werden, ob sich dieses Ger\u00e4t in einem akzeptablen Sicherheitszustand befindet. H\u00e4ufig wird in diesem Zusammenhang von Device Posture<\/strong> gesprochen.<\/p>\n Abh\u00e4ngig von der eingesetzten Infrastruktur k\u00f6nnen beispielsweise folgende Kriterien ber\u00fccksichtigt werden:<\/p>\n Welche Kriterien tats\u00e4chlich erforderlich sind, h\u00e4ngt von den Sicherheitsrichtlinien und vom Schutzbedarf der angeforderten Ressource ab.<\/p>\n Benutzeridentit\u00e4t, Ger\u00e4teinformationen und Sicherheitszustand k\u00f6nnen anschlie\u00dfend gemeinsam gegen die festgelegten Zugriffsrichtlinien gepr\u00fcft werden.<\/p>\n Ein bekanntes Beispiel w\u00e4re: Der Mitarbeiter ist erfolgreich per MFA authentifiziert, verwendet ein zentral verwaltetes Unternehmensger\u00e4t und dieses erf\u00fcllt die aktuellen Sicherheitsvorgaben. Die Richtlinie kann in diesem Fall den Zugriff auf eine Gesch\u00e4ftsanwendung erlauben.<\/p>\n Greift derselbe Mitarbeiter dagegen von einem unbekannten privaten Ger\u00e4t zu, k\u00f6nnte die Entscheidung anders ausfallen. Je nach Schutzbedarf kann der Zugriff beispielsweise eingeschr\u00e4nkt, eine zus\u00e4tzliche Sicherheitsma\u00dfnahme gefordert oder der Zugriff vollst\u00e4ndig verweigert werden.<\/p>\n Wichtig ist: Solche Entscheidungen sind keine universellen Regeln von Device Trust. Unternehmen definieren selbst, welche Kombination aus Identit\u00e4t, Ger\u00e4tezustand, Ressource und Kontext f\u00fcr ihre jeweilige Umgebung akzeptabel ist.<\/p>\n Ger\u00e4tevertrauen sollte nicht mit der erfolgreichen Erstpr\u00fcfung enden. Der Zustand eines Ger\u00e4ts kann sich auch w\u00e4hrend seines Lebenszyklus oder w\u00e4hrend einer bestehenden Zugriffssituation ver\u00e4ndern.<\/p>\n Wird beispielsweise erkannt, dass ein Endger\u00e4t nicht mehr den Compliance-Vorgaben entspricht oder ein erh\u00f6htes Risiko aufweist, kann diese Information in weitere Zugriffsentscheidungen einflie\u00dfen. Je nach Architektur und Richtlinie l\u00e4sst sich ein Zugriff dann beispielsweise begrenzen oder entziehen.<\/p>\n Device Trust wird damit dynamisch bewertet und nicht dauerhaft vergeben.<\/strong><\/p>\n Eine allgemeing\u00fcltige Definition, ab welchem Punkt jedes Ger\u00e4t als \u201evertrauensw\u00fcrdig\u201c gilt, gibt es nicht. Die Anforderungen h\u00e4ngen vom Unternehmen, vom Schutzbedarf der Ressourcen und von den jeweils eingesetzten Sicherheitskontrollen ab.<\/p>\n Einige Kriterien spielen jedoch regelm\u00e4\u00dfig eine wichtige Rolle.<\/p>\n Ein Endger\u00e4t sollte einen ausreichenden Patch- und Aktualisierungsstand besitzen. Sicherheitsupdates f\u00fcr Betriebssystem und Anwendungen schlie\u00dfen bekannte Schwachstellen und reduzieren damit m\u00f6gliche Angriffspunkte.<\/p>\n Zur Device Posture geh\u00f6ren h\u00e4ufig weitere Merkmale. Unternehmen k\u00f6nnen beispielsweise verlangen, dass der lokale Datentr\u00e4ger verschl\u00fcsselt ist, eine vorgeschriebene Endpoint-Security-L\u00f6sung aktiv ist oder bestimmte Konfigurationseinstellungen eingehalten werden.<\/p>\n Besonders bei mobilen Ger\u00e4ten und Laptops ist die Verschl\u00fcsselung des Ger\u00e4tespeichers relevant. Geht ein Ger\u00e4t verloren oder wird gestohlen, soll dadurch verhindert werden, dass gespeicherte Unternehmensdaten ohne Weiteres ausgelesen werden k\u00f6nnen.<\/p>\n Eine weitere wichtige Grundlage f\u00fcr Ger\u00e4tevertrauen ist Transparenz. Unternehmen m\u00fcssen wissen, welche Ger\u00e4te auf ihre Ressourcen zugreifen und welchen Status diese besitzen.<\/p>\n Mobile Device Management (MDM) beziehungsweise Unified Endpoint Management (UEM) kann dabei unterst\u00fctzen, Ger\u00e4te zentral zu registrieren, zu konfigurieren und ihren Compliance-Zustand zu bewerten.<\/p>\n Ein zentral verwaltetes Ger\u00e4t ist dadurch nicht automatisch sicher. Das Management schafft aber eine wichtige Voraussetzung daf\u00fcr, Konfigurationen und Sicherheitsanforderungen kontrolliert durchzusetzen und Ver\u00e4nderungen sichtbar zu machen.<\/p>\n Neben dem Sicherheitszustand spielt die Identit\u00e4t des Ger\u00e4ts eine wichtige Rolle. Schlie\u00dflich m\u00fcssen Unternehmen zuverl\u00e4ssig unterscheiden k\u00f6nnen, welches Endger\u00e4t eine Verbindung aufbauen m\u00f6chte.<\/p>\n Eine einfache technische Kennung oder Device ID kann zwar zur Identifikation beitragen, ist aber nicht zwangsl\u00e4ufig mit einem kryptografischen Identit\u00e4tsnachweis gleichzusetzen.<\/p>\n Hier k\u00f6nnen Ger\u00e4tezertifikate und PKI<\/strong> eine wichtige Rolle \u00fcbernehmen. Sie erm\u00f6glichen eine kryptografisch \u00fcberpr\u00fcfbare Ger\u00e4teidentit\u00e4t und k\u00f6nnen zur Authentifizierung gegen\u00fcber Unternehmensdiensten eingesetzt werden.<\/p>\n Device Trust klingt zun\u00e4chst nach einer klaren technischen Aufgabe: Ger\u00e4t identifizieren, Sicherheitsstatus pr\u00fcfen und anschlie\u00dfend eine Entscheidung treffen. In der Unternehmenspraxis wird diese Aufgabe jedoch durch die Vielzahl unterschiedlicher Endger\u00e4te und Nutzungsszenarien komplexer.<\/p>\n Neben klassischen Desktop-PCs und Notebooks greifen heute Smartphones, Tablets und zahlreiche weitere vernetzte Systeme auf Unternehmensressourcen zu. In Industrie- und IoT-Umgebungen kommen Maschinen, Sensoren, Gateways und andere Ger\u00e4te hinzu.<\/p>\n Diese Ger\u00e4te unterscheiden sich hinsichtlich Betriebssystem, Verwaltungsf\u00e4higkeit, Lebenszyklus und Sicherheitsmechanismen erheblich. Eine Device-Trust-Strategie muss deshalb ber\u00fccksichtigen, welche Ger\u00e4tearten tats\u00e4chlich vorhanden sind und welche Sicherheitsinformationen sich f\u00fcr sie zuverl\u00e4ssig erfassen lassen.<\/p>\n Ein Ger\u00e4t kann zum Zeitpunkt seiner Registrierung alle Sicherheitsanforderungen erf\u00fcllen und sp\u00e4ter dennoch ein Risiko darstellen. Beispielsweise k\u00f6nnen wichtige Updates fehlen, Konfigurationen ver\u00e4ndert oder Bedrohungen auf dem Endger\u00e4t erkannt werden.<\/p>\n Device Trust sollte deshalb nicht ausschlie\u00dflich aus einer einmaligen Ger\u00e4teaufnahme abgeleitet werden. Relevant ist vielmehr der m\u00f6glichst aktuelle Zustand des Ger\u00e4ts im Moment einer Zugriffsentscheidung beziehungsweise bei einer sp\u00e4teren Neubewertung.<\/p>\n Bring Your Own Device (BYOD) macht Device Trust besonders anspruchsvoll. Bei privaten Smartphones oder Notebooks besitzen Unternehmen naturgem\u00e4\u00df weniger Kontrolle \u00fcber Konfiguration, installierte Software und Nutzung.<\/p>\n Trotzdem k\u00f6nnen Mitarbeiter auf bestimmte Unternehmensressourcen angewiesen sein. Eine m\u00f6gliche Strategie besteht deshalb darin, den Zugriff abh\u00e4ngig vom Ger\u00e4t und Schutzbedarf zu differenzieren. Ein nicht verwaltetes Endger\u00e4t k\u00f6nnte beispielsweise lediglich einen eingeschr\u00e4nkten Zugriff erhalten, w\u00e4hrend sensible Anwendungen ein vollst\u00e4ndig verwaltetes und richtlinienkonformes Unternehmensger\u00e4t voraussetzen.<\/p>\n Technische Kontrollen allein reichen deshalb nicht aus. Unternehmen m\u00fcssen zun\u00e4chst wissen, welche Ger\u00e4te existieren, wem sie geh\u00f6ren, auf welche Ressourcen sie zugreifen und welche Ger\u00e4te die festgelegten Richtlinien erf\u00fcllen.<\/p>\n Hinzu kommen organisatorische Fragen: Wer definiert die Anforderungen an ein vertrauensw\u00fcrdiges Ger\u00e4t? Wie werden Ausnahmen behandelt? Was passiert, wenn ein Ger\u00e4t die Compliance verliert? Und wann muss ein Ger\u00e4t aus dem Bestand entfernt oder sein Zugriff entzogen werden?<\/p>\n Device Trust ben\u00f6tigt damit sowohl technische Kontrollm\u00f6glichkeiten als auch klare Prozesse und Verantwortlichkeiten.<\/p>\n Ein wichtiger Baustein f\u00fcr eine starke Ger\u00e4teidentit\u00e4t sind digitale Ger\u00e4tezertifikate<\/strong>. Sie basieren typischerweise auf einer Public Key Infrastructure (PKI) und erm\u00f6glichen eine kryptografisch \u00fcberpr\u00fcfbare Authentifizierung.<\/p>\n Ein digitales Zertifikat enth\u00e4lt unter anderem einen \u00f6ffentlichen Schl\u00fcssel und Identit\u00e4tsinformationen. Der zugeh\u00f6rige private Schl\u00fcssel muss gesch\u00fctzt werden und verbleibt idealerweise sicher auf beziehungsweise bei dem jeweiligen Ger\u00e4t.<\/p>\n Bei der Authentifizierung kann das Ger\u00e4t nachweisen, dass es \u00fcber den zugeh\u00f6rigen privaten Schl\u00fcssel verf\u00fcgt. Dadurch l\u00e4sst sich \u00fcberpr\u00fcfen, ob die vorgelegte kryptografische Identit\u00e4t tats\u00e4chlich zu dem erwarteten Ger\u00e4t beziehungsweise Schl\u00fcsselpaar geh\u00f6rt.<\/p>\n Die zugrunde liegende Frage lautet vereinfacht:<\/p>\n \u201eKann sich dieses Ger\u00e4t mit der registrierten und erwarteten kryptografischen Identit\u00e4t ausweisen?\u201c<\/strong><\/p>\n Ger\u00e4tezertifikate k\u00f6nnen in unterschiedlichen Szenarien eingesetzt werden, beispielsweise f\u00fcr die Authentifizierung in Unternehmens-WLANs, f\u00fcr VPN- oder ZTNA-Zugriffe, f\u00fcr Unternehmensanwendungen sowie in IoT- und Machine-to-Machine-Umgebungen.<\/p>\n PKI-basierte Ger\u00e4teidentit\u00e4ten sind insbesondere dann interessant, wenn eine gro\u00dfe Zahl von Maschinen, Ger\u00e4ten oder Workloads zuverl\u00e4ssig authentifiziert werden muss. Der Lebenszyklus dieser Zertifikate muss dabei vollst\u00e4ndig ber\u00fccksichtigt werden \u2013 von Ausstellung und Bereitstellung \u00fcber Erneuerung bis hin zum Widerruf nicht mehr vertrauensw\u00fcrdiger beziehungsweise nicht mehr verwendeter Zertifikate.<\/p>\n Zertifikatsbasierte Authentifizierung kann au\u00dferdem die Abh\u00e4ngigkeit von Passw\u00f6rtern reduzieren. Dabei muss jedoch zwischen Benutzer- und Ger\u00e4teauthentifizierung unterschieden werden: Ein Ger\u00e4tezertifikat ersetzt nicht automatisch s\u00e4mtliche Authentifizierungsmechanismen des Benutzers.<\/p>\n So wichtig eine \u00fcberpr\u00fcfbare Ger\u00e4teidentit\u00e4t ist: Ein g\u00fcltiges Ger\u00e4tezertifikat allein macht ein Endger\u00e4t noch nicht automatisch vertrauensw\u00fcrdig.<\/strong><\/p>\n Das Zertifikat unterst\u00fctzt die Frage, ob sich das Ger\u00e4t mit der erwarteten kryptografischen Identit\u00e4t authentifizieren kann. Daraus l\u00e4sst sich jedoch nicht automatisch ableiten, ob das Betriebssystem aktuell ist, die Festplatte verschl\u00fcsselt wurde, die erforderliche Endpoint Protection l\u00e4uft oder das Ger\u00e4t m\u00f6glicherweise kompromittiert ist.<\/p>\n Genau deshalb m\u00fcssen Ger\u00e4teidentit\u00e4t und Sicherheitszustand getrennt betrachtet und anschlie\u00dfend zusammengef\u00fchrt werden<\/strong>.<\/p>\n Vereinfacht l\u00e4sst sich der Zusammenhang f\u00fcr die Praxis so zusammenfassen:<\/p>\n Ger\u00e4teidentit\u00e4t + Device Posture + Zugriffsrichtlinien + laufende Neubewertung = Device Trust<\/strong><\/p>\n Diese Darstellung ist keine technische Norm oder mathematische Formel. Sie verdeutlicht jedoch, warum Device Trust mehr umfasst als die Ausstellung eines Zertifikats oder die Registrierung eines Ger\u00e4ts.<\/p>\n Eine kryptografisch zuverl\u00e4ssige Ger\u00e4teidentit\u00e4t beantwortet die Frage, welches Ger\u00e4t<\/strong> zugreift. Die Device Posture liefert Informationen dar\u00fcber, in welchem Sicherheitszustand<\/strong> sich dieses Ger\u00e4t befindet. Erst die jeweiligen Policies bestimmen anschlie\u00dfend, was diese Informationen f\u00fcr einen konkreten Zugriff bedeuten.<\/p>\n In einer modernen Zero-Trust-Umgebung m\u00fcssen diese verschiedenen Informationen zusammengef\u00fchrt werden. Dabei erf\u00fcllen Ger\u00e4temanagement, PKI und die eigentliche Zugriffsarchitektur unterschiedliche Aufgaben.<\/p>\n MDM- und UEM-Plattformen schaffen Transparenz \u00fcber verwaltete Endger\u00e4te und k\u00f6nnen Informationen zu deren Konfiguration und Compliance bereitstellen.<\/p>\n Zu diesen Informationen k\u00f6nnen beispielsweise Betriebssystem- und Patchstand, Verschl\u00fcsselung, Ger\u00e4tekonfiguration und die Einhaltung definierter Unternehmensrichtlinien geh\u00f6ren.<\/p>\n Dadurch l\u00e4sst sich erkennen, ob ein registriertes Ger\u00e4t aktuell die f\u00fcr einen bestimmten Zugriff erforderlichen Sicherheitsanforderungen erf\u00fcllt.<\/p>\n Die PKI \u00fcbernimmt eine andere Aufgabe. Mit digitalen Zertifikaten und den dazugeh\u00f6rigen Schl\u00fcsselpaaren l\u00e4sst sich eine kryptografische Ger\u00e4teidentit\u00e4t etablieren und f\u00fcr Authentifizierungsprozesse verwenden.<\/p>\n Damit kann ein Unternehmen nicht nur wissen, dass ein Ger\u00e4t in einem Inventar eingetragen ist, sondern dessen Identit\u00e4t bei einer entsprechenden zertifikatsbasierten Authentifizierung kryptografisch \u00fcberpr\u00fcfen.<\/p>\n Gerade bei einer gro\u00dfen Zahl an Ger\u00e4ten und Maschinenidentit\u00e4ten gewinnt dabei das automatisierte Zertifikatsmanagement an Bedeutung. Zertifikate m\u00fcssen zuverl\u00e4ssig ausgestellt, verteilt, erneuert und bei Bedarf widerrufen werden.<\/p>\n Zero Trust verbindet schlie\u00dflich die Ger\u00e4teinformationen mit weiteren Sicherheitssignalen. Zu einer Zugriffsentscheidung k\u00f6nnen neben Ger\u00e4teidentit\u00e4t und Device Posture beispielsweise auch Benutzeridentit\u00e4t, MFA-Status, Standort, angeforderte Anwendung und aktuelle Risikoinformationen beitragen.<\/p>\n Aus dieser Kombination ergibt sich abh\u00e4ngig von der jeweiligen Policy eine konkrete Entscheidung. Der Zugriff kann erlaubt oder verweigert, auf bestimmte Ressourcen beschr\u00e4nkt oder von zus\u00e4tzlichen Anforderungen abh\u00e4ngig gemacht werden.<\/p>\n Wie diese Informationen innerhalb einer Zero-Trust-Umgebung zu einer technischen Zugriffsentscheidung zusammengef\u00fchrt werden und welche Rolle dabei Policy Engine, Policy Administrator und Policy Enforcement Point spielen, erkl\u00e4ren wir ausf\u00fchrlich in unserem Beitrag zur Zero Trust Architektur<\/a>.<\/p>\n Ein besonders anschauliches Einsatzgebiet f\u00fcr Device Trust ist Zero Trust Network Access<\/strong>. Bei ZTNA soll ein Benutzer nicht allein aufgrund einer erfolgreichen Verbindung Zugriff auf ein komplettes Netzwerk erhalten. Stattdessen wird der Zugriff m\u00f6glichst gezielt auf ben\u00f6tigte Anwendungen oder Ressourcen beschr\u00e4nkt.<\/p>\n Die Ger\u00e4teidentit\u00e4t und der aktuelle Ger\u00e4tezustand k\u00f6nnen dabei wichtige Signale f\u00fcr die Zugriffsentscheidung liefern.<\/p>\n Ein Beispiel: Ein Mitarbeiter meldet sich korrekt an und best\u00e4tigt seine Identit\u00e4t erfolgreich per MFA. Sein Notebook wurde jedoch seit l\u00e4ngerer Zeit nicht mehr aktualisiert und erf\u00fcllt deshalb die vom Unternehmen festgelegten Sicherheitsanforderungen nicht mehr.<\/p>\n Die g\u00fcltige Benutzeridentit\u00e4t allein muss in diesem Fall nicht ausreichen. Eine entsprechende Zugriffsrichtlinie k\u00f6nnte den Zugriff auf eine sensible Anwendung verweigern oder einschr\u00e4nken, bis das Ger\u00e4t wieder den geforderten Sicherheitsstatus erreicht.<\/p>\n Umgekehrt kann ein bekanntes, verwaltetes und richtlinienkonformes Ger\u00e4t zusammen mit einer erfolgreich gepr\u00fcften Benutzeridentit\u00e4t ein positives Signal f\u00fcr die Zugriffsentscheidung liefern.<\/p>\n Device Trust und ZTNA erg\u00e4nzen sich damit: Device Trust liefert wichtige Informationen dar\u00fcber, welches Ger\u00e4t verwendet wird und welchen Sicherheitszustand es besitzt<\/strong>. ZTNA kann diese Informationen gemeinsam mit Identit\u00e4ts- und Kontextsignalen verwenden, um den Zugriff auf konkrete Ressourcen zu steuern.<\/p>\nWas ist Device Trust?<\/h2>\n
Wie funktioniert Device Trust?<\/h2>\n
1. Benutzer authentifizieren<\/h3>\n
2. Ger\u00e4t identifizieren<\/h3>\n
3. Sicherheitszustand des Ger\u00e4ts pr\u00fcfen<\/h3>\n
\n
4. Zugriffsrichtlinien anwenden<\/h3>\n
5. Sicherheitszustand weiter beobachten<\/h3>\n
Wann gilt ein Ger\u00e4t als vertrauensw\u00fcrdig?<\/h2>\n
Aktueller und richtlinienkonformer Sicherheitszustand<\/h3>\n
Zentrale Verwaltung und Transparenz<\/h3>\n
Eindeutige und \u00fcberpr\u00fcfbare Ger\u00e4teidentit\u00e4t<\/h3>\n
Worauf Unternehmen bei Device Trust achten m\u00fcssen<\/h2>\n
Immer mehr unterschiedliche Endger\u00e4te<\/h3>\n
Der Sicherheitszustand ist dynamisch<\/h3>\n
BYOD stellt besondere Anforderungen<\/h3>\n
Device Trust ben\u00f6tigt Transparenz und Governance<\/h3>\n
Wie funktionieren Ger\u00e4tezertifikate?<\/h2>\n
Warum Device Trust mehr als ein Ger\u00e4tezertifikat ist<\/h2>\n
Wie arbeiten Ger\u00e4temanagement, PKI und Zero Trust zusammen?<\/h2>\n
MDM und UEM liefern Informationen zum Ger\u00e4tezustand<\/h3>\n
PKI liefert eine kryptografisch \u00fcberpr\u00fcfbare Ger\u00e4teidentit\u00e4t<\/h3>\n
Zero Trust f\u00fchrt die Informationen zusammen<\/h3>\n
Welche Rolle spielt Device Trust bei ZTNA?<\/h2>\n