Mit <kes>+ lesen

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

Klassische Zero-Trust-Umsetzungen in Enterprise-Umgebungen haben eine zentrale Verantwortlichkeit für die Sicherheit der Infrastrukturen – in föderierten Umgebungen ist diese jedoch über mehrere interagierende, aber unabhängige Organisationen verteilt. Ausgehend von den Erfahrungen bei der Konzeption einer Zero-Trust-basierten Telematikinfrastruktur für das Gesundheitswesen werden Herausforderungen, Lösungsmöglichkeiten und verbleibende Probleme in derartigen komplexen Einsatzumgebungen aufgezeigt.

Lesezeit 21 Min.

Von Steffen Ullrich, Jena

Klassische, stark isolierte Netze werden zunehmend von innen und außen aufgeweicht: Von innen geschieht dies durch den Einsatz immer komplexerer Systeme und Anwendungen, zum Beispiel durch Microsoft Exchange. Bedingt durch diese Komplexität, gepaart mit Sicherheitslücken in der Software und bei der Konfiguration sowie zunehmendem Fachkräftemangel, ist ein zunehmender Verlust an Beherrschbarkeit über die eigenen Infrastrukturen zu beobachten. Dazu kommt von außen der verstärkte Einsatz gehosteter Anwendungen (als Software as a Service, SaaS) in der Cloud – etwa Microsoft 365 oder Google Workspace –, aber auch eine disruptiv starke Zunahme mobilen Arbeitens getrieben durch die Anforderungen in der Corona-Pandemie.

Als Folge finden immer mehr Datenzugriffe und Datenverarbeitung außerhalb der physischen Grenzen von Organisationen statt, was entsprechende Implikationen für die Kontrolle über die Daten und deren Sicherheit hat. Klassische Schutzmaßnahmen am Netzperimeter sind für die Bewältigung dieser Probleme nicht mehr ausreichend. Zero-Trust-Lösungen mit granularer und verteilter Zugriffskontrolle – passend zu Schutzbedarf und Mobilität von Daten und Nutzern – versprechen eine deutliche Verbesserung.

Die zunehmende Digitalisierung von Geschäftsprozessen resultiert gleichzeitig in einem steigenden Bedürfnis, Organisationen wie Lieferanten, Kunden oder Dienstleister eng anzubinden. Dabei findet zunehmend eine tiefere Integration statt: Dienstleister benötigen Zugriff auf Systeme und Anlagen, die in internen Netzen stehen, und dies zunehmend „von remote“ – oder Behörden geben anderen Behörden Zugriff auf eigene Fachdienste, jedoch unter Nutzung von Identitäten der zugreifenden Behörde. Eine besondere Vielfalt an unabhängigen Akteuren gibt es im Gesundheitssektor: Organisationen wie Krankenkassen und Ärztekammern verwalten die Identitäten für ihre Mitglieder, Hersteller stellen Fachdienste wie die elektronische Patientenakte bereit und Leistungserbringer sowie Versicherte greifen darauf zu.

Das Vertrauen in fremde Organisationen und Akteure ist naturgemäß beschränkter als gegenüber eigenen Mitarbeitern*. Schließlich besteht keine Verantwortlichkeit für die fremde Infrastruktur und es existiert zunächst keine Möglichkeit, deren Sicherheit mitzugestalten. Hier bieten sich Zero-Trust-Konzepte an [1,2,3,4,5]. Sie ermöglichen einen granularen Zugang, der selbst bei einem kompromittierten Zugriff nur handhabbar begrenzte Schäden verursacht.

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.
Abbildung 1: Zusammenspiel von Organisation in einem föderierten Umfeld: Organisationen A und B greifen auf den von Organisation FD bereitgestellten Fachdienst zu. In die Zugriffsentscheidung werden Regeln des Fachdienstes, Informationen aus dem Identity- and Access-Management (IAM) von A und B, von den dortigen Endpoint-Protection-Plattformen (EPP) bereitgestellte Geräteinformationen (Device-Management, DM) sowie von einem Security-Provider (Org. P) gelieferte Threat-Intelligence-Daten einbezogen.

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.

Abbildung 2: Vereinfachte Darstellung des konzeptionellen Aufbaus einer Zero-Trust-Architektur für die Telematikinfrastruktur 2.0 [6]. Die Durchsetzung der Zugriffskontrollen, also Policy-Enforcement Point (PEP) und Policy-Decision-Point (PDP), erfolgt vor einem Fachdienst und in der Infrastruktur sowie unter Kontrolle des Fachdienstes – dieser kann seine eigenen dienstspezifischen Zugriffsregeln als Mindestanforderung sicher durchsetzen. Übergreifende Regeln wie Anforderungen an die Sicherheit von Nutzer und Gerät sowie aktuelle Threat-Intelligence werden von der gematik bereitgestellt.

Security in föderierten Umgebungen

Die Umsetzung von Zero-Trust-Konzepten in föderierten Umgebungen ist komplex: Die Verteilung der Verantwortlichkeiten bei der Umsetzung von Zugriffskontrollen über mehrere Organisationen hinweg führt zu empfindlichen Reibungen beim Zusammenspiel, die sowohl technisch als auch organisatorisch begründet sind. Da in wichtigen Aspekten einer Zero-Trust-Architektur keine offenen Standards für die Zusammenarbeit zwischen verschiedenen Systemen existieren, benötigen erfolgversprechende Ansätze entweder eine organisationsübergreifende Harmonisierung der eingesetzten Verfahren oder müssen sich bei der Effektivität der Zugriffskontrollen auf den kleinsten gemeinsamen Nenner der eingesetzten Lösungen beschränken. Darüber hinaus tragen alle beteiligten Organisationen zur Gesamtsicherheit des Zusammenspiels bei, auch wenn sich bestimmte Schwächen einzelner Partner durch passende Architekturen selektiv kompensieren lassen.

Checkliste

Die Beachtung der folgenden Prinzipien hilft dabei, Sicherheitsanforderungen in föderierten Umgebungen effizient verwirklichen zu können:

  • Vermeidung von technischer Vielfalt: weitgehende Nutzung standardisierter Protokolle sowie übergreifende Nutzung der gleichen Zero-Trust-Lösungen
  • Vermeidung organisatorischer Vielfalt: übergreifende Einigung auf gemeinsame Sicherheitsanforderungen
  • verifiziertes Vertrauen: nachgewiesen hohe Sicherheitsniveaus der beteiligten Organisationen
  • lokale Sicherheitsmaßnahmen bei beschränktem Vertrauen: zusätzliche Authentifizierungen, unabhängig von fremdem IAM (z. B. Geräteregistrierung) sowie lokale Durchsetzung eigener Mindestanforderungen für Zugriffe

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.

Literatur

Literatur

[1] Bundesamt für Sicherheit in der Informationstechnik (BSI), Positionspapier Zero Trust 2023, Version 1.12, Juni 2023, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeLeitlinien/Zero-Trust/Zero-Trust_04072023.pdf__blob=publicationFile&v=4

[2] Evren Eren, Der Weg zum Zero-Trust-Networking (1), <kes> 2020#6, S. 52

[3] Evren Eren, Der Weg zum Zero-Trust-Networking (2), <kes> 2021#1, S. 50

[4] Stefan Strobel, Vertrauen ist gut, kein Vertrauen ist besser?!, Entwicklung und Implementierungen von „Zero Trust“, <kes> 2022#1, S. 14

[5] Kai Martius, Zero Trust: Allheilmittel oder fauler Zauber?, <kes> 2022#5, S. 48

[6] gematik, Zero Trust Architektur für die Telematikinfrastruktur, Feinkonzept, Version 1.0, März 2023, https://fachportal.gematik.de/fileadmin/Fachportal/Downloadcenter/gemKPT_Zero_Trust_V1.0.0.pdf

[7] Martin Holland, Nicht nur 134 Betroffene: Daten aller Okta-Kunden in Support-Datenbank erbeutet, heise online, November 2023, https://heise.de/-9542820

[8] Jürgen Schmidt, Microsofts gestohlener Schlüssel mächtiger als vermutet, heise online, Juli 2023, https://heise.de/-9224640

[9] Daniel AJ Sokolov, Nach Microsoft-Fiasko müssen US-Behörden groß aufräumen, heise online, April 2024, https://heise.de/-9682556

[10] Marie-Claire Koch, ING, Deutsche Bank und Co. wegen MOVEit-Lücke bei Majorel doch stärker betroffen, heise online, September 2023, https://heise.de/-9320188

[11] Imke Stock, Missing Link: Die MOVEit-Sicherheitslücke – eine Zwischenbilanz, heise online, Oktober 2023, https://heise.de/-9318038

[12] Dr. Christopher Kunz, Erpressung in Südwestfalen: Akira kam mit geratenem Passwort ins kommunale Netz, heise online, Januar 2024, https://heise.de/-9610102

[13] Dennis Schirrmacher, Unsicher konfigurierte Server leaken Daten von Millionen Patienten, heise online, September 2019, https://heise.de/-4531255

[14] European Commission, eIDAS Levels of Assurance (LoA), eID Documentation, https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eIDAS+Levels+of+Assurance

[15] Europäische Union, Verordnung (EU) 2024/903 des Europäischen Parlaments und des Rates vom 13. März 2024 über Maßnahmen für ein hohes Maß an Interoperabilität des öffentlichen Sektors in der Union (Verordnung für ein interoperables Europa), in: Amtsblatt der Europäischen Union Serie L, März 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32024R0903

Diesen Beitrag teilen: