BYOK Salesforce Shield ou Cache-Only Key Service : format JWE, cache de 72 h, révocation, étapes de configuration et clés servies par DuoKey.
Le Cache-Only Key Service de Salesforce est l'option de Shield Platform Encryption qui garde votre matériel de clé hors de Salesforce. Salesforce récupère la clé à la demande auprès d'un service de clés que vous contrôlez, via un appel sortant (callout) passant par un named credential, et ne la conserve que dans un cache chiffré. Salesforce ne conserve les clés cache-only dans aucun système d'enregistrement ni sauvegarde : si vous détruisez la clé ou cessez de la servir, les données qu'elle protège deviennent illisibles (Salesforce Platform Encryption Implementation Guide).
Pour les entreprises stockant des données clients sensibles dans Salesforce, la question de la propriété des clés de chiffrement est devenue une préoccupation critique de conformité et de sécurité. Le BYOK Salesforce (Bring Your Own Key) offre aux organisations la capacité de maintenir le contrôle cryptographique sur leurs données CRM, même lorsque ces données résident dans l'infrastructure multi-locataire de Salesforce. Cette capacité est passée d'un luxe de sécurité à une nécessité réglementaire, notamment pour les organisations opérant sous le RGPD, DORA, NIS2, ou des cadres sectoriels comme HIPAA et TISAX.
Le défi fondamental est simple : lorsque vos clés de chiffrement sont générées, stockées et gérées par votre fournisseur cloud, vous avez effectivement délégué la sécurité de vos données les plus sensibles à un tiers. Pour les industries réglementées, services financiers, santé, automobile et secteur public, cette délégation crée des lacunes d'audit, des risques de conformité et une exposition potentielle aux demandes d'accès aux données sous juridictions étrangères. La gestion externe des clés Salesforce répond à cette lacune en permettant aux entreprises de conserver l'autorité ultime sur les clés cryptographiques protégeant leurs données CRM.
Ce guide examine l'architecture technique, les implications de conformité et les considérations opérationnelles pour la mise en œuvre de solutions BYOK et Cache-Only Key dans Salesforce Shield Platform Encryption. Nous fournirons la profondeur technique dont les RSSI et les architectes de sécurité ont besoin pour prendre des décisions éclairées sur leur stratégie de souveraineté des données CRM.
Salesforce fournit des capacités de chiffrement par défaut, mais l'implémentation standard laisse des lacunes significatives en matière de sécurité et de conformité que les équipes de sécurité d'entreprise ne peuvent pas ignorer.
Le chiffrement standard de Salesforce utilise des clés qui sont générées et stockées dans l'infrastructure de Salesforce. Bien que cela offre une protection contre certains vecteurs de menace, comme le vol physique des supports de stockage, il ne répond pas à la préoccupation fondamentale de l'accès du fournisseur. Les administrateurs Salesforce, le personnel de support et potentiellement les forces de l'ordre dans les juridictions d'exploitation de Salesforce peuvent théoriquement accéder aux clés de chiffrement protégeant vos données.
Pour les organisations soumises aux réglementations européennes de protection des données, cela crée un conflit direct avec le principe de la souveraineté des données. La décision Schrems II a invalidé le cadre Privacy Shield précisément parce que les fournisseurs basés aux États-Unis pouvaient être contraints de fournir l'accès aux données en vertu du CLOUD Act, indépendamment de l'endroit où ces données sont physiquement stockées.
Lorsque les auditeurs examinent votre posture de sécurité Salesforce, ils poseront une question critique : « Qui contrôle les clés de chiffrement ? » Si la réponse est « Salesforce », vous faites face à plusieurs problèmes :
Avec des clés gérées par le fournisseur, vous ne pouvez pas démontrer un contrôle indépendant. Votre posture de sécurité n'est que aussi solide que les contrôles d'accès internes de Salesforce, des contrôles que vous ne pouvez pas auditer ni vérifier.
Salesforce emploie des milliers de personnes dans le monde entier. Bien que l'entreprise maintienne des pratiques de sécurité robustes, les menaces internes restent une réalité statistique dans toute grande organisation. Un rapport 2024 du Verizon Data Breach Investigations a constaté que les menaces internes représentaient 19 % des violations, l'abus d'accès privilégié étant le principal vecteur.
Lorsque Salesforce détient vos clés de chiffrement, un initié compromis chez Salesforce devient une menace pour vos données. La gestion externe des clés élimine ce risque en s'assurant que le personnel de Salesforce, quel que soit son niveau d'accès, ne peut pas déchiffrer vos données sans votre participation explicite.
La portée extraterritoriale du CLOUD Act américain signifie qu'une ordonnance judiciaire américaine peut contraindre Salesforce à produire des données stockées sur des serveurs n'importe où dans le monde. Pour les entreprises européennes, cela crée un conflit irréconciliable avec les exigences de protection des données du RGPD.
Avec le chiffrement BYOK Salesforce correctement mis en œuvre, même si Salesforce est contraint de remettre des données chiffrées, il ne peut pas fournir les clés pour les déchiffrer. Cela crée une protection technique qui complète les protections juridiques et contractuelles.
Salesforce Shield Platform Encryption propose deux façons de fournir votre propre matériel de clé : le Bring Your Own Key (BYOK), où vous téléversez un secret de locataire, et le Cache-Only Key Service, où Salesforce récupère la clé auprès de votre service de clés chaque fois que son cache est vide.
En BYOK, vous générez un secret de locataire hors de Salesforce et le téléversez, chiffré avec un certificat compatible BYOK. Shield utilise votre secret de locataire avec le secret maître de Salesforce pour dériver la clé de chiffrement des données. Le secret téléversé est stocké chez Salesforce.
| Aspect | BYOK |
|---|---|
| Génération de la clé | Vous générez le secret de locataire |
| Stockage | Téléversé et stocké par Salesforce |
| Clé de chiffrement des données | Dérivée de votre secret et du secret maître Salesforce |
| Révocation | Détruire le secret de locataire dans Setup |
| Dépendance à vos systèmes en production | Aucune |
Le BYOK va plus loin que les clés gérées par Salesforce, car vous maîtrisez la génération du secret et pouvez le détruire. Mais une fois téléversé, le matériel réside dans Salesforce.
Avec le Cache-Only Key Service, votre matériel de clé n'est jamais stocké dans un système d'enregistrement Salesforce. Salesforce appelle votre service de clés, reçoit la clé enveloppée en JSON Web Encryption (JWE) et ne la garde que dans un cache chiffré. Les clés cache-only contournent la dérivation : elles chiffrent et déchiffrent directement vos données (Salesforce).
| Aspect | Cache-Only Key Service |
|---|---|
| Génération de la clé | Vous générez et stockez une clé AES 256 bits dans votre service de clés |
| Stockage | Jamais persistée par Salesforce ; conservée dans un cache chiffré |
| Clé de chiffrement des données | Votre clé, utilisée directement (sans dérivation) |
| Révocation | Détruire la clé dans Setup, ou cesser de la servir depuis votre service |
| Dépendance à vos systèmes en production | Oui, dès que le cache est vide |
Le cache compte pour la révocation. Salesforce le vide régulièrement toutes les 72 heures, et certaines opérations le vident environ toutes les 24 heures. Détruire la clé cache-only dans Setup invalide immédiatement la copie en cache ; arrêter votre service de clés prend effet au prochain besoin du cache (Salesforce).
Choisissez le BYOK si :
Choisissez le Cache-Only Key si :
Pour comparer ces modèles chez les fournisseurs SaaS et cloud, voir Hold Your Own Key (HYOK) vs BYOK.
Quand un utilisateur lit des données chiffrées ou écrit dans des champs chiffrés et que la clé n'est pas en cache, le Cache-Only Key Service appelle votre service de clés via un named credential. Votre service renvoie le matériel de clé enveloppé en JWE sur le canal authentifié que vous avez configuré. Salesforce chiffre la clé reçue avec une clé de cache AES-256 propre à l'org, elle-même protégée par des clés sous HSM, avant de la mettre en cache (Salesforce).
| Élément | Format exigé |
|---|---|
| Clé de chiffrement des données (DEK) | AES 256 bits (32 octets) |
| Clé de chiffrement du contenu (CEK) | AES 256 bits, unique par requête |
| Certificat compatible BYOK | Certificat RSA 4096 bits créé dans Salesforce |
En-tête JWE alg | RSA-OAEP (chiffre la CEK) |
En-tête JWE enc | A256GCM (chiffre la DEK) |
Identifiant unique de clé (kid) | Chiffres, lettres, points, tirets et underscores |
Un en-tête protégé ressemble à {"alg":"RSA-OAEP","enc":"A256GCM","kid":"982c375b-f46b-4423-8c2d-4d1a69152a0b"}. Salesforce publie un exemple, le Cache-Only Key Wrapper, sur GitHub.
Si la détection de rejeu est activée dans les paramètres avancés de Platform Encryption, chaque appel porte un RequestIdentifier avec un nonce à usage unique. Votre service doit renvoyer ce nonce en jti dans l'en-tête JWE ; sinon Salesforce interrompt l'appel avec l'erreur POTENTIAL_REPLAY_ATTACK_DETECTED.
?????.RemoteKeyCalloutEvent, utilisable pour alerter en cas d'échec.Salesforce le dit clairement : la clé est sous votre responsabilité, et Salesforce ne peut pas récupérer un matériel de clé perdu stocké hors de son cache chiffré (Salesforce).
Le Cache-Only Key Service est disponible en éditions Enterprise, Performance, Unlimited et Developer, et nécessite Salesforce Shield ou Shield Platform Encryption plus le Cache-Only Key Service. Utilisez une clé cache-only distincte par type de clé (par exemple Data in Salesforce et Analytics).
Salesforce Shield Platform Encryption est le cadre de chiffrement d'entreprise qui permet les implémentations BYOK et Cache-Only Key. Comprendre son architecture est essentiel pour un déploiement correct.
Shield Platform Encryption fonctionne sur une structure de clés hiérarchique :
Cette hiérarchie fournit une défense en profondeur. La compromission d'une seule clé par enregistrement n'expose pas toutes les données chiffrées, et la séparation entre les secrets maître et de locataire signifie qu'aucune des deux parties ne peut seule dériver la clé de chiffrement des données.
Shield Platform Encryption prend en charge le chiffrement pour :
Tous les types de champs ne prennent pas en charge le chiffrement. Les champs de formule, les champs numérotation automatique et certains champs système ne peuvent pas être chiffrés. Votre équipe d'implémentation doit mapper les champs de données sensibles aux types de champs chiffrables pendant la phase de planification.
Salesforce Shield propose deux schémas de chiffrement :
Le chiffrement probabiliste offre une sécurité maximale en générant un texte chiffré unique pour des valeurs en clair identiques. Le même nom de client chiffré deux fois produit un texte chiffré différent. Cela empêche les attaques par analyse de motifs mais limite certaines fonctionnalités, vous ne pouvez pas filtrer ou regrouper par champs chiffrés.
Le chiffrement déterministe produit un texte chiffré cohérent pour des valeurs en clair identiques, permettant le filtrage, le regroupement et la correspondance insensible à la casse sur des données chiffrées. Cependant, cette cohérence crée une vulnérabilité théorique à l'analyse de fréquence sur les champs à haute cardinalité.
Pour la plupart des déploiements d'entreprise, le chiffrement probabiliste est approprié pour les champs très sensibles (numéros de sécurité sociale, données financières), tandis que le chiffrement déterministe convient aux champs nécessitant une fonctionnalité de requête (adresses email pour la correspondance des doublons).
Shield Platform Encryption nécessite la licence d'extension Salesforce Shield. Cette licence inclut également les capacités Event Monitoring et Field Audit Trail. Pour les organisations mettant en œuvre des programmes de sécurité complets, ces fonctionnalités supplémentaires justifient souvent l'investissement Shield au-delà du seul chiffrement.
Le Cache-Only Key Service nécessite Shield ou Shield Platform Encryption plus le Cache-Only Key Service.
Une intégration Cache-Only Key Service comporte quatre éléments :
Salesforce propose aussi Shield External Key Management avec des clés dans AWS KMS, via un named credential AWS Signature Version 4. Si cette clé AWS KMS se trouve dans un magasin de clés externe AWS, la clé racine reste elle aussi hors d'AWS.
Ces étapes suivent le Platform Encryption Implementation Guide de Salesforce :
kid) et choisissez le named credential de cette clé.DuoKey pour Salesforce assure le côté service de clés. Salesforce Shield appelle directement le point de terminaison Cache-Only Key Service (COKS) de DuoKey via un named credential et son external credential, authentifié par un secret de connecteur de type bearer que DuoKey génère à la création de l'application Salesforce. DuoKey ne se connecte jamais à votre org Salesforce et n'a besoin d'aucun nom d'utilisateur, mot de passe ou jeton de sécurité Salesforce.
Le BYOK Salesforce et, plus particulièrement, Cache-Only Key répondent directement à plusieurs préoccupations de conformité RGPD soulevées par l'arrêt Schrems II.
Avec Cache-Only Key correctement configuré, vous pouvez démontrer aux régulateurs que :
Maintenez les documents suivants pour les audits RGPD :
Comme Salesforce met la clé récupérée en cache, le service de clés n'est appelé que lorsque le cache est vide : après un vidage, une rotation ou une destruction. Le chiffrement et le déchiffrement quotidiens s'appuient sur le cache.
La vraie contrainte est la disponibilité. Si la clé n'est pas en cache et que votre service est injoignable, les utilisateurs ne peuvent ni lire ni écrire les données chiffrées. Salesforce demande un service de clés avec un SLA adapté et insiste sur les périodes chargées comme les fins de trimestre et d'année.
RemoteKeyCalloutEvent avec un trigger Apex after insertLa rotation régulière des clés est une exigence de conformité et une bonne pratique de sécurité.
| Type de données | Fréquence de rotation recommandée |
|---|---|
| Données hautement sensibles (données financières, santé) | Trimestrielle |
| Données personnelles standard | Annuelle |
| Données opérationnelles moins sensibles | Tous les 2 ans |
(Salesforce Platform Encryption Implementation Guide)
Q : Qu'est-ce que le Cache-Only Key Service de Salesforce ?
Une option de Shield Platform Encryption qui récupère votre clé de 256 bits auprès d'un service de clés que vous contrôlez, via un appel passant par un named credential, et ne la garde que dans un cache chiffré. Salesforce ne conserve les clés cache-only dans aucun système d'enregistrement ni sauvegarde.
Q : Quelle différence entre BYOK Salesforce et clé cache-only ?
En BYOK, vous téléversez un secret de locataire que Salesforce stocke et utilise pour dériver la clé de chiffrement des données. Avec une clé cache-only, Salesforce récupère votre clé à la demande, l'utilise directement et ne la stocke pas.
Q : Combien de temps Salesforce garde-t-il une clé cache-only en cache ?
Le cache est vidé toutes les 72 heures, et certaines opérations le vident environ toutes les 24 heures. Détruire la clé dans Setup invalide immédiatement la copie en cache.
Q : Que se passe-t-il si mon service de clés tombe en panne ?
Les clés en cache continuent de fonctionner. Quand le cache est vide et que l'appel échoue, la clé passe à Destroyed, Salesforce réessaie jusqu'à 24 heures, et les données concernées s'affichent en ????? jusqu'à ce que la clé puisse de nouveau être récupérée.
Q : Le Cache-Only Key Service exige-t-il du TLS mutuel ?
Aucune méthode particulière n'est imposée. L'appel passe par un named credential, qui prend en charge des formats comme le TLS mutuel et OAuth. Le point de terminaison DuoKey utilise un secret de connecteur bearer défini dans l'external credential du named credential.
Q : Quelles licences faut-il ?
Salesforce Shield ou Shield Platform Encryption, plus le Cache-Only Key Service, en édition Enterprise, Performance, Unlimited ou Developer.
Le chiffrement BYOK Salesforce, et en particulier Cache-Only Key, représente l'architecture de souveraineté des données CRM la plus robuste disponible sur la plateforme. Pour les organisations européennes soumises au RGPD, DORA ou NIS2, c'est de plus en plus non pas une option mais une nécessité pour démontrer un contrôle adéquat sur les données personnelles et financières sensibles.
La clé du succès réside dans le choix de la bonne architecture (BYOK vs Cache-Only Key selon votre modèle de menace), la mise en œuvre d'une infrastructure de gestion des clés externe à haute disponibilité et la documentation rigoureuse des contrôles pour les audits. DuoKey fournit un point de terminaison Cache-Only Key Service prêt à l'emploi pour Salesforce, ce qui vous évite de développer et d'exploiter vous-même le service de clés JWE.
Écrit par
DuoKey Security Team
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
