Gastbeitrag: Die Kernprinzipien der IT-Sicherheit – wie die Risikominderung durch moderne Datensicherung – erfüllen auch beim Einsatz von Containern nach wie vor ihren Zweck. Betriebs- und Infrastrukturverantwortliche sollten jedoch auch über den Tellerrand schauen, rät Michael Cade.
Foto: Veeam
Der Autor Michael Cade ist Senior Global Technologist bei Veeam
Da Unternehmen bei der Entwicklung und Skalierung von Anwendungen zunehmend einen Cloud-nativen Ansatz verfolgen, spielen Container und Kubernetes eine entscheidende Rolle bei der Verwaltung und der Bereitstellung von Arbeitslasten in Multi-Cloud-Umgebungen. Im gleichen Zug damit wächst jedoch die Komplexität.
Eine kürzlich durchgeführte Umfrage unter DevOps-Fachleuten ergab, dass 94 Prozent der Befragten im vergangenen Jahr mindestens einen Kubernetes-Sicherheitsvorfall erlebt haben und 59 Prozent die Sicherheit als ihre größte Sorge bei der Verwendung von Kubernetes und Containern betrachten. Während sich immer mehr DevOps-Teams also Kubernetes zuwenden, um mit den Skalierungsanforderungen ihrer Organisation noch Schritt halten zu können, dürfen Grundprinzipien des sicheren Betriebes, wie IT-Absicherung und Datenschutz, nicht außer Acht gelassen werden.
Entwickler müssen immer größere und skalierbarere Anwendungen in immer dynamischeren IT-Umgebungen schaffen. Für die Belegschaft, welche die Betriebs- oder Infrastruktur verantworten, kann es daher wie eine Vollzeitbeschäftigung erscheinen, mit den sich ändernden Entwicklungspraktiken Schritt zu halten. Kubernetes ist nur die jüngste Herausforderung der Container-Idee, aber das Ziel bleibt dasselbe: Wie kann man das Risiko reduzieren, Kosten minimieren und ein insgesamt besseres Geschäftsergebnis erzielen?
Will man die Situation bildhafter darstellen, bietet sich folgendes an: Entwickler sind die Pioniere – sie erforschen Neuland und bauen etwas auf, was es vorher nicht gab. Die Betriebs- und Infrastruktur-Teams hingegen sind die Siedler – sie kommen in einer zweiten Welle, um neue Entwicklungen zu konsolidieren und sicherzustellen, dass diese langfristig überleben. Genau das ist bei Kubernetes der Fall. Wenn Kubernetes die Virtualisierungs- oder Adoptionsphase erreicht hat, liegt die Verantwortung für das tatsächliche Geschäftsergebnis in der Regel bei den Betriebskräften. Aber es ist sehr viel verlangt, von diesen zu erwarten, dass sie die Feinheiten von Kubernetes und Containern verstehen. Denn auch bei neuen Technologien müssen grundlegende Prinzipien eingehalten werden - Sicherheit, Backup und Wiederherstellung sind nach wie vor erforderlich. Daher sind es die einzigartigen technischen Anforderungen, die eine Herausforderung darstellen.
Da viele Unternehmen mittlerweile die Cloud als ihre neue IT-Heimat betrachten, ergeben sich viele der Sicherheitsherausforderungen für Kubernetes aus der verteilten Natur der Cloud-Architektur. Unterschiedliche Arbeitslasten können an verschiedenen Standorten ausgeführt werden, einschließlich des Konzepts mehrerer Clouds sowie externer und lokaler Server. Dies vergrößert nicht nur die Angriffsfläche, sondern kann auch zu Problemen bezüglich der Sichtbarkeit von Datenströmen führen. Das macht die Überwachung von Containern und die Erkennung von Sicherheitslücken schwieriger.
Kubernetes ist zwar so konzipiert, dass es sicher ist und nur auf Anfragen antwortet, die es authentifizieren und autorisieren kann. Es bietet Entwicklern jedoch auch maßgeschneiderte Konfigurationsoptionen, was bedeutet, dass es nur so sicher ist wie die von den Entwicklern konfigurierten RBAC-Richtlinien gut geschrieben wurden (Role-based Access Control). Kubernetes verwendet auch ein so genanntes Flaches Netzwerk, was es Gruppen von Containern (oder Pods) ermöglicht, standardmäßig mit anderen Containern zu kommunizieren. Dies wirft Sicherheitsbedenken auf, da Angreifer, die einen Pod kompromittieren, theoretisch auf andere Ressourcen im selben Cluster zugreifen können.
Trotz dieser Komplexität ist die Lösung zur Minderung dieses Risiko recht einfach – Zero Trust als Strategie. Bei einer so großen Angriffsfläche, einem relativ offenen Netzwerk und Arbeitslasten, die sich über verschiedene Umgebungen erstrecken, ist eine Zero-Trust-Architektur – eine Architektur, die niemals vertraut und immer verifiziert – beim Aufbau von Kubernetes entscheidend.
Das Prinzip der Zero-Trust-Architektur besteht darin, den Schwerpunkt der Sicherheit vom Rand einer Anwendung weg zu verlagern und gleichzeitig diese Prinzipien überall anzuwenden. Alle internen Anfragen werden als verdächtig eingestuft, und die Authentifizierung ist von oben nach unten erforderlich. Diese Strategie trägt zur Gefahrenminderung bei, da sie davon ausgeht, dass im Netzwerk jederzeit Bedrohungen vorhanden sind und daher ständig strenge Sicherheitsverfahren für jeden Benutzer, jedes Gerät und jede Verbindung notwendig sind. Für die flüssige und dezentralisierte Architektur von Kubernetes ist dies unumgänglich.
Ein weiteres Grundprinzip, das zum Schutz von Kubernetes-Anwendungen erforderlich ist, betrifft die Sicherung und Wiederherstellung von Daten. Dies ist ein bekanntes Konzept, aber bei der Sicherung von Kubernetes und Containern gibt es viele einzigartige Überlegungen bezüglich Backup. Diese unterschiedlichen Anforderungen an die Datensicherung sind darauf zurückzuführen, dass sich Kubernetes grundlegend von anderen Architekturen unterscheidet, da es zum Beispiel keine Zuordnung von Anwendungen zu Servern oder virtuellen Maschinen gibt.
Kubernetes-Backup-Systeme müssen außerdem anwendungsorientiert und nicht auf die Infrastruktur ausgerichtet sein. Dies ist auf die DevOps-Philosophie und die Shift-Left-Prinzipien zurückzuführen, die im Wesentlichen bedeuten, dass der Entwickler mehr Kontrolle über die Infrastruktur und die Bereitstellungen hat. Weitere einzigartige Anforderungen für Kubernetes-Backups sind die Skalierung der Anwendung, Schutzlücken und die Integration des Ökosystems.
Aus diesem Grund ist außerdem bei der Wiederherstellung von Kubernetes-Umgebungen ein detaillierter Ausführungsplan erforderlich, der Cluster-Abhängigkeiten identifiziert und Anwendungen aktualisiert, um neue Speicherkomponenten zu berücksichtigen. Wichtig ist es auch, den Plan in relevante Kubernetes-Anwendungsprogrammierschnittstellen (APIs) zu übersetzen. Obwohl somit für die Datensicherung eine maßgeschneiderte, native Kubernetes-Lösung erforderlich ist, sind solche Wiederherstellungsprozesse für die langfristige Sicherheit des Unternehmens entscheidend. Effiziente Wiederherstellung und Disaster Recovery sind nicht verhandelbar, da Ausfälle schätzungsweise 1.459 Euro pro Minute kosten.
Darüber hinaus ist die Datensicherung aber auch für Test- und Entwicklungszwecke sowie für die Mobilität von Anwendungen von großem Wert. Die Anwendungsmobilität bezieht sich auf die Fähigkeit, eine Anwendung in eine andere Umgebung zu migrieren – über lokale Standorte, Clouds, Cluster oder Kubernetes-Verteilungen hinweg. Dies wird immer wichtiger, da IT-Umgebungen immer komplexer werden und Unternehmen auf neue Geschäftsanforderungen reagieren müssen, neue Technologieplattformen übernehmen oder Kosten optimieren wollen.
Obwohl Kubernetes neue technische Herausforderungen mit sich bringt, überwiegen die Vorteile. Betriebs- und Infrastrukturverantwortliche sind es ohnehin gewohnt, neue Tools in den sich ständig erweiternden Tech-Stack zu integrieren. Kernprinzipien, wie die Risikominderung durch moderne Datensicherung, erfüllen dabei nach wie vor ihren Zweck.
Sobald diese Fähigkeiten erlernt sind, können die Betriebsgruppen beginnen, über den Tellerrand zu schauen und den Wert ihrer Daten durch Aktivitäten wie Testen und Optimieren zu ermessen und zu nutzen. Durch ein robustes Backup, das die App-Mobilität unterstützt, können Teams außerdem einen großen Beitrag zur Zukunftssicherheit von Anwendungen leisten, indem sie sicherstellen, dass die Dienste die nächste technische Änderungswelle leichter bewältigen können. Kubernetes ist somit zwar das aktuelle Tool, das die Entwicklungslandschaft verändert, aber es wird sicherlich nicht das letzte sein. Daher sollten Unternehmen keine Angst vor der Integration haben.
 OpenAI.png&size=390x230&crop=0&trim=1)
