Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

This commit is contained in:
Translator
2025-03-17 03:51:43 +00:00
parent 5e8a0613a2
commit 6225ab50f3
3 changed files with 95 additions and 69 deletions

View File

@@ -14,26 +14,26 @@ Dies ist aus **Sicherheits**sicht sehr interessant, da **ein Konto nicht auf Res
Daher gibt es **zwei Arten von Konten in einer Organisation** (wir sprechen von AWS-Konten und nicht von Benutzerkonten): ein einzelnes Konto, das als Verwaltungskonto bezeichnet wird, und ein oder mehrere Mitgliedskonten.
- Das **Verwaltungskonto (das Root-Konto)** ist das Konto, das Sie verwenden, um die Organisation zu erstellen. Vom Verwaltungskonto der Organisation aus können Sie Folgendes tun:
- Das **Verwaltungskonto (das Root-Konto)** ist das Konto, das Sie zur Erstellung der Organisation verwenden. Vom Verwaltungskonto der Organisation aus können Sie Folgendes tun:
- Konten in der Organisation erstellen
- Andere bestehende Konten zur Organisation einladen
- 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 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 zum Erstellen dieses Root-Kontos/Organisation verwendet wurden.
- Die Integration mit unterstützten AWS-Diensten aktivieren, um die Dienstfunktionalitä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.
- **Mitgliedskonten** bilden alle anderen Konten in einer Organisation. Ein Konto kann nur Mitglied einer Organisation gleichzeitig sein. Sie können eine Richtlinie an ein Konto anhängen, um Kontrollen nur auf dieses eine Konto anzuwenden.
- **Mitgliedskonten** bilden alle anderen Konten in einer Organisation. Ein Konto kann nur Mitglied einer Organisation zur gleichen Zeit sein. Sie können eine Richtlinie an ein Konto anhängen, um Kontrollen nur auf dieses eine Konto anzuwenden.
- Mitgliedskonten **müssen eine gültige E-Mail-Adresse verwenden** und können einen **Namen** haben; im Allgemeinen werden sie nicht in der Lage sein, die Abrechnung zu verwalten (aber sie könnten Zugang dazu erhalten).
```
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
```
### **Organisations-Einheiten**
### **Organisationseinheiten**
Accounts können in **Organisations-Einheiten (OU)** gruppiert werden. Auf diese Weise können Sie **Richtlinien** für die Organisations-Einheit erstellen, die auf **alle untergeordneten Accounts angewendet werden**. Beachten Sie, dass eine OU andere OUs als Kinder haben kann.
Konten können in **Organisationseinheiten (OU)** gruppiert werden. Auf diese Weise können Sie **Richtlinien** für die Organisationseinheit erstellen, die auf **alle untergeordneten Konten angewendet werden**. Beachten Sie, dass eine OU andere OUs als Kinder haben kann.
```bash
# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
@@ -46,29 +46,45 @@ Dies ist der EINZIGE Weg, wie **sogar der Root-Benutzer daran gehindert werden k
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).
> [!WARNING]
> Beachten Sie, dass **SCPs nur die Prinzipale im Konto einschränken**, sodass andere Konten nicht betroffen sind. Das bedeutet, dass eine SCP, die `s3:GetObject` verweigert, nicht verhindert, dass Personen **auf einen öffentlichen S3-Bucket** in Ihrem Konto zugreifen.
> Beachten Sie, dass **SCPs nur die Prinzipale im Konto einschränken**, sodass andere Konten nicht betroffen sind. Das bedeutet, dass das Verweigern von `s3:GetObject` in einer SCP nicht verhindert, dass Personen **auf einen öffentlichen S3-Bucket** in Ihrem Konto zugreifen.
SCP-Beispiele:
- Verweigern Sie das Root-Konto vollständig
- Den Root-Account vollständig verweigern
- Nur bestimmte Regionen zulassen
- Nur genehmigte Dienste zulassen
- Verweigern Sie GuardDuty, CloudTrail und S3 Public Block Access von
- Verweigern, dass GuardDuty, CloudTrail und S3 Public Block Access deaktiviert werden
deaktiviert werden
- Verweigern Sie, dass Sicherheits-/Vorfallreaktionsrollen gelöscht oder
- Verweigern, dass Sicherheits-/Vorfallreaktionsrollen gelöscht oder
modifiziert werden.
- Verweigern Sie, dass Backups gelöscht werden.
- Verweigern Sie das Erstellen von IAM-Benutzern und Zugriffsschlüsseln
- Verweigern, dass Backups gelöscht werden.
- Verweigern, 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.
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.
RCP-Beispiele:
- S3-Buckets so einschränken, dass sie nur von Prinzipalen innerhalb Ihrer Organisation zugegriffen werden können
- KMS-Schlüsselverwendung auf nur vertrauenswürdige organisatorische Konten beschränken
- Berechtigungen auf SQS-Warteschlangen begrenzen, um unbefugte Änderungen zu verhindern
- Zugriffsgrenzen auf Secrets Manager-Geheimnisse durchsetzen, um sensible Daten zu schützen
Finden Sie Beispiele in [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)
### ARN
**Amazon Resource Name** ist der **eindeutige Name**, den jede Ressource innerhalb von AWS hat, er setzt sich wie folgt zusammen:
**Amazon Resource Name** ist der **einzigartige Name**, den jede Ressource innerhalb von AWS hat, er setzt sich wie folgt zusammen:
```
arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
@@ -92,32 +108,32 @@ IAM kann durch seine Fähigkeit definiert werden, Authentifizierungs-, Autorisie
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
Wenn Sie zum ersten Mal ein Amazon Web Services (AWS) Konto erstellen, beginnen Sie mit einer einzigen Anmeldeidentität, die **vollständigen Zugriff auf alle** AWS-Dienste und -Ressourcen im Konto hat. Dies ist der _**Root-Benutzer**_ des AWS-Kontos und wird durch die Anmeldung mit der **E-Mail-Adresse und dem Passwort, die Sie zur Erstellung des Kontos verwendet haben**, aufgerufen.
Wenn Sie zum ersten Mal ein Amazon Web Services (AWS) Konto erstellen, beginnen Sie mit einer einzelnen Anmeldeidentität, die **vollständigen Zugriff auf alle** AWS-Dienste und -Ressourcen im Konto hat. Dies ist der _**Root-Benutzer**_ des AWS-Kontos und wird durch die Anmeldung mit der **E-Mail-Adresse und dem Passwort, die Sie zur Erstellung des Kontos verwendet haben**, aufgerufen.
Beachten Sie, dass ein neuer **Admin-Benutzer** **weniger Berechtigungen als der Root-Benutzer** hat.
Aus sicherheitstechnischer Sicht wird empfohlen, andere Benutzer zu erstellen und diesen nicht zu verwenden.
Aus sicherheitstechnischer Sicht wird empfohlen, andere Benutzer zu erstellen und diesen zu vermeiden.
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
Ein IAM _Benutzer_ ist eine Entität, die Sie in AWS erstellen, um **die Person oder Anwendung** zu **repräsentieren, die damit interagiert**. Ein Benutzer in AWS besteht aus einem Namen und Anmeldeinformationen (Passwort und bis zu zwei Zugriffsschlüssel).
Wenn Sie einen IAM-Benutzer erstellen, gewähren Sie ihm **Berechtigungen**, indem Sie ihn zu einer **Benutzergruppe** machen, die geeignete Berechtigungspolicen angehängt hat (empfohlen), oder indem Sie **Richtlinien direkt** an den Benutzer anhängen.
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 mit MFA einschränken** möchten, müssen Sie in der Richtlinie angeben, dass für die Ausführung bestimmter Aktionen MFA vorhanden sein muss (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 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)).
#### CLI
- **Access Key ID**: 20 zufällige Großbuchstaben-Ziffern-Kombinationen wie AKHDNAPO86BSHKDIRYT
- **Access Key ID**: 20 zufällige Großbuchstaben-Zahlenkombinationen wie AKHDNAPO86BSHKDIRYT
- **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, dass der neue Zugriffsschlüssel funktioniert -> Alten Zugriffsschlüssel löschen_
_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_
### 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 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 ein MFA in AWS zu aktivieren.
Richtlinien mit MFA-Bedingungen können an Folgendes angehängt werden:
@@ -130,34 +146,34 @@ Beachten Sie, dass **`AssumeRole`-Anmeldeinformationen diese Informationen nicht
```bash
aws sts get-session-token --serial-number <arn_device> --token-code <code>
```
Wie [**hier angegeben**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), gibt es viele verschiedene Fälle, in denen **MFA nicht verwendet werden kann**.
As [**hier angegeben**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), gibt es viele verschiedene Fälle, in denen **MFA nicht verwendet werden kann**.
### [IAM-Benutzergruppen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
Eine IAM [Benutzergruppe](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) ist eine Möglichkeit, **Richtlinien mehreren Benutzern** gleichzeitig zuzuordnen, was die Verwaltung der Berechtigungen für diese Benutzer erleichtern kann. **Rollen und Gruppen können kein Teil einer Gruppe sein**.
Eine IAM [Benutzergruppe](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) ist eine Möglichkeit, **Richtlinien gleichzeitig mehreren Benutzern zuzuordnen**, was die Verwaltung der Berechtigungen für diese Benutzer erleichtern kann. **Rollen und Gruppen können kein Teil einer Gruppe sein**.
Sie können eine **identitätsbasierte Richtlinie an eine Benutzergruppe** anhängen, sodass alle **Benutzer** in der Benutzergruppe **die Berechtigungen der Richtlinie erhalten**. Sie **können** eine **Benutzergruppe** nicht als **`Principal`** in einer **Richtlinie** (wie einer ressourcenbasierten Richtlinie) identifizieren, da Gruppen sich auf Berechtigungen beziehen, nicht auf Authentifizierung, und Principals authentifizierte IAM-Entitäten sind.
Sie können eine **identitätsbasierte Richtlinie an eine Benutzergruppe anhängen**, sodass alle **Benutzer** in der Benutzergruppe **die Berechtigungen der Richtlinie erhalten**. Sie **können** eine **Benutzergruppe** nicht als **`Principal`** in einer **Richtlinie** (wie einer ressourcenbasierten Richtlinie) identifizieren, da Gruppen sich auf Berechtigungen beziehen, nicht auf Authentifizierung, und Principals authentifizierte IAM-Entitäten sind.
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, nicht andere Benutzergruppen enthalten.
- Es gibt **keine Standardbenutzergruppe, die automatisch alle Benutzer im AWS-Konto** umfasst. Wenn Sie eine solche Benutzergruppe haben möchten, müssen Sie sie erstellen und jeden neuen Benutzer ihr 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).
- 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.
- 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) <a href="#id_iam-roles" id="id_iam-roles"></a>
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 Berechtigungsnachweisen** 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 Aspekte zugeschnitten:
### [Temporäre Berechtigungsnachweise in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
### [Temporäre Anmeldeinformationen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
**Temporäre Berechtigungsnachweise werden hauptsächlich mit IAM-Rollen verwendet**, es gibt jedoch auch andere Verwendungen. Sie können temporäre Berechtigungsnachweise anfordern, die über einen eingeschränkten Satz von Berechtigungen verfügen als Ihr standardmäßiger IAM-Benutzer. Dies **verhindert**, dass Sie **versehentlich Aufgaben ausführen, die nicht erlaubt sind** durch die eingeschränkten Berechtigungsnachweise. Ein Vorteil temporärer Berechtigungsnachweise ist, dass sie automatisch nach einer festgelegten Zeitspanne ablaufen. Sie haben die Kontrolle über die Dauer, für die die Berechtigungsnachweise gültig sind.
**Temporäre Anmeldeinformationen werden hauptsächlich mit IAM-Rollen verwendet**, es gibt jedoch auch andere Verwendungen. Sie können temporäre Anmeldeinformationen anfordern, die einen eingeschränkteren Satz von Berechtigungen haben als Ihr standardmäßiger IAM-Benutzer. Dies **verhindert**, dass Sie **versehentlich Aufgaben ausführen, die mit den eingeschränkten Anmeldeinformationen nicht erlaubt sind**. Ein Vorteil temporärer Anmeldeinformationen ist, dass sie automatisch nach einer festgelegten Zeitspanne ablaufen. Sie haben die Kontrolle über die Dauer, für die die Anmeldeinformationen gültig sind.
### Richtlinien
@@ -166,7 +182,7 @@ AWS Security Token Service (STS) ist ein Webdienst, der die **Ausstellung von te
Werden verwendet, um Berechtigungen zuzuweisen. Es gibt 2 Arten:
- AWS verwaltete Richtlinien (vorkonfiguriert von AWS)
- Kundenverwaltete Richtlinien: Von Ihnen konfiguriert. Sie können Richtlinien basierend auf AWS verwalteten Richtlinien erstellen (eine von ihnen ändern und Ihre eigene erstellen), den Richtliniengenerator verwenden (eine GUI-Ansicht, die Ihnen hilft, Berechtigungen zu gewähren und zu verweigern) oder Ihre eigenen schreiben.
- 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).
@@ -198,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** 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.
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.
#### Ressourcen-Bucket-Richtlinien
@@ -208,9 +224,9 @@ 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 wird die Operation **fehlschlagen**, selbst wenn ein anderes Set von Berechtigungen dem Benutzer durch eine **andere Richtlinie** gewährt wird, wenn er versucht, sie zu verwenden.
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.
Eine Grenze ist einfach eine Richtlinie, die einem Benutzer angehängt ist und **das maximale Niveau der Berechtigungen angibt, das 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.
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.
**Dies**, **SCPs** und **die Einhaltung des Prinzips der minimalen Berechtigung** sind die Möglichkeiten, um zu kontrollieren, dass Benutzer nicht mehr Berechtigungen haben, als sie benötigen.
@@ -226,36 +242,34 @@ aws sts assume-role \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]
```
Beachten Sie, dass **AWS standardmäßig Sitzungsrichtlinien zu Sitzungen hinzufügen kann**, die aus anderen Gründen generiert werden. Zum Beispiel wird in [unauthentifizierten Cognito-angenommenen Rollen](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) standardmäßig (unter Verwendung verbesserter Authentifizierung) von AWS **Sitzungsanmeldeinformationen mit einer Sitzungsrichtlinie** 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 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).
Wenn Sie also irgendwann den Fehler "... weil keine Sitzungsrichtlinie den ... erlaubt" erhalten und die Rolle Zugriff auf die Aktion hat, liegt es daran, dass **eine Sitzungsrichtlinie dies verhindert**.
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**.
### Identitätsföderation
Die Identitätsföderation **ermöglicht Benutzern von Identitätsanbietern, die extern** zu AWS sind, sicher auf AWS-Ressourcen zuzugreifen, ohne AWS-Benutzeranmeldeinformationen eines gültigen IAM-Benutzerkontos angeben zu müssen.\
Die Identitätsföderation **ermöglicht Benutzern von Identitätsanbietern, die extern** zu AWS sind, den sicheren Zugriff auf AWS-Ressourcen, ohne AWS-Benutzerdaten von einem gültigen IAM-Benutzerkonto angeben zu müssen.\
Ein Beispiel für einen Identitätsanbieter kann Ihr eigenes Unternehmens-**Microsoft Active Directory** (über **SAML**) oder **OpenID**-Dienste (wie **Google**) sein. Der föderierte Zugriff ermöglicht es dann den Benutzern innerhalb davon, auf AWS zuzugreifen.
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 dem Drittanbieter-Identitätsanbieter vertrauen**, und die Drittanbieterplattform wird diejenige sein, die es den Benutzern ermöglicht, eine Rolle oder die andere zu übernehmen.
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
### 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 sein wie `<user_input>.awsapps.com`.
Die Anmeldedomäne wird etwas wie `<user_input>.awsapps.com` sein.
Um Benutzer anzumelden, gibt es 3 Identitätsquellen, die verwendet werden können:
Um Benutzer anzumelden, können 3 Identitätsquellen verwendet werden:
- Identity Center Directory: Reguläre AWS-Benutzer
- Identity Center-Verzeichnis: Reguläre AWS-Benutzer
- Active Directory: Unterstützt verschiedene Connectoren
- Externer Identitätsanbieter: Alle Benutzer und Gruppen stammen von einem externen Identitätsanbieter (IdP)
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
Im einfachsten Fall des Identity Center-Verzeichnisses wird das **Identity Center eine Liste von Benutzern und 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**.
@@ -267,7 +281,7 @@ Daher bedeutet es nicht, dass, selbst wenn Sie 2 Rollen mit einer Inline-Richtli
### Cross Account Trusts und Rollen
**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.\
**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.\
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
@@ -288,16 +302,16 @@ Die App verwendet die AssumeRoleWithWebIdentity, um temporäre Anmeldeinformatio
### Weitere IAM-Optionen
- Sie können **eine Passwortrichtlinieneinstellung** mit Optionen wie Mindestlänge und Passwortanforderungen festlegen.
- Sie können **einen "Credential Report" herunterladen**, der Informationen über aktuelle Anmeldeinformationen enthält (wie Benutzererstellungszeit, ob das Passwort aktiviert ist...). Sie können einen Berechtigungsbericht so oft wie einmal alle **vier Stunden** generieren.
- 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 von AWS. 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 dem geringsten Privileg** 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 Berechtigungen mit minimalen Rechten** 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:
| Identifier Code | Beschreibung |
| Identifikationscode | Beschreibung |
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ABIA | [AWS STS-Dienstträger-Token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
@@ -343,9 +357,9 @@ 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 **das Übernehmen einer Rolle in diesen Konten** erhalten hat, müssen Sie nicht jedes Mal manuell STS aufrufen (`aws sts assume-role --role-arn <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** erhalten hat, müssen Sie nicht jedes Mal manuell STS aufrufen (`aws sts assume-role --role-arn <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 (das `assume-role` wird für den Benutzer transparent durchgeführt).\
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:
```
[profile acc2]
@@ -355,7 +369,7 @@ role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional
```
Mit dieser Konfigurationsdatei können Sie aws cli wie folgt verwenden:
Mit dieser Konfigurationsdatei können Sie dann aws cli verwenden wie:
```
aws --profile acc2 ...
```
@@ -366,5 +380,6 @@ Wenn Sie nach etwas **ähnlichem** suchen, aber für den **Browser**, können Si
- [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
- [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/)
- [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
- [https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/](https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/)
{{#include ../../../banners/hacktricks-training.md}}