Privacyzentriertes Zero Trust : Teil 2: Zero Trust in Privacy-sensitiven Umgebungen
Bei Zero-Trust-Umsetzungen in Enterprise-Umgebungen wird eine weitreichende Kontrolle und Überwachung der von Mitarbeitern* genutzten Endgeräte meist als notwendig akzeptiert. Wenn jedoch beispielsweise Bürger auf digitale Dienste einer Verwaltung oder im Gesundheitswesen zugreifen, widerspricht eine tiefgreifende Kontrolle von Nutzern und Endgeräten den Erwartungen zum Schutz der Privatsphäre und Selbstbestimmung über die eigenen Geräte. In diesen Umgebungen sind daher Verfahren gewünscht, die auch unter eingeschränkter Überwachung ausreichend Sicherheit bieten.
Von Steffen Ullrich, Jena
Die zunehmende Digitalisierung führt zum Wunsch – aber auch zur Notwendigkeit – der digitalen Verfügbarkeit immer sensitiverer Daten auf der einen sowie einer gleichzeitig steigenden Komplexität und damit höheren Vulnerabilität auf der anderen Seite. Das erhöht die Attraktivität von Cyberangriffen für Kriminelle und staatliche Angreifer – Ransomware, Wirtschaftsspionage oder Cyberangriffe auf Produktion und kritische Infrastrukturen sind inzwischen allgegenwärtig. In diesem Umfeld gewinnt das Zero-Trust-Paradigma zunehmend an Bedeutung, da es ermöglicht, die Bedrohung systematisch zu verkleinern.
Eine Säule von Zero Trust (ZT) ist das Minimalitätsprinzip beim Zugriff, was bedeutet den Zugriff mit möglichst hoher Granularität nur auf das aktuell Gebrauchte zu begrenzen, nur so lange wie nötig zu erlauben – und damit sowohl proaktiv die Angriffsfläche als auch die Auswirkung erfolgreicher Angriffe zu verkleinern.
Die zweite Säule ist die kontinuierliche Validierung der Sicherheit von Nutzern und Endgeräten, um so eine Kompromittierung von Zugangsdaten oder Geräten frühzeitig zu entdecken und den Zugriff zu unterbinden.
Grundlage für eine erfolgreiche Einschätzung der Gerätesicherheit sind dabei vielfältige Zustandsinformationen, zum Beispiel zu Betriebssystemversion, installierter Software, installierten beziehungsweise ausstehenden Sicherheitspatches, Aktualität des Virenscanners, aktuell laufenden Prozessen et cetera. Zur Detektion einer Kompromittierung des Nutzer dient eine Anomalieerkennung basierend auf dem bisherigen Verhalten – zum Beispiel von wo und zu welchen Zeiten in der Vergangenheit Zugriffe erfolgt sind. Eine solche Verhaltensanalyse kann jedoch einen weitreichenden Eingriff in die Privatsphäre des Nutzers bedeuten. Oft sind auch spezielle Software-Agenten zur Kontrolle auf Endgeräten installiert, die einen Eingriff in dessen Funktionalität darstellen können.
Zero Trust kommt typischerweise in Enterprise-Umgebungen zum Einsatz, bei denen es um den Schutz firmeneigener Daten geht. Hier lässt sich bereits durch den Einsatz starker Nutzerauthentifizierung und restriktiv gemanagter Endgeräte für die eigenen Mitarbeiter eine hohe Prävention erreichen. Entsprechende Beschränkungen und auch eine gewisse Verhaltensanalyse der eigenen Mitarbeiter werden für den Schutz der Firmendaten meist als akzeptabel angesehen. Schwieriger ist es, wenn Dienstleister einen limitierten Zugriff bekommen sollen, weil deren Endgeräte im Allgemeinen vom Dienstleister selbst und nicht von der eigenen Firma verwaltet werden. Dienstleister sehen vermutlich sowohl die Überwachung ihrer Mitarbeiter als auch deren Geräte durch Kunden als problematisch an – ganz zu schweigen davon, dass fremdkontrollierte Software auf den eigenen Geräten auch ein Sicherheitsrisiko darstellen kann.
Noch schwieriger wird es, wenn – wie im Gesundheitswesen oder bei Behörden – die zugreifenden Nutzer Bürger mit eigenen Endgeräten sind: Zum einen geht es hier nicht um den Schutz von Firmendaten, sondern Dateneigentümer sind die Bürger beziehungsweise Versicherten selbst. Deren Erwartung ist zum anderen, in ihren Aktivitäten nicht überwacht zu werden und die volle Selbstbestimmung über ihre Geräte zu behalten. Diese berechtigten Erwartungen erschweren allerdings die zum Zwecke der Datensicherheit gewünschte Entdeckung kompromittierter Geräte beziehungsweise Zugangsdaten.
Privacy-freundliches Zero Trust
Privacy-freundliche Zero-Trust-Lösungen sind überall dort gefragt, wo sich erfasste und gespeicherte Verhaltensinformationen von Nutzern über den eigentlichen Zweck der Zugriffskontrolle hinaus zum Nachteil des Anwenders missbrauchen lassen. Das schließt sowohl einen „geplanten Missbrauch“ ein, beispielsweise zur Kontrolle der Arbeitsleistung von Mitarbeitern – aber auch „ungeplanter Missbrauch“ durch Kriminelle gehört dazu, wie er etwa im Fall von Datenleaks auftreten kann. Und schließlich können derartige Datensammlungen auch das Interesse des Staates wecken, um sie beispielsweise entgegen der ursprünglichen Zweckbestimmung gleichermaßen zur Verfolgung von Straftaten zu nutzen. Privacy-freundliche Lösungen zu schaffen, verringert an solchen Stellen nicht nur das Potenzial von Missbrauch, sondern erhöht auch die Akzeptanz bei den Anwendern.
Privacy-Freundlichkeit umfasst dabei nicht nur die erfassten Daten selbst, sondern ebenfalls die Methoden zur Datensammlung und -verarbeitung sowie die dabei beteiligten Softwarekomponenten und Dienstleister. Diese haben bedingt durch die Art und Weise der Datenerfassung oft Zugriff auf mehr und sensitivere Daten als eigentlich benötigt und entsprechend sicher und vertrauensvoll müssen Software und Dienstleister agieren, um unerwünschte Datenabgriffe durch Insider und Externe zu verhindern. Besonders kritisch sind dabei auf dem Endgerät des Anwenders laufende Komponenten wie Policy-Enforcement-Point-(PEP)-Agenten, sowie Komponenten mit Zugriff auf die Kommunikation wie der PEP selbst.
Die Notwendigkeit von Privacy-freundlichen Zero-Trust-Lösungen ist offensichtlich bei Umgebungen mit einer hohen Erwartungshaltung an die Privatsphäre: Dazu gehört zum Beispiel das Gesundheitswesen, aber auch der Zugriff von Bürgern auf staatliche Verwaltungsdienste. Beim Zugriff von Dienstleistern auf Kundeninfrastrukturen kommt hinzu, dass auch aus Sicht von Compliance und Cybersicherheit eine Verhaltenskontrolle der eigenen Mitarbeiter und ein Eingriff in die eigenen Geräte durch den Kunden unerwünscht sind. Innerhalb von Firmen beschränken darüber hinaus sowohl die Interessen der Mitarbeiter als auch Gesetze den Umfang einer möglichen Verhaltenskontrolle. Und wo man von Dienstleistern gemanagte Zero-Trust-Infrastrukturen nutzt, liegt es im Interesse der Firmen selbst, diesem Dienstleister nur die wirklich notwendigen Zugriffe auf Daten und Geräte zu gestatten.
Involvierte ZT-Komponenten
Der grundlegende Ablauf bei einer Zero-Trust- Zugriffskontrolle besteht darin, dass Nutzer zum einen auf eine sichere Weise authentifiziert und zum anderen die Sicherheit der Geräte sowie eventuell der IT-Umgebung überprüft werden. Die dabei gesammelten Daten über Nutzer, Geräte und Umgebung kombiniert man oft mit historischen „Verhaltensmustern“ und wertet diese zusammen mit aktueller Threat-Intelligence über Zugriffsregeln aus. Die daraus resultierende Zugriffsentscheidung für eine spezifische Ressource (z. B. Netzwerke, Systeme, Anwendungen, URLs, Aktionen oder Dokumente) kann dabei den Zugriff zulassen, ablehnen oder eine erneute Zugriffsanfrage mit erhöhten Sicherheitsvorkehrungen (z. B. mit einem zusätzlichen Authentifizierungsmerkmal) verlangen – das sogenannte Step-up. Eine einmal erfolgte Authentifizierung und Überprüfung eines Geräts wird für eine bessere Usability und Performance typischerweise für eine gewisse Zeit für weitere Zugriffe, auch auf andere Ressourcen, nachgenutzt.
Im Folgenden wird beschrieben, wie sich diese Abläufe über die einzelnen Komponenten einer Zero-Trust-Architektur verteilen (vgl. Abb. 1) und welche Informationen dabei den jeweiligen Komponenten prinzipiell zugänglich sind, selbst wenn sie nicht für die Zugriffsentscheidung gebraucht werden.
Der Policy-Enforcement-Point-(PEP)-Agent läuft auf dem Endgerät des Nutzers und sammelt dort Daten über die Gerätesicherheit, wie die Version des Betriebssystems, installierte und aktuell laufende Anwendungen, eingespielte Patches und die Aktualität von Anti-Malware- Signaturen. Gegebenenfalls integriert sich der PEP-Agent hier mit auf dem System bereits laufenden Sicherheitslösungen des Plattformanbieters oder Endpoint-Security- Lösungen von Drittanbietern, um von diesen weitere Informationen über die Gerätesicherheit zu bekommen. In einigen Szenarien setzt der PEP-Agent auch direkt Sicherheitspolicies durch – zum Beispiel kann der in eine Online-Banking-App integrierte PEP-Agent den Start auf einem gerooteten Gerät verweigern.
Über den PEP-Agenten erfolgen die Registrierung und Attestierung eines Geräts am Gerätemanagement sowie die abgesicherte Kommunikation mit der Anwendung über den vorgeschalteten PEP. Für diese Aufgabe ist der PEP oft mit umfangreichen Rechten ausgestattet, die ihm prinzipiell nicht nur Zugriff auf die notwendigen Gerätedaten, sondern auch auf nicht benötigte Anwenderdaten und gegebenenfalls Systemdaten ermöglichen. Entsprechend wichtig ist das Vertrauen in den PEP-Agenten, dass tatsächlich nur die benötigten Daten erfasst werden. Wichtig ist aber auch die Resistenz gegen Angriffe auf den PEP-Agenten, da ein erfolgreicher Angreifer tiefen Zugriff auf Nutzerdaten und System erhalten und darüber hinaus die Sicherheit des Geräts grundlegend gefährden kann.
Der Policy-Enforcement-Point (PEP) selbst terminiert den Zugriff des Nutzers (via PEP-Agent) vor einer Anwendung und leitet die Kommunikation nur weiter, wenn Nutzer und Gerät korrekt authentifiziert und geprüft wurden und die vom PDP kontrollierten Zugriffspolicies den Zugriff erlauben. Der PEP hat dabei Kenntnis von Zielressource, Nutzer, Gerät und damit einhergehenden Eigenschaften, die für eine Zugriffsentscheidung übermittelt werden beziehungsweise sich aus dem Kontext der Anfrage ergeben (z. B. die Quell-IP-Adresse eines Zugriffs). Diese Informationen lassen sich für umfangreiches und detailliertes Tracking nutzen. Darüber hinaus terminiert der PEP die verschlüsselte Verbindung vom PEP-Agenten auf dem Endgerät und bekommt in vielen Fällen dadurch generellen Zugriff auf die Anwendungsdaten, obwohl diese für eine Zugriffsentscheidung irrelevant sind – der PEP wäre prinzipiell sogar in der Lage, transferierte Anwendungsdaten zu verändern. Ähnlich wie beim PEP-Agenten sind daher eine hohe Resistenz des PEP gegen Angriffe und außerdem die Ausführung durch einen vertrauenswürdigen Betreiber notwendig.
Im Policy-Decision-Point (PDP) werden die über Nutzer und Gerät erfassten Informationen von den für die Zielressource spezifischen Policies (aus PAP) und Attributen (aus PIP) zu einer Zugriffsentscheidung verarbeitet. Ähnlich zum PEP hat der PDP dadurch umfangreiche Informationen für detailliertes Tracking, im Gegensatz zum PEP jedoch keinen Zugriff auf die eigentliche Anfrage und auch nicht auf Anwendungsdaten. Der PEP enthält vom PDP nur die Zugriffsentscheidung, das heißt eine darüber hinausgehende Wirkung des PDP auf den Datentransfer ist nicht möglich.
Die im PDP benutzten eher statischen Regeln kommen vom Policy-Administration-Point (PAP) und werden mit dynamischeren Informationen aus dem Policy-Information-Point (PIP) ergänzt. PAP und PIP sammeln selbst keine Informationen, sondern bekommen diese nur bereitgestellt.
Im Monitoring laufen Informationen aus PEP, PDP, IDP (siehe unten) und dem zu schützenden Fachdienst zusammen. Das vorrangige Ziel im Kontext von Zero-Trust ist es, durch übergreifende Aggregation Auffälligkeiten festzustellen – zum Beispiel laufende Angriffe, potenziell kompromittierte Nutzer et cetera. Die Detektion von Auffälligkeiten resultiert dann in Updates der Informationen im PIP und kann so bei der Zugriffskontrolle im PDP einbezogen werden. Außerdem dienen Informationen aus dem Monitoring zur längerfristigen Verbesserung der statischen Regeln im PAP. Der Umfang und Detailgrad der im Monitoring anfallenden Daten richtet sich nach dem, was PEP, PDP, IDP und Fachdienst liefern: Umfangreiche und detaillierte Daten ermöglichen dabei auf der einen Seite ein granulareres Monitoring und die bessere Entdeckung von Auffälligkeiten, erhöhen andererseits aber auch das Missbrauchspotenzial. Die Daten werden vom Monitoring allerdings nur empfangen, eine direkte Rückwirkung auf die Zero-Trust-Komponenten ist also nicht möglich.
Der Identity-Provider (IDP) authentifiziert Nutzer und leitet gegebenenfalls nutzerspezifische Attribute (Rollen) und Eigenschaften der Authentifizierung (Methoden, Level of Assurance etc.) für die Zugriffsentscheidung an PEP und PDP weiter. Der IDP kann dabei grob tracken, wann ein Nutzer auf welche Anwendung zugreift, dies jedoch ohne Details zur spezifischen Ressource. Zusätzlich sieht der IDP Kontextinformationen des Zugriffs wie die Quell-IP-Adresse. Die Granularität des möglichen Trackings ist abhängig davon, wie oft eine Authentifizierung erfolgen oder deren Gültigkeit überprüft (Refresh) werden muss.
Ein gegebenenfalls existierendes Authenticator-Modul auf dem Endgerät oder einem anderen Gerät des Nutzers arbeitet mit dem IDP zusammen, um eine starke und gleichzeitig komfortable Authentifizierung zu ermöglichen. Diese kann zum Beispiel aus einer Kombination von hardwarebasierter Identität, unterstützt um eine biometrische Freigabe bestehen. Das Modul braucht dafür eine hohe Resistenz gegen Angriffe und integriert sich dazu (ähnlich wie der PEP-Agent) tief in das System. Als Folge hat das Modul eventuell auch Zugriff auf Nutzer- und Systemdaten und könnte zur Kompromittierung des Geräts genutzt werden, selbst wenn diese Zugriffsrechte für die eigentliche Funktion nicht notwendig wären.
Das Gerätemanagement (bzw. die Geräteregistrierung) arbeitet zum einen mit dem PEP-Agent und Diensten von Plattformanbietern bei der Attestierung der Gerätesicherheit zusammen, ohne jedoch eine schädliche Rückwirkung auf das Endgerät zu ermöglichen. Zum anderen erfolgt eine Verknüpfung von Geräten mit deren Nutzern, um so neben der Authentifizierung der Nutzer das registrierte Gerät als zusätzlichen Sicherheitsfaktor bei Zugriffsentscheidungen einbeziehen zu können. Entsprechend viele Daten über Geräte fallen beim Gerätemanagement an – dazu Informationen zur Identität der Nutzer sowie Kontextinformationen des Zugriffs (z. B. Quell-IPAdresse). Eine Korrelation mit dem benutzten Dienst ist jedoch nicht möglich. Die Granularität des möglichen Trackings ist davon abhängig, wie oft eine Geräteattestierung erfolgen beziehungsweise aktualisiert (Refresh) werden soll.
Bei der Attestierung der Gerätesicherheit sind oftmals Dienste von Plattformanbietern involviert, typischerweise bestehend aus einer Softwarekomponente sowie einem Attestierungsservice im Internet. Die Softwarekomponente auf dem Endgerät hat durch die benötigte tiefe Integration in das System ebenfalls umfangreiche Einblicke in das komplette Endgerät (etwa in Aktivitäten des Nutzers, Kommunikation und abgelegte Daten) – signifikant mehr, als für die Attestierung benötigt werden. Ähnlich wie beim PEP-Agenten können Sicherheitslücken in dieser Softwarekomponente eine Kompromittierung des Endgeräts zur Folge haben. Darüber hinaus sind diese Komponenten typischerweise proprietär und es ist nicht transparent, welche Informationen verwertet und mit dem Attestierungsservice ausgetauscht werden. Gleiches gilt für Endpoint-Sicherheitslösungen von Drittanbietern, die gegebenenfalls ebenfalls in die Attestierung integriert werden – die hier gesammelten Informationen betreffen aber nur das spezifische Gerät und sind nicht mit dem Nutzer assoziiert.
Neben all diesen direkt involvierten Komponenten können zudem auch Datensenken wie Logserver oder Security-Information-and-Event-Management (SIEM)-Systeme eingebunden sein, die von den einzelnen Komponenten sowohl Informationen zur generellen Funktion als auch zu einzelnen Verarbeitungsvorgängen erhalten und diese für Realtime-Anomalie- und -Angriffserkennung wie auch nachträgliche Analysen bei Incidents nutzen können.
Erhobene Daten
Aus den für die Komponenten prinzipiell verfügbaren Informationen wird, wie bereits angesprochen, nur ein Teil tatsächlich für die Zugriffsentscheidung benötigt. Die wesentlichen sensitiven Informationen sind dabei die Kombination von Nutzer, Endgerät, Anwendung, zugegriffenen Ressourcen (zum Beispiel URL), Quell-IPAdresse und Zugriffszeit, die zum einen für die aktuelle Zugriffsentscheidung benutzt werden sowie zur Entdeckung ungewöhnlichen Verhaltens in die Erstellung anwenderspezifischer Nutzungsprofile einfließen können.
Die erfassten Informationen werden für die Zugriffsentscheidung oftmals mit nutzerunabhängigen Informationen verknüpft: Aus der Quell-IP-Adresse des Zugriffs lassen sich zum Beispiel Adressverschleierungen wie VPN und Tor ablesen, um so Zugriffe aus mit Angriffen assoziierten Netzen zu unterbinden. Auch lässt sich eine grobe Geolocation ermitteln, um den Zugriff zum Beispiel auf bestimmte Herkunftsländer zu beschränken oder unmögliche kurzfristige Standortänderungen (Impossible Travel) als Indikator einer Kompromittierung zu erkennen. Ebenso verhaltensauffällig können ungewöhnliche Zeiten der Nutzung oder ungewohnt umfangreiche Aktivitäten in kurzer Zeit sein („Absaugen“ von Daten).
Für eine genauere Bestimmung des Standorts sind gegebenenfalls sensitive Informationen wie die GPS-basierte Lokalisierung oder in der Umgebung befindliche WLAN-Netze vonnöten. Auch lassen sich Eigenschaften des aktuellen Netzes wie Name und Verschlüsselung (z. B. öffentlicher Hotspot statt Firmennetz) für die Detektion von für den Nutzer untypischen beziehungsweise gefährlichen Umgebungen nutzen.
Weitere sensitive Informationen können die auf dem System installierten oder/und gerade laufenden Anwendungen sein, aktuell etablierte Kommunikationsverbindungen, bestimmte Konfigurationseinstellungen oder Ähnliches. Aus diesen lässt sich zum Teil auf eine bereits erfolgte Kompromittierung des Geräts schließen. Weniger Privacy-sensitiv, aber wichtig für die Zugriffskontrolle sind andere Information über die Sicherheit des Geräts: etwa installierte Patches, Aktualität des Anti-Virus-Programms oder Verfügbarkeit und Güte hardwarebasierter Schlüsselspeicher (z. B. ein Trusted-Platform-Module, TPM).
Checkliste |
|---|
Datensparsamkeit bei Erfassung, Weitergabe, Speicherung - nur so viele Daten erfassen wie zur Erreichung des Nutzens nötig |
Vertrauenswürdige, angriffsresistente Komponenten - besonders an kritischen Stellen Security by Design, Security by Default, Privacy by Design, Defence in Depth |
Vermeidung umfangreicher Datenanhäufung bei einem einzelnen Betreiber - stattdessen Daten organisatorisch verteilen |
Privacy-freundliche Verarbeitung
Ziel einer Privacy-freundlichen Datenverarbeitung ist es, Missbrauchsmöglichkeiten durch Betreiber, Insider und externe Angreifer so weit wie möglich zu beschränken, gleichzeitig aber ausreichend Nutzen für die Dateneigentümer zu ermöglichen. „Nutzen“ bedeutet im Kontext von Zero Trust, eine Zugriffskontrolle umzusetzen, die autorisierten Nutzern einen komfortablen Zugriff auf ihre Daten bietet und nicht-autorisierten Personen zuverlässig den Zugriff verweigert.
Ein wesentlicher Aspekt zur Einschränkung von Missbrauchsmöglichkeiten ist es, nur so viele Daten zu erfassen, zu verarbeiten, weiterzugeben und zu speichern, wie tatsächlich notwendig. Diese Datensparsamkeit gilt bei allen Schritten der Verarbeitung. Das heißt zum Beispiel, dass in Komponenten erfasste Daten zur Weitergabe an Monitoring, Logging und SIEM bereits so weit wie möglich von Privacy-sensitiven Informationen bereinigt werden – etwa durch Pseudonymisierung, Anonymisierung oder das Löschen von Teilinformationen oder auch durch Weitergabe lokal aggregierter Informationen statt detaillierter Originaldaten.
Überdies sind Daten permanent zu löschen, wenn man sie nicht mehr braucht. Entsprechend ist je nach Anwendungsfall zu analysieren, welche Privacy-sensitiven Daten tatsächlich an welchen Stellen und wie lange benötigt werden. Hierbei ist auch zu beachten, dass eine derartige Analyse nicht durch potenzielle Eigeninteressen der Betreiber verzerrt wird, die für ihre Geschäftsmodelle eventuell gerne mehr Daten zur Verfügung hätten. Dies gilt besonders für Dienstleister – beispielsweise wenn diese Daten kundenübergreifend zur Verbesserung ihrer Threat-Intelligence-Angebote nutzen wollen. Dabei sollte man aber durchaus berücksichtigen, dass eine kundenübergreifende Analyse von Daten durchaus auch Vorteile für jeden der beteiligten Kunden haben kann.
Um das Risiko des Missbrauchs von Sicherheitslücken durch Angreifer zu minimieren, sollte die Datensparsamkeit bei der Erfassung idealerweise technisch durchgesetzt werden, die datenerfassenden Komponenten also ausschließlich Zugriff auf tatsächlich benötigte Daten bekommen. Auf dem Endgerät eines Nutzers laufende Komponenten haben jedoch typischerweise Zugriff auf deutlich mehr Daten als nötig. Heutige Systeme ermöglichen leider im Allgemeinen keine Rechtevergabe, welche die gewünschten Einschränkungen ausreichend granular durchsetzen würde. Hier kann „Security by Design“ dazu dienen, die Komponenten zumindest robuster gegen Angriffe zu gestalten – zum Beispiel durch Beschränkung hoher Privilegien auf geringe Teile der Software (Privilege Separation), restriktives Sandboxing et cetera. Eine sicherheitstechnische Begutachtung der Komponenten durch externe Experten im Rahmen einer Zulassung, Auditierung oder Zertifizierung kann zusätzlich helfen, eventuell sogar die Veröffentlichung als Open-Source.
Ähnliche Maßnahmen der Härtung lassen sich auch für PEP und PDP treffen. Um eine Gefährdung durch Insider beim Betreiber dieser Komponenten zu verringern, kann es hilfreich sein, sie unter die Verantwortung des Fachdienstes zu stellen. Der mögliche Einblick des PEP in die Kommunikation zwischen Nutzer und Fachdienst wird so weniger ein Risiko, da im Fachdienst diese Kommunikation ohnehin vorliegt und ein Abgriff der Kommunikation im PEP durch den betreibenden Fachdienst daher keinen Informationsgewinn darstellen würde. Gleiches gilt für die Gefahr des Trackings durch PEP und PDP, da die dafür nötigen Informationen dem Fachdienst ebenfalls vorliegen.
Um eine Korrelation der in IDP, Gerätemanagement und PEP/PDP anfallenden Informationen für ein detailliertes Tracking zu verhindern, kann es hilfreich sein, dafür getrennte Betreiber einzusetzen. Das kann eine Trennung über verschiedene Organisationen sein oder auch eine Trennung innerhalb der gleichen Organisation, die allerdings mit deutlich mehr Interessenskonflikten einhergeht. Um ein Tracking im Monitoring zu verhindern, sollte dieses nur stark reduzierte oder aggregierte Informationen von den Komponenten bekommen. Um das zu erreichen, könnten zum Beispiel nutzerspezifische Verhaltensanalysen bereits lokal in PEP, IDP oder Gerätemanagement erfolgen.
Das Missbrauchsrisiko lässt sich auch durch eine dezentrale Datenspeicherung vermindern: So können ein spezifisches Gerät betreffende Informationen (z. B. frühere Quell-IP-Adressen oder Orte) eventuell auf dem Gerät selbst – gegen Modifikationen geschützt – gespeichert werden und damit für eine Komponente wie PEP oder Gerätemanagement ausschließlich beim Zugriff dieses spezifischen Geräts verfügbar sein. Sensitive Daten könnten auch einer unabhängigen vertrauenswürdigen Instanz übergeben oder gar über mehrere Instanzen verteilt und von dort nur selektiv abgefragt (und ggf. kombiniert) werden, um so Leaks sensitiver Daten zu verhindern.
Fazit und Ausblick
Tiefere Privacy-Betrachtungen sind bisher typischerweise nicht Bestandteil von Zero-Trust-Produkten, da diese den Fokus in der Regel auf einzelne Unternehmen legen. Es ist jedoch erkennbar, dass die Bedeutung des Zero- Trust-Paradigmas sowie von Verhaltensanalysen zur
Gefahrenabwehr auch in komplexeren Umgebungen steigt – zum Beispiel bei der Anbindung von Dienstleistern, in kooperierenden Verwaltungen oder beim Zugriff von Versicherten und Leistungserbringern auf Fachdienste im Gesundheitssystem. Damit einhergehend wird auch die Rolle der Privacy in Zero-Trust-Umgebungen bedeutsamer.
Steffen Ullrich ist Technology Fellow bei der genua GmbH.