Trust

Chez Salesforce, Trust est notre valeur n°1. C'est le fondement de chaque décision architecturale sur la plate-forme. Pour les architectes, Trust se fait via un partenariat unique: Salesforce fournit une plate-forme sécurisée et conforme (l'infrastructure, les métadonnées et les outils nécessaires pour vous l'approprier) pendant que vous concevez des solutions sécurisées qui s'appuient sur cette fondation.

Ce partenariat fonctionne par le modèle de responsabilité partagée, qui est un cadre qui répartit clairement les responsabilités en matière de sécurité :

• Salesforce est responsable de la sécurité de la plate-forme, notamment de l'infrastructure, des correctifs et des certifications de conformité.
• Vous êtes responsable de la sécurité sur la plate-forme, notamment la configuration, les contrôles d'accès, le code personnalisé et la gouvernance des données.

Cette division est essentielle, car elle définit la responsabilité architecturale. Salesforce exploite une architecture multilocataire dans laquelle des milliers d'organisations partagent l'infrastructure. La plate-forme offre de solides protections de sécurité au niveau de l'infrastructure. Vos décisions architecturales déterminent si vos solutions spécifiques gagnent la confiance des parties prenantes.

Le modèle de responsabilité partagée vous charge de concevoir des solutions sécurisées pendant que la sécurité physique, la protection du réseau, le correctif de la plate-forme et le cryptage de l'infrastructure sont gérés pour vous. Vous pouvez ainsi vous concentrer sur la conception de solutions sécurisées basées sur cette base (par exemple, la gestion des identités et des accès, la protection des données, la sécurité de l'intégration, les pratiques de développement sécurisées, la conformité et l'adhésion réglementaire, et les capacités de réponse aux incidents).

Négliger Trust pendant la conception aggrave la dette technique. Une stratégie de cryptage manquante devient une modernisation coûteuse lorsque la réglementation change. Une intégration non régie devient une vulnérabilité lorsque les identifiants sont compromis. Instaurer la Trust dès le début est toujours moins coûteux que de la moderniser plus tard.

Trust couvre quatre dimensions architecturales qui fonctionnent ensemble de façon cohérente:

• Les contrôles de sécurité protègent les systèmes et les données
• La gestion de l'identité régit l'accès
• Les pratiques de confidentialité respectent l'agence utilisateur
• Les cadres de conformité satisfont aux obligations réglementaires

Les architectes qui conçoivent pour les quatre dimensions créent des solutions qui gagnent et maintiennent Trust par la transparence, le contrôle et la résilience.

À l'ère Agentic, Trust s'étend au contexte de confiance dans lequel les agents évoluent. Le contexte de confiance signifie que les agents accèdent à des données régies et vérifiées avec des frontières d’identité et d’autorisation claires, ce qui permet aux systèmes IA de raisonner et d’agir au nom des utilisateurs tout en préservant la sécurité, l’auditabilité et la conformité. La conception d'un contexte de confiance est fondamentale pour l'architecture Agentic Enterprise.

Ce pilier établit la base de sécurité de la plate-forme sur laquelle repose chaque solution Salesforce. Le pilier Agentic Trust s ' appuie sur cette base pour traiter les risques propres aux agents autonomes, notamment l ' injection rapide, la gouvernance de l ' action et les données auxquelles les agents ont accès pendant les temps de raisonnement. Il est important de concevoir d'abord la référence, puis de superposer les contrôles spécifiques à l'agent en suivant les consignes Agentic Trust.

Ce pilier est étroitement lié à d'autres préoccupations d'ordre général.

• La fiabilité dépend de l'infrastructure qui résiste aux attaques et se relève des violations.
• L'excellence opérationnelle nécessite des pipelines de déploiement sécurisés et des capacités de réponse aux incidents.
• L'équité exige un traitement transparent et éthique des données et des décisions algorithmiques.

Ensemble, ces piliers forment une approche unifiée, axée sur les solutions, à laquelle les organisations peuvent faire Trust pour leurs opérations les plus sensibles.

Dans le modèle de responsabilité partagée, Salesforce et les architectes doivent s ' acquitter de leurs responsabilités respectives en matière de Trust durable. Examinons de plus près ce que chaque partie doit sécuriser.

Salesforce est responsable de la sécurité de la plate-forme et de son infrastructure mondiale, notamment :

• Contrôles d'accès au centre de données, surveillance et protection de l'environnement
• Pour Hyperforce, le fournisseur de cloud sous-jacent (par exemple, AWS, Azure ou Google Cloud, selon l'instance) gère la sécurité physique du centre de données via une responsabilité déléguée. La documentation Infrastructure et sous-processeurs Salesforce identifie le fournisseur et les sous-processeurs de chaque service.

• Contrôles de sécurité au niveau de la couche réseau, notamment protection DDoS et détection des menaces
• Cryptage du trafic en transit (TLS 1.2+) et au repos (généralement AES-256)

• Réponse aux vulnérabilités et déploiement de correctifs de plate-forme via Salesforce (pour plus d’informations sur les avis de sécurité, visitez security.salesforce.com)
• Gestion de la sécurité du système d'exploitation et de l'infrastructure

• Certifications et attestations : Salesforce conserve les autorisations SOC 1/2/3, ISO 27001/27017/27018, FedRAMP (étendue à Government Cloud Plus et MuleSoft Government Cloud, pas à la plate-forme multilocataire commerciale) et PCI DSS Level 1.
• Appui réglementaire : Cela s'applique aux services éligibles à l'HIPAA avec des accords d'association commerciale (BAA) ou des programmes de conformité au RGPD.
• Pour plus d'informations, visitez trust.salesforce.com et compliance.salesforce.com.

• Architecture d'isolation locataire : Un noyau partagé, piloté par les métadonnées, partitionne les données et les métadonnées de chaque organisation par ID d'organisation. Par conséquent, une organisation ne peut pas accéder aux enregistrements d'une autre organisation, même si les deux fonctionnent sur une infrastructure partagée. Le noyau applique automatiquement la séparation à chaque requête, pas via une configuration que vous devez gérer.
• Cryptage au niveau de l'infrastructure dans l'infrastructure de repos et de sauvegarde : Les licences de plate-forme de base incluent Classic Encryption (AES-128 fournit uniquement des champs de texte personnalisés). Shield Platform Encryption nécessite une licence séparée (AES-256 permet d'apporter sa propre clé et fournit des champs, des fichiers et des pièces jointes standard et personnalisés).

Ces contrôles garantissent que la plate-forme reste sécurisée, fiable et conforme.

Vous êtes responsable de la sécurité de vos données, configurations et processus opérationnels.

• Identité et fédération : Pour l'authentification unique (SSO) et l'authentification multifacteur (MFA), vous devez vérifier l'identité de l'utilisateur.
• Restriction d'accès : Techniquement, les plages IP et les heures de connexion limitent la façon dont et quand les identités se connectent.
• Principe du moindre privilège (PoLP) : Utilisez le PoLP pour accorder l'accès uniquement aux rôles, profils et ensembles d'autorisations nécessaires à l'exécution de tâches individuelles.
• Gestion du cycle: de vie Suivez les consignes de gestion du cycle de vie des utilisateurs et de recertification de l'accès.

• Utiliser la classification des données, le masquage et la sécurité au niveau objet/champ/enregistrement
• Appliquer automatiquement les autorisations CRUD et les règles de partage
• Possédez, testez et déployez une stratégie éprouvée pour restaurer les données de votre organisation, en vous assurant que la perte de données ou la récupération de la corruption restent sous votre contrôle.

• Utilisez l'authentification API (par exemple, OAuth 2.0 ou JWT) et des identifiants nommés.
• Activez les utilisateurs d'intégration dédiés avec des ensembles d'autorisations PoLP afin que l'accès de chaque intégration soit limité et auditable séparément des utilisateurs humains.
• Sécurisez les points de terminaison et la validation système externe.

• Utilisez la Surveillance des événements, les pistes d'audit et l'intégration SIEM (Security Information and Event Management).
• Suivez les procédures de réponse aux incidents et les contrôles de sécurité.

• Utilisez un code personnalisé sécurisé (par exemple, Apex ou Lightning) et une validation d'entrée.
• Exécutez Apex en mode utilisateur pour appliquer automatiquement les autorisations d'objet, de champ et de partage dans le code.
• Suivez la prévention des injections et sécurisez les pratiques de développement.

• Maintenir le dispositif de conformité des solutions.
• Suivez les politiques de confidentialité/gestion du consentement et de rétention des données.

Certaines responsabilités nécessitent une collaboration :

• Réaction aux incidents de sécurité: Les deux parties participent aux activités de détection et d'intervention.
• Gestion des vulnérabilités: Salesforce corrige la plate-forme, les architectes corrigent le code personnalisé.
• Surveillance de sécurité: Combinez les signaux de sécurité générés par la plate-forme à l'analyse de l'architecte.
• Certifications de conformité: Salesforce certifie la plate-forme (par exemple, SOC, ISO et FedRAMP pour Government Cloud). Les architectes sont propriétaires des éléments qui s'appuient dessus (objets personnalisés, code, intégrations et configuration) dans le cadre de la posture certifiée afin de fournir des preuves de conformité pour les audits.
• Fédération d'identité: Salesforce fait confiance aux affirmations émises par le fournisseur d'identité de l'architecte. Les architectes maintiennent la sécurité du fournisseur et la relation Trust entre le fournisseur et Salesforce.
• Gestion des clés: En utilisant le cryptage par clé, Salesforce exploite le service de cryptage pendant que les architectes génèrent, permutent et révoquent le matériel de clé qui protège les données.

Chaque principe de conception, section de rubrique et élément de liste de contrôle de ce document représente votre responsabilité en tant qu'architecte. Le modèle de responsabilité partagée encadre ce que vous devez concevoir et configurer pour obtenir Trust sur la plate-forme Salesforce.

La frontière s'étend aux obligations réglementaires. Salesforce gère les certifications et les attestations de la plate-forme et protège l'infrastructure contre les violations. Les architectes sont responsables des obligations liées à vos données et juridictions (par exemple : Quelles lois s'appliquent, comment les données sont classées, quelles règles de conservation et de consentement les régissent, et comment vous détectez et signalez les violations des données sous votre contrôle). Par rapport aux règlements régissant vos déploiements, les architectes doivent déterminer les valeurs précises sous-jacentes à ces obligations (par exemple, les délais de conservation et les délais de notification) par rapport au règlement régissant votre déploiement, car elles peuvent varier selon la juridiction et évoluer au fil du temps.

Utilisez ces principes pour guider vos décisions architecturales en matière de sécurité sur la plate-forme.

• Appliquez zéro Trust à toutes les couches. Ne supposez jamais Trust basé sur l'emplacement du réseau, la familiarité des utilisateurs ou l'origine du système. Vérifiez explicitement chaque demande d'accès avec l'authentification, l'autorisation et le cryptage au niveau des couches données, application, intégration et infrastructure. L'architecture multilocataire signifie que vous partagez l'infrastructure avec des milliers d'organisations. Par conséquent, le réseau sur lequel votre solution fonctionne n'est pas un périmètre que vous pouvez traiter comme fiable. Vérifiez chaque demande en fonction de son bien-fondé (identité, autorisation et contexte) plutôt que de lui faire confiance pour son origine.
• Accordez le moindre privilège par défaut. Accordez le niveau d'accès minimum nécessaire à chaque utilisateur, intégration et processus automatisé pour atteindre son objectif. Commencez par les paramètres les plus restrictifs (par défaut à l'échelle de l'organisation) et autorisations minimales), puis agrandissez délibérément en fonction des exigences métiers documentées. Utilisez le modèle d'accès à quatre couches (organisation → objet → champ → enregistrement) afin de limiter davantage les couches ci-dessus.
• Mettez en œuvre la défense en profondeur. Superposez plusieurs contrôles de sécurité afin d'éviter que l'échec d'un contrôle ne compromette l'ensemble du système. Combinez des contrôles préventifs (par exemple, l'application de la loi CRUD/FLS et des stratégies de sécurité des transactions qui bloquent les opérations), des contrôles de détection (par exemple, la surveillance des événements) et des contrôles réactifs (par exemple, l'authentification et la notification renforcées de la sécurité des transactions). Concevez chaque couche comme si les couches adjacentes risquaient d'échouer. Pour rappel, la sécurité au niveau du champ protège les données même lorsque les règles de partage sont trop permissives.
• Intégrez la sécurité dès la conception. Intégrez la modélisation des menaces, les exigences de sécurité et la validation du contrôle à chaque phase de l'architecture, depuis le concept initial jusqu'à l'évolution continue. Effectuez la modélisation des menaces par usurpation, altération, répudiation, divulgation d'informations, déni de service et élévation de privilège (STRIDE) avant le début de la construction. La sécurité détermine la sélection de la technologie et les décisions de conception.
• Incorporez la sécurité à l'automatisation. Élaborez des contrôles de sécurité dans des pipelines automatisés, des modèles de configuration et des paramètres par défaut de plate-forme. Salesforce Code Analyzer dans CI/CD détecte les vulnérabilités avant le déploiement. La configuration en tant que code applique les normes de sécurité de base. La sécurité incorporée garantit la cohérence et permet d'adapter la sécurité à la complexité des solutions.
• Concevez pour la confidentialité. Incorporer les principes de confidentialité dès la phase initiale de l'architecture. Conçu pour la réduction des données (collecter uniquement les données nécessaires), la limitation des finalités (limiter l'accès par fonction), la gestion du consentement (appliquer un consentement précis et spécifique à l'objet) et les droits de la personne concernée (activer les workflows d'accès, de rectification, d'effacement et de portabilité à réaliser dans les délais réglementaires).
• Conception pour la traçabilité. Rendre chaque action consécutive attribuable et reconstructible après coup, avant de s'appuyer sur la détection d'anomalies dans celle-ci. Assurez-vous que les modifications apportées aux données, aux autorisations et à la configuration sont capturées dans les pistes d'audit, l'historique des champs et les journaux des événements, et conservez ces enregistrements dans un espace de stockage inviolable. La traçabilité est la condition préalable à la détection, à la criminalistique et à la responsabilité. Rappelez-vous, vous ne pouvez pas enquêter sur ce qui n'a jamais été enregistré.
• Conception pour la réponse à un incident. Conçu pour la détectabilité via la Surveillance des événements et pour l'intervention en temps réel via des stratégies de sécurité des transactions. Activez une réponse rapide à travers des procédures documentées et des frontières d'isolement. Prenez en charge la récupération grâce aux capacités de sauvegarde et à la préservation judiciaire. Testez les réponses à travers des exercices sur table et des simulations d'infraction.

Les architectes sont responsables de la sécurisation des solutions sur la plate-forme fournie par Salesforce.

Les charges de travail qui interagissent avec Salesforce s'exécutent de plus en plus hors de la plate-forme principale (services d'intégration, applications personnalisées et clients headless appellent fréquemment des API Salesforce, souvent au nom d'un utilisateur. Pour accélérer ce schéma, Salesforce expose les capacités de la plate-forme en tant qu'API, outils et commandes (par exemple, Salesforce Headless 360). Peu importe qui exploite ces applications, l'architecte est propriétaire de la frontière Trust où ils rencontrent Salesforce afin de déterminer comment ils s'authentifient, quelle identité et quelles autorisations ils portent, quels secrets ils détiennent et quelles données franchissent la frontière.

Les principes ci-dessous s'appliquent à toute plate-forme d'intégration conteneurisée (par exemple, MuleSoft CloudHub).

Lorsqu'un client externe s'authentifie en tant qu'utilisateur nommé, le modèle de sécurité de la plate-forme de Salesforce s'applique automatiquement. Les autorisations d'objet, la sécurité au niveau du champ et les règles de partage sont appliquées exactement comme dans le navigateur. L'authentification par utilisateur limite chaque appel aux autorisations de cet individu et préserve le journal d'audit, ce qui signifie que la révocation du jeton d'un utilisateur retire immédiatement au client la possibilité d'agir en son nom. Préférez-le à un compte de service partagé où que le travail soit effectué pour un utilisateur spécifique.

Concevez la frontière de façon défensive, car un client qui détient des jetons pour de nombreux utilisateurs concentre Trust et devient un proxy de grande valeur pour un assaillant: un seul jeton OAuth volé peut atteindre les données de chaque utilisateur servi par le client. Ce n'est pas hypothétique. L'incident de Salesloft Drift 2025 a vu des assaillants voler des jetons OAuth et les utiliser pour atteindre les données Salesforce dans des centaines d'organisations.

• Propagez l'identité des utilisateurs, ne la mettez pas en commun. Utilisez l'authentification par utilisateur ou l'échange de jetons OAuth 2.0 pour transmettre l'identité d'un utilisateur à travers les sauts de service (consultez Identité et authentification de l'agent), afin d'appliquer les compromis au contexte d'un utilisateur plutôt qu'à tous les utilisateurs.
• Traitez les identifiants client OAuth et les jetons d'actualisation comme cible principale. Stockez-les dans un magasin de secrets gérés, permutez-les fréquemment et conservez les conceptions pour une révocation immédiate. Surveillez l'utilisation de l'API pour détecter les modèles anormaux qui signalent un assaillant proxy.
• Réduisez la portée des deux côtés. Limitez les étendues OAuth de l'application cliente externe (ECA) et les autorisations Salesforce de l'utilisateur de l'intégration au minimum requis par la fonction, de sorte qu'un client compromis ne puisse pas pivoter vers des données non associées.
• Gouvernez la frontière via des applications clientes externes. Les ECA définissent comment une application externe s'authentifie, quels flux sont autorisés et quelles étendues s'appliquent, et conçoivent de nouvelles intégrations en fonction de ces flux (voir Architecture d'authentification).

Soyez prudent lorsqu'un client est exécuté en tant qu'Utilisateur agent ou Utilisateur d'intégration : ces identités peuvent fonctionner dans un contexte élevé (souvent contre des systèmes externes qui ne respectent pas les contrôles d'accès de Salesforce). Par conséquent, l'utilisation de la discipline d'autorisation et de surveillance décrite ci-dessus permet de maintenir ce pouvoir lié.

Lorsque les intégrations sont exécutées sur une plate-forme conteneurisée, l'isolation au niveau du conteneur est en soi considérée comme un contrôle de sécurité : chaque application est exécutée dans un conteneur dédié sans exécution partagée ni mémoire entre les applications.

Cet isolement fournit :

• Application des limites des locataires : Les applications compromises ne peuvent pas accéder aux données ou aux ressources des applications voisines qui partagent le même environnement. Chaque conteneur a un système de fichiers et un espace de traitement isolés. Forcez l'isolation du réseau via la configuration du pare-feu et du protocole TLS, et limitez explicitement le trafic sortant plutôt que de dépendre de paramètres par défaut permissifs.
• Défense approfondie : L'isolation du conteneur ajoute une couche de sécurité qui dépasse les contrôles au niveau de l'application. Même si le code de l'application contient des vulnérabilités, les limites du conteneur limitent le rayon d'explosion.
• Segmentation de la conformité : Les charges de travail réglementées (par exemple, PCI et HIPAA) peuvent être isolées dans des conteneurs dédiés, ce qui empêche le mélange de charges de travail non conformes.

Les architectes qui conçoivent des environnements multi-applications doivent s'appuyer sur l'isolation des conteneurs pour appliquer la séparation des tâches et des domaines de sécurité. Les intégrations de services financiers qui gèrent les données des détenteurs de carte doivent être exécutées dans des conteneurs séparés des intégrations marketing, même dans le même environnement.

Le trafic interconteneurs devrait être crypté et le protocole TLS mutuel (mTLS) devrait être appliqué lorsqu'un cadre réglementaire exige l'authentification des deux côtés:

Comment ça marche :

• Configurez des contextes TLS afin d'activer le protocole TLS mutuel facultatif (mTLS) pour les connexions entrantes si nécessaire.
• Utilisez SSL au niveau de la plate-forme avec l'authentification par certificat client pour sécuriser la communication entre les services de la plate-forme et les répliques.
• Configurez des contextes TLS pour activer le mTLS lorsque les cadres réglementaires l'exigent.
• Gérez les certificats via le magasin de certificats de la plate-forme afin de centraliser le cycle de vie et la révocation.
• Appliquer les limites d'isolation du réseau qui empêchent le trafic non autorisé entre les conteneurs.

Le cryptage du trafic au niveau de la couche de plate-forme fournit une défense en profondeur pour les données en transit. Même si le HTTPS de la couche applicative est mal configuré, le trafic des conteneurs reste crypté.

Les conteneurs qui se connectent à des systèmes sur site via un VPN doivent concevoir une protection des données en transit :

• Cryptage du tunnel : Acheminez tout le trafic entre les conteneurs et les systèmes sur site à travers des tunnels VPN cryptés. Cela s'applique quel que soit le TLS de la couche application. Une défense approfondie garantit le double cryptage des données confidentielles.
• Application de la segmentation du réseau : Les stratégies de tunnel VPN limitent les réseaux sur site que les conteneurs peuvent atteindre. Les conteneurs compromis ne peuvent pas pivoter vers des systèmes internes non autorisés au-delà des réseaux autorisés par VPN.
• Preuve de conformité : Le cryptage VPN est l'un des mécanismes acceptés pour protéger les données en transit vers et depuis des environnements Cloud. Les auditeurs qui examinent les contrôles HIPAA, PCI-DSS ou SOX s'attendent à ce que le cryptage documenté soit en transit pour les intégrations hybrides.

Les architectes doivent concevoir des stratégies VPN qui appliquent automatiquement l'accès réseau à moindre privilège. Les conteneurs d'intégration marketing ne doivent pas être acheminés vers des systèmes financiers internes, même si les deux sont accessibles via un VPN.

Les domaines Vanity (par exemple, les URL personnalisées des API d'intégration) nécessitent des architectes pour gérer les certificats TLS en tant qu'ancrages Trust :

Les domaines de vanité (par exemple, les URL personnalisées des API d'intégration) nécessitent que les architectes gèrent les certificats TLS en tant qu'ancrages Trust.

• Automatisation du cycle de vie des certificats : Implémentez le renouvellement et le déploiement automatisés des certificats. Les certificats expirés brisent Integration Trust; les clients rejettent les connexions qui contiennent des erreurs de validation de certificat.
• Planification de la révocation du certificat : Concevez des procédures de rotation des certificats pour les incidents de sécurité. Les clés privées compromises nécessitent une réémission et un déploiement rapides de certificats dans toutes les régions.
• Configuration de la suite de chiffrement : Les anciennes configurations TLS (TLS 1.0/1.1 et faible cryptage) échouent aux audits de conformité. Appliquez le protocole TLS 1.2+ (exigence minimale) et alignez les configurations de certificats et de clients sur les stratégies de sécurité de l'organisation.
• Consignation de la transparence du certificat : Les certificats TLS modernes sont soumis aux journaux publics de transparence des certificats (CT) par les autorités de certification (CA). Chaque journal CT renvoie un Signed Certificate Timestamp (SCT), une preuve cryptographique de consignation, que l'autorité de certification incorpore au certificat via une extension X.509v3. Les architectes doivent surveiller l'émission non autorisée de certificats dans les journaux CT de leur domaine, en utilisant des services tels que crt.sh ou des alertes automatisées.

Une mauvaise gestion des certificats impacte directement Trust posture:

• Certificats expirés : Entraîner des échecs d'authentification qui apparaissent comme des pannes. La surveillance doit inclure l'envoi d'alertes dans les 30 jours ou plus avant l'expiration pour permettre le démarrage des workflows de renouvellement.
• Certificats auto-signés : Brisez les chaînes Trust pour des clients externes. Les intégrations en production nécessitent des certificats signés par des autorités de certification de confiance.
• Étalement des certificats de carte bancaire : Correspond à des certificats génériques trop larges (par exemple, *.company.com) qui créent un rayon d'explosion important s'ils sont compromis. Les certificats à portée étroite sont préférés par domaine d'intégration.

Les zones de déploiement de conteneurs doivent respecter les exigences de résidence des données et de conformité.

• Résidence de données RGPD : Le RGPD exige une protection adéquate des données personnelles qui quittent l’Union européenne (UE), mais pas le déploiement de l’UE en tant que tel. Le déploiement d'intégrations dans une région de l'UE permet de maintenir le calcul des conteneurs et le traitement des données dans les limites réglementaires, ce qui est le moyen le plus direct de satisfaire à cette exigence. Les transferts effectués hors de l'UE restent autorisés par une décision d'adéquation, des clauses contractuelles types (CCN) ou des règles d'entreprise contraignantes (RCO).
• Lois de localisation des données : Les pays qui ont des exigences de localisation des données comprennent : Russie (loi fédérale 152-FZ et stockage obligatoire) et Chine (PIPL/CSL pour les CIIO), qui peuvent exiger le déploiement de conteneurs dans le pays. La loi DPDP de 2023 en Inde utilise une approche de liste noire qui n'impose pas un mandat général de stockage dans le pays. Les transferts de données sont autorisés vers n'importe quel pays, sauf restriction spécifique par une notification gouvernementale. Les architectes doivent comprendre les règlements propres à une juridiction.
• Mécanismes transfrontaliers de transfert de données : Lorsqu'un déploiement multirégional est nécessaire, mais que les données doivent traverser les frontières, les architectes doivent implémenter des CCN, des RCO ou d'autres mécanismes de transfert légal.
• Alignement de certification de conformité : Les zones de déploiement de conteneurs doivent correspondre aux certifications de conformité Salesforce. Les charges de travail autorisées par FedRAMP nécessitent un déploiement régional aux États-Unis. Pour les intégrations certifiées HITRUST, vous devez vérifier que la région de déploiement correspond à une étendue d'attestation HITRUST active.

Les décisions de déploiement régional sont des responsabilités d'architecte qui impactent directement la conformité réglementaire. Les équipes financières peuvent imposer un déploiement aux États-Unis uniquement pour les intégrations contrôlées par SOX. Les équipes soignantes peuvent avoir besoin de régions certifiées HITRUST pour traiter les informations de santé personnelles (PHI).

Les conteneurs doivent avoir accès aux identifiants, aux clés d'API et aux clés de cryptage. Les architectes doivent concevoir des processus de gestion des secrets qui empêchent l'exposition :

• Pas de secret codé en dur : N'incorporez jamais d'identifiants dans un code d'application ou des fichiers de configuration déployés dans des conteneurs. Utilisez des magasins de secrets gérés par la plate-forme.
• Injection secrète gérée par la plate-forme : Résolvez les secrets à l'exécution depuis le magasin géré de la plate-forme (au lieu de les conserver dans le système de fichiers) et marquez les valeurs de configuration contenant des identifiants comme protégées afin de ne pas les exposer dans les journaux ou dans la console.
• Rotation des secrets: Concevez des intégrations pour gérer gracieusement les secrets permutés. Les modèles d'actualisation de jeton OAuth, les workflows de rotation de clé d'API et les changements de mot de passe de base de données ne doivent pas nécessiter de redéploiement de conteneur.
• Accès aux secrets les moins confidentiels : Accordez aux conteneurs l'accès uniquement aux secrets requis pour leur fonction. Les intégrations marketing ne devraient pas accéder aux identifiants du système financier, même lorsqu'elles partagent le même environnement.

Les secrets exposés sont des incidents de sécurité d'intégration courants. Les architectes doivent concevoir des processus de gestion des secrets qui peuvent survivre aux révisions de code, aux journaux, aux messages d'erreur et aux tableaux de bord de surveillance sans fuite d'identifiants.

Les applications à la frontière de Salesforce génèrent des événements d'audit qui remplissent les exigences de consignation de conformité :

• Consignation des demandes/réponses : Consigne les requêtes d'API, les réponses et les décisions d'acheminement. Les équipes de conformité utilisent ces journaux pour des audits d'accès afin de déterminer qui a accédé à quelles données à quelle heure.
• Consignation des erreurs et des exceptions : Capture les événements de sécurité (par exemple, échecs d'authentification, refus d'autorisation et certificats non valides) dans les journaux du conteneur. L'intégration SIEM active la surveillance de la sécurité en temps réel.
• Stratégies de rétention des journaux : Les architectes doivent configurer des périodes de rétention conformes aux exigences réglementaires. Ces minimums sont fixés par règlement, diffèrent selon le cadre et évoluent au fil du temps. Par conséquent, ils doivent être dérivés d'une source de conformité bien tenue qui vérifie chaque chiffre par rapport au règlement en vigueur plutôt que par des valeurs de codage en dur.
• Cryptage du journal et contrôles d'accès : Les journaux d'audit peuvent contenir des métadonnées confidentielles. Les journaux doivent être cryptés au repos et l'accès contrôlé uniquement pour le personnel de sécurité/conformité autorisé. Une consignation insuffisante empêche les enquêtes sur les incidents et échoue aux audits de conformité. Les architectes doivent trouver un équilibre entre la verbosité de la consignation (par exemple, l'impact sur les performances et les coûts de stockage) et les besoins d'enquête de conformité et de sécurité.

La modélisation des menaces doit faire partie de la conception de vos solutions, plutôt qu'une étape séparée qui se produit avant ou après. Dès que vous avez une conception candidate à raisonner, vous devez modéliser ses menaces potentielles, et revisiter le modèle à mesure que la conception évolue. Ainsi, la sécurité façonne l'architecture au lieu d'être réaménagée sur la ligne. Salesforce gère la sécurité de l'infrastructure (par exemple, la protection du réseau, le durcissement du système d'exploitation et la gestion des vulnérabilités), mais vous devez identifier les risques au niveau de la couche applicative dans votre configuration, vos intégrations et votre code personnalisé. Appliquez l'infrastructure STRIDE (usurpation, altération, répudiation, divulgation d'informations, déni de service, élévation de privilèges) aux vecteurs de menace spécifiques à Salesforce répertoriés ci-dessous. Identifiez les limites Trust où les données traversent les systèmes, les réseaux ou les niveaux de privilèges.

Appliquez l'infrastructure STRIDE aux considérations de modélisation des menaces spécifiques à Salesforce suivantes :

• Les flux de données multi-organisations créent des limites Trust supplémentaires qui nécessitent une authentification et une autorisation explicites à chaque passage.
• Les intégrations externes utilisent des API et des middlewares, ce qui peut introduire des vecteurs d'attaque qui contournent les contrôles de sécurité de la plate-forme.
• Les composants Apex et Lightning nécessitent une analyse de codage sécurisée pour l'injection, le XSS et l'application automatique du contrôle d'accès.
• Les sites Experience Cloud élargissent la surface d'attaque aux utilisateurs non authentifiés ou légèrement authentifiés.
• Un code ISV (par exemple, des packages gérés, des listes AgentExchange, des applications connectées, des connecteurs tiers, des bibliothèques JavaScript côté client et les services d'IA externes que vos agents appellent) est un vecteur de chaîne d'approvisionnement qui traverse votre frontière Trust, à l'installation ou à l'exécution.

Le code tiers et ISV fait partie de votre Trust Boundary.

Les packages gérés ou les fiches AgentExchange sont exécutés dans votre organisation avec les autorisations que vous leur accordez. Par conséquent, leur dispositif de sécurité devient votre dispositif de sécurité dès que vous les installez. Salesforce Security Review vérifie chaque package répertorié avant qu'il n'atteigne AppExchange ou AgentExchange ; vous êtes propriétaire de tout ce qui passe après cette porte :

• Évaluation du package par rapport à votre propre classification des données et posture de risque
• En lui accordant le moins de privilèges que sa fonctionnalité documentée nécessite
• Tenue à jour avec les versions de l'éditeur
• Surveillez son activité avec les mêmes contrôles de Surveillance des événements et d'audit que vous appliquez à votre propre code.

Appliquez des contrôles de sécurité à chaque couche de la pile de solutions. Notez que la compromission d'une couche ne doit pas exposer le système complet.

Concevez chaque couche comme si les couches supérieures et inférieures risquaient d'échouer. N'oubliez pas que plusieurs contrôles indépendants créent de la résilience.

Zero Trust élimine la Trust implicite basée sur la position du réseau ou l'état d'authentification préalable. Chaque demande doit être authentifiée et autorisée indépendamment.

Appliquer zéro Trust à :

• Accès utilisateur via une vérification continue avec la MFA, des stratégies de session et un accès conditionnel basé sur le contexte (par exemple, IP, appareil, heure et comportement)
• Connexions d'intégration via la validation de jeton OAuth à chaque appel, TLS mutuel basé sur le certificat et liste d'autorisations IP
• Communication intersystèmes par authentification explicite, qui s'applique également aux systèmes internes de confiance
• Accès aux données via l'application automatique CRUD et FLS à chaque requête et opération, quel que soit le contexte d'appel

Inventaire des actifs de sécurité est une entrée de conception de sécurité : vous pouvez uniquement modéliser les menaces, appliquer le moindre privilège et surveiller une surface d'attaque que vous avez d'abord énumérée. Par conséquent, le suivi de vos actifs liés à la sécurité appartient aux décisions de conception qui en dépendent. Cela se distingue de la gestion de la configuration opérationnelle que couvre l'Excellence opérationnelle (par exemple, la gestion des versions des paramètres de l'organisation et la détection des écarts de configuration pour la stabilité opérationnelle). En d'autres termes, la préoccupation ici est plus étroite: quels actifs comportent des risques de sécurité et pourquoi ?

Tenez à jour l'inventaire de tous les actifs liés à la sécurité, y compris les objets personnalisés stockant des données confidentielles, les intégrations système externes, les API accessibles au public, les comptes privilégiés, les autorisations d'accès en production et les packages installés avec des autorisations élevées.

Votre inventaire des actifs de sécurité doit inclure :

• Objets et champs personnalisés contenant des données confidentielles ou restreintes
• Points de terminaison d'intégration et mécanismes d'authentification
• Utilisateurs avec des privilèges élevés (par exemple, Modifier toutes les données, Afficher toutes les données et Gérer les utilisateurs)
• Utilisateurs de l'intégration API uniquement et leurs étendues d'autorisation
• Applications clientes externes (ECA) et leurs étendues OAuth, ainsi que toutes les applications connectées héritées encore présentes dans l'organisation
• Packages AgentExchange installés et leurs autorisations accordées
• Les sites Experience Cloud et leurs modèles d'authentification et de partage externe
• Classes Apex personnalisées avec des modes de partage élevés
• Accordez une attention particulière aux classes héritées : code compilé à l'API version 66.0 ou antérieure, qui omet une déclaration de partage par défaut sur « without sharing » (par exemple, mode système, contournement de l'accès aux enregistrements de l'utilisateur actif). Notez qu'à partir de l'API version 67.0 (Summer '26), une déclaration omise est définie par défaut sur « with sharing » et que les opérations de base de données sont exécutées en mode utilisateur. Cependant, les classes existantes gardent l'ancien comportement jusqu'à leur recompilation à la version 67.0 (ou supérieure). Par conséquent, les classes non déclarées reportées des versions antérieures restent silencieusement élevées.

Il est de votre responsabilité de concevoir et de configurer des contrôles d'identité qui appliquent le moindre privilège.

Examinons de plus près comment concevoir et configurer correctement des contrôles en utilisant le PoLP.

Salesforce applique automatiquement le contrôle d'accès à travers quatre couches distinctes : organisation, objet, champ et enregistrement. Vous devez concevoir des solutions qui exploitent délibérément les quatre couches. Le contrôle d'accès principal est basé sur l'octroi, ce qui signifie que l'accès est additif et que les utilisateurs doivent l'obtenir à chaque couche pour atteindre un enregistrement. Il n'y a pas de règle généralisée « refuser les remplacements autoriser » dans la plate-forme principale. Par conséquent, vous ne pouvez pas vous opposer à un refus ciblé pour annuler l'accès à une subvention large déjà accordée.

Les couches supérieures permissives ne vous coûtent pas la capacité de restreindre, mais elles augmentent les efforts : L'élargissement anticipé des paramètres par défaut ou des autorisations d'objet à l'échelle de l'organisation implique de s'appuyer sur la sécurité au niveau du champ et la configuration du partage pour récupérer un accès qui n'aurait jamais dû être accordé.

Les règles de restriction et les autorisations de désactivation sont deux exceptions intégrées qui soustraient l'accès, mais chacune a une portée étroite (règles de restriction au filtrage au niveau de l'enregistrement et désactivation des autorisations accordées dans un groupe d'ensembles d'autorisations), pas une couche de refus généralisée.

Définissez OWDs sur Privé pour les objets contenant des données confidentielles. L'ouverture des OWD en lecture seule publique, et encore moins en lecture/écriture publique, expose les enregistrements de façon globale et réduit votre capacité à restreindre l'accès ultérieurement sans réarchitecture potentiellement significative. La dette Trust la plus courante dans les organisations matures provient des OWD permissifs définis lors de la mise en œuvre initiale.

La couche d'enregistrement suit un modèle grant-then-restrict, souvent représenté sous forme de pyramide de partage : Les OWD définissent la base restrictive, et la hiérarchie des rôles, les règles de partage et le partage manuel ouvrent l'accès vers le haut. Deux contrôles inversent ce flux pour retirer l'accès au lieu de l'accorder, et les deux méritent d'être conçus délibérément.

• Les règles de restriction filtrent ce que les utilisateurs peuvent afficher dans les enregistrements auxquels ils ont déjà accès. Par conséquent, les utilisateurs qui ont un accès étendu aux objets affichent uniquement le sous-ensemble autorisé par une règle.
• Les autorisations de désactivation soustraient des autorisations spécifiques dans un groupe d'ensembles d'autorisations. Vous pouvez ainsi assembler l'accès à partir de groupes réutilisables, puis retirer ce qu'une population donnée ne devrait pas avoir.
• Accédez à ces règles lorsque les couches basées sur l'octroi vous obligeraient à surprovisionner ou à fragmenter l'accès en de nombreux ensembles d'autorisations étroits.

Appliquer automatiquement la MFA (authentification multifacteur) pour tous les utilisateurs qui se connectent à des environnements de production via l'interface utilisateur, que Salesforce impose en tant qu'exigence de plate-forme. Cette exigence ne s'étend pas à l'accès API uniquement : Les intégrations utilisant des flux porteur JWT ou identifiants client sont exemptées. Par conséquent, vous devez protéger ces intégrations à la place avec la gestion des certificats et des restrictions IP. Étendez les exigences de la MFA aux opérations privilégiées.

Pour l'authentification unique (SSO), les protocoles SAML 2.0 ou OpenID Connect sont préférés. Configurez des stratégies de session pour concilier sécurité et convivialité :

• Expiration de session: Configurez des expirations de session adaptées aux niveaux de privilège utilisateur (des expirations plus courtes pour les comptes à privilèges élevés réduisent les risques liés aux sessions sans participation).
• Restrictions IP: Appliquez des restrictions aux profils administratifs et aux utilisateurs de l'intégration.
• Heures de connexion: Limitez les comptes de service aux fenêtres opérationnelles attendues.
• Activation de l'appareil : Utilisez l'activation native de l'appareil Salesforce (vérification de l'identité pour les connexions à partir d'appareils non reconnus), et ajoutez des restrictions MFA et IP pour les comptes à privilèges élevés. La posture Native Device Trust est appliquée via un fournisseur d'identité externe.
• Verrouillage IP de session: Verrouillez les sessions sur l'adresse IP d'où elles proviennent, afin d'empêcher la relecture d'un ID de session volé depuis un autre emplacement réseau. Cela renforce la sécurité, mais ajoute des frictions pour les utilisateurs mobiles et peut rompre les intégrations automatisées. Lorsque le verrouillage n'est pas viable, appliquez les Plages IP de connexion strictes au niveau du profil avec « Appliquer les plages IP de connexion à chaque requête » comme contrôle de compensation.
• Séances d'assurance élevée: Exiger un niveau de sécurité de session Assurance élevée, via des stratégies de niveau de sécurité de session et des stratégies d'accès, pour les opérations confidentielles (telles que l'accès à des rapports ou la gestion de plages IP), afin qu'une connexion de routine ne puisse pas atteindre en soi des actions à fort impact. Dans Lightning Experience, l'augmentation d'une session standard vers Assurance élevée en demandant de nouveau la MFA n'est pas prise en charge. Par conséquent, l'étendue de cette stratégie sachant que les utilisateurs de session standard sont bloqués par l'opération fermée au lieu d'être invités à élever.
• Protection contre les cookies: Demandez l'attribut HttpOnly afin d'empêcher les scripts de lire le cookie ID de session, et verrouillez les sessions sur le domaine dans lequel elles ont été utilisées pour réduire le piratage de session.
• Accès API uniquement pour les utilisateurs de l'intégration: Limitez les comptes d'intégration et de service à l'authentification API uniquement avec l'autorisation Utilisateur API uniquement, afin qu'ils ne puissent pas se connecter via l'interface utilisateur. Pour les nouvelles versions, attribuez le profil Accès minimal - Intégrations API uniquement à la licence utilisateur Salesforce Integration. L'ancien profil Intégration système API uniquement Salesforce n'est pas disponible dans les organisations provisionnées à partir de Spring '24. Par conséquent, concevez de nouvelles intégrations par rapport au profil actuel plutôt que par rapport au profil déprécié.

Pour l'authentification d'API, sélectionnez les flux OAuth 2.0 appropriés au modèle d'intégration :

• Écoulement porteur JWT: Utilisez-le pour les intégrations serveur à serveur exécutées en tant qu'utilisateur de l'intégration (basées sur un certificat, préférées pour les environnements de confiance).
• Flux serveur Web (code d'autorisation, avec PKCE): Utilisez-le pour les applications Web qui nécessitent une autorisation utilisateur et pour les intégrations serveur à serveur qui doivent gérer un contexte utilisateur spécifique (stockage de jetons d'actualisation côté serveur afin d'éviter les invites répétées du navigateur).
• Sécurisez la lecture du flux Code d'autorisation : Forcez l'extension PKCE afin qu'un code d'autorisation intercepté ne puisse pas être échangé par une personne autre que le client qui l'a demandé, et permutez les jetons d'actualisation (en émettant un nouveau à chaque utilisation et en invalidant le précédent) afin d'avoir une fenêtre de validité étroite. La réutilisation d'un compromis de signal de jeton retiré.
• Flux Code d'autorisation et identifiants d'identité headless (avec PKCE) : Utilisez-le pour des clients sans navigateur véritablement headless qui doivent être exécutés dans le contexte d'un utilisateur spécifique. Le flux serveur Web basé sur la redirection suppose un navigateur que ces clients n'ont pas.
• Flux d'appareil (pour appareils sans tête) : Notez qu'à compter du 28 août 2025, Salesforce a définitivement bloqué Flux d'appareil OAuth 2.0 pour l'application connectée Salesforce CLI par défaut. Utilisez à la place le flux serveur Web (web de connexion d'organisation sf) ou le flux porteur JWT (jwt de connexion d'organisation sf) pour les outils CLI et CI/CD.

N'utilisez pas le flux Nom d'utilisateur-Mot de passe. Salesforce l'a bloqué par défaut pour les organisations créées dans Summer '23 ou supérieur, et a publié des plans de retrait pour ce flux. Les intégrations existantes qui s'appuient encore sur le flux Nom d'utilisateur-Mot de passe devraient migrer maintenant vers le flux Porteur JWT ou le flux Identifiants client, plutôt que de traiter la migration comme une dette technique différée.

Ces flux sont configurés dans l'enregistrement de l'application qui représente votre intégration. À compter de la version Spring '26, Salesforce déplace cet enregistrement depuis Applications connectées vers Applications clientes externes (ECA) : la création d'applications connectées est désactivée par défaut et ECA est la construction par rapport à laquelle concevoir de nouvelles intégrations. Les applications connectées existantes restent installées. Cependant, une fois migrées, les organisations ne gèrent plus l'authentification. Par conséquent, tenez compte de la migration lors de l'audit de l'authentification des intégrations au lieu de traiter les applications connectées comme le modèle permanent.

En plus de choisir un flux d'authentification, créez une gouvernance distincte pour laquelle les applications peuvent se connecter :

• Une inscription par intégration : Enregistrez une application cliente externe dédiée pour chaque nouvelle intégration et une application connectée distincte pour chaque application existante. Limité aux étendues OAuth requises par chaque intégration, plutôt que de partager un enregistrement général entre de nombreux utilisateurs, un enregistrement dédié permet d'auditer et de révoquer indépendamment l'accès de chaque intégration.
• Autorisez explicitement l'accès (recommandé) : Définissez la stratégie Utilisateurs autorisés de l'application cliente externe sur « Les utilisateurs approuvés par l'administrateur sont pré-autorisés » afin qu'un administrateur accorde l'accès via des profils et des ensembles d'autorisations au lieu de laisser les utilisateurs s'autoriser eux-mêmes. Les administrateurs configurent ce paramètre directement dans Configuration, et Salesforce recommande de le contrôler pour déterminer qui peut se connecter.
• Contrôle d'accès API (plus strict, basé sur une liste d'autorisations) : Pour renforcer les contrôles, le Contrôle d'accès API limite les utilisateurs approuvés par l'administrateur uniquement aux applications connectées de la liste d'autorisations. Son activation nécessite une demande au Support client de Salesforce. Par conséquent, planifiez cette étape en la contournant plutôt que de la traiter comme un paramètre en libre-service.

N'incorporez jamais d'identifiants dans un code, des fichiers de configuration ou un contrôle de version. Utilisez des identifiants nommés et des identifiants externes pour gérer l'authentification de façon centralisée avec des capacités de rotation.

Contrairement à l'authentification traditionnelle des utilisateurs, les agents ont besoin de modèles d'identité distincts, et le modèle approprié dépend du fait qu'ils servent des employés ou des utilisateurs externes. Concevoir l'identité correctement est le fondement de la sécurité des agents : il détermine les données auxquelles l'agent peut accéder et les actions auxquelles il peut accéder.

Examinons de plus près les agents internes et externes. nts.

• Agents du personnel (interne) : Exécutez les tâches dans le contexte de l'utilisateur connecté. Ils héritent des licences, des ensembles d'autorisations, de la sécurité au niveau du champ et des règles de partage de cet utilisateur. Par conséquent, aucune identité d'agent séparée n'est provisionnée, et l'infrastructure de sécurité existante régit ce que l'agent peut faire.
• Agents clients (externe) : Interagissez via des canaux publics et exécutez-les en tant qu'utilisateurs Agent dédiés, utilisateurs d'intégration spécialisés, pas en tant qu'utilisateurs invités de site public. L'exécution au nom d'utilisateurs dédiés à l'intégration permet à l'agent d'exécuter des actions back-end et d'atteindre les données (ce que les profils invités non authentifiés ne peuvent pas), tout en restant lié par des autorisations explicites et à moindre privilège. Lorsque vous créez un agent client, provisionnez un nouvel Utilisateur agent avec un accès minimal et accordez uniquement les autorisations spécifiques requises par ses actions.

Lorsque le travail d'un agent couvre plusieurs services, propagez l'identité de l'utilisateur à travers chaque saut de service au lieu de revenir à une identité partagée ou invité. Le flux Échange de jetons Salesforce OAuth 2.0 prend en charge les éléments suivants :

Un client présente le jeton fournisseur d'identité existant de l'utilisateur, et un gestionnaire d'échange de jetons Apex le mappe avec un utilisateur Salesforce et émet un jeton d'accès Salesforce. Ainsi, le contexte de l'utilisateur d'origine suit la requête au lieu de se réduire à un compte de service. Surveillez l'activité des agents via la Surveillance des événements, en utilisant l'identité utilisateur de l'agent pour détecter les comportements anormaux.

Le choix du modèle approprié dépend de la personne qui initie la connexion et du contexte dans lequel le travail doit être exécuté.

Les scénarios de connexion courants sont mappés avec les approches recommandées comme suit :

Concevez des hiérarchies de rôles basées sur les besoins d'accès aux données (les utilisateurs doivent accéder aux enregistrements appartenant à d'autres utilisateurs), pas sur le graphique de rapport de gestion. Laissez la profondeur de la hiérarchie des rôles suivre de véritables relations d'accès aux données plutôt que d'ajouter des niveaux qui n'accordent aucun accès supplémentaire, car chaque niveau ajoute des coûts de calcul du partage, une considération qui a plus de poids dans les organisations avec des paramètres OWD privés et des volumes de données importants.

Les ensembles d'autorisations et les groupes d'ensembles d'autorisations réduisent la nécessité de multiplier les profils en offrant un accès flexible et additif. Accordez l'accès fonctionnel via des ensembles d'autorisations et des groupes d'ensembles d'autorisations plutôt que des profils, ce qui permet de garder l'accès additif et auditable. Les profils restent nécessaires : parallèlement aux heures de connexion et aux restrictions IP, ils contrôlent l'attribution de présentation de page, les paramètres par défaut des types d'enregistrement et la visibilité de l'application. Traitez les profils comme une partie durable du modèle d'accès, plutôt que comme une construction à éliminer.

Les stratégies de sécurité des transactions ne font pas partie de la base, elles sont une capacité complémentaire qui complète le modèle d'autorisation principal : les contrôles d'identité, de rôle, de profil, d'ensemble d'autorisations et de partage ci-dessus établissent déjà une posture d'autorisation sécurisée, et la Sécurité des transactions ajoute en plus l'évaluation contextuelle en temps réel. Configurez des stratégies pour détecter et bloquer les comportements anormaux, notamment les téléchargements de données en masse qui dépassent les schémas normaux, les connexions à partir de zones géographiques inattendues et les changements d'autorisation hors des fenêtres de modification.

Les contrôles de sécurité impliquent des compromis de disponibilité qui sont une responsabilité architecturale. Une restriction IP trop large peut verrouiller les utilisateurs légitimes lors d'un changement de réseau, et une stratégie de sécurité des transactions ajustée de façon trop agressive peut bloquer les activités commerciales valides. Par conséquent, étendez ces contrôles à un risque réel, mettez-les en place en mode surveillance uniquement avant de les appliquer, et concevez un chemin de rupture de verre pour les contrôles mal déclenchés.

Votre responsabilité : Concevez une hiérarchie des rôles, créez des ensembles d'autorisations, configurez des stratégies de sécurité des transactions.

Contrôle d'accès basé sur le rôle traditionnel) accorde des autorisations basées sur le rôle d'un utilisateur. ABAC (contrôle d'accès basé sur l'attribut) prend les décisions d'autorisation en fonction des attributs des données, de l'utilisateur et du contexte.

Pour la plupart des exigences, le modèle de partage principal exprime pleinement l'accès. Atteindre un ABAC dédié lorsque l'accès doit suivre une classification des données que le partage par enregistrement ne peut pas exprimer : Data 360 ABAC le fournit via des balises et des annotations.

Data 360 ABAC fonctionne via :

• Les politiques basées sur des balises qui définissent des règles d'accès basées sur des balises appliquées à des objets de données (par exemple, les balises Informations d'identification personnelle (PII), financières, de soins et confidentielles).
• Les annotations sont appliquées aux objets de données pour prendre en charge les décisions d'autorisation basées sur une stratégie.
• Stratégie « Autoriser tout » par défaut pour les organisations nouvelles et existantes qui doivent être explicitement supprimées pour activer des stratégies de gouvernance précises.

Son utilisation architecturale principale est l'application automatique de la classification des données. Consultez Classification des données sous Protection des données et confidentialité pour déterminer comment les niveaux de classification pilotent l'application automatique d'ABAC.

Ce niveau de granularité entraîne un coût opérationnel. Le partage de base répond à la question « Qui peut afficher cet enregistrement et pourquoi ? » à partir d'un petit ensemble de règles inspectables (OWD, hiérarchie des rôles et règles de partage), alors qu'ABAC dérive ses réponses au moment de l'évaluation de la combinaison de balises de données, d'attributs utilisateur et de contexte. Par conséquent, l'accès efficace devient plus difficile à raisonner et à auditer à mesure que les politiques et les balises s'accumulent.

Forcer l'auditabilité en tant qu'exigence de conception : appliquer des balises de façon cohérente, garder l'ensemble de stratégies petit et nommé pour la classification qu'il applique, et préserver la possibilité de reconstituer la raison pour laquelle un utilisateur a atteint un enregistrement donné. Réservez ABAC aux requêtes pilotées par la classification que le partage par enregistrement ne peut véritablement pas exprimer, plutôt que de le traiter comme un remplacement général du modèle basé sur la propriété.

Identifiez et protégez les comptes avec des privilèges élevés, notamment les administrateurs système, les utilisateurs de l'intégration et les comptes de processus automatisés. Ces comptes sont des cibles importantes pour les assaillants.

Appliquez des contrôles avancés aux comptes à impact critique.

• Nécessite une MFA résistante à l'hameçonnage
• Limiter les plages IP de connexion aux emplacements administratifs connus
• Activer les alertes de connexion et les notifications de changement d'autorisation
• Effectuer des examens périodiques de l'accès avec une attestation documentée pour les comptes à privilèges élevés dont la fréquence est déterminée par les exigences de tolérance au risque et de conformité de l'organisation
• Maintenir les procédures de bris de verre pour l'accès d'urgence et l'audit post-utilisation

Pour des comptes d'intégration et de service :

• Appliquer des flux OAuth ; jamais de flux nom d'utilisateur-mot de passe
• Application automatique des restrictions IP
• Implémenter des planifications de rotation des identifiants
• Surveillance des modèles d'utilisation d'API anormaux via la Surveillance des événements

Votre responsabilité : Identifier les comptes critiques, appliquer des contrôles renforcés, effectuer des examens trimestriels.

Concevez des processus automatisés pour provisionner les utilisateurs avec l'accès initial approprié, ajuster les autorisations à mesure que les rôles évoluent et déprovisionner rapidement lorsque l'accès n'est plus requis.

Implémentez un système de gestion des identités inter-domaines (SCIM) pour le provisionnement automatisé auprès des fournisseurs d’identité. Le provisionnement juste à temps SAML ou OpenID Connect est une alternative qui crée un utilisateur lors de la première connexion, mais qui ne déprovisionne pas les utilisateurs. En d'autres termes, SCIM est la colonne vertébrale du cycle de vie, pas un choix contre elle.

Le cycle de vie de l'identité comprend :

• Provisionnement: Créez des comptes avec un accès de référence correspondant à la fonction du poste, qui est déclenché par des événements système RH.
• Ajustements d'accès: Accordez des autorisations supplémentaires à mesure que les rôles augmentent et révoquez les autorisations lorsque les rôles changent.
• Recertification périodique: Vérifiez et validez l'accès tous les trimestres.
• Déprovisionnement: Révoquez immédiatement l'accès lorsque l'emploi prend fin ou lorsque les rôles ne nécessitent plus l'accès Salesforce.

Implémentez des processus de recertification de l'accès lorsque les responsables examinent et valident périodiquement les autorisations de leur équipe. La fréquence des examens est basée sur les exigences de risque et de conformité.

Votre responsabilité : Implémenter SCIM, concevoir des workflows de provisionnement, effectuer une recertification trimestrielle.

La séparation des données en plusieurs organisations est parfois considérée comme une simple décision de coût ou de résidence. Architecturalement parlant, c'est un compromis de sécurité, et les conséquences de la gouvernance appartiennent à votre conception de l'accès.

L'isolement est l'avantage clé. Les organisations séparées offrent la frontière la plus solide possible entre les jeux de données. Il n’y a pas de modèle de partage collectif et de purge d’autorisation interlocataires, mais il existe une ligne réglementaire claire pour les juridictions qui en exigent un. Cette même frontière fragmente la gouvernance. Chaque contrôle d'accès que vous devez gérer une seule fois dans une seule organisation (par exemple, conception d'ensembles d'autorisations, hiérarchie des rôles, durcissement des comptes avec impact critique, référence de contrôle d'intégrité, Surveillance des événements et corrélation SIEM) se multiplie désormais par organisation, ce qui signifie qu'il doit maintenir la cohérence entre toutes les organisations. La dérive entre les organisations crée sa propre surface d'attaque, car une autorisation restreinte dans une organisation et manquée dans une autre crée une incohérence que les assaillants peuvent trouver et exploiter. Les intégrations inter-organisations ajoutent des limites Trust authentifiées qui n'existaient pas auparavant. Chaque intégration inter-organisations est une connexion que vous devez sécuriser et surveiller.

C'est pourquoi il est important de comparer l'avantage de l'isolement au multiplicateur de gouvernance avant de scinder une organisation. Réservez les organisations multiples dans les cas où un mandat de localisation définitive ou l'exigence d'isolation contractuelle d'un client ne peut pas être satisfait dans une seule organisation. Lorsque vous l'adoptez, vous devez concevoir le modèle d'accès, la surveillance et les bases de configuration à appliquer de façon identique dans chaque organisation dès le début.

Votre responsabilité : Traitez une décision multi-organisations comme un compromis de sécurité, pas seulement comme un coût. Lorsque plusieurs organisations sont requises, appliquez les contrôles d'accès, la surveillance et les normes de référence de contrôle d'intégrité de façon cohérente dans chaque organisation, et sécurisez chaque intégration inter-organisations en tant que frontière Trust.

Il est de votre responsabilité de classer les données, de configurer le cryptage, de concevoir des contrôles de confidentialité.

Examinons de plus près comment protéger correctement les données et la vie privée.

Pour classer correctement vos données, vous devez les connaître. La tâche architecturale globale consiste à comprendre votre domaine métier et à gérer un dictionnaire de données qui répertorie les données que vous détenez, ce que cela signifie et où vivent les données confidentielles. Vous pouvez classer ou protéger uniquement les données que vous avez identifiées en premier.

Établissez un schéma de classification des données qui pilote les contrôles de protection appropriés. Une étiquette de classification ne protège rien en soi. Il correspond à l'entrée des contrôles que vous appliquez. Par conséquent, chaque classification que vous attribuez doit être mappée avec une décision concrète de cryptage, d'accès, de rétention ou de surveillance. Les décisions de classification prises pendant la modélisation des données influencent directement les exigences de cryptage, les contrôles d'accès, les stratégies de rétention et les obligations de conformité.

Chez Salesforce, nous utilisons un schéma à quatre niveaux qui fournit un cadre que vous pouvez adapter aux exigences réglementaires et aux besoins métiers de votre organisation. De nombreuses entreprises utilisent des modèles similaires alignés sur les normes de l'industrie (par exemple, ISO 27001 et NIST). Votre mise en œuvre spécifique doit refléter vos obligations de conformité (par exemple, HIPAA, PCI DSS, GDPR et réglementations sectorielles) et le contexte commercial.

Appliquez la classification au niveau du champ. Un enregistrement Compte unique peut contenir des champs Public (par exemple, les noms de société), Confidentiel (par exemple, les revenus de la société) et Limité (par exemple, les numéros de sécurité sociale). La sécurité au niveau du champ doit refléter ces distinctions.

La classification devient exécutoire via le contrôle d'accès basé sur l'attribut, qui lit les balises que vous attribuez et applique les règles d'accès. Il s'agit d'une couche pilotée par les métadonnées qui complète les règles de mot de passe à usage unique et de partage.

En alignant ABAC sur votre schéma de classification, la plate-forme peut :

• Limitez l'accès aux données balisées Restricted ou Confidential depuis la classification elle-même, plutôt que depuis une règle de partage gérée par objet.
• Adaptez l'accès à mesure que la classification d'un enregistrement change au fil du temps. Un enregistrement nouvellement balisé Régulé hérite d'un accès plus strict sans modification manuelle de la règle.
• Combinez des attributs de données (par exemple, classification et confidentialité) avec des attributs utilisateur (par exemple, service et autorisation) et le contexte (par exemple, heure et emplacement) dans une décision d'autorisation unique.

Concevez des stratégies ABAC alignées sur ce schéma afin de classer un champ comme restreint comme l'acte qui détermine ses contrôles d'accès et maintient l'application de la loi ancrée à la classification au lieu de maintenir des règles de partage séparées.

Votre responsabilité : Définissez un schéma de classification, entraînez les modélisateurs de données, classez les champs pendant la conception, configurez des contrôles et alignez les stratégies ABAC sur les niveaux de classification afin de favoriser l'application automatique des balises.

Commencez par les informations que la plate-forme fournit déjà pour chaque organisation. Les données au repos sont cryptées par défaut. Hyperforce applique le cryptage au niveau du volume qui protège un volume de stockage entier sous une clé unique que Salesforce possède et gère. Cette référence est toujours active et transparente pour votre solution, mais elle fonctionne au niveau du volume (pas par champ). Par conséquent, le choix des éléments à crypter et à contrôler pendant le cycle de vie de la clé appartient à la plate-forme, pas à vous.

Lorsque cette référence ne peut satisfaire à une obligation de conformité, contractuelle ou de classification des données, utilisez Shield Platform Encryption. Plus précisément, lorsque vous avez besoin de l'un des trois éléments que le cryptage au niveau du volume ne fournit pas :

• Contrôle du cycle de vie de la clé pour pouvoir générer, permuter et révoquer vous-même le matériel de clé
• Sélectivité sur les champs standard, les champs personnalisés, les fichiers et les pièces jointes cryptés au repos
• La possibilité de rendre les données inaccessibles à Salesforce.

Les données restreintes et les données soumises à des mandats réglementaires explicites de contrôle des clés (par exemple, HIPAA, PCI DSS et GDPR) sont les déclencheurs habituels. La base couvre déjà la protection de tout le reste au niveau de l'infrastructure.

Shield Platform Encryption crypte au niveau du champ, et offre deux schémas qui échangent la sécurité contre la possibilité d'interroger.

Le cryptage probabiliste est un schéma solide et par défaut, mais les champs cryptés ne peuvent pas être utilisés dans des critères de filtrage, des fonctions de tri ou d'agrégation (par exemple, les fonctions MAX(), MIN() et COUNT_DISTINCT()).

Le cryptage déterministe active le filtrage de correspondance exacte dans les rapports, les vues de liste et les clauses SOQL WHERE (sensibles à la casse ou insensibles à la casse) à une puissance réduite, car le même texte brut produit toujours le même texte chiffré.

Nous recommandons de crypter par défaut avec le schéma probabiliste et de réserver le cryptage déterministe aux champs spécifiques que vous devez filtrer ou trier. Évaluez ces compromis pendant la conception de la modélisation des données, notamment les impacts sur les références de champs de formule, l'agrégation de rapports et les opérations SOQL.

Les clés contrôlées par le client se présentent sous deux formes distinctes :

• Bring Your Own Key (BYOK) permet de générer du matériel de clé hors de Salesforce, en utilisant vos propres bibliothèques de cryptage, votre système de gestion des clés d'entreprise ou votre module de sécurité matériel, et de le fournir à la plate-forme.
• Le Service de clé cache uniquement conserve votre clé de cryptage des données dans un service de clé que vous contrôlez. Salesforce le récupère à la demande plutôt que de le stocker.

Les deux formulaires permettent de permuter et de détruire le matériel de clé selon votre propre planification. La destruction du matériel de clé rend les données qu'il protégeait irrécupérables, ce qui est un contrôle puissant et délibéré au lieu d'être une routine. Il est également important de documenter vos procédures de rotation et de révocation de clés.

Toutes les intégrations doivent utiliser le protocole TLS 1.2 ou supérieur (la plate-forme Salesforce l'applique), mais vous devez implémenter l'authentification mutuelle basée sur le certificat pour les intégrations qui gèrent les données restreintes (en utilisant votre propre configuration).

Votre responsabilité : Déterminez où le niveau de référence au niveau du volume de la plate-forme suffit et où une obligation de conformité, contractuelle ou de classification justifie Shield Platform Encryption, puis sélectionnez des schémas de cryptage, choisissez et exploitez une stratégie de clé contrôlée par le client, et implémentez l'authentification basée sur le certificat pour les intégrations sensibles.

Protégez les données confidentielles dans les environnements de non-production en utilisant des stratégies qui empêchent les données restreintes d'entrer dans les organisations sandbox.

• La copie sandbox partielle exclut les données restreintes des actualisations sandbox.
• Les règles de masquage des données brouillent les valeurs de champ confidentielles dans les organisations sandbox en utilisant des modèles qui préservent les caractéristiques des données.
• La génération de données synthétiques s'applique aux environnements de développement qui ne nécessitent jamais de données de production.
• Les modèles sandbox définissent les objets et les champs à inclure dans chaque type de sandbox.

Concevoir pour les tests de conformité est une responsabilité architecturale. Élaborez des cycles de développement et de test sur des données synthétiques avec des caractéristiques réalistes, afin de permettre aux équipes de valider par rapport à des conditions de production tout en respectant les limites de production des données réglementées.

Votre responsabilité : Concevoir une stratégie sandbox, configurer des règles Data Mask, générer des données de test synthétiques.

Concevez des solutions qui respectent la vie privée des utilisateurs via des décisions architecturales.

• Réduction des données : Recueillez uniquement les données nécessaires à des fins métiers déclarées. Défiez chaque ajout de champ en demandant « Quelle décision architecturale nécessite ces données ? » N'oubliez pas que les données les plus sécurisées sont celles que vous ne collectez jamais.
• Limitation de l'objet : Concevez des modèles d'accès aux données qui appliquent techniquement la limitation des objectifs. Utilisez des ensembles d'autorisations et des règles de partage pour restreindre l'accès aux données en fonction de l'objet d'une fonction. Par exemple, les utilisateurs marketing ne doivent pas accéder aux détails des requêtes de support, sauf si leur travail l'exige.
• Gestion du consentement : Implémentez le suivi du consentement au niveau individuel pour le marketing, les analytiques et le traitement facultatif des données. Concevez des workflows de retrait du consentement qui se propagent à travers des systèmes intégrés. En d'autres termes, le consentement est granulaire et spécifique au but.
• Droits de la personne concernée : Élaborez des workflows pour les demandes d'accès (par exemple, fournir des copies de données), la rectification (par exemple, corriger les imprécisions), l'effacement (par exemple, supprimer des données lorsque la loi le permet) et la portabilité (par exemple, exporter vers un format lisible par ordinateur). Concevez ces workflows à réaliser dans les délais de réponse imposés par chaque cadre de gouvernance. Ces échéances varient selon la juridiction (et sont modifiées périodiquement). Par conséquent, il est important de paramétrer l'accord de niveau de service du workflow à partir d'une source de conformité maintenue et de confirmer chaque fenêtre par rapport à la réglementation en vigueur (au lieu de coder en dur une seule valeur).

Votre responsabilité : Concevez des modèles de données avec une réduction, configurez l'accès par objectif, implémentez des workflows de consentement, élaborez une automatisation des droits des personnes concernées.

La résidence des données est un choix architectural que vous prenez avant le provisionnement, pas un paramètre que vous basculez ensuite. Hyperforce offre un déploiement régional, mais une région n'existe que lorsque Salesforce en exploite un, et la résidence d'une organisation est fixe au provisionnement. Votre responsabilité consiste à déterminer où chaque catégorie de données doit résider, à vérifier si une région appropriée est disponible et à concevoir les mécanismes de transfert de données qui traversent légitimement les frontières.

Au lieu d'utiliser par défaut le stockage dans le pays, il est important de classer vos obligations de résidence avant de commencer.

• La localisation obligatoire. Un petit nombre de juridictions exigent que certaines données restent à l'intérieur des frontières nationales (parfois, cela ne s'applique qu'aux secteurs réglementés). Lorsque Salesforce n'opère pas dans une région du pays, le stockage natif ne peut pas satisfaire à lui seul au mandat. Par conséquent, vous avez besoin d'une superposition de résidence des données ou d'une organisation séparée pour ces données. Puisque cette liste peut changer, il est important de confirmer le mandat spécifique par rapport au règlement applicable.
• Cadres basés sur la responsabilisation. La plupart des régimes n'imposent pas de mandat de localisation. Ils sont satisfaits par une plate-forme régionale avec un mécanisme de transfert transfrontalier approprié. Dans ce cas, la décision est basée sur la région qui réduit la latence et simplifie la conformité.

Lorsque des données traversent une frontière, l'intérêt est la sensibilisation avant la configuration. En d'autres termes, vous devez savoir quels transferts ont lieu et sur quelle base juridique, puis concevoir l'accès de sorte que les données soient régies de bout en bout. Lorsqu'elles existent, les décisions relatives à l'adéquation sont les moins controversées. Les Règles d'entreprise contraignantes (RCO) et les Clauses contractuelles types (CCN) couvrent la plupart des transferts restants. Utilisez le consentement explicite uniquement en dernier recours.

Associez le mécanisme de transfert à un accès restreint aux enregistrements (par exemple, des OWD privés et un partage spécifique) afin d'éviter qu'un transfert autorisé devienne trop large. Documentez des cartes de flux de données pour montrer où chaque catégorie de données provient, transite et réside. Revenez les voir lorsque la réglementation ou les disponibilités régionales changent.

Votre responsabilité : Classez les obligations de résidence par catégorie de données, vérifiez la disponibilité régionale avant le provisionnement, sélectionnez des mécanismes de transfert (adéquation, RCO/CSC) pour les flux transfrontaliers et documentez des cartes de flux de données.

Il est de votre responsabilité de concevoir des solutions qui maintiennent le dispositif de conformité fourni par la plate-forme.

Ce guide est directif. Les exigences réglementaires varient selon la juridiction et évoluent au fil du temps. Vous devez toujours vérifier les obligations spécifiques par rapport à la réglementation en vigueur (par exemple, la loi applicable, l'autorité de surveillance ou la documentation de conformité Salesforce) pour votre déploiement.

Salesforce maintient des certifications de conformité étendues (disponibles à l'adresse Trust.salesforce.com et compliance.salesforce.com): certifications SOC 2 Type II, ISO 27001, FedRAMP (pour Government Cloud), HIPAA, PCI DSS et régionales. Ces certifications couvrent les responsabilités de Salesforce en matière d'infrastructure de plate-forme et de services partagés.

Les certifications de plate-forme réduisent votre charge de conformité, mais n'éliminent pas votre responsabilité architecturale. Vos objets personnalisés, votre code Apex, vos intégrations et vos configurations doivent conserver le dispositif de conformité fourni par la plate-forme.

Votre responsabilité : Concevez des solutions qui maintiennent le dispositif de conformité, documentez comment l'architecture satisfait aux exigences réglementaires.

• Activez Belder Platform Encryption pour tous les champs qui contiennent des informations de santé protégées (PHI).
• Pour la conformité HIPAA, activez le Piste d'audit des champs avec des politiques de rétention afin de satisfaire aux exigences de tenue de registres de l'HIPAA. Confirmez la période actuelle par rapport au règlement applicable.
• Configurez la Surveillance des événements pour détecter les modèles d'accès PHI non autorisés.
• Mettez en œuvre toutes les garanties techniques requises par la règle de sécurité HIPAA, notamment les contrôles d'accès, la consignation des audits et la sécurité de la transmission.

• Implémentez la séparation des tâches (SoD) via des conceptions d'ensembles d'autorisations afin d'empêcher les utilisateurs uniques de créer et d'approuver des transactions financières.
• Pour les environnements PCI, évitez de stocker des numéros de compte principaux (PAN) complets dans Salesforce afin de limiter la portée de la conformité PCI DSS.
• Si possible, utilisez la jetonisation de la passerelle de paiement.

• Pour le RGPD et le LGPD, concevez une gestion du consentement qui capture un consentement granulaire et spécifique à un objectif.
• CCPA/CPRA suit un modèle de désabonnement. Fournir des mécanismes clairs pour se désabonner de la vente ou du partage de renseignements personnels plutôt qu'un consentement précis basé sur un but.
• Élaborez des workflows relatifs aux droits de la personne concernée qui sont terminés dans les délais de réponse de chaque cadre et confirmés par rapport au règlement en vigueur.
• Implémentez une automatisation de la rétention des données qui purge les données lorsque le consentement expire.

• Utilisez Salesforce Government Cloud pour les charges de travail gouvernementales réglementées.
• Implémentez des contrôles NIST 800-53 mappés avec la configuration de Salesforce.
• Activez la surveillance continue via la Surveillance des événements qui est acheminée vers l'infrastructure SIEM gouvernementale.

Votre responsabilité : Configurez Shield, Journal d'audit des champs, séparation des tâches, gestion du consentement, rétention des données en fonction des exigences réglementaires.

Les réglementations relatives à la protection des données et de la vie privée varient considérablement d’une juridiction à l’autre (et les obligations spécifiques changent rapidement). Par conséquent, ce niveau nécessite une prise de décision plutôt qu’un tableau pays par pays.

Les deux leviers architecturaux sont la résidence et le transfert transfrontalier, qui sont couverts par la Protection des données et de la vie privée.

Pour adhérer à ces règlements, vous devez :

• Classer où chaque catégorie de données doit résider
• Confirmer l'existence d'une zone appropriée avant le provisionnement
• Concevez un mécanisme de transfert légal des données qui franchissent une frontière.

Pour plus d'informations, consultez Résidence des données et souveraineté pour plus de détails sur le cadre de décision.

Tout ce qui n'est pas considéré comme un chiffre temporel (par exemple, le modèle de consentement utilisé par une administration, la date limite pour une demande de données de la personne concernée, la période de notification des organismes de réglementation ou des personnes concernées après une infraction, et la période de conservation minimale des dossiers d'audit). Ces chiffres sont fixés par la réglementation, diffèrent selon le cadre et sont modifiés dans les annexes des organismes de réglementation.

Ne les codez pas en dur ici. Vous devez déterminer les étapes suivantes en fonction de la réglementation régissant votre déploiement (ou d'une source de conformité maintenue qui en cite une) et adapter votre conception à la période la plus étroite de votre empreinte opérationnelle.

Voici les conséquences architecturales durables qui appartiennent à la conception.

• Une date limite de demande de données de l'objet, mesurée en jours à un chiffre, ne peut pas être respectée par un processus manuel ad hoc. Par conséquent, vous devez automatiser l'exécution de la DSR lorsque vous opérez dans une juridiction à échéance courte. Utilisez Experience Cloud pour l'admission, Service Cloud pour le suivi des requêtes, Centre de confidentialité pour la découverte et Flux pour l'exécution.
• Une fenêtre de notification d'infraction est trop étroite pour être improvisée. Par conséquent, vous devez élaborer à l'avance le workflow de réponse à l'infraction. Déterminez les règles d'anomalie de Surveillance des événements, les rôles préattribués, les notifications prédéfinies du régulateur et de la personne concernée, et un chemin d'escalade qui suppose l'échéance la plus serrée dans votre empreinte. Les notifications individuelles sont généralement déclenchées par une détermination de risque élevé. Par conséquent, vous devez inclure une évaluation des risques dans le workflow.
• Certaines juridictions exigent ou recommandent la conservation dans le pays des journaux d'audit, avec des minimums couvrant plusieurs années. Par conséquent, vous devez dimensionner la rétention SIEM au minimum dans votre empreinte et confirmer si les journaux peuvent quitter la juridiction.

Votre responsabilité : Concevez la résidence et le transfert par Protection des données et confidentialité, automatisez les workflows de DSR et de réponse aux infractions à l'échéance la plus serrée de votre empreinte, et confirmez chaque chiffre spécifique à la juridiction par rapport à la réglementation en vigueur plutôt qu'une valeur écrite dans ce guide.

Concevez une validation de conformité continue plutôt qu'une préparation d'audit ponctuelle.

• Le Contrôle d'intégrité de la sécurité évalue la configuration par rapport aux normes de sécurité de base de Salesforce et fournit des scores de risque. Exécutez régulièrement des contrôles pour vérifier la conformité aux recommandations de référence de sécurité de Salesforce. Maintenez des scores de 80 % ou plus (Très bonnes ou Excellentes bandes).
• Event Monitoring capture des journaux détaillés sur l'activité des utilisateurs, les appels d'API, les événements d'authentification et les modèles d'accès aux données. Acheminez les fichiers journaux des événements vers SIEM externe pour une rétention à long terme qui dépasse les limites de rétention native.
• Transaction Security évalue en temps réel les événements par rapport aux polices, et peut bloquer les événements, demander une augmentation de la MFA ou vous notifier des infractions aux polices.

Il est important d'automatiser les contrôles de conformité dans les pipelines de déploiement afin de vérifier que les déploiements n'affaiblissent pas les modèles d'autorisation, ne désactivent pas les paramètres d'audit ou n'introduisent pas de configurations non conformes.

Votre responsabilité : Exécutez le Contrôle d'intégrité trimestriel, acheminez la Surveillance des événements vers SIEM, configurez des stratégies de sécurité des transactions, automatisez la validation de la conformité dans CI/CD.

Concevez des stratégies de piste d'audit basées sur les exigences de conformité, les besoins en enquêtes et les obligations de rétention.

Pour les environnements réglementés, implémentez la Surveillance des événements avec l'intégration SIEM externe pour la rétention des journaux à long terme et la corrélation inter-systèmes. Concevez des stratégies Journal d'audit des champs qui couvrent tous les champs restrictifs et confidentiels soumis aux exigences réglementaires en matière de tenue de dossiers.

Votre responsabilité : Activez le Journal d'audit des champs pour les champs confidentiels, acheminez la Surveillance des événements vers SIEM, configurez des stratégies de sécurité des transactions.

Il est de votre responsabilité d'intégrer la sécurité tout au long du développement, pas après coup.

Intégrez les pratiques de sécurité dès la phase de développement la plus précoce possible. La modélisation des menaces pendant la phase d'architecture évite les vulnérabilités au niveau de la conception. Les exigences de sécurité capturées avec les exigences fonctionnelles vous empêchent de traiter la sécurité comme une réflexion a posteriori.

Les défauts de sécurité sont beaucoup plus coûteux à corriger lorsqu'ils sont découverts en production plutôt que pendant les phases de conception ou de développement. Une faille de sécurité au niveau de la conception détectée lors de l'examen de l'architecture peut prendre une seule conversation à corriger. Cependant, lorsque la même faille est détectée en production, elle nécessite une réarchitecture, une migration des données, une correction de conformité et une notification d'infraction potentielle.

C'est pourquoi nous pratiquons la sécurité des postes de travail à gauche, qui se concentre sur :

• Modélisation des menaces avant la finalisation de la conception
• Exigences de sécurité dans les récits utilisateur
• Formation au codage sécurisé pour les développeurs
• Analyse statique intégrée aux IDE
• Examens de code axés sur la sécurité
• Test de sécurité automatisé dans CI/CD
• Validation de la sécurité avant le déploiement en production

Votre responsabilité : Effectuez la modélisation des menaces, formez les développeurs, intégrez Code Analyzer dans CI/CD, exigez des examens de code sensibles à la sécurité.

Il est important de concevoir des protections contre les vulnérabilités courantes dans un contexte Salesforce. Examinons de plus près notre mappage avec le top 10 OWASP 2025 de Salesforce.

• A01:2025 - Contrôle d'accès rompu : Appliquer par programmation CRUD et la sécurité au niveau du champ (FLS) dans tous les accès aux données Apex.
  • Dans l'API version 67.0 ou supérieure, Apex est exécuté par défaut dans le contexte de l'utilisateur, ce qui signifie que les autorisations et le FLS de l'utilisateur actif sont appliqués lors de l'exécution de code.
    • WITH SECURITYENFORCED a été retiré, ce qui entraîne une erreur de compilation. Remplacez toutes les utilisations existantes par WITH USER_MODE. La plate-forme applique automatiquement l'accès dans l'interface utilisateur standard.
  • Dans l'API version 66.0 ou antérieure, le mode système est défini par défaut. Utilisez WITH USERMODE dans les requêtes SOQL ou Security.stripInaccessible() pour les opérations DML.
• A01:2025 - API de données côté client : Le Service de données Lightning et l'API d'interface utilisateur appliquent automatiquement le FLS, le CRUD et le partage de l'utilisateur actif. Par conséquent, un composant élaboré à partir de ces composants hérite par défaut du moindre privilège.
  • Cette protection est perdue lorsqu'un composant appelle un Apex personnalisé. Apex impératif applique automatiquement l'accès uniquement lorsqu'il est exécuté en mode utilisateur. Par conséquent, une classe déclarée sans partage agit comme une trappe d'échappement qui contourne le modèle en silence.
  • Utilisez Lightning Data Service et l'API UI pour l'accès aux données.
  • Vous devez réaffirmer CRUD, FLS et sharing pour chaque appel Apex impératif à partir d'un composant.
• A02:2025 - Mauvaise configuration de la sécurité : Surveillez les écarts de configuration par rapport aux normes de sécurité en utilisant le Contrôle d'intégrité.
  • Désactivez l'accès Utilisateur invité dans les sites Experience Cloud (sauf si une justification métier documentée l'exige explicitement).
• A05:2025 - Injection : La catégorie Injection 2025 couvre l'injection SOQL/SOSL et le script inter-site (XSS).
  • Pour l'injection de requêtes, utilisez des variables de liaison pour toutes les requêtes dynamiques. Ne concaténez jamais l'entrée utilisateur directement dans des chaînes de requête. Les mécanismes de requête paramétrés de la plate-forme éliminent le risque d'injection lorsqu'ils sont utilisés correctement.
  • Les injections SOQL ou SOSL sont limitées à une lecture qui divulgue des enregistrements ou des champs que l'appelant ne devrait pas pouvoir atteindre en élargissant les conditions de requête. Comme ces langages lisent les données alors que les écritures sont exécutées par des opérations DML séparées, cela crée un risque de contrôle d'accès et de confidentialité, car il s'aggrave lorsque les autorisations d'objet et de champ ne sont pas appliquées à la requête.
  • Pour XSS, les composants Web Lightning assurent une protection automatique via le moteur de restitution LWC.
  • Pour les composants Aura et Visualforce, vous devez appliquer des fonctions d'encodage de plate-forme (par exemple, HTMLENCODE, JSENCODE et URLENCODE) lors de la restitution de contenus dynamiques.

Votre responsabilité : Appliquer automatiquement CRUD/FLS dans un code personnalisé, appliquer des fonctions d'encodage, utiliser des variables de liaison, surveiller les écarts de configuration.

Concevez des pipelines CI/CD avec des portiques de sécurité à chaque étape. La sécurité doit être automatisée pour évoluer avec la vitesse de développement.

Examinons de plus près les étapes de sécurité du pipeline.

• Le contrôle source utilise des règles de protection de branche avec les examens de code requis. Il n'y a aucun engagement direct dans les agences principales ou engagement signé.
• L'analyse statique utilise Salesforce Code Analyzer, qui incorpore PMD, ESLint et RetireJS pour détecter les modèles d'injection, XSS et non sécurisés.
• Le scan de sécurité utilise les outils SAST et la détection des secrets pour empêcher les validations d'identifiants et le scan de vulnérabilité de dépendance.
• La validation des autorisations utilise des techniques de comparaison automatisées pour examiner les changements d'autorisation par rapport aux niveaux de sécurité de base, ce qui envoie des alertes concernant l'extension des privilèges.
• Les portes de déploiement rompent le déploiement lors de constatations de sécurité critiques qui nécessitent l'approbation de l'équipe de sécurité pour les modifications d'extension d'autorisation.
• La surveillance post-déploiement utilise des alertes de Surveillance des événements pour détecter un comportement anormal après les déploiements.

Votre responsabilité : Intégrez Code Analyzer dans CI/CD, configurez la protection des agences, implémentez des portes de déploiement, validez automatiquement les autorisations.

Les tests de sécurité complets incluent plusieurs techniques qui traitent différentes classes de vulnérabilité. Examinons de plus près chaque stratégie.

• L'analyse statique exécute Salesforce Code Analyzer dans les Developer IDE pour un retour immédiat, et dans les pipelines CI/CD en tant que portes automatisées. L'analyse statique identifie les vulnérabilités dans le code source sans exécuter l'application.
• Penetration Testing effectue des tests de pénétration pour les applications personnalisées exposées à des utilisateurs non fiables, en particulier les sites Experience Cloud et les API publiques.
  • Pour AppExchange et AgentExchange Security Review, des rapports d'analyse statique sont toujours requis.
  • Un rapport d'analyse dynamique (test de pénétration) est requis lorsque la solution intègre une application Web ou un service tiers.
  • Le test de pénétration simule les techniques d'attaque contre des applications live.
• Les tests unitaires axés sur la sécurité écrivent des tests Apex qui valident l ' application automatique du contrôle d ' accès en s ' exécutant au nom d ' utilisateurs dotés de profils d ' autorisation différents. Il est important de vérifier que l'application de la loi CRUD/FLS bloque les accès non autorisés.
• L'analyse des dépendances surveille les vulnérabilités connues dans les packages AgentExchange et les bibliothèques JavaScript. Il est important de s'abonner aux avis de sécurité des packages installés.

Votre responsabilité : Exécutez Code Analyzer, effectuez des tests de pénétration, écrivez des tests unitaires de sécurité, scannez les dépendances.

Chez Salesforce, la sécurité et la réponse aux incidents de données se concentrent sur la détection, le confinement et la récupération des violations, des accès non autorisés et de la destruction malveillante des données. Les équipes de réponse aux incidents travaillent avec deux piliers voisins qui ont des responsabilités adjacentes :

• L'excellence opérationnelle couvre les mécanismes opérationnels de gestion des incidents (par exemple, niveaux de gravité, rotation des astreintes, escalade et examen après incident)
• La fiabilité couvre la reprise de la disponibilité par rapport aux objectifs RTO et RPO, y compris la stratégie de sauvegarde et de reprise après sinistre.

En tant qu'architecte, il est de votre responsabilité de concevoir la détectabilité, la réponse et la récupération des incidents de sécurité.

La détectabilité est une qualité architecturale pour laquelle vous devez concevoir explicitement. Sans surveillance complète, les incidents de sécurité risquent de ne pas être détectés pendant de longues périodes.

Il est important d'implémenter la détection via plusieurs canaux.

• Event Monitoring capture des journaux d'événements bruts qui couvrent les connexions, les exportations de rapports et de données, les changements d'autorisation et les appels d'API. Vous devez identifier les événements anormaux, ce qui nécessite des stratégies de sécurité des transactions ou une corrélation SIEM en plus des journaux que vous configurez pour déterminer la logique de détection.
• Les politiques de sécurité des transactions évaluent les événements en temps réel et bloquent les actions suspectes. Vous devez configurer ces stratégies.
• Le Journal d'audit de configuration suit les modifications administratives apportées par la plate-forme, mais vous devez les surveiller.
• La consignation des applications personnalisées capture dans Apex les événements relatifs à la sécurité que vous devez implémenter.

Acheminez les journaux de Surveillance des événements vers les plates-formes SIEM pour les corréler à la télémétrie de sécurité d'entreprise. Concevez des règles d'alerte qui détectent les modèles suspects tout en minimisant les faux positifs grâce à des références comportementales.

Votre responsabilité : Acheminez la Surveillance des événements vers SIEM, configurez des stratégies de sécurité des transactions, implémentez la consignation personnalisée, établissez des bases comportementales.

Il est important de documenter les décisions architecturales qui prennent en charge la réponse aux incidents avant qu'ils ne se produisent.

• Les limites d'isolation conçoivent des solutions pour isoler les composants compromis sans perturber les fonctions métiers critiques. Vous devez configurer la révocation de l'ensemble d'autorisations, les changements de restriction IP et la fin de session pour fournir des capacités d'isolation rapides.
• La préservation judiciaire utilise la Surveillance des événements pour fournir des journaux d'activité détaillés (fonctionnalité de la plate-forme). Le Journal d'audit des champs préserve l'historique des modifications des données en fonction de votre configuration. Les journaux de conception acheminent vers un stockage immuable afin d'empêcher les assaillants de modifier votre architecture.
• Les procédures de récupération documentent les processus de récupération testés pour les types d'incident courants. Il est important de valider régulièrement l'intégrité des sauvegardes. Vous devez connaître votre objectif de temps de récupération (RTO) et votre objectif de point de récupération (RPO) pour les scénarios d'incident de sécurité.
• Les workflows de communication conçoivent des mécanismes de notification qui fonctionnent en cas d'incident (par exemple, des canaux de communication hors bande, des modèles prédéfinis et des procédures d'escalade qui ne dépendent pas de systèmes potentiellement compromis).
• Le canal de divulgation est destiné aux sites Experience Cloud publics. Il offre aux chercheurs externes une méthode documentée et surveillée pour vous signaler les problèmes de sécurité via une stratégie de divulgation publiée dans la norme RFC 9116 security.txt. Un rapport externe est souvent le premier signal d'un incident. Par conséquent, il est important d'établir ce chemin d'admission dans le cadre de l'architecture dont vous êtes responsable.

Votre responsabilité : Documentez les procédures d'isolation, acheminez les journaux vers un stockage externe immuable, testez les procédures de récupération tous les trimestres, établissez une communication hors bande et publiez un canal de divulgation des vulnérabilités pour les sites publics.

Chez Salesforce, il est important de préparer les capacités de réponse à des scénarios spécifiques à la plate-forme.

• Les comptes utilisateur compromis sont détectés via des anomalies de connexion Event Monitoring (par exemple, une géographie inattendue, des horaires inhabituels et de nouveaux appareils). Lorsque des comptes sont compromis, suspendez l'utilisateur, forcez la réinitialisation des identifiants, consultez le Journal d'audit de configuration et les journaux d'accès aux données pour déterminer la période de compromission.
• L'exfiltration de données en masse est détectée via les exportations de rapports Event Monitoring et les anomalies de volume d'accès aux données d'API. Lorsque des données sont exfiltrées, révoquez immédiatement les sessions, limitez les autorisations et identifiez les enregistrements et les niveaux de classification affectés.
• Le déploiement de code non autorisé est détecté via la surveillance du déploiement et les modifications de configuration du Journal d'audit de configuration. Lorsque le code non autorisé est déployé, annulez immédiatement le déploiement et auditez toutes les modifications apportées à l'identifiant de déploiement compromis.
• L'escalade des privilèges est détectée via la surveillance du Journal d'audit de configuration pour les changements d'autorisation qui se situent hors des fenêtres de modification approuvées. En cas d'escalade des privilèges, révoquez immédiatement les privilèges escaladés et auditez les activités exécutées avec un accès élevé.

Votre responsabilité : Documentez les procédures de réponse pour des scénarios spécifiques à la plate-forme, configurez la surveillance pour détecter chaque scénario, testez les procédures à travers des exercices sur table.

Après un incident, il est important de procéder à un examen post-incident sans jugement, axé sur les améliorations architecturales. Vous devez documenter ce qui s'est produit, les raisons pour lesquelles les contrôles existants n'ont pas permis de prévenir ou de détecter l'incident, et les changements architecturaux nécessaires pour réduire les risques futurs.

Objectifs de l'examen après incident :

• Déterminez la chronologie des incidents et les techniques d'attaque.
• Identifiez les échecs de contrôle qui ont activé l'incident.
• Documentez toutes les faiblesses architecturales révélées par l'incident.
• Donnez la priorité aux mesures correctives basées sur la réduction des risques.
• Partagez les leçons apprises entre les équipes.
• Mettez à jour les règles de détection et les procédures de réponse.

Il est important de suivre les métriques des incidents au fil du temps afin de déterminer le temps moyen de détection (MTTD), le temps moyen de réponse (MTTR) et l'étendue de l'impact.

Votre responsabilité : Effectuer un examen postérieur à l'incident en temps opportun, documenter les améliorations apportées aux ADR, suivre les tendances en matière de MTTD et de MTTR, partager les enseignements tirés.

Utilisez cette liste de contrôle lors des examens d'architecture, avant le déploiement en production et périodiquement pour une évaluation continue. Chaque élément représente vos responsabilités en tant qu'architecte Salesforce.

Responsabilité partagée

• Documentez tout ce que Salesforce sécurise (par exemple, l'infrastructure, la plate-forme et les certifications de conformité).
• Documentez tout ce que vous devez sécuriser (par exemple, configuration, accès, code personnalisé et gouvernance des données).
• Identifiez les domaines de responsabilité partagée (par exemple, réponse aux incidents, gestion des vulnérabilités et surveillance).
• Communiquer les responsabilités aux parties prenantes et aux équipes de mise en œuvre de la façon la plus claire et concise possible.

Architecture de sécurité

• Effectuez la modélisation des menaces en utilisant la méthodologie STRIDE avant de commencer à élaborer.
• Appliquez des contrôles approfondis de défense aux couches données, application, identité et intégration.
• Implémentez des principes de confiance zéro qui nécessitent une vérification explicite pour chaque demande d'accès.
• Tenir à jour l'inventaire des actifs de sécurité qui couvre les données confidentielles, les intégrations, les API et les comptes privilégiés.
• Documenter les décisions de l'architecture de sécurité dans les ADR, y compris l'analyse des menaces et la justification du contrôle.
• Sécurisez les clients headless et au nom de clients à la frontière de Salesforce Trust en propageant des identités par utilisateur plutôt que des jetons de pool.
• Stockez, permutez et limitez les privilèges des identifiants OAuth via des applications clientes externes.
• Pour les intégrations conteneurisées, appliquez automatiquement l'isolation des conteneurs en tant que frontière de sécurité, cryptez le trafic VPN inter-conteneurs et hybride avec mTLS (lorsque l'infrastructure l'exige), et alignez les zones de déploiement avec les certifications de résidence des données et de conformité.

Gestion des identités et des accès

• Définissez OWDs sur Privé pour les objets qui contiennent des données confidentielles.
• Réserver l'accès en lecture seule aux objets pour lesquels un accès en lecture large est une exigence documentée.
• Forcez la MFA pour tous les accès à l'interface utilisateur de production, et les clés de sécurité matérielles pour les comptes privilégiés. Les intégrations API uniquement qui utilisent des identifiants JWT Bearer ou client sont exemptées.
• Implémentez l'authentification unique en utilisant SAML 2.0 ou OpenID Connect avec l'authentification IdP forte.
• Utilisez OAuth 2.0 (porteur JWT préféré) pour toutes les authentifications d'API. N'utilisez jamais OAuth 2.0 pour des identifiants incorporés.
• Accordez l'accès via des ensembles d'autorisations basés sur des exigences documentées de moindre privilège.
• Appliquez des contrôles avancés aux comptes à impact critique (par exemple, restriction IP, alertes de connexion et examens périodiques de l'accès).
• Effectuez des examens périodiques de l'accès en utilisant une attestation documentée pour les comptes à privilèges élevés lorsque la fréquence est déterminée par les exigences de tolérance au risque et de conformité de l'organisation.
• Automatisez le cycle de vie de l’identité via le provisionnement SCIM et la détection des comptes inactifs pendant 90 jours.
• Exécutez les agents employés dans le contexte de l'utilisateur connecté, et provisionnez des Utilisateurs Agent dédiés avec le moindre privilège pour les agents clients. Ne le faites jamais pour un utilisateur invité de site public.
• Implémentez JWT pour l'authentification des agents en utilisant des identifiants d'instance d'agent et de définition de robot.
• Définissez des stratégies ABAC qui respectent les normes de classification des données et de balisage cohérent des métadonnées.

Protection des données et confidentialité

• Classez toutes les données et appliquez des contrôles de protection adaptés à chaque niveau de classification.
• Activez Shield Platform Encryption pour les données restreintes en utilisant la gestion des clés documentée.
• Demandez TLS 1.2+ pour toutes les intégrations avec authentification basée sur le certificat pour les données restrictées.
• Empêcher les données restrictées d'entrer dans des environnements de non-production via le masquage ou l'exclusion.
• Implémentez la gestion du consentement avec des workflows de suivi et de retrait précis.
• Élaborez des workflows relatifs aux droits de la personne concernée qui se terminent dans les délais de réponse de chaque cadre de gouvernance. Ils doivent être dimensionnés à la période la plus serrée de votre empreinte opérationnelle et paramétrés par juridiction à partir d'une source de conformité maintenue où chaque chiffre est confirmé par rapport au règlement en vigueur.
• Documentez les exigences de résidence des données et validez l'alignement de la région Hyperforce.

Conformité et conformité réglementaire

• Validez les certifications de plate-forme qui répondent aux exigences réglementaires de votre secteur d'activité.
• Activez la Surveillance des événements avec l'acheminement SIEM pour la rétention qui dépasse les limites en rétention native.
• Configurez le Journal d'audit des champs pour couvrir les champs restreints afin de vous assurer que la rétention respecte les minimums réglementaires.
• Maintenez des scores de Contrôle d'intégrité de sécurité de 80 % ou plus (Très bonne ou Excellente bande) et documentez toutes les exceptions.
• Automatisez la validation de la conformité pour les pipelines CI/CD qui se rompent lors d'infractions critiques.
• Mettez en œuvre des stratégies de sécurité des transactions pour la détection et la réponse en temps réel aux anomalies.

Cycle de développement sécurisé

• Effectuez la modélisation des menaces pendant la phase de conception (avant de réaliser des investissements importants dans la génération).
• Appliquez CRUD/FLS dans tous les environnements Apex.
• Utilisez l'application automatique du mode utilisateur pour l'API version 67.0 ou supérieure, ou WITH USERMODE ou stripInaccessible() pour l'API version 66.0 ou antérieure.
• N'utilisez pas WITH SECURITYENFORCED, qui a été retiré dans l'API version 67.0.
• Exécutez Salesforce Code Analyzer dans CI/CD lorsque des résultats critiques bloquent le déploiement.
• Demandez des révisions de code par des contrôleurs de sécurité pour toutes les modifications en production.
• Effectuez des tests de pénétration pour toutes les applications publiques et les sites Experience Cloud.
• Validez et désinfectez toutes les entrées utilisateur qui empêchent l'injection dans les contextes SOQL, SOSL et HTML.

Réaction aux incidents de sécurité

• Concevez des règles d'alerte Surveillance des événements pour détecter les modèles suspects via des niveaux de référence comportementaux.
• Acheminez les journaux vers un stockage externe immuable pour la préservation judiciaire.
• Documentez et testez les procédures de réponse aux incidents pour des scénarios spécifiques à la plate-forme.
• Effectuez des examens post-incident irréprochables avec les ADR pour capturer les améliorations architecturales.
• Suivez les métriques MTTD et MTTR pour identifier les écarts de détection et de réponse.

Partagez vos commentaires sur l'infrastructure bien archivée.