In meinem Artikel über Zero Trust und was das für die Infrastruktur bedeutet habe ich bereits beleuchtet, welche Mittel genutzt werden können und sollten, um die ersten Schritte zu #ZeroTrust in der #Infrastruktur umzusetzen.
Kurz zusammengefasst geht es einerseits darum das typische Einfallstor – nämlich den (User)Endpunkt aus der Gleichung, also dem Intranet, zu entfernen – und andererseits die Auswirkungen eines erfolgreichen Angriffs auf die Infrastruktur zu minimieren, Stichwort: Mikrosegmentierung.

In diesem Artikel möchte ich etwas genauer auf die Mikrosegmentierung eingehen, welche Schritte dafür erforderlich sind und warum und wie das zu einem gesteigerten ROI, erhöhter Performance und damit einer erfolgreich(eren) digitalen Transformation beitragen kann.

Inhaltsverzeichnis

1. Einführung in die Mikrosegmentierung
   • Ausgangssituation
2. Erster Schritt: BlackBox
3. Zweiter Schritt: IAM
4. Dritter Schritt: beschreib- und automatisierbar
5. Vierter Schritt: Segmentierung der BlackBox
6. Fünfter Schritt: Von Server zu Service
7. Beispiele (stark vereinfacht)
8. Fazit

Einführung in die Mikrosegmentierung

Wenn ich von Mikrosegmentierung spreche, dann meine ich damit die Infrastruktur einer Anwendung in eine „BlackBox“ zu überführen.

Ausgangssituation:

Eine typische (gegebenen Falls stark vereinfachte) Architektur einer Line-Of-Business (LOB) Applikation sieht ungefähr so aus:

Das heißt, es gibt mindestens drei Server(bereiche), meist in jeweils einzelnen VMs separiert, manchmal, um vermeintliche Kosten zu sparen, sogar auf einer VM vereint:

1. Frontend Server – Rendering und Bereitstellung des User Interfaces oder der aggregierten, für die User*innen gedachten Daten
2. Backend Server – Numbercrunching, Backenddienste, alles, was nicht direkt an die Nutzenden übertragen wird und zur Bereitstellung des Dienstes gereicht, insbesondere auch der Zugriff auf die Daten(bank)
3. Datenbank Server – selbsterklärend, meist relationale Datenbanken wie SQL oder mittlerweile auch häufige nosql Varianten

(Viel zu) Oft sind diese unterschiedlichen Dienste „einfach“ in das identische Netzwerk integriert – mit etwas Glück in ein spezielles „Server Netzwerk“, leider nicht immer!

Da wir jetzt wissen, wie es meist aussieht, lasst uns einen Blick darauf werfen, wie es aussehen sollte/könnte:

Erster Schritt: BlackBox

Der erste und vermutlich auch einfachste Schritt ist es die benötigten Server/VMs in einem V-Net zu separieren, dieses mit einer Firewall (darf auch in Software sein, zum Beispiel, sollte die Architektur in Azure sein einfach durch eine Azure Firewall!) abzusichern und nur den Zugriff auf den Frontend Server auf dem designierten Port (443?) zuzulassen (vermutlich dann auch mit NAT etc. so tief möchte ich hier aber nicht gehen):

Für unsere Nutzenden sollte dies keinen Unterschied machen, denn die Applikation funktioniert genau gleich zu dem Bild vorher, nur, dass eben kein direkter Zugriff mehr auf den Backendserver und/oder die Datenbank möglich ist.

VORSICHT! Sollte die Applikation – insbesondere die vielleicht vorhandene Instanz auf einem User-Endpunkt (aka „installierte Applikation“) nicht nach „aktuellem Stand der Technik“ geschrieben worden sein und direkten Zugriff auf Backend/oder Database erfordern, dann muss entsprechend angepasst werden und es sollte hier gegebenen Falls die Architektur hinterfragt werden.

Zweiter Schritt: IAM

Da wir nun unsere „BlackBox“ etabliert haben, sollte der nächste Schritt sein die Applikation allen berechtigten Nutzenden zur Verfügung zu stellen.
Da jeder bereits die Low-hanging-Fruits aus dem letzten Artikel umgesetzt hat und dabei die Endpunkte aus dem Intranet entfernt wurden, muss nun der Zugriff auf unsere Applikation über Azure AD und Azure AD App Proxy sichergestellt werden.

Daraus ergeben sich folgende Vorteile (auch hier gehe ich nicht dediziert darauf ein):

1. Pre Authentication („no log4j“)
2. MFA, Identity Protection, Single Sign On (SSO), Conditional Access (CA), …
3. Per App VPN
4. Risk transfer to Microsoft
5. Provisioning

Für mich also ein no-brainer!

Dritter Schritt: beschreib- und automatisierbar

Wenn ich an diesem Punkt angelangt bin, dann sollte es mir jetzt schon relativ einfach fallen die Blackbox zu „beschreiben“, in etwa so:

Frontend Server:
•	Performance: XL
•	Required Application: Apache Tomcat latest version + Java latest version
•	Network:
       	•	1Gbit 
	•	Firewall: true
		•	External
	•	1Gbit 
	•	Firewall: false
		•	Internal
Backend server:
•	Performance: M
•	Required Application: LOB Application XYZ latest version
•	Network:
	•	Internal
		•	Firewall: true
		•	1Gbit
Database
•	Performance: L
•	Size: S
•	Required Application: MS SQL latest version
•	Network:
	•	Internal
		•	10Gbit 
		•	Firewall: true

Wenn also eine solche Beschreibung möglich ist, dann lässt sich unsere Blackbox auch durch ein Script automatisiert erstellen.

Dies wiederum katapultiert uns einen wesentlichen Schritt in die Richtung von digitaler Transformation:

1. Der Ort, an dem unsere Applikation existiert, wird nebensächlich. Ob on-prem, Azure oder sonst wo spielt für die reine Technik keine Rolle. Hier müssen andere Abwägungen getroffen werden
2. Business Continuity und Resilienz: Wenn ich die Applikation auf Knopfdruck neuerstellen kann, dann trifft mich ein Ausfall nur marginal.
3. Wachstum: Wenn ich die Applikation auf Knopfdruck erstellen kann, dann kann ich sie auch sehr einfach auf andere Orte ausweiten, zum Beispiel die Firma erweitert ihr Geschäft auf einen neuen Kontinent oder Land „USA“, dann kann die Applikation als weitere Instanz sehr schnell und einfach auch in den USA betrieben werden.
4. Die „Migration“ beziehungsweise das Verschieben der Applikation von einem Ort zu einem anderen wird ungleich einfacher
5. Das Etablieren einer Dev, Test oder UAT Instanz wird deutlich vereinfacht.

Vierter Schritt: Segmentierung der BlackBox

Der vierte Schritt ist nur ein vermeintlich kleiner Schritt, aber für mich ein ganz wesentlicher und oft auch gar nicht so leichter:

Wir mikrosegmentieren unsere BlackBox noch einen Schritt weiter: die Einzelnen Server werden noch mal eigenständig gekapselt und durch Firewalls von den anderen getrennt, so dass der Zugriff innerhalb der BlackBox nur über dedizierte Verbindungen möglich ist.

Dabei sollte zusätzlich zwingend sichergestellt werden, dass die einzelnen Dienste für eine definierte, kurze Zeit ohne eine aktive Verbindung zu dem jeweils anderen auskommen können. Zum Beispiel durch ein entsprechendes Transaktionsmodell. Der Hintergrund dafür folgt im fünften Schritt, kann und sollte aber hier schon vorbereitet werden!

Fünfter Schritt: Von Server zu Service

Nachdem wir nun happy sind, weil wir sehr robust mit unserer Applikation aufgestellt sind, sollten wir uns über die Königsklasse Gedanken machen: nämlich wie kann ich aus der Applikation mehr Performance bei gleichzeitiger Senkung der Kosten oder Steigerung des Return of Invest erreichen?

„Das sind ja drei Dinge auf einmal, das geht nun wirklich!“ (nein, das „nicht“ habe ich nicht vergessen, sondern bewusst weggelassen!)

Um das zu erreichen, müssen wir die „Server“ zu „Services“ konvertieren.

Der Betrieb von VMs ist nur ein Workaround oder „Übergangstechnologie“ für die Zeit, in der ich keine bessere Möglichkeit habe.

NIEMAND (außer den Platform- und Managed Service Anbietern) verdient daran ein Betriebssystem zu betreiben und zu warten, es geht IMMER darum einen erwünschten DIENST zu bekommen, für den es bis vor PaaS und SaaS eben immer notwendig war auch ein OS zu betreiben.

Das heißt, oft ist der Frontend-Server lediglich ein Webserver. Daher stellt sich (auch früher schon) die Frage: warum nutze ich nicht einfach einen „Webdienst“?

Antwort: „haben wir schon immer so gemacht„, „die Hardware ist eh da„, „die Admins wissen, wie man das macht„,…

Und genau das sollte gemacht werden! Also alle „Server“ in Dienste überführen, DENN daraus ergeben sich die oben angesprochenen Verbesserungen:

Die meisten Applikationen haben ein vorhersagbares Muster der Auslastung!

Einfachstes Beispiel: Montagsmorgens um 8:00h gibt es einen Peak, der flacht bis 12h ab, ab 13h wieder Peak und dann kontinuierlich sinkend bis 18h, dann auf nahe 0.

Das spielte bis dato keine Rolle, denn – und da wiederhole ich mich leider:
„haben wir schon immer so gemacht„, „die Hardware ist eh da (und Strom und Platz bekommen wir nicht auf unsere Kostenstelle umgelegt, sind also egal)„

Wie wäre es denn, wenn man aus diesem Korsett ausbricht und Dinge einfach mal anders/besser macht?

Wie wäre es, wenn die Services sich mit den Ansprüchen der User wachsen oder schrumpfen, grade so viel, dass es „genau passt“?

Und in unserem Szenario ist genau das auch möglich!

Das heißt, nach unserem Schritt 4 sind wir in der Lage die Server und in Schritt 5 die Dienste in der Größe zu verändern, weil ja die jeweils anderen mittlerweile kurz auf ihren Counterpart verzichten können. Also mal eben schnell den Webserver von 4 Kernen auf 2 Kerne geschrumpft, oder die Datenbank von 10 DTUs auf 100 DTUs aufgebläht!!!

Je granularer dies möglich ist, umso mehr Kostenersparnisse lassen sich erzielen bei gleichzeitig gleichbleibender oder – je nach Bedarf – auch gestiegener Performance!

Und hier noch ein Link auf n-Tier Applikationsarchitektur in Azure:
Windows N-tier application on Azure – Azure Architecture Center | Microsoft Learn

Beispiele (stark vereinfacht):

1. Buchhaltung:
   Vor dem Monats/Quartals/Jahres-Abschluss werden nur rudimentäre Dinge im Buchhaltungssystem vorgenommen.
   Um den Ultimo können die Systeme gar nicht schnell genug die Berechnungen und Buchungen durchführen.
   => kurz vor der heißen Phase die entsprechenden Dienste deutlich hoch skalieren => ja, das sind höhere Kosten, dafür ist der erwartete Benefit aber noch deutlicher zu spüren!
   => kurz nach der heißen Phase alles wieder runterschrauben => daraus ergeben sich deutliche Kostenvorteile, die vermutlich über den Monat/Jahr gesehen unter den aktuellen Kosten liegen dürften!
2. Einfache Applikation, die nur während den Bürozeiten verwendet wird:
   Morgens an einem Arbeitstag, so gegen 7:30h fahren die Dienste von ihrem „minimal“ Zustand [im Extremfall von „komplett Abgeschaltet“] auf den „normal“ Zustand hoch und abends, vielleicht gegen 18:30h fahren sie wieder auf „minimal“ zurück. Am Wochenende bleiben sie auf „minimal“ und an Feiertagen vielleicht auch.
   Bei Ferien gehen sie von „minimal“ nur auf „Ferienbetrieb“, der vielleicht zwischen „minimal“ und „normal“ liegt.
   Allein dieser Betrieb senkt die Betriebskosten SIGNIFIKANT! Allein wenn man die Betriebsstunden zusammenrechnet, in denen nicht/kaum gearbeitet wird, sollten das klar machen! (%spoiler%: ca. 4/5 der Zeit, sofern in einer Zeitzone bei gleichen Start- und Endzeiten!)

Fazit

In der Sesamstraße heißt es „…wer nicht fragt bleibt dumm…“ – ich würde das hier umdichten auf „…wer nicht handelt bleibt arm…“ oder so ähnlich!

Will sagen: die Möglichkeiten sind so offensichtlich, dass ich mich jeden Tag frage: warum macht das nicht eigentlich jeder!?
Und da sind wir wieder bei „haben wir schon immer so gemacht„!

Daher BITTE BITTE BITTE nutzt die Chancen, die heute schon existieren und nutzt sowohl das freigewordene Budget als auch das neu-erlernte Wissen über Betrieb digitaler Systeme, um die nächsten Schritte in die Zukunft zu gehen! Das spart Kosten UND erhöht gleichzeitig die Sicherheit und die Resilienz des gesamten Unternehmens!