SDP-Architektur für mehr Netzwerksicherheit implementieren
Wesentlich für einen Software-defined Perimeter ist eine Client-Authentifizierung vor der Verbindung. Gleichzeitig verbirgt SDP die Interna eines Netzwerks vor Außenstehenden.
Software-defined Perimeter (kurz: SDP) ist eine relativ neue Technologie, die im Vergleich zu einem festen Perimeter erhebliche Verbesserungen für die Netzwerksicherheit bietet. SDP-Produkte gibt es noch nicht allzu lange, und der Prozess zur Implementierung der Technologie befindet sich noch in der Entwicklung. In diesem Artikel untersuchen wir SDP-Architekturen und die Anforderungen für ihre Implementierung.
SDP verbessert die Sicherheit des Netzwerkzugriffs erheblich. Das gilt insbesondere für Clients, die mit nicht vertrauenswürdigen Netzwerken verbunden werden. Die Clients sind auf bestimmte Services beschränkt, was die Sicherheit gegenüber einem herkömmlichen VPN erheblich verbessert. Der Rest des Netzwerks ist für Außenstehende nicht erreichbar und unsichtbar.
Einige Befürworter von SDP sagen, das Ganze sei identisch mit dem Zugang per Zero-Trust-Netzwerk, während andere die Unterschiede betonen. Viele der Prinzipien ähneln sich und bedürfen einer sorgfältigen Betrachtung.
SDP kehrt den TCP-Mechanismus um, der lautet: erst verbinden, dann authentifizieren. Stattdessen erfordert SDP eine Authentifizierung vor dem Verbindungsaufbau. Bei dieser Methodik arbeiten die Server nicht mit offenen TCP-Ports und warten auf eine Verbindung. Stattdessen informiert der Controller den Server über eine eingehende Verbindung, nachdem die Authentifizierung durchgeführt worden ist.
Die SDP-Architektur umfasst mehrere Modelle
In einer Veröffentlichung (PDF nach Registrierung) der Cloud Security Alliance (CSA) werden mehrere SDP-Architekturmodelle beschrieben. Organisationen werden mehrere Modelle implementieren, um die von ihnen verwendeten Kommunikationsmethoden zu unterstützen. Alle Modelle verwenden einen zentralen Sicherheits-Controller für die Authentifizierung und Autorisierung von Clients sowie zur Anmeldung von Servern und Diensten.
Das Diagramm (Abbildung 1) zeigt die Client-Server-Architektur von SDP, die zwei der CSA-Modelle abdeckt: das Client-zu-Server- und das Client-zu-Gateway-Modell.
Abbildung 1: Eine Architektur für Software-defined Perimeter.
Der Verbindungsaufbau geschieht in folgenden Schritten:
Jeder Server meldet sich beim SDP-Controller an. Die Server können entweder über eine interne Gateway-Funktion verfügen oder auf ein externes Gateway angewiesen sein.
Die Clients verbinden sich mit dem SDP-Controller, um sich zu authentifizieren, zu autorisieren und die Verbindungsdetails des gewünschten Dienstes zu erfahren.
Die Clients verbinden sich mit einem Server über einen verschlüsselten Kanal, entweder über ein internes Server-Gateway oder über ein externes Gateway.
Mit diesem Modell – bestehend aus Authentifizierungs-Controller, SDP-Softwareagenten und Gateways – kann sich jedes System mit jedem anderen System über einen sicheren Kanal verbinden. Außenstehende können hierbei nichts über die Struktur des Netzwerks erfahren.
Denken Sie daran, dass einige SDP-Dokumentationen Clients als initiierende Hosts und Server als akzeptierende Hosts bezeichnen. Diese Nomenklatur – auch als IH beziehungsweise AH bezeichnet – verdeutlicht die Rollen, wenn ein Server sich mit einem anderen Server verbindet.
Schutz von Anwendungen, Daten und Servern
Es dürfte kaum überraschen, dass eine SDP-Implementierung von einer detaillierten Anforderungsanalyse abhängt. Ihre grundlegende Anforderung besteht darin, die Netzwerksicherheit zu verbessern, was einige Implementierungskriterien erfordert. Letztlich müssen Sie mit potenziellen Anbietern zusammenarbeiten, um die detaillierten Anforderungen an Ihre Implementierung festzulegen.
Sie müssen wissen, welche Anwendungen, Server und Daten Sie unter den SDP-Schutzschirm bringen wollen. Welches Architekturmodell Sie wählen, hängt davon ab, ob es SDP-Agenten für die Client- und Server-Betriebssysteme gibt. In einigen Fällen werden Sie Gateways benötigen, in anderen integrierte SDP-Agenten.
Bestimmen Sie als Nächstes, wo sich die geschützten Anwendungen und Daten befinden. SaaS-Anwendungen müssen möglicherweise durch ein Gateway geschützt werden. Intern entwickelte Anwendungen in der Cloud oder im Data Center des Unternehmens können einen vom Anbieter bereitgestellten SDP-Agenten verwenden.
Ihre Anforderungen sollten sich auf die inhärente Fähigkeit von SDP stützen, die Interna des Netzwerks unsichtbar und für den unbefugten Zugriff nicht erreichbar zu machen, unabhängig vom Standort.
Clients und unterstützende Infrastruktur
Bei der Einrichtung Ihrer SDP-Architektur müssen Sie die verschiedenen Client-Betriebssysteme und deren Standorte bestimmen – etwa im Büro, im Home-Office oder mobil. Auf diese Weise können Sie sicherstellen, dass der SDP-Anbieter clientseitige Agenten für diese Clients bereitstellt. Eine weitere Option ist die Verwendung einer Remote-Desktop-Implementierung auf einem unterstützten Client unter Kontrolle der Organisation.
IoT-Clients benötigen möglicherweise spezielle Proxy Gateways. Prüfen Sie daher, ob diese unterstützt werden können.
Kontrollieren Sie auch, ob sich die SDP-Endpunkte in Ihre vorhandenen Systeme für das Identity and Access Management (IAM) zur Authentifizierung und Autorisierung integrieren lassen. Überprüfen Sie außerdem, wie das SDP-Produkt DNS und andere Netzwerkdienste nutzt. Sie sollten damit rechnen, dass Sie einige kritische Abhängigkeiten finden, die das Gesamtsystem beeinträchtigen könnten, wenn eine Komponente der unterstützenden Infrastruktur ausfällt.
Vorsicht vor komplexer Konfiguration
Die zusätzliche Sicherheit, die SDP bietet, hat ihren Preis: erhöhte Komplexität. Es sind zusätzliche Komponenten und Kommunikationsverfahren erforderlich, um eine erfolgreiche Sitzung aufzubauen. Es gibt eine Client- und Server-Kommunikation mit einem Controller, der selbst ordnungsgemäß funktionieren muss. Einige Architekturen erfordern zusätzliche Gateways als Proxy-Sicherheitsendpunkt für Services, die einen SDP-Agenten umfassen.
Sie müssen die Richtlinien definieren, die die SDP-Systemkonfiguration steuern. Gehen Sie davon aus, dass Sie einige Zeit brauchen, um zu lernen, wie man gute Policies und Konfigurationen erstellt. Genau wie bei Firewall-Regeln kann eine fehlerhafte Policy unbeabsichtigt eine Sicherheitslücke öffnen. Ihr Anbieter sollte Best-Practice-Empfehlungen für das Anlegen geeigneter Richtlinien und Konfigurationen bereitstellen.
SDP-Controller weisen eine interessante Parallele zu VoIP-Anruf-Controllern auf. Es sind nämlich resiliente Designs erforderlich, da sie steuern, wie sich Clients verbinden, und kritische Komponenten eines ordnungsgemäß funktionierenden Systems sind.
Sprechen Sie unbedingt mit Ihren potenziellen SDP-Anbietern über das Management ihrer Systeme, und stellen Sie ihnen die folgenden Fragen:
Lassen sich kritische Parameter mit Ihren vorhandenen Tools überwachen?
Kann das System Syslog-Meldungen an einen Logging-Server senden?
Kann die Protokollierung von Sicherheitsereignissen von den operativen Ereignissen des Controllers und des Gateways getrennt werden, so dass es einfacher ist, Systemprobleme zu identifizieren?
Zusammenarbeit mit Anbietern beim Troubleshooting
Um häufige Probleme in Ihrer SDP-Architektur zu erkennen, sollten Sie lernen, wie Sie den Controller, die Gateways und die Agenten überwachen können. Beschäftigen Sie sich dann einige Zeit mit den Problemen, die die System-Performance beeinträchtigen.
Der Controller wird nicht unbegrenzt viele Verbindungsanfragen bewältigen können. Sie sollten deshalb das Limit kennen, bevor Sie einen kompletten Produktions-Rollout anstoßen. Erstellen Sie außerdem Troubleshooting Runbooks, um den Diagnoseprozess beim Auftreten eines Fehlers gezielt anzugehen. Der SDP-Anbieter kann Anleitungen für häufige Probleme zur Verfügung stellen.
Die zusätzliche Sicherheit, die SDP bietet, hat ihren Preis: erhöhte Komplexität.
Nehmen Sie sich Zeit, um zu verstehen, wie die SDP-Produkte mit Ihren bestehenden Netzwerksicherheitssystemen funktionieren. Es ist unwahrscheinlich, dass Sie in der Lage sein werden, VPN-Konzentratoren, Firewalls und andere Sicherheitssysteme einzusparen. Sie sollten aber sicherstellen, dass durch sie keine Funktionen mehrfach vorhanden sind und dass sie gut zusammenspielen.
Prüfen Sie schließlich noch, ob SDP die Art und Weise ändern wird, wie Sie Anwendungen und die zugehörigen Server überwachen. Wird dafür eine Zugriffs-Policy benötigt, oder ist eine zusätzliche Software erforderlich? Vermeiden Sie es, von den Managementsystemen aus den vollen Zugriff auf die Server zu ermöglichen.
Wie bei jeder neuen Technologie empfiehlt es sich, bei der Einführung schrittweise vorzugehen, das heißt klein anfangen und mit steigender Lernkurve Erweiterungen vornehmen. Ermitteln Sie zunächst spezifische Anwendungsfälle.
Wenn Sie mehr Erfahrungen gesammelt haben, dehnen Sie dann die Implementierung auf weitere Anwendungen und Clients aus. Es wird einiges an Aufwand kosten, einen Proof of Concept zu erstellen, aber es wird die Mühe wert sein. Achten Sie vor allem darauf, wie Sie Probleme in der SDP-Implementierung erkennen und diagnostizieren können. Die zusätzliche Sicherheit bedingt möglicherweise, dass Sie Troubleshooting-Prozesse anpassen.
Erfahren Sie mehr über Identity and Access Management (IAM)
