Privacyzentriertes Zero Trust : Teil 1: Zero Trust in föderierten Umgebungen

Föderierte Umgebungen

Mit der zunehmenden Vernetzung eines Systems verteilter Verantwortlichkeiten erhöht sich die Schwierigkeit, für die Erfüllung gemeinsamer Aufgaben ein effektives, effizientes, aber gleichzeitig sicheres Zusammenspiel zu ermöglichen. Jede Organisation trifft im Allgemeinen eigenständige Entscheidungen hinsichtlich Sicherheitsmaßnahmen und dem Einsatz von Technologie und Produkten. Die daraus resultierende Vielfalt erschwert das funktionale Zusammenspiel – sie kann auch negative Auswirkungen auf die Sicherheit der beteiligten Organisationen haben. Im Folgenden wird betrachtet, was derartige föderierte Umgebungen charakterisiert und welche Herausforderungen sich daraus ergeben.

• In föderierten Umgebungen tragen mehrere Organisationen und Akteure essenzielle Teilaspekte zu einer gemeinsamen Erfüllung von Aufgaben bei: Zum Beispiel kann eine Behörde einen Fachdienst anbieten, die zugreifende Behörde wiederum stellt aber für die Authentifizierung am Fachdienst ihren eigenen Identitätsprovider (IDP) wie Active Directory oder benutzt Zertifikate, die von der eigenen Public-Key-Infrastruktur (PKI) ausgestellt sind. In dem vorgeschlagenen Feinkonzept für eine Zero-Trust-Telematikinstruktur im Gesundheitswesen [6] stellen die Krankenkassen die Identitätsprovider für die Versicherten: Versicherte als eigenständige Akteure authentisieren sich mittels dieser IDP an Fachdiensten wie der elektronischen Patientenakte (ePA), die wiederum von anderen Organisationen betrieben werden – die gematik verwaltet jedoch die Sicherheitsregeln, welche für den Zugriff auf die Fachdienste gelten.
• Organisationen und Akteure sind unabhängig voneinander: Das bedeutet nicht zuletzt, dass Entscheidungen bezüglich Sicherheitsmaßnahmen oder genutzter Technologie in der Verantwortung der jeweiligen Organisation beziehungsweise Akteure liegen. Beim Feinkonzept für die Telematikinfrastruktur ist es zum Beispiel so, dass Fachdienste oder Identitätsprovider die Zugangsgeräte der Versicherten oder Leistungserbringer weder managen noch Änderungen durchführen können, sondern maximal eine eingeschränkte Sicht auf deren Sicherheit haben. Ebenso können Versicherte keinen Einfluss auf die Sicherheit von IDP oder Fachdienst nehmen.
• Es sind Vertrauensbeziehungen nötig, auch bei fehlender aktiver Kontrolle über die von anderen Organisationen betriebenen Teile der Umgebung: So müssen beispielsweise die Betreiber von Fachdiensten darauf vertrauen können, dass der Identitätsprovider nur im Interesse der wirklichen Nutzer agiert und nicht versucht, sich unerlaubt als Nutzer auszugeben (Impersonation).
• Entsprechend Zero-Trust-Paradigmen kann es kein blindes Vertrauen geben: Die Vertraulichkeit und Integrität der eigenen Dienste und Daten sollte nicht durch Probleme bei anderen Organisationen und Betreibern gefährdet sein. Das wird jedoch durch einen gegebenenfalls unterschiedlichen Reifegrad und abweichende Prioritäten der beteiligten Organisationen beim Verständnis und der Umsetzung von Cybersicherheit erschwert. Wie stark Akteure sich einander vertrauen können, hängt davon ab, wie sehr sich die Vertrauensgrundlage technisch oder prozessual sicherstellen lässt.
• Es existiert eventuell eine hohe Heterogenität der eingesetzten Verfahren und Lösungen: Entscheidungen für genutzte Technologie sowie Lösungen liegen bei den beteiligten Organisationen. Das kann aufgrund einer hohen Heterogenität zu Interoperabilitätsproblemen führen, welche die übergreifende Zusammenarbeit funktional beeinträchtigen. Heterogenität erfordert eventuell auch, die Güte und Granularität von Zugriffskontrollen auf ein von allen Beteiligten realisierbares Minimum zu reduzieren.

Abgrenzung zu klassischen Enterprise-Umgebungen

Einige genannte Aspekte sind ebenso in klassischen, nicht als föderiert bezeichneten Infrastrukturen anzutreffen: Auch hier werden oft externe Identitätsprovider wie Okta, Microsoft Entra oder externe Infrastruktur- und Sicherheitsanbieter wie Cloudflare oder ZScaler eingesetzt. Allerdings entscheidet man sich dabei explizit für die Nutzung dieser Lösungen und kann die eigene Infrastruktur entsprechend anpassen. Zudem gibt es kein gemeinsames Ziel, sondern die Anbieter werden nur zur Erfüllung der eigenen Ziele eingesetzt.

Da derartige Dienstleister kritische Elemente der eigenen Infrastruktur betreiben, stellt sich die Frage, wie man ausreichendes Vertrauen in sie sicherstellen und solide überprüfen kann. Zu oft scheint es keine andere Wahl zu geben, als mangels Alternativen resigniert die Risiken zu akzeptieren, ähnlich wie bei der Nutzung komplexer Fremdsoftware in eigenen Infrastrukturen. Einige der hier beschriebenen Lösungsansätze können daher auch für klassische Enterprise-Umgebungen hilfreich sein.

Föderierte Problemstellungen

Die folgenden Abschnitte beschreiben wichtige Punkte spezifisch für föderierte Umgebungen und skizzieren potenzielle Lösungsansätze. Dabei wird allerdings deutlich, dass es für viele Probleme aktuell keine zufriedenstellende Lösung gibt: Man muss vielmehr mit Kompromissen leben. Diese Betrachtungen erheben indes keinen Anspruch auf Vollständigkeit.

Identity- and Access-Management anderer Organisationen

Sollen Zugriffe auf einen Fachdienst identititätsbasiert kontrolliert werden, ist eine zuverlässige Überprüfung der Identität und der damit zusammenhängenden Rechte beziehungsweise Rollen notwendig. Liegt das Identity- and Access-Management (IAM) für den Nutzer in der Verantwortung einer anderen Organisation und damit außerhalb des eigenen Managements, lassen sich keine fundierten Annahmen über dessen Sicherheit treffen.

Probleme können von der Kompromittierung einzelner Nutzer durch schwache Zugangsdaten, über Informationsleaks von einzelnen Zugriffstoken bis hin zur breiten Kompromittierung essenzieller Teile des IAM durch Kompromittierung des für die Erstellung von Zugangstoken benutzten kryptografischen Materials reichen. Als Ergebnis können sich Angreifer als einzelne Personen oder sogar ganze Organisationen ausgeben und mit den damit einhergehenden Rechten Daten abgreifen oder Infrastrukturen lateral kompromittieren. Jüngste Ereignisse wie die Kompromittierung von Okta [7] oder die Sicherheitslücken und Kompromittierung bei Microsoft [8,9] zeigen, dass derartige Befürchtungen realistisch sind: Ein zu großes Vertrauen in das externe IAM kann kritische Auswirkungen auf die eigene Sicherheit haben.

Ein potenzieller Lösungsansatz ist, das für die Sicherheit notwendige Vertrauen in das fremde IAM zu verringern, indem man zusätzliche unabhängige Faktoren einbezieht. Ein solcher Faktor muss dabei nicht notwendig sicherer als das fremde IAM sein: Die Gesamtsicherheit wird bereits dadurch erhöht, dass ein Angreifer mehrere unabhängige Faktoren gleichzeitig kompromittieren muss. Solche Faktoren können vorhandene Identitäten wie Personalausweis, Gesundheitskarte, digitale Gesundheits-ID oder künftig das EUDI-Wallet für die europäische digitale Identität sein. Selbst Identitäten bei sozialen Netzwerken wären denkbar, sofern diese klar mit der Identität assoziiert sind. Weiterhin lassen sich mit dem Nutzer assoziierte Kontaktwege wie E-Mail oder Telefonnummer zur Versendung von Sicherheitstoken zur Prüfung heranziehen.

Um solche gegebenenfalls aufwendigen Identitätsprüfungen auf ein Minimum zu beschränken, können diese mit einer Geräteregistrierung verbunden sein: Das heißt, eine Validierung ist nur bei der Nutzung eines neuen Geräts (Smartphone, Computer, Hardware-Token etc.) nötig. Dieser Weg wird im Feinkonzept für die Telematikinfrastruktur im Gesundheitswesen propagiert: Um eine missbräuchliche Personifizierung des Nutzers durch einen unsicheren Identitätsprovider zu verhindern, kommt eine Geräteregistrierung als zusätzlicher Faktor zum Einsatz.

Ein weiterer Lösungsweg ist, das Vertrauen in das fremde IAM zu erhöhen, indem Zulassungen, Zertifizierungen, Audits et cetera erfolgen (bzw. gefordert werden), welche die Sicherheit des IAM von unabhängiger Stelle nach anerkannten Kriterien prüfen und bestätigen. Neben der Überprüfung von eingesetzter Technologie und Prozessen kann in bestimmten Anwendungsfällen die wirtschaftliche und politische Stellung des IAMBetreibers mit einbezogen werden, um eine Kompromittierung auf Leitungsebene durch Interessenskonflikte auszuschließen.

Blindes Vertrauen in ein externes IAM findet sich in ähnlicher Form auch in nicht-föderierten Umgebungen bei der Nutzung von IAM-Dienstleistern wie Okta oder Microsoft Entra. Zusätzliche unabhängige Faktoren oder externe Audits lassen sich auch hier erfolgreich einbeziehen.

Datenverarbeitung durch Fachdienste anderer Organisationen

In föderierten Umgebungen werden Daten der einen Organisationen oft in Fachdiensten einer anderen Organisation gespeichert und verarbeitet. Der Dateneigentümer hat dabei keine Kontrolle über die Sicherheit der Speicherung und Verarbeitung. Ähnliche Situationen bestehen in nicht-föderierten Umgebungen, wenn die Datenverarbeitung durch Dienstleister abgewickelt wird, wie bei der Nutzung von Software as a Service (SaaS) in der Cloud. Dass es in solchen Situationen zu Sicherheitsproblemen kommt, ist leider nicht selten. Beispiele sind ein Datenleck bei Majorel [10,11], bei dem Kundendaten mehrerer Banken betroffen waren, oder die umfangreiche Kompromittierung von Südwestfalen IT als Dienstleister für Kommunen [12].

Derartige Probleme bei der Datenverarbeitung können viele Ursachen haben: Oft sind Datenleaks die Folge von Nachlässigkeit beziehungsweise mangelnder Cyber-Hygiene durch Lagerung von Daten auf offenen oder mit schwachem Zugriffsschutz versehenen Servern – so etwa 2019 bei einem Leak von Millionen von Patientendaten [13]. Daten sind ein attraktives Ziel für Angreifer: zum einen, um mittels Ransomware Geld von Dienstanbietern zu erpressen, zum anderen aber auch, um personenbezogene Daten für Identitätsdiebstahl zu benutzen oder vertrauliche Firmendaten für Industriespionage zu stehlen. Entsprechend werden Organisationen gezielt angegriffen, oftmals über bisher noch unbekannte Sicherheitslücken (Zero Days) wie bei den diversen Lücken in der MOVEit-Software [11].

Lösungsansätze sind schwierig. Der beste Weg wäre, dem Dienstleister Daten nur in verschlüsselter Form zugänglich zu machen und den Schlüssel zu behalten. Eine clientseitige Verschlüsselung eignet sich jedoch nur für die reine Datenspeicherung wie Backups und nicht, wenn der Dienstleister mit den Daten tatsächlich arbeiten soll. Hier können zumindest Datensparsamkeit, Pseudonymisierung und Anonymisierung sowie die zeitliche Begrenzung der Datenhaltung durch die andere Organisation den Schaden bei einer Kompromittierung begrenzen.

Schließlich helfen unabhängige Audits, das Sicherheitsniveau einer Fremdorganisation besser einzuschätzen und den Datenaustausch nur bei einer entsprechend hochwertigen Vertrauensbasis durchzuführen. So definiert die gematik im Gesundheitswesen hohe Anforderungen an die Betreiber von Fachdiensten sowohl aus technischer als auch organisatorischer Sicht – nur von der gematik zugelassene Produkte werden an die Telematikinfrastruktur angebunden.

Fremdgemanagte Zugriffskontrollen und -regeln

In föderierten Umgebungen werden Zugriffskontrollen auf die eigenen Daten und Dienste eventuell zum Teil von einer Fremdorganisation gemanagt. Das kann auf Ebene der Zugriffsregeln passieren, das heißt der Spezifikation, wie die Kontrolle zu erfolgen hat. Es kann sich aber auch um eine technische Umsetzung handeln: Zum Beispiel kann eine Organisation als Sicherheitsdienstleister die technische Infrastruktur zur Durchsetzung der Kontrollen bereitstellen. Ähnliche Situationen entstehen in nicht-föderalen Umgebungen, wenn zum Beispiel Secure-Access-Service-Edge-(SASE)-Anbieter die Zugriffskontrollpunkte als SaaS in der Cloud anbieten und sich im Rahmen von Security as a Service um Details der Zugriffsregeln kümmern.

In solchen Situationen kann eine Fremdorganisation durch Fehler oder Vorsatz gegebenenfalls unerwünschte Zugriffe auf nicht-öffentliche Infrastruktur und Dienste ermöglichen. Zusätzlich kann die externe Organisation Einblick in verschlüsselte Daten erlangen und Nutzersitzungen übernehmen, wenn – wie häufig der Fall – Zugriffskontrollen auf Applikationsebene stattfinden und dazu TLS/HTTPS-Verbindungen terminieren müssen.

Eine Lösung ist, die Zugriffskontrolle nur partiell aus der Hand zu geben und stattdessen Mindestanforderungen und -beschränkungen in vollständig eigener Kontrolle durchzusetzen. Zum Beispiel kann man den Zugriff auf einen zur Verfügung gestellten Fachdienst, auf bestimmte Daten und auf spezifische andere Organisationen beschränken – Organisationen wird jedoch eine eigenständige granulare Rechtevergabe für ihre einzelnen Mitarbeiter ermöglicht. Oder man lässt eine für Sicherheit zuständige Organisation Regeln für Mindestanforderungen an Nutzer und Geräte definieren und dynamische Regeln basierend auf Threat-Intelligence (TI) aufstellen – diese gelten aber nur ergänzend zu den eigenen Zugriffsregeln, sodass lokale Anforderungen nicht „aufgeweicht“ werden können. Darüber hinaus sollte die technische Durchsetzung der Kontrolle (und damit die Terminierung von TLS-Verbindungen) innerhalb der eigenen kontrollierten Infrastruktur erfolgen.

Im Feinkonzept für die Telematikinfrastruktur erfolgt die Durchsetzung der Zugriffskontrollen – also liegen dort auch Policy-Enforcement-Point (PEP) und Policy-Decision-Point (PDP) – vor einem Fachdienst und in der Infrastruktur sowie unter Kontrolle des Fachdienstes. Dieser kann seine eigenen dienstspezifischen Zugriffsregeln als Mindestanforderung sicher durchsetzen: zum Beispiel, welche Nutzerrollen (Ärzte, Versicherte etc.) Zugriff auf welche Aktivitäten haben. Übergreifende Regeln – wie Anforderungen an die Sicherheit von Nutzer und Gerät sowie aktuelle Threat-Intelligence – werden von der gematik bereitgestellt und vom PEP/PDP beim Fachdienst zusätzlich zu den eigenen anwendungsspezifischen Regeln durchgesetzt.

In einigen Zero-Trust-Application-Access-(ZTAA)- Produkten betreibt ein Dienstleister die (cloudbasierten) Zugangskontrollpunkte als Service. Die gewünschten Dienste werden über eine Konnektor-Software im eigenen Netz für diese Zugangskontrolle erreichbar gemacht. Über die Konfiguration der extern betriebenen Zugangskontrolle legt man fest, welche internen Dienste der Konnektor verfügbar machen soll – das heißt, der interne Konnektor folgt diesen externen Anweisungen. Dies birgt die Gefahr, dass bei einer Kompromittierung des Dienstleisters auch interne Dienste exponiert werden, die eigentlich nicht erreichbar sein sollten. Dem kann man durch eine Einschränkung der Kommunikationsmöglichkeiten des Konnektors beispielsweise über Firewall-Regeln begegnen.

Auch hier verbessern überdies unabhängige Audits die Vertrauensgrundlage: Sie schaffen gegebenenfalls so weit Vertrauen, dass einer Fremdorganisation die technische Durchsetzung der Zugriffskontrolle erlaubt und damit eine sicherheitskritische Funktion aus der Hand gegeben wird.

Sichere Interaktion

Um effektive Zugriffskontrollen zu ermöglichen, müssen Zero-Trust-Lösungen vielfältige Informationen einbeziehen. Dazu gehören zuvorderst zuverlässige Informationen über die Identität des Nutzers (Authentifizierung) sowie gegebenenfalls über seine Rollen und andere Attribute, die als Grundlage für Zugriffsrechte dienen. Für den Informationsaustausch sind herstellerübergreifende offene Standards wie OpenID Connect, OAuth, SAML, LDAP, Radius oder X.509-Zertifikate hilfreich, auch wenn beim Zusammenspiel hersteller- und organisationsspezifische Ausprägungen berücksichtigt werden müssen. Ebenso haben sich übergreifende Stufen wie eIDAS Levels of Assurance (LoA, [14]) für die Prüftiefen etabliert. Wie effektiv und sicher die von fremden Identitätsprovidern durchgeführten Authentifizierungen tatsächlich sind, ist für eine Organisation nicht transparent und damit Vertrauenssache.

Schwieriger ist die Bewertung der Gerätesicherheit (Device-Attestation), welche in Zero-Trust-Architekturen ausreichend Vertrauen in die Sicherheit eines Endgeräts ermöglichen soll. Hier existieren keine herstellerübergreifenden Standards, welche Geräteinformationen einbezogen werden, wie diese in die Bewertung der Gerätesicherheit einfließen sollen, wie eine solche Bewertung aussehen kann und wie sie übermittelt wird. In mobilen Geräten mit iOS und Android sind grundlegende Attestierungen Bestandteil der Plattform – man kann auf die von den US-Plattformanbietern bereitgestellten Dienste aufbauen und muss ihnen dabei vertrauen. Auf Desktopsystemen sowie für tiefere Attestierungen sieht man sich hingegen mit einer Vielzahl an Herstellern von Endpoint-Protection-Plattformen, Mobile-Device-Management- (MDM), Remote-Access- (RA) oder Zero-Trust-(ZT)-Lösungen konfrontiert. Diese bringen jeweils ihre eigenen Vorstellunge von Geräteattestierung mit und haben eine individuelle Auffassung davon, wie sie mit anwendungs- und netzseitigen Zugriffskontrollen interagieren.

Als Ergebnis findet man in heterogenen Umgebungen oft mehrere Zero-Trust-Agenten verschiedener Hersteller installiert, die für den Zugang zu jeweils unterschiedlichen Organisationen nötig sind. Für die Stabilität und Sicherheit des Endgerätes kann dies abträglich sein: Die Lösungen sind oft tief im System verankert, können sich gegenseitig stören und bei leider immer wiederkehrenden Sicherheitslücken Angreifern einen tiefen Zugriff auf Endgeräte ermöglichen. Damit gehen rechtliche Probleme einher: Kann eine Organisation für den Zugriff auf die von ihr angebotenen Dienste überhaupt verlangen, dass eine andere Organisation auf ihren eigenen Systemen Fremdsoftware installiert, die weitgehende Systemrechte hat? Wer trägt die Verantwortung bei Stabilitäts- oder Sicherheitsproblemen?

Die Vielfalt verschiedenartiger Informationen und Bewertungen stört ebenso bei der Zusammenführung von Informationen in Security-Information-and-Event- Management-(SIEM)-Systemen wie bei der Nutzung in Zugriffsregeln – auch bei deren Erstellung und Pflege hat jeder Hersteller seine eigene Spielart. Die Umsetzung einheitlicher Sicherheitspolicies in heterogenen Umgebungen wird dadurch zusätzlich erschwert.

Die Diversität proprietärer und nicht-interoperabler Lösungen erschwert aber nicht nur die Zusammenarbeit: Sie gefährdet auch die Zukunfts- und Planungssicherheit. Anwender befinden sich in einem Lock-in bei bestimmten Herstellern und sind deren aktueller und zukünftiger Plattformunterstützung, Sicherheit, Preisgestaltung, Produktentwicklung und Verfügbarkeit des Produkts ausgeliefert. Im wettbewerbsintensiven Markt der Cybersicherheit können Anwender dann schnell „unter die Räder“ kommen.

Der Gedanke ist naheliegend, organisationsübergreifend auf die gleichen Hersteller zu setzen, um so eine möglichst homogene Architektur zu erhalten. Damit verstärkt sich allerdings das Vendor-Lock-in, mit der beschriebenen Gefahr für Zukunfts- und Planungssicherheit. Der konträre Lösungsansatz ist, sich auf den kleinsten gemeinsamen Nenner aller in den Organisationen eingesetzten Lösungen zu beschränken: Das wiederum bedeutet Einbußen für die Qualität und Granularität der Zugriffskontrolle und wirkt negativ auf Sicherheit und Usability.

Bei entsprechender Marktmacht ist es möglich, das gewünschte Zusammenspiel zu definieren und von Herstellern umsetzen zu lassen. Dieser Ansatz wird zum Beispiel bei der Zero-Trust-Telematikinfrastruktur verfolgt: Eine von der gematik in Kooperation mit der Industrie erarbeitete übergreifende Spezifikation definiert die Interaktion der einzelnen Komponenten. Die Hersteller müssen
diese Spezifikation umsetzen, um sich an der Telematikinfrastruktur zu beteiligen. Gerade der öffentliche Sektor hat eine entsprechende Marktmacht – er könnte so Standards forcieren, von denen auch Enterprise-Umgebungen profitieren. Diese Möglichkeit spiegelt sich gleichsam in der EU-Verordnung für ein interoperables Europa [15] wider.

Verteilte Verantwortlichkeiten

Ein Kernprinzip von Zero Trust ist eine ausreichend granulare Zugriffsentscheidung beim Zugriff auf eine Ressource. Ziel ist, das von kompromittierten Zugängen ausgehende Risiko und den potenziellen Schaden zu minimieren. In einem föderierten Umfeld können nicht nur die gesammelten Informationen über Nutzeridentität oder Gerätesicherheit des aktuellen Zugriffs als Entscheidungsgrundlage dienen. Die beteiligten Akteure können jeweils eigene Zugriffsregeln bezüglich der Rechte von Nutzern und Nutzergruppen, Anforderungen an Gerätesicherheit, Einbeziehung von Threat-Intelligence und mehr einbringen. Zu den beschriebenen Problemen bezüglich der technischen Interoperabilität in einem heterogenen Umfeld kommen weitere Herausforderungen: So ist organisatorisch abzustimmen, welche Teile die jeweiligen Organisationen zu den Zugriffsregeln beitragen und wie diese technisch zusammengeführt und durchgesetzt werden. Da für die Zugriffsentscheidung Nutzer-, Geräte und Verhaltensdaten von Anwendern aus einer fremden Organisation erfasst werden, muss außerdem rechtlich geregelt sein, in welchem Umfang und zu welchem Zweck diese gesammelt, genutzt und gegebenenfalls gespeichert werden dürfen.

Eine Möglichkeit ist, alle Daten und Regeln an der Zugriffskontrolle vor dem Dienst zu aggregieren und durchzusetzen. Damit liegt die finale Entscheidung bei dem Dienst, der die zu schützenden Daten verwaltet: So kann man dienstspezifische Verhaltensdaten aus der Zugriffskontrolle sammeln und den beteiligten Organisationen aggregierte Teile davon für die Kontrolle und Optimierung der von ihnen beigetragenen Teile des Regelwerks zur Verfügung stellen – diese Vorgehensweise findet sich beispielsweise im Feinkonzept für die Zero- Trust-Telematikinfrastruktur wieder. Von Nachteil ist, dass bei dem Dienst eine Vielzahl von gegebenenfalls sensitiven Informationen aus fremden Organisationen anfällt – entsprechend vertrauenswürdig müssen die einzelnen Betreiber sein.

Eine weitere Option ist, einem gemeinsamen Dienstleister den Betrieb der Zero-Trust-Infrastruktur zu überlassen: Durch die zentrale Stellung über alle Organisationen und Dienste hinweg kann dieser dienstübergreifend Verhaltensdaten sammeln und so eine bessere Sichtbarkeit von Bedrohungen erreichen. Die Vertrauensstellung eines solchen Dienstleisters ist jedoch sehr hoch – dementsprechend wichtig ist eine hochwertig verifizierte Vertrauensbasis. Es ist nicht sinnvoll, sich dabei nur auf die Versprechen der Anbieter zu verlassen!

Schließlich besteht noch die Möglichkeit einer verteilten Durchsetzung von Zugriffsregeln. Damit lässt sich zum Beispiel am Fachdienst durchsetzen, dass nur bestimmte Organisationen zugreifen dürfen und die zugreifenden Geräte ein bestimmtes Sicherheitsniveau erfüllen müssen. In der zugreifenden Organisation kann eine granulare Kontrolle vorgenommen werden, welche konkreten Nutzer den Dienst verwenden dürfen. Eine Aggregierung der vielfältigen Geräteeigenschaften zu einem einfacheren Sicherheitsniveau kann in der zugreifenden Organisation oder durch einen unabhängigen Dienst erfolgen, der ausschließlich die Geräteinformationen bekommt. Auf diese Weise werden sensitive Daten weitestgehend lokal genutzt und nur in (weniger sensitiver) aggregierter Form weitergegeben. Durch diese Datensparsamkeit bei der Weitergabe muss der Verarbeitung in den fremden Organisationen weniger vertraut werden. Gleichzeitig erschwert dies jedoch die Verhaltensanalyse und damit die frühzeitige Erkennung anomalen Verhaltens.

Ein solches verteiltes Vorgehen wäre zum Beispiel bei der Zero-Trust- Telematikinfrastruktur denkbar: Hier haben auf der Seite der Leistungserbringer nur die Institutionen selbst eine Identität (SM-B-Institutionszertifikate oder den Praxis- & Institutionsausweis SMC-B) beziehungsweise einzelne Ärzte (Heilberufsausweis HBA), nicht aber die weiteren Angestellten. Dazu gibt es eine Vielzahl von internen und auch gegebenenfalls häufiger wechselnden Geräten, die man nicht ständig in der Telematikinfrastruktur registrieren will. Eine Möglichkeit wäre hier, dass innerhalb der Institutionen eine lokale Zero-Trust-Infrastruktur die Zugriffe auf die Telematikinfrastruktur sowohl beschränkt als auch gegenüber dieser mit aggregierten Geräte- und Nutzerinformationen auftritt. Durch eine Pseudonymisierung von internen Nutzern und Geräten beim Zugriff auf die Telematikinfrastruktur wäre dann sowohl die Vertraulichkeit gegenüber dem Dienst als auch die Rückvollziehbarkeit von Fehlern auf einzelne Geräte und Nutzer möglich.

In der kommenden <kes> befasst sich der zweite Teil dieser Serie zu privacyzentriertem Zero Trust mit datenschutzsensitiven Umgebungen.

Steffen Ullrich ist Technology Fellow bei der genua GmbH.