Was ist der Software-Defined-Perimeter?

Die aktuelle Funktionsweise von Netzwerken und der Veränderung der Verkehrsmuster, sowohl intern als auch in der Cloud, begrenzt die Wirkung eines festen Sicherheits-Perimeters.

In der Vergangenheit wurden Netzwerke so konzipiert, dass die interne Segmente immer durch die Perimeter-Sicherheit von der Außenwelt abgetrennt wurde. Das interne Netzwerk galt als vertrauenswürdig, während das externe als feindlich (und somit als nicht vertrauenswürdig) galt. Dieses Konzept stellt jedoch immer noch die Grundlage für die meisten Netzplaner dar, auch wenn sich seit die Netzanforderungen stark verändert haben.

Meistens besteht der feste Perimeter aus einer Reihe von Netzwerk- und Sicherheitskomponenten, was zu einer Hintereinanderschaltung von Appliances führt. Auch variieren typischerweise die Geräte, die ein Benutzer auf dem Weg zum internen LAN passieren muss. In der Regel besteht eine solche Hintereinanderschaltung von Appliances aus globalen Load-Balancern, einer externen Firewall, DDoS-Appliance, VPN-Konzentratoren, einer internen Firewall und den entsprechenden LAN-Segmenten.

Bei der klassischen Perimeter-Lösung basiert das Design auf der Sichtbarkeit und der Zugänglichkeit. Kann eine Entität außerhalb des Netzwerks keine interne Ressource sehen, dann kann kein Zugriff gewährt werden. Folglich wurden externe Entitäten am Eindringen gehindert, während internen Einheiten der Zutritt gestattet wurde. Dieses Konzept funktioniert jedoch nur bis zu einem gewissen Grad. Ein solches starres Abwehrgebilde kann immer durchbrochen werden; es ist nur eine Frage der Zeit. Jemand mit genügend Geschicklichkeit und Ausdauer wird irgendwann durchkommen.

 

Netzwerke verändern sich durch die Cloud und die mobilen Mitarbeiter

In Anbetracht der heutigen Funktionsweise der Netzwerke und der Veränderung der Verkehrsmuster, sowohl intern als auch in der Cloud, begrenzt diese die Wirkung eines festen Perimeters. Heutzutage verfügen die Netzwerk-Perimeter über viele Einstiegspunkte.

Stellen wir uns eine Ritterburg mit einem Fallgatter vor, das für den Zugang benutzt wurde. Der Durchgang durch das Fallgatter war relativ einfach, da wir nur eine Wache passieren mussten. Es gab nur einen Weg hinein und einen Weg hinaus. Heute verfügen wir jedoch über viele kleine Türen und Zugangswege, die alle individuell geschützt werden müssen.

Durch die Einführung von Cloud-basierten Anwendungsdiensten ändert sich die Lage des Perimeters nachhaltig. Daher sind die vorhandenen Netzwerkgeräte, die für den Perimeter verwendet werden, topologisch schlecht positioniert. Heutzutage befindet sich alles, was für das Unternehmen wichtig ist, außerhalb des Perimeters (beispielsweise der Remote-Access für die Mitarbeiter, SaaS-, IaaS- und PaaS-basierte Anwendungen.

Benutzer benötigen auch den Zugriff auf die Ressourcen in verschiedenen Cloud-Diensten, unabhängig davon, wo sich die Ressourcen befinden. Dies führt zu komplexen Multi-Cloud-Umgebungen. Den Benutzern ist es egal, wo sich die Anwendungen befinden. Sie benötigen nur den Zugriff auf die Anwendung. Auch die mobilen Mitarbeitern, die jederzeit und überall auf eine Vielzahl von Geräten zugreifen müssen, stellt neue Herausforderungen an den Perimeter.

Auch eine ständig wachsende Anzahl von Geräten (BYOD, Integratoren, Partner und Dienstleister vor Ort) sorgen letztendlich für eine Welt von übervernetzten Netzwerken.

Übermäßig vernetzte Netzwerke führen zu komplexen Konfigurationen der Netzwerkkomponenten. Dies resultiert letztendlich in großen und komplexen Vernetzungsrichtlinien. Diese sorgen für einen grobkörnigen Zugang zu einer Vielzahl von Diensten, bei denen die IP-Adresse nicht mehr dem tatsächlichen Benutzer entspricht.

Herkömmliche Appliances, die statische Konfigurationen nutzen, um den ein- und ausgehenden Datenverkehr zu begrenzen, gewährleisten die Zugänge häufig auf Informationen im IP-Header bzw. den Portnummern.

Im Wesentlichen sagt eine bestimmte Quell-IP-Adresse, die sich in irgendeiner Richtlinie befindet, wenig über deren Vertrauenswürdigkeit aus, da sich der jeweilige Zugriff dynamisch anhand des Geräts, dem Benutzer und den Anwendungsanforderungen ergibt.

 

Probleme der IP-Adressen

Bereits vor 30 Jahren wurden im RFC 1597 drei IP-Bereiche für den privaten Gebrauch reserviert: 10.0.0.0.0.0/8, 172.16.0.0.0/12 und 192.168.0.0.0/16. Wurde ein Endgerät mit einer dieser Adressen konfiguriert, galt dieses quasi als sicher. Die Praxis hat jedoch gezeigt, dass dies ein Fehlschluss ist.

Das Network-Address-Translation (NAT) hat die Netzwerke drastisch verändert. NAT erlaubte es internen vertrauenswürdigen Hosts, direkt mit den externen nicht vertrauenswürdigen Hosts zu kommunizieren. Da das Transmission-Control-Protocol (TCP) jedoch bidirektional arbeitet, ermöglicht es dieses, dass die Daten von den externen Hosts indiziert werden, während eine Verbindung zu den internen Hosts hergestellt wird.

Außerdem stehen für die an der Verbindung beteiligten IP-Adressen keine Kontextinformationen zur Verfügung. Deren einzige Zweck war in der Vergangenheit die reine Verbindung auf den unteren Schichten. Verfügt man über die IP-Adresse einer Person, kann man sich mit ihr verbinden. Die Authentifizierung wird erst auf einer höheren Schicht im Protokollstack relevant.

Nicht nur die IP-Adressen der Benutzer ändern sich regelmäßig, sondern es gibt auch keine Eins-zu-Eins-Beziehung zwischen den Benutzern und den IP-Adressen. Jeder kann von jeder beliebigen IP-Adresse aus kommunizieren und sich auch mit etwas Geschick im Pfad zwischen mir und einer vertrauenswürdigen Ressource integrieren.

Ich habe schon Netzwerke gesehen, in denen ein 20 Jahre alter Computer auf eine ICMP-Anfrage(reagiert, aber niemand weiß, wo sich dieser Rechner befindet. Da solche Dinge immer wieder in den Netzen vorkommen, können wir uns nicht nur auf die IP-Adressen verlassen und dürfen deshalb nicht erwarten, dass diese mehr Funktionen bereitstellen, als nur die reine Verbindung. Infolgedessen müssen wir uns von den IP-Adressen und dem Netzwerkstandort als Vertrauensbeweis für Ressourcenzugriffe verabschieden.

 

Eine große Lücke ist die Sichtbarkeit

Analysieren wir das Netzwerk und seine Schwachstellen, dann erkennen wir, dass die Transparenz die große Lücke in den heutigen hybriden Umgebungen darstellt. Im Großen und Ganzen sind Unternehmensnetzwerke komplexe Bestien und die Administratoren haben nur geringe Erkenntnisse darüber, wer oder was auf die Netzwerkressource zugreift.

Die IT verfügt nicht über die erforderliche Transparenz, um beispielsweise unsichere Geräte, nicht autorisierte Benutzer und potenziell schädliche Verbindungen zu erkennen, die Malware verbreiten oder mit dem unerlaubten Ausleiten von Daten beschäftigt sind.

Auch wenn wir wissen, wie unsere Netzwerkelemente miteinander entkoppelt werden können, wie stellen wir sicher, dass diese nicht wieder durch eine breitere Definition von Konnektivität miteinander verbunden werden? Dazu benötigen wir eine kontextuelle Sichtbarkeit. Wir benötigen vollständige Transparenz über das Netzwerk, um zu erkennen, wer, was, wann und wie mit den jeweiligen Gerät verbunden ist.

 

Gibt es einen Workaround?

Hierzu ist ein neuer Ansatz erforderlich, der es den Verantwortlichen der Anwendungen ermöglicht, die Infrastruktur in einer öffentlichen oder privaten Cloud und einem lokalen Rechenzentrum zu schützen. Diese neue Netzwerkarchitektur wird als softwaredefinierter Perimeter (SDP) bezeichnet. Die Prinzipien der SDPs sind nicht neu. In einigen Regierungsnetzen wurden ähnliche Netzwerkarchitekturen bereits implementiert. In diesen Umgebungen basiert der Netzwerkzugriff auf einer umfassenden Authentifizierung und Autorisierung. Hier ist typischerweise jede interne Ressource hinter einer Appliance verborgen. Ein Benutzer muss sich zuerst authentifizieren, bevor eine autorisierte Sichtbarkeit der Dienste den Zugriff gewährt.

 

Zero-Trust-Frameworks

SDP ist eine Erweiterung der Zero-Trust-Konzepte, die das implizite Vertrauen aus dem Netzwerk entfernen. Das SDP-Konzept begann mit Googles BeyondCorp. Googles BeyondCorp basiert auf der Idee, dass das Unternehmensnetzwerk keine besondere Bedeutung hat. Das Vertrauen in den Anwendungszugriff wird durch einen statischen Netzwerkperimeter über eine zentrale Appliance erbracht. Diese Appliance ermöglicht den ein- und ausgehenden Zugriff auf der Grundlage einer sehr groben Richtlinie. Der Zugriff auf die Anwendung sollte jedoch auf anderen Parametern basieren. Beispielsweise lassen sich die Fragen („Wer ist der Benutzer“, „Wie ist die derzeitige Sicherheitslage des betreffenden Geräts“, „Wie wird die Session bewertet?“) für einen kontrollierten Zugriff heranziehen.

Seien wir ehrlich, die Annahme, dass der interne Datenverkehr vertrauenswürdig ist, ist fehlerhaft und das Zero-Trust-Konzept geht grundsätzlich davon aus, dass alle vernetzten Rechner über keinerlei Vertrauen verfügen.

 

Was ist ein softwaredefinierter Perimeter (SDP)?

Mathias Hein, Consultant, Buchautor, Redakteur

Ein softwaredefinierter Perimeter hat die Aufgabe, die notwendigen Funktionen für einen dynamischen Perimeter bereitzustellen, der in Clouds, hybride Umgebungen und lokale Rechenzentrumsinfrastrukturen genutzt werden kann. In solchen Umgebungen wird oft während der Sitzung automatisch ein dynamischer Tunnel aufgebaut. Dabei handelt es sich um ein One-to-One-Mapping zwischen der anfragenden Stelle und der vertrauenswürdigen Ressource. Wichtig dabei ist der Umstand, dass die Perimeter nicht mehr einem vorher vom Netzwerkteam festgelegten Standort entspricht.

Ein softwaredefinierter Perimeter stützt sich auf zwei wesentliche Säulen: die Authentifizierungs- und Autorisierungsphase. Ein SDPs erfordern, dass die Endpunkte immer zuerst authentifiziert und autorisiert werden, bevor diese einen Netzwerkzugriff auf eine geschützte Ressource erhalten. Anschließend wird eine verschlüsselte Verbindungen zwischen den anfragenden Systemen und der Anwendungsinfrastruktur hergestellt.

Da die Benutzer und ihrer Geräte, bevor auch nur ein einziges Paket den Zieldienst erreicht, erst authentifiziert und autorisiert werden, sorgt dies für eine sogenannte minimale Privilegierung der Netzwerkschicht. Im Wesentlichen basiert das Konzept der geringsten Privilegien darauf, dass einem Unternehmen nur die minimalen Privilegien gewährt werden, die es benötigt, um die notwendige Arbeit erledigen zu können. Innerhalb eines Zero-Trust-Netzwerks erfolgt die Privilegierung dynamischer als in traditionellen Netzwerken, da viele verschiedene Aktivitätsattribute verwendet werden, um den jeweiligen Vertrauenswert zu bestimmen.

Die Konnektivität basiert auf dem Need-to-know-Modell. Bei diesem Modell werden keine DNS-Informationen, internen IP-Adressen oder sichtbaren Ports der internen Netzwerkinfrastruktur übermittelt. Dies ist auch der Grund, warum SDP-Ressourcen als „dunkle Infrastrukturen“ eingestuft werden. Die Anwendungen und Benutzer gelten als abstrakt, sei es vor Ort oder in der Cloud, was für die zugewiesene Richtlinie irrelevant wird.

Der Zugriff erfolgt direkt zwischen den Benutzern und ihren Geräten auf die Anwendung und die Ressource, unabhängig von der zugrunde liegenden Netzwerkinfrastruktur. Damit wird auch nicht mehr zwischen „innerhalb und außerhalb“ des Netzwerks unterschieden. Letztendlich wird der Netzwerkstandort irrelevant und beseitigt damit das implizite Vertrauen in IP-Adressen.