Für SDN-Sicherheit müssen IT-Teams neben Compliance auch Datenvertraulichkeit, Netzwerkintegrität und die Verfügbarkeit von Netzwerkservices sicherstellen.
Mit SDN das Enterprise-Netzwerk abzusichern, reicht allein nicht aus, wenn es um Software-defined Networking und Sicherheit geht. Es ist wichtig, zu berücksichtigen, wie das Software-defined Network (SDN) selbst gesichert ist, sowie an alle Compliance-Auswirkungen im Zusammenhang mit der Nutzung der SDN-Architektur zu denken.
Die Besonderheiten werden mit dem SDN-Angebot variieren, doch die Prinzipien für die Sicherheit von Software-defined Networking bleiben gleich. Um die SDN-Plattform abzusichern, müssen IT-Teams:
die Vertraulichkeit der Daten im Software-defined Network schützen;
die Integrität des SDN-Systems wahren; und
die kontinuierliche Verfügbarkeit von Netzwerkservices sicherstellen.
Um die Vertraulichkeit vollständig zu schützen, ist es unverzichtbar, den Netzwerk-Traffic zu verschlüsseln. IT-Teams sollten dies auch für den Kontrollkanal in der Umgebung erwägen. Dies umfasst die Kommunikation zwischen einem SDN-Controller und den Data-Plane-Geräten, die Pakete hin und her transportieren.
Falls ein SDN-System über irgendeine Fähigkeit zum Cachen von Daten verfügt – zum Beispiel als Teil eines sogenannten Network Flight Recorders – oder falls es Funktionen zur Datenkomprimierung besitzt, kann es darüber hinaus erforderlich sein, Daten zu verschlüsseln, die im Arbeitsspeicher, ja sogar auf einem Datenträger, in Data-Plane-Geräten oder im Controller abgelegt sind.
Integrität bildet die Grundlage
SDN-Systeme können sich selbstständig vor Angriffen schützen, aber dies erfordert gehärtete Plattformen sowohl für Controller als auch für Data-Plane-Geräte. Wenn der SDN-Controller beispielsweise auf einem schlecht gesicherten Linux-Server läuft, spielt es keine Rolle, wie sicher das SDN-System auf den Knoten auf einer höheren Ebene ist.
Jedes handelsübliche SDN-System sollte standardmäßig eine abgesicherte Basis haben –ganz gleich, ob Linux, CentOS oder etwas anderes. Ebenso müssen Data-Plane-Geräte – sofern sie nach einem Schichtmodell aufgebaut sind, wie einem Low-Level-Switch-Betriebssystem mit einem darauf aufsetzenden SDN-Stack – sowohl auf den unteren wie oberen Schichten des Stacks sicher sein.
IT-Teams müssen sich die Zeit nehmen, das neue Paradigma zu verstehen, und sicherstellen, dass die SDN-Infrastruktur so konform, sicher und zuverlässig ist wie die traditionelle.
Das Software-defined Network kann, natürlich, auf höheren Ebenen an seiner eigenen Verteidigung beteiligt sein. Es sollte zum Beispiel so konfiguriert sein, dass nur Control Traffic vom richtigen Standort aus – dem Controller – fließen darf und nicht von einem beliebigen Server, Laptop oder Smartphone im Netzwerk.
Verfügbarkeit für das Software-defined Network
Netzwerkteams nutzen regelmäßig redundante Switches und Verkabelungswege, um die Verfügbarkeit von Netzwerkservices zu gewährleisten. Das Gleiche gilt für Data-Plane-Geräte mit softwaredefinierter Netzwerksicherheit, aber das Vorhandensein SDN-Controllers erfordert zusätzliche Planung.
Redundanz ist für eine echte Kontinuität notwendig, obwohl die Data Plane, in den meisten Fällen jedenfalls, weiter in ihrer bestehenden Programmierung läuft, wenn ein Controller vorübergehend nicht verfügbar sein sollte. IT-Teams können das Verhalten nicht ändern, bis ein Controller wieder online ist, aber Systeme, die das Netzwerk nutzen, würden den Service nicht verlieren.
Bei einigen SDN-Angeboten ist der Controller eine dedizierte Appliance. In diesen Fällen können IT-Teams eine redundante Einheit erwerben.
In anderen Fällen handelt es sich beim Controller um eine Software, die auf Commodity-Hardware läuft. Die IT kann binnen Minuten eine neue Kopie erzeugen, und eine Live-Migration ist gleichfalls möglich. Um für Kontinuität zu sorgen, könnte die IT auch eine zweite Kopie des Controllers ausführen, je nach dem SDN-Design und der Kostenstruktur entweder in einem Failover mit Hot-Cold-Strategie oder in Form einer verteilten Hot-Hot-Lösung. Darüber hinaus braucht die IT einen Plan für den Fall, dass die Data Plane auf den Verlust eines Controllers oder das Umschalten von einem Controller zu einem anderen reagieren muss.
SDN-Sicherheit: Compliance
Zu guter Letzt müssen IT-Teams gewährleisten, dass sie die Compliance-Anforderungen der Organisation auch in Zukunft erfüllen werden, egal ob es die Datenschutz-Grundverordnung (EU-DSGVO) oder etwas anderes innerhalb des SDN-Paradigmas betrifft. Die IT muss bereit sein, auf Verlangen geschützte Daten, die von einem SDN-System zwischengespeichert werden, zu finden, um Schutzmechanismen darauf zu überprüfen oder definitiv zu bestätigen, dass im Netzwerk keine Daten zugänglich sind.
Abbildung 1: Zu den personenbezogenen Daten im Sinne der EU-DSGVO gehören unter anderem der Name, Standort und die IP-Adresse eines Benutzers.
Gleichfalls muss die IT dafür sorgen können, dass keine Daten an Plätze in der Netzwerkinfrastruktur gelangen, wo sie nicht sein sollten, und sich die Daten an den vorgesehenen Orten befinden. Ferner muss die IT auch in der Lage sein, die Daten zu löschen. Dazu muss sie wissen, welche Informationen das Software-defined Network speichert und für wie lange. Bei einem WAN-Anwendungsfall gehört dazu ebenfalls die Kontrolle, wo diese Informationen geografisch vorgehalten werden.
Die SDN-Bereitstellung im Unternehmen und darauf basierend die SDN-Sicherheit, stehen noch am Anfang. IT-Teams müssen sich die Zeit nehmen, das neue Paradigma zu verstehen, und sicherstellen, dass die SDN-Infrastruktur so konform, sicher und zuverlässig ist wie die traditionelle.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
Nächste Schritte
Sicherheit im Software-defined Network
Diese Kenntnisse benötigen Sie für SDN
Essential Guide: Einführung in Software-defined Networking
Erfahren Sie mehr über Software-defined Networking
