# 06. S3 Encryption

#### **1. Chiffrement au repos**

Le dilemme à l'examen repose toujours sur deux critères : **Qui gère la clé ?** et **Où se fait le chiffrement ?**

##### **A. Server-Side Encryption (SSE) : AWS chiffre pour vous**

Les données arrivent brutes chez AWS, et c'est S3 qui s'occupe de les chiffrer avant de les écrire sur le disque.

- **SSE-S3 (Chiffrement géré par S3)**
    - **Le concept :** AWS gère tout. La clé est créée, stockée et gérée automatiquement par AWS.
    - **Algorithme :** AES-256.
    - **Pourquoi ?** C'est la solution par défaut (gratuite et zéro gestion).
    - **Ce qu'il faut savoir pour l'examen :** Depuis 2023, **SSE-S3 est activé par défaut** sur tous les nouveaux buckets S3. Si vous n'en spécifiez aucun, c'est celui-là qui s'applique.
    - **Header HTTP à l'upload :** `"x-amz-server-side-encryption": "AES256"`

- **SSE-KMS (Chiffrement via AWS KMS)**
    
    
    - **Le concept :** Vous utilisez le service AWS Key Management Service (KMS) pour gérer les clés. Vous pouvez utiliser la clé AWS par défaut (`aws/s3`) ou créer votre propre clé personnalisée (Customer Managed Key).
    - **Pourquoi ?** Pour avoir un **contrôle d'accès strict** (qui a le droit d'utiliser la clé) et un **suivi d'audit (CloudTrail)** complet de chaque chiffrement/déchiffrement.
    - **Ce qu'il faut savoir pour l'examen :** Génère des coûts (appels API KMS).
        
        
        - Attention aux quotas de requêtes KMS en cas de fort trafic.
        - Pour déchiffrer un objet, l'utilisateur a besoin de la permission S3 **ET** de la permission `kms:Decrypt`.
    - **Header HTTP à l'upload :** `"x-amz-server-side-encryption": "aws:kms"`

- **SSE-C (Chiffrement avec clés fournies par le client)**
- - **Le concept :** Vous possédez et gérez la clé secrète, mais vous la passez à S3 dans la requête HTTPS pour qu'AWS fasse le travail de chiffrement. **AWS ne stocke jamais votre clé**. Une fois l'opération finie, AWS jette la clé de sa mémoire vive.
    - **Pourquoi ?** Pour les entreprises qui ont des obligations de conformité strictes interdisant de confier la gestion des clés à un tiers (même AWS).
    - **Ce qu'il faut savoir pour l'examen :** Si vous perdez la clé, vos données sont perdues à jamais. AWS a récemment renforcé la sécurité en désactivant le support SSE-C par défaut sur les nouveaux buckets (il faut l'autoriser explicitement via l'API si besoin).
    - **Header HTTP :** Vous devez envoyer la clé dans chaque requête HTTP (`x-amz-server-side-encryption-customer-key`).

##### **B. Client-Side Encryption : Vous chiffrez avant d'envoyer**

- **Le concept :** Vos données sont chiffrées **au sein même de votre application** (par exemple avec le SDK AWS / S3 Encryption Client) avant de franchir le réseau. AWS reçoit un fichier qui est déjà un bloc illisible.
- **Pourquoi ?** Sécurité maximale "End-to-End". AWS n'a aucun moyen de voir ce qu'il y a dans votre fichier, même s'ils le voulaient.

#### **2. Chiffrement en transit (Encryption in Transit)**

Le chiffrement en transit garantit que personne ne peut intercepter vos données entre votre client et les serveurs d'AWS.

- **Le comment :** S3 supporte nativement les protocoles **HTTP** et **HTTPS (TLS)**.
- **Pour l'examen (Piège classique) :** Comment forcer le chiffrement en transit ? On utilise une **Bucket Policy** avec une condition explicite qui rejette (`Deny`) toutes les connexions non sécurisées.

Voici à quoi ressemble la règle absolue à connaître pour le SAA-C03 :

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceHTTPS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::mon-bucket-examen",
        "arn:aws:s3:::mon-bucket-examen/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}
```

Comme `aws:SecureTransport` est `false` (donc du HTTP classique), l'accès est bloqué (`Deny`).