Brownfield Cloud: Warum Sanierung wichtiger ist als Innovation
Fast jedes Unternehmen, mit dem ich heute ein AWS-Assessment durchführe, hat dieselbe Geschichte: Irgendwann zwischen 2018 und 2022 wurde die Cloud-Reise gestartet. Erst ein Account, dann noch einer für die neue Anwendung, dann einer für Dev, einer für Prod. Vielleicht ein paar mehr für Pilotprojekte, die nie abgeschaltet wurden. Heute existieren 15, 20, 30 Accounts. Die ursprünglichen Verantwortlichen sind nicht mehr im Unternehmen. Die Dokumentation ist lückenhaft. Und der CISO wurde erst sechs Monate nach dem ersten Incident von der Existenz mancher Accounts informiert.
Das ist kein Versagen. Das ist die normale Evolutionskurve von Cloud-Umgebungen. Aber die wenigsten Unternehmen haben eine explizite Strategie dafür, wie man diesen Zustand in den Griff bekommt, ohne die ganze Infrastruktur neu aufzubauen.
Greenfield ist in der Branche das bevorzugte Narrativ. Clean-Slate-Architektur, alles von Anfang an richtig, Landing Zone von Null. Schöne Theorie. In der Praxis ist Greenfield 2026 die Ausnahme. Der Rest lebt in Brownfield. Und Brownfield hat andere Regeln.
Ich möchte drei Muster beschreiben, die ich in Assessments immer wieder antreffe. Kein Einzelunternehmen hat alle drei. Aber ich habe noch kein Unternehmen in Brownfield-Situation gesehen, das keines davon hat.
Muster 1: Account Sprawl ohne Zuordnung
Das häufigste Muster. Niemand kann auf Anhieb sagen, welcher Account zu welchem Produkt oder Team gehört. Cost-Allocation-Tags existieren, aber nicht konsequent. Manche Accounts haben gar keine Tags. Cost Explorer zeigt eine Zahl, aber die Zuordnung zu Teams oder Projekten ist Schätzarbeit.
Warum ist das ein Security-Problem und nicht nur ein Finanzproblem? Weil Scoping Security-kritisch ist.
Wenn ein Penetrationstest oder ein Security-Incident Response-Prozess läuft, ist die erste Frage: Was ist der Scope? Welche Systeme gehören zusammen? Wo sind die Blast-Radius-Grenzen? Ohne Account-Zuordnung gibt es keine verlässliche Antwort. Der Incident-Response-Prozess wird zur Detektivarbeit in der eigenen Infrastruktur.
In einem Assessment, das ich Anfang des Jahres durchgeführt habe, hat es drei Tage gedauert, bis das Team eine vollständige Liste der Accounts mit ihren Workloads zusammenstellen konnte. Drei Tage. In einem Incident wäre das eine Katastrophe.
Die Ursache ist strukturell: Accounts wurden über Jahre einzeln angelegt, ohne zentrales Governance-Framework. AWS Organizations war nicht von Anfang an aktiviert. Oder es war aktiviert, aber OUs wurden nie sinnvoll strukturiert.
Muster 2: IAM-Schulden aus der Pilotphase
Jedes Unternehmen hat sie: Service-Accounts mit AdministratorAccess, die aus der Pilotphase übrig sind. Damals wollte jemand schnell eine Lambda-Funktion testen. Der schnellste Weg war eine Rolle mit vollen Rechten. Das hat funktioniert. Der Service ist produktiv gegangen. Die Rolle wurde nie angepasst.
Das ist kein menschliches Versagen. Das ist die logische Konsequenz eines Kontexts, in dem Geschwindigkeit vor Governance stand.
Das Problem ist, dass diese Rollen heute oft kritische Workloads tragen. Die Lambda-Funktion von 2020 mit AdministratorAccess läuft mittlerweile in Produktion, verarbeitet Kundendaten und hat Netzwerkzugang zu internen Systemen.
IAM-Schulden sind einer der am meisten unterschätzten Angriffsvektoren. Nicht weil sie schwer zu finden sind, sondern weil sie so normal aussehen. Eine Rolle mit AdministratorAccess löst keinen Alarm aus. Sie steht da, bis jemand gezielt danach sucht.
Ein konkretes Beispiel aus einem Assessment: Ich fand eine IAM-Rolle, die über drei Jahre nicht genutzt worden war. Keine Last-Used-Aktivität. Aber sie hatte Full Access auf einen S3-Bucket mit historischen Kundendaten. Kein Mensch mehr im Unternehmen konnte sagen, warum diese Rolle existierte.
Das ist der Blast-Radius, den Angreifer suchen. Nicht die aufwendig konfigurierten, gut dokumentierten Rollen. Sondern die vergessenen.
Muster 3: SCP-Lücken auf Org-Ebene
Service Control Policies sind das mächtigste Werkzeug, das AWS Organizations bietet: präventive Leitplanken, die auf Ebene der gesamten Organisation oder einzelner Organizational Units wirken. Kein Account kann von ihnen abweichen, egal welche lokalen IAM-Policies gesetzt sind.
In der Praxis sehe ich zwei Extremzustände.
Der erste: SCPs existieren nicht oder nur als symbolische Einzeiler. Die Org-Ebene ist offen, jedes Team konfiguriert, was es möchte. Security-Baseline-Anforderungen, etwa keine Public-S3-Buckets, kein Deaktivieren von CloudTrail, kein Erstellen von IAM-Rollen mit Admin-Zugang ohne Approval-Prozess, werden individuell versucht durchzusetzen, mit unterschiedlichem Erfolg.
Der zweite: SCPs wurden irgendwann in einem Burst von Governance-Aktivismus gesetzt und sind so restriktiv, dass jedes Team für jede neue Anforderung ein Exception-Ticket braucht. Das SCP-Regime wird zum Bottleneck. Teams fangen an, Workarounds zu suchen. Governance wird zum Hindernisparcours, der umgangen wird.
Beides ist ein Problem. Ein SCP-Regime, das in der Praxis nicht gelebt wird, ist kein Governance-Instrument. Es ist Papiertiger-Compliance.
Warum Brownfield-Sanierung die unterschätzte Disziplin ist
Wenn ich mit Cloud-Verantwortlichen über diese drei Muster spreche, kommt oft die gleiche Reaktion: "Ja, wir wissen davon. Aber wir haben keine Zeit, das anzugehen. Es stehen strategische Initiativen an."
Das ist das Problem.
IAM-Schulden akkumulieren Zinseszinsen. Ein nicht gepatchter Service-Account heute ist ein potenziell kompromittierter Account morgen. Ein Account ohne Zuordnung heute ist ein ungeklärter Scope-Bereich in eurem nächsten NIS2- oder C5-Audit. Eine SCP-Lücke heute ist das Blast-Radius-Einfallstor, das der nächste Penetrationstest findet.
Die Antwort ist nicht, alles neu aufzubauen. Das ist weder wirtschaftlich noch praktisch. Die Antwort ist eine strukturierte Sanierung mit den Mitteln, die AWS bereitstellt:
AWS Control Tower Enrollment von bestehenden Accounts in eine saubere Multi-Account-Struktur. Das ist möglich, ohne Workloads zu migrieren. Control Tower bringt zentrales Logging, OUs mit sinnvoller Hierarchie und einen Ausgangspunkt für konsequente SCPs.
C5 Conformance Pack in AWS Config für automatisierte Compliance-Checks gegen den C5-Kriterienkatalog. Das identifiziert technische Abweichungen kontinuierlich, nicht nur zum Audit-Zeitpunkt.
Security Hub CSPM für konsolidierte Findings über alle Accounts. Wer 20 Accounts hat und für jeden einzeln nach Security-Findings sucht, hat keine Oversight. Security Hub gibt sie.
Mit dem Cloud Governance Accelerator (CGA) wende ich diesen Ansatz auf Brownfield-Konten an: chirurgisch, ohne Komplettmigration, mit dem Ziel, C5- und NIS2-Readiness in historisch gewachsenen Umgebungen herzustellen. Das ist kein Greenfield-Projekt. Es ist Sanierung mit Methode.
Die wichtigste Frage
Greenfield-Architektur ist die Prestige-Disziplin im Cloud-Geschäft. Neue Accounts, saubere Strukturen, moderne Architekturmuster. Kein Wunder, dass sie die Aufmerksamkeit bekommt.
Aber der größte Sicherheitsgewinn pro investiertem Euro liegt für die meisten DACH-Unternehmen heute nicht in Greenfield-Innovation. Er liegt in Brownfield-Sanierung. In dem Account, der seit drei Jahren läuft, dessen Rollen nie reviewt wurden, der keine Tags hat und dessen Zugehörigkeit zu einer Business-Unit unklar ist.
Wenn Unternehmen anfangen, diese Frage als strategische Priorität zu behandeln, nicht als technische Hausaufgabe, die immer wieder verschoben wird, verändert sich das Risikoniveau schneller als durch jedes neue Security-Tool.
Habt ihr eigene Erfahrungen mit Brownfield-Assessments oder konkreten Sanierungsprojekten gemacht? Ich freue mich über den Austausch.