Sécurité et partage des données dans Data Cloud

Data Cloud centralise des volumes de données personnelles souvent bien plus importants qu'un org CRM classique, ce qui en fait un point d'attention prioritaire en matière de sécurité et de gouvernance. Le modèle de sécurité s'appuie en partie sur des concepts familiers issus du CRM Salesforce (permission sets, profils), mais introduit aussi des mécanismes spécifiques au monde des données à grande échelle, qu'un consultant doit maîtriser avant toute mise en production.

Permissions et accès aux objets Data Cloud

L'accès aux fonctionnalités Data Cloud (créer un Data Stream, un segment, une activation) se gère via des permission sets standards comme Data Cloud Admin, Data Cloud User ou des permission sets custom construits sur les Data Cloud Permissions disponibles dans Setup. Le principe de moindre privilège s'applique ici avec d'autant plus d'importance que les Segments et Calculated Insights peuvent exposer des données sensibles agrégées à des utilisateurs qui n'auraient normalement pas accès au détail des enregistrements sources dans le CRM.

• Un utilisateur marketing qui construit des segments n'a pas nécessairement besoin d'un accès en création sur les Data Streams ou l'Identity Resolution.
• Séparez les rôles d'administration technique (Data Streams, DMO, Identity Resolution) des rôles d'exploitation métier (Segments, Activations), même si une même personne cumule parfois les deux dans une petite équipe.

Data Space comme frontière de sécurité

Au-delà de l'organisation logique par marque ou région (voir l'article dédié aux Data Spaces), le Data Space constitue aussi une frontière de sécurité : l'accès à un Data Space peut être restreint à certains utilisateurs ou groupes via les permissions dédiées, ce qui permet par exemple d'empêcher une équipe régionale d'accéder aux données d'une autre région, même au sein du même org Salesforce.

Row-Level Security et masquage de champs

Data Cloud propose des mécanismes de sécurité au niveau de la ligne (Row-Level Security) configurables sur les DMO, permettant de restreindre l'accès à un sous-ensemble d'enregistrements selon des critères définis (par exemple, un utilisateur régional ne voit que les profils de sa région). Pour les données particulièrement sensibles (informations de santé, données financières), un masquage de champ (Field-Level Masking) peut être appliqué pour que certains utilisateurs voient une valeur tronquée ou anonymisée plutôt que la donnée brute, même s'ils ont accès à l'enregistrement.

1. Identifiez les champs sensibles dès la phase de modélisation DMO, pas après la mise en production.
2. Configurez le masquage ou la Row-Level Security depuis la définition du DMO concerné dans Setup.
3. Testez avec un utilisateur de profil restreint pour valider que le masquage se comporte comme attendu avant le déploiement général.

Consentement et conformité réglementaire

Data Cloud intègre des objets dédiés à la gestion du consentement (opt-in, opt-out, préférences de communication par canal), consultables et filtrables comme n'importe quel autre DMO. Pour rester conforme au RGPD et aux réglementations équivalentes, ces objets de consentement doivent systématiquement être intégrés comme filtre dans les Segments destinés à l'activation marketing, et non traités comme une simple donnée descriptive parmi d'autres.

• Le droit à l'oubli (suppression sur demande) doit être géré via les processus de suppression Data Cloud, qui doivent propager la suppression à travers les Unified Individuals, les DMO liés, et les destinations déjà activées si nécessaire.
• Conservez une traçabilité claire de l'origine de chaque donnée personnelle ingérée (quel Data Stream, quelle source), indispensable pour répondre à un audit ou une demande d'accès d'une personne concernée.

Ne traitez jamais la conformité RGPD comme une case à cocher en fin de projet. Le modèle DMO, les règles d'Identity Resolution et les Data Spaces doivent être conçus dès le départ en tenant compte des exigences de consentement et de droit à l'oubli, car les revoir a posteriori sur une base de données déjà volumineuse est significativement plus coûteux.

Partage de données entre équipes et audit

Pour le partage interne, privilégiez les mécanismes natifs (permission sets, Data Space, Row-Level Security) plutôt que des contournements comme la duplication de segments avec des filtres légèrement différents pour chaque équipe, qui complique la gouvernance et augmente la surface d'exposition des données. Activez également les journaux d'audit disponibles (Setup > Event Monitoring, applicable à certains événements Data Cloud) pour tracer les accès aux données sensibles, en particulier sur les organisations soumises à des obligations réglementaires strictes (santé, finance, secteur public).