Managament , Fachartikel

Netzwerke sicher virtualisieren mit Software-defined Networking (SDN)

Netzwerke sicher virtualisieren mit Software-defined Networking (SDN)

Die Ansprüche, welchen unsere IT-Landschaft gerecht werden muss, verändern sich ständig. Agilität ist gerade im digitalen Zeitalter eine der wichtigsten Kenngrößen. Das Virtualisieren von IT-Ressourcen ist aktuell schon als „Best Practice“ zum Erlangen von höchstmöglicher Flexibilität anzusehen. Seit einiger Zeit ist nun auch das Virtualisieren der Netze in aller Munde. Entscheidungsträger sind aufgefordert, diese Architekturen zu bewerten, wenn es darum geht, den vorhandenen Netzwerkinfrastrukturen mehr Flexibilität zu geben oder neue hoch skalierbare Netze zu errichten. Software-defined Networking scheint die vielversprechendsten Lösungen für mehr Flexibilität und Agilität im Netz bereitzustellen. Ob es sich hierbei nur um den Hype einer neuen Netzarchitektur oder eine zukunftsträchtige Lösung handelt, soll dieser Artikel beleuchten.

Im Bereich der IT ist die Virtualisierungstechnik längst nicht mehr neu. Schon in den 60er Jahren experimentierten Hardwarehersteller wie IBM mit virtueller Speicherverwaltung zur Partitionierung von Ressourcen in deren Mainframes. Das ermöglichte ein quasi Multitasking und somit ein beinahe paralleles Rechnen. Virtualisierung beschreibt ein Verfahren in der IT, Rechentechnik zu abstrahieren und konsolidiert durch eine Virtualisierungssoftware auf physikalischen Maschinen zu reproduzieren. Auf einem physikalischen Rechner können so mehr als ein Betriebssystem parallel und voneinander gekapselt betrieben werden, obwohl sie sich die Hardware-Ressourcen teilen.

Der Virtualisierung der IT-Infrastruktur wird zukünftig eine immer größer werdende Bedeutung zukommen. Während ein Softwareprodukt durchschnittlich sechs Monate Entwicklungszeit benötigt, wird für ein vergleichbares, in Hardware umgesetztes Produkt, mehrere Jahre Entwicklung benötigt. Der Vorteil der kürzeren Entwicklungszeit beeinflusst Entscheidungsträger bei der Wahl der Mittel und wird so die Virtualisierung weiter vorantreiben. Der daraus resultierende finanzielle Vorteil gegenüber traditioneller Betreibertechnik wird der größte Treiber sein. Nach der mittlerweile etablierten Client/Server/Storage-Virtualisierung wird nun der nächste Schritt, hin zur Virtualisierung der Netzwerkinfrastruktur folgen.

So sollte gerade im Bereich der Automation und der flexibleren Administrierbarkeit ein Schritt nach vorn gegangen werden. Eine zentrale Steuerung der IT-Netzwerkinfrastruktur ist, nicht zuletzt aufgrund der angespannten personellen Lage bei den meisten Unternehmen, von enormer Bedeutung. Durch bessere Kontrollmöglichkeiten soll die Revisionsfähigkeit erhöht werden. Benötigt wird auch eine Steigerung der Leistungsfähigkeit und der Skalierbarkeit im Netzwerk. Auch muss die Fähigkeit der bereits vorhandenen Netzwerkgeräte überprüft werden, SDN nutzen zu können. Sollte das nicht der Fall sein, muss geprüft werden, ob es grundsätzlich möglich ist und wie hoch der Aufwand ausfällt, die Geräte auf die neue Architektur zu migrieren. Allgemein muss die neue Architektur den zukünftigen Anforderungen gewachsen sein. Dazu zählen die ständig wachsenden Anforderungen der Benutzer an die Antwortzeiten der genutzten Applikationen, die stetige Steigerung der Anzahl der Benutzer, welche über das Netzwerk auf Dienste zugreifen und eine Dynamisierung der Applikationsarchitekturen. Das bedeutet auch das Betreiben von Netzwerk verteilten Applikationen. Ferner muss das Netzwerk dem Wachstum der systembedingten Kommunikation durch die allgemeine Virtualisierung standhalten können. Und nicht zuletzt, die erhöhten Anforderungen an die technischen Antwortzeiten durch die Systemkomponenten selbst (Netzwerk-Overhead).

Grundlagen SDN

Welche Philosophie verbirgt sich hinter SDN? Im Großen und Ganzen geht es um Erhöhung der Flexibilität im Netz und Minimierung von Kosten. Ganz neu ist die SDN-Philosophie nicht. Schon in den Achtzigern lief auf spezialisierten Unix-Systemen Software für das Routing von Datenpaketen unter einer abgekoppelten Kontrollinstanz. Seit den frühen Neunzigern versuchten Firmen wie Enterasys Networks im experimentellen Stadium in ihren Netzwerkkomponenten die Kontroll- von der Datenebene zu trennen. Um die Jahrtausendwende verwarf man die Idee zwischenzeitlich, da der benötigte Durchsatz nicht erlangt wurde, um einen Vorteil gegenüber der herkömmlichen Paketübermittlung zu erreichen. Dank der heutigen Rechen-technik ändert sich das nun. Um den Unterschied zu traditionellen Netzwerken darzulegen, ist zunächst ein Blick auf die Technik der herkömmlichen Netzwerkinfrastruktur nötig.

Ein Router oder Switch sind speziell für eine bestimmte Anwendung entworfene Geräte. Auch diese bestehen aus einer Control- und Dataplane. Um Funktionsrobustheit und Schaltgeschwindigkeit zu maximieren, setzen Hersteller seit den 80er Jahren ausschließlich auf die Verwendung von applikationsspezifischen integrierten Schaltkreisen, sogenannten ASICs, kompakte Chips, in denen, fest verdrahtet, die Funktionalitäten der Komponenten eingebrannt sind. Dies garantiert schnellstmögliche Paketbearbeitung, senkt allerdings die Flexibilität auf ein Minimum. Jedes Gerät wird proprietär vom Hersteller auf seine fest eingerichteten Funktionen festgelegt und muss zusätzlich noch vom Anwender für den vorgesehenen Betrieb konfiguriert werden. Um die Barriere der Inflexibilität zu durchdringen, wurde nach Ansätzen geforscht, welche herkömmliche Netzwerktechnik dynamischer gestalten lässt. Einer dieser Ansätze ist die Nutzung von SDN.

Die Idee um SDN ist schon ein paar Jahre alt. In seiner Doktorarbeit an der Stanford University, beschrieb Martin Casado im Jahr 2008 die Idee der logischen Trennung von Kontrollmechanismen und Datenfluss. Er gilt somit gemeinsam mit seinen Betreuern Nick McKeown, Scott Shenker und Dan Boneh als Vater dieser Architektur.

Eine herkömmliche physikalische Netzwerkinfrastruktur ist ein relativ starres physisches Konstrukt aus Switches, Routern, Kabeln und Endgeräten. Netze lassen sich informationssicher komfortabel überwachen und es ist relativ einfach, Konfigurationen oder Log-Dateien auszulesen, einzuspielen und grafisch darzustellen. Allerdings müssen die unterschiedlichen Komponenten für sich konfiguriert und administriert werden. Eine Zentralisierung und Konsolidierung ist nicht, oder nur ansatzweise möglich. Infrastrukturelle Änderungen sind aktuell in vielen Unternehmen ein mittelgroßes bis großes Projekt, begleitet vom drohenden Totalausfall, wie beispielsweise beim Umbau bzw. der Umkonfigurierung der produktiv verwendeten Geräte. Der höchst mögliche Grad an Flexibilität wird aktuell in statischen Netzwerken mit der Erzeugung von VLANs bzw. VPNs erreicht. Beide Technologien überschneiden sich funktional und haben die gleichen Ziele - die Agilität und Sicherheit eines Netzwerkes zu erhöhen. Das wird erreicht, indem bei beiden “Packet Encapsulation“ für das Routen in einem physikalischen Netzwerk genutzt wird. Doch da, wo die technischen Möglichkeiten der Separierung durch VLANs aufhören, beginnen die Funktionalitäten eines SDN erst.

Die technische Realisierung von SDN

Wie kann sich der Anwender die SDN-Funktionalität vorstellen? In einem traditionellen Netzwerk, welches überwiegend aus physischen Netzwerkkomponenten besteht, muss jede Instanz bei Einbau und Veränderung, für sich an das Netzwerk angepasst werden. Über Konfigurationen, welche in jedem Switch und jedem Router separat implementiert werden, kann der Netzwerkverbund miteinander interagieren. Jede Komponente beinhaltet so eine eigene Zentrale, die über den Umgang mit ankommenden und abgehenden Datenpaketen entscheiden muss. Alle Geräte sind grundsätzlich hierarchisch gleichgestellt. Eine Priorisierung gibt es nur bezüglich einiger Protokolle, wie beispielsweise bei OSPF oder BGP. Ändert sich nun beispielsweise die Unternehmensstruktur, was in der Regel auch den Umzug der Mitarbeiter beinhaltet, werden meist neue Anforderungen an die Netzwerkinfrastruktur gestellt. Zugänge müssen verändert, Ports gesperrt und andere freigeschaltet werden. In einem physikalischen Netzwerk ist es nötig, jede betroffene Komponente den neuen Ansprüchen händisch anzupassen und die Konfiguration zu ändern. Das erfordert mitunter erheblichen Zeitaufwand bei der Administration und verursacht somit unnötige Kosten. Die SDN-Architektur kann hier für Abhilfe sorgen. Durch eine Trennung von Daten- und Kontrollebene wird es möglich, eine übergeordnete Instanz (SDN-Controller) zu schaffen, welche die Schalt- und Entscheidungsprozesse für alle, sich im Netzwerk befindlichen aktiven Komponenten übernimmt. 

Abbildung-1: SDN-Controller-Architektur

<next>

Der SDN-Controller stellt die Plattform für alle als Netzwerkapplikationen laufenden Netzwerkfunktionen dar. In den Applikationen wird der ein- und ausgehende Datenfluss geregelt. Nicht an eine bestimmte Form gebunden, kann ein SDN-Controller auf einem physischen Server, einer Virtuellen Maschine (VM) oder auf einem eigens zu diesem Zweck gebauten Gerät arbeiten. Zur Schaffung von Redundanzen können und sollten SDN-Controller mehrfach parallel betrieben werden. Das ist dringend notwendig, da beim Betrieb von nur einem SDN-Controller im Falle dessen Ausfalls ein „Single Point of Failure“ existiert. Im sogenannten East-West-Betrieb wird so über einen Controllerverbund Hochverfügbarkeit erreicht. Wichtig ist hier, dass schon durch Redundanzkonzepte für zusätzliche Sicherheit gesorgt wird. Das Orchestrierungssystem und die SDN-Steuerung sind grundlegende Elemente jedes neuen Netzwerkdesigns. Hat sich der Betreiber für eine Lösung entschieden, legt er damit auch die Auswahl der Hypervisoren, Netzwerkkomponenten und weiterer Technologien fest. 


Abbildung-2: Schnittstellen des SDN-Controllers

North- und Southbound-API

Wie schon beschrieben, ist SDN eine Stapel-Architektur. Die Steuerung des Netzwerkes obliegt einzig dem übergeordneten Controller. Mehrere, zu einem Cluster geschaltete Controller, ermöglichen einen hoch performanten Controllerverbund. Um Hochverfügbarkeit (HA) zu erlangen, werden die Controller über herstellerspezifische Schnittstellen per East-West-API verschaltet und Master-Slave-Rollen zugewiesen. Die Trennung zwischen der Netzwerk- und der Applikationsebene werden mit Hilfe des North- und des Southbound-API erreicht. Ein offenes, frei programmierbares API stellen die Grundlage einer erfolgreichen SDN-Architektur dar. Nur ohne proprietäre Zwänge lässt sich die Funktionsvielfalt dieser Architektur vollends ausschöpfen. Dadurch ergeben sich die zukunftsträchtigen Vorteile der SDN-Architektur: Agilität, Sicherheit, Stabilität und Skalierbarkeit.

Über das Northbound-API oder auch Northbound Interface (NBI) erfolgt die Integration mit anderen IT-Applikationen. Es stellt die Brücke zur Abstraktion des Netzwerkes für die Applikationen und Verwaltungssysteme dar. Hier lassen sich Werkzeuge programmieren, welche wichtige Funktionen innerhalb einer produktiven Netzwerkinfrastruktur übernehmen. Beispielsweise können so komplexe Next Generation Firewall, Routing, Loadbalancing und viele andere Funktionen über das NBI angebunden werden. Im Gegensatz zum Southbound-API ist für das NBI aktuell noch kein Standard vorhanden. Doch das soll sich ändern. Mit dem OpenDaylight-Projekt haben ca. 48 beteiligte Firmen (Stand Feb. 2015) einen Quasi-Standard auf den Markt geworfen. Seit 2012 bemüht sich die Open Networking Foundation (ONF) mit ihren über 100 Mitgliedsfirmen eine offizielle Standardisierung voranzutreiben. Im Jahre 2013 gründete sich dafür die „Northbound Interface Working Group“. Eine Task Force, welche sich zunehmend um die fehlende Standardisierung kümmern soll.

Damit soll ein unkontrolliertes Schnittstellenprogrammieren auf dem immer größer werdenden App-Markt für NBI-Applikationen verhindert werden. Diese sind für den Betrieb eines SDN von vitaler Bedeutung. Ohne über das NBI verfügbare Applikationen, wäre jedes noch so große SDN-Netzwerk unbedeutend in seiner Funktionalität. Die Agenda für 2014 bestand bisher allerdings nur daraus, eine Vorschau der NBI-Architektur und zwei Use Cases zu erstellen und einzupflegen.

Das Southbound-API ist die Schnittstelle, die es dem SDN-Controller ermöglicht, das Verhalten der Switches im unteren SDN-Stack zu definieren. Hier wird die Kommunikation mit der physikalischen Infrastruktur geregelt. Durch das OpenFlow-Protokoll, welches alle in der ONF mitwirkenden Unternehmen zum Standard deklariert haben, ist die Art der Kommunikation mit den Switches weitestgehend festgelegt. Allerdings ist dank des OpenSource-Ansatzes in der SDN-Architektur dieser Standard kein Muss. Der nicht an der ONF beteiligte Anbieter Enterasys Networks nennt als valide Alternativen für Southbound APIs beispielsweise SNMP, NETCONF, XMPP oder RADIUS. Aber auch die an der ONF beteiligten Unternehmen setzen nicht ausschließlich auf OpenFlow. Juniper und Arista Networks implementieren in ihre SDN-Komponenten bereits seit geraumer Zeit das Protokoll XMPP.

Die Programmierbarkeit von SDN

Einer der Vorzüge, sich für eine Umwandlung der traditionellen Netzwerke in ein SDN stark zu machen, ist die schon angesprochene Programmierbarkeit. In Richtung Norden, also über das Northbound-API lassen sich Funktionen wie ein Loadbalancer, DNS, IDS/IPS oder ein Monitoring-System für den virtuellen Einsatz im SDN programmieren. Hier ist der Entwickler nur von den Vorgaben des Frameworks limitiert. Das heißt, je nachdem welche Programmiersprachen vom Controller unterstützt werden, kann hier nach eigener Fähigkeit entwickelt werden. In Richtung Süden, über das Southbound-API ist die Limitierung schon deutlicher zu verzeichnen. Da hier Standards die Kommunikation mit der physikalischen Infrastruktur regeln sollen, muss der Anwender schon auf die bestehenden vom Hersteller vorgegebenen Protokolle zurückgreifen. In der Regel handelt es sich dabei um das OpenFlow-Protokoll.

Proprietäre Anbieter wie Juniper, VMware, Arista Network oder Brocade nutzen eigene, nicht freie Protokolle wie XMPP. Ein weiterer Vorteil der Programmierung ist, dass die Konfigurationen nicht mehr zwingend von reinen Netzwerkern vorgenommen werden müssen. Dafür steht eine Reihe von Werkzeugen zur Verfügung, welche den API-Programmierer unterstützen. Das ist einer der entscheidendsten Vorteile von SDN. Zur Implementierung neuer Funktionen musste bisher aufgrund der fest verdrahteten ASICs immer neue Netzwerk-Hardware entwickelt werden. Mit dem Einsatz von SDN, beschäftigt heute ein Unternehmen Programmierer, welche das gewünschte Upgrade in einem Bruchteil der bisherigen Entwicklungszeit entwickeln können.

<next>

 

In der traditionellen Netzwerkumgebung sind Switches zumeist vielfach vorhanden. Und doch ist jeder einzelne, für sich betrachtet, ein Unikat. In der Regel wird der einzusetzende Switch mit einer Grundkonfiguration bespielt und dann für seine ganz spezielle Aufgabe feinkonfiguriert. Je mehr Funktionen ein Switch bereitstellt, desto teurer ist er in der Anschaffung. Zusätzlich dazu werden Switches in sogenannte Leistungsklassen unterteilt. Hier unterscheiden Hersteller den maximal vom Switch zu leistenden Durchsatz (Bits pro Sekunde). Grundlegend anders verhält sich die Wertigkeit eines Switch in einem SDN. Hier muss ein Switch kaum noch Fähigkeiten mitbringen. Zum Betreiben eines SDN sind nur noch Standard-Switches notwendig. Angeboten werden hier, gerade um die SDN-Philosophie zu unterstützen, sogenannte White-Box-Switches. Im Gegensatz zu den Black-Box-Switches lassen sie sich vom Anwender mit nur den, für die jeweilige Funktion benötigten, Applikationen bespielen. Einzig die Datenpakete, welche er vom SDN-Controller zugesandt bekommt, muss der Switch an den im Header eingetragenen Port ausliefern. Dafür nutzt er eine sogenannte Flow- oder Forward-Tabelle, in die er die Anweisungen vom SDN-Controller speichert und abarbeitet. Hier ist schon ersichtlich auf was es bei einem SDN-geeigneten Switch ankommt.

Da die einzig wichtige Funktion die Weiterleitung der Pakete ist, muss der Switch eine große Anzahl davon in geringster Zeit bewältigen können. Die Unterscheidung in den Leistungsklassen von SDN-fähigen Switches bezieht sich hier auf die Aktionen pro Sekunde (Flows/s). Switches neuerer Generationen sind problemlos in der Lage, mehrere Hundert Millionen Flows/s zu verarbeiten. Switches, welche das OpenFlow-Protokoll unterstützen, werden als OpenFlow enabled bezeichnet. Diese Switches können sowohl OpenFlow-Pakete weiterleiten, als auch traditionellen Netzwerkverkehr steuern. Sie fungieren als Hybrid-Switch. Lediglich ein zusätzlicher Treiber ist nötig, um SDN-Funktionalität herzustellen. Allerdings sind ältere noch existierende Switches zumeist nicht SDN-fähig. Um einen SDN-fähigen Switch in den OpenFlow-Modus zu versetzen, muss auf diesem das Protokoll aktiviert (enabled) werden. 


Abbildung-3: OpenFlow Paket und Flow Tabelle

Vor- und Nachteile der SDN-Architektur

Grundsätzlich ist ein Software-definiertes Netzwerk ein großer Schritt in Richtung Agilität für ein Unternehmen. Wie bei jeder neuen Technologie gibt es allerdings nicht nur vorantreibende Punkte, sondern auch Risiken und Gefahren, die Beachtung finden müssen. Je nach Komplexität der bisherigen Infrastruktur fallen die Auswirkungen der Vor- und Nachteile größer oder kleiner aus.

Vorteile der SDN-Architektur

Der schnelle und detaillierte Überblick über ein Netzwerk ist für die Betreiber, aufgrund von Verfügbarkeit, Performance und Stabilität des Netzes, essentiell. Mit der Möglichkeit der konsolidierten Netzwerk-dokumentation durch das einfache Auslesen der Gesamtstruktur aus dem SDN-Controller, lassen sich simpel auch komplexe Netzwerkstrukturen darstellen. Weiter lassen sich mit Hilfe von SDN schnell und unkompliziert Netzsegmente und Funktionen im Netzwerk testen, ohne die produktive Umgebung verändern zu müssen oder zu beeinflussen. Eingesetzte Switches können einheitlich und von einfachster Bauart sein. Preiswerte White-Box-Switches sind für den Einsatz in einem SDN prädestiniert. Eine Unterscheidung findet nur noch in den Leistungsklassen nach Flows pro Sekunde statt. Hier kann je nach Notwendigkeit ein Netzsegment hoch oder runter skaliert werden. Insgesamt heißt das, ein SDN mit gleichwertiger Funktionalität erzeugt deutlich weniger Betriebskosten durch weniger gebundene Ressourcen. Auch lässt die Programmierbarkeit des Netzes ein Unternehmen schneller auf notwendige Veränderungen reagieren. Die Steuerung des kompletten Netzwerkes wird komfortabel von einer zentralen Stelle aus betrieben. Datenströme können auf Knopfdruck umgeleitet werden. So kann beispielsweise eine intelligente Netzwerksicherheit implementiert werden, die automatisch verdächtige Pakete einer Deep Paket Inspection unterzieht. Interner East-West-Datenverkehr ist nicht gezwungen, starre Wege zu durchlaufen, sondern kann über kürzeste Routen geführt werden.

Ein weiterer wichtiger Vorteil ist, dass zur Umsetzung von SDN in modernen Netzen die im Unternehmen vorhandene herkömmliche Switchingarchitektur nicht ausgetauscht werden muss. SDN wird als „Overlay-Network“ einfach auf die bestehende Hardware aufgesetzt. Auf Wunsch kann im bestehenden Netz auch eine hybride Architektur gefahren werden, welche traditionelle und SDN-Architektur parallel bereitstellt. So kann nach und nach in ein reines SDN migriert werden.

Nachteile der SDN-Architektur

In einem traditionellen Netzwerk registriert ein angrenzender Server/Rechner oder Switch den Ausfall einer Netzwerkkomponente und leitet in der Regel Maßnahmen ein. In einem SDN ist der Anwender hier auf zusätzlich bereit gestellte Applikationen angewiesen, welche ein komplettes Monitoring des vorhandenen Netzwerkes vornehmen und damit beispielsweise den Ausfall eines SDN-Switches anzeigt.

Ein einzelner SDN-Controller ist immer auch ein Single Point of Failure. Mit dem Betrieb von nur einem Controller ist eine Hochverfügbarkeitsanforderung nicht zu erfüllen. Kompensation wird nur über das Clustern mehrerer Controller erreicht, was wiederum die Komplexität der SDN-Programmierung erhöht, da der notwendige Austausch von Konfigurationsdaten unter den Controllern, eine zu programmierende Synchronisation erzeugt. Die dadurch gesteigerte Systemkommunikation der redundanten Controller erzeugt einen beträchtlichen Overhead, welcher zusätzliche Flows erzeugt. Die übergeordnete Orchestrierung macht das Erstellen von netzwerkweit geltenden Regeln und Rollen nötig. Ein weiterer Nachteil ist das noch relativ geringe Alter der Architektur SDN. Die Technik dazu steckt allgemein noch in den Kinderschuhen. Mit größeren wie kleineren Problemen müssen Anwender hier grundsätzlich rechnen. Nimmt man den sogenannten Badewanneneffekt zur Hilfe, befindet sich die Technologie um SDN noch am Anfang des ersten Drittels. Wirklich marktreife Entwicklungen für interessierte Unternehmen erscheinen noch relativ zögerlich. Im Allgemeinen ist die Architektur für Verantwortliche noch ein schwer kalkulierbares Investment.

Um die Funktionsweise von SDN zu verstehen und die neuen Netze sicher administrieren zu können, bedarf es zusätzlicher Ausbildung. So ist ein Unternehmen, welches sich für den Einsatz eines SDN entschieden hat, aufgerufen, seine Administratoren zusätzlich zu schulen.

Network as a Service (NaaS)

In den „Clouds“ ist die Netzwerkvirtualisierung mittlerweile angekommen. Durch SDN wird einem Cloud-Provider, zusätzlich zu den verankerten „as a Service“ Diensten ermöglicht, dem Kunden komplette virtuelle Netzwerkinfrastrukturen (NaaS) zur Verfügung zu stellen. Dieser meldet sich lediglich über eine API / RESTfulAPI bei einem Dienst seiner Wahl an, und hat dann die Möglichkeit, aus einer Vielzahl von Kennwerten, eine abstrahierte Netzwerkverbindung zusammenzustellen. Gewählt werden können hier Features wie, Ein- und Ausstiegspunkt, Bandbreite, Verschlüsselung, Routen, Quality of Service Parameter und viele andere Dinge, welche sich auch bei einem „realen“ Netzwerken konfigurieren lassen. Abgerechnet wird der Kunden hier jeweils anhand der übermittelten Daten (Volumen) oder nach Bereitstellungsgrad (Reservierung). Die angemieteten Verbindungen lassen sich flexibel skalieren. So kann sich der Kunde auf jede kurzfristige Veränderung schnell und unkompliziert einstellen.

<next>

 

Absicherung der virtuellen Netzwerkinfrastruktur

Für den Schutzbedarf eines IT-Netzwerkes stehen die drei Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit. Zusätzlich zur herkömmlichen Absicherung der Netzwerkkomponenten muss auch das SDN den Sicherheitsansprüchen genügen. Um eine hohe Verfügbarkeit des Netzes garantieren zu können, muss der SDN-Controller, als „Single Point of Failure“, unbedingt redundant ausgelegt werden. Zwei oder mehr Controller müssen dazu im East-West-Verbund verschaltet sein. Viele Anbieter bieten die Möglichkeit an, die Controller für eine hohe Verfügbarkeit in Clustern zu betreiben. Hierfür wird ein Controller zum Master erkoren und die übrigen als Slave betrieben. Im Fehlerfall des Masters übernimmt der rangniedrigere Slave-Controller die Funktion des Masters. Das Umschalten sollte hier möglichst schnell vonstattengehen um nicht bearbeitete Flows zu vermeiden.

Der SDN-Controller ist der sensibelste Punkt in einem SDN-Konstrukt. Sollte dieser kompromittiert werden, ist die Integrität des kompletten Netzwerkes verloren gegangen. Über einen kompromittierten Controller kann ein Angreifer, die sich im Netz befindlichen Switches, beliebig manipulieren. Um das zu verhindern, muss dringend für die bauliche Sicherheit gesorgt werden. Ein SDN-Conroller gehört immer hinter eine verschlossene Tür, zu der nur ausgewähltes Personal der Zugang ermöglicht  wird. Weiter ist für die Sicherheit beim physikalischen und elektronischen Zugriff auf den Controller zu sorgen. Der Zugang muss mit starken Passwörtern versehen werden. Über Rollenkonzepte und das Logging kann jede Änderung der Konfiguration nachvollzogen und bei Problemen zurückgeschrieben werden.

An festgelegten Knotenpunkten im virtuellen, wie auch im physikalischen Netzwerk, sollten Sensoren für ein IDS/IPS verteilt sein. So ist es automatisiert möglich, Angriffe auf das Netz zu erkennen und gegebenenfalls abzuwehren. Weiter kann so die strikte Trennung der virtuellen LANs überwacht werden. Dieses ist höchst wichtig zum Gewährleisten der Mandantenfähigkeit. SDN gestaltet das Zusammenspiel zwischen Netzwerk und Sicherheitslösungen dynamischer und effizienter. So kann zum Beispiel die Erkennung und Abschwächung von DDoS-Angriffen (Distributed Denial of Service) in einem SDN erheblich besser automatisiert werden als in traditionellen Netzwerken.


Abbildung-4: Abwehr einer DDoS-Attacke in einem SDN

In der Abbildung ist sehr deutlich der Vorteil dargestellt, den ein SDN gegenüber einem traditionellen Netzwerk bietet. Eine Sicherheitsapplikation des hier verwendeten sFlow-Protokolls sorgt dafür, dass DDoS-Angriffe schnellstmöglich erkannt und abgewehrt werden. Identifizierte Pakete des Angreifers, werden so umgehend geblockt.

Das komplette Netz kann über Monitoring-Systeme visualisiert werden. So kann, zum Beispiel mit der Verwendung einer Ampeldarstellung, schnell auf Ausfälle reagiert werden. Sogenannte “most talker“ können zielsicher identifiziert und gegebenenfalls separiert  bzw. deaktiviert werden, wenn sie als gefährdend für die Verfügbarkeit des Netzes eingestuft werden. Auch komplexe Firewall-Systeme können durch SDN-Anwendungen übernommen werden. So ist es nur eine Frage der Programmierung, welche Sicherheitssysteme zukünftig durch Applikationen in einem SDN übernommen werden können. Aktuell kristallisiert sich hier ein Ableger von SDN, welcher immer wieder in den Fachmedien diskutiert wird und sich fast ausschließlich um Sicherheitsaspekte bemüht. Das sogenannte Software-defined Protection/Security (SDP/S). Hier bleibt abzuwarten, in wie weit sich einzelne Facetten der Architektur etablieren werden.

Ausblick

Zunehmend versuchen Anbieter von SDN-Lösungen massiv Kunden für sich zu gewinnen und reagieren auf jede Bewegung am SDN-Markt.

Die Zeichen stehen eindeutig auf Netzwerkvirtualisierung. Im Moment liegt der Fokus für SDN eher bei der Nutzung im Rechenzentrum, als in der eines Unternehmens-LANs. Je größer das Datenaufkommen in den Unternehmen wird, umso mehr werden aktuell betriebene Netze an ihre Grenzen stoßen. Viele Betreiber werden sich daraufhin nach Alternativen zur traditionellen Netzwerkinfrastruktur umsehen und auch SDN in die Auswahlprozesse einzubeziehen. Der Stand der Entwicklung ist vergleichbar mit dem Beginn der Servervirtualisierung vor einigen Jahren. Heute sind, dem Marktforschungsunternehmen IDC zufolge, rund 70 Prozent aller Server virtualisiert. Die Tendenz ist steigend, da neu installierte Server in der Regel virtualisiert laufen.  Einen ähnlichen Verlauf wird möglicherweise auch die Entwicklung von SDN nehmen. Ein Blick auf die Marktforscher lässt zumindest ein großes Wachstum erahnen (siehe Abbildung-5).
 

Abbildung-5: SDN-Marktschätzung der nächsten Jahre (Quelle: Plexxi)

Die Notwendigkeit der Interoperabilität wird viele Unternehmen vor große Herausforderungen stellen. Zukünftig werden sich hier ungeahnte Unternehmenspartnerschaften eröffnen, in denen versucht werden wird, den Markt untereinander aufzuteilen. Teilweise werden die solventeren Unternehmen viel Geld in die Hand nehmen um kleinere innovative Start-ups in ihre Konzernstruktur zu integrieren. Diese Aussicht, wird wiederum viele Start-up dazu bewegen, neue bahnbrechende Entwicklungen für den SDN-Markt bereitzustellen, um auf sich aufmerksam zu machen. In Sachen Robustheit und Hochverfügbarkeit des Netzes muss im SDN-Umfeld noch erhebliche Entwicklungsarbeit geleistet werden. Hier werden sich auch viele kleinere Unternehmen positionieren wollen, in der Hoffnung, gewinnbringende Kooperationen mit den großen Netzwerkriesen eingehen zu können.

Das Monitoring eines Netzwerkes ist einer der gewinnbringenden Punkte eines SDN. Gleiches gilt für die Entwicklung von Troubleshooting-Software, um auftretende Probleme automatisiert zu analysieren und beheben zu können, ohne die Verfügbarkeit einzuschränken. Eine Vielzahl von SDN-Funktionen wird sich in den nächsten Jahren als Sicherheitsapplikationen positionieren. Zu beachten ist dabei, dass es aktuell noch keine überprüfende Instanz für die erhältlichen Programme gibt. Anwender sollten also strikt darauf achten, nur von vertrauenswürdigen Anbietern Applikationen zu implementieren. Um eine sichere SDN-Umgebung zu schaffen, ist es notwendig, dass Anwender zwingend mit dem IT-Sicherheitsverantwortlichen des Unternehmens zusammenarbeiten um alle sicherheitsrelevanten Punkte abzudecken.  Das Pflegen der Dokumentation ist gerade in einer agilen Netzwerkumgebung, wie sie bei SDN herrscht, ein essentieller Bestandteil der Zusammenarbeit. Bei allem Komfort, den SDN zukünftig den Netzwerkadministratoren zu bieten vermag, darf nicht außer Acht gelassen werden, dass SDN nur ein Werkzeug darstellt, welches auch sicher gehandhabt werden muss.

Ein weiterer wichtiger Punkt, die Switch-Basis-Konfiguration, hat in heutigen SDN-Angeboten noch keine Beachtung gefunden. Für die Interaktion mit der Basis-Konfiguration der physikalischen Switches, muss zukünftig auch eine Lösung gefunden werden. Kennwerte, wie beispielsweise die CPU-Last, die Geräteauslastung, ein simpler Systemneustart oder die Temperaturüberwachung (inklusive der Lüftersteuerung), müssen in ein SDN übergeben werden können. Schnittstellen dazu müssen über die Southbound-API bereitgestellt werden, und werden somit den Entwicklern der Protokolle OpenFlow, XMPP und anderen obliegen. Dazu müssen Kompatibilitäten mit anderen Herstellern geschaffen werden. Bestehende Sicherheitslösungen verschiedener Anbieter müssen miteinander harmonisieren und verschachtelt betrieben werden können um mehrstufige Sicherheit zu schaffen.

SDN-Controller dürfen nicht der Flaschenhals des Netzwerkes werden. Sie müssen mehrere Milliarden Flows pro Sekunde leisten können. Hier sind Entwickler von Hard- wie Software gleichermaßen gefordert. Zukünftig werden gigantische Datenmengen über die virtualisierten Netze laufen. Um das alles leisten zu können müssen Controller, wie auch Switches noch weitere Entwicklungszyklen durchlaufen. Um unabhängig zu bleiben, werden viele Anwender Open Source-basierte Lösungen bevorzugen. Aktuell ist allerdings selbst bei der Nutzung von OpenFlow noch keine Regelung gewährleistet, in wie weit die Kompatibilität mit nicht-OpenFlow-Netzwerken vollzogen werden kann. Auch hier herrscht Handlungsbedarf seitens der Entwickler.

Mario Sickert, GAI NetConsult GmbH

Quellen:
[1] http://blog.sflow.com/2014/01/physical-switch-hybrid-openflow-example.html
[2] https://www.sdxcentral.com/resources/sdncentral-library-sdn-market-report/sdn-market-size/
[3] https://www.opennetworking.org/
[4] http://www.opendaylight.org/

Diesen Artikel empfehlen

Einblicke in die Preise für gestohlene Daten

Intel Security veröffentlicht heute seinen Bericht The Hidden Data Economy, der einen Einblick gibt, wie und mit welchen Arten von gestohlenen Daten im Internet gehandelt wird. Dabei wird anhand von Beispielen die Preispolitik für den Handel mit diesen sensiblen Daten erläutert. Die McAfee Labs der...

Neue Bitkom-Checkliste zur elektronischen Archivierung

„Der Gesetzgeber schreibt zwar vor, was zu tun ist, beantwortet aber nicht die Frage danach, wie Unternehmen diese Anforderungen erfüllen können“, sagt Jürgen Biffar, Vorstandsvorsitzender des Kompetenzbereichs ECM im Bitkom. Die neue „GoBD*-Checkliste für Dokumentenmanagement-Systeme“ des...

IT-Sicherheit aus einem anderen Blickwinkel - Change or die

Gleichzeitig sind in den vergangenen Jahren die Anstrengungen zur Erhöhung der IT-Sicherheit massiv angestiegen, was sich nicht zuletzt auch in einer nationalen Cyber-Sicherheitsstrategie niedergeschlagen hat. Doch warum ist keine Verbesserung zu bemerken bzw. wann wird diese endlich...

Sichere Integrationsinfrastruktur – der Einstieg

Beim Aufbau und Betrieb einer Plattform zur System- oder Prozessintegration stößt man auf verschiedene technische und organisatorische Probleme. In diesem Artikel soll zunächst einmal auf Grundlagen eingegangen werden, um die verschiedenen Herausforderungen – insbesondere auch zur...

IT-SiG verabschiedet – was kommt auf uns zu?

Die Informationstechnologie prägt seit Jahrzehnten die Unternehmen in immer stärkerem Maße und spätestens seit Mitte der 90-er Jahre kann man dies auch für das Internet feststellen. Dass das Internet somit schon lange kein „Neuland“ mehr für deutsche Unternehmen ist, dies hat nun mittlerweile auch...

Neue Vorgaben der Finanzverwaltung für die IT-Compliance

Eine Verwaltungsverordnung kann zwar dem Bürger keine direkten Pflichten auferlegen, dennoch ist die GoBD von erheblicher Bedeutung, da die Finanzämter das Schreiben des BMF bei der Bearbeitung der Steuerangelegenheiten zwingend befolgen müssen und sich daher die Bearbeitungspraxis der Finanzämter...

Reputationsdienst für Zertifikate

Der jüngsten Untersuchung des Ponemon Instituts zufolge, mussten alle 2.300 befragten Unternehmen in den letzten zwei Jahren auf wiederholte Angriffe auf Schlüssel und Zertifikate reagieren. Die Bedrohungsforschung von FireEye, Intel, Kaspersky und Mandiant identifiziert immer wieder den Missbrauch...

Sichere Systeme – Security beim Hardwaredesign

Als eines der kritischen Systeme ist unser Straßenverkehr zu sehen. Jeder kennt es: In dicht besiedelten und infrastrukturell gut ausgestatteten Regionen reicht ein Kfz mit Defekt, um große Teile des Straßenverkehrs zu stören oder gar zum Erliegen zu bringen. Dies, und vorrangig die...

Das Ende der Ära von SSLv3

Wer hätte das gedacht, dass ein Pudel (engl. poodle) die lange Amtszeit von SSLv3 so abrupt beenden würde? Immerhin hat es vor diesem Angriff viele andere Angriffe auf das Protokoll gegeben, wie zum Beispiel BEAST, CRIME oder auch BREACH, denen man namentlich eher den Sturz von SSLv3 zugetraut...

eHealth – Der „Neue Markt“ für Cyber-Kriminelle?

Hinweise auf bereits festgestellte oder befürchtete Datenschutzverletzungen im Gesundheitswesen ereilen uns nahezu täglich. Bei immer mehr elektronisch gespeicherten medizinischen Daten und zunehmendem Datenaustausch müssen wir wohl zukünftig mit noch mehr Alarmmeldungen wie den nachstehenden...

Gefährliche Dinge(r) im Internet-of-Things?

Viele sprechen heute schon von der vierten industriellen Revolution (nach Erfindung der Dampfmaschine, der Einführung der Elektrizität und dem Beginn des Computerzeitalters) und meinen damit die bereits angelaufene Vernetzung im Internet-of-Things (IoT). Gartner geht in der Studie „Forecast: The...

Out-Of-Band-Management mit eingebauten Sicherheitsproblemen

„Turnschuhadministration“ - dieser Begriff ist sicherlich ein Albtraum für jeden Administrator, der etwas von seinem Handwerk versteht oder dessen Server nicht gerade im Raum nebenan stehen. Damit nicht für jede Tätigkeit der Weg in den Serverraum angetreten werden muss, bedient man sich...

Neuer Entwurf des IT-Sicherheitsgesetzes veröffentlicht

Eine erste Durchsicht des Entwurfs brachte folgende wesentliche Punkte und Neuerungen gegenüber dem Entwurf der alten Legislaturperiode für Betreiber Kritischer Infrastrukturen zu Tage: • Die Definition Kritischer Infrastrukturen und damit die Abgrenzung des Geltungsbereiches des Gesetzes ist...