alphaspirit - Fotolia

Sicherheit im Software-defined Network (SDN): Chancen und Risiken

SDN-Sicherheit bietet Chancen für eine höhere Qualität der Verbindung. Neue Risiken entstehen durch die falsche Implementierung des SDN-Controllers.

Dieser Artikel behandelt

Netzwerk-Sicherheitsanalyse

Die Meinungen rund um die Sicherheit im Software-defined Network (SDN) sind gespalten. SDN verbessere die Situation im Netzwerk inklusive der Netzwerksicherheit, sagen die meisten SDN-Befürworter. Auf der anderen Seite steht eine neue Gruppe von SDN-Security-Anbietern, die auf Lücken in der SDN-Sicherheit hinweisen.

Beide Aussagen stimmen, je nachdem, was man unter Netzwerksicherheit versteht, was man mit SDN meint und wie man seine SDN-Pläne umsetzt. Eine intelligente Planung reduziert immer das Risiko – dies gilt insbesondere für die softwaredefinierte Netzwerksicherheit.

SDN ist einer der vielen Fachbegriffe aus der IT-Welt, der zu weit gefasst und nicht klar definiert ist. Einige sehen in Software-defined Networking Software-Overlays, die auf bestehenden Geräten aufbauen – so wie zum Beispiel Software-defined WAN (SD-WAN). Andere sehen SDN als Netzwerk mit einem Satz von APIs, die eine Softwaresteuerung des Netzwerks erlauben, selbst wenn die zugrunde liegenden Geräte bereits seit Jahren im Einsatz sind.

Die Sicherheit im Overlay-SDN hängt davon ab, wie das Overlay-Netzwerk aufgebaut ist, während die Software-API-Sicherheit von der Sicherheit dieser APIs abhängt, die wiederum von der Art der Implementierung der APIs abhängt. In jedem Fall müssen potenzielle Benutzer die Sicherheit der bestehenden Netzwerk-Layer erweitern, um diese neuen Funktionen zu integrieren.

SDN ersetzt in seiner reinsten Form Netzwerke, die aus Geräten bestehen, die zusammenarbeiten, um Weiterleitungsroutinen mit Geräten zu erstellen, die das Routing zentral steuern. Bei diesem SDN-Typ wird jeder Datenpfad explizit durch Weiterleitungsregeln in allen beteiligten Geräten erstellt. Auch Ausfallmodi, die auf Hardware- oder Verbindungsfehler reagieren, lassen sich bereits im Vorfeld festlegen. OpenFlow wird häufig verwendet, um die Weiterleitungsregeln in jedem Gerät zu definieren; und die Summe dieser Regeln schafft die Konnektivität des Netzwerks.

Die positive Seite der SDN-Sicherheit

Das Positive an SDN aus der Perspektive der IT-Sicherheit ist das explizite Routing der Datenpakete. Im traditionellen Netzwerk arbeiten die Geräte zusammen, um Pfade zwischen allen Netzwerkbenutzern herzustellen. Wenn einige dieser Pfade ungültige oder unsichere Interaktionen darstellen, ist es notwendig, sie mit Hilfe eines Firewall-Prozesses zu blockieren. Mit SDN ist es möglich, ausschließlich gültige und validierte Routen zu definieren. Andere Pakete werden einfach blockiert.

Die Möglichkeit, Datenpakete in dieser Form zu verteilen, zeigt, dass ein richtig aufgebautes Software-defined Network einen neuen Sicherheits-Layer für Verbindungen einzieht, der in herkömmlichen IP- oder Ethernet-Netzwerken nicht verfügbar ist. Solange die Routing-Pfade den Richtlinien eines Unternehmens für sichere Verbindungen entsprechen, verhindert das passende SDN-Design grundsätzlich Verbindungen, die nicht mit diesen Richtlinien übereinstimmen. Voraussetzung dafür ist aber ein richtig aufgebautes SDN.

Die negative Seite der SDN-Sicherheit

Der Erfolg eines Software-defined Networks steht und fällt mit dem SDN-Controller. Und genau bei der Implementierung des Controllers liegt auch das größte Risiko für die SDN-Sicherheit. Da der SDN-Controller das Herzstück eines SDN bildet, entscheidet jeder zentrale Steuerungs- oder Management-Prozess fast wörtlich über Leben oder Tod eines Netzwerks. Es ist absolut notwendig, dass der SDN-Controller selbst sicher ist. Er muss auf einer vertrauenswürdigen Plattform laufen und neue Anwendungen oder neue Komponenten der Plattform entsprechend mit dem Trust-Siegel validieren. Es gilt: Wer den SDN-Controller steuert, besitzt das Netzwerk! Wird der Controller kompromittiert, ist Sicherheit bedeutungslos und nicht zu erreichen.

Der nächste Parameter, der bei der Sicherheit im Software-defined Network zu berücksichtigen ist, ist die Beziehung zwischen dem zentralen SDN-Controller und den Geräten, die von OpenFlow oder einem anderen Weiterleitungsmechanismus gesteuert beziehungsweise kontrolliert werden. Hier gibt es zwei verschiedene Ansätze: Die erste Variante hängt von vordefinierten Routen ab, die zweite Variante (On Demand) unterstützt Routen auf Anfrage beziehungsweise bei Bedarf.

Wer den SDN-Controller steuert, besitzt das Netzwerk. Wird der Controller kompromittiert, ist Sicherheit bedeutungslos und nicht zu erreichen.

Im vordefinierten Routenmodell definiert der SDN-Controller mit Hilfe von Traffic Management und analytischen Methoden, wo der Datenverkehr hinfließen soll. Dadurch erstellt er ein komplettes und umfassendes Connectivity-Modell für das Netzwerk. Der im Netzwerk ankommende Verkehr wird nach diesen Regeln weitergeleitet, und es lassen sich Regel-Hierarchien definieren, um auf Änderungen der grundlegenden Netzwerkbedingungen zu reagieren.

Im On-Demand-Modell ermittelt der SDN-Switch, der ein Paket empfängt, zunächst, ob das Paket eine Weiterleitungsregel hat. Wenn dies nicht der Fall ist, sendet der Switch eine Routen-Anforderung an den zentralen Controller. Die Antwort des SDN-Controllers basiert auf den aktuellen Bedingungen im Netzwerk und lässt sich auch für den nächsten Switch entlang des Datenpfads wiederholen.

Beide Ansätze stellen eine große Herausforderung für die Sicherheit bei der Verbindung zwischen dem Controller und den Switches dar. Wer auf den Pfad des Controllers zugreifen kann, erhält die volle Kontrolle über einen bestimmten Switch – und vielleicht das gesamte Netzwerk. Zudem können die Datenpfade des Controllers selbst wegen eines defekten Geräts oder eines Verbindungsfehlers ausfallen. Eine mögliche Folge: Administratoren können Teile des Netzwerkes nicht mehr kontrollieren, so dass es zu fehlerhaften Paketen kommen kann oder sich ein Angriffstor für Hacker öffnet.

Der On-Demand-Ansatz ist zudem besonders anfällig für einen Ausfall der Verbindung zwischen dem SDN-Controller und den Netzwerkgeräten, da Backup-Fehlermodi normalerweise nicht vordefiniert sind. Unternehmen, die dieses SDN-Modell einsetzen wollen, sollten unbedingt sicherstellen, dass sie die Verbindung des SDN-Controllers zu allen Switches zuverlässig und hochverfügbar am Laufen halten.

Doch damit nicht genug: On-Demand-SDN schafft auch das Risiko von Distributed Denial-of-Service-Angriffen (DDoS-Attacken) auf den SDN-Controller. Wenn eine große Anzahl von Paketen ohne vorgegebene Routen an mehreren Punkten im Netzwerk ankommt, kann das zu einer Flut von Anfragen an den Controller führen mit der Konsequenz, dass er diese legitimen Anfragen nicht mehr bewältigen kann. Das Netzwerk ist in diesem Szenario nicht mehr in der Lage, neue Routen für neue Benutzer oder Anwendungen einzurichten.

Die hässliche Seite von SDN-Security

Richtige Betriebspraktiken sind offensichtlich entscheidend für Software-definierte Netzwerksicherheit. Ist dies nicht der Fall, überwiegen die Risiken die möglichen Vorteile einer expliziten Steuerung der Verbindungen und des Routings. Frühe Bereitstellungen deuten auf zwei große Risiken für die SDN-Sicherheit hin: Erstens die Einführung von unsicheren Anwendungen und Komponenten im Controller, zweitens die fehlerhafte Planung der Routing-Richtlinien auf Controller-Ebene, um die Sicherheit auf der Netzwerkebene zu erhalten.

Um den SDN-Controller selbst zu sichern, sollten Unternehmen den Controller-Server und virtuelle Maschinen (VMs) von allen anderen Ressourcen-Pools trennen. Diese Trennung verhindert die versehentliche Kommunikation mit unsicheren Anwendungen oder die Kontamination von eng am SDN-Controller eingesetzten Sicherheitsmaßnahmen. Firmen sollten möglichst keine anderen Anwendungen auf demselben Server oder derselben VM betreiben. Wo dies nicht möglich ist, benötigen Sie einen strengen Trust-Management-Prozess, um die Komponenten zu validieren. Für alle Komponenten des SDN-Controllers und die zugehörigen Anwendungen ist ein formales Application Lifecycle Management (ALM) notwendig.

Noch komplizierter ist die Routenplanung. Ein möglicher Ansatz besteht darin, interne Routen zwischen Switches zu definieren, die auf einem formalen Satz von vorgeplanten Routen und Fehlermodi basieren. Diese sind voll verbindungsfähig und leiten Datenpakete weiter, die sie erhalten. Firmen sollten zudem alle Geräte am Rand des Netzwerks, bei denen der Verkehr von Benutzern und Anwendungen ankommt, mit Richtlinien versehen, um den Zugang zu diesen zentralen Verbindungsrouten zu steuern.

Grundsätzlich gilt: SDN-Sicherheit hängt mehr von sorgfältiger Planung als von zusammengefügten Sicherheitselementen ab – es sollte zumindest so sein. Wenn Unternehmen hier nicht richtig planen, bringt SDN nicht nur die gleichen Risiken wie herkömmliche Netzwerke mit sich, sondern es entstehen zusätzliche, auf den Controller bezogene Risiken. Das stellt weder eine optimale Nutzung von SDN dar, noch eine intelligente Art und Weise, das Netzwerk der Zukunft zu gestalten.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Sicherheit für das Software-defined Network (SDN): Der No-Touch-Ansatz

SDN-Sicherheit: Maßnahmen für eine sicherere Architektur

SDN-Sicherheit mit passendem Risiko-Management-Plan verbessern

Software-defined Networking: DNS-Sicherheit in SDN-Umgebungen

Artikel wurde zuletzt im April 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Netzwerk-Sicherheitsanalyse

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close