Cloud-Identität: IAM-Rollen und Servicekonten

In Cloud-Umgebungen ist die Identität der neue Perimeter. Jede Aktion – vom Starten einer VM über das Lesen einer Datenbank bis zum Aufrufen einer API – wird anhand der aufrufenden Identität autorisiert. Cloud-IAM-Systeme (Identity and Access Management) legen fest, wer was auf welchen Ressourcen tun darf. Anders als in On-Premises-Umgebungen, in denen der Netzwerkstandort implizites Vertrauen vermittelte, behandelt Cloud-IAM jede Anfrage unabhängig von ihrem Ursprung als zugriffspflichtig und verlangt eine ausdrückliche Autorisierung.

AWS IAM kennt drei primäre Identitätstypen. IAM Users stehen für einzelne Personen oder Anwendungen mit langfristig gültigen Zugangsdaten (Zugriffsschlüssel + geheimer Schlüssel). IAM Groups fassen Benutzer zusammen und weisen ihnen gemeinsame Berechtigungen zu. IAM Roles sind Identitäten mit temporären Zugangsdaten, die von Benutzern, AWS-Diensten (EC2, Lambda) oder anderen Konten übernommen werden können. Rollen sind langfristig gültigen Zugriffsschlüsseln vorzuziehen, da ihre Zugangsdaten automatisch ablaufen und dadurch das Risiko einer Offenlegung verringert wird.

IAM-Richtlinien legen fest, welche Aktionen eine Identität auf welchen Ressourcen ausführen darf. Das Prinzip der geringsten Rechte verlangt, dass Richtlinien nur die für eine Aufgabe erforderlichen Aktionen gewähren. Häufige Verstöße sind die Verwendung von *-Wildcards für Aktionen (gewährt alle Aktionen eines Dienstes), die Verwendung von * für Ressourcen (gewährt Zugriff auf alle Ressourcen) und das Zuweisen übermäßig weitreichender verwalteter Richtlinien wie AdministratorAccess zu Servicekonten. Jede Wildcard sollte begründet und regelmäßig überprüft werden.

In Google Cloud Platform (GCP) authentifizieren sich nichtmenschliche Workloads mithilfe von Dienstkonten – verwalteten Identitäten mit JSON-Schlüsseldateien oder Workload Identity Federation. Für jedes Dienstkonto sollte das Prinzip der geringsten Privilegien gelten: Binden Sie es nur an die GCP-Dienste, die es aufrufen muss. Dienstkontoschlüssel (aus der Konsole heruntergeladene JSON-Dateien) sind langlebige Zugangsdaten und müssen wie Passwörter behandelt werden: regelmäßig rotieren und niemals in den Quellcode übernehmen oder in öffentliche Repositories hochladen.

Verwaltete Identitäten in Azure (früher MSI) sind das Azure-Gegenstück zu AWS-IAM-Rollen für Dienste. Sie ermöglichen es Azure-Ressourcen (VMs, App Services, Functions), sich ohne gespeicherte Zugangsdaten bei Azure-APIs zu authentifizieren. Es gibt zwei Typen: vom System zugewiesene verwaltete Identitäten sind an eine bestimmte Ressource gebunden und werden gelöscht, wenn die Ressource gelöscht wird. Vom Benutzer zugewiesene verwaltete Identitäten sind eigenständige Objekte, die von mehreren Ressourcen gemeinsam verwendet werden können. Verwaltete Identitäten machen gespeicherte Schlüssel oder Secrets überflüssig.

Langlebige Zugangsdaten – statische Zugriffsschlüssel, API-Tokens und Dienstkontoschlüsseldateien, die niemals ablaufen – gehören zu den größten Risikofaktoren in Cloud-Umgebungen. Wenn sie offengelegt werden (etwa über GitHub, einen S3-Bucket, Protokolle oder einen kompromittierten Laptop eines Entwicklers), gewähren diese Zugangsdaten sofortigen Zugriff, bis sie manuell widerrufen werden. Unternehmen sollten alle langlebigen Zugangsdaten prüfen, sie nach einem festen Zeitplan rotieren, rollenbasierte oder föderierte Zugriffe bevorzugen, die kurzlebige Tokens erzeugen, und sofort alarmieren, wenn Zugangsdaten in öffentlichen Repositories auftauchen.

Eine IAM-Rechteausweitung liegt vor, wenn eine Identität eine Kombination von Berechtigungen verwendet, um sich zusätzliche Berechtigungen zu gewähren. Zu den klassischen Pfaden der Rechteausweitung gehören: eine umfangreichere Policy an den eigenen Benutzer anhängen, einen neuen IAM-Benutzer mit erweiterten Berechtigungen erstellen, eine Rolle (iam:PassRole) an einen Dienst übergeben und die Ausführungsrolle einer Lambda-Funktion aktualisieren. Der AWS IAM Access Analyzer kann solche Muster erkennen, und IAM-Berechtigungsgrenzen können die maximalen Berechtigungen, die einer Identität gewährt werden dürfen, strikt begrenzen.

Cloud-Organisationen verwenden häufig mehrere Konten (Entwicklung, Staging, Produktion, Sicherheit), um die Auswirkungen von Sicherheitsvorfällen zu begrenzen. Die kontoübergreifende Übernahme von Rollen ermöglicht es Identitäten in einem Konto, Rollen in einem anderen Konto zu übernehmen, sodass zentralisierte Tools kontenübergreifend arbeiten können. Zu den Sicherheitskontrollen gehören: eine External ID in der Vertrauensrichtlinie zu verlangen, um Confused-Deputy-Angriffe zu verhindern, über die Principal-ARN einzuschränken, welche Konten eine Rolle übernehmen dürfen, und alle kontoübergreifenden Rollenübernahmen zu Prüfzwecken in CloudTrail zu protokollieren.

AWS-EC2-Instanzen können die Zugangsdaten ihrer IAM-Rolle über den Instance Metadata Service (IMDS) unter http://169.254.169.254 abrufen. Die SSRF-Schwachstellenklasse ist hier besonders gefährlich: Ist eine Anwendung für SSRF anfällig, kann ein Angreifer die Zugangsdaten der IAM-Rolle der Instanz exfiltrieren, indem er den Server dazu bringt, die IMDS-URL abzurufen. IMDSv2 (das ein Sitzungstoken voraussetzt) mindert den auf SSRF basierenden Diebstahl von Zugangsdaten und sollte auf allen EC2-Instanzen erzwungen werden.

IAM Access Analyzer (AWS) erkennt automatisch Ressourcen, die mit externen Principals geteilt werden, sowie IAM-Policies, die mehr Berechtigungen gewähren als beabsichtigt. Das Tool analysiert Bucket-Policies, Vertrauensrichtlinien von Rollen und KMS-Schlüssel-Policies, um externen Zugriff zu kennzeichnen, der nicht ausdrücklich vorgesehen war. Regelmäßige Prüfungen von IAM-Policies – manuell oder mit Tools wie Cloudsplaining, PMapper oder Permissions Boundary Analyzer – sind unerlässlich, um Pfade zur Rechteausweitung zu erkennen, bevor Angreifer sie finden.

Workload Identity Federation ermöglicht es externen Workloads (GitHub Actions, lokalen Systemen und anderen Cloud-Anbietern), sich mit kurzlebigen OIDC-Tokens statt mit langlebigen Dienstkontoschlüsseln bei Cloud-IAM zu authentifizieren. Ein GitHub-Actions-Workflow kann mithilfe seines OIDC-Tokens für die Dauer des Jobs eine AWS-IAM-Rolle übernehmen; anschließend läuft das Token ab. Dieser Ansatz beseitigt die gesamte Klasse der Leaks langlebiger Zugangsdaten aus CI/CD-Pipelines.

In dieser Lektion haben Sie gelernt: IAM-Rollen stellen temporäre Zugangsdaten bereit und werden für Cloud-Workloads gegenüber langlebigen Zugriffsschlüsseln bevorzugt, Policies nach dem Prinzip der geringsten Privilegien sollten Wildcards vermeiden und nur bestimmte Aktionen für bestimmte Ressourcen erlauben und IMDSv2, Berechtigungsgrenzen und Workload Identity Federation beseitigen gängige Wege zur Offenlegung von Zugangsdaten. Als Nächstes befassen wir uns mit Cloud Security Posture Management (CSPM).