gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-03-12 21:22:57 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-services/aws-s3-a

Browse Source
This commit is contained in:
Translator
2026-02-12 13:06:24 +00:00
parent 9572ad64e7
commit 3b8c386f3a
1 changed files with 61 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files

122
src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md
View File

@@ -4,36 +4,36 @@
## S3
Amazon S3 ist ein Dienst, der es Ihnen ermöglicht, **große Mengen an Daten zu speichern**.
Amazon S3 ist ein Dienst, der es dir ermöglicht, **große Mengen an Daten zu speichern**.
Amazon S3 bietet mehrere Optionen, um den **Schutz** von Daten im Ruhezustand zu gewährleisten. Die Optionen umfassen **Berechtigungen** (Richtlinie), **Verschlüsselung** (Client- und Server-seitig), **Bucket-Versionierung** und **MFA** **basierte Löschung**. Der **Benutzer kann** eine dieser Optionen aktivieren, um den Datenschutz zu erreichen. **Datenreplikation** ist eine interne Funktion von AWS, bei der **S3 automatisch jedes Objekt über alle Verfügbarkeitszonen repliziert** und die Organisation es in diesem Fall nicht aktivieren muss.
Amazon S3 bietet mehrere Optionen, um den **Schutz** von Daten at REST zu gewährleisten. Zu den Optionen gehören **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** und **MFA** **based delete**. Der **Benutzer kann** jede dieser Optionen aktivieren, um den Datenschutz zu erreichen. **Data replication** ist eine interne Funktion von AWS, bei der **S3 repliziert automatisch jedes Objekt über alle Availability Zones hinweg** und die Organisation muss sie in diesem Fall nicht aktivieren.
Mit ressourcenbasierten Berechtigungen können Sie Berechtigungen für Unterverzeichnisse Ihres Buckets separat definieren.
Mit ressourcenbasierten Berechtigungen kannst du Berechtigungen für Unterverzeichnisse deines Buckets separat definieren.
### Bucket-Versionierung und MFA-basierte Löschung
### Bucket Versioning und MFA based delete
Wenn die Bucket-Versionierung aktiviert ist, erzeugt jede Aktion, die versucht, eine Datei innerhalb einer Datei zu ändern, eine neue Version der Datei und behält auch den vorherigen Inhalt bei. Daher wird der Inhalt nicht überschrieben.
Wenn Bucket Versioning aktiviert ist, erzeugt jede Aktion, die versucht, eine Datei zu ändern, eine neue Version der Datei und behält auch den vorherigen Inhalt derselben. Daher wird der Inhalt nicht überschrieben.
Darüber hinaus verhindert die MFA-basierte Löschung, dass Versionen von Dateien im S3-Bucket gelöscht werden und auch, dass die Bucket-Versionierung deaktiviert wird, sodass ein Angreifer diese Dateien nicht ändern kann.
Außerdem verhindert MFA based delete, dass Versionen von Dateien im S3 bucket gelöscht werden, und dass Bucket Versioning deaktiviert wird, sodass ein Angreifer diese Dateien nicht verändern kann.
### S3-Zugriffsprotokolle
### S3 Access logs
Es ist möglich, das **S3-Zugriffsprotokoll** (das standardmäßig deaktiviert ist) für einen Bucket zu aktivieren und die Protokolle in einem anderen Bucket zu speichern, um zu erfahren, wer auf den Bucket zugreift (beide Buckets müssen sich in derselben Region befinden).
Es ist möglich, **S3 access login** zu aktivieren (was standardmäßig deaktiviert ist) für einen Bucket und die Logs in einem anderen Bucket zu speichern, um zu wissen, wer auf den Bucket zugreift (beide Buckets müssen in derselben Region sein).
### S3-Vorgenehmigte URLs
### S3 Presigned URLs
Es ist möglich, eine vorgenehmigte URL zu generieren, die normalerweise verwendet werden kann, um **auf die angegebene Datei** im Bucket zuzugreifen. Eine **vorgenehmigte URL sieht so aus**:
Es ist möglich, eine presigned URL zu generieren, die üblicherweise verwendet werden kann, um **auf die angegebene Datei** im Bucket zuzugreifen. Eine **presigned URL sieht so aus**:
```
https://<bucket-name>.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa
```
Eine vorab signierte URL kann **über die CLI mit den Anmeldeinformationen eines Benutzers erstellt werden, der Zugriff auf das Objekt hat** (wenn das von Ihnen verwendete Konto keinen Zugriff hat, wird eine kürzere vorab signierte URL erstellt, die jedoch nutzlos sein wird).
Eine presigned URL kann **über die cli mit den credentials eines principal, der Zugriff auf das Objekt hat, erstellt werden** (wenn der account, den Sie verwenden, keinen Zugriff hat, wird eine kürzere presigned URL erstellt, die jedoch nutzlos ist).
```bash
aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
```
> [!NOTE]
> Die einzige erforderliche Berechtigung zum Generieren einer vorab signierten URL ist die erteilte Berechtigung. Für den vorherigen Befehl ist die einzige Berechtigung, die der Principal benötigt, `s3:GetObject`.
> Die einzige erforderliche permission, um eine presigned URL zu erzeugen, ist die permission, die vergeben wird — für den vorherigen Befehl benötigt der principal also nur `s3:GetObject`
Es ist auch möglich, vorab signierte URLs mit **anderen Berechtigungen** zu erstellen:
Es ist auch möglich, presigned URLs mit **other permissions** zu erstellen:
```python
import boto3
url = boto3.client('s3').generate_presigned_url(
@@ -42,22 +42,22 @@ Params={'Bucket': 'BUCKET_NAME', 'Key': 'OBJECT_KEY'},
ExpiresIn=3600
)
```
### S3 Verschlüsselungsmechanismen
### S3-Verschlüsselungsmechanismen
**DEK bedeutet Datenverschlüsselungsschlüssel** und ist der Schlüssel, der immer generiert wird und zur Verschlüsselung von Daten verwendet wird.
**DEK steht für Data Encryption Key** und ist der Schlüssel, der stets erzeugt und verwendet wird, um Daten zu verschlüsseln.
<details>
<summary><strong>Server-seitige Verschlüsselung mit von S3 verwalteten Schlüsseln, SSE-S3</strong></summary>
<summary><strong>Serverseitige Verschlüsselung mit S3 managed keys, SSE-S3</strong></summary>
Diese Option erfordert minimale Konfiguration und die gesamte Verwaltung der verwendeten Verschlüsselungsschlüssel wird von AWS verwaltet. Alles, was Sie tun müssen, ist **Ihre Daten hochzuladen und S3 kümmert sich um alle anderen Aspekte**. Jeder Bucket in einem S3-Konto erhält einen Bucket-Schlüssel.
Diese Option erfordert minimale Konfiguration und alle Aufgaben der Schlüsselverwaltung werden von AWS übernommen. Alles, was Sie tun müssen, ist, **Ihre Daten hochzuladen und S3 kümmert sich um alle weiteren Aspekte**. Jedem Bucket in einem S3-Konto wird ein Bucket key zugewiesen.
- Verschlüsselung:
- Objekt Daten + erstellter Klartext DEK --> Verschlüsselte Daten (in S3 gespeichert)
- Erstellter Klartext DEK + S3 Master Key --> Verschlüsselter DEK (in S3 gespeichert) und der Klartext wird aus dem Speicher gelöscht
- Object Data + erzeugter plaintext DEK --> Verschlüsselte Daten (in S3 gespeichert)
- Erzeugter plaintext DEK + S3 Master Key --> Verschlüsselter DEK (in S3 gespeichert) und der Plaintext wird aus dem Speicher gelöscht
- Entschlüsselung:
- Verschlüsselter DEK + S3 Master Key --> Klartext DEK
- Klartext DEK + Verschlüsselte Daten --> Objekt Daten
- Verschlüsselter DEK + S3 Master Key --> Plaintext DEK
- Plaintext DEK + verschlüsselte Daten --> Object Data
Bitte beachten Sie, dass in diesem Fall **der Schlüssel von AWS verwaltet wird** (Rotation nur alle 3 Jahre). Wenn Sie Ihren eigenen Schlüssel verwenden, können Sie rotieren, deaktivieren und Zugriffskontrollen anwenden.
@@ -65,76 +65,76 @@ Bitte beachten Sie, dass in diesem Fall **der Schlüssel von AWS verwaltet wird*
<details>
<summary><strong>Server-seitige Verschlüsselung mit KMS verwalteten Schlüsseln, SSE-KMS</strong></summary>
<summary><strong>Serverseitige Verschlüsselung mit KMS managed keys, SSE-KMS</strong></summary>
Diese Methode ermöglicht es S3, den Schlüsselverwaltungsdienst zu nutzen, um Ihre Datenverschlüsselungsschlüssel zu generieren. KMS bietet Ihnen eine viel größere Flexibilität, wie Ihre Schlüssel verwaltet werden. Zum Beispiel können Sie die CMK deaktivieren, rotieren und Zugriffskontrollen anwenden sowie deren Nutzung über AWS Cloud Trail überwachen.
Diese Methode ermöglicht es S3, den Key Management Service zu verwenden, um Ihre Data Encryption Keys zu erzeugen. KMS bietet Ihnen deutlich mehr Flexibilität bei der Verwaltung Ihrer Schlüssel. Zum Beispiel können Sie einen CMK deaktivieren, rotieren und Zugriffskontrollen auf den CMK anwenden sowie deren Nutzung mittels AWS Cloud Trail nachverfolgen.
- Verschlüsselung:
- S3 fordert Datenkeys von KMS CMK an
- KMS verwendet eine CMK, um das Paar DEK Klartext und DEK verschlüsselt zu generieren und sendet sie an S3
- S3 verwendet den Klartextschlüssel, um die Daten zu verschlüsseln, speichert die verschlüsselten Daten und den verschlüsselten Schlüssel und löscht den Klartextschlüssel aus dem Speicher
- S3 fordert Data Keys vom KMS CMK an
- KMS verwendet einen CMK, um das Paar plaintext DEK und verschlüsselten DEK zu erzeugen und sendet sie an S£
- S3 verwendet den plaintext key, um die Daten zu verschlüsseln, speichert die verschlüsselten Daten und den verschlüsselten Key und löscht den plaintext Key aus dem Speicher
- Entschlüsselung:
- S3 fragt KMS, um den verschlüsselten Datenkey des Objekts zu entschlüsseln
- KMS entschlüsselt den Datenkey mit der CMK und sendet ihn an S3 zurück
- S3 fordert KMS auf, den verschlüsselten Data Key des Objekts zu entschlüsseln
- KMS entschlüsselt den Data Key mit dem CMK und sendet ihn an S3 zurück
- S3 entschlüsselt die Objektdaten
</details>
<details>
<summary><strong>Server-seitige Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln, SSE-C</strong></summary>
<summary><strong>Serverseitige Verschlüsselung mit kundenbereitgestellten Schlüsseln, SSE-C</strong></summary>
Diese Option gibt Ihnen die Möglichkeit, Ihren eigenen Master-Schlüssel bereitzustellen, den Sie möglicherweise bereits außerhalb von AWS verwenden. Ihr vom Kunden bereitgestellter Schlüssel würde dann mit Ihren Daten an S3 gesendet, wo S3 die Verschlüsselung für Sie durchführt.
Diese Option gibt Ihnen die Möglichkeit, Ihren eigenen Master Key zu verwenden, den Sie möglicherweise bereits außerhalb von AWS nutzen. Ihr customer-provided key würde zusammen mit Ihren Daten an S3 gesendet, wo S3 dann die Verschlüsselung für Sie durchführt.
- Verschlüsselung:
- Der Benutzer sendet die Objektdaten + Kunden-Schlüssel an S3
- Der Kunden-Schlüssel wird verwendet, um die Daten zu verschlüsseln, und die verschlüsselten Daten werden gespeichert
- Ein gesalzener HMAC-Wert des Kunden-Schlüssels wird ebenfalls für zukünftige Schlüsselvalidierung gespeichert
- Der Kunden-Schlüssel wird aus dem Speicher gelöscht
- Der Nutzer sendet die Objektdaten + Customer key an S3
- Der Customer key wird verwendet, um die Daten zu verschlüsseln und die verschlüsselten Daten werden gespeichert
- Ein gesalzener HMAC-Wert des Customer key wird ebenfalls zur späteren Schlüsselvalidierung gespeichert
- Der Customer key wird aus dem Speicher gelöscht
- Entschlüsselung:
- Der Benutzer sendet den Kunden-Schlüssel
- Der Nutzer sendet den Customer key
- Der Schlüssel wird gegen den gespeicherten HMAC-Wert validiert
- Der vom Kunden bereitgestellte Schlüssel wird dann verwendet, um die Daten zu entschlüsseln
- Der customer-provided key wird dann verwendet, um die Daten zu entschlüsseln
</details>
<details>
<summary><strong>Client-seitige Verschlüsselung mit KMS, CSE-KMS</strong></summary>
<summary><strong>Clientseitige Verschlüsselung mit KMS, CSE-KMS</strong></summary>
Ähnlich wie bei SSE-KMS verwendet dies ebenfalls den Schlüsselverwaltungsdienst, um Ihre Datenverschlüsselungsschlüssel zu generieren. Diesmal wird KMS jedoch über den Client und nicht über S3 aufgerufen. Die Verschlüsselung erfolgt dann clientseitig und die verschlüsselten Daten werden an S3 gesendet, um gespeichert zu werden.
Ähnlich wie bei SSE-KMS nutzt dies ebenfalls den Key Management Service, um Ihre Data Encryption Keys zu erzeugen. Allerdings wird KMS hier vom Client und nicht von S3 aufgerufen. Die Verschlüsselung findet clientseitig statt und die verschlüsselten Daten werden anschließend zur Speicherung an S3 gesendet.
- Verschlüsselung:
- Client fordert einen Datenkey von KMS an
- KMS gibt den Klartext DEK und den verschlüsselten DEK mit der CMK zurück
- Beide Schlüssel werden zurückgesendet
- Der Client verschlüsselt dann die Daten mit dem Klartext DEK und sendet die verschlüsselten Daten + den verschlüsselten DEK (der als Metadaten der verschlüsselten Daten in S3 gespeichert wird) an S3
- Der Client fordert einen Data Key bei KMS an
- KMS liefert den plaintext DEK und den mit dem CMK verschlüsselten DEK zurück
- Beide Keys werden zurückgegeben
- Der Client verschlüsselt dann die Daten mit dem plaintext DEK und sendet an S3 die verschlüsselten Daten + den verschlüsselten DEK (welcher als Metadaten der verschlüsselten Daten in S3 gespeichert wird)
- Entschlüsselung:
- Die verschlüsselten Daten mit dem verschlüsselten DEK werden an den Client gesendet
- Der Client fragt KMS, um den verschlüsselten Schlüssel mit der CMK zu entschlüsseln, und KMS sendet den Klartext DEK zurück
- Der Client bittet KMS, den verschlüsselten Key mit dem CMK zu entschlüsseln, und KMS sendet den plaintext DEK zurück
- Der Client kann nun die verschlüsselten Daten entschlüsseln
</details>
<details>
<summary><strong>Client-seitige Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln, CSE-C</strong></summary>
<summary><strong>Clientseitige Verschlüsselung mit kundenbereitgestellten Schlüsseln, CSE-C</strong></summary>
Mit diesem Mechanismus können Sie Ihre eigenen bereitgestellten Schlüssel nutzen und einen AWS-SDK-Client verwenden, um Ihre Daten zu verschlüsseln, bevor Sie sie zur Speicherung an S3 senden.
Mit diesem Mechanismus können Sie Ihre eigenen bereitgestellten Schlüssel verwenden und einen AWS-SDK-Client nutzen, um Ihre Daten vor dem Senden an S3 zu verschlüsseln.
- Verschlüsselung:
- Der Client generiert einen DEK und verschlüsselt die Klartextdaten
- Dann verschlüsselt er den DEK mit seiner eigenen benutzerdefinierten CMK
- Reicht die verschlüsselten Daten + verschlüsselten DEK an S3 ein, wo sie gespeichert werden
- Der Client erzeugt einen DEK und verschlüsselt die plaintext Daten
- Dann verschlüsselt er den DEK mit seinem eigenen CMK
- Sendet die verschlüsselten Daten + den verschlüsselten DEK an S3, wo beides gespeichert wird
- Entschlüsselung:
- S3 sendet die verschlüsselten Daten und DEK
- Da der Client bereits die CMK hat, die zur Verschlüsselung des DEK verwendet wurde, entschlüsselt er den DEK und verwendet dann den Klartext DEK, um die Daten zu entschlüsseln
- S3 sendet die verschlüsselten Daten und den DEK
- Da der Client bereits den CMK besitzt, mit dem der DEK verschlüsselt wurde, entschlüsselt er den DEK und verwendet dann den plaintext DEK, um die Daten zu entschlüsseln
</details>
### **Enumeration**
Eine der traditionellen Hauptmethoden zur Kompromittierung von AWS-Organisationen beginnt mit der Kompromittierung von öffentlich zugänglichen Buckets. **Sie können** [**öffentliche Bucket-Enumeratoren auf dieser Seite finden**](../aws-unauthenticated-enum-access/#s3-buckets)**.**
One of the traditional main ways of compromising AWS orgs start by compromising buckets publicly accesible. **Sie finden** [**öffentliche Bucket-Enumeratoren auf dieser Seite**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
```bash
# Get buckets ACLs
aws s3api get-bucket-acl --bucket <bucket-name>
@@ -229,16 +229,16 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
```
### dual-stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
Sie können auf einen S3-Bucket über einen Dual-Stack-Endpunkt zugreifen, indem Sie einen virtual hosted-style oder einen path-style Endpunktnamen verwenden. Diese sind nützlich, um S3 über IPv6 zuzugreifen.
Sie können auf einen S3-Bucket über einen dual-stack Endpoint zugreifen, indem Sie einen virtual hosted-style oder einen path-style Endpoint-Namen verwenden. Diese sind nützlich, um S3 über IPv6 zu erreichen.
Dual-Stack-Endpunkte verwenden die folgende Syntax:
Dual-stack endpoints use the following syntax:
- `bucketname.s3.dualstack.aws-region.amazonaws.com`
- `s3.dualstack.aws-region.amazonaws.com/bucketname`
### Privesc
Auf der folgenden Seite können Sie überprüfen, wie man **S3-Berechtigungen missbrauchen kann, um Privilegien zu eskalieren**:
Auf der folgenden Seite können Sie nachlesen, wie man **S3 permissions missbrauchen kann, um Privilegien zu eskalieren**:
{{#ref}}
../aws-privilege-escalation/aws-s3-privesc/README.md
@@ -266,19 +266,19 @@ Auf der folgenden Seite können Sie überprüfen, wie man **S3-Berechtigungen mi
### S3 HTTP Cache Poisoning Issue <a href="#heading-s3-http-desync-cache-poisoning-issue" id="heading-s3-http-desync-cache-poisoning-issue"></a>
[**Laut dieser Forschung**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) war es möglich, die Antwort eines beliebigen Buckets zu cachen, als ob sie zu einem anderen gehörte. Dies hätte missbraucht werden können, um beispielsweise die Antworten von Javascript-Dateien zu ändern und beliebige Seiten zu kompromittieren, die S3 zur Speicherung von statischem Code verwenden.
[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) war es möglich, die Antwort eines beliebigen Buckets zu cachen, als würde sie zu einem anderen gehören. Dies hätte missbraucht werden können, um z. B. JavaScript-Datei-Antworten zu verändern und beliebige Seiten zu kompromittieren, die S3 zum Speichern statischen Codes verwenden.
## Amazon Athena
Amazon Athena ist ein interaktiver Abfrageservice, der es einfach macht, **Daten** direkt im Amazon Simple Storage Service (Amazon **S3**) **unter Verwendung von** standardmäßigen **SQL** zu **analysieren**.
Amazon Athena ist ein interaktiver Abfragedienst, der es ermöglicht, **Daten** direkt in Amazon Simple Storage Service (Amazon **S3**) **mithilfe** von Standard-**SQL** zu **analysieren**.
Sie müssen eine **relationale DB-Tabelle** mit dem Format des Inhalts vorbereiten, der in den überwachten S3-Buckets erscheinen wird. Anschließend kann Amazon Athena die DB aus den Protokollen befüllen, sodass Sie Abfragen durchführen können.
Sie müssen eine **relational DB table** mit dem Format des Inhalts vorbereiten, der in den überwachten S3-Buckets erscheinen wird. Anschließend kann Amazon Athena die DB aus den Logs befüllen, sodass Sie Abfragen ausführen können.
Amazon Athena unterstützt die **Möglichkeit, S3-Daten abzufragen, die bereits verschlüsselt sind**, und wenn es so konfiguriert ist, **kann Athena auch die Ergebnisse der Abfrage verschlüsseln, die dann in S3 gespeichert werden können**.
Amazon Athena unterstützt die **Ability to query S3 data that is already encrypted** und wenn entsprechend konfiguriert, **kann Athena auch die Ergebnisse der Abfrage verschlüsseln, die dann in S3 gespeichert werden können**.
**Diese Verschlüsselung der Ergebnisse ist unabhängig von den zugrunde liegenden abgefragten S3-Daten**, was bedeutet, dass selbst wenn die S3-Daten nicht verschlüsselt sind, die abgefragten Ergebnisse verschlüsselt werden können. Ein paar Punkte, die zu beachten sind, sind, dass Amazon Athena nur Daten unterstützt, die mit den **folgenden S3-Verschlüsselungsmethoden** **verschlüsselt** wurden, **SSE-S3, SSE-KMS und CSE-KMS**.
**Diese Verschlüsselung der Ergebnisse ist unabhängig von den zugrunde liegenden abgefragten S3-Daten**, was bedeutet, dass selbst wenn die S3-Daten nicht verschlüsselt sind, die abgefragten Ergebnisse verschlüsselt werden können. Einige Punkte, die zu beachten sind: Amazon Athena unterstützt nur Daten, die mit den **folgenden S3 encryption methods**, **SSE-S3, SSE-KMS, and CSE-KMS** verschlüsselt wurden.
SSE-C und CSE-E werden nicht unterstützt. Darüber hinaus ist es wichtig zu verstehen, dass Amazon Athena nur Abfragen gegen **verschlüsselte Objekte ausführen wird, die sich in derselben Region wie die Abfrage selbst befinden**. Wenn Sie S3-Daten abfragen müssen, die mit KMS verschlüsselt wurden, sind spezifische Berechtigungen für den Athena-Benutzer erforderlich, um die Abfrage durchzuführen.
SSE-C and CSE-C are not supported. Zusätzlich ist es wichtig zu verstehen, dass Amazon Athena Abfragen nur gegen **verschlüsselte Objekte ausführen wird, die sich in derselben Region wie die Abfrage befinden**. Wenn Sie S3-Daten abfragen müssen, die mit KMS verschlüsselt wurden, sind spezielle Berechtigungen für den Athena-Benutzer erforderlich, damit er die Abfrage durchführen kann.
### Enumeration
```bash
@@ -302,7 +302,7 @@ aws athena get-prepared-statement --statement-name <name> --work-group <wg-name>
# Run query
aws athena start-query-execution --query-string <query>
```
## Referenzen
## References
- [https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3](https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3)
- [https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html)