Die Revolution kommt dann natürlich nicht von unten sondern häufig von oben. Manager und Entscheider greifen zum Besen und schreiten zum Kehraus im Rechenzentrum. Nicht einmal Kostenvergleiche werden abgewartet. Cloud-Torschlusspanik greift um sich. Dabei steht fest: Das Ende der Party ist absehbar. Dann nämlich, wenn der letzte Cloud-Fanatiker begreift, dass die weit entfernte Cloud keine Wunder vollbringt und die Latenz eine physikalische Größe ist, bleibt vom Cloud-Gelage vor allem dieses übrig: die duale IT. Dann hat die Organisation zwei IT-Welten, mit unterschiedlichen Regeln und Architekturen.

Eine Dystopie?

Wem der einführende Text in diesem Geleit wie die Beschreibung einer Dystopie vorkommt, kann ich versichern: In mehr als einem Unternehmen bin ich der neuen dualen IT schon begegnet. Sie institutionalisiert sich sogar schon mancherorts. Nach dem Vorbild des Abspanns so manchen Polit-Thrillers zunächst der Hinweis, dass jede Ähnlichkeit mit real existierenden Personen und Organisationen rein zufällig ist. Und dann der Film: OnPrem und Cloud sind schon organisatorisch getrennt und werden auch so genannt. An mancher Tür prangt schon das Cloud-Schild, an manch anderer der schüchtern wirkende Wegweiser zu OnPrem. Die Scheidung scheint rechtswirksam geworden zu sein.

Zwangsläufig kommen bei mir die Erinnerungen an die 1990er Jahre hoch. Ein Beispiel: In einem Unternehmen gab es seit Jahren die Trennung der IT nach Produktion und kaufmännischer IT. Ab Anfang der 1990er Jahre schritt die IT-Durchdringung immer schneller voran, in beiden Bereichen, in der Produktion und in der kommerziellen IT. Wurfkabel und sich zwischen Tür und Türrahmen schlingende Cheapernet-Segmente wurden dem Bedarf nicht mehr gerecht. Irgendwann wurde von beiden IT-Abteilungen die Hausverwaltung angerufen, um Abhilfe zu schaffen. Weise entschied sich diese für eine strukturierte, flächendeckende Verkabelung. Plötzlich mussten sich die beiden IT-Welten eine Infrastruktur teilen. Mit Müh und Not gelang dieser erste Schritt (Layer 1). Der zweite kam danach (Layer 2, Ethernet). Und bald mussten sich die beiden IT-Abteilungen auch noch auf abgestimmte IP-Adressen einigen. Der Prozess dauerte Jahre.

Ich kann viele ähnliche Geschichten von der mühsamen Ablösung der dualen durch eine geeinte IT erzählen. Aber ich belasse es bei dem einen Beispiel und weise darauf hin, dass die Etablierung einer einheitlichen, standardisierten und abgestimmten IT in vielen Unternehmen viel Mühe und Zeit gekostet hat. Jedes Mal war das Aufatmen hörbar, wenn dieser Prozess zum Abschluss kam und Früchte wie gleiche Architekturen, gleiche Prozesse und gleiche Sicherheitsniveaus trug.

Beispiel Zonenkonzept

In vielen Unternehmen sieht das RZ-Zonenkonzept für Webanwendungen die berühmte 3-tier-Architektur vor: Web – Applikation – Datenbank. Fein säuberlich getrennt befinden sich Webserver, Applikationsserver und Datenbankserver in unterschiedlichen Zonen. Für die Sicherheit greift das sogenannte Zwiebelschalenmodell. Der Durchgriff von der äußersten in die innerste Schale wird unterbunden. Den Webservern und zum Teil auch anderen Servern wird oft ein Load Balancer vorgeschaltet. Auf diesem residieren in einigen Fällen auch zusätzliche Sicherheitsfunktionen wie Web Application Firewall (WAF) und XML-Gateway. Die zusätzlichen Funktionen dienen zum Beispiel der Überprüfung des HTTP-Verkehrs zwecks Erkennung von Angriffsmustern. Das funktioniert natürlich nur, wenn zuvor die Layer-4-Verschlüsselung mit Transport Layer Security (TLS) aufgebrochen ist. Also lagert man das TLS-Tunnelende aus, zum Beispiel auf eben die Load Balancer am Eingang einer Zone.

Insbesondere in und für die Cloud wird aber häufig gemäß einer Microservice-Architektur entwickelt. Anwendungen werden in mehrere bis viele Module zerlegt. Jedes Modul kann unabhängig von anderen entwickelt, aktualisiert und gepatcht werden. Die typische Basis eines Moduls bzw. eines Microservices ist ein Container. Für Container werden eigene Management- und Automatisierungswerkzeuge genutzt.

Auf Container zugeschnittene Middlebox-Funktionen sind in diesem Fall auch sinnvoll, zum Beispiel für Load Balancing. Der Load Balancer ist dabei selbst ein Container bzw. ein Microservice.

Anwendungsmodule bzw. Microservices (in der Regel Web Services) werden dynamisch aufgerufen, zum Beispiel auch von Applikationsservern. Es ist klar, dass die statische Konfiguration von Load-Balancern mit WAF-Funktion und TLS-Terminierung der Microservice-Architektur nicht gerecht wird. Um Sicherheitsanforderungen zu genügen, wird die Architektur dem Zero-Trust-Modell immer ähnlicher. Zero Trust bedeutet dabei „nie vertrauen, immer verifizieren“. Jedes Modul muss sich also selbst schützen. Oft wird Mutual TLS für die Authentisierung, aber auch für die Verschlüsselung der Kommunikation angewandt. Mutual TLS bedeutet, dass sich beide Kommunikationspartner anhand von Zertifikaten authentisieren.

Manche Anwendung in der Cloud orientiert sich also jetzt schon nicht mehr an althergebrachten Zwiebelschalenmodellen für das Zonenkonzept. Aber das ist kein Grund, das bewährte Zonenkonzept in toto über Bord zu werfen. Das zu tun wäre nämlich das Kind mit dem Bade ausschütten.

Bewährte Zonenkonzepte enthalten nämlich mehr als nur das Zwiebelschalenmodell. Sie regeln zum Beispiel den administrativen Zugriff, wo möglich unter Nutzung eigener Zonen und entkoppelt von produktiver Kommunikation. In bewährten Zonenkonzepten gibt es auch Platz für Dienste wie DNS, die von allen Komponenten in einer Umgebung genutzt werden. Die Admin- und die Dienste-Zone werden auch in einer Microservice-Umgebung gebraucht.

Außerdem bricht die Microservice-Architektur nicht nächtlich über das RZ her und erobert es im Handstreich. Es gibt jede Menge Anwendungen, die nach klassischen Modellen arbeiten, auch sogar in der Cloud.

Zwischenfazit: Dem durch duale IT drohenden Chaos beim Zonenkonzept ist durch die Weiterentwicklung desselben entgegenzuwirken. Neue erforderliche Zonen sind hinzuzufügen und bewährte Sonderzonen beizubehalten.

Beispiel Perimeter

Früher war die Welt übersichtlich: hier das RZ, dort die externen Zugänge, zu erkennen an den Provider-Schränken. Dazwischen Sicherheitskomponenten wie Firewalls, IPS etc. Jetzt ist die Cloud da. Was ist sie? Verlängerung des Rechenzentrums? Ein externes Netz? Unsicheres Terrain?

Abbildung 1: Verbote sind auch keine Lösung

Die simple Antwort: von allem etwas! Cloud ist nicht gleich Cloud. Es kommt wesentlich darauf an, welches Servicemodell der Cloud zugrunde liegt (siehe Abbildung 1). Wenn der Perimeter die Grenze zwischen verschiedenen administrativen Domänen markieren soll, kann er sich bei Platform as a Service (PaaS) und Infrastructure as a Service (IaaS) durchaus in der Cloud befinden.

Eine Grundsatzentscheidung besteht darin, wie weit man darauf vertraut, dass der Cloud-Betreiber zeitgemäße Schutzmechanismen implementiert. Angesichts von Spectre und Meltdown1 ist das durch virtuelle Segmentierung erreichbare Sicherheitsniveau durchaus zu hinterfragen.

Aber selbst im vermeintlich einfachen Modell Software as a Service (SaaS), bei dem der Providerschrank nach wie vor die Grenzen administrativer Hoheiten markiert, stellt sich die Frage, welche Sicherheitskomponenten an dieser Grenze zum Einsatz kommen. Microsoft als SaaS-Anbieter würde am liebsten keine Web Proxies auf dem Weg zwischen Office365-Kunden und der Microsoft Cloud sehen. Proxy-Konfigurationen werden damit nicht einfacher.

Was aber nicht sein darf, ist eine duale IT, in der keinerlei einheitliche Regeln für Perimeter gelten.

Cloud geregelt nutzen

Die Liste der sich mit der Cloud ändernden Rahmenbedingungen, die zur Vermeidung der dualen IT einer Regelung bedürfen, ließe sich fortsetzen. Das würde jedoch den Rahmen dieses Geleits sprengen. Lassen Sie uns die Fortsetzung der Diskussion auf unser Cloud-Forum vertagen, das am 25. und 26. November in der sympathischen Domstadt Köln stattfinden wird. Meine Kolleginnen und Kollegen werden bis dahin die Erfahrungen aus den diesjährigen Projekten mit Cloud-Bezug zusammenfassen und für Sie aufbereiten. Wir freuen uns auf die Diskussion mit Ihnen.