Wer mit AWS arbeitet, arbeitet üblicherweise nicht nur mit einem Account. Das hat mehrere Vorteile und wird auch von AWS als best practice genannt. Warum hat man mehrere Accounts? So lassen sich zum Beispiel Workloads nach Team und Geschäftsbereich aufteilen. Man hat die Möglichkeit die accounts je nach Umgebung unterschiedlich abzusichern (In der Entwicklungsumgebung geht es eher um die Iterationsgeschwindigkeit, dort kann mehr erlaubt werden um die Entwickler nicht zu blockieren. In der Produktionsumgebung wiederum sollen weniger Personen Zugriff haben und die Produktionsdaten müssen strikt abgesichert sein).

Ausserdem helfen mehrere Accounts dabei den blast radius zu reduzieren wenn es einen Vorfall gibt. Ebenso erlaubt es einen besseren Überblick über Kosten, die den teams und Geschäftsbereichen zugewiesen werden können.

Hier sind einige Best Practices um die Multi-Account AWS Struktur abzusichern:

AWS Organisation einrichten Link zu Überschrift

AWS Organisations ist ein Service, den AWS 2017 gestartet hat um das Verwalten von mehreren Accounts zu vereinfachen und es gibt keinen Grund es nicht zu benutzen. Hier wird ein Account als Management Account ausgewählt, der an der Spitze der Organisation steht. Weitere Accounts lassen sich per Knopfdruck erstellen oder in die Organisation einladen. Accounts können sogenannten Organisational Units (OUs) zugewiesen werden um das Verwalten zu vereinfachen. Wichtig zu erwähnen ist, dass kein impliziter trust zwischen accounts aufgebaut wird wenn sie in der selben Organisation leben. Jede Verbindung zwischen Accounts muss explizit und nachverfolgbar erstellt werden.

AWS Control Tower: ja oder nein? Link zu Überschrift

Control Tower (CT) ist ein Service, der AWS Organisations erweitert und Accounts mit vorgegebenen governance Leitplanken und Sicherheitsfunktionen erstellen kann. CT kommt mit vielen Funktionen out-of-the-box, ist allerdings ziemlich opinionated und nicht sehr flexibel. Ausserdem kann das Erstellen neuer Accounts bis zu einer Stunde in Anspruch nehmen. Ob das das Richtige ist muss in jedem Fall separat beurteilt werden.

Root User absperren Link zu Überschrift

Der Management Account der Organisation sollte so weit wie möglich abgesichert und so wenig wie möglich benutzt werden. Ein Grund dafür ist dass Sicherheitsmechanismen wie Service Control Policies (siehe unten) für diesen Account nicht greifen.

Funktionen, die eigentlich dem Management Account vorbehalten sind lassen sich an andere Accounts delegieren. Beispiele hier sind das Erstellen von Organisationsweiten Backup policies oder das Verwalten von organisationsweiten Sicherheitsstandards und Befunden.

Service Control Policies einsetzen Link zu Überschrift

SCPs erlauben das Erstellen von Richtlinien, die accountweit oder in ganzen OUs aktiv sind. Beispiele hier sind das Erstellen von Ressourcen in bestimmten Regionen zu verbieten, Virtuelle Maschinen nur von einem bestimmten Typ zu erlauben oder das Ressourcenerstellen nur zu erlauben, wenn ein organisationsId-tag festgelegt wurde.

Sinnvolle SCPs lassen sich im Internet finden, so zum Beispiel hier.

Logs und Backups in abgesicherte Accounts schicken Link zu Überschrift

Wird ein Account kompromittiert und hat der Angreifer weitläufige Befugnisse ist es ein Leichtes für ihn seine Spuren zu verwischen indem er alle Logs im befallenen Account einfach löscht. Werden diese Logs allerdings bereits in einen Audit-Account weitergeleitet (der mit SCPs zusätzlich keine Löschungen erlaubt) so wird es schwieriger.

Dasselbe gilt für Backups in Ransomware-Attacken. Liegen diese sicher in einem anderen Account lassen sich Workloads wiederherstellen.

Weitere Dinge die in einem Audit-Account landen sollten sind Cloudtrail logs, cloudwatch logs, VPC flow logs und Config logs sowie SecurityHub und GuardDuty Ergebnisse.

IAM zentralisieren mit Identity Center Link zu Überschrift

Seit 2017 gibt es einen Single Sign On (SSO) Service in AWS, der 2022 in AWS Identity Center umbenannt wurde. Damit lassen sich Zugänge zentralisieren und verwalten. Benutzer und Gruppen lassen sich entweder direkt über den Identity Center verwalten oder über einen SAML Identity Provider wie Microsoft Entra.

Hier sollte man für alle Nutzer Multifactor Authentication (MFA) verpflichtend machen. Eine weitere Idee ist das Erstellen von IAM users (iam:createuser) via SCPs zu verbieten.