mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 06:30:35 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
Translator
@@ -20,7 +20,7 @@ Daher gibt es **zwei Arten von Konten in einer Organisation** (wir sprechen von
|
||||
- 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
|
||||
- Richtlinien auf Entitäten (Wurzeln, 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.
|
||||
|
||||
@@ -31,16 +31,16 @@ Das Verwaltungskonto hat die **Verantwortlichkeiten eines Zahlungskontos** und i
|
||||
```
|
||||
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
|
||||
```
|
||||
### **Organisations-Einheiten**
|
||||
### **Organisationseinheiten**
|
||||
|
||||
Konten 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 Konten angewendet werden**. Beachten Sie, dass eine OU andere OUs als Kinder haben kann.
|
||||
Accounts 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
|
||||
```
|
||||
### 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 Stamm 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 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**.
|
||||
|
||||
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).
|
||||
@@ -50,17 +50,19 @@ Der einzige Weg, dies zu umgehen, besteht darin, auch das **Master-Konto** zu ko
|
||||
|
||||
SCP-Beispiele:
|
||||
|
||||
- Den Root-Account vollständig verweigern
|
||||
- Verweigern Sie das Root-Konto vollständig
|
||||
- Nur bestimmte Regionen zulassen
|
||||
- Nur genehmigte Dienste zulassen
|
||||
- Verweigern, dass GuardDuty, CloudTrail und S3 Public Block Access deaktiviert werden
|
||||
- Verweigern Sie GuardDuty, CloudTrail und S3 Public Block Access von
|
||||
|
||||
- Verweigern, dass Sicherheits-/Vorfallreaktionsrollen gelöscht oder
|
||||
deaktiviert werden
|
||||
|
||||
- Verweigern Sie, dass Sicherheits-/Vorfallreaktionsrollen gelöscht oder
|
||||
|
||||
modifiziert werden.
|
||||
|
||||
- Verweigern, dass Backups gelöscht werden.
|
||||
- Verweigern, IAM-Benutzer und Zugriffsschlüssel zu erstellen
|
||||
- Verweigern Sie, dass Backups gelöscht werden.
|
||||
- Verweigern Sie das Erstellen von IAM-Benutzern und Zugriffsschlüsseln
|
||||
|
||||
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)
|
||||
|
||||
@@ -90,7 +92,7 @@ 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 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.
|
||||
Wenn Sie zum ersten Mal ein Amazon Web Services (AWS) Konto erstellen, beginnen Sie mit einer einzigen Anmeldedaten, die **vollständigen Zugriff auf alle** AWS-Dienste und -Ressourcen im Konto hat. Dies ist der AWS-Konto _**Root-Benutzer**_ 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.
|
||||
|
||||
@@ -100,17 +102,17 @@ Aus sicherheitstechnischer Sicht wird empfohlen, andere Benutzer zu erstellen un
|
||||
|
||||
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 **Mitgliedschaft in 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 **Benutzergruppe** machen, die geeignete Berechtigungspolicen angehängt hat (empfohlen), oder indem Sie **direkt Richtlinien** 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 auf die API-Schlüssel eines Benutzers mithilfe von 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 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)).
|
||||
|
||||
#### CLI
|
||||
|
||||
- **Access Key ID**: 20 zufällige Großbuchstaben-Zahlenkombinationen wie AKHDNAPO86BSHKDIRYT
|
||||
- **Access Key ID**: 20 zufällige Großbuchstaben-Ziffern-Kombinationen 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:\
|
||||
&#xNAN;_Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key_
|
||||
_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_
|
||||
|
||||
### MFA - Multi Factor Authentication
|
||||
|
||||
@@ -141,7 +143,7 @@ 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).
|
||||
- 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>
|
||||
|
||||
@@ -151,11 +153,11 @@ Eine IAM-Rolle besteht aus **zwei Arten von Richtlinien**: einer **Vertrauensric
|
||||
|
||||
#### 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) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
**Temporäre Anmeldeinformationen werden hauptsächlich mit IAM-Rollen verwendet**, es gibt jedoch auch andere Verwendungen. Sie können temporäre Anmeldeinformationen anfordern, die über einen eingeschränkteren 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 Anmeldeinformationen. Ein Vorteil temporärer Anmeldeinformationen ist, dass sie automatisch nach einer festgelegten Zeit ablaufen. Sie haben die Kontrolle über die Dauer, für die die Anmeldeinformationen gültig sind.
|
||||
**Temporäre Anmeldeinformationen werden hauptsächlich mit IAM-Rollen verwendet**, es gibt jedoch auch andere Verwendungszwecke. Sie können temporäre Anmeldeinformationen anfordern, die über einen eingeschränkteren 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 Anmeldeinformationen. Ein Vorteil von temporären Anmeldeinformationen ist, dass sie automatisch nach einer festgelegten Zeit ablaufen. Sie haben die Kontrolle über die Dauer, für die die Anmeldeinformationen gültig sind.
|
||||
|
||||
### Richtlinien
|
||||
|
||||
@@ -164,7 +166,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 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.
|
||||
- Kundenverwaltete Richtlinien: Von Ihnen konfiguriert. Sie können Richtlinien basierend auf AWS verwalteten Richtlinien erstellen (eine davon ä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.
|
||||
|
||||
Standardmäßig ist der Zugriff **verweigert**, der Zugriff wird gewährt, wenn eine explizite Rolle angegeben wurde.\
|
||||
Wenn **einzelne "Deny" existiert, wird sie das "Allow" überschreiben**, mit Ausnahme von Anfragen, die die Root-Sicherheitsanmeldeinformationen des AWS-Kontos verwenden (die standardmäßig erlaubt sind).
|
||||
@@ -196,7 +198,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 beim Löschen dieser Identität über die AWS Management Console auch die in der Identität eingebetteten Richtlinien gelöscht. 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 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
|
||||
|
||||
@@ -206,7 +208,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 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 wird die Operation **fehlschlagen**, wenn dem Benutzer durch eine **andere 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.
|
||||
|
||||
@@ -214,9 +216,9 @@ Eine Grenze ist einfach eine Richtlinie, die einem Benutzer angehängt ist und *
|
||||
|
||||
### Sitzungsrichtlinien
|
||||
|
||||
Eine Sitzungsrichtlinie ist eine **Richtlinie, die gesetzt wird, wenn eine Rolle angenommen wird**. Dies wird wie eine **IAM-Grenze für diese Sitzung** sein: Das bedeutet, dass die Sitzungsrichtlinie keine Berechtigungen gewährt, sondern **sie auf die in der Richtlinie angegebenen beschränkt** (wobei die maximalen Berechtigungen die sind, die die Rolle hat).
|
||||
Eine Sitzungsrichtlinie ist eine **Richtlinie, die gesetzt wird, wenn eine Rolle angenommen wird**. Dies wird wie eine **IAM-Grenze für diese Sitzung** sein: Das bedeutet, dass die Sitzungsrichtlinie keine Berechtigungen gewährt, sondern **sie auf die in der Richtlinie angegebenen einschränkt** (wobei die maximalen Berechtigungen die sind, die die Rolle hat).
|
||||
|
||||
Dies ist nützlich für **Sicherheitsmaßnahmen**: Wenn ein Administrator eine sehr privilegierte Rolle annehmen möchte, könnte er die Berechtigungen auf nur die in der Sitzungsrichtlinie angegebenen beschränken, falls die Sitzung kompromittiert wird.
|
||||
Dies ist nützlich für **Sicherheitsmaßnahmen**: Wenn ein Administrator eine sehr privilegierte Rolle annehmen möchte, könnte er die Berechtigungen auf nur die in der Sitzungsrichtlinie angegebenen einschränken, falls die Sitzung kompromittiert wird.
|
||||
```bash
|
||||
aws sts assume-role \
|
||||
--role-arn <value> \
|
||||
@@ -226,16 +228,16 @@ aws sts assume-role \
|
||||
```
|
||||
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).
|
||||
|
||||
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 Sitzungsrichtlinie dies erlaubt ..." erhalten und die Rolle Zugriff auf die Aktion hat, liegt es daran, dass **eine Sitzungsrichtlinie dies verhindert**.
|
||||
|
||||
### Identitätsföderation
|
||||
|
||||
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.\
|
||||
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.\
|
||||
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.
|
||||
Um dieses Vertrauen zu konfigurieren, wird ein **IAM-Identitätsanbieter (SAML oder OAuth)** erstellt, 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.
|
||||
|
||||
Sie möchten jedoch 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 Benutzern ermöglicht, eine Rolle oder die andere zu übernehmen.
|
||||
Sie möchten jedoch 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>
|
||||
|
||||
@@ -245,7 +247,7 @@ AWS IAM Identity Center (Nachfolger von AWS Single Sign-On) erweitert die Mögli
|
||||
|
||||
Die Anmeldedomäne wird etwas sein wie `<user_input>.awsapps.com`.
|
||||
|
||||
Um Benutzer anzumelden, können 3 Identitätsquellen verwendet werden:
|
||||
Um Benutzer anzumelden, gibt es 3 Identitätsquellen, die verwendet werden können:
|
||||
|
||||
- Identity Center-Verzeichnis: Reguläre AWS-Benutzer
|
||||
- Active Directory: Unterstützt verschiedene Connectoren
|
||||
@@ -253,19 +255,19 @@ Um Benutzer anzumelden, können 3 Identitätsquellen verwendet werden:
|
||||
|
||||
<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 und 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 vergeben, 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 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`**.
|
||||
|
||||
Daher bedeutet es nicht, dass, selbst wenn Sie 2 Rollen mit einer Inline-Richtlinie namens **`AwsSSOInlinePolicy`** sehen, sie **die gleichen Berechtigungen 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) den **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) erlauben, **auf sein Konto zuzugreifen**, 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
|
||||
@@ -286,25 +288,27 @@ Die App verwendet die AssumeRoleWithWebIdentity, um temporäre Anmeldeinformatio
|
||||
|
||||
### Weitere IAM-Optionen
|
||||
|
||||
- Sie können **eine Passwortrichtlinieneinstellung** wie Mindestlänge und Passwortanforderungen festlegen.
|
||||
- Sie können **einen "Credential Report"** mit Informationen über aktuelle Anmeldeinformationen (wie Benutzererstellungszeit, ob das Passwort aktiviert ist...) herunterladen. Sie können einen Berechtigungsbericht so oft wie einmal alle **vier Stunden** generieren.
|
||||
- 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 Erstellungszeit des Benutzers, ob das Passwort aktiviert ist...). Sie können einen Berechtigungsbericht so oft wie einmal alle **vier Stunden** generieren.
|
||||
|
||||
AWS Identity and Access Management (IAM) bietet **fein abgestufte 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 **fein abgestufte 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 geringsten Privilegien** 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:
|
||||
|
||||
| ABIA | [AWS STS-Dienstträger-Token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
| Identifier Code | Beschreibung |
|
||||
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| ACCA | Kontextabhängige Anmeldeinformationen |
|
||||
| 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 |
|
||||
| APKA | Öffentlicher 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. |
|
||||
@@ -327,7 +331,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 genannte **`[default]`** verwendet.\
|
||||
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.\
|
||||
Beispiel einer Anmeldeinformationsdatei mit mehr als 1 Profil:
|
||||
```
|
||||
[default]
|
||||
@@ -339,9 +343,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 **die Annahme 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 **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.
|
||||
|
||||
Sie können die Datei `~/.aws/config` verwenden, um [**anzugeben, welche Rollen angenommen 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).\
|
||||
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).\
|
||||
Ein Beispiel für eine Konfigurationsdatei:
|
||||
```
|
||||
[profile acc2]
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## **CloudTrail**
|
||||
|
||||
AWS CloudTrail **zeichnet Aktivitäten in Ihrer AWS-Umgebung auf und überwacht sie**. Es erfasst detaillierte **Ereignisprotokolle**, einschließlich wer was, wann und von wo getan hat, für alle Interaktionen mit AWS-Ressourcen. Dies bietet eine Prüfspur von Änderungen und Aktionen, die bei der Sicherheitsanalyse, der Compliance-Prüfung und der Verfolgung von Ressourcenänderungen hilft. CloudTrail ist entscheidend für das Verständnis des Verhaltens von Benutzern und Ressourcen, die Verbesserung der Sicherheitslage und die Gewährleistung der Einhaltung von Vorschriften.
|
||||
AWS CloudTrail **zeichnet Aktivitäten in Ihrer AWS-Umgebung auf und überwacht sie**. Es erfasst detaillierte **Ereignisprotokolle**, einschließlich wer was, wann und von wo getan hat, für alle Interaktionen mit AWS-Ressourcen. Dies bietet eine Prüfspur von Änderungen und Aktionen, die bei der Sicherheitsanalyse, der Compliance-Prüfung und der Verfolgung von Ressourcenänderungen hilft. CloudTrail ist entscheidend für das Verständnis des Verhaltens von Benutzern und Ressourcen, zur Verbesserung der Sicherheitslage und zur Gewährleistung der Einhaltung von Vorschriften.
|
||||
|
||||
Jedes protokollierte Ereignis enthält:
|
||||
|
||||
@@ -48,7 +48,7 @@ Darüber hinaus werden **Digest-Dateien (zur Überprüfung der Dateiintegrität)
|
||||
- Wenden Sie Berechtigungen auf den Ziel-S3-Bucket an, um den Zugriff über Konten für CloudTrail zu ermöglichen, und erlauben Sie jedem AWS-Konto, das Zugriff benötigt
|
||||
- Erstellen Sie einen neuen Trail in den anderen AWS-Konten und wählen Sie aus, den im Schritt 1 erstellten Bucket zu verwenden
|
||||
|
||||
Wenn Sie jedoch alle Protokolle im selben S3-Bucket speichern können, können Sie CloudTrail-Protokolle von mehreren Konten nicht in CloudWatch-Protokollen aggregieren, die zu einem einzelnen AWS-Konto gehören.
|
||||
Wenn Sie jedoch alle Protokolle im selben S3-Bucket speichern können, können Sie CloudTrail-Protokolle von mehreren Konten nicht in CloudWatch-Protokolle aggregieren, die zu einem einzelnen AWS-Konto gehören.
|
||||
|
||||
> [!CAUTION]
|
||||
> Denken Sie daran, dass ein Konto **verschiedene Trails** von CloudTrail **aktiviert** haben kann, die dieselben (oder unterschiedliche) Protokolle in verschiedenen Buckets speichern.
|
||||
@@ -83,23 +83,23 @@ Der CloudTrail-Ereignisverlauf ermöglicht es Ihnen, in einer Tabelle die aufgez
|
||||
|
||||
### Einblicke
|
||||
|
||||
**CloudTrail Insights** analysiert automatisch **Schreibmanagementereignisse** von CloudTrail-Tracks und **benachrichtigt** Sie über **ungewöhnliche Aktivitäten**. Wenn es beispielsweise einen Anstieg von `TerminateInstance`-Ereignissen gibt, der von festgelegten Baselines abweicht, sehen Sie dies als Insight-Ereignis. Diese Ereignisse erleichtern **das Finden und Reagieren auf ungewöhnliche API-Aktivitäten** mehr denn je.
|
||||
**CloudTrail Insights** analysiert automatisch **Schreibmanagementereignisse** von CloudTrail-Tracks und **benachrichtigt** Sie über **ungewöhnliche Aktivitäten**. Wenn beispielsweise ein Anstieg der `TerminateInstance`-Ereignisse festgestellt wird, der von festgelegten Baselines abweicht, sehen Sie dies als Insight-Ereignis. Diese Ereignisse erleichtern **das Finden und Reagieren auf ungewöhnliche API-Aktivitäten** mehr denn je.
|
||||
|
||||
Die Einblicke werden im selben Bucket wie die CloudTrail-Protokolle gespeichert: `BucketName/AWSLogs/AccountID/CloudTrail-Insight`
|
||||
|
||||
### Sicherheit
|
||||
|
||||
| Integrität der CloudTrail-Protokolldatei | <ul><li>Überprüfen, ob Protokolle manipuliert wurden (modifiziert oder gelöscht)</li><li><p>Verwendet Digest-Dateien (erstellt Hash für jede Datei)</p><ul><li>SHA-256-Hashing</li><li>SHA-256 mit RSA für digitale Signatur</li><li>privater Schlüssel im Besitz von Amazon</li></ul></li><li>Benötigt 1 Stunde, um eine Digest-Datei zu erstellen (jede Stunde zur vollen Stunde)</li></ul> |
|
||||
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| Unbefugten Zugriff stoppen | <ul><li><p>Verwenden Sie IAM-Richtlinien und S3-Bucket-Richtlinien</p><ul><li>Sicherheitsteam —> Administratorzugriff</li><li>Prüfer —> Nur-Lese-Zugriff</li></ul></li><li>Verwenden Sie SSE-S3/SSE-KMS, um die Protokolle zu verschlüsseln</li></ul> |
|
||||
| Verhindern, dass Protokolldateien gelöscht werden | <ul><li>Beschränken Sie den Löschzugriff mit IAM- und Bucket-Richtlinien</li><li>Konfigurieren Sie S3 MFA-Löschen</li><li>Überprüfen Sie mit der Protokolldatei-Validierung</li></ul> |
|
||||
| Kontrollname | Implementierungsdetails |
|
||||
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| Integrität der CloudTrail-Protokolldatei | <ul><li>Überprüfen, ob Protokolle manipuliert wurden (modifiziert oder gelöscht)</li><li><p>Verwendet Digest-Dateien (erstellt Hash für jede Datei)</p><ul><li>SHA-256-Hashing</li><li>SHA-256 mit RSA für digitale Signatur</li><li>privater Schlüssel im Besitz von Amazon</li></ul></li><li>Es dauert 1 Stunde, um eine Digest-Datei zu erstellen (jede Stunde zur vollen Stunde)</li></ul> |
|
||||
| Unbefugten Zugriff stoppen | <ul><li><p>Verwenden Sie IAM-Richtlinien und S3-Bucket-Richtlinien</p><ul><li>Sicherheitsteam —> Administratorzugriff</li><li>Prüfer —> Nur-Lese-Zugriff</li></ul></li><li>Verwenden Sie SSE-S3/SSE-KMS, um die Protokolle zu verschlüsseln</li></ul> |
|
||||
| Verhindern, dass Protokolldateien gelöscht werden | <ul><li>Zugriff auf das Löschen mit IAM- und Bucket-Richtlinien einschränken</li><li>S3 MFA-Löschen konfigurieren</li><li>Überprüfen mit der Protokolldatei-Validierung</li></ul> |
|
||||
|
||||
## Zugriffsberater
|
||||
|
||||
AWS Access Advisor stützt sich auf die letzten 400 Tage der AWS **CloudTrail-Protokolle, um seine Einblicke zu gewinnen**. CloudTrail erfasst eine Historie von AWS-API-Aufrufen und verwandten Ereignissen, die in einem AWS-Konto durchgeführt wurden. Access Advisor nutzt diese Daten, um **zu zeigen, wann Dienste zuletzt aufgerufen wurden**. Durch die Analyse der CloudTrail-Protokolle kann Access Advisor bestimmen, auf welche AWS-Dienste ein IAM-Benutzer oder eine Rolle zugegriffen hat und wann dieser Zugriff stattfand. Dies hilft AWS-Administratoren, informierte Entscheidungen über **die Verfeinerung von Berechtigungen** zu treffen, da sie Dienste identifizieren können, die über längere Zeiträume nicht aufgerufen wurden, und möglicherweise übermäßig breite Berechtigungen basierend auf realen Nutzungsmustern reduzieren können.
|
||||
AWS Access Advisor stützt sich auf die letzten 400 Tage der AWS **CloudTrail-Protokolle, um seine Einblicke zu gewinnen**. CloudTrail erfasst eine Historie der AWS-API-Aufrufe und verwandten Ereignisse, die in einem AWS-Konto durchgeführt wurden. Access Advisor nutzt diese Daten, um **zu zeigen, wann Dienste zuletzt aufgerufen wurden**. Durch die Analyse der CloudTrail-Protokolle kann Access Advisor bestimmen, auf welche AWS-Dienste ein IAM-Benutzer oder eine Rolle zugegriffen hat und wann dieser Zugriff stattfand. Dies hilft AWS-Administratoren, informierte Entscheidungen über **die Verfeinerung von Berechtigungen** zu treffen, da sie Dienste identifizieren können, die über längere Zeiträume nicht aufgerufen wurden, und möglicherweise zu weitreichende Berechtigungen basierend auf realen Nutzungsmustern reduzieren können.
|
||||
|
||||
> [!TIP]
|
||||
> Daher informiert der Zugriffsberater über **die unnötigen Berechtigungen, die Benutzern erteilt werden**, sodass der Administrator sie entfernen kann
|
||||
> Daher informiert Access Advisor über **die unnötigen Berechtigungen, die Benutzern erteilt werden**, damit der Administrator sie entfernen kann
|
||||
|
||||
<figure><img src="../../../../images/image (78).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -124,7 +124,7 @@ aws cloudtrail get-query-results --event-data-store <data-source> --query-id <id
|
||||
```
|
||||
### **CSV Injection**
|
||||
|
||||
Es ist möglich, eine CVS-Injektion innerhalb von CloudTrail durchzuführen, die willkürlichen Code ausführt, wenn die Protokolle im CSV-Format exportiert und mit Excel geöffnet werden.\
|
||||
Es ist möglich, eine CVS-Injektion in CloudTrail durchzuführen, die willkürlichen Code ausführt, wenn die Protokolle im CSV-Format exportiert und mit Excel geöffnet werden.\
|
||||
Der folgende Code generiert einen Protokolleintrag mit einem schlechten Trail-Namen, der die Payload enthält:
|
||||
```python
|
||||
import boto3
|
||||
@@ -142,7 +142,7 @@ Für weitere Informationen zu CSV-Injektionen siehe die Seite:
|
||||
https://book.hacktricks.wiki/en/pentesting-web/formula-csv-doc-latex-ghostscript-injection.html
|
||||
{{#endref}}
|
||||
|
||||
Für weitere Informationen zu dieser speziellen Technik siehe [https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/](https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/)
|
||||
Für weitere Informationen zu dieser spezifischen Technik siehe [https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/](https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/)
|
||||
|
||||
## **Umgehung der Erkennung**
|
||||
|
||||
@@ -183,9 +183,9 @@ print("account id:" + "{:012d}".format(AWSAccount_from_AWSKeyID("ASIAQNZGKIQY56J
|
||||
```
|
||||
Überprüfen Sie weitere Informationen in der [**originalen Forschung**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489).
|
||||
|
||||
#### Protokoll nicht generieren
|
||||
#### Kein Protokoll generieren
|
||||
|
||||
Die effektivste Technik dafür ist tatsächlich eine einfache. Verwenden Sie einfach den Schlüssel, den Sie gerade gefunden haben, um auf einen Dienst in Ihrem eigenen Angreifer-Konto zuzugreifen. Dadurch wird **CloudTrail ein Protokoll in IHREM EIGENEN AWS-Konto und nicht im Konto des Opfers** erstellen.
|
||||
Die effektivste Technik dafür ist tatsächlich eine einfache. Verwenden Sie einfach den Schlüssel, den Sie gerade gefunden haben, um auf einen Dienst in Ihrem eigenen Angreifer-Konto zuzugreifen. Dadurch wird **CloudTrail ein Protokoll in IHREM EIGENEN AWS-Konto und nicht im Konto des Opfers** generieren.
|
||||
|
||||
Das Problem ist, dass die Ausgabe Ihnen einen Fehler anzeigt, der die Kontonummer und den Kontonamen angibt, sodass **Sie sehen können, ob es sich um ein Honeytoken handelt**.
|
||||
|
||||
@@ -193,20 +193,20 @@ Das Problem ist, dass die Ausgabe Ihnen einen Fehler anzeigt, der die Kontonumme
|
||||
|
||||
In der Vergangenheit gab es einige **AWS-Dienste, die keine Protokolle an CloudTrail senden** (finden Sie eine [Liste hier](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)). Einige dieser Dienste werden mit einem **Fehler** antworten, der die **ARN der Schlüsselrolle** enthält, wenn jemand Unbefugtes (der Honeytoken-Schlüssel) versucht, darauf zuzugreifen.
|
||||
|
||||
Auf diese Weise kann ein **Angreifer die ARN des Schlüssels erhalten, ohne ein Protokoll auszulösen**. In der ARN kann der Angreifer die **AWS-Kontonummer und den Namen** sehen, es ist einfach, die Kontonummern und Namen der HoneyToken-Unternehmen zu kennen, sodass ein Angreifer auf diese Weise feststellen kann, ob das Token ein HoneyToken ist.
|
||||
Auf diese Weise kann ein **Angreifer die ARN des Schlüssels erhalten, ohne ein Protokoll auszulösen**. In der ARN kann der Angreifer die **AWS-Kontonummer und den Namen** sehen, es ist einfach, die Kontonummern und Namen der HoneyToken-Unternehmen zu kennen, sodass ein Angreifer auf diese Weise identifizieren kann, ob das Token ein HoneyToken ist.
|
||||
|
||||
.png>)
|
||||
|
||||
> [!CAUTION]
|
||||
> Beachten Sie, dass alle öffentlichen APIs, die entdeckt wurden, keine CloudTrail-Protokolle zu erstellen, jetzt behoben sind, sodass Sie möglicherweise Ihre eigenen finden müssen...
|
||||
> Beachten Sie, dass alle öffentlichen APIs, die nicht CloudTrail-Protokolle erstellen, jetzt behoben sind, sodass Sie möglicherweise Ihre eigenen finden müssen...
|
||||
>
|
||||
> Für weitere Informationen überprüfen Sie die [**originale Forschung**](https://rhinosecuritylabs.com/aws/aws-iam-enumeration-2-0-bypassing-cloudtrail-logging/).
|
||||
|
||||
### Zugriff auf Dritte Infrastruktur
|
||||
|
||||
Bestimmte AWS-Dienste werden **einige Infrastrukturen** wie **Datenbanken** oder **Kubernetes**-Cluster (EKS) **erzeugen**. Ein Benutzer, der **direkt mit diesen Diensten spricht** (wie der Kubernetes-API), **wird die AWS-API nicht verwenden**, sodass CloudTrail diese Kommunikation nicht sehen kann.
|
||||
Bestimmte AWS-Dienste werden **einige Infrastrukturen** wie **Datenbanken** oder **Kubernetes**-Cluster (EKS) **erzeugen**. Ein Benutzer, der **direkt mit diesen Diensten** (wie der Kubernetes-API) **spricht, wird die AWS-API nicht verwenden**, sodass CloudTrail diese Kommunikation nicht sehen kann.
|
||||
|
||||
Daher könnte ein Benutzer mit Zugriff auf EKS, der die URL der EKS-API entdeckt hat, lokal ein Token generieren und **direkt mit dem API-Dienst sprechen, ohne von CloudTrail erkannt zu werden**.
|
||||
Daher könnte ein Benutzer mit Zugriff auf EKS, der die URL der EKS-API entdeckt hat, ein Token lokal generieren und **direkt mit dem API-Dienst sprechen, ohne von CloudTrail erkannt zu werden**.
|
||||
|
||||
Weitere Informationen in:
|
||||
|
||||
@@ -228,7 +228,7 @@ aws cloudtrail stop-logging --name [trail-name]
|
||||
```bash
|
||||
aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services
|
||||
```
|
||||
#### Protokollierung durch Ereignis-Selektoren deaktivieren
|
||||
#### Deaktivieren der Protokollierung durch Ereignis-Selektoren
|
||||
```bash
|
||||
# Leave only the ReadOnly selector
|
||||
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[{"ReadWriteType": "ReadOnly"}]' --region <region>
|
||||
@@ -236,7 +236,7 @@ aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '
|
||||
# Remove all selectors (stop Insights)
|
||||
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[]' --region <region>
|
||||
```
|
||||
Im ersten Beispiel wird ein einzelner Ereignis-Selektor als JSON-Array mit einem einzelnen Objekt bereitgestellt. Der `"ReadWriteType": "ReadOnly"` zeigt an, dass der **Ereignis-Selektor nur schreibgeschützte Ereignisse erfassen sollte** (CloudTrail-Insights **werden beispielsweise keine Schreibereignisse überprüfen**).
|
||||
Im ersten Beispiel wird ein einzelner Ereignis-Selektor als JSON-Array mit einem einzelnen Objekt bereitgestellt. Der `"ReadWriteType": "ReadOnly"` zeigt an, dass der **Ereignis-Selektor nur schreibgeschützte Ereignisse erfassen sollte** (CloudTrail-Insights **werden beispielsweise keine Schreib**ereignisse überprüfen).
|
||||
|
||||
Sie können den Ereignis-Selektor basierend auf Ihren spezifischen Anforderungen anpassen.
|
||||
|
||||
|
||||
@@ -27,13 +27,13 @@ Ein Namespace ist ein Container für CloudWatch-Metriken. Er hilft, Metriken zu
|
||||
|
||||
### Metriken
|
||||
|
||||
Metriken sind über die Zeit gesammelte Datenpunkte, die die Leistung oder Nutzung von AWS-Ressourcen darstellen. Metriken können aus AWS-Diensten, benutzerdefinierten Anwendungen oder Drittanbieter-Integrationen gesammelt werden.
|
||||
Metriken sind Datenpunkte, die über die Zeit gesammelt werden und die Leistung oder Nutzung von AWS-Ressourcen darstellen. Metriken können aus AWS-Diensten, benutzerdefinierten Anwendungen oder Drittanbieter-Integrationen gesammelt werden.
|
||||
|
||||
- **Beispiel**: CPUUtilization, NetworkIn, DiskReadOps.
|
||||
|
||||
### Dimensionen
|
||||
|
||||
Dimensionen sind Schlüssel-Wert-Paare, die Teil von Metriken sind. Sie helfen, eine Metrik eindeutig zu identifizieren und bieten zusätzlichen Kontext, wobei 30 die maximale Anzahl von Dimensionen ist, die mit einer Metrik verknüpft werden können. Dimensionen ermöglichen auch das Filtern und Aggregieren von Metriken basierend auf spezifischen Attributen.
|
||||
Dimensionen sind Schlüssel-Wert-Paare, die Teil von Metriken sind. Sie helfen, eine Metrik eindeutig zu identifizieren und bieten zusätzlichen Kontext, wobei 30 die maximale Anzahl von Dimensionen ist, die mit einer Metrik verknüpft werden können. Dimensionen ermöglichen auch das Filtern und Aggregieren von Metriken basierend auf bestimmten Attributen.
|
||||
|
||||
- **Beispiel**: Für EC2-Instanzen könnten Dimensionen InstanceId, InstanceType und AvailabilityZone umfassen.
|
||||
|
||||
@@ -45,7 +45,7 @@ Statistiken sind mathematische Berechnungen, die auf Metrikdaten durchgeführt w
|
||||
|
||||
### Einheiten
|
||||
|
||||
Einheiten sind der Messungstyp, der mit einer Metrik verbunden ist. Einheiten helfen, Kontext und Bedeutung zu den Metrikdaten zu liefern. Zu den gängigen Einheiten gehören Prozent, Bytes, Sekunden, Anzahl.
|
||||
Einheiten sind der Messungstyp, der mit einer Metrik verbunden ist. Einheiten helfen, Kontext und Bedeutung zu den Metrikdaten zu liefern. Gängige Einheiten sind Prozent, Bytes, Sekunden, Anzahl.
|
||||
|
||||
- **Beispiel**: CPUUtilization könnte in Prozent gemessen werden, während NetworkIn in Bytes gemessen werden könnte.
|
||||
|
||||
@@ -82,8 +82,8 @@ Einheiten sind der Messungstyp, der mit einer Metrik verbunden ist. Einheiten he
|
||||
**Hauptkomponenten**:
|
||||
|
||||
- **Schwellenwert**: Der Wert, bei dem der Alarm ausgelöst wird.
|
||||
- **Bewertungszeiträume**: Die Anzahl der Zeiträume, über die Daten bewertet werden.
|
||||
- **Datapoints to Alarm**: Die Anzahl der Zeiträume mit einem erreichten Schwellenwert, die erforderlich sind, um den Alarm auszulösen.
|
||||
- **Bewertungszeiträume**: Die Anzahl der Zeiträume, über die die Daten bewertet werden.
|
||||
- **Datenpunkte zum Alarm**: Die Anzahl der Zeiträume mit einem erreichten Schwellenwert, die erforderlich sind, um den Alarm auszulösen.
|
||||
- **Aktionen**: Was passiert, wenn ein Alarmzustand ausgelöst wird (z. B. Benachrichtigung über SNS).
|
||||
|
||||
**Beispielanwendung**:
|
||||
@@ -118,10 +118,10 @@ Einheiten sind der Messungstyp, der mit einer Metrik verbunden ist. Einheiten he
|
||||
Ermöglicht das **Aggregieren und Überwachen von Protokollen aus Anwendungen** und Systemen von **AWS-Diensten** (einschließlich CloudTrail) und **von Apps/Systemen** (**CloudWatch-Agent** kann auf einem Host installiert werden). Protokolle können **unbegrenzt gespeichert** werden (abhängig von den Einstellungen der Protokollgruppe) und können exportiert werden.
|
||||
|
||||
**Elemente**:
|
||||
|
||||
| **Protokollgruppe** | Eine **Sammlung von Protokollstreams**, die dieselben Aufbewahrungs-, Überwachungs- und Zugriffskontrolleinstellungen teilen |
|
||||
| Begriff | Definition |
|
||||
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Protokollstream** | Eine Sequenz von **Protokolldaten**, die die **gleiche Quelle** teilen |
|
||||
| **Protokollgruppe** | Eine **Sammlung von Protokollstreams**, die dieselben Aufbewahrungs-, Überwachungs- und Zugriffskontrolleinstellungen teilen |
|
||||
| **Protokollstream** | Eine Sequenz von **Protokollereignissen**, die die **gleiche Quelle** teilen |
|
||||
| **Abonnementfilter** | Definieren ein **Filtermuster, das Ereignisse** in einer bestimmten Protokollgruppe übereinstimmt, senden sie an Kinesis Data Firehose-Stream, Kinesis-Stream oder eine Lambda-Funktion |
|
||||
|
||||
### CloudWatch-Überwachung & Ereignisse
|
||||
@@ -131,13 +131,13 @@ In diesem Fall kann CloudWatch bereit sein, ein Ereignis zu senden und einige au
|
||||
|
||||
### Agenteninstallation
|
||||
|
||||
Sie können Agenten in Ihren Maschinen/Containern installieren, um automatisch die Protokolle an CloudWatch zurückzusenden.
|
||||
Sie können Agenten in Ihren Maschinen/Containern installieren, um die Protokolle automatisch an CloudWatch zurückzusenden.
|
||||
|
||||
- **Erstellen** Sie eine **Rolle** und **fügen** Sie sie der **Instanz** mit Berechtigungen hinzu, die es CloudWatch ermöglichen, Daten von den Instanzen zu sammeln, zusätzlich zur Interaktion mit dem AWS Systems Manager SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM).
|
||||
- **Laden** Sie den **Agenten** herunter und **installieren** Sie ihn auf der EC2-Instanz ([https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip](https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip)). Sie können ihn von innerhalb der EC2 herunterladen oder automatisch mit AWS Systems Manager installieren, indem Sie das Paket AWS-ConfigureAWSPackage auswählen.
|
||||
- **Konfigurieren** und **starten** Sie den CloudWatch-Agenten.
|
||||
|
||||
Eine Protokollgruppe hat viele Streams. Ein Stream hat viele Ereignisse. Und innerhalb jedes Streams sind die Ereignisse garantiert in der richtigen Reihenfolge.
|
||||
Eine Protokollgruppe hat viele Streams. Ein Stream hat viele Ereignisse. Und innerhalb jedes Streams sind die Ereignisse in der Reihenfolge garantiert.
|
||||
|
||||
## Enumeration
|
||||
```bash
|
||||
@@ -224,10 +224,10 @@ aws cloudwatch put-metric-alarm --cli-input-json <value> | --alarm-name <value>
|
||||
aws cloudwatch delete-alarms --alarm-names <value>
|
||||
aws cloudwatch put-composite-alarm --alarm-name <value> --alarm-rule <value> [--no-actions-enabled | --actions-enabled [--alarm-actions <value>] [--insufficient-data-actions <value>] [--ok-actions <value>] ]
|
||||
```
|
||||
Das folgende Beispiel zeigt, wie man einen Metrikalarm unwirksam macht:
|
||||
Das folgende Beispiel zeigt, wie man einen Metrik-Alarm unwirksam macht:
|
||||
|
||||
- Dieser Metrikalarm überwacht die durchschnittliche CPU-Auslastung einer bestimmten EC2-Instanz, bewertet die Metrik alle 300 Sekunden und erfordert 6 Bewertungsperioden (insgesamt 30 Minuten). Wenn die durchschnittliche CPU-Auslastung in mindestens 4 dieser Perioden 60 % überschreitet, wird der Alarm ausgelöst und sendet eine Benachrichtigung an das angegebene SNS-Thema.
|
||||
- Durch Ändern des Schwellenwerts auf mehr als 99 %, Festlegen der Periode auf 10 Sekunden, der Bewertungsperioden auf 8640 (da 8640 Perioden von 10 Sekunden 1 Tag entsprechen) und der Datenpunkte auf Alarm ebenfalls auf 8640, wäre es erforderlich, dass die CPU-Auslastung über 99 % alle 10 Sekunden während des gesamten 24-Stunden-Zeitraums liegt, um einen Alarm auszulösen.
|
||||
- Dieser Metrik-Alarm überwacht die durchschnittliche CPU-Auslastung einer bestimmten EC2-Instanz, bewertet die Metrik alle 300 Sekunden und erfordert 6 Bewertungsperioden (insgesamt 30 Minuten). Wenn die durchschnittliche CPU-Auslastung in mindestens 4 dieser Perioden 60 % überschreitet, wird der Alarm ausgelöst und sendet eine Benachrichtigung an das angegebene SNS-Thema.
|
||||
- Durch die Änderung des Schwellenwerts auf mehr als 99 %, das Setzen der Periode auf 10 Sekunden, der Bewertungsperioden auf 8640 (da 8640 Perioden von 10 Sekunden 1 Tag entsprechen) und der Datapoints to Alarm auf ebenfalls 8640, wäre es erforderlich, dass die CPU-Auslastung über 99 % alle 10 Sekunden während des gesamten 24-Stunden-Zeitraums liegt, um einen Alarm auszulösen.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Original Metric Alarm" }}
|
||||
@@ -254,7 +254,7 @@ Das folgende Beispiel zeigt, wie man einen Metrikalarm unwirksam macht:
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Modifizierte Metrik-Alarme" }}
|
||||
{{#tab name="Modified Metric Alarm" }}
|
||||
```json
|
||||
{
|
||||
"Namespace": "AWS/EC2",
|
||||
@@ -283,9 +283,9 @@ Das folgende Beispiel zeigt, wie man einen Metrikalarm unwirksam macht:
|
||||
|
||||
### **`cloudwatch:DeleteAlarmActions`, `cloudwatch:EnableAlarmActions`, `cloudwatch:SetAlarmState`**
|
||||
|
||||
Durch das Löschen von Alarmaktionen könnte der Angreifer kritische Benachrichtigungen und automatisierte Reaktionen verhindern, die ausgelöst werden, wenn ein Alarmzustand erreicht wird, wie z.B. die Benachrichtigung von Administratoren oder das Auslösen von Auto-Scaling-Aktivitäten. Das unangemessene Aktivieren oder Wiederaktivieren von Alarmaktionen könnte ebenfalls zu unerwartetem Verhalten führen, entweder durch die Reaktivierung zuvor deaktivierter Aktionen oder durch die Änderung, welche Aktionen ausgelöst werden, was potenziell Verwirrung und Fehlleitungen bei der Vorfallreaktion verursachen könnte.
|
||||
Durch das Löschen von Alarmaktionen könnte der Angreifer kritische Warnungen und automatisierte Reaktionen verhindern, die ausgelöst werden, wenn ein Alarmzustand erreicht wird, wie z. B. die Benachrichtigung von Administratoren oder das Auslösen von Auto-Scaling-Aktivitäten. Das unangemessene Aktivieren oder Wiederaktivieren von Alarmaktionen könnte ebenfalls zu unerwartetem Verhalten führen, entweder durch die Reaktivierung zuvor deaktivierter Aktionen oder durch die Änderung, welche Aktionen ausgelöst werden, was potenziell zu Verwirrung und Fehlleitungen bei der Vorfallreaktion führen könnte.
|
||||
|
||||
Darüber hinaus könnte ein Angreifer mit der Berechtigung Alarmzustände manipulieren, indem er falsche Alarme erstellt, um Administratoren abzulenken und zu verwirren, oder echte Alarme zum Schweigen bringt, um laufende bösartige Aktivitäten oder kritische Systemausfälle zu verbergen.
|
||||
Darüber hinaus könnte ein Angreifer mit der Berechtigung Alarmzustände manipulieren, indem er falsche Alarme erstellt, um Administratoren abzulenken und zu verwirren, oder echte Alarme zum Schweigen bringt, um laufende böswillige Aktivitäten oder kritische Systemausfälle zu verbergen.
|
||||
|
||||
- Wenn Sie **`SetAlarmState`** bei einem zusammengesetzten Alarm verwenden, ist nicht garantiert, dass der zusammengesetzte Alarm in seinen tatsächlichen Zustand zurückkehrt. Er kehrt nur dann in seinen tatsächlichen Zustand zurück, wenn einer seiner untergeordneten Alarme den Zustand ändert. Er wird auch neu bewertet, wenn Sie seine Konfiguration aktualisieren.
|
||||
```bash
|
||||
@@ -293,7 +293,7 @@ aws cloudwatch disable-alarm-actions --alarm-names <value>
|
||||
aws cloudwatch enable-alarm-actions --alarm-names <value>
|
||||
aws cloudwatch set-alarm-state --alarm-name <value> --state-value <OK | ALARM | INSUFFICIENT_DATA> --state-reason <value> [--state-reason-data <value>]
|
||||
```
|
||||
**Potenzielle Auswirkungen**: Fehlende Benachrichtigungen für kritische Ereignisse, potenzielle unentdeckte Probleme, falsche Alarme, Unterdrückung echter Alarme und möglicherweise verpasste Erkennungen echter Vorfälle.
|
||||
**Potenzielle Auswirkungen**: Fehlende Benachrichtigungen für kritische Ereignisse, potenzielle unentdeckte Probleme, falsche Alarme, Unterdrückung echter Alarme und möglicherweise verpasste Erkennungen realer Vorfälle.
|
||||
|
||||
### **`cloudwatch:DeleteAnomalyDetector`, `cloudwatch:PutAnomalyDetector`**
|
||||
|
||||
@@ -302,7 +302,7 @@ Ein Angreifer könnte die Fähigkeit zur Erkennung und Reaktion auf ungewöhnlic
|
||||
aws cloudwatch delete-anomaly-detector [--cli-input-json <value> | --namespace <value> --metric-name <value> --dimensions <value> --stat <value>]
|
||||
aws cloudwatch put-anomaly-detector [--cli-input-json <value> | --namespace <value> --metric-name <value> --dimensions <value> --stat <value> --configuration <value> --metric-characteristics <value>]
|
||||
```
|
||||
Das folgende Beispiel zeigt, wie man einen Metrik-Anomalie-Detektor unwirksam macht. Dieser Metrik-Anomalie-Detektor überwacht die durchschnittliche CPU-Auslastung einer bestimmten EC2-Instanz, und allein durch das Hinzufügen des Parameters „ExcludedTimeRanges“ mit dem gewünschten Zeitbereich wäre es ausreichend, um sicherzustellen, dass der Anomalie-Detektor während dieses Zeitraums keine relevanten Daten analysiert oder warnt.
|
||||
Das folgende Beispiel zeigt, wie man einen Metrik-Anomalie-Detektor unwirksam macht. Dieser Metrik-Anomalie-Detektor überwacht die durchschnittliche CPU-Auslastung einer bestimmten EC2-Instanz, und allein durch das Hinzufügen des Parameters „ExcludedTimeRanges“ mit dem gewünschten Zeitbereich wäre es ausreichend, um sicherzustellen, dass der Anomalie-Detektor während dieses Zeitraums keine relevanten Daten analysiert oder Alarm schlägt.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Original Metric Anomaly Detector" }}
|
||||
@@ -355,7 +355,7 @@ Das folgende Beispiel zeigt, wie man einen Metrik-Anomalie-Detektor unwirksam ma
|
||||
|
||||
### **`cloudwatch:DeleteDashboards`, `cloudwatch:PutDashboard`**
|
||||
|
||||
Ein Angreifer könnte die Überwachungs- und Visualisierungsfähigkeiten einer Organisation gefährden, indem er deren Dashboards erstellt, ändert oder löscht. Diese Berechtigungen könnten genutzt werden, um kritische Sichtbarkeit in die Leistung und Gesundheit von Systemen zu entfernen, Dashboards so zu ändern, dass falsche Daten angezeigt werden, oder böswillige Aktivitäten zu verbergen.
|
||||
Ein Angreifer könnte die Überwachungs- und Visualisierungsfähigkeiten einer Organisation gefährden, indem er deren Dashboards erstellt, ändert oder löscht. Diese Berechtigungen könnten genutzt werden, um kritische Einblicke in die Leistung und Gesundheit von Systemen zu entfernen, Dashboards so zu ändern, dass falsche Daten angezeigt werden, oder böswillige Aktivitäten zu verbergen.
|
||||
```bash
|
||||
aws cloudwatch delete-dashboards --dashboard-names <value>
|
||||
aws cloudwatch put-dashboard --dashboard-name <value> --dashboard-body <value>
|
||||
@@ -374,7 +374,7 @@ aws cloudwatch put-managed-insight-rules --managed-rules <value>
|
||||
|
||||
### **`cloudwatch:DisableInsightRules`, `cloudwatch:EnableInsightRules`**
|
||||
|
||||
Durch das Deaktivieren kritischer Einsichtsregeln könnte ein Angreifer die Organisation effektiv blind für wichtige Leistungs- und Sicherheitsmetriken machen. Umgekehrt könnte es durch das Aktivieren oder Konfigurieren irreführender Regeln möglich sein, falsche Daten zu erzeugen, Lärm zu erzeugen oder bösartige Aktivitäten zu verbergen.
|
||||
Durch das Deaktivieren kritischer Einsichtregeln könnte ein Angreifer die Organisation effektiv blind für wichtige Leistungs- und Sicherheitsmetriken machen. Umgekehrt könnte es durch das Aktivieren oder Konfigurieren irreführender Regeln möglich sein, falsche Daten zu erzeugen, Lärm zu erzeugen oder bösartige Aktivitäten zu verbergen.
|
||||
```bash
|
||||
aws cloudwatch disable-insight-rules --rule-names <value>
|
||||
aws cloudwatch enable-insight-rules --rule-names <value>
|
||||
@@ -385,17 +385,17 @@ aws cloudwatch enable-insight-rules --rule-names <value>
|
||||
|
||||
Ein Angreifer mit den Berechtigungen **`cloudwatch:DeleteMetricStream`** , **`cloudwatch:PutMetricStream`** wäre in der Lage, Metrikdatenströme zu erstellen und zu löschen, was die Sicherheit, Überwachung und Datenintegrität gefährdet:
|
||||
|
||||
- **Bösartige Streams erstellen**: Metrikstreams erstellen, um sensible Daten an unbefugte Ziele zu senden.
|
||||
- **Ressourcenmanipulation**: Die Erstellung neuer Metrikstreams mit übermäßigen Daten könnte viel Lärm erzeugen, was zu falschen Alarmen führt und wahre Probleme maskiert.
|
||||
- **Überwachungsstörung**: Durch das Löschen von Metrikstreams würden Angreifer den kontinuierlichen Fluss von Überwachungsdaten stören. Auf diese Weise wären ihre bösartigen Aktivitäten effektiv verborgen.
|
||||
- **Böswillige Streams erstellen**: Metrikströme erstellen, um sensible Daten an unbefugte Ziele zu senden.
|
||||
- **Ressourcenmanipulation**: Die Erstellung neuer Metrikströme mit übermäßigen Daten könnte viel Lärm erzeugen, was zu falschen Alarmen führt und wahre Probleme maskiert.
|
||||
- **Überwachungsstörung**: Durch das Löschen von Metrikströmen würden Angreifer den kontinuierlichen Fluss von Überwachungsdaten stören. Auf diese Weise wären ihre böswilligen Aktivitäten effektiv verborgen.
|
||||
|
||||
Ähnlich könnte man mit der Berechtigung **`cloudwatch:PutMetricData`** Daten zu einem Metrikstream hinzufügen. Dies könnte zu einem DoS führen, aufgrund der Menge an unzulässigen Daten, die hinzugefügt werden, wodurch es völlig nutzlos wird.
|
||||
Ähnlich wäre es mit der Berechtigung **`cloudwatch:PutMetricData`** möglich, Daten zu einem Metrikstrom hinzuzufügen. Dies könnte zu einem DoS führen, aufgrund der Menge an unzulässigen Daten, die hinzugefügt werden, wodurch es völlig nutzlos wird.
|
||||
```bash
|
||||
aws cloudwatch delete-metric-stream --name <value>
|
||||
aws cloudwatch put-metric-stream --name <value> [--include-filters <value>] [--exclude-filters <value>] --firehose-arn <value> --role-arn <value> --output-format <value>
|
||||
aws cloudwatch put-metric-data --namespace <value> [--metric-data <value>] [--metric-name <value>] [--timestamp <value>] [--unit <value>] [--value <value>] [--dimensions <value>]
|
||||
```
|
||||
Beispiel für das Hinzufügen von Daten, die 70 % der CPU-Auslastung über eine gegebene EC2-Instanz entsprechen:
|
||||
Beispiel für das Hinzufügen von Daten, die 70% der CPU-Auslastung über eine gegebene EC2-Instanz entsprechen:
|
||||
```bash
|
||||
aws cloudwatch put-metric-data --namespace "AWS/EC2" --metric-name "CPUUtilization" --value 70 --unit "Percent" --dimensions "InstanceId=i-0123456789abcdefg"
|
||||
```
|
||||
@@ -408,7 +408,7 @@ Ein Angreifer würde den Fluss der betroffenen Metrikdatenströme kontrollieren
|
||||
aws cloudwatch stop-metric-streams --names <value>
|
||||
aws cloudwatch start-metric-streams --names <value>
|
||||
```
|
||||
**Potenzielle Auswirkungen**: Störung des Flusses von Überwachungsdaten, die die Erkennung von Anomalien und Vorfällen beeinträchtigt.
|
||||
**Potenzielle Auswirkungen**: Störung des Flusses von Überwachungsdaten, was die Erkennung von Anomalien und Vorfällen beeinträchtigt.
|
||||
|
||||
### **`cloudwatch:TagResource`, `cloudwatch:UntagResource`**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user