

# SEC 3. Wie verwalten Sie Berechtigungen für Personen und Maschinen?
<a name="sec-03"></a>

 Verwalten Sie Berechtigungen zum Steuern des Zugriffs auf Personen- und Maschinenidentitäten, die Zugriff auf AWS und Ihren Workload benötigen. Berechtigungen steuern, wer worauf und unter welchen Bedingungen zugreifen kann. 

**Topics**
+ [SEC03-BP01 Definieren von Zugriffsanforderungen](sec_permissions_define.md)
+ [SEC03-BP02 Gewähren des Zugriffs mit den geringsten Berechtigungen](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Einrichtung eines Notfallzugriffprozesses](sec_permissions_emergency_process.md)
+ [SEC03-BP04 Kontinuierliche Reduzierung der Berechtigungen](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 Definieren eines Integritätsschutzes für Berechtigungen in Ihrer Organisation](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 Zugriffsverwaltung basierend auf dem Lebenszyklus](sec_permissions_lifecycle.md)
+ [SEC03-BP07 Analysieren des öffentlichen und kontoübergreifenden Zugriffs](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 Sicheres gemeinsames Nutzen von Ressourcen in Ihrer Organisation](sec_permissions_share_securely.md)
+ [SEC03-BP09 Sicheres Teilen von Ressourcen mit Dritten](sec_permissions_share_securely_third_party.md)

# SEC03-BP01 Definieren von Zugriffsanforderungen
<a name="sec_permissions_define"></a>

Administratoren, Endbenutzer oder andere Komponenten müssen auf jede Komponente oder Ressource Ihres Workloads zugreifen. Sie müssen eine klare Definition davon haben, wer oder was Zugriff auf die einzelnen Komponenten haben soll. Anschließend wählen Sie den entsprechenden Identitätstyp und die entsprechende Authentifizierungs- und Autorisierungsmethode aus.

 **Typische Anti-Muster:** 
+ Hartkodierung oder Speicherung von geheimen Daten in Ihrer Anwendung 
+ Gewähren individueller Berechtigungen für alle Nutzer 
+ Verwendung langlebiger Anmeldeinformationen 

 **Risikostufe, wenn diese bewährte Methode nicht genutzt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Administratoren, Endbenutzer oder andere Komponenten müssen auf jede Komponente oder Ressource Ihres Workloads zugreifen. Sie müssen eine klare Definition davon haben, wer oder was Zugriff auf die einzelnen Komponenten haben soll. Anschließend wählen Sie den entsprechenden Identitätstyp und die entsprechende Authentifizierungs- und Autorisierungsmethode aus.

Regulärer Zugriff auf AWS-Konten in der Organisation sollte per [Verbundzugriff](https://aws.amazon.com/identity/federation/) oder einen zentralen Identitätsanbieter bereitgestellt werden. Sie sollten auch Ihr Identitätsmanagement zentralisieren und sicherstellen, dass es ein etabliertes Verfahren zur Integration des AWS-Zugriffs in den Zugriffslebenszyklus der Mitarbeiter gibt Wenn beispielsweise ein Mitarbeiter in eine Rolle mit einer anderen Zugriffsstufe wechselt, sollte sich auch dessen Gruppenmitgliedschaft so ändern, dass die neuen Zugriffsanforderungen berücksichtigt werden.

 Legen Sie bei der Definition der Zugriffsanforderungen für nicht menschliche Identitäten fest, welche Anwendungen und Komponenten Zugriff benötigen und wie die Berechtigungen gewährt werden. Eine empfohlene Vorgehensweise ist die Verwendung von nach dem Modell der geringsten Berechtigung entwickelten IAM-Rollen. [AWS-verwaltete Richtlinien](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) bieten vordefinierte IAM-Richtlinien für die meisten typischen Anwendungsfälle.

AWS-Services wie beispielsweise [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) und [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)können dabei helfen, Secrets in sicherer Weise von Anwendungen oder Workloads zu trennen, wenn es nicht möglich ist, IAM-Rollen zu verwenden. In Secrets Manager können Sie die automatische Rotation Ihrer Anmeldeinformationen einrichten. Mit Systems Manager können Sie auf Parameter in Ihren Skripts, Befehlen, SSM-Dokumenten, Konfigurations- und Automatisierungsworkflows verweisen, indem Sie den bei der Erstellung des Parameters angegebenen eindeutigen Namen verwenden.

Sie können AWS Identity and Access Management Roles Anywhere verwenden, um [temporäre Sicherheitsanmeldeinformationen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) für Workloads zu erhalten, die außerhalb von AWS ausgeführt werden. Ihre Workloads können dieselben [IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) und [IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) verwenden, die Sie für AWS-Anwendungen zum Zugriff auf AWS-Ressourcen nutzen. 

 Verwenden Sie nach Möglichkeit kurzfristige temporäre anstelle langfristiger statischer Anmeldeinformationen. Verwenden Sie für Szenarien, in denen Sie IAM-Nutzer mit programmatischem Zugriff und langfristigen Anmeldeinformationen benötigen, [Informationen über die letzte Nutzung von Zugriffsschlüsseln,](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) um Zugriffsschlüssel zu entfernen und zu rotieren. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Attributbasierte Zugriffskontrolle (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 
+  [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 
+  [AWS-verwaltete Richtlinien für IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) 
+  [AWS-IAM-Richtlinienbedingungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 
+  [IAM-Anwendungsfälle](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html) 
+  [Entfernen von nicht benötigten Anmeldeinformationen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [Arbeiten mit Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 
+  [Steuerung des Zugriffs auf AWS-Ressourcen auf der Grundlage von AWS-Konto, OU oder Organisation](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/) 
+  [Identifizieren, Arrangieren und Verwalten von geheimen Daten mithilfe der erweiterten Suche in AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) 

 **Zugehörige Videos:** 
+  [Become an IAM Policy Master in 60 Minutes or Less (Experte für IAM-Richtlinien in unter 60 Minuten)](https://youtu.be/YQsK4MtsELU) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD (Trennung von Pflichten, geringste Berechtigung, Delegierung und CI/CD)](https://youtu.be/3H0i7VyTu70) 
+  [Streamlining identity and access management for innovation (Optimieren des Identitäts- und Zugriffsmanagements für Innovation)](https://www.youtube.com/watch?v=3qK0b1UkaE8) 

# SEC03-BP02 Gewähren des Zugriffs mit den geringsten Berechtigungen
<a name="sec_permissions_least_privileges"></a>

 Es hat sich bewährt, nur den Zugriff zu gewähren, den Identitäten benötigen, um bestimmte Aktionen auf bestimmten Ressourcen unter bestimmten Bedingungen durchzuführen. Nutzen Sie Gruppen und Identitätsattribute, um Berechtigungen dynamisch in großem Umfang festzulegen, anstatt Berechtigungen für einzelne Benutzer zu definieren. Sie können beispielsweise einer Gruppe von Entwicklern den Zugriff erlauben, nur die Ressourcen für ihr Projekt zu verwalten. So ist sichergestellt, dass einem Entwickler, der nicht mehr am Projekt arbeitet, automatisch der Zugriff entzogen wird, ohne dass die zugrunde liegenden Zugriffsrichtlinien geändert werden müssen. 

**Gewünschtes Ergebnis:** Die Benutzer sollten nur über die erforderlichen Berechtigungen für ihre Aufgabe verfügen. Die Benutzer sollten nur Zugriff auf Produktionsumgebungen erhalten, um eine bestimmte Aufgabe in einem begrenzten Zeitraum auszuführen. Nach Abschluss der Aufgabe sollte der Zugriff widerrufen werden. Nicht mehr benötigte Berechtigungen sollten widerrufen werden. Dies gilt auch, wenn ein Benutzer zu einem anderen Projekt wechselt oder eine andere Tätigkeit übernimmt. Administratorberechtigungen sollten nur einer kleinen Gruppe von vertrauenswürdigen Administratoren erteilt werden. Die Berechtigungen sollten regelmäßig geprüft werden, um eine schleichende Ausweitung der Berechtigungen zu vermeiden. Maschinen- oder Systemkonten sollten die geringsten Berechtigungen erhalten, die zur Ausführung ihrer Aufgaben benötigt werden. 

**Typische Anti-Muster:**
+  Standardmäßige Gewährung von Administratorberechtigungen für Benutzer 
+  Verwendung des Root-Benutzers für alltägliche Aktivitäten 
+  Erstellung übermäßig großzügiger Richtlinien, jedoch ohne vollständige Administratorberechtigungen 
+  Keine Überprüfung der Berechtigungen, um festzustellen, ob sie einen Zugriff mit den geringsten Berechtigungen gewähren 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Das Prinzip der [geringsten Berechtigung](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#grant-least-privilege) besagt, dass nur die Berechtigungen für die kleinste Gruppe von Aktionen erteilt werden sollte, die für die Durchführung einer bestimmten Aufgabe notwendig sind. Dies schafft ein Gleichgewicht zwischen Benutzerfreundlichkeit, Effizienz und Sicherheit. Die Anwendung dieses Prinzips trägt dazu bei, den unbeabsichtigten Zugriff zu beschränken und nachzuverfolgen, wer auf welche Ressourcen zugreifen kann. IAM-Benutzer und -Rollen verfügen standardmäßig über keine Berechtigungen. Der Root-Benutzer verfügt standardmäßig über vollen Zugriff und sollte strikt kontrolliert, überwacht und nur für [Aufgaben verwendet werden, die Root-Zugriff erfordern](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). 

 Mithilfe von IAM-Richtlinien können ausdrücklich Berechtigungen für IAM-Rollen oder bestimmte Ressourcen erteilt werden. So können beispielsweise identitätsbasierte Richtlinien an IAM-Gruppen angefügt werden, während S3-Buckets von ressourcenbasierten Richtlinien kontrolliert werden können. 

 Wenn Sie eine IAM-Richtlinie erstellen, können Sie die Serviceaktionen, Ressourcen und Bedingungen angeben, die erfüllt sein müssen, damit AWS den Zugriff erlaubt oder verweigert. AWS unterstützt eine Vielzahl von Bedingungen, mit denen Sie den Zugriff einschränken können. Mit dem [Bedingungsschlüssel](https://docs.aws.amazon.com//latest/UserGuide/reference_policies_condition-keys.html) `PrincipalOrgID` können Sie beispielsweise Aktionen verweigern, wenn der Anforderer nicht Ihrer AWS-Organisation angehört. 

 Sie können auch Anforderungen kontrollieren, die AWS-Services in Ihrem Namen stellen, wie das Erstellen einer AWS Lambda-Funktion durch AWS CloudFormation. Hierfür verwenden Sie den Bedingungsschlüssel `CalledVia`. Sie sollten unterschiedliche Richtlinientypen in Ebenen organisieren, um einen umfassenden Verteidigungsansatz aufzubauen und die Berechtigungen Ihrer Benutzer insgesamt zu begrenzen. Sie können auch Beschränkungen in Bezug darauf festlegen, welche Berechtigungen unter welchen Umständen erteilt werden können. So können Sie beispielsweise Ihren Anwendungsteams gestatten, eigene IAM-Richtlinien für die von ihnen erstellten Systeme zu erstellen, müssen aber auch eine [Berechtigungsgrenze](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) anwenden, um die maximalen Berechtigungen zu begrenzen, die das System erhalten kann. 

 **Implementierungsschritte** 
+  **Implementieren Sie Richtlinien für geringste Berechtigungen**: Weisen Sie IAM-Gruppen und -Rollen Zugriffsrichtlinien zu, die in ihrem Umfang möglichst gering und an die von Ihnen definierte Rolle oder Funktion der Benutzer angepasst sind. 
  +  **Basisrichtlinien zur API-Nutzung**: Eine Möglichkeit, herauszufinden, welche Berechtigungen benötigt werden, besteht in der Prüfung der AWS CloudTrail-Protokolle. Diese Prüfung ermöglicht es Ihnen, Berechtigungen zu erstellen, die auf die Aktionen zugeschnitten sind, die der Benutzer tatsächlich in AWS ausführt. [IAM Access Analyzer kann automatisch eine IAM-Richtlinie auf der Grundlage](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) [einer Aktivität generieren](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/). Sie können IAM Access Advisor auf Organisations- oder Kontoebene verwenden, um [zu verfolgen](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html), [auf welche Informationen für eine bestimmte Richtlinie zuletzt zugegriffen wurde](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html). 
+  **Erwägen Sie, [von AWS verwaltete Richtlinien für berufliche Funktionen ](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html)zu verwenden.** Beim Erstellen von differenzierten Berechtigungsrichtlinien haben Sie zunächst möglicherweise Schwierigkeiten, herauszufinden, wo Sie beginnen sollten. AWS verfügt über verwaltete Richtlinien für allgemeine Job-Rollen, wie z. B. Fakturierungsmitarbeiter, Datenbankadministratoren und Datenwissenschaftler. Diese Richtlinien können helfen, den Zugriff der Benutzer einzuschränken und gleichzeitig festzulegen, wie die Richtlinien für die geringste Berechtigung implementiert werden sollen. 
+  **Entfernen von unnötigen Berechtigungen:** Entfernen Sie nicht benötigte Berechtigungen und schränken Sie zu großzügige Richtlinien ein. Die [Richtliniengenerierung von IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/access-analyzer-policy-generation.html) kann bei der Feinabstimmung von Berechtigungsrichtlinien hilfreich sein. 
+  **Stellen Sie sicher, dass Benutzer nur beschränkten Zugriff auf Produktionsumgebungen haben:** Benutzer sollten nur Zugriff auf Produktionsumgebungen haben, wenn ein gültiger Anwendungsfall vorliegt. Nachdem der Benutzer die konkreten Aufgaben ausgeführt hat, für die Zugriff auf die Produktionsumgebung erforderlich war, sollte der Zugriff widerrufen werden. Die Beschränkung des Zugriffs auf Produktionsumgebungen hilft, unbeabsichtigte Vorkommnisse mit Auswirkungen auf die Produktion zu verhindern und das Ausmaß der Auswirkungen eines unbeabsichtigten Zugriffs zu verringern. 
+ **Ziehen Sie Berechtigungsgrenzen in Betracht:** Eine Berechtigungsgrenze ist eine Funktion für eine verwaltete Richtlinie. Sie legt die maximalen Berechtigungen fest, die mit einer identitätsbasierten Richtlinie einer IAM-Entität erteilt werden können. Eine Berechtigungsgrenze erlaubt einer Entität nur die Ausführung jener Aktionen, die sowohl nach ihren identitätsbasierten Richtlinien als auch nach ihren Berechtigungsgrenzen zulässig sind.  
+  **Ziehen Sie [Ressourcen-Tags](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) für Berechtigungen in Betracht:** Ein attributbasiertes Zugriffskontrollmodell, das Ressourcen-Tags verwendet, bietet Ihnen die Möglichkeit, den Zugriff basierend auf dem Zweck der Ressource, dem Besitzer, der Umgebung oder anderen Kriterien zu gewähren. Mithilfe von Ressourcen-Tags können Sie beispielsweise zwischen Entwicklungs- und Produktionsumgebungen unterscheiden. Mit diesen Tags können Sie den Zugriff der Entwickler auf die Entwicklungsumgebung beschränken. Durch die Kombination von Tagging und Berechtigungsrichtlinien können Sie einen differenzierten Ressourcenzugriff erzielen, ohne komplizierte, benutzerdefinierte Richtlinien für jeden Tätigkeitsbereich definieren zu müssen. 
+  **Verwenden Sie [Service-Kontrollrichtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) für AWS Organizations.** Service-Kontrollrichtlinien steuern zentral die maximal verfügbaren Berechtigungen für Mitgliedskonten in Ihrer Organisation. Wichtig ist, dass Sie mithilfe von Service-Kontrollrichtlinien die Root-Benutzerberechtigungen in Mitgliedskonten einschränken können. Ziehen Sie auch die Verwendung von AWS Control Tower in Betracht, das präskriptive verwaltete Kontrollen zur Bereicherung von AWS Organizations bietet. Sie können auch Ihre eigenen Kontrollen in Control Tower definieren. 
+  **Erstellen Sie eine Benutzerlebenszyklus-Richtlinie für Ihre Organisation:** Benutzerlebenszyklus-Richtlinien definieren Aufgaben, die ausgeführt werden müssen, wenn Benutzer neu in AWS eingebunden werden, ihre Rolle oder ihren Aufgabenbereich ändern oder keinen Zugriff mehr auf AWS benötigen. Bei jedem Schritt im Lebenszyklus eines Benutzers sollten Berechtigungsprüfungen erfolgen, um sicherzustellen, dass die Berechtigungen angemessen restriktiv sind und keine schleichenden Berechtigungserweiterungen stattfinden. 
+  **Legen Sie einen regelmäßigen Zeitplan für die Prüfung von Berechtigungen und das Entfernen nicht benötigter Berechtigungen fest:** Sie sollten den Benutzerzugriff regelmäßig prüfen, um sicherzustellen, dass die Benutzer nicht zu viele Zugriffsrechte haben. [AWS Config](https://aws.amazon.com/config/) und IAM Access Analyzer können bei der Prüfung der Benutzerberechtigungen hilfreich sein. 
+ **Erstellen Sie eine Job-Rollen-Matrix:** In einer Job-Rollen-Matrix sind die verschiedenen Rollen und erforderlichen Zugriffsebenen innerhalb Ihrer AWS-Präsenz visuell dargestellt. Mithilfe einer Job-Rollen-Matrix können Sie Berechtigungen auf der Grundlage von Benutzerzuständigkeiten in Ihrer Organisation definieren und trennen. Verwenden Sie Gruppen, anstatt Berechtigungen direkt auf einzelne Benutzer oder Rollen anzuwenden.** **

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Gewähren der geringsten Berechtigung](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html?ref=wellarchitected#grant-least-privilege) 
+  [Berechtigungsgrenzen für IAM-Entitäten](https://docs.aws.amazon.com//latest/UserGuide/access_policies_boundaries.html) 
+  [Techniken zum Erstellen von IAM-Richtlinien für geringste Berechtigungen](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/) 
+  [IAM Access Analyzer erleichtert die Implementierung geringster Berechtigungen durch die Generierung von IAM](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)[-Richtlinien auf der Grundlage der Zugriffsaktivitäten](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/) 
+  [Delegieren Sie die Berechtigungsverwaltung an Entwickler und verwenden Sie hierfür IAM-Berechtigungsgrenzen](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) 
+  [Verfeinern der Berechtigungen mithilfe der zuletzt genutzten Informationen](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html) 
+  [IAM-Richtlinienarten und wann sie verwendet werden sollten](https://docs.aws.amazon.com//latest/UserGuide/access_policies.html) 
+  [Testen von IAM-Richtlinien mit dem IAM-Richtliniensimulator](https://docs.aws.amazon.com//latest/UserGuide/access_policies_testing-policies.html) 
+  [Integritätsschutz in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 
+  [Zero-Trust-Architekturen: Eine AWS-Perspektive](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/) 
+  [Implementieren des Prinzips der geringsten Berechtigung mit CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/) 
+  [Attributbasierte Zugriffskontrolle (ABAC)](https://docs.aws.amazon.com//latest/UserGuide/introduction_attribute-based-access-control.html?ref=wellarchitected) 
+ [Reduzieren des Richtlinienbereichs durch Anzeigen der Benutzeraktivität](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html?ref=wellarchitected) 
+  [Anzeigen des Rollenzugriffs](https://docs.aws.amazon.com//latest/UserGuide/id_roles_manage_delete.html?ref=wellarchitected#roles-delete_prerequisites) 
+  [Tagging zum Organisieren Ihrer Umgebung und Stärkung der Rechenschaftspflicht](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html?ref=wellarchitected) 
+  [AWS-Markierungsstrategien](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/?ref=wellarchitected) 
+  [Markieren von AWS-Ressourcen](https://aws.amazon.com/premiumsupport/knowledge-center/quicksight-iam-identity-center/) 

 **Zugehörige Videos:** 
+  [Next-generation permissions management (Berechtigungsmanagement der nächsten Generation)](https://www.youtube.com/watch?v=8vsD_aTtuTo) 
+  [Zero Trust: An AWS perspective (Zero Trust: Eine AWS-Perspektive)](https://www.youtube.com/watch?v=1p5G1-4s1r0) 
+  [How can I use permissions boundaries to limit users and roles to prevent privilege escalation?](https://www.youtube.com/watch?v=omwq3r7poek) (Wie kann ich mit Berechtigungsgrenzen Benutzer und Rollen einschränken, um die Eskalation von Berechtigungen zu vermeiden?) 

 **Zugehörige Beispiele:** 
+  [Lab: IAM-Berechtigungsgrenzen – Übertragung der Rollenerstellung](https://wellarchitectedlabs.com/Security/300__Permission_Boundaries_Delegating_Role_Creation/README.html) 
+  [Lab: IAM-Tag-basierte Zugriffskontrolle für EC2](https://wellarchitectedlabs.com/Security/300__Tag_Based_Access_Control_for_EC2/README.html?ref=wellarchitected) 

# SEC03-BP03 Einrichtung eines Notfallzugriffprozesses
<a name="sec_permissions_emergency_process"></a>

 Erstellen Sie einen Prozess, der im unwahrscheinlichen Fall eines Problems mit Ihrem zentralen Identitätsanbieter den Notfallzugriff auf Ihre Workloads ermöglicht. 

 Sie müssen Prozesse für verschiedene Ausfallmodi entwerfen, die zu einem Notfallereignis führen können. Unter normalen Umständen verbinden sich die Benutzer Ihrer Belegschaft beispielsweise über einen zentralen Identitätsanbieter mit der Cloud ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)), um ihre Workloads zu verwalten. Wenn der zentrale Identitätsanbieter jedoch ausfällt oder die Konfiguration für den Verbund in der Cloud geändert wird, können sich die Benutzer in Ihrem Unternehmen möglicherweise nicht mit der Cloud verbinden. Ein Prozess für den Notfallzugriff ermöglicht autorisierten Administratoren den Zugriff auf Ihre Cloud-Ressourcen über alternative Verfahren (z. B. eine alternative Form des Verbunds oder direkter Benutzerzugriff), um Probleme mit Ihrer Verbundkonfiguration oder Ihren Workloads zu beheben. Der Prozess für den Notfallzugriff wird verwendet, bis der normale Verbundmechanismus wiederhergestellt ist. 

 **Gewünschtes Ergebnis:** 
+  Sie haben die Ausfallmodi definiert und dokumentiert, die als Notfall gelten: Berücksichtigen Sie dabei Ihre normalen Abläufe und die Systeme, auf die Ihre Benutzer angewiesen sind, um ihre Workloads zu verwalten. Überlegen Sie, wie jede dieser Abhängigkeiten ausfallen und zu einer Notsituation führen kann. Die Fragen und bewährten Methoden in der [Säule „Zuverlässigkeit“](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html) können Sie dabei unterstützen, Ausfallmodi zu identifizieren und widerstandsfähigere Systeme zu entwickeln, um die Wahrscheinlichkeit von Ausfällen zu minimieren. 
+  Sie haben die Schritte dokumentiert, die befolgt werden müssen, um einen Ausfall als Notfall zu identifizieren. Sie können beispielsweise festlegen, dass Ihre Identitätsadministratoren den Status Ihrer primären und Standby-Identitätsanbieter überprüfen müssen und, falls beide nicht verfügbar sind, ein Notfallereignis für den Ausfall eines Identitätsanbieters feststellen. 
+  Sie haben einen Prozess für den Notfallzugriff definiert, der für jeden Notfall- oder Ausfallmodus spezifisch ist. Wenn Sie hier möglichst detaillierte Informationen angeben, kann dies der Neigung Ihrer Benutzer entgegenwirken, einen allgemeinen Prozess für alle Arten von Notfällen zu stark zu nutzen. Ihre Prozesse für den Notfallzugriff beschreiben die Umstände, unter denen ein Prozess jeweils verwendet werden sollte, und umgekehrt Situationen, in denen der Prozess nicht verwendet werden sollte. In diesem Fall wird auf alternative Prozesse hingewiesen, die zutreffen können. 
+  Ihre Prozesse sind mit detaillierten Anweisungen und Playbooks, die schnell und effizient befolgt werden können, gut dokumentiert. Denken Sie daran, dass ein Notfallereignis Stress für Ihre Benutzer bedeuten kann und dass sie unter extremem Zeitdruck stehen können. Gestalten Sie Ihren Prozess daher so einfach wie möglich. 

 **Typische Anti-Muster:** 
+  Sie verfügen nicht über gut dokumentierte und gut getestete Prozesse für den Notfallzugriff. Ihre Benutzer sind nicht auf einen Notfall vorbereitet und nutzen improvisierte Prozesse, wenn er eintritt. 
+  Ihre Prozesse für den Notfallzugriff hängen von denselben Systemen (z. B. einem zentralen Identitätsanbieter) ab wie Ihre normalen Zugriffsmechanismen. Das bedeutet, dass der Ausfall eines solchen Systems sowohl Ihre normalen Zugriffsmechanismen als auch Ihre Notfallzugriffsmechanismen betrifft und Ihre Fähigkeit zur Wiederherstellung nach dem Ausfall beeinträchtigen kann. 
+  Ihre Prozesse für den Notfallzugriff werden in Situationen verwendet, die keine Notfälle sind. Ein Beispiel könnte sein, dass Ihre Benutzer Prozesse für den Notfallzugriff häufig missbrauchen, da es für sie einfacher ist, Änderungen direkt vorzunehmen, als Änderungen über eine Pipeline einzureichen. 
+  Ihre Prozesse für den Notfallzugriff generieren nicht genügend Protokolle, um sie zu überwachen, oder die Protokolle werden nicht so überwacht, dass Sie bei einem möglichen Missbrauch der Prozesse gewarnt werden. 

 **Vorteile der Nutzung dieser bewährten Methode:** 
+  Durch gut dokumentierte und gut getestete Prozesse für den Notfallzugriff können Sie die Zeit reduzieren, die Ihre Benutzer benötigen, um auf ein Notfallereignis zu reagieren und es zu beheben. Dies kann zu kürzeren Ausfallzeiten und einer höheren Verfügbarkeit der Services führen, die Sie für Ihre Kunden bereitstellen. 
+  Sie können jede Notfallzugriffsanfrage verfolgen und unbefugte Versuche, den Prozess für Nicht-Notfallereignisse zu missbrauchen, erkennen und darauf hinweisen. 

 **Risikostufe bei fehlender Befolgung dieser Best Practice:**: Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Dieser Abschnitt enthält Richtlinien zur Erstellung von Prozessen für den Notfallzugriff für verschiedene Ausfallmodi im Zusammenhang mit Workloads, die in AWS bereitgestellt werden. Zunächst finden Sie allgemeine Leitlinien, die für alle Ausfallmodi gelten, und danach spezifische Anleitungen für die verschiedenen Arten von Ausfallmodi. 

 **Allgemeine Leitlinien für alle Ausfallmodi** 

 Beachten Sie beim Entwerfen eines Prozesses für den Notfallzugriff für einen Ausfallmodus Folgendes: 
+  Dokumentieren Sie die Voraussetzungen und Annahmen für den Prozess: Wann soll der Prozess verwendet werden und wann nicht? Es ist hilfreich, den Ausfallmodus detailliert zu beschreiben und Annahmen zu dokumentieren, z. B. den Zustand anderer verwandter Systeme. Der Prozess für den Ausfallmodus 2 geht beispielsweise davon aus, dass der Identitätsanbieter verfügbar ist, aber die Konfiguration in AWS geändert wurde oder abgelaufen ist. 
+  Erstellen Sie im Voraus Ressourcen, die für den Notfallzugriffsprozess benötigt werden ([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html)). Erstellen Sie beispielsweise vorab das AWS-Konto für den Notfallzugriff (IAM users und -Rollen) und die kontoübergreifenden IAM-Rollen in allen Workload-Konten. So wird sichergestellt, dass diese Ressourcen bereit und verfügbar sind, wenn ein Notfallereignis eintritt. Durch das Erstellen von Ressourcen im Voraus sind Sie nicht abhängig von den APIs der AWS- [Steuerebene](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) (zum Erstellen und Ändern von AWS-Ressourcen), die im Notfall möglicherweise nicht verfügbar sind. Wenn Sie IAM-Ressourcen vorab erstellen, müssen Sie außerdem keine [möglichen Verzögerungen aufgrund einer letztendlichen Konsistenz berücksichtigen.](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) 
+  Schließen Sie Prozesse für den Notfallzugriff in Ihre Vorfallmanagementpläne ein ([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)). Dokumentieren Sie, wie Notfallereignisse nachverfolgt und an andere in Ihrem Unternehmen, z. B. an Peer-Teams, Führungskräfte und gegebenenfalls extern an Kunden und Geschäftspartner, kommuniziert werden sollen. 
+  Definieren Sie den Prozess für Notfallzugriffsanfragen in Ihrem bestehenden Workflow-System für Serviceanfragen, falls eines vorhanden ist. In der Regel können Sie mit solchen Workflow-Systemen Eingabeformulare erstellen, um Informationen zur Anfrage zu erfassen, die Anfrage in jeder Phase des Workflows zu verfolgen und sowohl automatisierte als auch manuelle Genehmigungsschritte hinzuzufügen. Ordnen Sie jede Anfrage einem entsprechenden Notfallereignis zu, das in Ihrem Vorfallmanagement-System verfolgt wird. Mit einem einheitlichen System für Notfallzugriffe können Sie diese Anfragen in einem zentralen System verfolgen, Nutzungstrends analysieren und Ihre Prozesse verbessern. 
+  Stellen Sie sicher, dass Ihre Notfallzugriffsprozesse nur von autorisierten Benutzern initiiert werden können, und legen Sie fest, dass Genehmigungen von Kollegen oder Führungskräften des Benutzers erforderlich sind. Das Genehmigungsverfahren sollte sowohl während als auch außerhalb der Geschäftszeiten funktionieren. Definieren Sie, wie Genehmigungsanfragen sekundäre Genehmiger berücksichtigen, falls die primären Genehmiger nicht verfügbar sind, und wie sie in Ihrer Managementkette nach oben eskaliert werden, bis sie genehmigt wurden. 
+  Stellen Sie sicher, dass der Prozess detaillierte Auditprotokolle und Ereignisse sowohl für erfolgreiche als auch für fehlgeschlagene Versuche generiert, Notfallzugriff zu erhalten. Überwachen Sie sowohl den Anforderungsprozess als auch den Notfallzugriffsmechanismus, um Missbrauch oder nicht autorisierte Zugriffe zu erkennen. Korrelieren Sie Aktivitäten mit laufenden Notfallereignissen aus Ihrem Vorfallsmanagement-System und senden Sie Benachrichtigungen, wenn Aktionen außerhalb der erwarteten Zeiträume erfolgen. Sie sollten beispielsweise die Aktivitäten im AWS-Konto für den Notfallzugriff überwachen und entsprechende Benachrichtigungen senden, da es im normalen Betrieb nie verwendet werden sollte. 
+  Testen Sie die Notfallzugriffsprozesse regelmäßig, um sicherzustellen, dass die Schritte klar sind und die richtigen Zugriffsebenen schnell und effizient gewährt werden. Ihre Notfallzugriffsprozesse sollten im Rahmen der Simulation von Vorfallsreaktionen ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) und Tests der Notfallwiederherstellung ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)) getestet werden. 

 **Ausfallmodus 1: Der für den Verbund mit AWS verwendete Identitätsanbieter ist nicht verfügbar** 

 Wie in [SEC02-BP04 Verlassen auf einen zentralen Identitätsanbieter](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) beschrieben, wird empfohlen, sich auf einen zentralen Identitätsanbieter zu verlassen, der die Benutzer Ihres Unternehmens verbindet, um den Zugriff auf AWS-Konten zu gewähren. Sie können mit IAM Identity Center einen Verbund für mehrere AWS-Konten in Ihrer AWS-Organisation implementieren oder einzelne AWS-Konten mit IAM verbinden. In beiden Fällen authentifizieren sich die Benutzer in Ihrer Belegschaft beim zentralen Identitätsanbieter, bevor sie zu einem AWS-Anmeldeendpunkt für das Single Sign-On weitergeleitet werden. 

 Im unwahrscheinlichen Fall, dass der zentrale Identitätsanbieter nicht verfügbar ist, können sich die Benutzer Ihrer Belegschaft nicht mit AWS-Konten verbinden oder ihre Workloads verwalten. In einem solchen Notfall können Sie einen Notfallzugriffsprozess für eine kleine Gruppe von Administratoren einrichten, die auf AWS-Konten zugreifen dürfen, um kritische Aufgaben auszuführen, die nicht warten können, bis die zentralen Identitätsanbieter wieder online sind. Nehmen Sie beispielsweise an, dass Ihr Identitätsanbieter für 4 Stunden nicht verfügbar ist und während dieses Zeitraums die Obergrenzen einer Amazon EC2 Auto Scaling-Gruppe in einem Produktionskonto geändert werden müssen, um einen unerwarteten Anstieg des Kundenverkehrs zu bewältigen. Ihre Notfalladministratoren sollten den Notfallzugriffsprozess befolgen, um Zugriff auf das spezifische AWS-Konto in der Produktion zu erhalten und die erforderlichen Änderungen vorzunehmen. 

 Der Notfallzugriffsprozess basiert auf einem vorab erstellten AWS-Konto für den Notfallzugriff, das ausschließlich für den Notfallzugriff verwendet wird und über AWS-Ressourcen (wie IAM-Rollen und IAM users) zur Unterstützung des Notfallzugriffsprozesses verfügt. Während des normalen Betriebs sollte niemand auf das Notfallzugriffskonto zugreifen. Sie müssen dieses Konto auf Missbrauch überwachen und ggf. Warnungen senden (weitere Informationen finden Sie im vorherigen Abschnitt mit allgemeinen Leitlinien). 

 Das Notfallzugriffskonto verfügt über IAM-Notfallzugriffsrollen mit der Berechtigung, kontoübergreifende Rollen in den AWS-Konten anzunehmen, für die Notfallzugriff erforderlich ist. Diese IAM-Rollen sind vordefiniert und mit Vertrauensrichtlinien konfiguriert, die den IAM-Rollen des Notfallkontos vertrauen. 

 Das Notfallzugriffsverfahren kann einen der folgenden Ansätze verwenden: 
+  Sie können vorab [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) für Ihre Notfalladministratoren im Notfallzugriffskonto erstellen, denen sichere Passwörtern und MFA-Token zugeordnet sind. Diese IAM users verfügen über Berechtigungen, um die IAM-Rollen anzunehmen, die dann den kontoübergreifenden Zugriff auf das AWS-Konto ermöglichen, für das der Notfallzugriff erforderlich ist. Wir empfehlen, so wenige solcher Benutzer wie möglich zu erstellen und jeden Benutzer einem einzelnen Notfalladministrator zuzuweisen. Während eines Notfalls meldet sich ein Notfalladministrator mit seinem Passwort und seinem MFA-Tokencode beim Notfallzugriffskonto an, wechselt zur IAM-Notfallzugriffsrolle im Notfallkonto und wechselt schließlich zur IAM-Notfallzugriffsrolle im Workload-Konto, um die für den Notfall erforderliche Änderungsaktion durchzuführen. Der Vorteil dieses Ansatzes besteht darin, dass jeder IAM user einem Notfalladministrator zugewiesen ist und Sie anhand der CloudTrail-Ereignisse feststellen können, welcher Benutzer sich angemeldet hat. Der Nachteil ist, dass Sie mehrere IAM users mit den zugehörigen langlebigen Passwörtern und MFA-Token verwalten müssen. 
+  Sie können den [Root-Benutzer für das Notfallzugriff-AWS-Konto](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) verwenden, um sich beim Notfallzugriffskonto anzumelden, die IAM-Rolle für den Notfallzugriff anzunehmen und dann die kontoübergreifende Rolle im Workload-Konto anzunehmen. Wir empfehlen, ein sicheres Passwort und mehrere MFA-Token für den Root-Benutzer festzulegen. Wir empfehlen außerdem, das Passwort und die MFA-Token in einem sicheren Vault für Unternehmensanmeldeinformationen zu speichern, der eine starke Authentifizierung und Autorisierung erzwingt. Sie sollten das Passwort und die Faktoren zum Zurücksetzen des MFA-Tokens sichern: Legen Sie die E-Mail-Adresse für das Konto auf eine E-Mail-Verteilerliste fest, die von Ihren Cloud-Sicherheitsadministratoren überwacht wird. Legen Sie die Telefonnummer des Kontos auf eine gemeinsam genutzte Telefonnummer fest, die ebenfalls von Sicherheitsadministratoren überwacht wird. Der Vorteil dieses Ansatzes besteht darin, dass nur ein Satz von Root-Benutzeranmeldeinformationen verwaltet werden muss. Der Nachteil ist, dass sich mehrere Administratoren als Root-Benutzer anmelden können, da es sich um einen gemeinsam genutzten Benutzer handelt. Sie müssen die Protokollereignisse für den Unternehmens-Vault überprüfen, um festzustellen, welcher Administrator das Passwort für den Root-Benutzer ausgecheckt hat. 

 **Ausfallmodus 2: Die Konfiguration des Identitätsanbieters in AWS wurde geändert oder ist abgelaufen** 

 Um den Verbund der Benutzer in Ihrem Unternehmen mit AWS-Konten zu ermöglichen, können Sie IAM Identity Center mit einem externen Identitätsanbieter konfigurieren oder einen IAM-Identitätsanbieter erstellen ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). In der Regel konfigurieren Sie diese, indem Sie ein XML-Dokument mit SAML-Metadaten importieren, das von Ihrem Identitätsanbieter bereitgestellt wird. Das XML-Metadatendokument enthält ein X.509-Zertifikat, das einem privaten Schlüssel entspricht, mit dem der Identitätsanbieter seine SAML-Zusicherungen signiert. 

 Diese Konfigurationen auf AWS-Seite können versehentlich von einem Administrator geändert oder gelöscht werden. In einem anderen Szenario läuft das in AWS importierte X.509-Zertifikat möglicherweise ab und eine neue XML-Metadatendatei mit einem neuen Zertifikat wurde noch nicht in AWS importiert. In beiden Szenarien kann der Verbund mit AWS für die Benutzer Ihrer Belegschaft unterbrochen werden, was zu einem Notfall führt. 

 In einem solchen Notfall können Sie Ihren Identitätsadministratoren Zugriff auf AWS gewähren, um die Verbundprobleme zu beheben. Ihr Identitätsadministrator verwendet beispielsweise den Notfallzugriffsprozess, um sich beim AWS-Konto für den Notfallzugriff anzumelden. Er wechselt zu einer Rolle im Identity Center-Administratorkonto und aktualisiert die Konfiguration des externen Identitätsanbieters, indem er das aktuelle XML-Dokument mit SAML-Metadaten von Ihrem Identitätsanbieter importiert, um den Verbund wieder zu aktivieren. Sobald der Verbund wiederhergestellt ist, verwenden die Benutzer in Ihrer Belegschaft weiter den normalen Betriebsprozess, um sich mit ihren Workload-Konten zu verbinden. 

 Sie können die oben für Ausfallmodus 1 beschriebenen Vorgehensweisen befolgen, um einen Notfallzugriffsprozess zu erstellen. Sie können Ihren Identitätsadministratoren Berechtigungen nach dem Prinzip der geringsten Rechte gewähren, sodass sie nur auf das Identity Center-Administratorkonto zugreifen und nur in diesem Konto Aktionen für Identity Center ausführen können. 

 **Ausfallmodus 3: Störung von Identity Center** 

 Für den unwahrscheinlichen Fall einer Störung von IAM Identity Center oder einer AWS-Region empfehlen wir, eine Konfiguration einzurichten, mit der Sie temporären Zugriff auf die AWS-Managementkonsole gewähren können. 

 Der Notfallzugriffsprozess verwendet einen direkten Verbund von Ihrem Identitätsanbieter zu IAM in einem Notfallkonto. Einzelheiten zu den Prozess- und Entwurfsüberlegungen finden Sie im [Artikel zum Einrichten des Notfallzugriffs auf die AWS-Managementkonsole](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html). 

### Implementierungsschritte
<a name="implementation-steps"></a>

 **Allgemeine Schritte für alle Ausfallmodi** 
+  Erstellen Sie ein AWS-Konto speziell für Notfallzugriffsprozesse. Erstellen Sie vorab die für das Konto benötigten IAM-Ressourcen wie IAM-Rollen oder IAM users und optional IAM-Identitätsanbieter. Erstellen Sie außerdem vorab kontoübergreifende IAM-Rollen in den AWS-Konten für den Workload mit Vertrauensbeziehungen zu den entsprechenden IAM-Rollen im Notfallzugriffskonto. Nutzen Sie Instrumentierungsservices wie [CloudFormation StackSets mit AWS Organizations,](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) um solche Ressourcen in den Mitgliedskonten Ihrer Organisation zu erstellen. 
+  Erstellen Sie in AWS Organizations [Service-Kontrollrichtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (Service Control Policies, SCPs), um das Löschen und Ändern der kontoübergreifenden IAM-Rollen in den AWS-Konten der Mitglieder zu verweigern. 
+  Aktivieren Sie CloudTrail für das AWS-Konto für den Notfallzugriff und senden Sie die Trail-Ereignisse an einen zentralen S3-Bucket im AWS-Konto für die Protokollerfassung. Wenn Sie AWS Control Tower verwenden, um Ihre AWS-Umgebung mit mehreren Konten einzurichten und zu verwalten, ist für jedes Konto, das Sie mit AWS Control Tower erstellen oder in AWS Control Tower registrieren, CloudTrail standardmäßig aktiviert und wird an einen S3-Bucket in einem dedizierten AWS-Konto für das Protokollarchiv gesendet. 
+  Überwachen Sie die Aktivitäten des Notfallzugriffskontos, indem Sie EventBridge-Regeln erstellen, die bei der Anmeldung in der Konsole und bei API-Aktivitäten durch die IAM-Notfallrollen greifen. Senden Sie Benachrichtigungen an Ihr Security Operations Center, wenn Aktivitäten außerhalb eines laufenden Notfallereignisses stattfinden, das in Ihrem Vorfallmanagement-System nachverfolgt wurde. 

 **Zusätzliche Schritte für Ausfallmodus 1 (Der für den Verbund mit AWS verwendete Identitätsanbieter ist nicht verfügbar) und Ausfallmodus 2 (Die Konfiguration des Identitätsanbieters in AWS wurde geändert oder ist abgelaufen)** 
+  Erstellen Sie vorab Ressourcen, je nachdem, welchen Mechanismus Sie für den Notfallzugriff wählen: 
  +  **Unter Verwendung der IAM users:** Erstellen Sie vorab die IAM users mit sicheren Passwörtern und den zugehörigen MFA-Geräten. 
  +  **Unter Verwendung des Root-Benutzers des Notfallkontos:** Konfigurieren Sie den Root-Benutzer mit einem sicheren Passwort und speichern Sie das Passwort im Unternehmens-Vault für Anmeldeinformationen. Ordnen Sie dem Root-Benutzer mehrere physische MFA-Geräte zu und bewahren Sie die Geräte an Orten auf, zu denen die Mitglieder Ihres Notfalladministratorteams schnell Zugang haben. 

 **Zusätzliche Schritte für den Ausfallmodus 3 (Störung von Identity Center)** 
+  Erstellen Sie wie im [Artikel zum Einrichten des Notfallzugriffs auf die AWS-Managementkonsole](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html) erläutert im AWS-Konto für den Notfallzugriff einen IAM-Identitätsanbieter, um den direkten SAML-Verbund von Ihrem Identitätsanbieter aus zu ermöglichen. 
+  Erstellen Sie Notfalleinsatzgruppen in Ihrem Identitätsanbieter ohne Mitglieder. 
+  Erstellen Sie IAM-Rollen, die den Notfalleinsatzgruppen im Notfallzugriffskonto entsprechen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden für Well-Architected:** 
+  [SEC02-BP04 Verlassen auf einen zentralen Identitätsanbieter](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html) 
+  [SEC03-BP02 Gewähren des Zugriffs mit den geringsten Berechtigungen](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html) 
+  [SEC10-BP02 Entwickeln von Vorfallmanagementplänen](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html) 
+  [SEC10-BP07 Durchführen von Gamedays](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html) 

 **Zugehörige Dokumente:** 
+  [Set up emergency access to the AWS-Managementkonsole (Einrichten des Notfallzugriffs auf die AWS-Managementkonsole)](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html) 
+  [Enabling SAML 2.0 federated users to access the AWS-Managementkonsole (Aktivieren des Zugriffs von SAML 2.0-Verbundbenutzern auf die AWS-Managementkonsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html) 
+  [Break glass access („Break Glass“-Zugriff)](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) 

 **Zugehörige Videos:** 
+  [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center (AWS re:Invent 2022 – Vereinfachen des vorhandenen Mitarbeiterzugriffs mit IAM Identity Center)](https://youtu.be/TvQN4OdR_0Y) 
+  [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive (AWS re:inforce 2022 – AWS Identity and Access Management (IAM) zur Vertiefung)](https://youtu.be/YMj33ToS8cI) 

 **Zugehörige Beispiele:** 
+  [AWS Break Glass Role (AWS-Rolle „Break Glass“)](https://github.com/awslabs/aws-break-glass-role) 
+  [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework) 
+  [AWS-Beispiele von Playbooks für die Vorfallsreaktion](https://github.com/aws-samples/aws-incident-response-playbooks) 

# SEC03-BP04 Kontinuierliche Reduzierung der Berechtigungen
<a name="sec_permissions_continuous_reduction"></a>

Wenn Ihre Teams bestimmen, welchen Zugriff sie benötigen, entfernen Sie unnötige Berechtigungen und erstellen Sie Überprüfungsprozesse, damit jederzeit dem Prinzip der geringsten Berechtigung entsprochen wird. Überwachen Sie Ihre Identitäten kontinuierlich und entfernen Sie ungenutzte Identitäten und Berechtigungen für den Zugriff von Menschen und Maschinen.

 **Gewünschtes Ergebnis:** Berechtigungsrichtlinien sollten dem Prinzip der geringsten Berechtigung folgen. Wenn Zuständigkeiten und Rollen immer besser definiert werden, müssen Sie Ihre Berechtigungsrichtlinien prüfen, um unnötige Berechtigungen zu entfernen. Dieses Konzept verringert die Auswirkungen, wenn Anmeldeinformationen versehentlich offen gelegt werden oder wenn anderweitig ohne Genehmigung darauf zugegriffen wird. 

 **Typische Anti-Muster:** 
+  standardmäßige Gewährung von Administratorberechtigungen für Benutzer 
+  Erstellung übermäßig lockerer Richtlinien, jedoch ohne vollständige Administratorberechtigungen 
+  Aufbewahrung von Berechtigungsrichtlinien, nachdem Sie nicht mehr benötigt werden 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Wenn Teams und Projekte gerade erst mit der Arbeit beginnen, können lockere Richtlinien verwendet werden, um Innovationen und Agilität zu unterstützen. So könnten beispielsweise Entwickler in einer Entwicklungs- und Testumgebung Zugang zu einer breiten Palette von AWS-Services erhalten. Wir empfehlen, den Zugriff kontinuierlich zu prüfen und auf sServices und Serviceaktionen einzuschränken, die für die anstehende Aufgabe wirklich benötigt werden. Wir empfehlen diese Evaluierung für menschliche und für maschinelle Identitäten. Maschinenidentitäten, manchmal auch als System- oder Servicekonten bezeichnet, sind Identitäten, die AWS den Zugriff auf Anwendungen oder Server ermöglichen. Dieser Zugriff ist besonders in einer Produktionsumgebung wichtig, in der übermäßig lockere Zugriffsregeln weitreichende Auswirkungen haben und möglicherweise Kundendaten offen legen könnten. 

 AWS bietet mehrere Verfahren zur Unterstützung der Identifizierung nicht verwendeter Benutzer, Rollen, Berechtigungen und Anmeldeinformationen. AWS kann auch bei der Analyse von Zugriffsaktivitäten von IAM-Benutzern und -Rollen helfen, darunter ebenfalls Analysen zu zugehörigen Zugriffsschlüsseln sowie zum Zugriff auf AWS-Ressourcen wie etwa Objekten in Amazon S3-Buckets. Die Generierung von Richtlinien mit AWS Identity and Access Management Access Analyzer kann Ihnen bei der Erstellung restriktiver Berechtigungsrichtlinien auf der Grundlage der Services und Aktionen helfen, mit denen ein Prinzipal tatsächlich interagiert. Die [attributbasierte Zugriffssteuerung (Attribute-based Access Control, ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) kann die Verwaltung von Berechtigungen vereinfachen, da Sie Benutzern Berechtigungen auf der Grundlage ihrer Attribute erteilen können, anstatt jedem Benutzer direkt Berechtigungsrichtlinien zuzuweisen. 

 **Implementierungsschritte** 
+  **Verwendung von [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html):** IAM Access Analyzer hilft bei der Identifizierung von Ressourcen in Ihrer Organisation und in Konten, wie etwa Amazon Simple Storage Service (Amazon S3)-Buckets oder IAM-Rollen, die[gemeinsam mit einer externen Entität genutzt werden](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html). 
+  **Verwendung der [Richtliniengenerierung von IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html): Die **Richtliniengenerierung von IAM Access Analyzer hilft bei der Erstellung [detaillierter Berechtigungsrichtlinien auf der Grundlage eines IAM-Benutzers oder der Zugriffsaktivität einer IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks). 
+  **Festlegen eines akzeptablen Zeitrahmens und einer Nutzungsrichtlinie für IAM-Benutzer und -Rollen**: Verwenden Sie den [Zeitstempel des letzten Zugriffs](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html), um [nicht verwendete Benutzer und Rollen zu identifizieren](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/) und diese zu entfernen. Prüfen Sie die Informationen zum letzten Zugriff auf Services und Aktionen, um [Berechtigungen für bestimmte Benutzer und Rollen zu identifizieren und entsprechend zuzuteilen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Sie können beispielsweise Informationen zum letzten Zugriff verwenden, um die spezifischen Amazon S3-Aktionen zu identifizieren, die Ihre Anwendungsrolle erfordert, und den Zugriff der Rolle auf diese Aktionen beschränken. Funktionen für die zuletzt abgerufenen Informationen sind in der AWS-Managementkonsole und programmgesteuert verfügbar, damit Sie sie in Ihre Infrastruktur-Workflows und automatisierten Tools integrieren können. 
+  **Erwägen Sie die [Protokollierung von Datenereignissen in AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html):** Standardmäßig protokolliert CloudTrail keine Datenereignisse wie Amazon S3-Aktivitäten auf Objektebene (zum Beispiel `GetObject` und `DeleteObject`) oder Amazon DynamoDB-Tabellenaktivitäten (zum Beispiel `PutItem` und `DeleteItem`). Erwägen Sie die Aktivierung der Protokollierung dieser Ereignisse, um zu ermitteln, welche Benutzer und Rollen Zugriff auf bestimmte Amazon S3-Objekte oder DynamoDB-Tabellenelemente benötigen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Gewähren von geringsten Berechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [Entfernen von nicht benötigten Anmeldeinformationen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+ [ Was ist AWS CloudTrail? ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+  [Arbeiten mit Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 
+ [ Protokollierung und Überwachung von DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ Enabling CloudTrail event logging for Amazon S3 buckets and objects ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) (Aktivieren von CloudTrail-Ereignisprotokollierung für Amazon-S3-Buckets und -Objekte)
+ [ Getting credential reports for your AWS-Konto](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) (Abrufen von Berichten zu Anmeldeinformationen für Ihr AWS-Konto)

 **Zugehörige Videos:** 
+  [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU) (Experte für IAM-Richtlinien in unter 60 Minuten werden) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70) (Trennung von Pflichten, geringste Berechtigung, Delegierung und CI/CD) 
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive ](https://www.youtube.com/watch?v=YMj33ToS8cI) (AWS re:inforce 2022 – AWS Identity and Access Management (IAM) zur Vertiefung)

# SEC03-BP05 Definieren eines Integritätsschutzes für Berechtigungen in Ihrer Organisation
<a name="sec_permissions_define_guardrails"></a>

 Richten Sie allgemeine Kontrollen ein, die den Zugriff auf alle Identitäten in Ihrer Organisation einschränken. Sie können beispielsweise den Zugriff auf bestimmte AWS-Regionen einschränken oder verhindern, dass Ihre Bediener gemeinsame Ressourcen löschen, z. B. eine IAM-Rolle, die für Ihr zentrales Sicherheitsteam verwendet wird. 

 **Typische Anti-Muster:** 
+ Ausführen von Workloads in Ihrem Organisationsadministrator-Konto 
+ Ausführen von Produktions- und Nicht-Produktionsworkloads im selben Konto 

 **Risikostufe, wenn diese bewährte Methode nicht genutzt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Wenn Sie im Zuge Ihres Wachstums zusätzliche Workloads in AWS verwalten, sollten Sie diese Workloads mithilfe von Konten trennen und die Konten mit AWS Organizations verwalten. Wir empfehlen, allgemeinen Integritätsschutz für Berechtigungen einzurichten, der den Zugriff auf alle Identitäten in Ihrer Organisation einschränkt. Sie können beispielsweise den Zugriff auf bestimmte AWS-Regionen einschränken oder verhindern, dass Mitglieder Ihres Teams gemeinsame Ressourcen löschen, z. B. eine IAM-Rolle, die vom zentralen Sicherheitsteam verwendet wird. 

 Sie können beginnen, indem Sie Beispiel-Servicekontrollrichtlinien implementieren, die beispielsweise verhindern, dass Benutzer wichtige Services deaktivieren. SCPs verwenden die IAM-Richtliniensprache und ermöglichen Ihnen, Kontrollen einzurichten, die alle IAM-Prinzipale (Benutzer und Rollen) einhalten müssen. Sie können den Zugriff auf bestimmte Serviceaktionen und Ressourcen oder basierend auf bestimmten Bedingungen einschränken, um die Zugriffskontrollanforderungen Ihrer Organisation zu erfüllen. Falls erforderlich, können Sie Ausnahmen zum Integritätsschutz definieren. Sie können beispielsweise Serviceaktionen für alle IAM-Entitäten im Konto mit Ausnahme einer bestimmten Administratorrolle einschränken. 

 Wir empfehlen, die Ausführung von Workloads in Ihrem Veraltungskonto zu vermeiden. Das Verwaltungskonto sollte für den Einsatz und die Bereitstellung von Integritätsschutz für die Sicherheit verwendet werden, der sich auf Mitgliedskonten auswirkt. Manche AWS-Services unterstützen die Verwendung eines delegierten Administratorkontos. Wenn ein solches delegiertes Konto verfügbar ist, sollten Sie es anstelle des Verwaltungskontos verwenden. Sie sollten den Zugriff auf das Organisationsadministratorkonto strengstens einschränken. 

Die Verwendung einer Mehrkonten-Strategie ermöglicht größere Flexibilität bei der Anwendung von Integritätsschutz auf Ihre Workloads. Die AWS Security Reference Architecture bietet präskriptive Anleitungen zur Gestaltung Ihrer Kontenstruktur. AWS-Services wie AWS Control Tower bieten Funktionen für die zentrale Verwaltung präventiver und erkennender Kontrollen in ihrer Organisation. Definieren Sie für jedes Konto bzw. jede OU in Ihrer Organisation einen klaren Zweck und schränken Sie die Steuerungen entsprechend diesem Zweck ein. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+ [AWS Organizations](https://aws.amazon.com/organizations/) 
+ [Service-Kontrollrichtlinien (SCPs),](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 
+ [Bessere Nutzung von Servicekontrollrichtlinien in einer Mehrkontenumgebung](https://aws.amazon.com/blogs/security/get-more-out-of-service-control-policies-in-a-multi-account-environment/) 
+ [AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html) 

 **Zugehörige Videos:** 
+ [Enforce Preventive Guardrails using Service Control Policies (Durchsetzung von präventivem Integritätsschutz mit Servicekontrollrichtlinien)](https://www.youtube.com/watch?v=mEO05mmbSms) 
+  [Building governance at scale with AWS Control Tower (Governance in großem Umfang mit AWS Control Tower)](https://www.youtube.com/watch?v=Zxrs6YXMidk) 
+  [AWS Identity and Access Management deep dive (Tiefer Einblick in AWS Identity and Access Management)](https://www.youtube.com/watch?v=YMj33ToS8cI) 

# SEC03-BP06 Zugriffsverwaltung basierend auf dem Lebenszyklus
<a name="sec_permissions_lifecycle"></a>

 Integrieren Sie Zugriffskontrollen in den Operator- und Anwendungslebenszyklus sowie Ihren zentralen Verbundanbieter. Entfernen Sie beispielsweise den Zugriff eines Benutzers, wenn er die Organisation verlässt oder eine andere Rolle übernimmt. 

Wenn Sie Workloads mit separaten Konten verwalten, müssen Sie Ressourcen für diese Konten freigeben. Wir empfehlen, dass Sie Ressourcen mit [AWS Resource Access Manager (AWS RAM)](http://aws.amazon.com/ram/). Mit diesem Service können Sie AWS-Ressourcen einfach und sicher innerhalb Ihrer AWS Organizations-Organisation und -Organisationseinheiten freigeben. Mithilfe von AWS RAM wird der Zugriff auf gemeinsam genutzte Ressourcen automatisch gewährt oder widerrufen, wenn Konten in die Organisation oder Organisationseinheit verschoben werden, für die sie freigegeben sind. Auf diese Weise können Sie sicherstellen, dass Ressourcen nur für die Konten freigegeben werden, die Sie beabsichtigen.

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Verwenden eines Lebenszyklus für den Benutzerzugriff: Implementieren Sie eine Lebenszyklusrichtlinie für den Benutzerzugriff für neue Benutzer, Änderungen von Zuständigkeiten und das Ausscheiden von Benutzern, um sicherzustellen, dass nur aktuelle Benutzer Zugriff haben. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Attributbasierte Zugriffskontrolle (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [Gewähren von geringsten Rechten](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 
+  [Entfernen von nicht benötigten Anmeldeinformationen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [Arbeiten mit Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 

 **Relevante Videos:** 
+  [Become an IAM Policy Master in 60 Minutes or Less (Experte für IAM-Richtlinien in unter 60 Minuten)](https://youtu.be/YQsK4MtsELU) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD (Trennung von Pflichten, geringste Berechtigung, Delegierung und CI/CD)](https://youtu.be/3H0i7VyTu70) 

# SEC03-BP07 Analysieren des öffentlichen und kontoübergreifenden Zugriffs
<a name="sec_permissions_analyze_cross_account"></a>

Überwachen Sie kontinuierlich Ergebnisse, die den öffentlichen und kontoübergreifenden Zugriff betreffen. Beschränken Sie den öffentlichen und kontoübergreifenden Zugriff ausschließlich auf Ressourcen, die diese Art von Zugriff benötigen.

 **Gewünschtes Ergebnis:** Wissen, welche Ihrer AWS-Ressourcen für wen freigegeben sind. Überwachen und prüfen Sie kontinuierlich Ihre freigegebenen Ressourcen, um sicherzustellen, dass sie nur für autorisierte Prinzipale freigegeben sind. 

 **Typische Anti-Muster:** 
+  fehlendes Inventar gemeinsam genutzter Ressourcen 
+  Nichtbefolgung eines Prozesses zur Genehmigung von kontoübergreifendem oder öffentlichem Zugriff auf Ressourcen 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Wenn sich Ihr Konto in AWS Organizations befindet, können Sie den Zugriff auf Ressourcen der gesamten Organisation, bestimmten Organisationseinheiten oder einzelnen Konten gewähren. Wenn Ihr Konto nicht zu einer Organisation gehört, können Sie Ressourcen für einzelne Konten freigeben. Sie können direkten kontoübergreifenden Zugriff mithilfe von Richtlinien gewähren, die an Ressourcen angefügt sind – (z. B. [Amazon Simple Storage Service (Amazon S3)-Bucket-Richtlinien](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) – oder indem Sie einem Prinzipal erlauben, eine IAM-Rolle in einem anderen Konto anzunehmen. Prüfen Sie bei der Verwendung von Ressourcenrichtlinien, dass der Zugriff nur autorisierten Prinzipalen gewährt ist. Definieren Sie einen Prozess für die Genehmigung aller Ressourcen, die öffentlich verfügbar sein müssen. 

 [AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) verwendet [belegbare Sicherheit](https://aws.amazon.com/security/provable-security/), um alle Zugriffspfade zu einer Ressource von außerhalb ihres Kontos zu identifizieren. Es überprüft Ressourcenrichtlinien kontinuierlich und meldet Ergebnisse des öffentlichen und kontoübergreifenden Zugriffs, um Ihnen die Analyse potenziell umfassender Zugriffe zu erleichtern. Erwägen Sie die Konfiguration von IAM Access Analyzer mit AWS Organizations, um die Transparenz aller Ihrer Konten sicherzustellen. IAM Access Analyzer ermöglicht Ihnen auch die [Voranzeige der Ergebnisse](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html) vor der Bereitstellung von Ressourcenberechtigungen. So können Sie sicherstellen, dass mit den Richtlinienänderungen nur der beabsichtigte öffentliche und kontoübergreifende Zugriff auf Ihre Ressourcen gewährt wird. Beim Entwurf des Mehrkonten-Zugriffs können Sie mit [Vertrauensrichtlinien](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) steuern, in welchen Fällen eine Rolle angenommen werden kann. So können Sie etwa den Bedingungsschlüssel [`PrincipalOrgId` verwenden, um den Versuch, eine Rolle von außerhalb Ihrer AWS Organizations anzunehmen, abzulehnen.](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) 

 [AWS Config kann Ressourcen melden](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html), die nicht korrekt konfiguriert sind, und über AWS Config-Richtlinienprüfungen Ressourcen erkennen, für die der öffentliche Zugriff konfiguriert ist. Services wie [AWS Control Tower](https://aws.amazon.com/controltower/) und [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) vereinfachen die Bereitstellung von Prüfungen und Integritätsschutz über AWS Organizations hinweg, um öffentlich zugängliche Ressourcen zu identifizieren und zu korrigieren. Beispielsweise verfügt AWS Control Tower über verwalteten Integritätsschutz, der erkennen kann, ob [Amazon EBS-Snapshots von AWS-Konten wiederhergestellt werden können.](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 

 **Implementierungsschritte** 
+  **Erwägen Sie die Aktivierung von [AWS Config für AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html):** AWS Config ermöglicht die Aggregierung von Ergebnissen mehrerer Konten in einer AWS Organizations zu einem delegierten Administratorkonto. Dies sorgt für eine umfassende Sicht und ermöglicht die [Bereitstellung von AWS-Config-Regeln über mehrere Konten hinweg, um öffentlich zugängliche Ressourcen zu erkennen](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html). 
+  **Konfiguration von AWS Identity and Access Management Access Analyzer:** IAM Access Analyzer hilft Ihnen, die Ressourcen in Ihrer Organisation und Ihren Konten zu identifizieren, z. B. Amazon S3-Buckets oder IAM-Rollen, die [mit einer externen Entität geteilt werden](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html). 
+  **Verwenden Sie die automatische Korrektur in AWS Config, um auf Änderungen in der Konfiguration des öffentlichen Zugriffs auf Amazon S3-Buckets reagieren zu können:** [Sie können die Einstellungen zur Blockierung des öffentlichen Zugriffs für Amazon S3-Buckets automatisch erneut aktivieren](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/). 
+  **Implementierung von Überwachung und Benachrichtigung, wenn Amazon S3-Buckets öffentlich zugänglich werden:** Sie müssen über [Überwachungs- und Benachrichtigungsmechanismen](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/) verfügen, um zu erkennen, wenn Amazon S3 Block Public Access deaktiviert ist, und wenn Amazon S3-Buckets öffentlich zugänglich werden. Dazu können Sie bei Verwendung von AWS Organizations eine [Servicekontrollrichtlinie](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) erstellen, die Änderungen an Amazon S3-Richtlinien für den öffentlichen Zugriff verhindern. AWS Trusted Advisor prüft auf Amazon S3-Buckets, die Open-Access-Berechtigungen haben. Bucket-Berechtigungen, die allen Benutzern den Zugriff zum Hochladen/Löschen einräumen, bergen ein hohes Potenzial für Sicherheitsrisiken, da alle Personen Elemente in einem Bucket hinzufügen, ändern oder löschen können. Die Prüfung von Trusted Advisor untersucht explizite Bucket-Berechtigungen und zugeordnete Bucket-Richtlinien, die die Bucket-Berechtigungen möglicherweise überschreiben. Sie können auch mit AWS Config Ihre Amazon S3-Buckets für den öffentlichen Zugriff überwachen. Für weitere Informationen vgl. [Verwendung von AWS Config zur Überwachung und Reaktion auf Amazon S3-Buckets mit öffentlicher Zugänglichkeit](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/). Bei der Prüfung der Zugänglichkeit ist es wichtig, zu berücksichtigen, welche Art von Daten Amazon S3-Buckets enthalten. [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) hilft dabei, sensitive Daten wie etwa PII, PHI und Anmeldeinformationen wie private oder AWS-Schlüssel zu erkennen und zu schützen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Verwendung von AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [AWS Control Tower Controls Library ](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+  [AWS Foundational Security Best Practices Standard](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+  [AWS Config Managed Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html) 
+  [Prüfungsreferenz von AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) 
+ [ Monitoring AWS Trusted Advisor check results with Amazon EventBridge ](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html) (Überwachen der Prüfergebnisse von AWS Trusted Advisor mit Amazon EventBridge)
+ [ Managing AWS Config Rules Across All Accounts in Your Organization ](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html) (Verwaltung von AWS Config-Regeln für alle Konten in Ihrer Organisation)
+ [AWS Config und AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)

 **Zugehörige Videos:** 
+ [Best Practices for securing your multi-account environment](https://www.youtube.com/watch?v=ip5sn3z5FNg)(Bewährte Methoden für den Schutz Ihrer Mehrkonten-Umgebung)
+ [Dive Deep into IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0) (Tiefer Einblick in IAM Access Analyzer)

# SEC03-BP08 Sicheres gemeinsames Nutzen von Ressourcen in Ihrer Organisation
<a name="sec_permissions_share_securely"></a>

Wenn die Anzahl der Workloads zunimmt, müssen Sie möglicherweise den Zugriff auf Ressourcen in diesen Workloads ausweiten oder diese Ressourcen mehrfach über mehrere Konten hinweg zugänglich machen. Möglicherweise haben Sie Konstrukte zur Untergliederung Ihrer Umgebung, etwa für Entwicklungs-, Test- und Produktionsumgebungen. Solche Trennungskonstrukte schränken Sie jedoch nicht in der Lage ein, sicher zu teilen. Durch die gemeinsame Nutzung sich überschneidender Ressourcen können Sie übermäßigen betrieblichen Aufwand reduzieren und eine konsistente Umgebung schaffen, ohne dass Sie raten müssen, was Sie vielleicht versäumt haben, wenn Sie eine Ressource mehrmals erstellen. 

 **Gewünschtes Ergebnis:** Minimierung unbeabsichtigter Zugriffe durch Verwendung sicherer Verfahren für die Freigabe von Ressourcen innerhalb Ihrer Organisation und die Unterstützung Ihrer Initiative zur Verhinderung von Datenverlusten. Reduzieren Sie Ihren organisatorischen Aufwand gegenüber der Verwaltung einzelner Komponenten, senken Sie die Zahl von Fehlern durch das manuelle mehrmalige Erstellen identischer Ressourcen, und steigern Sie die Skalierbarkeit Ihrer Workloads. Sie können von kürzeren Lösungszeiten in Szenarien mit mehreren Fehlerpunkten profitieren und Ihr Vertrauen in die Bestimmung erhöhen, wann eine Komponente nicht mehr benötigt wird. Anleitungen zur Analyse extern freigegebener Ressourcen finden Sie unter [SEC03-BP07 Analysieren des öffentlichen und kontoübergreifenden Zugriffs](sec_permissions_analyze_cross_account.md). 

 **Typische Anti-Muster:** 
+  Fehlen eines Prozesses für die kontinuierliche Überwachung und die automatische Benachrichtigung bei unerwarteten externen Freigaben 
+  Fehlen einer Basislinie dazu, was freigegeben werden sollte und was nicht 
+  die standardmäßige Verwendung einer sehr offenen Richtlinie, anstatt Ressourcen explizit freizugeben, wenn sie benötigt werden 
+  manuelle Erstellung grundlegender Ressourcen bei Bedarf, die sich überlappen 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Gestalten Sie Ihre Zugriffskontrollen und -muster so, dass die Nutzung freigegebener Ressourcen kontrolliert wird und nur mit vertrauenswürdigen Entitäten möglich ist. Überwachen Sie freigegebene Ressourcen, prüfen Sie kontinuierlich den Zugriff darauf und erhalten Sie Benachrichtigungen bei unangemessenen oder unerwarteten Freigaben. Lesen Sie [Analysieren öffentlicher und kontoübergreifender Zugriffe](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html), um Richtlinien einzurichten, die externe Zugriffe auf die Ressourcen beschränken, für die dies erforderlich ist, und um einen Prozess zur kontinuierlichen Überwachung und Benachrichtigung einzurichten. 

 Die kontoübergreifende Freigabe innerhalb von AWS Organizations wird von [einer Reihe von AWS-Services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) unterstützt, wie etwa [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) und [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html). Diese Services ermöglichen die Freigabe von Daten für ein zentrales Konto, ihre Zugänglichkeit von einem zentralen Konto aus sowie die Verwaltung von Ressourcen und Daten von einem zentralen Konto aus. Beispielsweise kann AWS Security Hub CSPM Ergebnisse von einzelnen Konten auf ein zentrales Konto übertragen, wo Sie alle Ergebnisse einsehen können. AWS Backup kann eine Sicherungskopie einer Ressource kontoübergreifend freigeben. Sie können mit [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) weitere verbreitete Ressourcen freigeben, wie etwa [VPC-Subnetze und Transit Gateway-Anhänge](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) oder [Amazon SageMaker AI-Pipelines.](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker) 

 Um Ihr Konto darauf zu beschränken, Ressourcen nur innerhalb Ihrer Organisation freizugeben, verwenden Sie [Service Control Policies (SCPs, Service-Kontrollrichtlinien)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html), um den Zugriff auf externe Prinzipale zu verhindern. Kombinieren Sie bei der Freigabe von Ressourcen identitätsbasierte Kontrollen und Netzwerk-Kontrollen zur [Erstellung eines Datenperimeters für Ihre Organisation](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) zum Schutz gegen unbeabsichtigte Zugriffe. Ein Datenperimeter ist ein Satz von präventiven Maßnahmen zum Integritätsschutz, die dabei helfen, sicherzustellen, dass nur vertrauenswürdige Identitäten aus erwarteten Netzwerken auf vertrauenswürdige Ressourcen zugreifen. Diese Kontrollen begrenzen, welche Ressourcen gemeinsam genutzt werden, und verhindern die gemeinsame Nutzung oder Offenlegung von Ressourcen, die nicht zugelassen werden sollten. So können Sie Beispielsweise als Teil ihres Datenperimeters VPC-Endpunktrichtlinien und die Bedingung ` AWS:OrincipalOrgID` verwenden, um sicherzustellen, dass die auf Ihre Amazon S3-Buckets zugreifenden Identitäten zu Ihrer Organisation gehören. Es ist wichtig zu wissen, dass [SCPs nicht für serviceverknüpfte Rollen (LSR) oder AWS-Service-Prinzipale gelten](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions). 

 Bei Verwendung von Amazon S3 sollten Sie [ACLs für Ihren Amazon S3-Bucket deaktivieren](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) und IAM-Richtlinien für die Einrichtung der Zugriffskontrollen verwenden. Für die [Einschränkung des Zugriffs auf einen Amazon S3-Ursprung](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) von [Amazon CloudFront](https://aws.amazon.com/cloudfront/) aus migrieren Sie von der Ursprungszugriffsidentität (OAI) zur Ursprungszugriffssteuerung (OAC), die zusätzliche Funktionen wie beispielsweise die serverseitige Verschlüsselung mit [AWS Key Management Service](https://aws.amazon.com/kms/) unterstützt. 

 In manchen Fällen möchten Sie möglicherweise die Freigabe von Ressourcen außerhalb Ihrer Organisation zulassen oder einer Drittpartei den Zugriff auf Ihre Ressourcen gewähren. Präskriptive Anleitungen zur Verwaltung von Berechtigungen für die externe Freigabe von Ressourcen finden Sie unter[Berechtigungsmanagement](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html). 

 **Implementierungsschritte** 

1.  **Nutzen Sie AWS Organizations.** 

    AWS Organizations ist ein Kontoverwaltungsservice, mit dem Sie mehrere AWS-Konten zu einer zentral erstellten und verwalteten Organisation konsolidieren können. Sie können Ihre Konten in Organisationseinheiten (OUs) gruppieren und jeder OU unterschiedliche Richtlinien zuweisen, um Ihre Budget-, Sicherheits- und Compliance-Anforderungen zu erfüllen. Sie können auch steuern, wie AWS-Services für künstliche Intelligenz (KI) und Machine Learning (ML) Daten erfassen und speichern können, und die Mehrkonten-Verwaltung der mit Organizations integrierten AWS-Services verwenden. 

1.  **Integrieren Sie AWS Organizations mit AWS-Services.** 

    Wenn Sie einen AWS-Service zur Ausführung von Aufgaben in Ihrem Namen in den Mitgliedskonten Ihrer Organisation aktivieren, erstellt AWS Organizations eine serviceverknüpfte IAM-Rolle für den jeweiligen Service in jedem Mitgliedskonto. Sie sollten den vertrauenswürdigen Zugriff mit der AWS-Managementkonsole, den AWS-APIs oder der AWS CLI verwalten. Präskriptive Anleitungen zur Einrichtung vertrauenswürdigen Zugangs finden Sie unter [Verwendung von AWS Organizations mit anderen AWS-Services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) und unter [AWS-Services, die Sie mit Organizations verwenden können](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html). 

1.  **Richten Sie einen Datenperimeter ein.** 

    Der AWS-Perimeter wird typischerweise als von AWS Organizations verwaltete Organisation repräsentiert. Zusammen mit On-Premises-Netzwerken und -Systemen ist der Zugriff auf AWS-Ressourcen das, was viele als den Perimeter von My AWS bezeichnen. Das Ziel des Perimeters besteht darin, zu überprüfen, ob der Zugriff erlaubt ist, wenn die Identität und die Ressource vertrauenswürdig sind und es sich um ein erwartetes Netzwerk handelt. 

   1.  Definieren und implementieren Sie die Perimeter. 

       Befolgen Sie die Schritte unter [Perimeter-Implementierung](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html) im Whitepaper zum Thema „Aufbau eines Perimeters in AWS“ für jede Autorisierungsbedingung. Eine präskriptive Anleitung zum Schutz von Netzwerkebenen finden Sie unter [Schutz von Netzwerken](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-networks.html). 

   1.  Sorgen Sie für kontinuierliche Überwachung und Benachrichtigung. 

       [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) hilft bei der Identifizierung von Ressourcen in Ihrer Organisation und in Konten, die gemeinsam mit externen Entitäten genutzt werden. Sie können [IAM Access Analyzer mit AWS Security Hub CSPM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-securityhub-integration.html) integrieren, um Ergebnisse für eine Ressource von IAM Access Analyzer zu Security Hub CSPM zu senden und zu aggregieren und so die Sicherheitssituation ihrer Umgebung zu analysieren. Aktivieren Sie für die Integration IAM Access Analyzer und Security Hub CSPM in jeder Region und in jedem Konto. Sie können auch mit AWS-Config-Regeln die Konfiguration prüfen und die jeweilige Partei mit [Amazon Q Developer in chat applications mit AWS Security Hub CSPM](https://aws.amazon.com/blogs/security/enabling-aws-security-hub-integration-with-aws-chatbot/) benachrichtigen. Anschließend können Sie mit [Automatisierungsdokumenten von AWS Systems Manager](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) nicht-konforme Ressourcen reparieren. 

   1.  Präskriptive Anleitungen zur Überwachung und kontinuierlichen Beratung zu extern freigegebenen Ressourcen finden Sie unter [Analyse des öffentlichen und kontoübergreifenden Zugriffs](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html). 

1.  **Verwenden Sie die Ressourcenfreigabe in AWS-Services, und sorgen Sie für entsprechende Einschränkungen.** 

    Viele AWS-Services erlauben die Freigabe von Ressourcen für ein anderes Konto oder die Ausrichtung auf eine Ressource in einem anderen Konto, wie etwa [Amazon Machine Images (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) und [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html). Schränken Sie die `ModifyImageAttribute`-API auf die Angabe der vertrauenswürdigen Konten für die Freigabe des AMI ein. Geben Sie die Bedingung `ram:RequestedAllowsExternalPrincipals` bei Verwendung von AWS RAM an, um die Freigabe auf Ihre Organisation zu beschränken und Zugriffe von nicht vertrauenswürdigen Entitäten zu verhindern. Präskriptive Anleitungen und Überlegungen dazu finden Sie unter [Ressourcenfreigabe und externe Ziele](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html). 

1.  **Verwenden Sie AWS RAM für sichere Freigaben in einem Konto oder mit anderen AWS-Konten.** 

    [AWS RAM](https://aws.amazon.com/ram/) hilft bei der sicheren Freigabe der Ressourcen, die Sie erstellt haben, mit Rollen und Benutzern in Ihrem Konto sowie mit anderen AWS-Konten. In einer Mehrkonten-Umgebung ermöglicht AWS RAM die einmalige Erstellung einer Ressource und ihre Freigabe für andere Konten. Dies reduziert Ihren operationalen Aufwand und sorgt für Konsistenz, Transparenz und Prüfbarkeit durch Integrationen mit Amazon CloudWatch und AWS CloudTrail, die bei Verwendung eines kontoübergreifenden Zugriffs nicht möglich sind. 

    Wenn Sie Ressourcen bereits mit einer ressourcenbasierten Richtlinie freigegeben haben, können Sie mit der [`PromoteResourceShareCreatedFromPolicy`-API](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) oder einem Äquivalent die Ressourcenfreigabe zu einer vollständigen AWS RAM-Ressourcenfreigabe erhöhen. 

    In manchen Fällen müssen Sie möglicherweise weitere Schritte unternehmen, um Ressourcen freizugeben. So müssen Sie etwa für die Freigabe eines verschlüsselten Snapshots [einen AWS KMS-Schlüssel freigeben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key). 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [SEC03-BP07 Analysieren des öffentlichen und kontoübergreifenden Zugriffs](sec_permissions_analyze_cross_account.md) 
+  [SEC03-BP09 Sicheres Teilen von Ressourcen mit Dritten](sec_permissions_share_securely_third_party.md) 
+  [SEC05-BP01 Erstellen von Netzwerkebenen](sec_network_protection_create_layers.md) 

 **Zugehörige Dokumente:** 
+ [Bucket-Besitzer gewährt kontoübergreifende Berechtigung für Objekte, die er nicht besitzt](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [Verwendung von Vertrauensrichtlinien mit IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Erstellen von Datenperimetern auf AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [Verwenden einer externen ID, um Dritten Zugriff auf Ihre AWS-Ressourcen zu gewähren](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [AWS-Services, die Sie mit AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) verwenden können
+ [Einrichten eines Datenperimeters auf AWS: Zulassen ausschließlich vertrauenswürdiger Identitäten für den Zugriff auf Unternehmensdaten ](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)

 **Zugehörige Videos:** 
+ [Granular Access with AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s) (Granulärer Zugriff mit AWS Resource Access Manager)
+ [Securing your data perimeter with VPC endpoints](https://www.youtube.com/watch?v=iu0-o6hiPpI) (Schutz Ihres Datenperimeters mit VPC-Endpunkten)
+ [ Establishing a data perimeter onAWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)(Einrichten eines Datenperimeters auf AWS)

 **Zugehörige Tools:** 
+ [ Beispiele für eine Datenperimeterrichtlinie ](https://github.com/aws-samples/data-perimeter-policy-examples)

# SEC03-BP09 Sicheres Teilen von Ressourcen mit Dritten
<a name="sec_permissions_share_securely_third_party"></a>

 Die Sicherheit Ihrer Cloud-Umgebung endet nicht bei Ihrer Organisation. Möglicherweise stützt sich Ihre Organisation auf eine Drittpartei, um einen Teil Ihrer Daten zu verwalten. Das Berechtigungsmanagement für das von Dritten verwaltete System sollte dem Prinzip des Just-in-time-Zugriffs und dem der geringsten Berechtigung mit temporären Anmeldeinformationen folgen. Durch die enge Zusammenarbeit mit einer Drittpartei können Sie die möglichen Auswirkungen und das Risiko unbeabsichtigter Zugriffe gemeinsam senken. 

 **Gewünschtes Ergebnis:** Langfristige AWS Identity and Access Management (IAM)-Anmeldeinformationen, IAM-Zugriffsschlüssel und geheime Schlüssel, die einem Benutzer zugeordnet sind, können von allen verwendet werden, sofern sie gültig und aktiv sind. Die Verwendung einer IAM-Rolle und temporärer Anmeldeinformationen hilft bei der Verbesserung Ihrer allgemeinen Sicherheitsposition durch Reduzierung des Aufwands für die Verwaltung langfristiger Anmeldeinformationen und des operationalen Overheads dieser sensiblen Details. Durch die Verwendung einer universell eindeutigen Kennung (UUID) für die externe ID in der IAM-Vertrauensrichtlinie und die Anbindung der IAM-Richtlinien an die IAM-Rolle unter Ihrer Kontrolle können Sie prüfen und sicherstellen, dass der der Drittpartei gewährte Zugriff nicht zu umfangreich ist. Anleitungen zur Analyse extern freigegebener Ressourcen finden Sie unter [SEC03-BP07 Analysieren des öffentlichen und kontoübergreifenden Zugriffs](sec_permissions_analyze_cross_account.md). 

 **Typische Anti-Muster:** 
+  Verwendung der Standard-IAM-Vertrauensrichtlinie ohne Bedingungen 
+  Verwenden langfristiger IAM-Anmeldeinformationen und Zugriffsschlüssel 
+  Wiederverwendung externer IDs 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Möglicherweise möchten Sie die Freigabe von Ressourcen außerhalb von AWS Organizations zulassen oder einer Drittpartei den Zugriff auf Ihr Konto gewähren. So könnte etwa eine Drittpartei eine Überwachungslösung bereitstellen, die auf Ressourcen in Ihrem Konto zugreifen muss. In solchen Fällen sollten Sie eine kontoübergreifende IAM-Rolle erstellen, die nur über die von der Drittpartei benötigten Berechtigungen verfügt. Definieren Sie dazu eine Vertrauensrichtlinie mit der [externen ID-Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). Wenn eine externe ID verwendet wird, können Sie oder die Drittpartei eine eindeutige ID für jede(n) Kunden, Drittpartei oder Tenancy generieren. Die eindeutige ID sollte nach ihrer Erstellung ausschließlich von Ihnen kontrolliert werden. Die Drittpartei muss einen Prozess implementieren, durch den die externe ID in sicherer, prüfbarer und reproduzierbarer Weise dem Kunden zugeordnet wird. 

 Sie können auch [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) verwenden, um IAM-Rollen für Anwendungen außerhalb von AWS zu verwalten, die AWS-APIs verwenden. 

 Wenn die Drittpartei keinen Zugriff mehr auf Ihre Umgebung benötigt, entfernen Sie die Rolle. Vermeiden Sie die Weitergabe langfristiger Anmeldeinformationen an Dritte. Achten Sie auf andere AWS-Services, die die Freigabe unterstützen. Beispielsweise erlaubt AWS Well-Architected Tool [die Freigabe eines Workloads](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) für andere AWS-Konten, und [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) hilft Ihnen bei der sicheren Freigabe einer AWS-Ressource, deren Eigentümer Sie sind, für andere Konten. 

 **Implementierungsschritte** 

1.  **Verwenden Sie kontoübergreifende Rollen, um Zugriff auf externe Konten zu gewähren.** 

    [Kontoübergreifende Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) reduzieren den Umfang sensibler Informationen, die von externen Konten und Drittparteien für deren Kunden gespeichert werden. Kontoübergreifende Rollen ermöglichen die sichere Gewährung des Zugriffes auf AWS-Ressourcen in Ihrem Konto für Drittparteien wie etwa AWS Partners oder andere Konten in Ihrer Organisation, bei gleichzeitiger Wahrung der Möglichkeit, diesen Zugriff zu verwalten und zu überprüfen. 

    Möglicherweise stellt Ihnen die Drittpartei Dienstleistungen aus einer hybriden Infrastruktur heraus bereit oder ruft Daten zu einem anderen Standort ab. [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) hilft Ihnen bei der Aktivierung von Workloads Dritter zur sicheren Interaktion mit Ihren AWS-Workloads und zur weiteren Reduzierung der Erfordernis langfristiger Anmeldeinformationen. 

    Sie sollten keine langfristigen Anmeldeinformationen oder mit Benutzern verbundene Zugriffsschlüssel für die externe Gewährung des Zugriffs auf Konten verwenden. Verwenden Sie stattdessen kontoübergreifende Rollen, um kontoübergreifenden Zugriff zu gewähren. 

1.  **Verwenden Sie eine externe ID mit Drittparteien.** 

    Die Verwendung einer [externen ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) ermöglicht Ihnen, in einer IAM-Vertrauensrichtlinie festzulegen, wer eine Rolle annehmen kann. Die Vertrauensrichtlinie kann verlangen, dass der Benutzer, der die Rolle annimmt, die Bedingung und das Ziel seiner Aktivität bestätigt. Sie bietet dem Kontoinhaber auch die Möglichkeit, die anzunehmende Rolle nur unter bestimmten Umständen zuzulassen. Die primäre Funktion der externen ID besteht darin, das [Confused-Deputy](https://docs.aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/)-Problem anzugehen und zu verhindern. 

    Verwenden Sie eine externe ID, wenn Sie AWS-Konto-Eigentümer sind und eine Rolle für eine Drittpartei konfiguriert haben, die neben Ihrem auf andere AWS-Konten zugreift, oder wenn Sie Rollen für verschiedene Kunden annehmen. Arbeiten Sie zusammen mit der Drittpartei oder AWS Partner an der Einrichtung einer externen ID-Bedingung für die IAM-Vertrauensrichtlinie. 

1.  **Verwenden Sie universell eindeutige externe IDs.** 

    Implementieren Sie einen Prozess, der für externe IDs zufällige und eindeutige Werte generiert, etwa eine universell eindeutige Kennung (UUID). Eine Drittpartei, die externe IDs für verschiedene Kunden wiederverwendet, behebt das Confused-Deputy-Problem nicht, da Kunde A möglicherweise unter Verwendung des Rollen-ARN von Kunde B zusammen mit der duplizierten externen ID die Daten von Kunde B einsehen kann. In einer Multi-Tenant-Umgebung, in der eine Drittpartei mehrere Kunden mit verschiedenen AWS-Konten unterstützt, muss die Drittpartei eine andere eindeutige ID als die externe ID für jedes AWS-Konto verwenden. Die Drittpartei ist für das Erkennen doppelter externer IDs und die sichere Zuordnung jedes Kunden zur entsprechenden externen ID verantwortlich. Die Drittpartei muss durch Testen sicherstellen, dass sie die Rolle nur annehmen kann, wenn die externe ID angegeben wird. Die Drittpartei sollte den ARN der Kundenrolle und die externe ID nicht speichern, bis die externe ID benötigt wird. 

    Die externe ID wird nicht als Secret behandelt, ihr Wert darf aber nicht leicht zu erraten sein wie etwa eine Telefonnummer, ein Name oder eine Konto-ID. Machen Sie die externe ID zu einem schreibgeschützten Feld, damit sie nicht für illegitime Einrichtungen geändert werden kann. 

    Sie oder die Drittpartei können/kann die externe ID generieren. Richten Sie einen Prozess ein, um festzulegen, wer für die Generierung der ID verantwortlich ist. Unabhängig von der Entität, die die externe ID erstellt, setzt die Drittpartei Eindeutigkeit und Formate in konsistenter Weise für alle Kunden durch. 

1.  **Nehmen Sie von Kunden bereitgestellte langfristige Anmeldeinformationen außer Betrieb.** 

    Beenden Sie die Verwendung langfristiger Anmeldeinformationen, und verwenden Sie kontoübergreifende Rollen oder IAM Roles Anywhere. Wenn Sie langfristige Anmeldeinformationen verwendet müssen, formulieren Sie einen Plan für die Migration rollenbasierter Zugriffe. Einzelheiten zur Verwaltung von Schlüsseln finden Sie unter[Identitätsmanagement](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html). Arbeiten Sie auch mit Ihrem AWS-Konto-Team und der Drittpartei daran, ein Runbook zur Risikodämpfung zu erstellen. Präskriptive Anleitungen zur Reaktion auf mögliche Auswirkungen von Sicherheitsvorfällen finden Sie unter [Vorfallbehandlung](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html). 

1.  **Prüfen Sie, ob die Einrichtung über präskriptive Anleitungen verfügt oder automatisiert ist.** 

    Die für den kontoübergreifenden Zugriff in Ihren Konten erstellte Richtlinie muss dem [Prinzip der geringsten Berechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) folgen. Die Drittpartei muss ein Rollenrichtliniendokument oder einen automatisierten Einrichtungsmechanismus bereitstellen, der eine AWS CloudFormation-Vorlage oder ein Äquivalent verwendet. Dies reduziert die Gefahr von Fehlern durch die manuelle Erstellung von Richtlinien und bietet einen Überwachungspfad. Weitere Informationen zur Verwendung einer CloudFormation-Vorlage für die Erstellung kontoübergreifender Rollen finden Sie unter [Kontoübergreifende Rollen](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/). 

    Die Drittpartei muss einen automatisierten und prüfbaren Einrichtungsmechanismus bereitstellen. Sie sollten jedoch die Einrichtung der Rolle automatisieren, indem Sie das Rollenrichtliniendokument verwenden, das den erforderlichen Zugriff angibt. Sie sollten mit der CloudFormation-Vorlage oder einem Äquivalent Änderungen überwachen, mit besonderem Augenmerk auf „Drift Detection“. 

1.  **Berücksichtigen Sie Änderungen.** 

    Ihre Kontostruktur und Ihr Bedarf an einer Drittpartei bzw. deren Serviceangebots können sich über Nacht ändern. Sie sollten Änderungen und Ausfälle antizipieren und mit den richtigen Personen, Prozessen und Technologielösungen entsprechend planen. Prüfen Sie regelmäßig das von Ihnen bereitgestellte Zugriffsniveau und implementieren Sie Erkennungsverfahren, die Sie auf unerwartete Änderungen aufmerksam machen. Überwachen und prüfen Sie die Verwendung der externen Rolle und den Datenspeicher der externen IDs. Sie sollten darauf vorbereitet sein, den Zugriff der Drittpartei temporär oder dauerhaft zu widerrufen, wenn sich unerwartete Änderungen oder Zugriffsmuster ergeben. Messen Sie auch die Auswirkungen Ihrer Widerrufaktion, einschließlich der dafür benötigten Zeit, der involvierten Personen, der Kosten und der Auswirkungen auf andere Ressourcen. 

    Präskriptive Anleitungen zu Erkennungsverfahren finden Sie unter [Bewährte Erkennungsmethoden](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html). 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [SEC02-BP02 Verwenden von temporären Anmeldeinformationen](sec_identities_unique.md) 
+  [SEC03-BP05 Definieren eines Integritätsschutzes für Berechtigungen in Ihrer Organisation](sec_permissions_define_guardrails.md) 
+  [SEC03-BP06 Zugriffsverwaltung basierend auf dem Lebenszyklus](sec_permissions_lifecycle.md) 
+  [SEC03-BP07 Analysieren des öffentlichen und kontoübergreifenden Zugriffs](sec_permissions_analyze_cross_account.md) 
+ [ SEC04 Detection ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)

 **Zugehörige Dokumente:** 
+ [Bucket-Besitzer gewährt kontoübergreifende Berechtigung für Objekte, die er nicht besitzt](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [Verwendung von Vertrauensrichtlinien mit IAM-Rollen](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Delegieren des Zugriffs in allen AWS-Konten mithilfe von IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [Wie greife ich mit IAM auf Ressourcen in einem anderen AWS-Konto zu?](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [ Bewährte Sicherheitsmethoden in IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [ Logik für die kontenübergreifende Richtlinienauswertung ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [Verwenden einer externen ID, um Dritten Zugriff auf Ihre AWS-Ressourcen zu gewähren](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [ Collecting Information from AWS CloudFormation Resources Created in External Accounts with Custom Resources ](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)(Erfassen von Informationen von in externen Konten mit benutzerdefinierten Ressourcen erstellten AWS-CloudFormation-Ressourcen)
+ [Securely Using External ID for Accessing AWS Accounts Owned by Others ](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)(Sichere Verwendung einer externen ID für den Zugriff auf AWS-Konten, die anderen gehören)
+ [ Extend IAM roles to workloads outside of IAM with IAM Roles Anywhere ](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)(Erweitern von IAM-Rollen auf Workloads außerhalb von IAM mit IAM Roles Anywhere)

 **Zugehörige Videos:** 
+ [ How do I allow users or roles in a separate AWS-Konto access to my AWS-Konto? ](https://www.youtube.com/watch?v=20tr9gUY4i0) (Wie gewähre ich Benutzern oder Rollen in einem separaten AWS-Konto Zugriff auf mein AWS-Konto?)
+ [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less ](https://www.youtube.com/watch?v=YQsK4MtsELU) (AWS re:Invent 2018: Werden Sie in höchstens 60 Minuten zum IAM-Richtlinienexperten)
+ [AWS Knowledge Center Live: IAM Best Practices and Design Decisions ](https://www.youtube.com/watch?v=xzDFPIQy4Ks) (AWS Knowledge Center Live: Bewährte IAM-Methoden und -Entwurfsentscheidungen)

 **Zugehörige Beispiele:** 
+ [ Well-Architected Lab - Lambda cross account IAM role assumption (Level 300) ](https://www.wellarchitectedlabs.com/security/300_labs/300_lambda_cross_account_iam_role_assumption/) (Well-Architected Lab – Lambda-kontoübergreifende IAM-Rollenannahme)
+ [ Configure cross-account access to Amazon DynamoDB ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html) (Konfigurieren des kontoübergreifenden Zugriffs auf Amazon DynamoDB)
+ [AWS STS Network Query Tool ](https://github.com/aws-samples/aws-sts-network-query-tool)