SCP Best Practices : AWS Service Control Policies
AWS Service Control Policies
Service Control Policies ermöglichen Administratoren eine zentrale Kontrolle über die maximalen Berechtigungen aller Konten innerhalb ihrer Organisation. Wir definieren und benennen Strategien und betrachten die Best Practices, um Sie bei der Compliance-Automatisierung zu unterstützen.
Mit AWS Organizations können Sie AWS-Konten hierarchisch um Organisationseinheiten (OU) herum strukturieren. Das Verwaltungskonto befindet sich in der obersten Ebene im Stammverzeichnis. Darunter befinden sich OUs als untergeordnete Einheiten, die weitere untergeordnete OUs haben können. In diesem Baum können Sie Einschränkungen für Konten basierend auf ihrer OU konfigurieren. Ein einfaches Beispiel ist die Trennung zwischen Entwicklungs-, Test- und Produktionskonten. SCPs fungieren als Leitplanke, die die Berechtigungen für eine Gruppe von Konten begrenzt.
Wenn Sie Konten Berechtigungen erteilen möchten, reichen SCPs allein nicht aus. Sie müssen Konten oder Gruppen weiterhin Berechtigungen über IAMs erteilen. Sowohl SCPs als auch IAM-Benutzer und -Rollen definieren die effektiven Berechtigungen:
Über SCPs können Sie den maximalen Satz an Aktionen definieren, die für alle Konten zulässig und nicht zulässig sind. Dies sind die Leitplanken. Darüber hinaus muss der AWS-Administrator Richtlinien an IAM-Benutzer, -Rollen oder -Ressourcen anfügen. Die logische Schnittstelle zwischen dem, was SCPs, IAM und ressourcenbasierte Richtlinien erlauben, ist der Satz wirksamer Berechtigungen. Wenn SCP oder IAM eine Operation blockieren, kann der Benutzer diese Operation nicht ausführen, selbst wenn sie von der anderen Seite erlaubt wird.
Der Standard-SCP FullAWSAccess „Allow * on *“. Betrachten Sie dies als leere Leitplanke, was bedeutet, dass durch diesen SCP keine Einschränkungen definiert sind. Denken Sie daran, dass dies nicht bedeutet, dass jeder alles tun kann, denn es müssen IAM-Richtlinien vorhanden sein, die die erteilten Berechtigungen definieren. Bei Verwendung der Standardrichtlinie würde Ihre Strategie darin bestehen, eine Deny-Liste zu implementieren, eine Reihe von SCPs, die aus Deny-Anweisungen bestehen, um die Berechtigungen des Kontos einzuschränken. Die entgegengesetzte Strategie wäre, den Standard-SCP FullAWSAccess zu löschen und eine Allow-Liste zu implementieren.
Weitere Einzelheiten zu den Auswirkungen auf Berechtigungen finden Sie hier. JSON-Syntax mit einem oder mehreren Statement-Elementen stellt SCPs dar.
Der oben erwähnte Standard-SCP FullAWSAccess sieht folgendermaßen aus:
Klicken Sie hier, um eine Liste der Kontingente einschließlich einiger Mindest- und Höchstwerte zu finden. Bei SCPs müssen Sie sicherstellen, dass ein Limit von 5120 Bytes (nicht Zeichen) besteht. Achten Sie besonders auf zusätzliche Leerzeichen (Leerzeichen und Zeilenumbrüche) in den JSON-Dateien: Wenn Sie einen SCP mithilfe der AWS Management Console speichern, werden Leerzeichen zwischen JSON-Elementen und außerhalb von Anführungszeichen entfernt und nicht gezählt. Es gibt andere Möglichkeiten zum Speichern von SCPs ohne Automatisierung.
Das Testen und Debuggen von SCPs ist eine schwierige Aufgabe, da ein Mitgliedskonto die auf sie angewendeten SCPs nicht sehen kann. Und wenn aufgrund fehlender Berechtigungen etwas schief geht, sehen Sie den Grund dafür nicht, sodass Sie nicht erkennen können, ob ein SCP oder eine IAM-Richtlinie der Grund für die Ablehnung ist. Hier finden Sie Tipps zum Testen von SCPs.
Wie oben erwähnt, gibt es zwei Möglichkeiten, die SCPs in Ihrer Organisation zu konfigurieren: entweder als Sperrliste oder als Zulassungsliste. Wie hier beschrieben bedeutet die Konfiguration über die Sperrliste, dass standardmäßig alle Aktionen erlaubt sind (siehe das oben erwähnte Standard-SCP) und Sie nur angeben, welche Dienste und Aktionen verboten sind. Die Konfiguration über die Zulassungsliste ist umgekehrt: Standardmäßig wird alles verboten und bestimmte Dienste und Aktionen erlaubt.
Die AWS-Dokumentation enthält mehrere Beispiel-SCPs als Ausgangspunkt in Ihrer eigenen Umgebung. Im Folgenden stellen wir einige davon als Best Practices vor.
Aktionen als Root-Benutzer verbieten
Wie in der AWS Control Tower-Dokumentation beschrieben, sollten Sie den Kontozugriff mit Root-Benutzeranmeldeinformationen wie folgt verbieten:
Während der Ersteinrichtung Ihrer AWS-Umgebung wird das Root-Benutzerkonto erstellt. Sie sollten niemals die alltägliche Interaktion mit Ihrer AWS-Umgebung mit dem Root-Benutzer zulassen und dies durch das obige SCP erzwingen. Erstellen Sie stattdessen AWS Identity and Access Management (IAM)-Benutzer für die alltägliche Arbeit.
Verhindern Sie, dass Mitgliedskonten die Organisation verlassen.
Die folgende Richtlinie blockiert die Verwendung der API-Operation LeaveOrganization, sodass Administratoren von Mitgliedskonten ihre Konten nicht aus der Organisation entfernen können.
Nur ausgewählte Regionen verwenden
Manchmal sind Einschränkungen bezüglich der Regionen für Operationen erforderlich. Der folgende Codeauszug verweigert den Zugriff auf alle Operationen außerhalb der angegebenen zwei europäischen Regionen:
Beachten Sie, dass dies nur ein Auszug des vollständigen SCP ist, das Sie für diese Regionseinschränkung benötigen. Das vollständige SCP finden Sie hier. Darüber hinaus enthält eine zusätzliche Liste von Aktionen in globalen Diensten Endpunkte, die physisch von einer anderen Region (us-east-1) gehostet werden. Ohne diese Ausnahmeliste würden diese Aktionen aufgrund des SCP verweigert.
Zugriff von außen einschränken
Wenn Sie ein Konto einrichten, definieren Sie meistens zulässige Netzwerkressourcen. Es sollte nicht möglich sein, diese Einstellungen zu ändern, beispielsweise durch Gewähren eines direkten Zugriffs auf das Internet. Das folgende SCP kann verwendet werden, um die Konfiguration Ihrer virtuellen privaten Amazon EC2-Clouds zu schützen. Für das vollständige SCP klicken Sie hier:
Sie interessieren sich für weitere bewährte Sicherheitsmethoden? Sehen Sie sich die Tipps in der AWS-Dokumentation an. Wenn Sie weitere Fragen zur AWS-Sicherheit im Allgemeinen haben, unterstützen Sie unsere AWS-zertifizierten Lösungsarchitekten und -ingenieure gerne!
