Zero Trust Netzwerke

Kapitel 4. Entscheidungen über Genehmigungen treffen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

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

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 maßgeblich für die Zugriffskontrolle 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.

Das Zero-Trust-Modell ist noch sehr neu und dieser Bereich entwickelt sich schnell weiter. Einige der in diesem Kapitel enthaltenen Inhalte gelten zum Zeitpunkt der Erstellung dieses Dokuments als Stand der Technik. Die bekannten Implementierungen unterscheiden sich noch stark in ihren Ansätzen, und die meisten sind nicht öffentlich zugänglich. Nichtsdestotrotz sind die wichtigsten Komponenten und Verantwortlichkeiten bekannt.

Unter Berücksichtigung der Realität konzentriert sich dieses Kapitel auf die architektonische Anordnung der Komponenten, die erforderlich sind, um Zero-Trust-Autorisierungsentscheidungen zu treffen, 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 die praktischen Kronjuwelen des Zero-Trust-Sicherheitsmodells, daher sollte bei ihrer Wartung und ihrem Sicherheitsstatus besondere Sorgfalt walten. Prüfe sorgfältig alle Vorschläge, die vorschlagen, diese Aufgaben in einem einzigen System zusammenzufassen.

Abbildung 4-1. Null-Vertrauens-Autorisierungssysteme

Die Durchsetzungskomponente wird in großer Zahl im gesamten System vorhanden sein und sollte so nah wie möglich an der Arbeitsbelastung sein. Sie ist diejenige, die das Ergebnis der Autorisierungsentscheidung tatsächlich beeinflusst. Sie wird normalerweise als Load Balancer, Proxy oder sogar als Firewall eingesetzt. Diese Komponente interagiert mit der Policy Engine, die für die eigentliche Entscheidung zuständig ist. 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 Trust Engine wird von der Policy Engine für die Risikoanalyse genutzt. Sie 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 eine Genehmigungsentscheidung getroffen werden kann. Googles BeyondCorp ist weithin als Vorreiter dieser Technologie bekannt.

Schließlich gibt es noch die verschiedenen Datenspeicher, die die Quelle der Wahrheit für die Daten darstellen, 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, seien es Benutzerdaten, Gerätedaten oder andere, werden von der Policy Engine und der Trust Engine intensiv genutzt und bilden die Grundlage, an der alle Entscheidungen gemessen werden .

Durchsetzung

Die Durchsetzungskomponente (siehe Abbildung 4-2) ist ein natürlicher Ansatzpunkt. Sie steht an der "Frontlinie" des Berechtigungsflusses und ist für die Ausführung der Entscheidungen verantwortlich, die vom Rest des Berechtigungssystems getroffen 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 und 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 Control Plane 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 hast, 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 sind.

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 das Ergebnis feststeht, wird es 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 niedriger Latenz ermöglicht eine feinkörnige und umfassende Autorisierung von Netzwerkaktivitäten; so könnten 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; die Integration der Policy Engine in denselben Prozess könnte sie daher unerwünschten Risiken 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.

Was ist mit RADIUS passiert?

Die Beziehung zwischen der Policy Engine und der Durchsetzungsschicht ist den meisten Netzwerktechnikern vertraut. 1997 hat die IETF einen Standard ratifiziert, der das RADIUS-Protokoll beschreibt, das die Authentifizierung, Autorisierung und Abrechnung von Netzwerkdiensten ermöglicht. RADIUS steht für Remote Authentication Dial-In User Service -allein derName verrät sein Alter. Obwohl das Protokoll selbst hoffnungslos unsicher ist (es verwendet MD5 für die Echtheitsbestätigung), wurde es speziell für die vorliegende Aufgabe geschrieben. Wie würde es aussehen, RADIUS zwischen der Durchsetzungsschicht und der Policy Engine zu verwenden? RADIUS könnte mit anderen Protokollen, die in diesem Buch besprochen werden, geschützt werden, aber das erscheint mir zu umständlich. Vielleicht gibt es eine Möglichkeit, ein RADIUS-ähnliches Projekt zu schaffen, das die Bedrohungsrealität der heutigen Systeme berücksichtigt.

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 speichern. 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 auf menschliche Systemadministratoren zu verlassen, die 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 Richtlinie in einem Zero-Trust-Netzwerk ähnelt in mancher Hinsicht der traditionellen Netzwerksicherheit, in anderer Hinsicht unterscheidet sie sich jedoch grundlegend.

Die Zero-Trust-Politik ist noch nicht standardisiert

Die Realität sieht heute so aus, dass die Zero-Trust-Richtlinien immer noch nicht in der gleichen Weise standardisiert sind wie netzwerkorientierte Richtlinien. 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. Dies 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 in Form von Details der Netzwerkimplementierung (IP-Adressen und Bereiche) zu definieren, werden sie am besten in Form von logischen Komponenten im Netzwerk festgelegt. Diese Komponenten bestehen im Allgemeinen 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.

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. Im nächsten Abschnitt werden wir mehr über die Score-Komponente erfahren.

Es gibt keinen Standard

Gegenwärtig implementieren ausgereifte Zero-Trust-Netzwerke ihre eigene Richtliniensprache bzw. ihr eigenes Richtlinienformat von Fall zu Fall und werden in der Regel vollständig intern entwickelt. Einfachere Zero-Trust-Netzwerke können die Richtlinien in eine bestehende Struktur einbetten, wie in Abbildung 4-3 dargestellt. Letzteres ist zwar im Allgemeinen akzeptabel, wird aber in der Regel überholt, wenn sich das Netzwerk weiterentwickelt und neue Funktionen hinzufügt. Die Vorteile einer standardisierten/interoperablen Policy-Sprache liegen klar auf der Hand. Diese Arbeit bleibt jedoch eine offene Forschungsfrage .

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

Wer legt die Politik fest?

Zero Trust Netzwerkrichtlinien sollten feinkörnig sein, was für die 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 Definition der Richtlinien auf die Teams zu verteilen, damit diese die Richtlinien für die Dienste, die ihnen gehören, pflegen können.

Die Öffnung der Richtliniendefinition für die gesamte Organisation kann gewisse Risiken mit sich bringen, 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.

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 nützlich sein.

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 zu überprüfen, wenn sie ihren Score berechnet. Ein Geräteinventar kann der Trust Engine zum Beispiel Informationen darüber liefern, wann ein Gerät das letzte Mal geprüft wurde oder ob es eine bestimmte Hardware-Sicherheitsfunktion hat.

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-Vertrauenswürdigkeitsprüfung mag zwar für den Anfang einfach sein, aber eine Reihe statisch definierter Regeln reicht nicht aus, um das angestrebte Ziel der Verteidigung gegen unerwartete Angriffe zu erreichen. Ausgereifte Trust-Engines verwenden daher neben statischen Regeln auch maschinelle Lernverfahren, um eine Bewertungsfunktion 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 unbearbeitete Beobachtungen, die mit vertrauenswürdigen oder nicht vertrauenswürdigen Personen in Verbindung gebracht werden. Aus diesen Daten werden Merkmale extrahiert und zur Ableitung einer computergenerierten Scoring-Funktion verwendet. Diese Bewertungsfunktion, ein 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 Risiko der analysierten Daten korrekt vorherzusagen, verfeinert werden. Ein Modell, das eine ausreichende Genauigkeit aufweist, kann dann als Vorhersage über die Gefährlichkeit von noch nicht gesehenen Anfragen im Netzwerk gelten.

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 aus Gründen der gewünschten Anpassung der Bewertungsfunktion - Vertrauensdienste 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.

Stell dir vor, die Anmeldedaten eines Benutzers werden von einem böswilligen Dritten erzwungen. 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 Netzwerk-Agent die Entität ist, die bewertet werden sollte.

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 an, dass ein böswilliger menschlicher Nutzer (die berüchtigte interne Bedrohung) mehrere Kioskgerä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 gängige Bedrohungen zu entschärfen.

Insgesamt scheint es die richtige Lösung zu sein, sowohl den Netzwerkagenten selbst als auch die zugrundeliegenden Einheiten, aus denen der Agent besteht, zu bewerten. Diese Bewertungen können der Policy Engine zur Verfügung gestellt werden, die dann die richtige(n) Komponente(n) auswählt, die auf der Grundlage der geschriebenen Policy zugelassen werden soll.

Die Vorlage so vieler Bewertungen, die bei der Erstellung von Richtlinien berücksichtigt werden müssen, kann die Aufgabe der Erstellung von Richtlinien jedoch schwieriger und fehleranfälliger machen. In einer idealen Welt wäre eine einzige Bewertung ausreichend, aber dieser Ansatz stellt zusätzliche Anforderungen an die Verfügbarkeit der Vertrauensmaschine. 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 scheint 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 zu sein.

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 Anzeige der eigenen Punktzahl könnte für potenzielle Angreifer ein Signal sein, dass sie ihre Vertrauenswürdigkeit im System erhöhen oder verringern. Dieser Wunsch, Informationen zurückzuhalten, sollte gegen die Frustration der Endnutzer/innen abgewogen werden, die nicht verstehen können, wie sich ihre Handlungen auf ihr eigenes Vertrauen in das System auswirken. Ein guter Kompromiss aus der Betrugsindustrie besteht darin, den Nutzern ihre Punktzahl nur selten zu zeigen und die Faktoren hervorzuheben, die zu ihrer Punktzahl beitragen bestimmen.

Datenspeicher

Die Datenspeicher, die für Autorisierungsentscheidungen verwendet werden, sind ganz einfach die Quellen der Wahrheit über den aktuellen und vergangenen Zustand 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: Inventar 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. Die Komponenten der Trust-Engine werden diese Daten höchstwahrscheinlich nutzen, da die Vertrauens- und Risikobestimmungen die Hauptaufgabe der Engine sind.

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 sFlow-Daten. Unabhängig davon, welche Daten gespeichert werden, müssen sie mit dem Primärschlüssel aus einem der Bestandssysteme abfragbar sein.

Wir werden in diesem Buch über verschiedene Bestands- und historische Datenspeicher sprechen und verwandte Konzepte vorstellen.

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 Richtliniendefinitionen 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 dieser Richtlinien auf die Organisation zu verteilen, wobei die Sicherheitsteams die vorgeschlagenen Änderungen überprüfen.

Die Trust Engine ist ein neues Konzept für Sicherheitssysteme. Sie ist für die Berechnung der Vertrauenswürdigkeit von Systemkomponenten verantwortlich, indem sie statische und abgeleitete Algorithmen verwendet, die aus dem bisherigen Verhalten abgeleitet werden. Der Trust Score ist eine numerische Bestimmung der Vertrauenswürdigkeit einer Komponente und ermöglicht es den Richtlinienverfassern, sich auf den Grad des Vertrauens zu konzentrieren, der für den Zugriff auf eine Ressource erforderlich ist, anstatt sich mit den Details zu befassen, welche Aktionen 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 Policy-Engine, die Trust-Engine und vielleicht auch Systeme von Drittanbietern können diese Daten nutzen, so dass die Erfassung dieser Daten eine angemessene Rendite abwirft.

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