Modes de chiffrement et application en transit

Sécurité AWS pour les développeurs

Rahul Singh

Technical Product Manager

Deux garanties, un défaut

Une application envoie un objet vers un compartiment Amazon S3. Une accolade verte « in transit » couvre le saut réseau, et une seconde « at rest » couvre l'objet stocké, avec une note indiquant que SSE-S3 s'applique sauf indication contraire dans la requête.

Au repos : les octets sur disque
En transit : les octets sur le réseau

Deux garanties, un défaut

Au repos : les octets sur disque
En transit : les octets sur le réseau
Déjà fait : SSE-S3 sur chaque nouvel objet
À vous : le mode et qui détient la clé, décidez

Où s'arrête le texte en clair

Côté serveur

AWS reçoit des octets en clair
S3 chiffre à l'écriture

Un flux côté serveur. Votre processus détient le texte en clair, l'envoie via TLS, et Amazon S3 chiffre à l'écriture. Une barre dessous suit les octets, séparée par un trait pointillé à S3 : avant, « vos octets : lisibles ici » en rouge ; après, « ciphertext » en vert.

Où s'arrête le texte en clair

Côté serveur

AWS reçoit des octets en clair
S3 chiffre à l'écriture

Côté client

Vous chiffrez avant l'envoi
AWS ne stocke que du ciphertext

Un flux côté client. Votre processus chiffre d'abord, envoie le ciphertext via TLS, et Amazon S3 stocke ce qu'il reçoit. Une barre dessous suit les octets, séparée par un trait pointillé dans votre processus : le court segment avant indique « vos octets : lisibles ici » en rouge, tout le reste « ciphertext » en vert.

Quatre modes, une différence

Même algorithme, quatre détenteurs de clé

Le mode passe en en-tête du PUT
SSE-S3 : clé AWS, rien à gérer
SSE-KMS : votre clé, CloudTrail, et une stratégie de clé attachée à la clé indiquant qui peut l'utiliser

Quatre cartes empilées : SSE-S3, SSE-KMS, DSSE-KMS et SSE-C. Un rail à gauche va du contrôle AWS en haut à votre contrôle en bas, et chaque carte n'affiche que la valeur d'en-tête de requête qui sélectionne ce mode.

Quatre modes, une différence

Même algorithme, quatre détenteurs de clé

Le mode passe en en-tête du PUT
SSE-S3 : clé AWS, rien à gérer
SSE-KMS : votre clé, CloudTrail, et une stratégie de clé attachée à la clé indiquant qui peut l'utiliser
DSSE-KMS : deux couches indépendantes
SSE-C : votre clé à chaque requête, à vos risques

L'objection de coût à SSE-KMS

Deux lignes. Sans Bucket Keys, six flèches vont d'Amazon S3 vers AWS KMS, une par requête d'objet. Avec Bucket Keys, une seule flèche part d'une clé au niveau du compartiment, détenue dans S3. Note : Bucket Keys indisponible avec DSSE-KMS.

Sans : un appel KMS par objet
Avec Bucket Keys : une clé de courte durée, réutilisée
Non disponible avec DSSE-KMS
Jusqu'à 99% d'appels KMS en moins

Chiffrez le champ, pas la table

Au repos est déjà activé

Une requête renvoie le clair à toute personne ayant accès en lecture

Un élément DynamoDB avec cinq attributs. Deux attributs contiennent du ciphertext avec des rails bleus, tandis que la clé de partition, la clé de tri et l'horodatage restent en clair. Une boîte verte indique que toute la table est chiffrée au repos.

Chiffrez le champ, pas la table

Au repos est déjà activé

Une requête renvoie le clair à toute personne ayant accès en lecture

AWS Database Encryption SDK

Chiffrez des attributs choisis dans votre code
Les clés de partition et de tri, utilisées par DynamoDB pour retrouver les éléments, restent en clair car il les indexe

TLS est proposé, pas exigé

Proposé, pas imposé

S3 répond en HTTP et HTTPS indifféremment

Deux scénarios. Sans condition sur le compartiment, un client HTTPS et un client HTTP accèdent à l'objet. Avec la règle de refus, le chemin HTTP s'arrête sur une croix rouge et n'établit pas la connexion.

TLS est proposé, pas exigé

Proposé, pas imposé

S3 répond en HTTP et HTTPS indifféremment

En faire une exigence

Stratégie de compartiment : refuser si aws:SecureTransport est false
Les clients légitimes ne remarquent rien

Quelle autorité atteste le nom

Nom public

ACM : approuvé publiquement, gratuit, renouvelle tout seul

Nom résolu uniquement par votre réseau

AWS Private CA : votre autorité de certification
Jamais approuvée sur l'internet public

Deux cartes empilées indiquant qui peut émettre le certificat. La carte du haut, nom public, donne reports point example point com comme nom résolu et ACM comme émetteur, approuvé partout. La carte du bas, nom interne, donne admin point example point internal, résolu uniquement dans votre VPC, et AWS Private CA comme émetteur.

La moitié privée est à vous de perdre

Qui le détient

ACM : AWS le conserve
Paire de clés EC2, ou toute clé SSH : vous détenez la partie privée, unique

Deux cartes empilées « qui détient quelle moitié ». La carte du haut, moitié publique, indique qu'elle vit sur AWS ou l'instance. La carte orange du bas, moitié privée, précise : vous n'en avez qu'une copie, à garder dans Secrets Manager (coché vert), et jamais dans un dépôt, un ordinateur portable ou une messagerie (croix orange).

La moitié privée est à vous de perdre

Qui le détient

ACM : AWS le conserve
Paire de clés EC2, ou toute clé SSH : vous détenez la partie privée, unique

Si c'est le vôtre

Secrets Manager, pas un dépôt
Remplacez selon un calendrier

Trois réponses, pas une

Trois cartes numérotées pour le mode, le contrôle de clé et le transit, chacune montrant l'en-tête ou la clé de condition correspondante. Une ligne dessous note que seul le troisième contrôle vit hors des réglages de chiffrement.

Mode : ce qui a écrit l'objet
Contrôle de clé : qui peut le déchiffrer, dans ce compte ou un autre
Transit : exigé ou seulement proposé

Passons à la pratique !

Sécurité AWS pour les développeurs