Kontenübergreifende Rollen und Ressourcenrichtlinien

Reale Architekturen erstrecken sich über mehrere Konten: ein Produktionskonto, ein Protokollierungskonto und ein Konto für gemeinsam genutzte Services. Workloads und Personen müssen häufig auf Ressourcen über diese Grenzen hinweg zugreifen.

Der sichere Weg besteht niemals darin, Anmeldeinformationen zwischen Konten zu kopieren. Stattdessen gewähren Sie einen begrenzten Zugriff über kontoübergreifende Rollen oder ressourcenbasierte Richtlinien.

Das häufigste Muster ist eine Rolle im Zielkonto, die ein Principal im Quellkonto übernimmt.

• Die Vertrauensrichtlinie der Rolle nennt das Quellkonto oder den Principal.
• Der Principal im Quellkonto ruft AssumeRole auf und erhält temporäre Anmeldeinformationen.
• Anschließend arbeitet er im Zielkonto im Rahmen der Berechtigungen dieser Rolle.

Damit eine Rolle kontoübergreifend übernommen werden kann, müssen beide Seiten dies erlauben:

• Die Vertrauensrichtlinie der Zielrolle erlaubt den Principal des Quellkontos.
• Die Identitätsrichtlinie des Quell-Principals erlaubt sts:AssumeRole für diese Rolle.

Fehlt eine der beiden Voraussetzungen, schlägt die Übernahme fehl. Diese doppelte Prüfung ist ein häufiger Prüfungsaspekt.

Einige Services unterstützen ressourcenbasierte Richtlinien, die direkt an die Ressource angefügt werden, beispielsweise eine S3-Bucket-Richtlinie, eine KMS-Schlüsselrichtlinie oder eine SQS-Warteschlangenrichtlinie.

Damit kann einem Principal in einem anderen Konto Zugriff gewährt werden, ohne dass dieser eine Rolle übernehmen muss. Das externe Konto verwendet seine eigene Identität, und die Ressourcenrichtlinie autorisiert sie.

Wählen Sie den Mechanismus abhängig vom Service:

• Verwenden Sie für Services ohne Ressourcenrichtlinie (EC2, die meisten APIs) eine kontoübergreifende Rolle.
• Für S3, KMS, SNS, SQS, Lambda und andere Services kann eine Ressourcenrichtlinie direkten kontoübergreifenden Zugriff gewähren.

Ressourcenrichtlinien vermeiden einen zusätzlichen AssumeRole-Schritt.

Wenn Sie einem Drittanbieter (beispielsweise einem SaaS-Anbieter) kontoübergreifenden Zugriff gewähren, fügen Sie der Vertrauensrichtlinie eine Bedingung für eine externe ID hinzu.

Der Anbieter muss beim Übernehmen der Rolle einen eindeutigen geheimen Wert übergeben. Dadurch wird das Confused-Deputy-Problem verhindert, bei dem ein Angreifer den Anbieter dazu bringt, auf das Konto eines falschen Kunden zuzugreifen.

Kontoübergreifende Rollen sollten nur das erforderliche Minimum gewähren und auf bestimmte Ressourcen und Aktionen beschränkt sein.

Ein häufiger Fehler ist ein weit gefasstes Vertrauen in ein gesamtes externes Konto in Verbindung mit Administratorberechtigungen. Beschränken Sie das Vertrauen auf eine bestimmte Rolle oder einen bestimmten Benutzer und die Berechtigungen auf die konkrete Aufgabe.

Bei einem häufigen Entwurf wird eine Funktion in einem Konto zentralisiert, auf die andere Konten über Rollen zugreifen. Beispielsweise übernimmt ein Sicherheitskonto schreibgeschützte Rollen in jedem Workload-Konto.

Jedes Workload-Konto enthält eine gleichnamige Rolle, die dem Sicherheitskonto vertraut. Dadurch kann das entsprechende Tool alle Konten einheitlich prüfen.

AWS Resource Access Manager (RAM) gibt bestimmte Ressourcen wie Subnetze oder Transit Gateways für Konten innerhalb einer Organisation frei.

RAM dient dazu, die Ressource selbst freizugeben, statt API-Berechtigungen für Aktionen auf dieser Ressource zu erteilen. Der Dienst ergänzt Rollen und Ressourcenrichtlinien bei der Freigabe von Netzwerk- und Infrastrukturressourcen.

Kontoübergreifender Zugriff vergrößert Ihre Vertrauensfläche. Prüfen Sie ihn daher regelmäßig.

• CloudTrail protokolliert jeden AssumeRole-Aufruf und jeden kontoübergreifenden API-Aufruf.
• IAM Access Analyzer kennzeichnet Ressourcenrichtlinien, die Zugriff außerhalb Ihres Kontos gewähren.

Prüfen Sie diese Informationen, um unbeabsichtigte Freigaben frühzeitig zu erkennen.

Um Konten sicher zu verbinden, verwenden Sie bevorzugt Rollen für Computing und APIs sowie Ressourcenrichtlinien für Speicher- und Messaging-Services. Wenden Sie immer das Prinzip der geringsten Berechtigungen an und verwenden Sie für Drittanbieter eine externe ID.

Geben Sie niemals langfristige Schlüssel zwischen Konten weiter.

Analysieren Sie den kontoübergreifenden Zugriff.

Sie haben gelernt, wie Sie Konten sicher verbinden.

• Kontoübergreifende Rollen benötigen sowohl eine Vertrauensrichtlinie als auch eine Identitätsrichtlinie im Quellkonto.
• Ressourcenbasierte Richtlinien gewähren direkten Zugriff für Services wie S3 und KMS.
• Verwenden Sie für Drittanbieter eine externe ID und prüfen Sie den Zugriff mit Access Analyzer und CloudTrail.