Beispiel Mikrosegmentierung

Wie mein Kollege Dr. Hoff in einem Insider-Beitrag dargestellt hat, erfordern moderne Zonenkonzepte Mikrosegmentierung. In letzter Konsequenz bedeutet dies, dass nur notwendige Kommunikationsbeziehungen zulässig sind. Zonen werden so weit verkleinert, bis sie nur aus einem Server bestehen. Ein zentral verwalteter Mechanismus sorgt dafür, dass jeder Server nur explizit freigeschaltete Kommunikationsbeziehungen nutzen kann. Diese werden auf erforderliche Kombinationen aus Protokoll, Hosts und Portnummern beschränkt.

Die Notwendigkeit, mit Mikrosegmentierung die Auswirkung des Kompromittierens einzelner Hosts zu begrenzen, ist schon seit Jahren bekannt. Aber sie ist in historisch gewachsenen OnPrem-Rechenzentren nur schwer zu realisieren. Eine Schwierigkeit besteht darin, dass in den meisten Umgebungen das Gros der Server virtualisiert ist. Die „Firewall“ muss direkt an der virtuellen Maschine platziert sein, d.h. bereits die Kommunikation über den virtuellen Switch im Hypervisor kontrollieren. Zugleich muss die verteilte Sicherheitsfunktion zentral verwaltet werden. Da Anbieter von Virtualisierungslösungen wie VMware mittlerweile versuchen, Tools von Drittanbietern an der Wahrnehmung dieser Firewall-Funktion zu hindern, bleibt als Lösung für die Mikrosegmentierung nur noch der Mechanismus innerhalb der Virtualisierungslösung selbst. Das bedeutet höhere Kosten und noch mehr Abhängigkeit von einem Hersteller. Und der Weg zur Mikrosegmentierung ist ein steiniger, an dessen Anfang die Erfassung der vielen zulässigen Kommunikationsbeziehungen steht.

In der Cloud ist die Mikrosegmentierung von Anfang an da. Bildet man eine Virtual Private Cloud (VPC) in AWS bzw. ein VNET in Azure, muss man externe Kommunikation explizit zulassen. Zusätzlich stehen zum Beispiel Network Access Control Lists (NACLs) zur Verfügung. In der Cloud ist Mikrosegmentierung die Regel und ein offener Kanal die Ausnahme.

Beispiel DDoS

Distributed Denial of Service (DDoS) ist ein verbleibendes Restrisiko in jeder Umgebung, die über das Internet kommuniziert. Konzertierte Angriffe unter Missbrauch einer Vielzahl von Geräten, die der Angreifer zu Bots umfunktioniert, sind gang und gäbe. Solche Angriffe kann man erkennen und abwehren. Dafür sind intelligente Mechanismen erforderlich, die es in den meisten privaten RZs noch nicht gibt. Außerdem kann die Erkennung und Abwehr im eigenen RZ schon zu spät sein, wenn nämlich durch den Angriff die Internetverbindung lahmgelegt wird. Also muss man die DDoS-Abwehr als Provider-Service einkaufen. Nicht selten muss man dafür so viel bezahlen wie für den Internetanschluss selbst.

In der Cloud kann man dagegen den DDoS-Dienst des Cloud-Anbieters nutzen, der schon seit Jahren etabliert ist. Er ist in der Regel wesentlich preiswerter als die Pendants für den Schutz von OnPrem-RZs.

Beispiel WAF

Zum Schutz von Web Services setzt man häufig Instanzen der Kategorie Web Application Firewall (WAF) ein. Diese kontrollieren auf Applikationsebene die Kommunikation und blockieren zum Beispiel nicht erwünschte oder riskante Operationen auf HTTP-Ebene. Dafür ist es erforderlich, Transport Layer Security (TLS) zu umgehen und die entsprechende Verschlüsselung aufzubrechen. Denn verschlüsselten Verkehr kann man nicht eingehend untersuchen. Für die Kombination von WAF und TLS-Terminierung benötigt man Komponenten, deren Beschaffung, Konfiguration und Betrieb einen signifikanten Aufwand verursachen kann.

In der Cloud ist WAF ein Standarddienst, den man „dazu buchen“ kann. Dieser Dienst skaliert mit den zu schützenden Ressourcen. Für Updates und Erkennung neuer Angriffsprofile ist der Cloud-Betreiber zuständig. Das vereinfacht die Entscheidung für die WAF-Nutzung in der Cloud.