Identity and Access Management (IAM) legt fest, welche Identität sich authentifizieren kann und welche Aktionen diese Identität an einer bestimmten Ressource ausführen darf. In einer Multi-Cloud-Umgebung kann ein unternehmensweiter Identitätsanbieter die Anmeldung der Belegschaft ermöglichen, während AWS, Azure und Google Cloud jeweils eigene Autorisierungsentscheidungen innerhalb ihrer jeweiligen administrativen Grenzen treffen. Eine erfolgreiche Anmeldung autorisiert für sich genommen noch keinen API-Zugriff auf eine Ressource. Bei AWS wird das SSO für die Belegschaft üblicherweise über das IAM Identity Center konfiguriert; IAM-Rollen stellen in Verbindung mit dem AWS Security Token Service (STS) die daraus resultierenden temporären Zugangsdaten aus.
[Quellen][/Quellen]
Eine sinnvolle Abgrenzung verläuft zwischen dem Identitätsanbieter, der Control Plane der jeweiligen Cloud und der Data Plane der jeweiligen Cloud. Eine Control Plane verwaltet Cloud-Ressourcen und deren Konfiguration. Eine Data Plane verarbeitet Anfragen an die Ressourcen selbst; bei einer solchen Anfrage bewertet die jeweilige Cloud Principal, Aktion, Ressource und relevante Bedingungen innerhalb ihres eigenen IAM-Systems. Diese Ebenen tauschen zwar möglicherweise Identitätsinformationen aus, nutzen jedoch keinen gemeinsamen, universellen Berechtigungssatz.
[Quellen][/Quellen]
Damit lassen sich die Grenzen der Anmeldung nachvollziehen, ohne dass daraus automatisch auf einen Ressourcenzugriff geschlossen wird.
[Quellen][/Quellen]
Probleme bei IAM-Implementierungen in Multi-Cloud-Umgebungen haben oft ihren Ursprung in Begriffen, die zwar vertraut klingen, aber unterschiedliche Gültigkeitsbereiche (Scopes) haben. Ein AWS-Konto stellt eine administrative Grenze für AWS-Ressourcen dar. Ein Azure-Tenant bildet die Grenze für das Microsoft Entra ID-Verzeichnis, während der Zugriff auf Azure-Ressourcen üblicherweise über die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) auf Ebene von Verwaltungsgruppen, Abonnements, Ressourcengruppen oder einzelnen Ressourcen geregelt wird. In der Google Cloud bilden Organisation und Projekt jeweils eigene Bereiche für die Zuweisung von Cloud-IAM-Richtlinien und die Eigentümerschaft an Ressourcen.
Diese Unterscheidung ist wichtig, da die Zugehörigkeit zu einer Identitätsgruppe nicht automatisch eine Berechtigung für eine Ressource bedeutet. In Azure kann Microsoft Entra ID zwar einen Benutzer authentifizieren und dessen Gruppenzugehörigkeit offenlegen, doch muss Azure RBAC zusätzlich eine entsprechende Rolle zuweisen, um die angeforderte Azure-Aktion zu autorisieren. Bei AWS wirken Richtlinien von AWS Identity and Access Management (IAM) sowie Anmeldeinformationen des AWS Security Token Service (STS) an der Autorisierung mit. In der Google Cloud wertet Cloud IAM die Richtlinienbindungen für die jeweilige Ressourcenhierarchie aus. Ähnlich klingende Gruppennamen führen nicht zu identischen Zugriffsrechten über diese Grenzen hinweg.
Auch Nachweise aus dem laufenden Betrieb sind an bestimmte Bereiche gebunden. Ein Anmeldeereignis beim Identitätsanbieter des Unternehmens belegt zwar die erfolgte Authentifizierung, reicht aber für sich genommen nicht aus, um zu bestätigen, dass AWS, Azure oder Google Cloud eine nachfolgende API-Anfrage zugelassen haben. Ein Audit-Protokoll der Cloud kann zwar einen Zugriffsversuch auf die Steuerungsebene (Control Plane) oder die Ressourcen-API dieser Cloud aufzeigen, belegt jedoch nicht die Korrektheit der Lebenszyklusdaten beim Identitätsanbieter des Unternehmens. Erforderlich sind Nachweise von der Ebene, die die Entscheidung getroffen hat – einschließlich Informationen zu Identität, Ressource, Aktion und Zeitfenster.
Entscheidungsregel Analysieren Sie Zugriffe jeweils für eine Cloud und eine Anfrage nach der anderen. Identifizieren Sie zunächst den Principal (die Identität), die Zielressource, die API-Aktion und die Autorisierungsebene, die die Prüfung durchgeführt hat.
Anstatt alle Identitäten gleich zu behandeln, verwenden wir eine klar abgegrenzte Workload. Der Dienst orders-api lauscht auf Port 8080. Eine Workforce-Identität, orders-workforce-user, repräsentiert einen Operator, der interaktiven Zugriff über den Identitätsanbieter des Unternehmens benötigt. Die Gruppe app-operators steht für die vorgesehene operative Rolle, während cloud-admins bewusst davon getrennt ist, da administrativer Zugriff mit anderen Risiken und Genehmigungsverfahren verbunden ist.
Die automatisierte Identität lautet orders-ci und repräsentiert einen Continuous-Integration-Job, der die Workload bereitstellt oder verwaltet. Ihre Anfragen sind keine Browser-Sitzungen von Mitarbeitern. Anstatt langlebige Cloud-Zugriffsschlüssel zu verwenden, erhält sie für jede Cloud kurzlebige, föderierte Anmeldeinformationen. Unsere Provider-Grenzen sind das AWS-Konto dev, der Azure-Mandant contoso und das Google Cloud-Projekt orders-prod; jede spätere Autorisierungsanfrage muss eines dieser Ziele explizit benennen.
Wir können nun untersuchen, wie die Identitätspfade für Workforce und CI die jeweilige Cloud erreichen.