Steuerung von Identitäten in Unternehmensnetzen

Mein Kollege Dr. Behrooz Moayeri hat in der April-Ausgabe des Netzwerk Insider [1] von IT-Mündigkeit gesprochen. Dabei hat er unter anderem ausgeführt, dass Endgeräte mittlerweile nicht mehr nur in den sicheren Häfen der Unternehmensnetze verweilen – auch nicht per Virtual Private Network (VPN) – und von hier aus über abgesicherte Verbindungen Dienste an verschiedenen Stellen im Rechenzentrum und im Internet konsumieren. Vielmehr werden diese Endgeräte direkt aus dem Homeoffice in das Internet gelassen, auch weil viele Sicherheitstechnologien auf dem Weg zu speziellen Diensten wenig bis keine Fähigkeiten mehr haben, diese Kommunikation zu kontrollieren.

Diese Umschreibung zeigt meiner Ansicht nach ganz gut das Dilemma auf, in dem sich die IT-Sicherheit in Zeiten der Netzwerk-Transformation befindet. Viele Endgeräte kommunizieren von irgendwo zu irgendwelchen Diensten und nicht mehr ausschließlich von Standort-lokalen Netzen zu Diensten, die zentral im Rechenzentrum bereitgestellt werden. Dieses Maß an Unkontrollierbarkeit und Anarchie – vornehm auch Dynamisierung genannt – ist natürlich aus dem Blickwinkel einer ganzheitlichen IT-Sicherheit nicht tragbar, denn die obersten Prämissen sind hierbei nach wie vor: Kontrolle und Sichtbarkeit. Oder auch: Steuerung und Monitoring.

Zwar kann ich mit diesen Schlagworten die Grundpfeiler eines jeden Sicherheitskonzeptes zusammenfassen, leider hinkt die Übertragung dieser Thematiken in neue Sicherheitsarchitekturen in der Standardisierung weit hinterher. Ich möchte dies kurz am Beispiel des Bausteins „NET.1.1 Netzarchitektur und –design“ des IT-Grundschutzkompendiums des Bundesamts für Sicherheit in der Informationstechnik (BSI) verdeutlichen.

Direkt in der Einleitung des genannten Bausteins wird nämlich der Geltungsbereich für die aufgeführten Anforderungen auf kabelgebundene Netze eingeschränkt. Das heißt, wer ein Sicherheitskonzept nach IT-Grundschutz pflegt, muss entweder „die Cloud“ als „das Internet“ übersetzen und alle seine Benutzer und Endgeräte über die eigenen kabelgebundenen Netze führen oder auf Basis einer Risikobetrachtung entscheiden, welche Maßnahmen für jeden selbst in einem Baustein „Transformierte Netzarchitektur und –design“ relevant und zur Absicherung der genutzten Dienste geeignet sind.

Hierzu hat sich jedoch in der Praxis gezeigt, dass der existierende Baustein in den meisten Aspekten und Anforderungen auf die geschilderte Situation durchaus übertragbar ist. Denn grundsätzlich beschreibt er, wie eine Kommunikationskontrolle zwischen nicht oder nur eingeschränkt vertrauenswürdigen Netzen und vertrauenswürdigen Netzen aussehen soll. Hier eine Auswahl der Anforderungen in einer sinngemäßen Umformulierung:

• Man habe eine Sicherheitsrichtlinie, wann eine Kommunikation von A nach B mit welchen Techniken abgesichert sein soll.
• Man trenne nicht vertrauenswürdige Netze (z.B. das Internet) von vertrauenswürdigen Netzen mit einer mehrstufigen Firewall-Struktur. Dabei solle man im besten Fall jede Kommunikation zwischen zwei Firewalls entkoppeln, also auf Ebene der Anwendungen terminieren und zielgerichtet – ggf. applikationsweise – kontrollieren und sichtbar machen.
• Zur besseren Kontrolle segmentiere man Netze, also man nehme Firewall-Technologien und stelle sie zwischen Endgeräte und Server, Infrastrukturdienste und ihren Konsumenten, zwischen Administrationsfähigkeiten und die zu administrierende IT, usw.

Diese Anforderungslage ist natürlich übertragbar auf eine Situation, in der alle Benutzer in der Welt verteilt sind und Services konsumieren wollen, die ebenfalls in der Welt verteilt sind. Man benötigt also in den Sicherheitsarchitekturen nur die folgenden Fähigkeiten:

1. Steuerung der Endgeräte und Benutzer bzw. Identitäten von Maschinen und Personen,
2. Applikationskontrolle, im Sinne der Terminierung auf einem Application Layer Gateway (ALG) sowie
3. Steuerungsmöglichkeiten hin zu ausgewählten bzw. abgesicherten Services.

Beispiel: Identitäten und Internet-/Cloud-Zugang

Wir wollen uns zunächst unter dem Gesichtspunkt der Identitätssteuerung die Verfügbarkeit dieser Fähigkeiten in gängigen ALGs anschauen. An dieser Stelle nehmen wir als gegeben an, dass sowohl der Betrieb der verwendeten Endgeräte als auch die Benutzerverwaltung mit Rollen und Berechtigungen zentral verwaltet werden und über standardisierte Wege, beispielsweise mit einem über das Protokoll SAML (Secure Assertion Markup Language) angebundenen Identity-Provider, in den ALGs genutzt werden können. Hierbei möchte ich zunächst den Fall der ausgehenden Kommunikation zu Diensten betrachten, die im Internet bereitgestellt werden.

In der Regel werden Cloud-Dienste über HTTPS realisiert, und somit können sie auch in den meisten Fällen über das für dieses Protokoll spezifische Sicherheitsgateway – einen Forward-Proxy, oder auch Web Gateway genannt – kontrolliert werden. In diversen Artikeln im Netzwerk Insider aus den letzten Jahren wurden die Fähigkeiten, auch von cloudbasierten Lösungen, dargestellt, Nutzer zu dieser Art von ALG zu führen. Die wohl gängigsten Methoden hierzu sind

• die Verteilung von Proxy-Einstellungen über Proxy Automation Configuration (PAC) Files,
• die direkte Anmeldung an einem Proxy,
• das Tunneln allen Web-Verkehrs aus einer kontrollierten Infrastruktur hin zum Proxy oder
• das Ausrollen von Agenten-Software auf den Endgeräten (im übertragenen Sinn sind dies durch die Proxy-Lösung zentral gemanagte „PAC files“).

Alternative Anbindungsmethoden an einen Web-Security-Dienst sind:

• Anbindung an einen klassischen Reverse-Proxy: Hier kommen dann in der Regel Techniken zum Einsatz, die über eine kontrollierte Namensauflösung den Endgeräten statt der IP des gewünschten Dienstes die Proxy-IP verraten.
• Anbindung über VPN-Tunnel: Dies stellt in der Praxis eine Mischung aus den Anbindungsarten „Agent“ und „Tunneln“ dar, da hier dediziert ein VPN-GW hin zum Web-Proxy-Dienst angesprochen werden muss. Soll dies zentral verwaltet werden, bedingt dies meist den Rollout einer Client-Software. Eine moderne Ausprägung der VPN-Tunnel repräsentieren sogenannte Zero-Trust-Network-Access(ZTNA)-Lösungen, die in der Regel im Sinne eines Meshed-VPNs durch mehrere zentral gemanagten Firewall-Instanzen mit mehreren Eingangs- und Ausgangspunkten realisiert sind.

Als Spezialausprägung eines solchen „virtuellen“ privaten Netzes, das dynamisch mehrere Netze verbindet, kann ein Software-Defined WAN (SD-WAN) angesehen werden, das eine Technologie beschreibt, die losgelöst von der Übertragungstechnik (z.B. Internet und MPLS-WAN) ein virtuelles WAN realisiert. Hier kann gegebenenfalls (teilweise) eine direkte Auskopplung von Verkehr in Richtung Internet stattfinden.

Alle diese Fälle haben gemeinsam, dass in der Regel jeder Benutzer durch explizite oder implizite Anmeldung seine Identität preisgibt und dem ALG zur Filterung zur Verfügung stellt. So lassen sich mit den Funktionen moderner Forward-Proxys zielgerichtet Benutzer und Benutzergruppen steuern und Zugriffe auf Services, beispielsweise über eine Applikations-Erkennung oder über URL-Filter, im Internet kontrollieren. Hier hat sich in den vergangenen Jahren, auch was den Funktionsumfang angeht, einiges getan. So lassen sich zum Beispiel auf Basis der Aktionen, die ein Benutzer durchführt, Nutzungsprofile erstellen. Dies geht weit über „welche Webseiten wurden aufgerufen“ hinaus. Man kann ebenso „unnormales“ Verhalten von einzelnen Identitäten feststellen und auf Basis der Erkenntnis weitere Aktionen anstoßen, darunter Blockieren gewisser Zugriffe oder – im Austausch mit dem Verzeichnisdienst – Sperrung des Benutzerkontos. So zählt auch der netzbasierte Schutz vor Schadsoftware, der in den HTTP-Sessions übertragene Dateien auf bekannte Schadprogramme untersucht, mit einer Eskalation an Sandboxumgebungen und einer Einbindung von Sicherheitsintelligenzen zu den Funktionen, die heute meist „nur“ eine Lizenzerweiterung kosten.

Eine zentrale Grundvoraussetzung für die Nutzung vieler dieser tollen Funktionen aus dem Blickwinkel Informationssicherheit betrachtet – Datenschützer sind hier meist weniger euphorisch – ist allerdings geblieben: die Notwendigkeit, die Transportverschlüsselung zeitweise aufzubrechen. Und genau hier zeigt sich das Problem, das in [1] angesprochen wurde: Es unterstützen nicht alle Applikationen, die über HTTP übertragen werden, ein Aufbrechen der Verschlüsselung.

Im Falle von selbst bereitgestellten Diensten über eine Reverse-Proxy-Lösung ist das normalerweise kein Problem. Wenn der Dienst ein SSL-Offloading auf dem Reverse-Proxy unterstützt, kann der Proxy das Ende für den verschlüsselten Verkehr darstellen und alle seine Untersuchungsfähigkeiten zur Geltung bringen.

Für die wohl meisten im Markt genutzten Lösungen zwecks Unified Communication and Collaboration (UCC) ist allerdings schon das bloße Führen über einen Proxy gegen die Empfehlungen der Hersteller. Diese sehen meist so aus, dass man weder SSL-Inspection durchführen noch tiefergehende Analysen des Verkehrs unternehmen sollte, da sonst die Service-Nutzung stark eingeschränkt würde. Führt man auch Latenz-sensitiven Verkehr für Sprach- und Video-Übertragung über einen Proxy, so muss man starke und für die Benutzer direkt bemerkbare Einbußen in der Qualität des Service in Kauf nehmen. Dies liegt oftmals darin begründet, dass ohne direkte Erreichbarkeit der meist im Internet befindlichen Plattformen für die UCC-Lösungen die Applikation für UDP-Verkehr die Fallback-Lösung auf den Endgeräten wählt: die Proxy-Einstellungen des Betriebssystems. Hier werden dann verbindungslose Protokolle über das verbindungsorientierte TCP getunnelt, was in den angesprochenen Qualitätsverlust bei Video und Sprache resultiert.

Die oben beschriebene Anforderungslage im Baustein NET.1.1 fordert nun konkret die Führung über einen Proxy für im Internet befindliche Dienste. Bei strenger Auslegung der Anforderung muss man also mit Qualitätsverlusten leben, oder man findet alternative Wege, das geforderte Maß an Kontrolle bzw. Sichtbarkeit herzustellen. Alternative Wege könnten am Beispiel von Microsoft Teams etwa so aussehen, dass man die in die Microsoft-M365-Plattform integrierten Sicherheitsfunktionen nutzt, also den Verkehr nicht aufbricht und die Sicherheitsfunktionen „am Ende des Tunnels“ anwendet. In [1] wurden Sicherheitsmaßnahmen „am Anfang des Tunnels“ suggeriert, z.B. Sensibilisierung der Benutzer. Ich möchte dies im Folgenden kurz durch alternative Lösungsbausteine erweitern, die sich maßgeblich auf HTTP-Verkehr und Services im Internet beziehen. Die folgenden Maßnahmen sind jedoch genauso auch auf Services im Rechenzentrum, in einer (Virtual) Private Cloud oder bei einem Outsourcing-Dienstleister übertragbar. Dabei spielen Lösungen wie TrustedGate von Rhode und Schwartz zunächst keine Rolle, da sie auch die Übertragung von Video und Sprache nicht dediziert entkoppeln. Die genannte Lösung bricht entgegen der Hersteller-Empfehlung Verkehr von Microsoft Teams auf, entnimmt den Inhalt, verschlüsselt die Informationen und speichert sie verteilt an sicheren Orten ablegen, um anschließend in der Microsoft Cloud einzig Platzhalterinformationen zu hinterlassen. Diese Funktion zur Kontrolle und Änderung von Inhalten bleiben jedoch beschränkt auf Dienste, die nicht zur Übertragung von Video und Sprache vorgesehen sind.

• Zielgerichtete Freischaltung / Ausnahmen von ausgewählten IPs und Protokollen
  Analog zu Ausnahmen für das Split-Tunneling bei VPN-Lösungen können für bestimmten UDP-Verkehr zielgerichtet relevante IP-Pools bei Herstellern etabliert werden, die, ohne über den Proxy geführt zu werden, direkte Routen erlauben. Solche direkten Freischaltungen sollten in der Regel mit weiteren Sicherheitsvorkehrungen eingeschränkt werden. Dazu zählen Anomalie-Erkennung über Firewalls mit Applikationserkennung, Intrusion Detection sowie Endpoint Detection and Response (EDR) auf Endgeräten. Ziel ist es immer, die Kommunikation auf das absolut Notwendige zu beschränken, sie zu überwachen und eine mögliche Ausnutzung der Ausnahme durch Angriffserkennung zu verhindern.

• Aufbau eines dedizierten Sicherheits-Proxys für Applikationen, die ein Aufbrechen der Kommunikation unterstützen.
  Zwar kann gemäß den Vorgaben im Baustein NET.1.1 des BSI-IT-Grundschutzes keine Terminierung und Entkopplung der Kommunikation auf Applikationsebene ohne Einbußen stattfinden, allerdings lassen die Vorgaben dort Freiraum für die Nutzung sogenannter Sicherheits-Proxys. Der Aufbau eines dedizierten Gateways, z.B. einer Next-Generation Firewall, nur für diesen Anwendungszweck als alternativer Sicherheits-Baustein wird an vielen Stellen genutzt, um alle Einschränkungen, die bereits als ergänzende Maßnahmen im ersten Punkt beschrieben wurden, zentral abzubilden. Die Fähigkeiten der Einschränkung, wer (welche Benutzer mit welchen Endgeräten), wie (über welche Protokolle, in welchem Ausmaß, in welcher Regelmäßigkeit, …) auf was (Freischaltung anhand von Applikationserkennung) zugreifen kann, werden häufig durch Sicherheits-Proxys bereitgestellt. Dabei sind die verwendeten Sicherheitskomponenten häufig keine Proxys im ursprünglichen Wortsinn, sondern Protokoll- und Anwendungs-spezifische Gateways.

• Einstufung der Endgeräte als nicht oder eingeschränkt vertrauenswürdig
  Da Endgeräte und Benutzer immer häufiger nicht mehr grundsätzlich als vertrauenswürdig angesehen werden (Stichwort „Zero Trust Architecture“) können diese folglich in einer Sicherheitsarchitektur ebenfalls neu platziert werden. Ein grundsätzlicher Ansatz von Zero Trust ist, dass schützenswerte Dienste immer nur nach vorheriger Authentisierung und kontrolliert durch relevante Sicherheitstechnik verfügbar sind. Endgeräte werden immer weiter von den eigentlichen Daten und den schützenswerten Informationen weggehalten – auch bedingt durch vermehrte Homeoffice-Nutzung und Konzepte wie „Modern Workplace“, in denen sich Benutzer nicht mehr hinter der gleichen Netzadresse verbergen. Virtuelle Desktop-Infrastrukturen oder Terminal-Server unterstützen diesen Ansatz, indem sie die Notwendigkeit für die sichere Bereitstellung von Applikationen auf (mobilen) Endgeräten nicht mehr erfordern.

  Wird nun also ein interner Benutzer bzw. sein Endgerät nicht mehr als grundsätzlich vertrauenswürdig eingestuft, so gelten folglich auch nicht alle Anforderungen für die Anbindung von internen Systemen an das Internet, z.B. nach BSI IT-Grundschutz. Hier gilt es dann eine Risikoanalyse durchzuführen, die bewertet, ob eine direkte Anbindung an die gewünschte Applikation oder auch das Internet grundsätzlich erlaubt ist.

Insbesondere die letzte alternative Maßnahme erfordert es, dass in internen Netzen Fähigkeiten geschaffen werden, Kommunikation auf Basis von Identitäten zu kontrollieren. Mindestens jedoch die Fähigkeiten auf Ebene des Netzes, Identitäten (Endgeräte und/oder Nutzer) zielgerichtet die Kommunikation zu bestimmten Diensten zu erlauben oder zu verwehren.

Rolle von Netzsegmentierung zur Identitätssteuerung

Wie wir gesehen haben, zeigt sich, dass die größten Herausforderungen bei der Steuerung von Identitäten oftmals nicht die Anbindung der Benutzer, sondern die Kontolle der Kommunikation hin zu den Diensten ist. Also will ich im Weiteren kurz beleuchten, welche Möglichkeiten in klassischen Netzen zur Verfügung stehen, Identitäten zu steuern.

Erst einmal muss man festhalten, dass das Netzwerk in der Regel nur einen Beitrag zur Identitätssteuerung liefern kann. In erster Linie erfolgt die „Benutzerkontrolle“ durch Rollen- und Rechtekonzepte auf Ebene der Anwendungen. Nichtsdestotrotz gibt es im Netz an vielen Stellen sinnvolle Möglichkeiten, Identitäten zu erkennen und zu lenken:

• Netzzugangskontrolle (Network Access Control, NAC)

  Eine Netzzugangskontrolle ermöglicht es, dass nur bekannte (Maschinen-)Identitäten Zugang zu Netzen erhalten. Möglichst auf der Basis von IEEE 802.1X soll, nach einer erfolgreichen Authentisierung, ausschließlich bekannten Endgeräten der Zugang gewährt werden (Autorisierung). Hier gibt es nun zur Identitätssteuerung mehrere Aspekte.

  Mit NAC existiert die Möglichkeit, auf Basis der Gruppenzugehörigkeit von Identitäten unterschiedliche Autorisierungsmethoden umzusetzen. So ist es zum einen möglich, dynamisch ein bestimmtes VLAN auf dem Access-Port anzulegen (z.B. Drucker bekommen das Drucker-VLAN). Zum anderen ist es möglich, für gewisse Endgerätegruppen spezifische Access Control Lists (ACLs) auf den Port zu laden, sodass für alle Endgeräte einer Gruppe beispielsweise nur der Zugriff auf Ressourcen im Internet gestattet ist (z.B. per White Listing der Proxy-IP).

  Mit diesen Stilmitteln ist man nun in der Lage, zielgerichtet Kommunikation für einzelne Identitäten im Netz auseinanderzuhalten, beispielsweise durch ACLs auf Server-Switches, oder Firewall-Regeln auf Basis von bestimmten VLANs (z.B.: aus dem Drucker-VLAN darf nur der Print-Server erreicht werden).

  An dieser Stelle sei kurz erwähnt, dass es nicht standardkonforme NAC-Lösungen gibt, die identitätsbasiert agieren. So kann beispielsweise in einer Default-Regel ein Captive-Portal zur Verfügung gestellt werden, das eine Benutzer-Authentisierung verlangt, bevor durch eine Änderung in der Autorisierung die erlaubten Ressourcen im Netz verfügbar gemacht werden. In der Praxis sind diese Lösungen jedoch eher selten verbreitet.

• Remote Access / Fernwartung

  Als nachgelagerte Lösung zu einem VPN-Gateway  ist es mit klassischen Netzwerksteuerungsmaßnahmen (Routing, ACLs, Firewalls) auf Basis von IP-Adressen möglich, den Zugang zu gewissen Zielen zu kontrollieren, zum Beispiel zu einer Fernwartungslösung. Für die Identitätssteuerung bedeutet dies jedoch im Extremfall, dass man je nach Benutzer- oder Nutzergruppe einen dedizierten IP-Pool bereitstellt, mit dem dann in internen Netzen die Kontrolle auf Basis des Authentisierungsergebnisses weitergeführt werden kann.

  Für den Use Case Remote Access hat sich in den vergangenen Jahren allerdings, getrieben durch Anwendungen wie Fernwartung und Fernadministration, eine Architektur etabliert, die auf Basis von Sprungsystemen agiert. Konkret bedeutet dies, dass für die Fernadministration der Zugang zu einem dedizierten Sprungsystem nur gestattet ist, wenn man sich gegenüber dem Netzwerk (bzw. der Fernwartungslösung) angemessen authentisiert hat. Von dem Sprungsystem – wo in der Regel auf Basis des Betriebssystems und/oder der Anwendung eine weitere Authentisierung stattfindet – erlauben dann die Steuerungsmaßnahmen im Netz Zugriffe auf zu administrierende Komponenten. Dies haben Lösungen für das sogenannte Privileged Access Management (PAM) zur Vollendung gebracht, die neben Sprungsystemen meist ein Access Gateway – oft auch VPN-Gateway – mit sich bringen. Benutzer loggen sich dann größtenteils nicht mehr auf den Sprungsystemen ein, sondern werden mit einem technischen User-Account durch das Access Gateway angemeldet und erhalten ausschließlich Zugang zum Stream des Bildschirms oder der Applikation, der/die auf dem Sprungsystem die eigentlichen Aktionen durchführt. Erweiterte Funktionen erlauben dann neben einer Aufzeichnung der Sitzung ebenfalls die Kontrolle der durchführbaren Aktionen. Dies ist insofern ein Netzwerk-Thema, als dass für bestimmte Sprungserver der PAM-Lösung zielgerichtete Freischaltungen in der Infrastruktur erfolgen müssen, damit die gewünschte Identitätssteuerung umgesetzt werden kann.

• Identity-based Filtering in Next-Generation Firewalls (NGFWs)

  Als Gartner den Begriff der Next-Generation Firewalls geprägt hat, bestand eine Anforderung unter anderem darin, dass für die Firewall externe Informationen verarbeitet werden können sollen. In der Praxis hat sich gezeigt, dass die Anbindung an eine API von NGFWs zur automatischen Aktivierung von Firewall-Regelwerken der Hauptanwendungsfall für diese Anforderung geworden ist, meistens durch eine Anbindung an einen Verzeichnisdienst und die identitätsbasierte Filterung.

  Die Umsetzung von identitätsbasierter Filterung in NGFWs gliedert sich maßgeblich in drei grundlegend unterschiedliche Varianten, die wir oben bereits so – oder so ähnlich –für den Proxy gesehen haben:

• Explizite Authentisierung an einem User-Portal, das durch eine NGFW bereitgestellt wird: Je nachdem, welche Netze die gewünschten Ziel-Services beheimaten, muss der Endanwender das richtige Gateway bzw. das richtige Portal aufrufen, und nach erfolgreicher Authentisierung weiß nun die NGFW, hinter welcher IP-Adresse sich der Anwender befindet. Hier besteht die Hauptherausforderung darin, dass man die Firewall direkt ansprechen muss, was aus Sicherheitsperspektive meist vermieden werden soll und dass man als Anwender selbst entscheiden und kontrollieren muss, welchen Weg man durch die Infrastruktur hin zu seinem Ziel-Gateway nimmt.
• Explizite Schnittstelle zu Verzeichnisdiensten: Besteht eine Schnittstelle zwischen dem führenden Verzeichnisdienst und der Firewall, kann auf Basis des Ereignisses einer erfolgreichen Anmeldung eine Zuordnung zwischen Identität und IP-Adresse hergestellt werden. Dann ist die NGFW in der Lage, Identitäten auf Netzübergängen auseinanderzuhalten und zu filtern. In großen Umgebungen kann es jedoch sein, dass es mehrere große Verzeichnisdienste gibt, die alle angebunden werden sollen.
• Auslesen der Ereignis-Logs erfolgreicher Anmeldungen: In manchen Fällen funktioniert die Funktion der identitätsbasierten Filterung dadurch, dass eine Zuordnung von IP-Adresse und Konto stattfindet (Mapping von Quell-IP-Adressen und Konto). Dies hat in sehr großen Netzen den Nachteil, dass von einer IP-Adresse mehrere angemeldete Identitäten kommen können, beispielsweise ein und derselbe Benutzer mit seinem normalen und mit seinem privilegierten Konto.

Mit mindestens einer dieser Techniken besteht fast immer die Möglichkeit, für die Firewalls ein Mapping zwischen der eigentlichen Identität (also dem Benutzer) und der IP-Adresse herzustellen und diese Information auch in einem Regelwerk zu verarbeiten.

Fazit

Seit einigen Jahren weiß man, dass die Sichtbarkeit und das Wissen darum, was an Schadhaftem in IT-Infrastrukturen passieren kann, auch genau vor diesen Angriffsszenarien schützt. Um weiter sicherheitsrelevante Risiken senken zu können, muss die Angriffsfläche auf die Infrastruktur verkleinert werden.

Diese Maßgabe führt dazu, dass man heute nicht nur von Einschränkung und Kontrolle von Kommunikation sowie von Least-Privilege- und Need-to-Kow-Prinzipien spricht. Man geht mindestens gedanklich einen Schritt weiter hin zur Zero-Trust-Architektur, also dem Prinzip, dass nur authentisierte Kommunikation zielgerichtet freigeschaltet bzw. überhaupt erst eingerichtet wird.

Als zentrale Fähigkeit zur Umsetzung einer Zero-Trust-Architektur haben wir die Möglichkeiten von Identitätssteuerung beleuchtet. Wir haben gesehen, dass hierzu Basis-Netztechnologien wie Router und Switches ebenso wie Firewalls und Application Layer Gateways einen Beitrag in der Gesamtarchitektur leisten können.

Allerdings kann sich erst mit den Fähigkeiten zur Applikationskontrolle und -steuerung ein Gesamtbild zur Zero-Trust-Architektur ergeben.

Referenzen

[1] Dr. Behrooz Moayeri; Netzwerk Insider; April 2022; https://www.comconsult.com/der-netzwerk-insider/7hswk81mviq4/#geleit