Modèles de protection des données


En savoir plus sur Well-Architected Trust → Protection des données

Modèles

Où chercherÀ quoi ressemble le bien
Schéma de classification des données✅ Schéma de classification documenté avec des niveaux (Public, Interne, Confidentiel, Restreint)
✅ Exemples commerciaux fournis pour chaque niveau de classification
✅ Schéma de classification aligné sur les obligations réglementaires (HIPAA, PCI DSS, GDPR)
✅ Modélisateurs de données formés pour appliquer la classification de façon cohérente pendant la conception
✅ Nouveaux champs classés dans le cadre du processus de modélisation des données, pas rétroactivement
Classification au niveau du champ✅ Classification appliquée au niveau du champ, pas seulement au niveau de l’objet
✅ Les champs d’un seul objet peuvent avoir des classifications différentes
✅ La sécurité au niveau du champ reflète les distinctions de classification
✅ Données non classées par défaut au niveau de protection approprié le plus élevé
✅ La classification pilote les contrôles de protection (cryptage, accès, rétention)
Objets et champs personnalisés✅ Tous les objets personnalisés ont une classification des données documentée
✅ Champs confidentiels (salaire, SSN, PHI, données de paiement) classés comme confidentiels ou restreints
✅ Champs publics (nom de la société, site Web) documentés en tant que Public
✅ Métadonnées de classification capturées dans les descriptions de champ
✅ Classification examinée lors des examens de code et ARB
Objets standard✅ Champs d’objet standard évalués par rapport au schéma de classification
✅ Shield Platform Encryption activé pour les champs standard Restreints
✅ Sécurité au niveau du champ appliquée aux champs standard confidentiels
✅ Rapports et vues de liste filtrés pour empêcher l’exposition de champs standard confidentiels
Données d’intégration✅ Données circulant à travers des intégrations classées avant l’implémentation
✅ Sensibilité des données système externes évaluée et documentée
✅ Gestion des points de terminaison d’intégration Les données restreintes utilisent l’authentification basée sur le certificat
✅ Classification des données préservée à travers les frontières du système
Mappage de conformité✅ Champs PHI HIPAA identifiés et marqués Restricted
✅ Les données des détenteurs de carte PCI évitées dans Salesforce si possible, tokenisées via une passerelle de paiement pour réduire la portée. Lorsqu’elles doivent être stockées, utilisez des champs personnalisés cryptés sous les contrôles PCI DSS.
Données personnelles RGPD identifiées et soumises à des contrôles de confidentialité
✅ Données financières SOX classées et soumises à la séparation des tâches

Anti-modèles

Où chercherÀ quoi ressemble mal
Protection uniforme⚠️ Même protection appliquée à tous les champs quelle que soit la sensibilité
⚠️ Données de faible valeur surprotégées (gaspillage de ressources) alors que les données de grande valeur sont sous-protégées
⚠️ Informations sur les sociétés publiques traitées de la même façon que les données PHI ou de carte de paiement
⚠️ Chaque champ crypté « juste pour être sûr » sans justification de classification
Classification rétroactive⚠️ Données classées après déploiement en production
⚠️ Données confidentielles découvertes lors d’audits de conformité plutôt que d’examens de conception
⚠️ Données classées uniquement après des incidents de sécurité
⚠️ « On trouvera la classification plus tard » est la valeur par défaut lors du développement
Classification au niveau de l’objet uniquement⚠️ Objets entiers classés uniformément lorsque les champs ont une sensibilité différente
⚠️ Accès au niveau de l’objet accordé sans sécurité au niveau du champ pour les champs confidentiels
⚠️ Tous les champs des objets Compte ou Contact supposés avoir la même classification
⚠️ Autorisations d’objet utilisées comme seul contrôle d’accès pour les objets à sensibilité mixte
Knowledge tribales⚠️ Classification non documentée, n’existant que dans la Knowledge des personnes clés
⚠️ Les développeurs comptaient sur eux pour « juste savoir » quels champs sont sensibles
⚠️ Aucun schéma de classification écrit accessible à tous les modélisateurs de données
⚠️ Nouveaux membres de l’équipe intégrés sans formation en classification

Modèles

Où chercherÀ quoi ressemble le bien
Cryptage au repos✅ Toutes les données cryptées au niveau de l’infrastructure via Hyperforce
✅ Shield Platform Encryption activé pour les données restreintes
✅ Schéma de cryptage (probabiliste, déterministe, déterministe sensible à la casse) sélectionné en fonction des exigences de requête et d’unicité
✅ compromis de cryptage évalués lors de la conception du modèle de données
Stratégie Shield Platform Encryption✅ Cryptage probabiliste utilisé pour la plupart des champs restreints (prend en charge toutes les opérations de requête)
✅ Cryptage déterministe utilisé pour les champs nécessitant une correspondance exacte clauses WHERE ou unicité
✅ Déterministe sensible à la casse utilisé lorsque la distinction de la casse est importante pour la logique métier
✅ Comportement de champ crypté testé avant le déploiement en production
✅ Références de champ de formule à des champs cryptés traités de façon appropriée (déplacés vers Apex si nécessaire)
Gestion des clés✅ Procédures de rotation des clés documentées et automatisées
✅ Scénarios de destruction clés testés pendant les exercices de reprise après sinistre
✅ Clés gérées par le client (BYOK) évaluées pour la conformité nécessitant un contrôle explicite des clés
✅ Principales procédures de révocation documentées
✅ Cycle de vie de clé de cryptage géré selon les exigences de conformité
Cryptage en transit✅ TLS 1.2 ou supérieur requis pour toutes les intégrations
✅ Authentification mutuelle basée sur le certificat pour les intégrations qui gèrent les données restreintes
✅ En-têtes HSTS configurés pour les sites Experience Cloud afin d’empêcher la rétrogradation du protocole
✅ Expiration du certificat TLS surveillée et renouvellement automatisé configuré
✅ Chiffrements faibles et protocoles désactivés
Code et configuration✅ Identifiants jamais incorporés dans un code, des fichiers de configuration ou un contrôle de version
✅ Identifiants nommés et identifiants externes utilisés pour gérer l’authentification de façon centralisée
✅ Capacités de rotation des identifiants intégrées à l’architecture
✅ Identifiants nommés authentification abstraite du code, activant les mises à jour sans changement de code
Packages AppExchange✅ Exigences de sécurité du package évaluées avant l’installation
✅ Champs cryptés accessibles aux packages uniquement lorsque l’entreprise le justifie
✅ Modèles d’accès aux données du package surveillés via la Surveillance des événements
✅ Packages nécessitant l’accès aux données restreintes soumises à un examen avancé

Anti-modèles

Où chercherÀ quoi ressemble mal
Cryptage sans évaluation⚠️ Le cryptage probabiliste activé sur tous les champs sans test
⚠️ Échec des rapports critiques en production, car les champs cryptés ne peuvent pas être agrégés
⚠️ Cryptage activé dans les sources de champ de formule sans comprendre l’impact
⚠️ Champs utilisés dans les requêtes SOQL LIKE cryptées sans basculer vers le cryptage déterministe
Identifiants incorporés⚠️ Identifiants incorporés dans un code, des paramètres personnalisés ou un contrôle de version
⚠️ Clés d’API, mots de passe et certificats codés en dur dans les classes Apex
⚠️ Identifiants engagés dans des référentiels de contrôle de code source
⚠️ Identifiants stockés dans des métadonnées personnalisées ou des paramètres personnalisés sans cryptage
Protocoles faibles ou hérités⚠️ TLS 1.0 ou 1.1 accepté (déprécié et vulnérable)
⚠️ Flux OAuth nom d’utilisateur-mot de passe autorisé lorsque le porteur JWT est disponible
⚠️ Certificats auto-signés acceptés dans les intégrations de production
⚠️ La validation du certificat désactivée « pour que l’intégration fonctionne »
Aucune gestion des clés⚠️ Shield Platform Encryption activé sans procédure de rotation des clés
⚠️ Aucun scénario de destruction de clé documenté
⚠️ Clés par défaut utilisées sans évaluer la conformité des clés gérées par le client
⚠️ Procédures de rotation et de révocation des clés jamais testées
Surcryptage⚠️ Données de classification publiques ou internes cryptées, ajoutant un coût sans avantage
⚠️ Shield Platform Encryption activé sur chaque champ, créant une complexité inutile
⚠️ BYOK utilisé lorsque la conformité ne l’exige pas (ajoute les frais généraux opérationnels)
⚠️ Cryptage obligatoire lorsque la classification des données ne le justifie pas

Modèles

Où chercherÀ quoi ressemble le bien
Stratégie sandbox✅ Les données restreintes ne pénètrent jamais dans les environnements de développement ou de test
✅ La copie sandbox partielle exclut les objets et les champs restreints
✅ Les modèles de sandbox définissent les objets et les champs à inclure par type d’environnement
✅ Data Mask configuré pour les sandbox qui nécessitent des données de type production
Règles Data Mask✅ Les règles Data Mask masquent les champs sensibles tout en préservant les caractéristiques des données
✅ Les modèles maintiennent l’intégrité référentielle (la même entrée produit la même sortie masquée)
✅ Adresses e-mail masquées, mais restent valides pour le test
✅ Numéros de téléphone masqués, mais restent valides
✅ Dates décalées de façon cohérente en maintenant des relations relatives
✅ Champs numériques randomisés dans des plages réalistes
Données synthétiques✅ Les environnements de développement utilisent la génération de données synthétiques
✅ Les données synthétiques ont des caractéristiques réalistes permettant des tests efficaces
✅ Aucune donnée de production jamais requise pour le développement
✅ Tester la génération de données automatisée dans les pipelines de développement
Environnements de non-production✅ Données de production jamais copiées dans des organisations de développeur personnel
✅ Captures d’écran et démonstrations utilisent des données masquées ou synthétiques
✅ Les environnements de formation utilisent des données synthétiques ou des données de production fortement masquées
✅ Accès des sous-traitants et des fournisseurs aux données de non-production limitées à la classification Business Use Only

Anti-modèles

Où chercherÀ quoi ressemble mal
Données de production dans des organisations sandbox⚠️ Sandbox complètes actualisées avec des données de production non masquées pour le développement
⚠️ Données restreintes copiées dans les sandbox Developer pour plus de commodité
⚠️ Les développeurs reçoivent un large accès aux sandbox production-données
⚠️ Sandbox actualisées avec des données confidentielles « car les tests sont plus faciles avec des données réelles »
Aucune donnée synthétique⚠️ Données de production utilisées uniquement pour tous les tests
⚠️ Pas de génération de données synthétiques pour les environnements de développement
⚠️ « Nous avons besoin de données réelles » assumées sans évaluer les alternatives synthétiques
⚠️ Données de test manuelles créées lorsque la génération peut être automatisée

Modèles

Où chercherÀ quoi ressemble le bien
Minimisation des données✅ Seules les données nécessaires à des fins commerciales déclarées collectées
✅ Chaque ajout de champ contesté avec « quelle décision architecturale nécessite ces données ? »
✅ Données ne servant plus à la collecte retirées
✅ Champs facultatifs clairement marqués et non obligatoires sans justification métier
✅ Conservation des données historiques aligné sur la base juridique, pas “tout garder pour toujours”
Limite du motif✅ Les ensembles d’autorisations limitent l’accès aux données en fonction de l’objet de la fonction
✅ Les utilisateurs marketing ne peuvent pas accéder aux détails des requêtes de support sans justification documentée
✅ Les commerciaux ne peuvent pas accéder aux historiques de service client, sauf si la tâche l’exige
✅ L’accès aux données interfonctionnelles nécessite une approbation et une surveillance explicites
✅ Motif d’accès aux données documenté dans les descriptions d’ensemble d’autorisations
Gestion du consentement✅ Consentement capturé au niveau individuel pour le marketing, les analytiques, le traitement facultatif
✅ Le consentement est granulaire (spécifique au but), pas le consentement général binaire
✅ Les workflows de retrait du consentement se propagent à travers les systèmes intégrés
✅ Décisions de consentement suivies avec l’horodatage, la version et le mécanisme
✅ L’interface utilisateur de consentement explique clairement ce à quoi l’utilisateur consent
Droits de la personne concernée✅ Les workflows de demande d’accès fournissent des copies de données dans les délais fixés par les ensembles réglementaires régissant votre déploiement
✅ Les workflows de rectification corrigent les imprécisions avec le journal d’audit
✅ Les workflows d’effacement suppriment les données lorsque la loi le permet (en tenant compte des obligations de conservation)
✅ Les workflows de portabilité exportent les données sous un format lisible par machine
✅ Workflows de droits de la personne concernée testés régulièrement pour valider les chronologies
✅ L’automatisation du workflow garantit le respect cohérent des échéanciers réglementaires
Contrôles de confidentialité✅ Contrôles de confidentialité appliqués techniquement, pas seulement par le biais d’une politique
✅ Les règles de partage implémentent la limitation d’objet
✅ La sécurité au niveau du champ protège les attributs confidentiels
✅ Les pistes d’audit capturent les événements relatifs à la confidentialité
✅ Contrôles de confidentialité validés dans les pipelines CI/CD

Anti-modèles

Où chercherÀ quoi ressemble mal
Tout collecter⚠️ Démarche « Collecter toutes les données possibles, on en aura peut-être besoin un jour »
⚠️ Champs ajoutés sans objet métier documenté
⚠️ Données conservées indéfiniment sans justification de rétention
⚠️ Données facultatives collectées en rendant les champs obligatoires
Consentement général⚠️ Consentement unique « accepter les conditions » à toutes fins utiles
⚠️ Consentement marketing combiné à la prestation de services dans une case à cocher unique
⚠️ Consentement fait en tout ou rien lorsque les finalités sont séparables
⚠️ Consentement enfoui dans des conditions générales de 20 pages
Police sans application⚠️ La politique de confidentialité décrit les pratiques idéales qui ne sont pas appliquées techniquement
⚠️ Formation des utilisateurs mise sur la prévention de l’accès inapproprié aux données
⚠️ Principes de confidentialité documentés sans mettre en œuvre de contrôles techniques
⚠️ Conformité de la politique assumée sans suivi ni validation
Demandes manuelles de la personne concernée⚠️ Les demandes GDPR/CCPA traitées via des tickets informatiques manuels prenant des mois
⚠️ Aucune procédure documentée d’accès, de rectification, d’effacement, de portabilité
⚠️ La fenêtre de demande-complétion des ensembles de réglementations régissant votre déploiement est manquée
⚠️ Demander l’inexistence des workflows détectés pendant les audits
Partage excessif de données⚠️ Accès élargi aux données accordé entre les ministères sans justification exprès
⚠️ Marketing autorisé à accéder aux détails des requêtes de support
⚠️ Ventes a autorisé l’accès aux historiques de service client sans besoin documenté
⚠️ Public Lecture/Écriture OWD utilisé pour les objets contenant des données personnelles

Modèles

Où chercherÀ quoi ressemble le bien
Déploiement régional Hyperforce✅ Organisation provisionnée dans la région Hyperforce répondant aux exigences de résidence des données
✅ Le stockage et le traitement des données sont effectués dans les limites géographiques requises
✅ Exigences régionales documentées et validées avant le provisionnement
✅ Exigences multi-régions satisfaites via une architecture multi-organisations si nécessaire
Mappage de flux de données✅ Document de cartes de flux de données où les données proviennent, transitent et résident
✅ Transferts de données transfrontaliers identifiés et évalués par rapport aux réglementations
✅ Clauses contractuelles standard ou règles d’entreprise contraignantes pour les transferts internationaux
✅ Chemins de transit de données évalués pour la conformité de résidence, pas seulement l’emplacement de stockage
Portée de résidence des données✅ Emplacement de stockage de données (qui région Hyperforce)
✅ Emplacement de traitement des données (régions de calcul)
✅ Emplacement de stockage de sauvegarde
✅ Consigner et auditer l’emplacement de stockage du journal
✅ Chemins de transit d’intégration évalués pour le mouvement transfrontalier de données
Architecture multi-organisations✅ Architecture multi-organisations utilisée lorsque les exigences réglementaires ne peuvent pas être satisfaites dans une seule organisation
✅ Chaque organisation provisionnée dans la région appropriée pour ses données
✅ Les modèles d’intégration respectent les contraintes de résidence des données
✅ Compromis de complexité opérationnelle documentés dans les ADR
Validation de la conformité✅ Exigences de résidence des données documentées par juridiction
✅ La sélection de la zone Hyperforce validée par rapport aux exigences avant provisionnement
✅ Les audits périodiques confirment que les données restent dans les limites requises
✅ Les modifications apportées aux règlements de résidence déclenchent un examen de l’architecture

Anti-modèles

Où chercherÀ quoi ressemble mal
Surveillance de la résidence⚠️ Infractions à la résidence des données découvertes lors d’audits de conformité
⚠️ Organisations provisionnées sans évaluation des besoins régionaux
⚠️ « Cloud is Cloud » assumé sans prendre en compte les réglementations de localisation des données
⚠️ Compétences ajoutées sans révision des obligations de résidence
Transit ignorant la résidence⚠️ Seul l’emplacement de stockage pris en compte lorsque les chemins de transit sont ignorés
⚠️ Données acheminées à travers les régions hors des limites de conformité
⚠️ Middleware d’intégration utilisé dans les régions non conformes
⚠️ Sauvegardes stockées dans des régions différentes des données principales
Multi-organisation inutile⚠️ Architecture multi-organisations utilisée lorsqu’une seule organisation avec des régions Hyperforce suffit
⚠️ Complexité opérationnelle, coûts de licence et frais généraux d’intégration multipliés sans nécessité réglementaire
⚠️ Multi-organisations implémenté « juste pour être sûr » sans exigence de conformité spécifique
⚠️ Multi-organisation utilisé par défaut lorsque la classification des données et les contrôles d’accès sont suffisants