Einleitung
In diesem Blog möchte ich die vorhandenen Werkzeuge und Ressourcen für Authentisierung und Autorisierung bei AWS beleuchten. Um ein klareres Bild zu vermitteln, werden zusätzlich einige organisatorische Services beschrieben.
Nicht Teil dieses Blogs sind weiterführende Konzepte welche beschreiben, wie man mit diesen Werkzeugen eine Authentisierung und Autorisierung für eine Organisation umsetzt.
Die Werkzeuge werden buttom-up beschrieben.
Identifikation von Ressourcen
Bei AWS bezeichnet man jegliche Elemente als Ressource. Dies kann eine Datenbank sein, aber auch eine Policy für die Autorisierung. Ressourcen werden durch eine ARN identifiziert. Die Notation einer ARN setzt sich folgendermassen zusammen: arn:partition:service:region:account-id:resource-type:resource-id. Also z.B. arn:aws:rds:eu-west-1:111111111111:db:my-database-instance. Für die Referenzierung von Ressourcen (beispielsweise bei Policies) können auch Platzhalter verwendet werden. Wobei „*“ für eine beliebige Anzahl von beliebigen Zeichen steht, und „?“ für genau ein beliebiges Zeichen.
IAM
Dies ist der Name des AWS Service für die Verwaltung von Benutzern und Berechtigungen.
Principal
Bei AWS werden Benutzer, Gruppen, Rollen als Principal bezeichnet. Auch Services besitzen ein Principal. Principals stellen Akteure dar, für welche es gilt Berechtigungen zu definieren.
IAM Policies
Es gibt verschiedene Arten von Policies. Jedoch sind wohl wichtigsten die Identity/Principal basierenden, welche einem Principal angefügt werden können. Und die Ressourcen basierten, bei welchen man Ressourcen als Ausgangspunkt für Berechtigung verwendet. Die Identity/Principal basierten Policies können wiederverwendbar erstellt werden, sodass man z.B. mehreren Rollen den schreibenden Zugriff auf ein S3 Bucket gewährt. Obwohl solche, Identity/Principal basierten Policies ebenfalls an Benutzer und Gruppen angefügt werden können, ist es jedoch empfehlenswert diese bei Möglichkeit lediglich Rollen anzufügen, um die Wiederverwendbarkeit weiter zu erhöhen und den Verwaltungsaufwand zu mindern, da gerade Benutzer im Vergleich öfters ändern als Rollen. AWS stellt eine Vielzahl an vordefinierten Policies zur Verfügung, diese sind jedoch oft generisch. Policies werden in JSON beschrieben.
IAM Rollen
Beschreiben Anwendungsfälle im Betrieb oder Entwicklung aus organisatorischer Sicht. Rollen können bis zu 20 Policies angefügt werden. Benutzer können für eine Sitzung mehrere bestimmte Rollen übernehmen. Eine Operation kann jedoch nur immer mit einer Rolle ausgeführt werden, bedeutet Rollen sind nicht kumulativ. Da sie wiederverwendbar sind, stellen diese ein probates Bindeglied zwischen Policies und Benutzer/Gruppen dar um die finalen Berechtigungen zu organisieren. Damit ein Benutzer oder Gruppe eine Rolle übernehmen darf, muss in für diese Rolle ein Vertrauensverhältnis (Trust relation) zu diesem Principal erstellt werden. Diese sind ebenfalls in JSON beschrieben.
IAM Benutzer und Gruppen
Benutzer stellen die Identifikation von menschlichen wie auch technischen Benutzer dar. Gruppen ermöglicht es wiederum diese organisatorisch zu gruppieren. Weiter bieten Benutzergruppen die Möglichkeit die Berechtigung für Rollen abstrakter zu definieren, anstelle dies für jeden Benutzer tun zu müssen. Für die Authentisierung von Benutzern stehen Möglichkeiten, wie klassisches Passwort auch SAML 2.0 oder OAuth zur Verfügung. Dies ermöglicht die Integration z.B. von Active Directory.
AWS Account
Ein Account bei AWS ist organisatorisch das wohl zentralste Element. Obwohl man die gesamte Organisation einer Firma innerhalb eines Accounts realisieren kann, ist es empfehlenswert einzelnen Abteilungen oder Teams separate Accounts zuzuweisen. Neben der Authentisierung und Autorisierung von Benutzern und Rollen ist ein Account ebenfalls eine wichtige Stufe für die Kostenkontrolle.
AWS Organization
Beinhaltet die Account übergreifenden Konfigurationen und ermöglicht die Definition von Policies für Accounts. Beispielsweise darf der Account von Team B nur bestimmte Services verwenden.
AWS Control Tower
Ist eine Erweiterung von Organizations. Neben Landing Zones und Dashboards gibt es auch die Möglichkeit für Account Templates. Der Control Tower erweitert ebenfalls das Regelwerk für die Verwaltung von AWS Accounts.
Fazit
Aus Erfahrung ist empfehlenswert bei der Abbildung einer Organisation in AWS bis und mit Stufe Account bereits initial eine möglichst finale Struktur zu definieren. Änderungen auf den granularen Ebenen sind zwar aufwändig, aber verhältnismässig gut umsetzbar. Dieses Thema ist ebenfalls Teil des Well-Architected Frameworks.
