Mehrere Entwicklungsteams stellen Produktions-Workloads in einem gemeinsam genutzten AWS-Produktionskonto bereit. Kürzlich haben Mitglieder eines Entwicklungsteams eine EC2-Instance beendet, die einem anderen Team gehörte. Entwickler verwenden SAML-Föderation über AWS Organizations, um Rollen zu übernehmen. Sie müssen verhindern, dass Entwickler Instances verwalten, die anderen Teams gehören, während sie gleichzeitig ihre eigenen Instances verwalten können. Welche Strategie erfüllt diese Anforderungen?

Die korrekte Strategie ist, ein Sitzungs-Tag (aws:PrincipalTag) während der SAML-Föderation zu übergeben, das die Entwicklungseinheit des Benutzers identifiziert. Anschließend wird eine IAM-Richtlinie mit einer Deny-Anweisung und einer StringNotEquals-Bedingung angewendet. Diese Bedingung vergleicht das Ressourcentag 'DevelopmentUnit' mit dem Sitzungs-Tag 'aws:PrincipalTag/DevelopmentUnit'. Wenn die Tags nicht übereinstimmen, wird der Zugriff verweigert, wodurch verhindert wird, dass Entwickler Ressourcen verwalten, die nicht zu ihrem Team gehören. Gleichzeitig können sie Ressourcen verwalten, bei denen die Tags übereinstimmen. Die Option mit separaten OUs und SCPs ist weniger flexibel und skaliert schlechter, da für jede OU und jedes SCP manuell Konfigurationen vorgenommen werden müssten. Eine Allow-Aktion mit StringEquals würde nur den Zugriff auf die eigenen Ressourcen erlauben, aber nicht explizit den Zugriff auf fremde Ressourcen verweigern, was zu unerwünschten Seiteneffekten führen könnte, wenn andere Richtlinien breiteren Zugriff gewähren. Separate IAM-Richtlinien für jede Einheit sind zwar möglich, aber die Kombination mit einem Deny-Ansatz über Sitzungs-Tags ist effizienter und sicherer, da sie eine explizite Verweigerung durchsetzt.