diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index 454340d18..5fd942002 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -21,7 +21,7 @@ Daher gibt es **zwei Arten von Konten in einer Organisation** (wir sprechen von - Konten aus der Organisation entfernen - Einladungen verwalten - Richtlinien auf Entitäten (Roots, OUs oder Konten) innerhalb der Organisation anwenden -- Die Integration mit unterstützten AWS-Diensten aktivieren, um die Dienstfunktionalität über alle Konten in der Organisation bereitzustellen. +- Die Integration mit unterstützten AWS-Diensten aktivieren, um die Funktionalität über alle Konten in der Organisation bereitzustellen. - Es ist möglich, sich als Root-Benutzer mit der E-Mail-Adresse und dem Passwort anzumelden, die zur Erstellung dieses Root-Kontos/Organisation verwendet wurden. Das Verwaltungskonto hat die **Verantwortlichkeiten eines Zahlungskontos** und ist verantwortlich für die Bezahlung aller Gebühren, die von den Mitgliedskonten angefallen sind. Sie können das Verwaltungskonto einer Organisation nicht ändern. @@ -40,7 +40,7 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU ``` ### Service Control Policy (SCP) -Eine **Service Control Policy (SCP)** ist eine Richtlinie, die die Dienste und Aktionen angibt, die Benutzer und Rollen in den Konten, auf die die SCP Einfluss hat, verwenden können. SCPs sind **ähnlich wie IAM** Berechtigungsrichtlinien, mit dem Unterschied, dass sie **keine Berechtigungen gewähren**. Stattdessen geben SCPs die **maximalen Berechtigungen** für eine Organisation, eine organisatorische Einheit (OU) oder ein Konto an. Wenn Sie eine SCP an den Root Ihrer Organisation oder an eine OU anhängen, **beschränkt die SCP die Berechtigungen für Entitäten in Mitgliedskonten**. +Eine **Service Control Policy (SCP)** ist eine Richtlinie, die die Dienste und Aktionen spezifiziert, die Benutzer und Rollen in den Konten, auf die die SCP Einfluss hat, verwenden können. SCPs sind **ähnlich wie IAM** Berechtigungsrichtlinien, mit dem Unterschied, dass sie **keine Berechtigungen gewähren**. Stattdessen spezifizieren SCPs die **maximalen Berechtigungen** für eine Organisation, eine organisatorische Einheit (OU) oder ein Konto. Wenn Sie eine SCP an die Root-Organisation oder eine OU anhängen, **beschränkt die SCP die Berechtigungen für Entitäten in Mitgliedskonten**. Dies ist der EINZIGE Weg, wie **sogar der Root-Benutzer daran gehindert werden kann**, etwas zu tun. Zum Beispiel könnte es verwendet werden, um Benutzer daran zu hindern, CloudTrail zu deaktivieren oder Backups zu löschen.\ Der einzige Weg, dies zu umgehen, besteht darin, auch das **Master-Konto** zu kompromittieren, das die SCPs konfiguriert (das Master-Konto kann nicht blockiert werden). @@ -53,25 +53,25 @@ SCP-Beispiele: - Den Root-Account vollständig verweigern - Nur bestimmte Regionen zulassen - Nur genehmigte Dienste zulassen -- Verweigern, dass GuardDuty, CloudTrail und S3 Public Block Access deaktiviert werden +- Verhindern, dass GuardDuty, CloudTrail und S3 Public Block Access deaktiviert werden -- Verweigern, dass Sicherheits-/Vorfallreaktionsrollen gelöscht oder +- Verhindern, dass Sicherheits-/Vorfallreaktionsrollen gelöscht oder modifiziert werden. -- Verweigern, dass Backups gelöscht werden. -- Verweigern, dass IAM-Benutzer und Zugriffsschlüssel erstellt werden +- Verhindern, dass Backups gelöscht werden. +- Verhindern, dass IAM-Benutzer und Zugriffsschlüssel erstellt werden Finden Sie **JSON-Beispiele** in [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) ### Resource Control Policy (RCP) -Eine **Resource Control Policy (RCP)** ist eine Richtlinie, die die **maximalen Berechtigungen für Ressourcen innerhalb Ihrer AWS-Organisation** definiert. RCPs sind in der Syntax ähnlich wie IAM-Richtlinien, gewähren jedoch **keine Berechtigungen** – sie begrenzen nur die Berechtigungen, die von anderen Richtlinien auf Ressourcen angewendet werden können. Wenn Sie eine RCP an den Root Ihrer Organisation, eine organisatorische Einheit (OU) oder ein Konto anhängen, beschränkt die RCP die Ressourcenberechtigungen für alle Ressourcen im betroffenen Bereich. +Eine **Resource Control Policy (RCP)** ist eine Richtlinie, die die **maximalen Berechtigungen für Ressourcen innerhalb Ihrer AWS-Organisation** definiert. RCPs sind in der Syntax ähnlich wie IAM-Richtlinien, gewähren jedoch **keine Berechtigungen**—sie begrenzen nur die Berechtigungen, die von anderen Richtlinien auf Ressourcen angewendet werden können. Wenn Sie eine RCP an die Root-Organisation, eine organisatorische Einheit (OU) oder ein Konto anhängen, beschränkt die RCP die Ressourcenberechtigungen für alle Ressourcen im betroffenen Bereich. -Dies ist der EINZIGE Weg, um sicherzustellen, dass **Ressourcen die vordefinierten Zugriffslevel nicht überschreiten** – selbst wenn eine identitätsbasierte oder ressourcenbasierte Richtlinie zu großzügig ist. Der einzige Weg, diese Grenzen zu umgehen, besteht darin, auch die RCP zu ändern, die von dem Verwaltungskonto Ihrer Organisation konfiguriert wurde. +Dies ist der EINZIGE Weg, um sicherzustellen, dass **Ressourcen die vordefinierten Zugriffslevel nicht überschreiten**—selbst wenn eine identitätsbasierte oder ressourcenbasierte Richtlinie zu großzügig ist. Der einzige Weg, diese Grenzen zu umgehen, besteht darin, auch die RCP zu ändern, die von dem Verwaltungskonto Ihrer Organisation konfiguriert wurde. > [!WARNING] -> RCPs beschränken nur die Berechtigungen, die Ressourcen haben können. Sie steuern nicht direkt, was Prinzipale tun können. Wenn beispielsweise eine RCP den externen Zugriff auf einen S3-Bucket verweigert, stellt sie sicher, dass die Berechtigungen des Buckets niemals Aktionen über das festgelegte Limit hinaus zulassen – selbst wenn eine ressourcenbasierte Richtlinie falsch konfiguriert ist. +> RCPs beschränken nur die Berechtigungen, die Ressourcen haben können. Sie steuern nicht direkt, was Prinzipale tun können. Wenn beispielsweise eine RCP den externen Zugriff auf einen S3-Bucket verweigert, stellt sie sicher, dass die Berechtigungen des Buckets niemals Aktionen über das festgelegte Limit hinaus zulassen—selbst wenn eine ressourcenbasierte Richtlinie falsch konfiguriert ist. RCP-Beispiele: @@ -120,7 +120,7 @@ Ein IAM _Benutzer_ ist eine Entität, die Sie in AWS erstellen, um **die Person Wenn Sie einen IAM-Benutzer erstellen, gewähren Sie ihm **Berechtigungen**, indem Sie ihn zu einer **Gruppe von Benutzern** machen, die über geeignete Berechtigungspolicen verfügt (empfohlen), oder indem Sie **Richtlinien direkt** an den Benutzer anhängen. -Benutzer können **MFA aktivieren, um sich** über die Konsole anzumelden. API-Token von MFA-aktivierten Benutzern sind nicht durch MFA geschützt. Wenn Sie den **Zugriff der API-Schlüssel eines Benutzers mithilfe von MFA einschränken** möchten, müssen Sie in der Richtlinie angeben, dass für die Durchführung bestimmter Aktionen MFA erforderlich ist (Beispiel [**hier**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). +Benutzer können **MFA aktivieren, um sich** über die Konsole anzumelden. API-Token von MFA-aktivierten Benutzern sind nicht durch MFA geschützt. Wenn Sie den **Zugriff der API-Schlüssel eines Benutzers mit MFA einschränken** möchten, müssen Sie in der Richtlinie angeben, dass für die Durchführung bestimmter Aktionen MFA erforderlich ist (Beispiel [**hier**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). #### CLI @@ -128,12 +128,12 @@ Benutzer können **MFA aktivieren, um sich** über die Konsole anzumelden. API-T - **Secret access key ID**: 40 zufällige Groß- und Kleinbuchstaben: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Es ist nicht möglich, verlorene Secret Access Key IDs wiederherzustellen). Wann immer Sie den **Access Key** **ändern** müssen, sollten Sie diesen Prozess befolgen:\ -_Einen neuen Zugriffsschlüssel erstellen -> Den neuen Schlüssel auf das System/Anwendung anwenden -> Den ursprünglichen als inaktiv markieren -> Testen und überprüfen, ob der neue Zugriffsschlüssel funktioniert -> Alten Zugriffsschlüssel löschen_ +_Einen neuen Zugriffsschlüssel erstellen -> Den neuen Schlüssel im System/Anwendung anwenden -> Den ursprünglichen als inaktiv markieren -> Testen und überprüfen, ob der neue Zugriffsschlüssel funktioniert -> Alten Zugriffsschlüssel löschen_ ### MFA - Multi Factor Authentication Es wird verwendet, um **einen zusätzlichen Faktor für die Authentifizierung** zusätzlich zu Ihren bestehenden Methoden, wie Passwort, zu erstellen und somit ein mehrstufiges Authentifizierungsniveau zu schaffen.\ -Sie können eine **kostenlose virtuelle Anwendung oder ein physisches Gerät** verwenden. Sie können Apps wie Google Authenticator kostenlos verwenden, um ein MFA in AWS zu aktivieren. +Sie können eine **kostenlose virtuelle Anwendung oder ein physisches Gerät** verwenden. Sie können Apps wie Google Authenticator kostenlos verwenden, um MFA in AWS zu aktivieren. Richtlinien mit MFA-Bedingungen können an Folgendes angehängt werden: @@ -157,19 +157,19 @@ Sie können eine **identitätsbasierte Richtlinie an eine Benutzergruppe anhäng Hier sind einige wichtige Merkmale von Benutzergruppen: - Eine Benutzer **gruppe** kann **viele Benutzer enthalten**, und ein **Benutzer** kann **zu mehreren Gruppen gehören**. -- **Benutzergruppen können nicht geschachtelt** werden; sie können nur Benutzer enthalten, keine anderen Benutzergruppen. +- **Benutzergruppen können nicht geschachtelt werden**; sie können nur Benutzer enthalten, keine anderen Benutzergruppen. - Es gibt **keine Standardbenutzergruppe, die automatisch alle Benutzer im AWS-Konto einschließt**. Wenn Sie eine solche Benutzergruppe haben möchten, müssen Sie sie erstellen und jeden neuen Benutzer zuweisen. - Die Anzahl und Größe der IAM-Ressourcen in einem AWS-Konto, wie die Anzahl der Gruppen und die Anzahl der Gruppen, denen ein Benutzer angehören kann, sind begrenzt. Weitere Informationen finden Sie unter [IAM- und AWS STS-Quoten](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). ### [IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -Eine IAM **Rolle** ist sehr **ähnlich** zu einem **Benutzer**, da sie eine **Identität mit Berechtigungspolitiken ist, die bestimmen, was** sie in AWS tun kann und was nicht. Eine Rolle **hat jedoch keine Anmeldeinformationen** (Passwort oder Zugriffsschlüssel), die mit ihr verbunden sind. Anstatt eindeutig mit einer Person verbunden zu sein, ist eine Rolle dazu gedacht, **von jedem, der sie benötigt (und genügend Berechtigungen hat), übernommen zu werden**. Ein **IAM-Benutzer kann eine Rolle übernehmen, um vorübergehend** andere Berechtigungen für eine bestimmte Aufgabe zu erhalten. Eine Rolle kann einem [**federierten Benutzer**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) zugewiesen werden, der sich über einen externen Identitätsanbieter anstelle von IAM anmeldet. +Eine IAM **Rolle** ist sehr **ähnlich** zu einem **Benutzer**, da sie eine **Identität mit Berechtigungspolitiken ist, die bestimmen, was** sie in AWS tun kann und was nicht. Eine Rolle **hat jedoch keine Anmeldeinformationen** (Passwort oder Zugriffsschlüssel), die mit ihr verbunden sind. Anstatt eindeutig mit einer Person verbunden zu sein, ist eine Rolle dazu gedacht, **von jedem, der sie benötigt (und genügend Berechtigungen hat), übernommen zu werden**. Ein **IAM-Benutzer kann eine Rolle übernehmen, um vorübergehend** andere Berechtigungen für eine bestimmte Aufgabe zu erhalten. Eine Rolle kann einem **[federierten Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)** zugewiesen werden, der sich über einen externen Identitätsanbieter anstelle von IAM anmeldet. Eine IAM-Rolle besteht aus **zwei Arten von Richtlinien**: einer **Vertrauensrichtlinie**, die nicht leer sein kann und definiert, **wer die Rolle übernehmen kann**, und einer **Berechtigungsrichtlinie**, die nicht leer sein kann und definiert, **auf was sie zugreifen kann**. #### AWS Security Token Service (STS) -AWS Security Token Service (STS) ist ein Webdienst, der die **Ausstellung von temporären, eingeschränkten Anmeldeinformationen** erleichtert. Er ist speziell auf folgende Aspekte zugeschnitten: +AWS Security Token Service (STS) ist ein Webdienst, der die **Ausstellung von temporären, eingeschränkten Anmeldeinformationen** erleichtert. Er ist speziell auf folgende Zwecke zugeschnitten: ### [Temporäre Anmeldeinformationen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) @@ -185,7 +185,7 @@ Werden verwendet, um Berechtigungen zuzuweisen. Es gibt 2 Arten: - Kundenverwaltete Richtlinien: Von Ihnen konfiguriert. Sie können Richtlinien basierend auf AWS verwalteten Richtlinien erstellen (eine davon ändern und Ihre eigene erstellen), den Richtlinien-Generator verwenden (eine GUI-Ansicht, die Ihnen hilft, Berechtigungen zu gewähren und zu verweigern) oder Ihre eigenen schreiben. Standardmäßig ist der Zugriff **verweigert**, der Zugriff wird gewährt, wenn eine explizite Rolle angegeben wurde.\ -Wenn **einzelne "Deny" existiert, wird es das "Allow" überschreiben**, mit Ausnahme von Anfragen, die die Root-Sicherheitsanmeldeinformationen des AWS-Kontos verwenden (die standardmäßig erlaubt sind). +Wenn **einzelne "Verweigern" existiert, wird es das "Erlauben" überschreiben**, mit Ausnahme von Anfragen, die die Root-Sicherheitsanmeldeinformationen des AWS-Kontos verwenden (die standardmäßig erlaubt sind). ```javascript { "Version": "2012-10-17", //Version of the policy @@ -214,7 +214,7 @@ Die [spezifischen Felder, die für Bedingungen pro Dienst verwendet werden könn #### Inline-Richtlinien Diese Art von Richtlinien wird **direkt einem Benutzer, einer Gruppe oder einer Rolle zugewiesen**. Daher erscheinen sie nicht in der Richtlinienliste, da sie von niemand anderem verwendet werden können.\ -Inline-Richtlinien sind nützlich, wenn Sie eine **strikte Eins-zu-eins-Beziehung zwischen einer Richtlinie und der Identität, auf die sie angewendet wird, aufrechterhalten** möchten. Zum Beispiel möchten Sie sicherstellen, dass die Berechtigungen in einer Richtlinie nicht versehentlich einer anderen Identität zugewiesen werden, als der, für die sie bestimmt sind. Wenn Sie eine Inline-Richtlinie verwenden, können die Berechtigungen in der Richtlinie nicht versehentlich der falschen Identität zugeordnet werden. Darüber hinaus werden die in der Identität eingebetteten Richtlinien gelöscht, wenn Sie diese Identität über die AWS Management Console löschen. Das liegt daran, dass sie Teil der Hauptentität sind. +Inline-Richtlinien sind nützlich, wenn Sie eine **strikte Eins-zu-eins-Beziehung zwischen einer Richtlinie und der Identität** aufrechterhalten möchten, auf die sie angewendet wird. Zum Beispiel möchten Sie sicherstellen, dass die Berechtigungen in einer Richtlinie nicht versehentlich einer anderen Identität zugewiesen werden, als der, für die sie bestimmt sind. Wenn Sie eine Inline-Richtlinie verwenden, können die Berechtigungen in der Richtlinie nicht versehentlich der falschen Identität zugeordnet werden. Darüber hinaus werden die in der Identität eingebetteten Richtlinien gelöscht, wenn Sie die AWS Management Console verwenden, um diese Identität zu löschen. Das liegt daran, dass sie Teil der Hauptentität sind. #### Ressourcen-Bucket-Richtlinien @@ -224,7 +224,7 @@ Wenn eine Hauptentität keine ausdrückliche Ablehnung auf ihnen hat und eine Re ### IAM-Grenzen -IAM-Grenzen können verwendet werden, um **die Berechtigungen, auf die ein Benutzer oder eine Rolle Zugriff haben sollte, einzuschränken**. Auf diese Weise schlägt die Operation **fehl**, wenn ein Benutzer versucht, sie zu verwenden, selbst wenn ihm von einer **anderen Richtlinie** ein anderes Berechtigungsset gewährt wird. +IAM-Grenzen können verwendet werden, um **die Berechtigungen, auf die ein Benutzer oder eine Rolle Zugriff haben sollte, zu beschränken**. Auf diese Weise schlägt die Operation **fehl**, wenn dem Benutzer von einer **anderen Richtlinie** ein anderes Berechtigungsset gewährt wird und er versucht, diese zu verwenden. Eine Grenze ist einfach eine Richtlinie, die einem Benutzer angehängt ist und **das maximale Niveau der Berechtigungen angibt, die der Benutzer oder die Rolle haben kann**. Selbst wenn der Benutzer Administratorzugriff hat, wenn die Grenze angibt, dass er nur S· Buckets lesen kann, ist das das Maximum, was er tun kann. @@ -242,9 +242,9 @@ aws sts assume-role \ [--policy-arns ] [--policy ] ``` -Hinweis: Standardmäßig **kann AWS Sitzungspolicies zu Sitzungen hinzufügen**, die aus anderen Gründen generiert werden. Zum Beispiel werden in [unauthentifizierten Cognito-angenommenen Rollen](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) standardmäßig (unter Verwendung verbesserter Authentifizierung) **Sitzungsanmeldeinformationen mit einer Sitzungspolicy** generiert, die die Dienste einschränkt, auf die die Sitzung zugreifen kann [**auf die folgende Liste**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). +Hinweis: Standardmäßig **kann AWS Sitzungspolicies zu Sitzungen hinzufügen**, die aus anderen Gründen generiert werden. Zum Beispiel in [unauthentifizierten Cognito-angenommenen Rollen](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) wird AWS standardmäßig (unter Verwendung verbesserter Authentifizierung) **Sitzungsanmeldeinformationen mit einer Sitzungspolicy** generieren, die die Dienste einschränkt, auf die die Sitzung zugreifen kann [**auf die folgende Liste**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). -Wenn Sie also irgendwann den Fehler "... weil keine Sitzungspolicy dies erlaubt ..." erhalten und die Rolle Zugriff auf die Aktion hat, liegt es daran, dass **eine Sitzungspolicy dies verhindert**. +Daher, wenn Sie irgendwann den Fehler "... weil keine Sitzungspolicy das ... erlaubt", und die Rolle Zugriff hat, um die Aktion auszuführen, liegt es daran, dass **eine Sitzungspolicy dies verhindert**. ### Identitätsföderation @@ -253,35 +253,37 @@ Ein Beispiel für einen Identitätsanbieter kann Ihr eigenes Unternehmens-**Micr Um dieses Vertrauen zu konfigurieren, wird ein **IAM-Identitätsanbieter (SAML oder OAuth)** generiert, der die **andere Plattform** **vertraut**. Dann wird mindestens eine **IAM-Rolle (vertrauend) dem Identitätsanbieter zugewiesen**. Wenn ein Benutzer von der vertrauenswürdigen Plattform auf AWS zugreift, greift er als die genannte Rolle zu. +Allerdings möchten Sie normalerweise **eine andere Rolle je nach Gruppe des Benutzers** auf der Drittanbieterplattform vergeben. Dann können mehrere **IAM-Rollen der Drittanbieter-Identitätsanbieter vertrauen**, und die Drittanbieterplattform wird diejenige sein, die es Benutzern ermöglicht, eine Rolle oder die andere zu übernehmen. +
### IAM Identity Center AWS IAM Identity Center (Nachfolger von AWS Single Sign-On) erweitert die Möglichkeiten von AWS Identity and Access Management (IAM), um einen **zentralen Ort** bereitzustellen, der die **Verwaltung von Benutzern und deren Zugriff auf AWS**-Konten und Cloud-Anwendungen zusammenführt. -Die Anmeldedomäne wird etwas wie `.awsapps.com` sein. +Die Anmeldedomäne wird etwas sein wie `.awsapps.com`. Um Benutzer anzumelden, können 3 Identitätsquellen verwendet werden: -- Identity Center-Verzeichnis: Reguläre AWS-Benutzer +- Identity Center Directory: Reguläre AWS-Benutzer - Active Directory: Unterstützt verschiedene Connectoren - Externer Identitätsanbieter: Alle Benutzer und Gruppen stammen von einem externen Identitätsanbieter (IdP)
-Im einfachsten Fall des Identity Center-Verzeichnisses wird das **Identity Center eine Liste von Benutzern & Gruppen** haben und in der Lage sein, **Richtlinien** für sie zu **irgendeinem der Konten** der Organisation zuzuweisen. +Im einfachsten Fall des Identity Center-Verzeichnisses wird das **Identity Center eine Liste von Benutzern & Gruppen haben** und in der Lage sein, **Richtlinien** für sie zu **irgendeinem der Konten** der Organisation zuzuweisen. Um einem Benutzer/einer Gruppe im Identity Center Zugriff auf ein Konto zu gewähren, wird ein **SAML-Identitätsanbieter, der dem Identity Center vertraut, erstellt**, und eine **Rolle, die dem Identitätsanbieter mit den angegebenen Richtlinien vertraut, wird im Zielkonto erstellt**. #### AwsSSOInlinePolicy -Es ist möglich, **Berechtigungen über Inline-Richtlinien für Rollen zu gewähren, die über IAM Identity Center erstellt wurden**. Die in den Konten erstellten Rollen, die **Inline-Richtlinien im AWS Identity Center** erhalten, haben diese Berechtigungen in einer Inline-Richtlinie namens **`AwsSSOInlinePolicy`**. +Es ist möglich, **Berechtigungen über Inline-Richtlinien für Rollen zu vergeben, die über IAM Identity Center erstellt wurden**. Die in den Konten erstellten Rollen, die **Inline-Richtlinien im AWS Identity Center** haben, werden diese Berechtigungen in einer Inline-Richtlinie namens **`AwsSSOInlinePolicy`** haben. Daher bedeutet es nicht, dass, selbst wenn Sie 2 Rollen mit einer Inline-Richtlinie namens **`AwsSSOInlinePolicy`** sehen, dass sie **die gleichen Berechtigungen haben**. ### Cross Account Trusts und Rollen -**Ein Benutzer** (vertrauend) kann eine Cross-Account-Rolle mit einigen Richtlinien erstellen und dann **einem anderen Benutzer** (vertrauenswürdig) **Zugriff auf sein Konto gewähren**, jedoch nur **mit dem Zugriff, der in den neuen Rollrichtlinien angegeben ist**. Um dies zu erstellen, erstellen Sie einfach eine neue Rolle und wählen Sie Cross-Account-Rolle aus. Rollen für den Cross-Account-Zugriff bieten zwei Optionen. Bereitstellung des Zugriffs zwischen AWS-Konten, die Sie besitzen, und Bereitstellung des Zugriffs zwischen einem Konto, das Sie besitzen, und einem Drittanbieter-AWS-Konto.\ +**Ein Benutzer** (vertrauend) kann eine Cross-Account-Rolle mit einigen Richtlinien erstellen und dann **einem anderen Benutzer** (vertrauenswürdig) **den Zugriff auf sein Konto erlauben**, jedoch nur **mit dem Zugriff, der in den neuen Rollrichtlinien angegeben ist**. Um dies zu erstellen, erstellen Sie einfach eine neue Rolle und wählen Sie Cross-Account-Rolle aus. Rollen für den Cross-Account-Zugriff bieten zwei Optionen. Bereitstellung des Zugriffs zwischen AWS-Konten, die Sie besitzen, und Bereitstellung des Zugriffs zwischen einem Konto, das Sie besitzen, und einem Drittanbieter-AWS-Konto.\ Es wird empfohlen, **den Benutzer, der vertraut ist, anzugeben und nichts Allgemeines zu verwenden**, da sonst andere authentifizierte Benutzer wie föderierte Benutzer dieses Vertrauen ebenfalls missbrauchen können. ### AWS Simple AD @@ -305,26 +307,26 @@ Die App verwendet die AssumeRoleWithWebIdentity, um temporäre Anmeldeinformatio - Sie können **eine Passwortrichtlinieneinstellung** wie Mindestlänge und Passwortanforderungen festlegen. - Sie können **einen "Credential Report" herunterladen**, der Informationen über aktuelle Anmeldeinformationen (wie Erstellungszeit des Benutzers, ob das Passwort aktiviert ist...) enthält. Sie können einen Anmeldebericht so oft wie einmal alle **vier Stunden** generieren. -AWS Identity and Access Management (IAM) bietet **feingranulare Zugriffskontrolle** über alle AWS-Dienste. Mit IAM können Sie festlegen, **wer auf welche Dienste und Ressourcen zugreifen kann** und unter welchen Bedingungen. Mit IAM-Richtlinien verwalten Sie Berechtigungen für Ihre Mitarbeiter und Systeme, um **die Berechtigungen mit minimalen Rechten** sicherzustellen. +AWS Identity and Access Management (IAM) bietet **feingranulare Zugriffskontrolle** über alle AWS-Dienste. Mit IAM können Sie festlegen, **wer auf welche Dienste und Ressourcen zugreifen kann** und unter welchen Bedingungen. Mit IAM-Richtlinien verwalten Sie Berechtigungen für Ihre Mitarbeiter und Systeme, um **die minimalen Berechtigungen** sicherzustellen. ### IAM-ID-Präfixe Auf [**dieser Seite**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) finden Sie die **IAM-ID-Präfixe** von Schlüsseln, abhängig von ihrer Natur: -| Identifikationscode | Beschreibung | -| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| ABIA | [AWS STS-Dienstträger-Token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | +| Identifier Code | Beschreibung | +| --------------- | ----------------------------------------------------------------------------------------------------------- | +| ABIA | [AWS STS-Dienstträger-Token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | -| ACCA | Kontextbezogene Anmeldeinformationen | -| AGPA | Benutzergruppe | -| AIDA | IAM-Benutzer | -| AIPA | Amazon EC2-Instanzprofil | -| AKIA | Zugriffsschlüssel | -| ANPA | Verwaltete Richtlinie | -| ANVA | Version in einer verwalteten Richtlinie | -| APKA | Öffentliches Schlüssel | -| AROA | Rolle | -| ASCA | Zertifikat | +| ACCA | Kontextabhängige Anmeldeinformationen | +| AGPA | Benutzergruppe | +| AIDA | IAM-Benutzer | +| AIPA | Amazon EC2-Instanzprofil | +| AKIA | Zugriffsschlüssel | +| ANPA | Verwaltete Richtlinie | +| ANVA | Version in einer verwalteten Richtlinie | +| APKA | Öffentliches Schlüssel | +| AROA | Rolle | +| ASCA | Zertifikat | | ASIA | [Temporäre (AWS STS) Zugriffsschlüssel-IDs](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) verwenden dieses Präfix, sind jedoch nur in Kombination mit dem geheimen Zugriffsschlüssel und dem Sitzungstoken eindeutig. | ### Empfohlene Berechtigungen zur Überprüfung von Konten @@ -345,7 +347,7 @@ Die folgenden Berechtigungen gewähren verschiedenen Lesezugriff auf Metadaten: ### CLI-Authentifizierung Damit ein regulärer Benutzer sich über die CLI bei AWS authentifizieren kann, müssen **lokale Anmeldeinformationen** vorhanden sein. Standardmäßig können Sie diese **manuell** in `~/.aws/credentials` konfigurieren oder **ausführen** `aws configure`.\ -In dieser Datei können Sie mehr als ein Profil haben. Wenn **kein Profil** angegeben ist, wird das in dieser Datei als **`[default]`** bezeichnete verwendet.\ +In dieser Datei können Sie mehr als ein Profil haben. Wenn **kein Profil** angegeben ist, wird das in dieser Datei genannte **`[default]`** verwendet.\ Beispiel einer Anmeldeinformationsdatei mit mehr als 1 Profil: ``` [default] @@ -357,7 +359,7 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7 region = eu-west-2 ``` -Wenn Sie auf **verschiedene AWS-Konten** zugreifen müssen und Ihr Profil Zugriff auf **eine Rolle in diesen Konten** erhalten hat, müssen Sie nicht jedes Mal manuell STS aufrufen (`aws sts assume-role --role-arn --role-session-name sessname`) und die Anmeldeinformationen konfigurieren. +Wenn Sie auf **verschiedene AWS-Konten** zugreifen müssen und Ihr Profil Zugriff auf **eine Rolle in diesen Konten** hat, müssen Sie nicht jedes Mal manuell STS aufrufen (`aws sts assume-role --role-arn --role-session-name sessname`) und die Anmeldeinformationen konfigurieren. Sie können die Datei `~/.aws/config` verwenden, um [**anzugeben, welche Rollen übernommen werden sollen**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), und dann den Parameter `--profile` wie gewohnt verwenden (die `assume-role` wird für den Benutzer transparent durchgeführt).\ Ein Beispiel für eine Konfigurationsdatei: