SDN und SDSEC – Wie alte Ideen durch geschicktes PR zu „Erfindungen“ werden

 

Hype Hype Hype….. und wieder ein neuer Hype, hurra, wir steigern das Bruttosozialprodukt!

Gehen wir einmal die bekanntesten Hype Begriffe der letzten Monate durch: Cloud, Internet of Things, Big Data, Fintech, Startup, Kickstart……

Nun kommen zwei neue Begriffe dazu, die in ihrer Basis eine alte Idee ist und durch die PR-Maschinerie wiedereinmal die Neuerfindung, vielleicht eher die Modernisierung des Rades als eine völlig neue Erfindung darstellen lässt.

Ehrlich gesagt bin ich so langsam müde davon ständig unterscheiden zu müssen, ob eine auf dem Markt mit Trommeln und Pauken gefeierte Innovation denn tatsächlich etwas völlig neues darstellt, oder durch die heutigen Möglichkeiten der Medien und PR-Mächte nicht neu verpackt, in Version 2.0 schmackhaft gemacht wird.

Die Rede ist hierbei von dem neuerdings auf den Weg gebrachten Begriffs „Software Defined Networks“ (SDN) oder inzwischen auf die gleiche PR-Schiene gesetztes „Software Defined Security“ (SD-SEC).

Die Erklärung für dieses Phänomen ist dabei denkbar einfach: Man entkopple zwei grundlegende Abhängigkeiten architektonisch voneinander ohne ihre technische Abhängigkeit zu verlieren, reichere das ganze mit aktuellen Technologien an, folge dem Trend und verpacke es mit Blümchen und Schleifchen. Fertig ist die neue Erfindung! 😀

Es ist heute durchweg in der Techno-Branche die Masche geworden,  die alte Karre zu sanieren und als Innovation zu verkaufen, statt echte Innovation zu bilden und wirklich neues zu schaffen.

Bevor ich aber auf das Hauptthema einsteige, hier die schon lange erwarteten Erläuterungen der oben genannten Begriffe:

  • Cloud = Klassisches Hosting nun mit voller, dezentraler Virtualisierung mit neuster Technologie
  • Internet of Things = Internet im Toaster oder im Kühlschrank und in den Steuerungsanlagen der Atomkraftwerke
  • Big Data = Data Mining aus Vorratsdaten und nun auch endlich mit Daten aus Massenvernetzung mit KI gestützter Auswertung
  • Fintech = Banken entdecken endlich die Technologie, weg von Steinzeit
  • Startup = Viel mehr Menschen gehen in die Selbstständigkeit
  • Kickstart = Ich habe eine Idee, wo kann ich Gewerbe anmelden und nach einem Jahr Insolvenz anmelden

Verstehen sie mich nicht falsch. Ich bin selbst ein Technik-Fan und bin froh, dass Menschen immer weiter wollen und ihre Erfindungen ständig verbessern, ergänzen, ausbauen. Aber diese Lobby gestützten PR Kampagnen, gefördert durch Web-Medien gehen mit allmählich auf den Keks. Das ist pures Boosting des Kapitalismus, ahnungslose Kunden denken zu lassen, ein zweiter Isaac Newton schreit gerade wieder „Heureka“, diesmal nicht in der Wanne sondern im Internet. (Es war übrigens Archimedes 😉 nicht Newton)

Aus Managed Networks wird SDN

So ist es bei SDN der Fall, dass sich erst einmal die wenigsten etwas unter diesem Begriff vorstellen können, bis sie sich einmal mit dem, was dahinter stehen soll, befasst haben. Gehen wir doch mal aus Spass und unbehaftet an den Begriff ran: Software Defined Networks. Ich stelle mir das in den ersten paar Sekunden so vor, dass ich eine Software kaufen kann, die es überflüssig machen soll, dass meine Netzwerkarchitektur mithilfe meines Admins mit seinen Patch-Kabeln und Router Konsolen konfiguriert wird. Eine Knoten- und Netzverkabelung ist überflüssig geworden, das macht jetzt alles die Software. Ich muss also mein Admin nicht mehr in den Serverraum mit Kühlschranktemparaturen schicken oder ihn treten, weil er die Portbelegungsliste nach einem Change mal wieder nicht aktualisiert hat?

Das wäre doch toll 🙂 Aber ich muss sie enttäuschen. Diese Erleichterung gibt es bereits seid mindestens 10 Jahren, zumindest wenn man das Netz intelligent genug aufgebaut hat.

Tatsächlich geht es bei SDN darum, eine Entkopplung der Kontrolleinheit von der Dateneinheit zu bewirken, um einerseits die Administration eines Netzwerks zu zentralisieren und Software basiert zu konfigurieren, andererseits eine Hardware-Unabhängigkeit herbeizuführen. Wenn ein Admin an seiner Routerkonsole sitzt, konfiguriert er diesen auch softwarebasiert, nur nicht eben zentral, oder nicht immer. Nicht immer deswegen, da einige Hersteller bereits viel früher damit begonnen hatten, das Management ihrer Produkte durch Softwareprodukte und proprietäre Protokolle möglichst einheitlich und zentral zu ermöglichen, die man als Kunde zukaufen konnte. Es ist ja nicht so, dass z.B. ein Checkpoint Administrator heute noch zum anderen Ende der Stadt in das Rechenzentrum fahren muss, nur um eine Firewallregel zu verändern. Ebenso muss auch kein Cisco Administrator zwangsläufig an den Core Router, um eine virtuelle LAN als VPN Pool zu erzeugen, um externe VPN User nach ihrer Funktion in das interne Netz feingranular zu routen. Diese oder ähnliche vereinfachte Netzwerkadministration gibt es und gab es bereits viel früher.

Die Idee hinter SDN soll es sein, das Leben der Netzwerkadministratoren dahingehend zu vereinfachen, in dem zentrale Konfigurationsplattforme bei dezentralen, womöglich verteilten Netzwerken geschaffen werden soll. Dabei wird auch Wert darauf gelegt, durch die Entkopplung der Steuer- und Konfiguriereinheit von der Dateneinheit eine gewisse Hardwareunabhängigkeit herbei zu führen. In einer möglichst abstrahierten, unabhängigen Implementierung des SDN, wäre es möglich eine Multi-Hardware-Architektur für den gleichen Zweck einzusetzen. Dabei können durch geeignete Schnittstellen neben dedizierter Hardware, z.B. auch ein handelsüblicher PC in einen Router, eine Firewall oder ein Switch verwandelt werden, welcher netzwerktechnische Möglichkeiten des Routing&Switchings, des Firwallings und VLAN Truncings bereitstellen würde, ohne dass der Admin jedes Mal an unterschiedlichsten Konsolen statische Konfigurationsarbeit leisten muss.

Beflügelt wurde die Idee des SDN aber erst durch die Virtualisierungstechnik und der damit verbundenen und zugleich geforderten Möglichkeiten eines hoch dynamischen und flexiblen Betriebs von IT Systemen und Netzwerken. Auch die fehlende Dynamik eines autonomen Systems, welches sich in einem Netzwerk nicht beliebig hinter unterschiedlichen Knotenpunkten bewegen kann, soll mit dem Ansatz des SDN ermöglicht werden. Die autonomen Fähigkeiten einer jeden Teilstruktur soll dabei nicht verloren gehen, auch wenn die Kontrollinstanzen, die Steuerungseinheiten unerreichbar wären.

Es ist des Weiteren bereits bekannt und länger present, das ein Hypervisor, der viele virtuelle Maschinen über seine physischen Netzwerkschnittstellen ansprechbar macht, neben diesen VMs auch virtuelle Netzwerkschnittstellen sowie virtuelle Switches und gar internes Routing realisieren kann. Während also z.B. CISCO mit seinem VTP dem Admin die Möglichkeit gibt mal eben virtuelle Subnetze über die zentrale Management Software zu konfigurieren und zu routen ohne dabei an die Konsole gehen oder Kabel umstecken zu müssen, kann der Hypervisor Admin Netzwerke innerhalb eines Hosts konfigurieren und schalten. Die Anforderungen an dein SDN dabei ist es, nicht nur diese Möglichkeiten zentral zu vereinen, sondern auch ihre Dynamik weitestgehend zu übernehmen und so eine Vereinfachung der Administration herbeizuführen, mit einer gewissen Intelligenz zur Störungsvermeidung und ggf. automatischer Behebung. Dadurch lässt sich u.U. auch ein SIEM realisieren, welches über definierte Entscheidungswege mal eben ein komplettes virtuelles Subnetz bei Bedarf umrouten könnte.

Hinsichtlich der Entkopplung der Steuerung von der Dateneinheit kann ich mit sicherheit sagen, dass dies keineswegs eine neue Erfindung ist. Ansätze hierzu gab es bereits vor 16 Jahren in der Linux Welt. Ich hatte einmal selbst einen Auftrag begleitet, auf Linux basierte multi-purpose bzw. multi-service Systeme aufzubauen, deren Konfigurationseinheit vollständig entkoppelt und damals schon webbasiert bereitgestellt werden sollte. Das lief auch ganz gut. Ich konnte ein System im Handumdrehen in einen Router verwandeln. Mit den 5 Netzwerkkarten in diesem PC System, konnte ich an unterschiedlichen Knotenpunkten dynamische Routen bestimmen und mit vorgeschalteten Last Verteilungssystemen das Ausfallrisiko minimieren. Die Systeme waren zudem clusterfähig und konnten über die Management Konsole neben der Funktion als Router oder Firewall auch mal so eben in ein Fileserver verwandelt werden. Multi-Purpose eben. Sicher sollte man heute primäre Funktionen nicht vermischen. So sollte ein Router nicht missbraucht werden, um gleichzeitig einen Fileserver oder Webserver bereitzustellen. Jedoch gab es dieses zentrale Management von Hardware-unabhängigen Netzwerkkomponenten inkl. einer gewissen Dynamik bereits viel früher. Man denke auch an das OSPF Protokoll und dessen Vorteile, wenn es ums schnelle und ausfallsichere Routing ging.

In einem stark von Virtualisierung und Cloud-Technologie geprägtem Umfeld, wäre eine Harmonisierung und Flexibilisierung der Netzwerkverwaltung sicher eine sinnvolle Sache, ohne dass der Admin 5 Konsolen an 3 Standorten bedienen muss, weil sich gerade etwas an der Topologie ändert. Aber neu ist die Idee sicherlich nicht. Sie ist allenfalls ein Bedarf, weil neue Technologien aus ihrem anfänglichen Trend-Modus heute zu unserer Realität geworden sind und die klassische Arbeitsweise in den Schichten darunter nicht mehr zeitgemäss und in Einklang mit diesen Technologien erscheint.

Was darf man unter dem Begriff SD-SEC verstehen?

Das SD-SEC oder auch SDS genannt, also „Software Defined Security“ ist dabei eine Art von Sicherheitsmodell, in dem die Informationssicherheit in einer Rechnerumgebung implementiert wird, kontrolliert und von Sicherheitssoftware verwaltet. Es ist eine durch Software verwaltete, richtliniengesteuerte Sicherheit, wo die meisten der Sicherheitskontrollen wie Intrusion Detection, Netzwerksegmentierung und Zugriffskontrollen automatisiert und durch die Software überwacht werden.

SD-SEC soll in der Regel in IT-Umgebungen implementiert werden, die eine minimale oder keine Hardware-basierte Abhängigkeit zur Sicherheit besitzen, wie es in Cloud Computing Umgebungen und Virtualisierungs-Infrastrukturen der Fall wäre. Jedes neue Gerät, welches in diesen Umgebungen erstellt wird, wird automatisch von SD-SEC abgedeckt und über die Basis-Sicherheits-Policy gesteuert. Damit ist auch sichergestellt, dass die Reichweite und Skalierbarkeit der gewünschten Sicherheit sich der zugrunde liegenden Umgebung anpasst und sich mit den steigenden Infrastruktur / Umwelt-Ressourcen bewegt. Darüber hinaus sollen SD-SEC gesteuerte Umgebungen in andere Rechenzentren / IT-Einrichtungen verschoben oder migriert werden, ohne die Sicherheits-Policy und der Kontrollen an Ort und Stelle beeinflussen zu müssen. Kommt ihnen das nicht auch bereits bekannt vor? 🙂 Auch SD-SEC ist eine Standardisierung und Harmonisierung von verschiedenen Ansätzen zu einer einheitlichen Modellierung so wie SDN.

Und jetzt?

Wir sollten uns dennoch immer wieder fragen, um nicht zu sagen einen Hype-Begriff hinterfragen, ob es denn wirklich etwas völlig neues ist, oder man nur eine erweiterte Idee zu einem Produkt gebracht hat und nun diesen mit aller Kraft als Hype vermarkten will. Ebenfalls sollte man wissenschaftliche Aspekte bei neuen Modellierungen oder Ansätzen strikt davon trennen, daraus ein Trend oder gar ein Hype machen zu müssen.

Eine wissenschaftliche Errungenschaft kann zu einem Hype werden, aber ein Hype ist nicht immer zwangsläufig eine neue Errungenschaft.

(red)

 

 

Diesen Beitrag teilen:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*