Object Storage - Chiffrez vos objets côté serveur avec SSE-C ou SSE-OMK

Voir en Markdown

Découvrez comment chiffrer vos objets Object Storage au repos avec des clés gérées par le client (SSE-C) ou par OVHcloud (SSE-OMK)

Objectif

L'Object Storage OVHcloud compatible S3¹ propose deux méthodes de chiffrement côté serveur (SSE) pour protéger vos objets au repos :

SSE-C (Server-Side Encryption with Customer Keys) : vous fournissez une clé AES 256 bits à chaque requête. Vous conservez le contrôle total des clés, mais vous êtes responsable de leur stockage et de leur rotation.
SSE-OMK (Server-Side Encryption with OVHcloud-Managed Keys) : OVHcloud génère et gère automatiquement une clé de chiffrement unique par objet. Aucune gestion de clés n'est requise.
Une troisième option, le chiffrement côté client (CSE), vous permet de chiffrer vos données avant de les envoyer vers Object Storage. Ce guide inclut le CSE dans le tableau comparatif ci-dessous, mais n'en couvre pas la mise en œuvre en détail.

Ce guide explique comment chiffrer vos objets côté serveur avec SSE-C ou SSE-OMK.

Warning

Object Storage ne stocke pas votre clé de chiffrement SSE-C. En cas de perte, l'objet chiffré ne peut pas être récupéré — la seule option est de le supprimer.

Choisir une méthode

	CSE	SSE-C	SSE-OMK
Qui gère les clés	Vous (côté client)	Vous (par requête)	OVHcloud
Contrôle des clés	Total	Total	Aucun
Charge de gestion	Élevée	Moyenne	Aucune
Téléchargement transparent	Non	Non	Oui
Coût supplémentaire	Aucun	Aucun	Aucun

Utilisez SSE-C lorsque vos exigences de conformité ou d'audit imposent un contrôle exclusif des clés. Utilisez SSE-OMK pour un chiffrement transparent sans gestion de clés.

Prérequis

Avoir créé un bucket Object Storage
Avoir créé un utilisateur et avoir défini les droits d'accès requis sur le bucket
Avoir installé et configuré l'AWS CLI

Consultez notre guide « Débuter avec Object Storage » pour plus de détails.

Accès à l'espace client OVHcloud

Lien direct :
Pour accéder à vos services : Public Cloud > Sélectionnez votre projet

En pratique

SSE-C — Chiffrement côté serveur avec clés client

Lorsque vous envoyez un objet avec SSE-C, Object Storage applique le chiffrement AES-256 en utilisant la clé que vous fournissez. Pour récupérer l'objet, vous devez fournir la même clé — Object Storage la vérifie avant de déchiffrer.

Chaque requête nécessite trois en-têtes :

En-tête	Description
`--sse-customer-algorithm`	Algorithme de chiffrement. Doit être `AES256`.
`--sse-customer-key`	Clé de chiffrement de 256 bits (32 octets) encodée en Base64.
`--sse-customer-key-md5`	Condensat MD5 128 bits de la clé brute encodé en Base64 (vérification d'intégrité selon la RFC 1321).

Création d'une clé de chiffrement

secret=$(openssl rand 32)
encKey=$(echo -n "$secret" | base64)
md5Key=$(echo -n "$secret" | openssl dgst -md5 -binary | base64)

Envoi d'un objet

aws s3api put-object \
  --body <file_path> \
  --bucket <bucket_name> \
  --key <object_key> \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "$encKey" \
  --sse-customer-key-md5 "$md5Key"

Téléchargement d'un objet

aws s3api get-object \
  --bucket <bucket_name> \
  --key <object_key> \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "$encKey" \
  --sse-customer-key-md5 "$md5Key" \
  <destination_file_path>

En l'absence des en-têtes de chiffrement, vous obtiendrez une erreur 400 Bad Request.

Obtention des métadonnées d'un objet

aws s3api head-object \
  --bucket <bucket_name> \
  --key <object_key> \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "$encKey" \
  --sse-customer-key-md5 "$md5Key"

Exemple de sortie :

{
    "LastModified": "Tue, 19 Apr 2022 09:38:47 GMT",
    "ContentLength": 111,
    "ETag": "\"272913026300e7ae9b5e2d51f138e674\"",
    "VersionId": "1650376416551536",
    "ContentType": "binary/octet-stream",
    "Metadata": {},
    "StorageClass": "STANDARD"
}

Sans les en-têtes de chiffrement, vous obtiendrez une erreur 400 Bad Request.

Suppression d'un objet chiffré

La suppression ne nécessite pas les en-têtes de chiffrement :

aws s3 rm s3://<bucket_name>/<object_key>

URLs présignées

Les URLs présignées prennent en charge SSE-C avec les conditions suivantes :

Lors de la génération de l'URL, incluez x-amz-server-side-encryption-customer-algorithm dans le calcul de la signature.
Lors de l'utilisation de l'URL, le client doit fournir les trois en-têtes SSE-C.

Info

Les URLs présignées SSE-C ne peuvent être utilisées que par programmation — l'accès via un navigateur n'est pas pris en charge, car les en-têtes SSE-C ne peuvent pas être envoyés depuis un navigateur.

SSE-OMK — Chiffrement côté serveur avec clés gérées par OVHcloud

SSE-OMK chiffre automatiquement les objets au repos. OVHcloud dérive une clé unique par objet (en combinant une clé maître par bucket avec un sel aléatoire), de sorte que chaque objet est protégé individuellement sans aucune charge de gestion de votre côté. Les téléchargements sont entièrement transparents — aucun en-tête de chiffrement n'est nécessaire.

Avantages

Gestion des clés simplifiée : OVHcloud prend en charge la génération, le stockage et la rotation des clés. Aucune charge administrative ni planification de rotation pour votre équipe.
Isolation par objet : chaque objet est chiffré avec sa propre clé dérivée. Une compromission potentielle de clé n'affecte que cet objet, et non l'ensemble de votre bucket.
Accès transparent : les objets chiffrés se comportent exactement comme des objets non chiffrés — aucune modification de votre application ou de vos workflows n'est nécessaire.

Envoi d'un objet

aws s3api put-object \
  --bucket <bucket_name> \
  --key <object_key> \
  --body <file_path> \
  --server-side-encryption AES256 \
  --endpoint-url https://s3.<region>.io.cloud.ovh.net

Téléchargement d'un objet

Aucun en-tête de chiffrement n'est nécessaire — le déchiffrement est géré automatiquement côté serveur :

aws s3api get-object \
  --bucket <bucket_name> \
  --key <object_key> \
  <destination_file_path> \
  --endpoint-url https://s3.<region>.io.cloud.ovh.net

Warning

N'incluez pas d'en-têtes SSE-C lors du téléchargement d'un objet SSE-OMK — cela entraînera une erreur 400 Bad Request.

Activation de SSE-OMK sur un bucket

Une fois activé, tous les objets envoyés par la suite sont automatiquement chiffrés. Les objets existants ne sont pas affectés : renvoyez-les pour les chiffrer rétroactivement.

Info

Pour activer SSE-OMK à la création du bucket, consultez le guide « Débuter avec Object Storage ».

AWS CLI

Espace client OVHcloud

aws s3api put-bucket-encryption \
  --bucket <bucket_name> \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}' \
  --endpoint-url https://s3.<region>.io.cloud.ovh.net

Vérification du chiffrement du bucket

AWS CLI

Espace client OVHcloud

aws s3api get-bucket-encryption \
  --bucket <bucket_name> \
  --endpoint-url https://s3.<region>.io.cloud.ovh.net

Suppression d'un objet chiffré

La suppression fonctionne exactement comme pour les objets non chiffrés :

aws s3 rm s3://<bucket_name>/<object_key>

Considérations

Surcharge de chiffrement : SSE-OMK introduit une légère latence, négligeable pour la plupart des charges de travail. Pour la minimiser, utilisez un bucket dans une région géographiquement proche de votre application.
Visibilité des clés : vous ne pouvez pas inspecter, faire pivoter ou auditer directement les clés de chiffrement. Si vos exigences de conformité imposent la propriété ou la traçabilité des clés, utilisez SSE-C à la place.
Défense en profondeur : SSE-OMK protège les données au repos, mais ne remplace pas le contrôle d'accès. Associez-le à des politiques IAM strictes et à la journalisation des accès pour surveiller et restreindre qui peut lire vos objets.

Info

L'utilisation du chiffrement SSE-C ou SSE-OMK n'entraîne pas de frais supplémentaires.

Cas d'usage recommandés

CSE (Client-Side Encryption)

Idéal pour les organisations avec des exigences strictes de souveraineté des données, où les clés de chiffrement ne doivent jamais quitter l'environnement du client.
Adapté aux secteurs fortement réglementés comme la finance et la santé.

SSE-C (Server-Side Encryption with Customer Keys)

Recommandé pour les organisations qui doivent auditer ou faire pivoter leurs propres clés, tout en déléguant la charge du chiffrement au serveur.
À utiliser lorsque la conformité impose la propriété des clés, sans la complexité totale du chiffrement côté client.

SSE-OMK (Server-Side Encryption with OVHcloud-Managed Keys)

Idéal pour les équipes souhaitant un chiffrement robuste sans la charge opérationnelle de la gestion des clés.
Recommandé lorsque la simplicité et la rapidité de déploiement sont prioritaires et qu'il n'y a pas d'exigences de conformité liées à la propriété des clés.

Dépannage

Symptôme	Cause probable	Résolution
`400 Bad Request` lors d'un téléchargement SSE-C	En-têtes de chiffrement manquants ou incorrects	Incluez les trois en-têtes `--sse-customer-*` avec la même clé utilisée lors de l'upload
`400 Bad Request` lors d'un téléchargement SSE-OMK	En-têtes SSE-C inclus par erreur	Supprimez tous les en-têtes `--sse-customer-*`
Impossible de récupérer un objet SSE-C	Clé de chiffrement perdue	La récupération est impossible — supprimez l'objet
Augmentation de la latence	Surcharge liée au chiffrement/déchiffrement	Utilisez une région géographiquement proche de votre bucket pour réduire la latence

Aller plus loin

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Échangez avec notre communauté d'utilisateurs.

¹ : S3 est une marque déposée appartenant à Amazon Technologies, Inc. Les services de OVHcloud ne sont pas sponsorisés, approuvés, ou affiliés de quelque manière que ce soit.

Cette page vous a-t-elle aidé ?