[{"data":1,"prerenderedAt":183},["ShallowReactive",2],{"service-articles-de-aws-security-foundation":3},[4],{"id":5,"title":6,"body":7,"category":170,"date":171,"description":13,"extension":172,"meta":173,"navigation":174,"order":156,"path":175,"published":176,"seo":177,"service":178,"stem":179,"summary":180,"updated":181,"__hash__":182},"blog\u002Fblog\u002Faws-multi-account-terraform.md","AWS-Multi-Account-Struktur mit Terraform sicher aufbauen",{"type":8,"value":9,"toc":154},"minimark",[10,14,19,38,42,45,48,53,56,59,63,66,93,96,100,103,107,110,114,122,125,129,132,135,138,142,145],[11,12,13],"p",{},"Viele Unternehmen betreiben Produktion, Tests und interne Werkzeuge in einem einzigen AWS-Account. Das geht so lange gut, bis eine falsche Berechtigung oder ein kompromittierter Zugang alles auf einmal gefährdet. Eine saubere Account-Struktur verhindert genau das, und mit Terraform bleibt sie auch bei wachsender Größe beherrschbar.",[15,16,18],"h2",{"id":17},"das-wichtigste-in-kürze","Das Wichtigste in Kürze",[20,21,22,26,29,32,35],"ul",{},[23,24,25],"li",{},"Eine Account-Grenze isoliert Fehler und Angriffe stärker, als es eine IAM-Policy allein kann.",[23,27,28],{},"Vier Account-Typen decken die meisten realen Bedürfnisse ab: Management, Security mit Log-Archiv, Shared Services und je ein Workload-Account pro Umgebung.",[23,30,31],{},"Terraform-Module mit getrenntem State pro Account halten die Struktur wartbar, während sie wächst.",[23,33,34],{},"Änderungen an produktiven Accounts laufen ausschließlich über eine geprüfte Pipeline, nie per manuellem Apply vom Laptop.",[23,36,37],{},"Zentrales, unveränderliches Logging in einem eigenen Account sorgt dafür, dass ein kompromittierter Account seine Spuren nicht löschen kann.",[15,39,41],{"id":40},"warum-ein-einzelner-aws-account-nicht-reicht","Warum ein einzelner AWS-Account nicht reicht",[11,43,44],{},"Am Anfang ist es verlockend, alles in einem einzigen AWS-Account laufen zu lassen und die Trennung IAM-Policies und Tags zu überlassen. Von diesem Modell bin ich jedes Mal wieder abgerückt, denn eine Account-Grenze isoliert grundlegend stärker als eine Policy.",[11,46,47],{},"Eine falsch konfigurierte IAM-Policy oder ein kompromittiertes Credential hat in einem Single-Account-Setup einen Blast-Radius, der die gesamte Umgebung umfasst. Produktion, Staging und geteiltes Tooling liegen alle hinter demselben Perimeter.",[49,50,52],"h3",{"id":51},"was-account-grenzen-leisten","Was Account-Grenzen leisten",[11,54,55],{},"Verteilt man diese Workloads auf getrennte Accounts, kann ein Fehler in einer Umgebung eine andere schlicht nicht erreichen. Es gibt keine Policy, mit der man sich an einer harten Account-Grenze vorbeikonfigurieren könnte.",[11,57,58],{},"Zwei weitere Vorteile ergeben sich gleich mit. Least Privilege wird leichter nachvollziehbar, weil Berechtigungen auf den Inhalt eines Accounts begrenzt sind, statt Ressource für Ressource aufgezählt zu werden. Und die Kostenzuordnung wird trivial: Jeder Euro in einem Account gehört einem bekannten Team oder Workload, ohne dass Tagging-Disziplin die Hauptarbeit leisten muss.",[15,60,62],{"id":61},"eine-pragmatische-aws-account-struktur","Eine pragmatische AWS-Account-Struktur",[11,64,65],{},"Die Struktur, auf die ich standardmäßig setze, besteht aus vier Bausteinen:",[20,67,68,75,81,87],{},[23,69,70,74],{},[71,72,73],"strong",{},"Management-Account"," an der Wurzel, ausschließlich für Billing und organisationsweite Policies.",[23,76,77,80],{},[71,78,79],{},"Security- und Log-Archiv-Account",", der Read-only-Kopien der Logs aller anderen Accounts erhält und selbst keine Workloads hält.",[23,82,83,86],{},[71,84,85],{},"Shared-Services-Account"," für Dinge wie eine Container-Registry oder CI-Runner, die jede Umgebung braucht, aber nicht selbst besitzen sollte.",[23,88,89,92],{},[71,90,91],{},"Workload-Accounts pro Umgebung"," (Dev, Staging, Produktion), jeweils voneinander isoliert.",[11,94,95],{},"Das ist nicht exotisch. Die Struktur spiegelt, was AWS Organizations und AWS Control Tower ohnehin erwarten. Sie hält auch das mentale Modell einfach: Wer den Account benennen kann, weiß, was in ihm erlaubt ist.",[15,97,99],{"id":98},"terraform-das-mit-ihrer-account-struktur-skaliert","Terraform, das mit Ihrer Account-Struktur skaliert",[11,101,102],{},"Von Hand ist das ab mehr als zwei oder drei Accounts nicht mehr handhabbar. Deshalb bilde ich die gesamte Struktur in Terraform ab.",[49,104,106],{"id":105},"wiederverwendbare-module-und-getrennter-state","Wiederverwendbare Module und getrennter State",[11,108,109],{},"Wiederverwendbare Module decken die Teile ab, die sich über Accounts hinweg wiederholen: Networking, IAM-Baselines und Logging. Der State ist pro Account und Umgebung getrennt, damit eine Änderung in Staging niemals den State von Produktion berühren kann.",[49,111,113],{"id":112},"keine-manuellen-änderungen-an-produktion","Keine manuellen Änderungen an Produktion",[11,115,116,117,121],{},"Rollouts sind end-to-end automatisiert. Es gibt kein manuelles ",[118,119,120],"code",{},"terraform apply"," von jemandes Laptop gegen einen produktiven Account. Muss sich etwas ändern, geschieht das jedes Mal über dieselbe geprüfte Pipeline.",[11,123,124],{},"Erst das macht die Account-Struktur vertrauenswürdig, denn die Isolation ist nur so gut wie der Prozess, der sie pflegt.",[15,126,128],{"id":127},"iam-und-zentrales-logging-als-fundament","IAM und zentrales Logging als Fundament",[11,130,131],{},"Innerhalb dieser Struktur halte ich IAM-Rollen standardmäßig nach Least Privilege. Service-Rollen bekommen exakt die Berechtigungen, die ihr Workload braucht, und nichts wird \"vorsichtshalber\" vergeben.",[11,133,134],{},"Jeder Account schickt seine CloudTrail- und CloudWatch-Logs an den zentralen Log-Archiv-Account. Dort sind sie aus Sicht der erzeugenden Accounts unveränderlich.",[11,136,137],{},"Diese Kombination bedeutet, dass ein kompromittierter Workload-Account seine eigenen Spuren nicht löschen kann. Die Analyse, was passiert ist, hängt nie davon ab, dem untersuchten Account zu vertrauen.",[15,139,141],{"id":140},"was-das-für-ihr-unternehmen-heißt","Was das für Ihr Unternehmen heißt",[11,143,144],{},"Für die Geschäftsführung läuft eine saubere Account-Struktur auf eine einfache Frage hinaus: Wie groß wird der Schaden, wenn etwas schiefgeht? In einem einzelnen Account betrifft ein Fehler oder ein Angriff potenziell alles, also Produktion, Testumgebungen und interne Werkzeuge zugleich. Mit getrennten Accounts bleibt er auf einen Bereich begrenzt, und das zentrale Log-Archiv liefert belastbare Nachweise darüber, was passiert ist.",[11,146,147,148,153],{},"Das zahlt sich spätestens dann aus, wenn Kunden, Versicherer oder Prüfer nach Ihren Sicherheitsmaßnahmen fragen, etwa im Zusammenhang mit NIS2. Wo Ihre eigene AWS-Umgebung heute steht, können Sie mit dem ",[149,150,152],"a",{"href":151},"\u002Ftools\u002Faws-security-check","kostenlosen AWS-Sicherheits-Check"," einschätzen.",{"title":155,"searchDepth":156,"depth":156,"links":157},"",2,[158,159,163,164,168,169],{"id":17,"depth":156,"text":18},{"id":40,"depth":156,"text":41,"children":160},[161],{"id":51,"depth":162,"text":52},3,{"id":61,"depth":156,"text":62},{"id":98,"depth":156,"text":99,"children":165},[166,167],{"id":105,"depth":162,"text":106},{"id":112,"depth":162,"text":113},{"id":127,"depth":156,"text":128},{"id":140,"depth":156,"text":141},"Artikel","28. Juli 2026","md",{},true,"\u002Fblog\u002Faws-multi-account-terraform","2026-07-28",{"title":6,"description":13},"aws-security-foundation","blog\u002Faws-multi-account-terraform","Eine AWS-Multi-Account-Struktur mit Terraform begrenzt den Schaden durch Fehler und Angriffe. Welche Accounts Sie brauchen und wie zentrales Logging hilft.","2026-11-06","i4yZLLUMONUEfIRZ0R8zTFZJmLXsIhWay7hHZpT_Ndo",1794305788748]