SES
La configuration d'une règle SES permet de placer l'email dans un bucket S3. Dans cette configuration, l'option "KMS Key" est disponible, ce qui permet à SES de crypter l'e-mail. avant l'envoi/le dépôt dans le seau. Plus précisément, il s'agit d'utiliser le cryptage côté client (CSE) et non le cryptage côté serveur (SSE).
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email-action-s3.html
S3
Il est également possible de configurer les propriétés d'un bac S3 pour crypter les objets lorsqu'ils sont téléchargés. (SSE)
Contexte
- le seau n'est accessible que par le code (notre système et/ou AWS Lambda), c'est-à-dire qu'il n'y aura pas besoin de séparer différents utilisateurs/rôles/etc
Question
-
Pourquoi utiliser
- Action SES S3 avec cryptage CSE activé + cryptage S3 SSE désactivé au lieu de
- Action SES S3 avec cryptage CSE DISABLED + cryptage S3 SSE ENABLED
(Je ne suis pas tellement préoccupé par le cryptage SES + S3)
- Cela a-t-il un rapport avec le transit du contenu de l'e-mail entre SES et S3 ? En quoi cela peut-il constituer un risque, ce transfert n'est-il pas interne à AWS ?
Note d'accompagnement
- Création d'un seau et activation du cryptage.
- Ajoutez une stratégie SESPut bucket pour autoriser SES. https://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email-permissions.html
- Je configure la règle SES S3 pour mettre les emails dans le seau en question, mais lors de la sauvegarde, j'obtiens une erreur : "Could not write to bucket"
- Modifier le seau, supprimer le cryptage
- L'enregistrement de la règle SES réussit maintenant.
Cela pourrait simplement signifier qu'une autre politique est nécessaire quelque part, ou est-ce qu'il y a quelque chose qui m'échappe à propos du cryptage AWS et qui explique pourquoi les étapes ci-dessus ont échoué et pourquoi SES a le cryptage côté client comme option ?
(J'ai posé cette question dans un autre document : AWS SES - Échec de la règle S3 permettant d'écrire dans un seau avec cryptage du seau )
