Chiffrement BYOK Salesforce : Sécurisez vos données CRM avec une gestion externe des clés

Table des matières

Pourquoi le chiffrement natif de Salesforce est insuffisant
BYOK vs Cache-Only Key : quel modèle convient à vos besoins
Présentation de Salesforce Shield Platform Encryption
Intégration de la gestion externe des clés avec Salesforce
Répondre aux exigences RGPD avec le BYOK Salesforce
Impact sur les performances et expérience utilisateur
Rotation des clés et gestion du cycle de vie dans Salesforce
Conclusion
Références et lectures complémentaires

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.

Pourquoi le chiffrement natif de Salesforce est insuffisant

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 problème des clés gérées par le fournisseur

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.

Échecs d'audit de conformité

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 :

RGPD Article 32 exige des mesures techniques appropriées pour assurer la sécurité des données — mesures que vous contrôlez
DORA Article 9 mandate que les entités financières maintiennent le contrôle de leurs fonctions de sécurité ICT
Directive NIS2 exige que les organisations mettent en œuvre des contrôles cryptographiques avec des procédures documentées de gestion des clés
HIPAA Security Rule nécessite des contrôles d'accès que vous pouvez vérifier et auditer indépendamment

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.

Le vecteur de menace interne

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.

Risques d'accès aux données sous juridiction

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.

BYOK vs Cache-Only Key : quel modèle convient à vos besoins

Salesforce propose deux approches distinctes au chiffrement contrôlé par le client : Bring Your Own Key (BYOK) et Cache-Only Key. Comprendre les différences est essentiel pour sélectionner le bon modèle pour vos exigences de sécurité.

Architecture Bring Your Own Key (BYOK)

Dans le modèle BYOK, vous générez votre secret de locataire en dehors de Salesforce et le téléchargez sur la plateforme. Salesforce combine votre secret de locataire avec un secret maître généré par Salesforce pour créer la clé de chiffrement des données qui protège vos informations.

Caractéristiques clés du BYOK :

Aspect	Comportement BYOK
Génération de clé	Secret de locataire généré par le client
Stockage de clé	Secret de locataire stocké dans le HSM Salesforce
Dérivation de clé	Combiné avec le secret maître Salesforce
Révocation	Détruit le secret de locataire ; nécessite le support Salesforce pour la récupération
Accès hors ligne	Salesforce peut accéder aux données chiffrées (avec la clé dérivée)

Le BYOK apporte une amélioration significative par rapport au chiffrement purement géré par Salesforce car vous contrôlez le processus de génération du secret de locataire. Cependant, comme la clé de chiffrement des données dérivée existe dans l'infrastructure de Salesforce, Salesforce conserve techniquement la capacité de déchiffrer vos données pendant les opérations normales.

Architecture Cache-Only Key

Le modèle Salesforce Cache-Only Key va plus loin en s'assurant que votre matériau de clé ne persiste jamais dans l'infrastructure de Salesforce. Au lieu de cela, votre système de gestion des clés externe fournit des clés à la demande, et Salesforce les met en cache en mémoire uniquement pour la durée d'utilisation active.

Caractéristiques clés de Cache-Only Key :

Aspect	Comportement Cache-Only Key
Génération de clé	Générée et gérée extérieurement par le client
Stockage de clé	Jamais persisté dans Salesforce ; cache mémoire uniquement
Dérivation de clé	Matériau de clé récupéré du KMS externe via callout
Révocation	Immédiate par la révocation de l'accès au service de clés externe
Accès hors ligne	Salesforce ne peut pas accéder aux données sans le service de clés externe

Cache-Only Key fournit la forme la plus solide de souveraineté des données CRM disponible dans Salesforce. Si vous révoquez l'accès à votre service de clés externe, Salesforce perd immédiatement la capacité de déchiffrer vos données — sans ticket de support requis, sans période de grâce.

Cadre de décision

Choisissez BYOK lorsque :

Vous devez satisfaire aux exigences de conformité de base pour les clés contrôlées par le client
Votre modèle de menace n'inclut pas Salesforce comme adversaire potentiel
Vous avez besoin d'une implémentation plus simple avec moins de dépendances externes
Les préoccupations de continuité d'activité l'emportent sur la posture de sécurité maximale

Choisissez Cache-Only Key lorsque :

Les règlements exigent que vous puissiez révoquer immédiatement l'accès du fournisseur cloud
Votre modèle de menace inclut des préoccupations d'accès aux données sous juridiction (CLOUD Act)
Vous avez besoin d'une preuve cryptographique que le fournisseur ne peut pas accéder aux données au repos
Vous disposez d'une infrastructure de gestion des clés externe mature

Pour les organisations dans les industries réglementées — notamment les services financiers européens, la santé et l'automobile — Cache-Only Key représente généralement le choix approprié pour une souveraineté maximale des données.

Présentation de Salesforce Shield Platform Encryption

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.

Composantes de Shield Platform Encryption

Shield Platform Encryption fonctionne sur une structure de clés hiérarchique :

Secret maître — Généré et géré par Salesforce
Secret de locataire — Généré par le client (en BYOK) ou récupéré extérieurement (en Cache-Only Key)
Clé de chiffrement des données — Dérivée de la combinaison des secrets maître et de locataire
Clés par enregistrement — Clés individuelles dérivées pour des enregistrements de données spécifiques

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.

Types de données chiffrables

Shield Platform Encryption prend en charge le chiffrement pour :

Données de champs standard et personnalisés — Texte, zone de texte, téléphone, email, champs URL
Fichiers et pièces jointes — Documents téléchargés vers Salesforce
Index de recherche — La recherche chiffrée maintient la fonctionnalité tout en protégeant les données
Chatter — Publications et commentaires dans la plateforme de collaboration Salesforce
Événements de plateforme — Données d'événements dans le traitement asynchrone

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.

Chiffrement probabiliste vs déterministe

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).

Exigences de licence

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.

La fonctionnalité Cache-Only Key nécessite Shield Platform Encryption plus une configuration supplémentaire pour l'intégration du service de clés externe.

Intégration de la gestion externe des clés avec Salesforce

La mise en œuvre de la gestion des clés externe Salesforce nécessite de connecter votre système de gestion des clés (KMS) à l'infrastructure de chiffrement de Salesforce. Cette intégration suit une architecture standardisée mais exige une planification rigoureuse.

Architecture de gestion des clés externe

L'architecture d'intégration pour Cache-Only Key implique :

Votre KMS externe — Génère, stocke et gère le matériau de clé de chiffrement réel
Service de courtier de clés — Gère l'authentification et la traduction de protocole de communication
Credential nommé Salesforce — Stocke les informations d'authentification pour le service externe
Certificat Salesforce — Permet l'authentification mTLS
Connexion Cache-Only Key — Configuration Salesforce reliant à votre service de clés

Lorsque Salesforce doit chiffrer ou déchiffrer des données, il effectue un callout authentifié vers votre service de clés, récupère le matériau de clé, l'utilise pour l'opération cryptographique et supprime la clé de la mémoire lorsqu'elle n'est plus nécessaire.

Prérequis d'implémentation

Avant de commencer l'implémentation, assurez-vous que vous avez :

Licence Shield Platform Encryption activée dans votre org Salesforce
KMS externe capable de servir des clés via HTTPS avec mTLS
Connectivité réseau entre Salesforce et votre KMS (règles de pare-feu, configuration proxy)
Infrastructure de certificats pour l'authentification mutuelle
Haute disponibilité pour votre service de clés (Salesforce nécessite une disponibilité constante)

Processus d'intégration étape par étape

Étape 1 : Configurer votre KMS externe

Votre KMS doit exposer un point de terminaison HTTPS qui accepte les demandes de récupération de clés et retourne le matériau de clé dans le format attendu par Salesforce. La réponse doit inclure :

Matériau de clé (encodé en base64)
Identifiant de clé
Indication du type de clé

L'intégration Salesforce de DuoKey fournit un connecteur pré-construit qui gère ce protocole, éliminant les exigences de développement personnalisé.

Étape 2 : Créer un Credential nommé dans Salesforce

Naviguez vers Configuration > Sécurité > Credentials nommés et créer un nouveau credential :

URL : Votre point de terminaison de service de clés
Type d'identité : Principal nommé
Protocole d'authentification : Basé sur les certificats (pour mTLS)

Étape 3 : Télécharger les certificats

Téléchargez le certificat client que Salesforce présentera à votre KMS, et configurez votre KMS pour faire confiance à la chaîne de certificats de Salesforce.

Étape 4 : Configurer le service Cache-Only Key

Dans Configuration > Sécurité > Platform Encryption > Gestion des clés :

Sélectionnez « Bring Your Own Key »
Choisissez « Cache-Only Key Service »
Spécifiez votre Credential nommé
Configurez les paramètres de callout du service de clés

Étape 5 : Tester l'intégration

Utilisez les outils de test intégrés de Salesforce pour vérifier :

La connectivité vers votre service de clés externe
La récupération réussie des clés
Les opérations de chiffrement et de déchiffrement

Étape 6 : Activer le chiffrement sur les champs

Une fois le service de clés opérationnel, activez le chiffrement sur vos champs sensibles via Configuration > Sécurité > Platform Encryption > Politique de chiffrement.

Considérations de disponibilité et de latence

Cache-Only Key crée une dépendance d'exécution sur votre service de clés externe. Si votre KMS est indisponible, Salesforce ne peut pas déchiffrer les données protégées. Cela a des implications significatives :

Exigences de disponibilité du KMS — Votre service de clés doit atteindre ou dépasser les SLA de disponibilité propres de Salesforce
Distribution géographique — Déployer des instances KMS dans des régions proches de votre centre de données Salesforce
Circuit breaker — Implémenter des mécanismes de détection de panne et de basculement pour éviter les pannes en cascade

Répondre aux exigences RGPD avec le BYOK 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.

Démontrer la souveraineté des données

Avec Cache-Only Key correctement configuré, vous pouvez démontrer aux régulateurs que :

Salesforce ne peut pas déchiffrer vos données sans votre service de clés
Une demande du CLOUD Act à Salesforce ne peut produire que du texte chiffré inutilisable
Vous maintenez le contrôle exclusif sur le matériau de clé protégeant les données personnelles européennes

Documentation de conformité

Maintenez les documents suivants pour les audits RGPD :

Architecture de flux de données montrant le contrôle des clés externes
Politique de gestion des clés avec procédures de rotation et de révocation
Journaux d'accès aux clés démontrant votre contrôle exclusif
Analyses d'impact sur la protection des données (DPIA) pour le traitement Salesforce

Impact sur les performances et expérience utilisateur

Le chiffrement introduit de la latence dans les opérations Salesforce. Comprendre et gérer cet impact est essentiel pour une adoption réussie.

Benchmarks de latence typiques

Pour Cache-Only Key, chaque opération de chiffrement/déchiffrement ajoute typiquement :

Accès initial aux enregistrements : 50-150ms supplémentaires (récupération de clé)
Opérations subséquentes : Minimal (clé en cache en mémoire)
Chargement de listes : 100-300ms supplémentaires selon le volume d'enregistrements

Stratégies d'optimisation

Mise en cache : Optimiser les TTL de mise en cache des clés pour équilibrer sécurité et performance
Chunking : Traiter les chiffrements en masse pendant les heures creuses
Architecture régionale : Co-localiser votre KMS avec votre instance Salesforce

Rotation des clés et gestion du cycle de vie dans Salesforce

La rotation régulière des clés est une exigence de conformité et une bonne pratique de sécurité.

Fréquences de rotation recommandées

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

Processus de rotation des clés

Générer une nouvelle clé dans votre KMS externe
Déclarer la nouvelle version de clé dans Salesforce via l'interface de gestion des clés
Initier la rechiffrement — Salesforce rechiffre les données existantes avec la nouvelle clé
Vérifier le rechiffrement — Confirmer que toutes les données ont été migrées vers la nouvelle clé
Archiver l'ancienne clé — Conserver pour le déchiffrement de sauvegardes anciennes si nécessaire

La rotation des clés ne cause pas d'interruption de service dans Salesforce — la plateforme gère la transition en arrière-plan pendant que les opérations normales continuent.

Conclusion

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 propose un connecteur pré-construit pour Salesforce Cache-Only Key qui simplifie considérablement ce déploiement tout en satisfaisant aux exigences de souveraineté les plus strictes des régulateurs européens.