Software-defined Perimeter (SDP)

Wie ein SDP funktioniert

Der SDP-Cybersicherheitsansatz entschärft gängige Netzwerkangriffe und schützt alle Klassifizierungsstufen von Legacy-IT-Assets. Dies gilt unabhängig davon, ob sie sich in der Cloud, On-Premises, in einem Perimeternetzwerk, einem Data Center oder auf einem Anwendungsserver befinden.

Das SDP-Konzept kombiniert Standards des NIST und der Organization for the Advancement of Structured Information Systems (OASIS) – einschließlich Public Key Infrastructure (PKI), Transport Layer Security (TLS), IPsec und Security Assertion Markup Language (SAML) – mit Sicherheitskonzepten wie Federation, Device Attestation und Geolocation.

Ein SDP fungiert als Vermittler zwischen internen Anwendungen und Benutzern, die nur dann Zugang zu Diensten erhalten können, wenn die richtigen Authentifizierungs- und Autorisierungskriterien erfüllt sind. Als Need-to-know-Framework stellt ein SDP nur die Informationen zur Verfügung, die ein Benutzer oder Gerät benötigt – nichts weiter. Deshalb teilt ein SDP keine DNS-Informationen (Domain Name System), interne IP-Adressen (Internet Protocol) oder Informationen zu internen Netzwerk-Ports mit.

SDP-Anwendungsfälle

SDPs verringern die Wahrscheinlichkeit erfolgreicher Netzwerkbedrohungen. Dazu zählen DoS-Attacken (Denial of Service), MitM-Angriffe (Man in the Middle), Port-Scans, Serverschwachstellen und Lateral-Movement-Angriffe, etwa SQL Injection (Structured Query Language) oder Cross-Site Scripting (XSS).

Zu den SDP-Anwendungsfällen gehören auch folgende Punkte:

• SDPs unterstützen eine Vielzahl von Geräten: Der virtuelle Perimeter kann sowohl Laptops und PCs als auch Mobil- und IoT-Geräte (Internet of Things) authentifizieren. SDPs gewährleisten, dass keine Verbindungen von nicht autorisierten oder ungültigen Geräten initiiert werden können.
• SDPs beschränken den breiten Netzwerkzugriff: Einzelne Entitäten erhalten keinen umfassenden Zugriff auf Netzwerksegmente oder Subnetze. Somit dürfen Geräte lediglich auf die spezifischen Dienste und Hosts zugreifen, die per Richtlinie zugelassen sind. Dadurch wird die Angriffsfläche des Netzwerks minimiert und das Scannen von Ports und Schwachstellen durch böswillige Nutzer oder Schadsoftware verhindert.
• SDPs unterstützen eine breiter angelegte risikobasierte Policy: SDP-Systeme treffen Zugriffsentscheidungen auf Grundlage zahlreicher Risikokriterien, darunter Threat Intelligence, Malware-Ausbrüche und neue Software.
• SDPs lassen sich für jegliche Verbindungen verwenden: Die SDP-Technologie ermöglicht die Konnektivität zu ausschließlich den IT-Ressourcen, die von den Mitarbeitern benötigt werden, ohne umständliche Managementanforderungen oder steigende Hardwarekosten.
• SDPs ermöglichen die Kontrolle von Diensten, Anwendungen und Zugriff: SDPs können steuern, welche Anwendungen und Geräte auf bestimmte Dienste zugreifen dürfen. Dies schränkt die Angriffsfläche ein und verhindert, dass böswillige Benutzer oder Malware sich mit Ressourcen verbinden können.
• SDPs sind für die Anwendungsisolierung von entscheidender Bedeutung: Ein SDP, der in einem Enterprise-Rechenzentrum eingesetzt wird, isoliert missionskritische Anwendungsinfrastrukturen und Daten von unbefugten Benutzern. Hacker sind nicht in der Lage, diese Anwendungen zu finden oder zu infiltrieren, da sie durch den SDP getarnt sind.
• SDPs helfen, Public und Hybrid Clouds zu schützen: Mit SDPs können Unternehmen nicht nur Public-Cloud-Instanzen für SaaS, IaaS und PaaS verbergen, sondern auch Hybrid-Cloud-Umgebungen, die sowohl Public als auch Private Clouds

SDP-Architektur

Die SDP-Technologie schafft einen sicheren Perimeter basierend auf Richtlinien, mit denen Dienste von ungeschützten Netzwerken isoliert werden. Sie verwenden das Least-Privilege-Prinzip (Pinciple of Least Privilege, POLP), um Geräte abzusichern. Dadurch erhalten Benutzer und Geräte nur den Zugriff, den sie zur Ausführung der jeweiligen Aufgabe benötigen.

Ein SDP-Framework bietet ein bedarfsorientiertes, dynamisch bereitgestelltes Air-Gapped-Netzwerk – eine Segmentierung von Netzwerkressourcen, die einen physisch definierten Netzwerkperimeter abbildet, aber in Software und nicht über eine Appliance betrieben wird. Dazu werden Benutzer und Geräte authentifiziert, bevor die Benutzer/Geräte-Kombination autorisiert wird, um eine sichere Verbindung zu den isolierten Services herzustellen. Unautorisierte Benutzer und Geräte können sich nicht mit den geschützten Ressourcen verbinden.

Nach Abschluss der Authentifizierung erhalten vertrauenswürdige Geräte eine eindeutige und temporäre Verbindung zur Netzwerkinfrastruktur. Das SDP-Framework ermöglicht es Unternehmen, die Abläufe bei der Benutzerauthentifizierung und der Anwendungssicherheit zu optimieren.

SDP-Architekturen bestehen aus zwei Hauptkomponenten: SDP-Controllern und SDP-Hosts. Ein SDP-Controller bestimmt, welche SDP-Hosts miteinander kommunizieren können. Es gibt sowohl initiierende als auch akzeptierende SDP-Hosts. Ein initiierender SDP-Host kommuniziert mit einem SDP-Controller, um festzustellen, mit welchen Hosts er eine Verbindung aufbauen kann. Ein akzeptierender SDP-Host akzeptiert nur erlaubte Kommunikationsvorgänge und Verbindungen von einem SDP-Controller. Einige SDP-Architekturen verwenden Gateways, die als akzeptierender Host zwischen den beiden sich verbindenden Geräten/Benutzern fungieren.

Verschlüsselte Verbindungen, häufig VPN-Tunnel (Virtual Private Network), zwischen Controllern, Hosts und Gateways gewährleisten die Sicherheit der gesamten Kommunikation und aller Benutzer/Geräte.

SDP-Bereitstellungsmodelle und -Workflows

SDP-Bereitstellungsmodelle lassen sich durch die Art und Weise charakterisieren, wie sie die Interaktionen zwischen Clients, Servern und Gateways strukturieren. Zu den wichtigsten SDP-Ansätzen gehören folgende Modelle:

• Client-to-Gateway-Bereitstellungen positionieren Server hinter einem akzeptierenden Host, der als Gateway zwischen den geschützten Servern und den initiierenden Hosts fungiert. Der Client-to-Gateway-SDP kann innerhalb eines Netzwerks bereitgestellt werden, um Lateral-Movement-Angriffe, wie Exploits von Schwachstellen in Betriebssystemen und Anwendungen, MitM-Attacken und Serverscans, zu reduzieren. Die Bereitstellung kann auch direkt im Internet erfolgen, um geschützte Server von nicht autorisierten Benutzern zu trennen und Angriffe einzudämmen. Dieses Modell eignet sich sowohl für Unternehmen, die Cloud-basierte Anwendungen nutzen, als auch für jene, die On-Premises-Legacy-Anwendungen schützen wollen.

• Client-to-Server-Bereitstellungen ähneln Client-to-Gateway-Bereitstellungen, mit dem Unterschied, dass der durch den SDP geschützte Server das System ist, auf dem die Software für den akzeptierenden Host läuft, und nicht das Gateway. Die Entscheidung zwischen dem Client-to-Gateway- und dem Client-to-Server-Modell basiert in der Regel auf einer Reihe von Faktoren. Dazu gehören die Analyse der Load-Balancing-Anforderungen, der Elastizität der Server (wie anpassungsfähig der Cloud-Server bei Änderungen der Workloads ist) und die Anzahl der Server, die ein Unternehmen hinter dem SDP schützen muss. Dieses Modell ist für Unternehmen mit Cloud-basierten Anwendungen geeignet.
• Server-to-Server-Bereitstellungen schützen Server, die REST-Dienste (Representational State Transfer), SOAP-Services (Simple Object Access Protocol), einen RPC-Aufruf (Remote Procedure Call) oder jede Art von Programmierschnittstelle (Application Programming Interface, API) über das Internet anbieten, vor allen nicht autorisierten Hosts im Netzwerk. Bei diesem Modell ist der akzeptierende Host der Server mit REST, SOAP, RPC oder API. Dieses Modell ist für Unternehmen mit Cloud-basierten IoT- und/oder VM-Umgebungen sinnvoll.
• Client-to-Server-to-Client-Bereitstellungen beruhen auf einer P2P-Beziehung (Peer to Peer) zwischen den Clients. Bei dieser Bereitstellung verschleiert der SDP die IP-Adressen der sich verbindenden Clients, wobei der Server als Vermittler für beide Clients fungiert. Dieses Modell eignet sich gut für Unternehmen, die Anwendungen wie Chat, Video Conferencing und IP-Telefonie
• Client-to-Gateway-to-Client-Bereitstellungen sind Varianten des Client-to-Server-to-Client-Modells. Dieses Modell unterstützt ebenfalls P2P, wobei jeder Client als initiierender Host, akzeptierender Host oder beides fungiert, wenn eine Verbindung untereinander hergestellt wird.

• Bei Gateway-to-Gateway-Bereitstellungen befinden sich ein oder mehrere Server hinter einem akzeptierenden Host. Hierbei agiert der akzeptierende Host als Gateway. Außerdem befinden sich ein oder mehrere Clients hinter einem initiierenden Host, so dass der initiierende Host als Gateway genutzt wird. Dieses Modell ist für vernetzte und IoT-Geräte gedacht, auf denen keine SDP-Clients installiert werden können, zum Beispiel Drucker, Scanner und intelligente Sensoren.

SDP versus VPN

Der häufigste Vorteil eines VPNs besteht in der Möglichkeit, Benutzern und Dritten Remote-Zugriff auf isolierte Netzwerke zu gewähren. Es gibt allerdings zwei massive Sicherheitsrisiken, die VPNs zu einer ungeeigneten Methode für Remote Access auf isolierte Netzwerke und Anwendungen machen:

1. Diebstahl von Zugangsdaten: Dieses Risiko betrifft VPNs in doppelter Hinsicht, denn Menschen neigen dazu, denselben Benutzernamen und dasselbe Passwort für zahlreiche Websites zu verwenden. Da es möglich ist, dass die Anmeldedaten, die Personen für den Zugriff auf ihre Social-Media-Konten nutzen, identisch sind mit denen ihrer VPN-Konten für Remote Access, ist der Diebstahl von Zugangsdaten der häufigste und effektivste Angriffsvektor für Netzwerke.
2. Exzessiver Zugriff: Ein VPN stellt Benutzern einen Teil des Netzwerks zur Verfügung – bei weitreichenden und oft unverhältnismäßigen Zugriffsmöglichkeiten auf Netzwerkressourcen. Dazu zählt die Infrastruktur, wie das Dynamic Host Configuration Protocol (DHCP), DNS, Switches und Router. Dies bietet nicht nur eine große Angriffsfläche für Hacker, sondern erlaubt auch legitimen Benutzern den Zugriff auf weit mehr als die ein oder zwei Anwendungen, die sie tatsächlich benötigen.

Administratoren sollten ihre VPN-Infrastruktur mit SDP-Tools ergänzen. Damit lassen sich Sicherheitsprobleme auch in Hybrid- und Multi-Cloud-Bereitstellungen bewältigen, potenzielle Angriffsflächen reduzieren und wichtige Daten schützen. Mit SDP-Software können Netzwerkadministratoren hochverfügbare Mikroperimeter für Hybrid- und Multi-Cloud-Umgebungen dynamisch bereitstellen, um Dienste für einen feingranularen Nutzerzugriff zu isolieren.

Ein kompromittiertes Gerät ist die größte Herausforderung bei der Verwendung eines Mobiltelefons oder Tablets als VPN-Zugangsgerät. Jedes Gerät, das über ein VPN auf ein isoliertes Netzwerk zugreift, birgt das Risiko, Malware in diese Umgebung einzuschleppen. Beim VPN-Verbindungsaufbau wird der Zustand eines Geräts nicht überprüft. Wenn sich Malware auf einem Zugangsgerät befindet, kann sich die Schadsoftware über das VPN in das gesamte isolierte Netzwerk ausbreiten und dort unermesslichen Schaden anrichten, indem sie zum Beispiel Ransomware installiert. Mit einem SDP werden die Endgeräte von vorneherein als nicht vertrauenswürdig eingestuft.

SDP versus Zero Trust

Das auf Zero Trust basierende Netzwerksicherheitsmodell geht davon aus, dass alle Anwender, Geräte und Transaktionen kompromittiert sein können, unabhängig vom Standort. Daher besteht die Grundlage des Modells darin, niemandem zu vertrauen. Wie ein SDP basiert das Zero-Trust-Modell auf der Annahme, dass herkömmliche perimeterbasierte Sicherheit unwirksam ist.

Die Konzepte von SDP und Zero Trust folgen dem gleichen Grundgedanken, nämlich dass man die Identität einer Person oder eines Geräts überprüfen muss, unabhängig davon, wo sie sich befinden.

SDP ist eine effektive Architektur, um das Zero-Trust-Sicherheitsmodell einzuführen, wobei Zero Trust häufig als die Philosophie hinter der SDP-Architektur bezeichnet wird. Durch die gemeinsame Bereitstellung von SDP und Zero Trust lässt sich gewährleisten, dass das Netzwerk und seine Ressourcen per SDP getarnt sind, während die Authentifizierungsmaßnahmen über Zero Trust erfolgen.