Die Skalierung von Terraform über organisatorische Grenzen hinweg erfordert eine sorgfältige Balance zwischen Standardisierung und Flexibilität. Durch klare Team-Strukturen, durchdachte Governance, automatisierte CI/CD-Prozesse und geeignete Tooling-Unterstützung können auch komplexe Multi-Tenant-Infrastrukturen effektiv verwaltet werden. Mit diesem Fundament können Sie Ihre Terraform-Praxis von einzelnen Teams auf die gesamte Organisation ausweiten und dabei Konsistenz, Sicherheit und Effizienz gewährleisten.

Dies ist der erste Teil einer Serie über die Konzeption von Mandantenfähigkeit als Infrastructure-as-Code in großen Infrastrukturen.

Am 19. Juli 2024 führte ein schwerwiegender IT-Ausfall, der auf ein fehlerhaftes Update der Falcon-Pattform von CrowdStrike zurückzuführen war, zu weitreichenden Störungen in verschiedenen Sektoren, darunter Flugverkehr, Krankenhäuser und Regierungsbehörden. Diese Plattform soll die Sicherheit erhöhen, indem Sie Angriffe in Echtzeit unterbindet. Dazu werden Messpunkte tief im Serversystem verdrahtet und dazu werden die höchsten Admin-Privilegien auf diesen System selbst benötigt. Dieser Ansatz an sich ist bereits fragwürdig, aber es wurde noch eine zusätzliche Angriffsfläche integriert: Diese Sensoren, die tief in Systemabläufe zur Sicherheitsüberwachung integriert sind, erhielten Updates über ein von Crowdstrike gesteuertes globales Verteilungssystem - implementiert mit der guten Absicht, eine möglichst konsistente globale Sicherheitsabdeckung zu erreichen, indem man nicht vergebens darauf wartet, dass die Kunden selbst tätig werden.

Ein solcher zentralisierter Ansatz stellt natürlich nur dann kein Problem dar, wenn er auch funktioniert und nichts kaputt macht.

Aber genau das ist passiert - ein fehlerhaftes Update wurde großflächig auf Serversysteme verteilt, die unter Microsoft Windows liefen. Durch die tiefe Integration in die Systeme hagelte es aufgrund einer fehlerhaften Library (sensorsvc.dll) die als Blue Screens bekannten Kernel Panics und durch diesen "Single Point of Failure" wurde die angestrebte konsistente globale Sicherheitslage zu einem globalen Ausfall. Besonders betroffen waren Fluggesellschaften - es wurden etwa 1.500 Flüge gestrichen -, Banken, Einzelhandel und Gesundheitswesen. Das Update wurde zwar zurückgezogen, aber die Serversysteme mussten im abgesicherten Modus manuell repariert werden. Dieser Vorfall verdeutlichte die Verwundbarkeiten zentralisierter Update-Verteilungssysteme und die Kettenreaktionen, die durch einen solchen "Single Point of Failure" entstehen können.

Und noch mehr wurde deutlich, was passieren kann, wenn auf grundliegende Maßnahmen zur Absicherung gegen Ausfälle verzichtet: Robustes Service-Health-Monitoring mit automatisierten Failovern, Mechanismen zur Eingrenzung des Blast Radius und umfassende Disaster-Recovery-Fähigkeiten. Diejenigen Kunden, welche so weit gedacht hatten, konnten einfach ihre Standby-Systeme aktivieren. Aber kaum jemand hatte so weit gedacht. Dabei werden solche architektonische Prinzipien für geschäftskritische Systeme zunehmend unerlässlich.