Die SDDC-Fehler Anderer

Anbieter zum Thema

PANDUIT

DAXTEN GmbH

Data Center Group – Büro Köln

Von Perimeter-basierten Sicherheitskontrollen zur SDDC-Mikrosegmentierung

Bei der Umstellung von einem konventionellen Datencenter auf ein SDDC kommen die Beteiligten stets in die Versuchung, bereits existierende Perimeter-basierte Kontrollen auf Biegen und Brechen im neuen SDDC umzusetzen. In der Praxis erweist sich diese Strategie als äußerst komplex und der Versuch, unternehmenskritische Anwendungen und -Daten zu beschützen erweist sich oft als eine große Herausforderung, die nicht unbedingt von Erfolg gekrönt sein muss.

An der Wurzel des Übels liegt die meist höchst komplizierte Datacenter-Architektur. In einem traditionellen Datencenter hat man es mit Tausenden Multi-Tier-Anwendungen und -Diensten zu tun, die eine gemeinsame IT-Infrastruktur benutzen.

Natürlich gibt es Software-Werkzeuge, um die traditionelle RZ-Umgebung zu segmentieren, doch solche scheinbaren Lösungen erweisen sich als kurzsichtig, da sie die Administration des Datacenter ausschließlich anhand von physikalischen Eigenschaften splitten, zum Beispiel entlang der Grenze zwischen dem App- und dem Web-Server. In einer solchen Datacenter-Umgebung bieten Sicherheitskontrollen und -Richtlinien schlicht nicht den effektiven Schutz für unternehmenskritische Applikationen und Daten.

Neue Denke in Sachen Security

In einem SDDC muss man die Sicherheitsherausforderungen auf eine neue Art und Weise angehen. Zusätzlich zur physikalischen Segmentierung, wann immer angebracht, lassen sich Verwaltungsrichtlinien implementieren, die eine logische Segmentierung gewährleisten.

Ein SDDC kann diese Richtlinien in Bezug auf Benutzer, Applikationen und Daten durchsetzen, um eine „Sicherheitszone des Misstrauens“ eingerichtet werden („Zero-Trust-Umgebung“), welche leichter beschützt und einfacher nach außen hin abgeschirmt werden kann.

Diese Mikrosegmentierung, also: die granulare Aufteilung des Datencenters in logische Zonen, hilft nicht nur, durch umfassende Verhaltensanalyse und fortschrittliche Bedrohungsabwehr Eindringlinge als solche zu erkennen, sondern auch abzublocken. Diese Maßnahmen sollten die Erkennung von Bots, Trojanern, Rootkits und anderer Malware einschließen.

Logische versus physikalische Netzwerkisolierung

Viele VMware-Anwender wiegen sich in der Illusion, dass mehrfache vSwitches auf einem einzigen ESX-Host eine konsistente Architektur einer physikalischen Netzwerkisolation (statt lediglich einer logischen) ermöglichen. Das administrative Frontend täuscht dem Administrator im Interesse einer verbesserten Usability eine physikalische Netzwerkisolation ja auch vor.

Alle vSwitches auf einem Host laufen in demselben Bereich des Arbeitsspeichers auf der Basis eines gemeinsamen Codes. Ob man einen vSwitch oder zehn vSwitches auf einem Host einrichtet, bleibt der Speicherbedarf unverändert.

Alle vSwitches, die auf einem Host laufen, teilen sich eine einzige Kontrollebene und fungieren als separate logische Netzwerkpartitionen. (Kein Wunder, dass vSwitches so gerne gehackt werden.) Viele Anwender gehen dann aber hin und schließen jeden der vSwitches des betreffenden Hosts an ein separates physikalisches Netzwerk an in der Überzeugung, dass sie dadurch physikalische Isolierung erzielten. Weit gefehlt. Das Resultat ist logische Separation, vergleichbar mit einem einzigen physikalischen Switch, der zwischen einer Reihe von VLANs vermittelt.

Logische Isolierung rechtfertigt aber keinesfalls die Kosten der zusätzlichen Netzwerkadapter für jeden vSwitc. Diese führen oft zum Kauf überdimensionierter Hosts, etwa Rack-Mounted-Server statt Blades, fördern die Entstehung von Flaschenhälsen durch reduzierte Skalierbarkeit, etwa aufgrund der Illusion, dass die nicht existierende physikalische Netzwerkisolation der Sicherheitszonen aufrecht erhalten werden muss, und erhöhen unnötig den administrativen Aufwand, ohne die benötigte physikalische Netzwerkisolierung zu bieten.

(ID:43630099)