Inhalt
Immutable Infrastructure ist ein Konzept, das trotz seiner vielen Vorteile oft eher ein hochgestecktes Ziel als eine implementierte Praxis ist. Viele Unternehmen haben die Einführung dieses Konzepts in Erwägung gezogen, aber oft wird es im Streben nach einer schnelleren Markteinführung und der Bereitstellung neuer Funktionen zurückgestellt.
Immutable Infrastrukturen sind jedoch ein entscheidender Faktor für die sichere Bereitstellung von Anwendungsinfrastrukturen in großem Maßstab. Durch die Minimierung von Konfigurationsabweichungen und unbeabsichtigten Änderungen lässt sich die Anwendungsinfrastruktur leichter skalieren und sicherer warten, und auch die allgemeine Sicherheitslage wird verbessert.
In dieser zweiteiligen Serie werden wir erörtern, was sich hinter dem Begriff „Immutable Infrastructure“ verbirgt, warum sie mehr als nur eine sichere Methode zur Bereitstellung von Anwendungen in großem Umfang ist und warum sie ein wichtiger Bestandteil der Sicherheitsstrategie eines jeden Unternehmens ist.
Was versteht man unter Immutable Infrastructure?
Das Prinzip der Immutable Infrastructure lässt sich wie folgt zusammenfassen: Sobald die Softwareinfrastruktur bereitgestellt ist, ist diese unveränderlich und wird auch so lange nicht verändert, bis sie durch eine neue Version, Funktion oder Revision vollständig ersetzt wird.
Das scheint einfach zu sein, aber was bedeutet es, wenn man sagt, dass die Infrastruktur unveränderlich ist? Wie sieht das in der Praxis aus?
Eine gängige Analogie zur Erläuterung von Immutable Infrastructure ist „Vieh gegen Haustiere“. Wenn wir an Haustiere denken, denken wir an Tiere mit individuellen Namen, Verhaltensweisen, Ernährungsgewohnheiten und Pflegevorschriften. Rinder hingegen haben in der Regel keine Namen, neigen zu einem Herdenverhalten und werden auf eine allgemeine und stark skalierte Weise gefüttert und gepflegt.
Ersetzen Sie „Tiere“ in der vorherigen Analogie durch „Server“, und die Parallelen werden offensichtlich. Server, Knoten oder virtuelle Maschinen, die wie Haustiere behandelt werden, haben eindeutige Namen und Verhaltensweisen, und die Abfolge der Schritte oder Aktionen, die unternommen wurden, um den aktuellen Zustand oder die aktuelle Konfiguration zu erreichen, kann nicht einfach auf einem anderen Knoten repliziert werden. Umgekehrt werden Server, die wie Vieh behandelt werden, in der Regel als Teil einer größeren Herde benannt, wobei alphanumerische Sequenzen ihre einzige eindeutige Kennung sind. Ihre Pflege und Fütterung, oder in diesem Fall die Konfiguration, ist ein skalierbarer und wiederholbarer Prozess, der auf neue Mitglieder der Herde angewandt werden kann, um sie schnell auf den gleichen Stand wie die anderen Mitglieder zu bringen.
In diesem Paradigma werden Netzwerkkomponenten wie Server nicht gepatcht, aufgerüstet oder verändert. Wenn eine Aktualisierung erforderlich ist, wird die vorhandene Komponente zerstört und durch eine neue ersetzt.
Das Konzept der Immutable Infrastructure erstreckt sich auch auf Software-Artefakte. Software-Artefakte werden im Allgemeinen als Nebenprodukt oder Output der Software-Entwicklung betrachtet. (Im Kontext dieses Artikels bezieht sich der Begriff „Software-Artefakt“ speziell auf eine Codeeinheit oder Anwendungsfunktionalität, die als eigenständige Funktion oder Anwendung oder als Teil eines größeren Systems bereitgestellt werden kann.)
Veränderliche Software-Artefakte führen oft zu schwierigen, fehleranfälligen Bereitstellungsprozessen. In einer hypothetischen Entwicklungsumgebung muss ein Entwickler möglicherweise kleine Änderungen an seiner Software vornehmen, damit diese in seiner lokalen Entwicklungsumgebung, in der Testumgebung und schließlich in der Staging-Umgebung korrekt ausgeführt werden können. Was passiert, wenn der Einsatz in der Produktionsumgebung fehlschlägt? War die ursprüngliche Funktion fehlerhaft oder war es eine der vielen vorgenommenen Änderungen, um das Artefakt in den verschiedenen Umgebungen funktionsfähig zu machen? Veränderliche Artefakte führen zu übermäßiger Komplexität und erschweren das Debuggen von Software- und Infrastrukturproblemen erheblich.
Ein immutabler Ansatz, wie z. B. die Versionierung von Software-Artefakten mit unveränderlichen Tags (z. B. ein Git-Commit-Hash) oder die Verwendung von Containern zur Kapselung aller Elemente, führt zu einem viel einfacheren und weniger fehleranfälligen Prozess.
Was sind die Vorteile von Immutable Infrastructure?
Die Konzentration auf die Unveränderbarkeit der Infrastruktur bietet einer Softwareorganisation eine Reihe von Vorteilen: Sie vereinfacht den Verwaltungsaufwand und die Komplexität, ermöglicht eine bessere grundlegende Sicherheitslage und verbessert die betrieblichen Ergebnisse/Skalierbarkeit.
Verringerung der Komplexität
Betrachtet man das Beispiel der Software-Artefakte etwas weiter, so helfen unveränderliche Software-Artefakte, die Komplexität und den Verwaltungsaufwand bei der Software-Entwicklung zu reduzieren. Die meisten modernen Softwareanwendungen bestehen nicht mehr nur aus einem Compiler oder Interpreter, sondern stellen oft ein komplexes Netz von Softwareabhängigkeiten, verschiedenen Build-Artefakten, Konfigurationsdateien und Middleware dar.
Der Versuch, all diese miteinander verbundenen Komponenten zu verwalten, wird im großen Maßstab schnell zu einer nicht zu bewältigenden Angelegenheit. Wie können Entwicklungsteams all die verschiedenen Abhängigkeiten und einzigartigen Konfigurationen über Tausende von Knoten und Microservices hinweg effektiv verfolgen? Bei immutablen Software-Artefakten werden alle Abhängigkeiten, Konfigurationsdateien und Tools in einem Docker-Container gekapselt, der eindeutig versioniert und gekennzeichnet ist.
Dieser Prozess findet einmalig zum Zeitpunkt der Erstellung statt, und das Artefakt wird nie wieder geändert, unabhängig von der Bereitstellungsumgebung oder dem Kontext. Wenn ein Entwickler einen Aspekt des Artefakts ändert, auch wenn es sich nur um eine kleine Änderung der Abhängigkeit oder der Konfiguration handelt, wird ein neues Artefakt mit einem neuen Versions-Tag erstellt und anstelle des vorherigen bereitgestellt.
Verbesserung der Sicherheit
Immutable Infrastructure hilft Software-Teams auch dabei, eine bessere allgemeine Sicherheitslage zu erhalten. Die Unveränderlichkeit kann sich auch auf die Verwaltung herkömmlicher Fernzugriffswege wie SSH, SFTP und andere Arten von Verbindungen erstrecken.
In älteren, veränderlichen Systemen wurden Server über manuellen Fernzugriff mit SSH oder ähnlichen Tools konfiguriert und aktualisiert. Der SSH-Zugriff erfordert die Verwaltung der Benutzerkonten und der zulässigen SSH-Schlüssel auf jedem Server, die den Zugriff erlauben. Die Verwaltung dieser Art von Zugriff in großem Umfang bedeutete oft, dass die Software- und Betriebsteams auch eine Softwareinfrastruktur für das Konfigurationsmanagement bereitstellen und verwalten mussten, was den Stack zusätzlich komplex machte und Angriffsflächen bot. Jeder Knoten, der Fernzugriff erlaubt, ist ein potenzielles Ziel für Hacker und erhöht die Komplexität der Verwaltung.
Bei einem immutablen Muster werden Zugriff und Benutzerkonten während der Konfigurations- und Bereitstellungsphase der Infrastruktur definiert und nie wieder geändert, ohne dass eine neue Version der Konfiguration als vollständiger Ersatz bereitgestellt wird. Unternehmen, die häufig Zugriff auf Systeme gewähren oder entziehen müssen, sollten alternative Verwaltungsmuster in Betracht ziehen, anstatt ihre Flotte jedes Mal zu ersetzen, wenn ein neuer Benutzer hinzugefügt wird. In Teil 2 dieses Artikels werden verschiedene Implementierungsmuster, die für den Zugriff auf die Infrastruktur und die Verwaltung verwendet werden können, genauer untersucht.
Verbesserung der operativen Ergebnisse
Die Verbesserung der operativen Ergebnisse bei Softwareimplementierungen sollte ein Hauptaugenmerk für jede technische Organisation sein. Eine der wichtigsten DORA-Kennzahlen ist die „Change Failure Rate“: der Prozentsatz der Einsätze, die in der Produktion zu einem Fehler führen. Niedrige Änderungsfehlerraten sind ein sicherer Indikator für eine gesunde Softwareentwicklungs- und Betriebsumgebung.
Betrachten Sie eine hypothetische Softwarebereitstellung in einem großen, verteilten System. In der alten, veränderlichen Infrastruktur durften sich kleine Änderungen und Optimierungen im Laufe der Zeit ansammeln. Dies führte zu einer Konfigurationsabweichung, d. h., die laufenden Systeme spiegeln nicht mehr den anerkannten, von den Entwicklern und dem Betriebspersonal definierten Konfigurationszustand wider. Änderungen oder Implementierungen am System führen zu unerwartetem Verhalten und Fehlern, die in Tests nicht angemessen modelliert werden können, da es keine homogenen Umgebungen gibt. Die Bereitstellung führt zu einem Ausfall in der Produktion, und die Techniker müssen sich abmühen, die Ursache zu ermitteln. Ein Rollback auf einen funktionierenden Zustand ist nahezu unmöglich, da der definierte Arbeitszustand nicht der Realität entspricht.
Bei einer unveränderlichen Bereitstellung ist der aktuelle Arbeitszustand der Infrastruktur- und Anwendungskomponenten bekannt und definiert; alles ist eindeutig mit Commit-Hashes und Versionsnummern gekennzeichnet. Wenn eine neue Softwareimplementierung oder eine Infrastrukturänderung zu einem Produktionsausfall führt, ist es einfach, die fehlerhafte Änderung zu identifizieren. Beim Rollback wird einfach der vorherige bekannte Arbeitszustand wiederhergestellt. Die Möglichkeit, die mittlere Zeit bis zur Problemlösung („Mean Time to Resolution“, MTTR) zu minimieren, ist eine weitere wichtige DORA-Kennzahl und führt zu besseren Ergebnissen für die technischen und geschäftlichen Teams.
Immutable Infrastructure in der Cloud
Moderne verteilte Softwareinfrastrukturen werden häufig in der Cloud gehostet. Cloud-Anbieter wie AWS, Azure und Google Cloud Platform bieten eine Fülle von verwalteten und nicht verwalteten Diensten an, die Startups und Unternehmen gleichermaßen für das Hosting ihrer Anwendungen nutzen können. Der öffentliche Charakter der Cloud-Infrastruktur bringt jedoch eigene Sicherheitsherausforderungen mit sich, die in einer herkömmlichen, lokalen Infrastruktur nicht unbedingt vorhanden sind. Die größere Angriffsfläche bedeutet, dass jeder Gewinn bei der Reduzierung der Komplexität auch ein Gewinn für die Sicherheit ist.
Eine unveränderliche Infrastruktur kann die Komplexität reduzieren, indem sie nicht vorgesehene Änderungen und letztlich die Konfigurationsabweichung in der Umgebung einschränkt. Dies ist ein wichtiges Sicherheitsergebnis für Cloud-Umgebungen. Die Verringerung der Komplexität führt zu einer Softwarearchitektur, die einfacher zu verwalten, zu verstehen und letztlich auch sicherer ist.
Hier ein gutes Gedankenexperiment für Softwareinfrastrukturen: Könnten Ihre Entwicklungsteams alle Zugriffsvektoren, die ein Angreifer potenziell ausnutzen könnte, korrekt aufzählen, ohne sich die aktiven, laufenden Arbeitslasten anzusehen? Live-Systeme erfordern natürlich Wartung und Sicherheitstests. Aber mit einer Immutable Infrastructure-Konfiguration können Unternehmen den Zustand kritischer Produktionssysteme vollständig nachvollziehen.
Nicht alle Cloud-Dienste sind in dieser Hinsicht gleich; es ist durchaus möglich, einen komplexen, brüchigen, veränderlichen Software-Stack auf herkömmlichen Rechendiensten wie Amazon EC2 aufzubauen. In Anlehnung an das AWS-Beispiel könnte ein Unternehmen unveränderliche Container erstellen, sie in Amazon ECR mit Build-Tags speichern und sie auf Amazon ECS bereitstellen, was eine wesentlich unveränderliche Lösung darstellt. In Teil 2 dieser Serie werden wir uns eingehender mit spezifischen Unveränderbarkeitsmustern befassen, die mit Cloud-Services implementiert werden können.
Immutable Infrastructure ist nicht nur ein Buzzword
Immutable Infrastructure ist nicht nur ein „Nice-to-have“, sondern sollte als grundlegendes Prinzip beim Aufbau einer verteilten, Cloud-basierten Anwendungsinfrastruktur betrachtet werden. Sie ermöglicht es Entwicklungsteams, große Mengen an Infrastruktur sicher und in großem Umfang zu verwalten. Die manuelle Änderungsverwaltung kommt schnell ins Stocken und führt zu Schwachstellen in veralteten, veränderbaren Infrastrukturen.
Es steht auch im Zusammenhang mit anderen wichtigen Konzepten und Praktiken in der heutigen Technik, wie Infrastructure as Code, Container-Sicherheit und DevSecOps. In Teil 2 dieser Serie werden wir uns eingehender mit unveränderlicher Infrastruktur und Web-Sicherheit beschäftigen, einschließlich einiger Beispiele und Vorteile sowie spezifischer Implementierungsmuster für Cloud-basierte Infrastruktur.
Share this post
