Kapitel 4. Entscheidungen über Genehmigungen treffen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Die Autorisierung ist wohl der wichtigste Prozess in einem Zero-Trust-Netzwerk, und deshalb sollte eine Entscheidung über die Autorisierung nicht auf die leichte Schulter genommen werden. Für jeden Datenfluss und/oder jede Anfrage muss letztendlich eine Entscheidung getroffen werden.

Die Datenbanken und unterstützenden Systeme, die wir hier besprechen, sind die wichtigsten Systeme, die zusammenkommen, um diese Entscheidungen zu treffen und zu beeinflussen. Gemeinsam sind sie für die Zugriffskontrolle maßgeblich und müssen daher strikt voneinander getrennt werden. Diese Zuständigkeiten sollten sorgfältig voneinander abgegrenzt werden, insbesondere bei der Entscheidung, ob sie in einem einzigen System zusammengefasst werden sollen, was nach Möglichkeit vermieden werden sollte.

Unter Berücksichtigung der Realität konzentriert sich dieses Kapitel auf die architektonische Anordnung der Komponenten, die für Zero-Trust-Autorisierungsentscheidungen erforderlich sind, sowie darauf, wie sie zusammenpassen und diese Entscheidungen durchsetzen.

Architektur der Autorisierung

Die Zero-Trust-Autorisierungsarchitektur umfasst vier Hauptkomponenten, wie in Abbildung 4-1 dargestellt:

  • Durchsetzung

  • Politikmotor

  • Vertrauensmotor

  • Datenspeicher

Diese vier Komponenten unterscheiden sich in ihren Zuständigkeiten und werden daher als separate Systeme behandelt. Aus Sicherheitssicht ist es sehr wünschenswert, dass diese Komponenten voneinander isoliert sind. Diese Systeme sind in der Praxis die Kronjuwelen des Zero-Trust-Sicherheitsmodells und sollten daher besonders sorgfältig gewartet und gesichert werden. Aus Sicht der Implementierung ist es entscheidend, dass diese Komponenten voneinander isoliert sind, damit ein Verstoß gegen eine Komponente nicht automatisch zu einem Verstoß gegen das gesamte System führt, sowohl aus Sicht der Sicherheit als auch der Verfügbarkeit. Dies wird in der Regel durch Cloud-basierte Systeme erreicht, bei denen SaaS-basierte Dienste eine Isolierung auf der Grundlage verschiedener Faktoren ermöglichen, während die Dienste unter dem Dach eines einzigen Anbieters verfügbar bleiben. Ein weiteres gängiges Muster ist die Verwendung von Microservices, bei denen verschiedene Dienste auf verschiedene Anbieter verteilt und über klar definierte APIs zugänglich sind. Da Softwaresysteme heutzutage in der Regel stark verteilt sind, sollte die Planung der Isolierung frühzeitig in den Vordergrund gestellt werden.

Abbildung 4-1. Zero-Trust-Autorisierungssystem

Die Durchsetzung ist die Komponente, die das Ergebnis der Autorisierungsentscheidung tatsächlich beeinflusst. In der Regel handelt es sich dabei um einen Load Balancer, einen Proxy oder sogar eine Firewall. Diese Komponente interagiert mit der Policy Engine, mit der wir die eigentliche Entscheidung treffen. Die Durchsetzungskomponente stellt sicher, dass die Kunden authentifiziert sind, und gibt den Kontext jedes Datenflusses/jeder Anfrage an die Policy Engine weiter. Die Policy Engine vergleicht die Anfrage und ihren Kontext mit den Richtlinien und teilt dem Enforcer mit, ob die Anfrage zugelassen wird oder nicht. Die Durchsetzungskomponenten sollten in großer Zahl im gesamten System vorhanden sein und so nah wie möglich an der Arbeitslast liegen.

Eine Trust Engine nutzt mehrere Datenquellen, um einen Risikoscore zu berechnen, ähnlich wie bei einer Kreditwürdigkeitsprüfung. Dieser Score kann zum Schutz vor unbekannten Unbekannten verwendet werden und trägt dazu bei, die Richtlinien stark und robust zu halten, ohne sie durch Kanten und Signaturen zu verkomplizieren. Er wird von der Policy Engine als zusätzliche Komponente verwendet, mit der Autorisierungsentscheidungen getroffen werden können. BeyondCorp von Google ist weithin als Pionier dieser Technologie bekannt. Die Trust Engine wird von der Policy Engine für die Risikoanalyse genutzt.

Schließlich stellen die verschiedenen Datenspeicher die Quelle der Wahrheit für die Daten dar, die für die Autorisierung verwendet werden. Diese Daten werden verwendet, um ein vollständiges kontextbezogenes Bild eines bestimmten Datenflusses/einer bestimmten Anfrage zu erstellen, wobei kleine authentifizierte Daten als primäre Suchschlüssel verwendet werden (z. B. ein Benutzername oder die Seriennummer eines Geräts). Diese Datenspeicher, egal ob es sich um Benutzerdaten, Gerätedaten oder andere Daten handelt, werden von der Policy Engine und der Trust Engine intensiv genutzt und bilden die Grundlage für alle Entscheidungen.

Durchsetzung

Die Vollzugskomponente (siehe Abbildung 4-2) ist ein natürlicher Ansatzpunkt. Sie steht an der "Frontlinie" des Genehmigungsflusses und ist dafür verantwortlich, dass die Entscheidungen, die der Rest des Genehmigungssystems trifft, umgesetzt werden.

Abbildung 4-2. Ein Agent erhält ein Vorautorisierungssignal, um den Zugang zu einem System mit traditionellen Durchsetzungsmechanismen zu gewähren. Diese Systeme bilden zusammen die Durchsetzungskomponente.

Die Durchsetzung kann in zwei Hauptaufgaben aufgeteilt werden. Erstens muss eine Interaktion mit der Policy Engine stattfinden. Dabei handelt es sich in der Regel um die Genehmigungsanfrage selbst (z. B. hat ein Load Balancer eine Anfrage erhalten und muss wissen, ob sie genehmigt ist oder nicht). Die zweite ist die eigentliche Installation und die laufende Durchsetzung der Entscheidung. Obwohl diese beiden Aufgaben eine einzige Komponente in der Zero-Trust-Autorisierungsarchitektur darstellen, kannst du wählen, ob sie zusammen oder getrennt erfüllt werden sollen.

Die Art und Weise, wie du dies handhabst, hängt wahrscheinlich von deinem Anwendungsfall ab. Ein identitätsbewusster Proxy kann zum Beispiel die Policy Engine aufrufen, um eine eingegangene Anfrage aktiv zu autorisieren, und im selben Schritt die Antwort verwenden, um die Anfrage entweder zu bedienen oder abzulehnen. Dies ist ein Beispiel dafür, dass die Anliegen als Einheit behandelt werden. Eine andere Möglichkeit wäre, dass ein Daemon vor der Autorisierung eine Anfrage für den Zugang zu einem bestimmten Dienst erhält, die dann die Policy Engine zur Autorisierung aufruft. Nach erfolgreicher Autorisierung kann der Daemon die lokalen Firewall-Regeln manipulieren, um die Anfrage zuzulassen. Bei diesem Ansatz verlassen wir uns auf "standardmäßige" Durchsetzungsmechanismen, die von der Zero-Trust-Kontrollebene informiert/programmiert werden. Es ist jedoch zu beachten, dass dieser Ansatz einen clientseitigen Hook erfordert, um die Kontrollebene über die Autorisierungsanfrage zu informieren. Je nachdem, wie viel Kontrolle du über deine Geräte und Anwendungen brauchst, kann das akzeptabel sein oder nicht.

Die Platzierung der Durchsetzungskomponente ist sehr wichtig. Da sie unseren Kontrollpunkt innerhalb der Datenebene darstellt, müssen wir sicherstellen, dass die Durchsetzungskomponenten so nah wie möglich an den Endpunkten platziert werden. Andernfalls kann sich das Vertrauen "hinter" der Durchsetzungskomponente stauen, was die Zero-Trust-Sicherheit untergräbt. Glücklicherweise kann die Durchsetzungskomponente als eine Art Client modelliert und im gesamten System großzügig eingesetzt werden. Dies steht im Gegensatz zu den übrigen Autorisierungskomponenten, die als Dienste modelliert werden.

Policy Engine

Die Policy Engine ist die Komponente, die die Macht hat, eine Entscheidung zu treffen. Sie vergleicht die von der Durchsetzungskomponente kommende Anfrage mit den Richtlinien, um festzustellen, ob die Anfrage zulässig ist oder nicht. Sobald dies festgestellt wurde, wird das Ergebnis an die Durchsetzungskomponente zur tatsächlichen Umsetzung zurückgegeben.

Die Anordnung der Durchsetzungsschicht und der Policy Engine ermöglicht dynamische, zeitpunktbezogene Entscheidungen, so dass ein Widerruf schnell erfolgen kann. Daher ist es wichtig, dass diese Komponenten separat und unabhängig voneinander betrachtet werden. Das heißt aber nicht, dass sie nicht auch zusammen eingesetzt werden können.

Abhängig von einer Reihe von Faktoren kann eine Policy Engine neben dem Durchsetzungsmechanismus gehostet werden. Ein Beispiel hierfür wäre ein Load Balancer, der Anfragen über Interprozesskommunikation (IPC) statt über einen Remote-Aufruf genehmigt. Der attraktivste Vorteil dieser Architektur ist die geringere Latenzzeit für die Autorisierung der Anfrage. Ein Autorisierungssystem mit geringer Latenz ermöglicht eine feinkörnige und umfassende Autorisierung von Netzwerkaktivitäten. So können z. B. einzelne HTTP-Anfragen autorisiert werden, anstatt der üblicherweise eingesetzten Autorisierung auf Sitzungsebene. Es sollte beachtet werden, dass es am besten ist, die Prozessebene zwischen der Policy Engine und der Durchsetzungsschicht zu isolieren. Da sich die Durchsetzungsschicht im Datenpfad des Benutzers befindet, ist sie stärker gefährdet; daher könnte die Integration der Policy Engine in denselben Prozess sie einem unerwünschten Risiko aussetzen. Wenn du die Policy Engine als eigenen Prozess einrichtest, kannst du sicherstellen, dass Fehler in der Durchsetzungsschicht nicht zu einer Gefährdung der Policy Engine führen.

Speicherung von Richtlinien

Die Regeln, die von der Policy Engine referenziert werden, müssen gespeichert werden. Diese Regeln werden letztendlich in die Policy Engine geladen, aber es wird dringend empfohlen, die Regeln außerhalb der Policy Engine selbst zu erfassen. Die Speicherung der Richtlinienregeln in einer Versionskontrolle ist ideal und bietet mehrere Vorteile:

  • Änderungen der Richtlinien können im Laufe der Zeit verfolgt werden.

  • Die Gründe für die Änderung von Richtlinien werden in der Versionskontrolle festgehalten.

  • Der erwartete aktuelle Stand der Politik kann mit den tatsächlichen Durchsetzungsmechanismen abgeglichen werden.

Viele dieser Vorteile wurden in der Vergangenheit durch strenge Änderungsmanagementverfahren umgesetzt. In diesem System werden Änderungen an der Systemkonfiguration beantragt und genehmigt, bevor sie schließlich umgesetzt werden. Das daraus resultierende Änderungsmanagementprotokoll kann genutzt werden, um festzustellen, warum sich das System in seinem aktuellen Zustand befindet.

Die Verlagerung der Richtlinien in die Versionskontrolle ist die logische Schlussfolgerung der Änderungsmanagementverfahren, wenn das System programmatisch konfiguriert werden kann. Anstatt sich darauf zu verlassen, dass menschliche Systemadministratoren die gewünschten Richtlinien in das System laden, können wir die Richtlinien als Daten erfassen, die ein Programm lesen und anwenden kann. In vielerlei Hinsicht ähnelt das Laden von Richtlinien dann der Bereitstellung von Software. Daher können Systemadministratoren die Standardverfahren der Softwareentwicklung (nämlich Codeüberprüfung und Beförderungspipelines) nutzen, um die Änderungen der Richtlinien zu verwalten.

Was macht eine gute Politik aus?

Die Richtlinien in einem Zero-Trust-Netzwerk ähneln in mancher Hinsicht der traditionellen Netzwerksicherheit, in anderer Hinsicht unterscheiden sie sich jedoch grundlegend.

Die Zero-Trust-Politik ist noch nicht standardisiert

Die Realität sieht heute so aus, dass die Zero-Trust-Politik noch nicht so standardisiert ist wie eine netzwerkorientierte Politik. Daher ist die Definition der Standardsprache für Richtlinien, die in einem Zero-Trust-Netzwerk verwendet werden, eine große Chance.

Schauen wir uns zuerst an, was ähnlich ist. Eine gute Richtlinie in einem Zero-Trust-Netzwerk ist feinkörnig. Der Grad der Granularität hängt von der Reife des Netzwerks ab, aber das gewünschte Ziel ist eine Richtlinie, die auf die einzelnen zu sichernden Ressourcen zugeschnitten ist. Das unterscheidet sich nicht wesentlich von einem traditionellen Netzwerksicherheitsmodell, das darauf abzielt, das Netzwerk zu segmentieren, um die Angriffsfläche zu verringern.

Das Zero-Trust-Modell unterscheidet sich von der traditionellen Netzwerksicherheit durch die Kontrollmechanismen, die zur Festlegung der Richtlinien verwendet werden. Anstatt die Richtlinien anhand von Details der Netzwerkimplementierung zu definieren (z. B. IP-Adressen und Bereiche), werden die Richtlinien am besten anhand von logischen Komponenten im Netzwerk festgelegt. Diese Komponenten bestehen in der Regel aus:

  • Netzwerkdienste

  • Geräteendpunktklassen

  • Benutzerrollen

Durch die Definition von Richtlinien aus logischen Komponenten, die im Netzwerk vorhanden sind, kann die Policy Engine die Durchsetzungsentscheidungen auf der Grundlage ihres Wissens über den aktuellen Zustand des Netzwerks berechnen. Konkret bedeutet dies, dass ein Webdienst, der heute auf einem Server läuft, morgen vielleicht auf einem anderen Server läuft oder sogar automatisch von einem Zeitplannungsprogramm zwischen den Servern gewechselt wird. Die Richtlinie, die wir definieren, muss von diesen Implementierungsdetails losgelöst sein, um sich an diese Realität anzupassen. Ein Beispiel für diese Art von Richtlinie aus dem Kubernetes-Projekt ist in Abbildung 4-3 dargestellt.

Abbildung 4-3. Ein Ausschnitt aus einer Kubernetes-Netzwerkrichtlinie. Diese Richtlinien verwenden Workload-Labels und berechnen die zugrundeliegenden IP-basierten Durchsetzungsregeln, wenn und wo dies notwendig ist.

Obwohl es keine einheitliche Methode oder einen Standard für die Definition von Richtlinien gibt, werden sie in der Regel im JSON- oder YAML-Format konfiguriert und sind semantisch leicht zu verstehen. Ein Beispiel ist die benutzerdefinierte Cloud-Richtlinie von Google, die Bedingungen für bekannte Geräte definiert, z. B. für unternehmenseigene und vom Administrator genehmigte Geräte mit einem bekannten Betriebssystem:

{
   "name": "example_custom_level",
   "title": "Example custom level",
   "description": "An example custom access level.",
   "custom":  {
     "expr": {
       "expression": "device.is_corp_owned == true || (device.os_type != OsType.OS_UNSPECIFIED && device.is_admin_approved_device == true)",
       "title": "Check for known devices",
       "description": "Permits requests from corp-owned devices and admin-approved devices with a known OS."
     }
   }
 }

Richtlinien in einem Zero-Trust-Netzwerk stützen sich auch auf Trust Scores, um unbekannte Angriffsvektoren zu erkennen. Durch die Definition von Richtlinien mit einer Vertrauenswürdigkeitskomponente können Administratoren Risiken mindern, die sonst nicht mit einer bestimmten Richtlinie erfasst werden können. Daher sollten die meisten Richtlinien eine Trust-Score-Komponente enthalten. Das folgende Beispiel zeigt eine Richtlinie für den bedingten Zugriff in Microsofts Azure-Cloud, die von allen Nutzern mit einem Risikowert von "mittel" oder "hoch" verlangt, dass sie eine obligatorische Multifaktor-Authentifizierung durchführen, wenn sie sich bei einer HR-Anwendung anmelden. Der Trust Score wird später in diesem Kapitel ausführlich behandelt:

{
   "displayName": "Require MFA For High/Medium Sign-in Risk",
   "state": "enabled",
   "conditions": {
       "signInRiskLevels": ["high", "medium"],
       "clientAppTypes": [
           "all"
       ],
        "users": {
           "includeUsers": ["*"]
       }
   },
   "grantControls": {
       "operator": "OR",
       "builtInControls": [
           "mfa"
       ]
   }
}

Fehlende politische Standards

Zum Zeitpunkt der Erstellung dieses Artikels gibt es noch keinen branchenweiten Standard für die Definition von Richtlinien, aber Organisationen wie das National Cybersecurity Center of Excellence (NCCoE) arbeiten daran. Es hat eine öffentlich zugängliche Beschreibung der praktischen Schritte erstellt, die erforderlich sind, um die Cybersecurity-Referenzdesigns für Zero Trust sowie die verschiedenen Komponenten von Zero Trust, einschließlich der Richtlinien, umzusetzen. Mehr dazu erfährst du auf der Website des NCCoE.

Die Richtlinie sollte sich nicht allein auf Vertrauenswerte stützen. Bestimmte Merkmale der zu autorisierenden Anfrage können ebenfalls Teil der Richtliniendefinition sein. Ein Beispiel dafür wäre, dass bestimmte Nutzerrollen nur Zugang zu einem bestimmten Dienst haben sollten.

Wer legt die Politik fest?

Zero-Trust-Netzwerkrichtlinien sollten fein abgestuft sein, was für Systemadministratoren eine außerordentliche Belastung darstellen kann, um die Richtlinien auf dem neuesten Stand zu halten. Um diesen Konfigurationsaufwand zu verteilen, entscheiden sich die meisten Unternehmen dafür, die Richtliniendefinition auf verschiedene Teams zu verteilen, damit diese bei der Pflege der Richtlinien für ihre eigenen Dienste helfen können. Die Öffnung der Richtliniendefinition für das gesamte Unternehmen birgt gewisse Risiken, wie z. B. wohlmeinende Benutzer, die zu weit gefasste Richtlinien erstellen und damit die Angriffsfläche des Systems vergrößern, das sie eigentlich einschränken wollten. Zero-Trust-Systeme stützen sich auf zwei organisatorische Abläufe, um dieser Gefahr entgegenzuwirken.

Politische Bewertungen

Da die Richtlinien in der Regel unter Versionskontrolle gespeichert werden, kann eine weitere Person die Änderungen an den Richtlinien überprüfen und so sicherstellen, dass die Änderungen gut durchdacht sind. Sicherheitsteams können die Änderungen zusätzlich überprüfen und Fragen stellen, um sicherzustellen, dass die definierte Richtlinie so eng wie möglich gefasst ist. Da die Richtlinie mit logischen Absichten und nicht mit physischen Komponenten definiert wird, ändert sie sich weniger schnell, als wenn sie mit physischen Begriffen definiert würde.

Die zweite organisatorische Maßnahme besteht darin, eine breit angelegte Infrastrukturrichtlinie über eine feinkörnige Richtlinie zu legen. Eine Infrastrukturgruppe könnte zum Beispiel verlangen, dass nur eine bestimmte Gruppe von Rollen Datenverkehr aus dem Internet annehmen darf. Das Infrastrukturteam legt daher eine Richtlinie fest, die diese Beschränkung durchsetzt, und keine benutzerdefinierte Richtlinie darf sie umgehen. Die Durchsetzung dieser Beschränkung kann auf verschiedene Weise erfolgen: durch einen automatischen Test der vorgeschlagenen Richtlinien oder durch eine Policy Engine, die zu weit gefasste Richtlinien aus nicht vertrauenswürdigen Quellen einfach ablehnt. Eine solche Durchsetzung kann auch für die Einhaltung von Vorschriften und gesetzlichen Bestimmungen nützlich sein.

Es gibt zwar keinen Standardprozess für die Festlegung von Null-Vertrauensrichtlinien, aber die Kipling-Methode ist ein guter Leitfaden für die Festlegung von Null-Vertrauensrichtlinien. Diese Methode hilft dabei, das Wer, Was, Wann, Wo, Warum und Wie der Richtlinien für den Ressourcenzugriff kurz und bündig zu erklären:

  • Wer sollte auf eine Ressource zugreifen dürfen? Dies ist im Wesentlichen die Identität (die ein Mensch oder eine Maschine sein kann), die den Datenfluss initiieren darf.

  • Welche Anwendung/API/welcher Dienst darf auf die Ressource zugreifen?

  • Wann ist es der Identität erlaubt, auf die Ressource zuzugreifen? Hier geht es vor allem um Zeitrahmen wie Bürozeiten usw.

  • Wo befindet sich die Ressource? Das kann überall sein, auch in der Cloud, in Rechenzentren vor Ort usw.

  • Warum ist der Zugriff der Identität auf die Ressource erlaubt? Dies ist die Hauptbegründung für den Zugriff und entscheidend für die Einhaltung von Vorschriften und Bestimmungen.

  • Wie soll der Verkehr beim Zugriff auf eine Ressource verarbeitet werden?

Trust Engine

Die Trust Engine ist das System in einem Zero-Trust-Netzwerk, das eine Risikoanalyse für eine bestimmte Anfrage oder Aktion durchführt. Die Aufgabe dieses Systems ist es, eine numerische Bewertung des Risikos einer bestimmten Anfrage/Aktion zu erstellen, die die Policy Engine verwendet, um eine endgültige Entscheidung über die Genehmigung zu treffen.

Die Trust Engine greift häufig auf Daten aus maßgeblichen Inventarsystemen zurück, um die Attribute einer Entität bei der Berechnung ihrer Punktzahl zu überprüfen. Ein Geräteinventar kann der Trust Engine zum Beispiel Informationen darüber liefern, wann ein Gerät das letzte Mal auf seine Konformität hin überprüft wurde oder ob es über eine bestimmte Hardware-Sicherheitsfunktion verfügt.

Eine numerische Risikobewertung zu erstellen, ist eine schwierige Aufgabe. Ein einfacher Ansatz wäre es, eine Reihe von Ad-hoc-Regeln festzulegen, die die Risikobereitschaft eines Unternehmens bewerten. Bei einem Gerät, das nicht mit den neuesten Software-Patches ausgestattet ist, könnte die Punktzahl beispielsweise herabgesetzt werden. Ebenso könnte die Vertrauenswürdigkeit eines Nutzers, der ständig bei der Authentifizierung fehlschlägt, herabgesetzt werden. Eine Ad-hoc-Vertrauensbewertung mag zwar für den Anfang einfach sein, aber eine Reihe von statisch definierten Regeln reicht nicht aus, um das gewünschte Ziel der Abwehr unerwarteter Angriffe zu erreichen. Ausgereifte Trust-Engines verwenden daher nicht nur statische Regeln, sondern auch Techniken des maschinellen Lernens, um eine Scoring-Funktion abzuleiten.

Beim maschinellen Lernen wird eine Bewertungsfunktion abgeleitet, indem beobachtbare Fakten aus einer Teilmenge von Aktivitätsdaten, den sogenannten Trainingsdaten, berechnet werden. Bei den Trainingsdaten handelt es sich um rohe Beobachtungen, die mit vertrauenswürdigen oder nicht vertrauenswürdigen Personen in Verbindung gebracht wurden. Aus diesen Daten werden Merkmale extrahiert und zur Ableitung einer computergenerierten Bewertungsfunktion verwendet. Diese Bewertungsfunktion - oder das Modell im Sinne des maschinellen Lernens - wird dann mit einer Reihe von Daten verglichen, die das gleiche Format wie die Trainingsdaten haben. Die daraus resultierenden Werte werden mit von Menschen definierten Risikobewertungen verglichen, und die Qualität des Modells kann dann anhand seiner Fähigkeit, das mit den analysierten Daten verbundene Risiko korrekt vorherzusagen, verfeinert werden. Ein Modell, das eine ausreichende Genauigkeit aufweist, kann dann als Vorhersage für die Gefährlichkeit von noch nicht gesehenen Anfragen im Netzwerk gelten.

Modelle für maschinelles Lernen können aus einer Vielzahl von Merkmalen wie der IP-Adresse des Nutzers, dem Standort, dem Gerät usw. lernen, um zu beurteilen, ob eine aktuelle Nutzeranfrage anormal oder typisch für den aktuellen Kontext ist. Denk daran, dass "False Positives" jederzeit auftreten können. Das liegt daran, dass es legitime Situationen gibt, in denen die fragliche Nutzeraktivität normal ist, die Vorhersage aber eher anomal ist. Ein Beispiel für einen "False Positive" ist, wenn ein Nutzer an einen neuen Ort reist, z. B. in den Urlaub, und eine Zugangsanfrage stellt. In diesem Fall wurde das maschinelle Lernmodell noch nicht auf den Standort des neuen Nutzers trainiert und wird daher höchstwahrscheinlich ein anormales Muster erkennen. Der Umgang mit falsch-positiven Ergebnissen ist ein wichtiges Thema beim maschinellen Lernen und wird in der Regel durch die Anpassung von Faktoren wie Lerndauer, Genauigkeit und Wiedererkennung verbessert.

Obwohl maschinelles Lernen zunehmend zur Lösung schwieriger Rechenprobleme eingesetzt wird, macht es die Notwendigkeit expliziterer Regeln in der Vertrauensmaschine nicht überflüssig. Ob aufgrund von Einschränkungen bei den abgeleiteten Bewertungsmodellen oder aufgrund des Wunsches nach einer individuellen Anpassung der Bewertungsfunktion, Trust Engines verwenden in der Regel eine Mischung aus Ad-hoc- und maschinellen Bewertungsmethoden.

Welche Einrichtungen werden bewertet?

Die Entscheidung, welche Komponenten eines vertrauensfreien Netzwerks bewertet werden sollten, ist eine interessante Überlegung. Soll die Bewertung für jede einzelne Einheit (Nutzer, Gerät und Anwendung), für den Netzwerkagenten als Ganzes oder für beide berechnet werden? Schauen wir uns einige Szenarien an.

Verwendung von Netzwerkagenten für das Scoring

Stell dir vor, die Anmeldedaten eines Benutzers werden von einem böswilligen Dritten erpresst. Einige Systeme entschärfen diese Bedrohung, indem sie das Benutzerkonto sperren, was einen Denial-of-Service-Angriff gegen den betreffenden Benutzer darstellen kann. Würden wir einen Nutzer aufgrund dieser Aktivität negativ bewerten, hätte ein Zero-Trust-Netzwerk das gleiche Problem. Ein besserer Ansatz ist es, zu erkennen, dass wir den Netzwerkagenten authentifizieren und so dem Netzwerkagenten des Angreifers entgegenwirken, während der Netzwerkagent des legitimen Nutzers unversehrt bleibt. Dieses Szenario spricht dafür, dass der Netzwerkagent die Entität ist, die bewertet werden sollte.

Verwendung von Geräten für das Scoring

Aber nur den Netzwerkagenten zu scannen, kann gegen andere Angriffsvektoren unzureichend sein. Nehmen wir ein Gerät, das mit bösartigen Aktivitäten in Verbindung gebracht wurde. Der Netzwerkagent eines Nutzers auf diesem Gerät zeigt vielleicht keine Anzeichen von bösartigem Verhalten, aber die Tatsache, dass der Agent mit einem verdächtigen Gerät gebildet wird, sollte sich eindeutig auf die Vertrauensbewertung für alle Anfragen auswirken, die von diesem Gerät ausgehen. Dieses Szenario legt nahe, dass das Gerät bewertet werden sollte.

Nehmen wir einen böswilligen menschlichen Nutzer (die berüchtigte interne Bedrohung), der mehrere Kiosk-Geräte benutzt, um Geschäftsgeheimnisse auszuspionieren. Wir möchten, dass die Vertrauensmaschine dieses Verhalten erkennt, wenn der Nutzer zwischen den Geräten wechselt, und dass der abnehmende Grad an Vertrauen in der Vertrauensbewertung für alle zukünftigen Autorisierungsentscheidungen berücksichtigt wird. Auch hier zeigt sich, dass die Bewertung des Netzwerkagenten allein nicht ausreicht, um häufige Bedrohungen abzuschwächen. Insgesamt scheint es die richtige Lösung zu sein, sowohl den Netzwerkagenten selbst als auch die zugrundeliegenden Entitäten, die den Agenten bilden, zu bewerten. Diese Bewertungen können der Policy Engine zur Verfügung gestellt werden, die dann die richtigen Komponenten auswählt, die je nach der zu erstellenden Policy zugelassen werden.

Wenn beim Verfassen von Richtlinien so viele Punkte berücksichtigt werden müssen, kann dies die Erstellung von Richtlinien jedoch erschweren und fehleranfällig machen. In einer idealen Welt wäre eine einzige Bewertung ausreichend, aber dieser Ansatz stellt zusätzliche Anforderungen an die Verfügbarkeit der Trust Engine. Ein System, das versucht, eine einzige Bewertung zu erstellen, müsste wahrscheinlich zu einem Online-Modell übergehen, bei dem die Trust Engine während der Entscheidungsfindung interaktiv abgefragt wird. Die Engine würde einen gewissen Kontext über die zu genehmigende Anfrage erhalten, damit sie die beste Bewertungsfunktion für diese spezielle Anfrage auswählen kann. Dieses Konzept ist deutlich komplexer in Aufbau und Betrieb. Außerdem erscheint es für Richtlinien, bei denen ein Systemadministrator eine bestimmte Komponente gezielt ansprechen möchte (z. B. nur Einsätze von Geräten mit einer Punktzahl über X zulassen), ziemlich umständlich.

Offenlegung von Punkten gilt als riskant

Obwohl die Punktzahlen, die den Entitäten in einem Null-Vertrauensnetzwerk zugewiesen werden, nicht als vertraulich gelten, sollte es vermieden werden, die Punktzahlen den Endnutzern des Systems zugänglich zu machen. Die eigene Punktzahl zu sehen, könnte ein Signal für potenzielle Angreifer sein, dass sie ihre Vertrauenswürdigkeit im System erhöhen oder verringern. Dieser Wunsch, Informationen zurückzuhalten, sollte gegen die Frustration abgewogen werden, die dadurch entsteht, dass die Endnutzer/innen nicht verstehen können, wie sich ihre Handlungen auf ihre eigene Vertrauenswürdigkeit im System auswirken. Ein guter Kompromiss aus der Betrugsindustrie besteht darin, den Nutzern ihre Punktzahl nur selten zu zeigen und die Faktoren hervorzuheben, die zur Ermittlung ihrer Punktzahl beitragen.

Datenspeicher

Die Datenspeicher, die für Autorisierungsentscheidungen verwendet werden, sind ganz einfach die Quellen der Wahrheit für die aktuellen und vergangenen Zustände des Systems. Die Informationen aus diesen Datenspeichern fließen durch die Systeme der Kontrollebene und bilden einen großen Teil der Grundlage für die Autorisierungsentscheidungen, wie in Abbildung 4-4 dargestellt.

Wir haben bereits darüber gesprochen, dass die Trust Engine diese Datenspeicher nutzt, um einen Trust Score zu erstellen, der wiederum von der Policy Engine berücksichtigt wird. Auf diese Weise sind die Informationen aus den Datenspeichern der Kontrollebene durch das Autorisierungssystem geflossen und haben schließlich die Policy Engine erreicht, wo die Entscheidung getroffen wurde. Diese Datenspeicher werden sowohl direkt als auch indirekt von der Policy Engine genutzt, können aber auch für andere Systeme nützlich sein, die verlässliche Daten über den Zustand des Netzwerks benötigen.

Abbildung 4-4. Autoritative Datenspeicher werden von der Policy Engine sowohl direkt als auch indirekt über die Trust Engine verwendet

Zero-Trust-Netzwerke haben in der Regel viele Datenspeicher, die nach Funktionen organisiert sind. Es gibt zwei Haupttypen: Bestandsdaten und historische Daten. Ein Inventar ist eine einzige konsistente Quelle der Wahrheit, die den aktuellen Zustand der Ressource(n) aufzeichnet, die sie repräsentiert. Ein Beispiel dafür ist ein Benutzerinventar, das alle Benutzerinformationen speichert, oder ein Geräteinventar, das Informationen über die dem Unternehmen bekannten Geräte aufzeichnet.

In einem Inventar gibt es einen Primärschlüssel, der die verfolgte Entität eindeutig repräsentiert. Im Falle eines Nutzers ist das wahrscheinlich der Benutzername, bei einem Gerät vielleicht die Seriennummer. Wenn sich ein Zero Trust Agent authentifiziert, vergleicht er seine Identität mit diesem Primärschlüssel im Inventar. Stell dir das so vor: Ein Nutzer authentifiziert sich mit einem bestimmten Benutzernamen. Die Policy Engine erfährt den Benutzernamen und dass der Benutzer erfolgreich authentifiziert wurde. Der Benutzername wird dann als Primärschlüssel für den Abgleich mit dem Benutzerinventar verwendet. Wenn du dir diesen Ablauf und Zweck vor Augen hältst, kannst du je nach deiner Implementierung und deinen Authentifizierungsentscheidungen die richtigen Primärschlüssel auswählen.

Ein historischer Datenspeicher ist ein wenig anders. Historische Datenspeicher werden in erster Linie für die Risikoanalyse aufbewahrt. Sie sind nützlich, um vergangenes Verhalten und Muster zu untersuchen, um das Risiko in Bezug auf eine bestimmte Anfrage oder Aktion zu bewerten. Diese Daten werden am ehesten von den Komponenten der Trust-Engine genutzt, da diese in erster Linie für Vertrauens- und Risikobestimmungen zuständig ist.

Man kann sich viele Arten von historischen Datenspeichern vorstellen, und wenn es um die Risikoanalyse geht, sind der Fantasie keine Grenzen gesetzt. Einige gängige Beispiele sind Benutzerabrechnungsdaten und sFlow1 Daten. Unabhängig davon, welche Daten gespeichert werden, müssen sie mit dem Primärschlüssel aus einem der Bestandssysteme abfragbar sein. Wir werden im Laufe dieses Buches über verschiedene Bestands- und Verlaufsdatenspeicher sprechen, wenn wir verwandte Konzepte vorstellen.

Bedrohungsdaten, die sowohl aus internen als auch aus externen Quellen wie Open Source Intelligence (OSINT) stammen, liefern wertvolle Erkenntnisse, die von Trust-Engines genutzt werden können, um einen Trust-Score zu ermitteln. Nehmen wir ein Szenario an, in dem die Zugangsdaten eines Nutzers aufgrund einer kürzlich erfolgten Datenpanne im Dark Web aufgetaucht sind. In diesem Fall kann die Trust Engine die Bedrohungsdaten nutzen, um die Vertrauenswürdigkeit des Nutzers zu berechnen, was dazu führen kann, dass die Policy Engine die Anfrage ablehnt oder nur eingeschränkten Zugang gewährt.

Compliance- und Regulierungsstandards wie die General Data Protection Regulation (GDPR), das Federal Risk and Authorization Management Program (FedRAMP) usw. wirken sich auf den Entscheidungsprozess der Policy Engine bei der Analyse einer Anfrage aus. Unternehmen verfügen in der Regel über ein versioniertes System zur Einhaltung von Vorschriften und gesetzlichen Bestimmungen, das zur Erstellung von Richtlinien verwendet werden kann, die im Idealfall vollständig automatisiert sind, aber höchstwahrscheinlich eine abschließende menschliche Überprüfung vor der Freigabe erfordern. Das Endergebnis ist ein robustes System, in dem die Richtlinien-Engine den Compliance- und Regulierungsspeicher abfragen kann, um zu entscheiden, ob eine Anfrage genehmigt oder abgelehnt werden sollte.

Szenario-Durchgang

Bevor wir dieses Kapitel abschließen, betrachten wir ein einfaches, aber realistisches Szenario, das dir helfen wird, die verschiedenen Komponenten, die in diesem und früheren Kapiteln besprochen wurden, zu verstehen und wie sie miteinander interagieren. In späteren Kapiteln werden wir das Szenario erweitern und uns mit verschiedenen Aspekten von Zero Trust befassen, z. B. mit Nutzern, Geräten, Anwendungen und Datenverkehr.

Schauen wir uns einen typischen Arbeitsablauf für einen Benutzer namens Bob an, der als Business Manager für die Wayne Corporation arbeitet und versucht, auf eine Ressource, z. B. einen Drucker, zuzugreifen. Abbildung 4-5 zeigt eine Übersicht über die Zero-Trust-Komponenten in diesem Szenario.

Abbildung 4-5. Eine logische Ansicht eines Zero-Trust-Sicherheitsmodells mit Kontrollebene, Datenebene, Benutzer und Ressourcen

Betrachte zunächst die Komponenten der Steuerungsebene, wie in Abbildung 4-6 dargestellt. Bobs persönliche Daten, wie sein Name, seine IP-Adresse und sein Standort, werden im User Store gespeichert. Zu den Gerätedaten gehören Details wie das Betriebssystem und ob Bobs Geräte den neuesten Sicherheitspatch erhalten haben oder nicht. In den Aktivitätsprotokollen schließlich werden alle Interaktionen aufgezeichnet, einschließlich des Zeitstempels (im Unix-Format), der IP-Adresse und des Standorts.

Die Trust Engine nutzt ein maschinelles Lernmodell, um den Trust Score dynamisch zu berechnen, indem sie nach anormalem Verhalten in Bobs Aktivitätsprotokollen sucht. Ihre Hauptaufgabe ist es, den Trust Score zu berechnen und an die Policy Engine zu übermitteln.

Die Policy Engine, das Herzstück der Control Plane, entscheidet anhand von Trust Scores und Compliance-Richtlinien, ob Bobs Anfrage bewilligt oder abgelehnt werden soll.

Abbildung 4-6. Um eine Entscheidung über die Autorisierung einer Zugriffsanfrage zu treffen, verwendet die Policy Engine eine Vertrauensbewertung sowie Compliance-Regeln

Wir werden uns nun die Regeln, die das Verhalten der Policy Engine bestimmen, genauer ansehen. Die ersten beiden beziehen sich auf die Einhaltung von Vorschriften und stellen sicher, dass das System stets die gesetzlichen und betrieblichen Anforderungen erfüllt. Die dritte fügt der Richtlinie einen Vertrauenswert als dynamischen Input hinzu und stellt sicher, dass Anfragen nur bewilligt werden, wenn der Wert einen bestimmten Schwellenwert überschreitet. Wenn keine andere Regel zutrifft, wird der Antrag standardmäßig abgelehnt, sodass der Zugang nur dann gewährt wird, wenn eine Regel ihn ausdrücklich zulässt:

1. Einhaltung

Erlaube Anfragen nur während der Bürozeiten von Montag bis Freitag zwischen 9.00 und 17.00 Uhr Eastern Time Zone (EST).

2. Einhaltung

Lasse nur Anfragen von Geräten zu, die das neueste Sicherheitsupdate erhalten haben. Damit soll sichergestellt werden, dass die Geräte gepatcht und weniger anfällig für Angriffe sind.

3. Trust Score

Erlaube Anfragen nur, wenn der Vertrauenswert größer als 7/10 ist. Ein höherer Vertrauenswert schafft in diesem Fall mehr Vertrauen, daher wird ein Wert von 7 verwendet. In der Regel sind die Vertrauenswerte in den Richtlinien konfigurierbar und werden im Laufe der Zeit angepasst, um ein Gleichgewicht zu gewährleisten; ein niedriger Wert lässt böswillige Anfragen durch die Maschen schlüpfen, während ein hoher Wert echte Zugriffsanfragen negativ beeinflussen kann.

4. Standard

Wenn keine andere Regel angewendet wird, gilt diese Regel als Auffangregel (also als Standardregel), die in Kraft tritt. Diese Regel ist wichtig, denn es wird empfohlen, eine Anfrage standardmäßig zu verweigern, anstatt sie standardmäßig zuzulassen. Das ist sinnvoll, weil es in einem Null-Vertrauenssystem kein inhärentes Vertrauen gibt, so dass jede Anfrage für sich bewertet und als gleich bösartig behandelt wird.

Als Nächstes betrachten wir die Datenebene, zu der die Durchsetzung, die Ressourcen (Drucker, Dateifreigaben usw.) und der Benutzer Bob gehören, der den Zugriff auf eine Ressource (in diesem Fall eine Dateifreigabe) beantragt. In Abbildung 4-7 sind sowohl die Steuerungsebene als auch die Datenebene dargestellt.

Abbildung 4-7. Bobs Antrag auf Zugriff auf die Dateifreigabe wird abgelehnt, nachdem die Policy Engine den Antrag anhand der Vertrauenswürdigkeit und anderer Richtlinienregeln bewertet hat

Hier ist eine schrittweise Analyse von Bobs Anfrage:

  1. Am Montag, um 9.30 Uhr Eastern Time Zone (EST), fordert Bob von seinem Laptop aus Zugriff auf die Dateifreigabe an. Der Laptop ist vollständig gepatcht und läuft unter MacOS.

  2. Die Durchsetzungskomponente fängt die Anfrage ab und sendet sie zur Autorisierung an die Policy Engine.

  3. Die Policy Engine empfängt die Anfrage und berät sich mit der Trust Engine, um die Vertrauenswürdigkeit der Anfrage zu bestimmen.

  4. Die Trust-Engine verwendet ein maschinelles Lernmodell, um den Trust-Score auf der Grundlage der Aktivitätsprotokolle zu berechnen. Anomalien werden erkannt, weil Bobs IP-Adresse 1.2.3.5 und sein Standort in Finnland ungewöhnlich sind. Da die Anfragen von New York und Finnland aus gestellt wurden und nur wenige Sekunden auseinander liegen, scheint es für einen Menschen unmöglich, die Zeitstempel zwischen den letzten beiden Aktivitäten zu vergleichen. Das maschinelle Lernmodell beschließt, dass die Anfrage mit einem Vertrauenswert von 3 bewertet werden sollte, was auf ein geringes Maß an Vertrauen hindeutet, und sendet diesen Wert an die Policy Engine.

  5. Die Policy Engine erhält von der Trust Engine den Vertrauenswert 3.

  6. Für die Autorisierung vergleicht die Policy Engine die Anfrage mit allen Richtlinienregeln:

    Diese erste Regel führt zu einer Bewilligung (oder Erlaubnis), weil der Antrag während der zulässigen Zeit am Montag gestellt wird.

    Die zweite Regel führt zu einer Gewährung (oder Erlaubnis), weil die Anfrage mit einem Gerät gestellt wird, das mit dem neuesten Sicherheitsupdate gepatcht wurde.

    Die dritte Regel führt zu einer Verweigerung, weil die Anfrage einen Vertrauenswert von 3 hat, während die Richtlinie einen Vertrauenswert von 7 oder höher verlangt, um den Zugriff zu gewähren. Da die Ablehnung eine endgültige Aktion ist, verarbeitet die Policy Engine keine weiteren Regeln.

  7. Die Policy Engine sendet eine verweigerte Aktion an die Durchsetzungskomponente. Sie sendet auch zusätzliche Informationen über das Ergebnis, die helfen können, den Grund für die Verweigerung der angeforderten Aktion zu verstehen.

  8. Die Durchsetzungskomponente erhält das Ergebnis der Policy Engine und lehnt Bobs Anfrage ab, sodass er nicht auf die Dateifreigabe zugreifen kann. Außerdem schickt sie Bob eine hilfreiche Nachricht, wie er seine Chancen auf den Zugriff auf die Ressource verbessern kann, wenn er sich dazu entschließt, eine weitere Anfrage zu stellen.

Das Szenario in diesem Abschnitt ist zwar sehr einfach, aber es vermittelt ein funktionales Verständnis der verschiedenen Komponenten der Kontroll- und Datenebene, die zusammenarbeiten, um Bobs Anfrage nach Zugriff auf die Dateifreigabe abzulehnen. Das Wichtigste dabei ist, dass das System keine Ad-hoc-Entscheidungen trifft, sondern den Gesamtzusammenhang der Zugriffsanfrage bei seinen Entscheidungen berücksichtigt.

Zusammenfassung

In diesem Kapitel ging es um die Systeme, die für die endgültige Entscheidung verantwortlich sind, ob eine bestimmte Anfrage in einem Zero-Trust-Netzwerk genehmigt werden sollte. Diese Entscheidung ist eine kritische Komponente eines solchen Netzwerks und sollte daher sorgfältig konzipiert und isoliert werden, um sicherzustellen, dass sie vertrauenswürdig ist.

Wir haben diese Verantwortung in vier Schlüsselsysteme aufgeteilt: Durchsetzung, Policy Engine, Trust Engine und Datenspeicher. Diese Komponenten sind logische Verantwortungsbereiche. Sie könnten zwar in weniger physischen Systemen zusammengefasst werden, aber die Autoren bevorzugen ein isoliertes Design.

Das Durchsetzungssystem ist dafür verantwortlich, dass die Autorisierungsentscheidung der Policy Engine wirksam wird. Da sich dieses System im Datenpfad des Nutzerverkehrs befindet, wird es am besten so implementiert, dass die Richtlinienentscheidung referenziert und dann durchgesetzt wird. Je nach gewählter Architektur kann die Policy Engine benachrichtigt werden, bevor eine Anfrage gestellt wird, oder während der Bearbeitung dieser Anfrage.

Die Policy Engine ist das Schlüsselsystem, das die Genehmigungsentscheidung auf der Grundlage der ihm zur Verfügung stehenden Daten und der von den Systemadministratoren erstellten Policy-Definitionen berechnet. Dieses System sollte stark isoliert sein. Die definierten Richtlinien sollten idealerweise getrennt von der Engine gespeichert werden und es sollten gute Softwareentwicklungspraktiken angewandt werden, um sicherzustellen, dass Änderungen verstanden und überprüft werden und nicht verloren gehen, wenn die Richtlinie vom Vorschlag zur Implementierung übergeht. Da in Zero-Trust-Netzwerken viel feiner abgestufte Richtlinien erwartet werden, entscheiden sich ausgereifte Unternehmen dafür, die Verantwortung für die Festlegung der Richtlinien innerhalb der Organisation zu verteilen, wobei die Sicherheitsteams die vorgeschlagenen Änderungen überprüfen.

Die Trust Engine ist ein neues Konzept in Sicherheitssystemen. Sie ist für die Berechnung der Vertrauenswürdigkeit von Systemkomponenten zuständig und verwendet dazu statische und abgeleitete Algorithmen, die aus dem bisherigen Verhalten abgeleitet werden. Der Trust Score ist eine numerische Bestimmung der Vertrauenswürdigkeit einer Komponente und ermöglicht es den Richtlinienerstellern, sich auf den Grad des Vertrauens zu konzentrieren, der für den Zugriff auf eine Ressource erforderlich ist, anstatt sich mit den Einzelheiten der Aktionen zu befassen, die dieses Vertrauen verringern könnten.

Die letzte Komponente dieses Teils des Systems sind die maßgeblichen Datenquellen, die aktuelle und historische Daten erfassen, die für die Genehmigungsentscheidung verwendet werden können. Diese Datenspeicher sollten sich darauf konzentrieren, Quellen der Wahrheit zu sein. Die Richtlinien-Engine, die Vertrauens-Engine und vielleicht auch Systeme von Drittanbietern können diese Daten nutzen, so dass sich die Erfassung dieser Daten auszahlt.

Das Szenario zeigte, wie die verschiedenen Komponenten der Kontroll- und Datenebene zusammenwirken, damit das System funktioniert. In unserem Szenario wurde die Anfrage des Benutzers Bob, auf eine Dateifreigabe zuzugreifen, auf der Grundlage des Gesamtkontextes der Anfrage bewertet, der sowohl eine dynamische Berechnung der Vertrauenswürdigkeit als auch verschiedene vom Unternehmen festgelegte Richtlinien umfasst, um eine endgültige Genehmigungsentscheidung zu treffen. Dieses Szenario wird in späteren Kapiteln weiter ausgeführt.

Im nächsten Kapitel geht es darum, wie Geräte Vertrauen gewinnen und erhalten.

1 sFlow, kurz für "sampled flow", ist ein Industriestandard für den Paketexport auf Schicht 2 des OSI-Modells.

Get Zero Trust Networks, 2. Auflage now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial