Netzwerkbasierte Containersicherheit
Sicher skalieren im RZ
IT-Entscheider beschäftigen sich vermehrt mit Containertechnik. Mikrosegmentierung und Mandantentrennung für kritische Abteilungen sowie Test- und Entwicklungsumgebungen gewinnen an Bedeutung. Einige Großunternehmen adaptieren bereits die Technik, die bisher nur einige Service-Provider anbieten, aber auch Mittelständler bereiten die eigene Infrastruktur auf Anpassungen vor.
Die Anforderungen an RZ-Netzwerke wandeln sich erheblich: Weder Wartungen noch ein Betriebsausfall dürfen die Applikationen in ihrer Funktionsweise beeinträchtigen. Dies erfordert vom Netzwerk eine gewisse Intelligenz, um die schnelle und möglichst einfache Reaktion auf solche Szenarien zu ermöglichen. Die Basis dafür schafft ein im Active-Active-Modus betriebenes Infrastruktursystem, also die Sicherung des Betriebs über zwei Rechenzentren hinweg. Gleichzeitig sind die Subnetze anzupassen. Das Default-Gateway muss dort vorhanden sein, wo es benötigt wird, zudem müssen die Sicherheitsregeln mit der Applikation oder der virtuellen Maschine mitwandern, ohne manuelle Interaktion zu erfordern.
Für die darunterliegende Architektur ist ein sogenanntes "Spine and Leaf"-Design erforderlich (Bild 1), das die idealen Voraussetzungen für den vermehrten Ost-West-Verkehr im RZ bietet. Eine Layer-3-Fabric ist mit einem überlagerten Protokoll so aufgebaut, dass auch Layer-2-Verkehr mit den Vorteilen eines Routing-Protokolls (hier IS-IS und MP-BGP) nutzbar ist. IS-IS (Intermediate System to Intermediate System) ist ein "Link State Interior Gateway"-Protokoll und arbeitet ähnlich wie OSPF (Open Shortest Path First). MP-BGP (Multi-Protocol Border Gateway Protocol) hingegen ist eine BGP-Erweiterung zur Unterstützung von IPv4 und IPv6 im Unicast sowie Multicast. Ergänzt werden diese durch COOP (Council of Oracle Protocol), das für die Konsistenz der Endgeräteadressen auf den Spine Switches verantwortlich ist.
Controller Cluster
Ein für Konfiguration und Management eingesetzter Controller Cluster definiert die Kommunikationsbeziehungen. So ist es unter anderem möglich, über Mikrosegmentierung innerhalb eines VLANs Datenströme voneinander zu trennen, um beispielsweise Sicherheitszonen in eine Applikation einzuziehen. Ist eine Kommunikationsbeziehung zweier oder mehrerer Applikationen definiert, dann ist auch nur das erlaubt, was direkt in dieser Kommunikationsbeziehung angegeben ist. Ein Beispiel hierfür wäre, dass Webserver_A von außen über Port 443 erreichbar ist und intern zum SQL Server_A über Port 3306 seine Datenquelle anspricht. Jegliche weiteren Kommunikationsbeziehungen zu anderen Clients oder Servern sind untersagt, da sie nicht explizit innerhalb der Fabric erlaubt sind. So hält ein hohes Maß an Sicherheit beim Applikationsbetrieb bereits durch die Standardmechanismen der SDN-Fabric (Software-Defined Networking) Einzug in das Rechenzentrum.
Außerdem ermöglicht die Fabric, Regelwerke und Kommunikationsbeziehungen bei VM-Migrationen innerhalb eines Rechenzentrums oder zwischen Rechenzentren mitzunehmen und übergreifend anzuwenden. So garantiert der Lastausgleich die Betriebssicherheit im Netzwerk selbst bei einem RZ-Ausfall. Access-Listen sind somit obsolet: Sobald der Administrator eine Applikation entfernt, werden auch betroffene Regeln entfernt und mögliche Kommunikationspfade geschlossen.
Neben den Sicherheitsaspekten ist die Hochverfügbarkeit eines Netzes die Basis für Stabilität. Dies gewährleisten nicht nur RZ-übergreifende Redundanz, sondern auch bereits simple Mechanismen, die durch Software das Netz entlasten und parallel die Sicherheit erhöhen. Auch hier bildet die genannte "Spine and Leaf"-Architektur den Grundstein. Die Leaves dienen als Zugangsebene für Server und erlauben es, ein dynamisches Default Gateway für jedes Subnetz zu führen. Der Vorteil: Jeglicher Traffic, der auf einem angeschlossenen Server am gleichen Leaf-Switch terminiert, muss diesen nicht mehr verlassen. Bei einer historischen Three-Tier-Architektur mit Core, Distribution und Access Layer erzeugte dieser Vorgang häufig Last auf mehreren Geräten. Die neue Technik hingegen verringert die Last der Fabric und die Wahrscheinlichkeit von Paketverlusten.
Jede Komponente im Netzwerk ist redundant ausgelegt. Die Spines sollten dafür mindestens in doppelter Ausführung pro Rechenzentrum installiert sein und dienen gleichzeitig dazu, die Bandbreite zu erhöhen. Die Leaves sind verantwortlich für den Anschluss der Server-Ports und agieren immer paarweise über VPC-Domains (Virtual Port Channel). Das Controller Cluster setzt man in Produktionsnetzen mit mindestens drei Knoten auf, um neben der Redundanz ein Quorum als Instanz zu haben. Hinzu kommen Mechanismen, die bei Fehlern Netzausfälle verhindern.
Container erlauben den Applikationsbetrieb in einer isolierten Umgebung. Damit sehen Umgebungen unabhängig von Ort und Plattform immer identisch aus und verhalten sich auch identisch. So werden alle benötigten Bibliotheken sowie weitere Binär- und Konfigurationsdateien in einer Umgebung betrieben und auch bei einer Portierung von der Test- in die Produktivlandschaft übernommen.
Dadurch steigen aber gleichzeitig Komplexität und Dichte beim Betrieb - unabhängig davon, ob der Administrator eine Container-Engine direkt auf dem Bare-Metal-System aufsetzt oder über eine Virtualisierungsumgebung einführt. In der Applikationsentwicklung wiederum wird das Ressourcen-Management wesentlich komplexer und um eine weitere Ebene erweitert. So erhöht sich beispielsweise der Grad der Komplexität und der Kommunikationsbeziehungen im Gastbetriebssystem durch Container auf das N-fache (Bild 2). Damit steigt automatisch die Anzahl der Endpunkte im Netzwerk ebenso wie der Netzwerkverkehr zwischen den Betriebssystemen. Ebenso wächst die Gefahr, dass im Netzwerk Kommunikationsbeziehungen entstehen, die aufgrund der Konformität nicht erlaubt sind. Des Weiteren kann eine "Containerisierung" zu Engpässen zwischen gewollten Kommunikationsbeziehungen führen. Unterschiedliche Skalierungen sowie automatische Regeln zum Ausrollen oder Abschalten von Containern bei verschiedenen Lastspitzen erschweren es, die Service-Qualität auf Containerebene zu gewährleisten. Zudem gibt es nur selten Anwendungsfälle, in denen containerbasierte Applikationen komplett autark arbeiten und nicht mit anderen Enterprise-Applikationen kommunizieren. Die Integration wesentlicher Dienste und Anwendungen aus der bestehenden Infrastruktur erfordert daher sehr agile Richtlinien und Regelwerke, die es erlauben, mit den schnellen und wechselnden Anforderungen umzugehen.
Dies bedeutet im Umkehrschluss, dass der SDN-basierte Netzwerkansatz unumgänglich ist, um Konformität mit Agilität zu verschmelzen. Dazu sind Regeln nicht mehr nach VMs oder Hosts zuzuweisen, sondern nach Endpoint-Gruppen. Das erleichtert deren Management von der Einführung über die Kommunikation bis hin zum Abschalten des Containers.
Eine solche Konsolidierung verbessert die Sicherheit im Netzwerk über die gesamte Fabric. Zum einen kann man so Hochverfügbarkeit über Geolokationen realisieren, ohne dabei die Sicherheit aus den Augen zu lassen. Zum anderen können Applikationsentwickler isolierte Sandbox-Szenarien testen, die sonst nur in separaten Umgebungen möglich sind und häufig zu Schatten-IT führen.
Lesen Sie mehr zum Thema
