Gestion des identités et des accès - Modèles


En savoir plus sur Well-Architected Trust → Identity and Access Management

Modèles

Où chercherÀ quoi ressemble le bien
Plate-forme | Architecture✅ Les contrôles d’accès vérifient explicitement l’identité à chaque requête, indépendamment de l’emplacement du réseau ou de l’appareil
Plate-forme | Architecture✅ Les contrôles de sécurité basés sur l’identité remplacent les hypothèses Trust basées sur le réseau
Plate-forme | Organisation✅ Les décisions d’accès prennent en compte qui demande l’accès (authentification), ce qu’il est autorisé à faire (autorisation) et le contexte (appareil, emplacement)
Plate-forme | Documentation✅ L’architecture de sécurité documente l’identité en tant que frontière Trust principale, pas périmètre réseau

Anti-modèles

Où chercherÀ quoi ressemble mal
Plate-forme | Architecture⚠️ Les utilisateurs sur le réseau d’entreprise ou VPN sont présumés fiables et bénéficient d’un accès élargi en fonction de la seule position du réseau
Plate-forme | Architecture⚠️ Les contrôles d’accès s’appuient sur le périmètre réseau plutôt que sur la vérification de l’identité
Plate-forme | Organisation⚠️ Les décisions d’accès ne prennent pas en compte les signaux de contexte (appareil, emplacement, heure, schémas de comportement)
Plate-forme | Documentation⚠️ L’architecture de sécurité traite la localisation du réseau comme frontière Trust principale

Modèles

Où chercherÀ quoi ressemble le bien
Plate-forme | Organisation✅ Les solutions exploitent les quatre couches d’accès Salesforce : Organisation (licences, fonctionnalités), Objet (CRUD), Champ (FLS), Enregistrement (partage)
Plate-forme | Organisation✅ Le modèle d’accès est conçu de haut en bas (organisation → objet → champ → enregistrement) et validé de bas en haut
Plate-forme | Organisation✅ Les paramètres par défaut de l’organisation (OWD) sont définis sur Privé pour les objets contenant des données confidentielles
Plate-forme | Organisation✅ Les OWD définis sur Accès public en lecture seule sont limités aux objets de référence (produits, catalogues de prix) dans lesquels une large visibilité prend en charge l’activité sans exposer au risque
Plate-forme | Organisation✅ Les contraintes au niveau de l’organisation (licences, plages IP, heures de connexion, autorisations de fonctionnalité) définissent les capacités de référence pour les populations d’utilisateurs
Plate-forme | Organisation✅ Les autorisations d’objet (via des profils et des ensembles d’autorisations) contrôlent l’accès créer, lire, modifier et supprimer à chaque objet pour les segments utilisateur
Plate-forme | Organisation✅ La sécurité au niveau du champ protège les champs confidentiels, même lorsque l’accès aux objets est accordé
Plate-forme | Organisation✅ Le partage au niveau de l’enregistrement utilise une hiérarchie des rôles et des règles de partage basées sur des exigences métiers documentées
Plate-forme | Organisation✅ L’accès est délibérément élargi par rapport à la base restrictive, pas restreint après des paramètres par défaut permissifs

Anti-modèles

Où chercherÀ quoi ressemble mal
Plate-forme | Organisation⚠️ Le modèle d’accès ne tire pas parti des quatre couches (organisation, objet, champ, enregistrement)
Plate-forme | Organisation⚠️ Les OWD sont définis sur Accès public en lecture/écriture pour plus de commodité pendant le développement sans plan de restriction
Plate-forme | Organisation⚠️ Les OWD trop permissifs définis tôt deviennent exponentiellement plus difficiles à restreindre à mesure que le volume de données augmente et que les processus métiers se cristallisent
Plate-forme | Organisation⚠️ La sécurité au niveau du champ n’est pas configurée, s’appuyant uniquement sur des contrôles d’accès au niveau de l’objet ou de l’enregistrement

Modèles

Où chercherÀ quoi ressemble le bien
Plate-forme | Organisation✅ L’authentification multifacteur (MFA) est automatiquement appliquée pour tous les utilisateurs qui accèdent aux environnements de production (obligatoire pour l’accès à l’interface utilisateur)
Plate-forme | Organisation✅ La MFA est étendue aux opérations privilégiées, notamment aux exportations de données en masse, aux changements d’autorisation et à la configuration administrative
Plate-forme | Organisation✅ L’authentification unique (SSO) utilise le protocole SAML 2.0 ou OpenID Connect
Plate-forme | Organisation✅ L’expiration de la session est correctement configurée : 2 heures pour les utilisateurs standard, 15-30 minutes pour les administrateurs et les utilisateurs qui accèdent aux données restreintes
Plate-forme | Organisation✅ Des restrictions IP sont appliquées pour les profils administratifs et les utilisateurs de l’intégration
Plate-forme | Organisation✅ Les heures de connexion limitent les comptes de service aux fenêtres opérationnelles attendues
Plate-forme | Organisation✅ L’activation native de l’appareil vérifie les connexions à partir d’appareils non reconnus ; les restrictions de la MFA et de l’IP ajoutent une protection pour les comptes à privilèges élevés
Plate-forme | Organisation✅ Si l’authentification unique est activée, les utilisateurs administrateurs approuvés ont un accès direct à la connexion (procédures de bris de verre)
Plate-forme | Organisation✅ La relation entre les utilisateurs et les entités qui se connectent à Salesforce est de 1:1 (aucun compte utilisateur partagé)
Plate-forme | Organisation✅ Le contrôle d’accès API empêche les utilisateurs de s’authentifier via des applications connectées non autorisées
Plate-forme | Identifiants nommés✅ Les identifiants nommés et les identifiants externes gèrent l’authentification de façon centralisée avec des capacités de rotation
Plate-forme | Identifiants nommés✅ Les identifiants nommés extraient les détails d’authentification du code, ce qui permet de mettre à jour les identifiants sans changer de code
Plate-forme | Identifiants nommés✅ Les identifiants ne sont jamais incorporés dans un code, des fichiers de configuration ou un contrôle de version
Plate-forme | Apex✅ Les méthodes qui exécutent l’authentification utilisent des identifiants nommés pour gérer les flux nom d’utilisateur/mot de passe
Plate-forme | Apex✅ Aucun nom d’utilisateur ou mot de passe n’est affiché dans le code sous des formats lisibles (pas de valeurs ou de chaînes codées en dur)
Plate-forme | Aura✅ Les méthodes qui exécutent l’authentification utilisent des identifiants nommés pour gérer les flux nom d’utilisateur/mot de passe
Plate-forme | Aura✅ Aucun nom d’utilisateur ou mot de passe n’est affiché dans le code sous des formats lisibles
Plate-forme | Composants Web Lightning (LWC)✅ Les méthodes qui exécutent l’authentification utilisent des identifiants nommés
Plate-forme | Composants Web Lightning (LWC)✅ Aucun nom d’utilisateur ou mot de passe n’est affiché dans le code
Intégration | API✅ Le flux de porteur JWT OAuth 2.0 est utilisé pour les intégrations serveur à serveur dans des environnements de confiance (préféré pour les intégrations en production)
Intégration | API✅ Le flux de serveur Web OAuth 2.0 est utilisé pour les intégrations serveur à serveur nécessitant un contexte utilisateur
Intégration | API✅ Le flux d’appareil OAuth 2.0 est utilisé pour les appareils headless; les outils CLI et CI/CD utilisent le flux serveur Web (sf org login web) ou le flux porteur JWT (sf org login jwt) — le flux d’appareil a été bloqué pour l’application connectée Salesforce CLI par défaut à compter du 28 août 2025
Intégration | API✅ Le flux OAuth nom d’utilisateur-mot de passe n’est pas utilisé. Les intégrations existantes qui s’appuient sur ce flux sont migrées vers le flux d’identifiants du porteur ou client JWT.

Anti-modèles

Où chercherÀ quoi ressemble mal
Plate-forme | Organisation⚠️ La MFA n’est pas appliquée pour l’accès à l’environnement de production
Plate-forme | Organisation⚠️ Les configurations de connexion ne respectent pas les exigences de la MFA Salesforce
Plate-forme | Organisation⚠️ La MFA n’est pas étendue aux opérations privilégiées (exportations en masse, changements d’autorisation, configuration administrative)
Plate-forme | Organisation⚠️ L’expiration de la session n’est pas configurée ou est excessivement permissive (>24 heures)
Plate-forme | Organisation⚠️ Les stratégies de session ne différencient pas les utilisateurs standard et les administrateurs/utilisateurs accédant aux données restreintes
Plate-forme | Organisation⚠️ Les restrictions IP ne sont pas appliquées pour les profils administratifs et les utilisateurs de l’intégration
Plate-forme | Organisation⚠️ Les comptes de service n’ont pas d’heures de connexion limitées aux fenêtres opérationnelles attendues
Plate-forme | Organisation⚠️ Les comptes à privilèges élevés ne dépendent que de l’activation de l’appareil – aucune restriction de MFA ou IP ajoutée
Plate-forme | Organisation⚠️ Si l’authentification unique est activée, aucun utilisateur administrateur approuvé n’a un accès direct à la connexion (pas de procédure de bris de verre)
Plate-forme | Organisation⚠️ La relation entre les utilisateurs et les entités n’est pas 1:1 (des comptes utilisateur partagés existent)
Plate-forme | Organisation⚠️ Le contrôle d’accès API n’est pas activé
Plate-forme | Identifiants nommés⚠️ Les identifiants sont incorporés directement dans un code, des fichiers de configuration ou un contrôle de version
Plate-forme | Apex⚠️ Les noms d’utilisateur et les mots de passe apparaissent dans un code sous des formats lisibles
Plate-forme | Apex⚠️ L’authentification est gérée de façon ponctuelle sans mise en œuvre cohérente
Plate-forme | Aura⚠️ L’authentification est gérée de façon ad hoc sans identifiant nommé
Plate-forme | Aura⚠️ Les noms d’utilisateur et les mots de passe apparaissent dans le code
Plate-forme | Composants Web Lightning (LWC)⚠️ L’authentification est gérée de façon ad hoc sans identifiant nommé
Plate-forme | Composants Web Lightning (LWC)⚠️ Les noms d’utilisateur et les mots de passe apparaissent dans le code
Plate-forme | Entreprise⚠️ Les SLA et les exigences de provisionnement et de déprovisionnement utilisateur n’existent pas
Intégration | API⚠️ Le flux OAuth nom d’utilisateur-mot de passe est utilisé lorsque des flux OAuth plus sécurisés sont disponibles
Intégration | API⚠️ Les étendues OAuth sont trop permissives (accès total lorsque l’étendue limitée est suffisante)
Intégration | API⚠️ Les identifiants client (ID client, secret client) sont stockés de façon non sécurisée dans des fichiers de code ou de configuration

Modèles

Où chercherÀ quoi ressemble le bien
Plate-forme | Organisation✅ La profondeur de la hiérarchie des rôles est de 5 à 7 niveaux maximum (évitant les surcoûts de performance et la complexité du dépannage)
Plate-forme | Organisation✅ Les ensembles d’autorisations et les groupes d’ensembles d’autorisations offrent un accès flexible et additif sans prolifération de profils
Plate-forme | Organisation✅ Les ensembles d’autorisations accordent l’accès à des fonctions, des applications ou des privilèges temporaires élevés spécifiques
Plate-forme | Organisation✅ Les groupes d’ensembles d’autorisations combinent des ensembles d’autorisations associés avec des capacités de désactivation pour les exceptions
Plate-forme | Organisation✅ Tous les accès fonctionnels sont accordés via des ensembles d’autorisations et des groupes d’ensembles d’autorisations (pas des profils), ce qui offre de la flexibilité à mesure que les rôles évoluent
Plate-forme | Organisation✅ Les stratégies de sécurité des transactions étendent l’autorisation avec l’évaluation contextuelle en temps réel
Plate-forme | Organisation✅ Les stratégies de sécurité des transactions détectent et bloquent les comportements anormaux (téléchargements de données en masse dépassant les modèles, connexion à partir de zones géographiques inattendues, changements d’autorisation hors des fenêtres de modification)
Plate-forme | Organisation✅ Les restrictions IP sont configurées pour les opérations hautement confidentielles ou l’accès aux données
Plate-forme | Organisation✅ Un utilisateur d’intégration API-only unique est configuré pour chaque intégration
Plate-forme | Apex✅ Tous les codes accédant aux données appliquent CRUD et FLS en utilisant WITH USER_MODE, WITH SYSTEM_MODE keywords ou les méthodes Security.stripInaccessible()
Plate-forme | Apex✅ Les requêtes SOQL utilisent des mots-clés WITH USER_MODE ou WITH SYSTEM_MODE explicitement basés sur des exigences métiers
Plate-forme | Apex✅ Les opérations DML utilisent Security.stripInaccessible() pour appliquer automatiquement l’accès avant les opérations insert/update/upsert
Plate-forme | Apex✅ Les instructions DML de base de données déclarent explicitement le mode utilisateur ou système pour les opérations de données
Plate-forme | Apex✅ Les opérations de base de données utilisent des méthodes stripInaccessible() pour filtrer les résultats de requêtes et de sous-requêtes
Plate-forme | Apex✅ Les mots-clés de partage (avec partage, sans partage, partage hérité) sont utilisés correctement en fonction des exigences de sécurité métier
Plate-forme | Normes de conception✅ Les cas d’utilisation pour accorder des privilèges élevés (Modifier toutes les données, Afficher toutes les données) sont clairement documentés avec une justification métier

Anti-modèles

Où chercherÀ quoi ressemble mal
Plate-forme | Organisation⚠️ La hiérarchie des rôles est plus profonde que 5-7 niveaux, ce qui entraîne une surcharge de performance dans les calculs de partage et le dépannage de la complexité
Plate-forme | Organisation⚠️ La hiérarchie des rôles accorde un large accès sans justification métier
Plate-forme | Organisation⚠️ Les profils sont clonés à répétition pour des variations d’autorisation mineures, créant des dizaines de profils avec des distinctions imprécises
Plate-forme | Organisation⚠️ Les profils contiennent des contrôles d’accès pour les métadonnées (doivent utiliser des ensembles d’autorisations)
Plate-forme | Organisation⚠️ Les stratégies de sécurité des transactions ne sont pas implémentées pour détecter les comportements anormaux
Plate-forme | Organisation⚠️ Les restrictions IP ne sont pas configurées pour les opérations hautement confidentielles ou l’accès aux données
Plate-forme | Organisation⚠️ Les utilisateurs API uniquement ne sont pas configurés ou sont partagés entre plusieurs intégrations
Plate-forme | Organisation⚠️ Les autorisations Afficher toutes les données ou Modifier toutes les données sont accordées sans justification documentée
Plate-forme | Apex⚠️ Les requêtes SOQL/SOSL et les opérations DML sont exécutées en mode système par défaut sans contrôle d’accès explicite
Plate-forme | Apex⚠️ L’application du CRUD et du FLS est incohérente ou manquante
Plate-forme | Apex⚠️ SOQL s’appuie sur WITH SECURITY_ENFORCED, qui a été retiré et entraîne désormais une erreur de compilation (remplacer par WITH USER_MODE)
Plate-forme | Apex⚠️ Les mots-clés de partage sont utilisés de façon incohérente ou pas du tout
Plate-forme | Normes de conception⚠️ Les cas d’utilisation pour accorder des autorisations élevées ne sont pas clairement documentés

Modèles

Où chercherÀ quoi ressemble le bien
Plate-forme | Data 360✅ RBAC (rôles, profils, ensembles d’autorisations) contrôle l’accès à la plate-forme (qui peut utiliser Data 360), ABAC contrôle l’accès aux données (quelles données ils affichent en fonction des attributs)
Plate-forme | Data 360✅ Les agents IA exécutent dans le contexte de l’utilisateur demandeur (au nom de). Par conséquent, les requêtes générées par l’agent sont limitées par l’accès de cet utilisateur au lieu d’être exécutées avec un accès au niveau système
Plate-forme | Documentation✅ La taxonomie de classification des données est documentée avec des définitions d’attributs, des règles d’application et une justification métier

Anti-modèles

Où chercherÀ quoi ressemble mal
Plate-forme | Data 360⚠️ L’accès qui doit suivre la classification des données est forcé par la hiérarchie des rôles et le partage, qui ne peut pas l’exprimer, au lieu d’atteindre le contrôle d’accès basé sur l’attribut
Plate-forme | Data 360⚠️ Contournement FLS : les utilisateurs sans accès au niveau du champ récupèrent des données via une API ou des requêtes SOQL qui n’appliquent pas FLS
Plate-forme | Data 360⚠️ Les agents IA interrogent les données sans les exécuter dans le contexte de l’utilisateur demandeur ; les requêtes générées par l’agent contournent les contrôles d’accès au niveau de l’objet, du champ et de l’enregistrement
Plate-forme | Data 360⚠️ Le contexte d’exécution de l’agent ne comprend pas les attributs user-on-of; les agents fonctionnent avec un accès au niveau système
Plate-forme | Documentation⚠️ La taxonomie de classification des données n’est pas documentée; les définitions d’attributs varient selon l’équipe, ce qui crée une application incohérente

Modèles

Où chercherÀ quoi ressemble le bien
Plate-forme | Organisation✅ Les comptes à impact critique (administrateurs système, utilisateurs de l’intégration, comptes de processus automatisés) sont identifiés et suivis dans l’inventaire des actifs
Plate-forme | Organisation✅ Les comptes à impact critique représentent des objectifs à valeur élevée en raison des privilèges élevés offrant un large accès à la plate-forme
Plate-forme | Organisation✅ Des clés de sécurité matérielles ou des applications d’authentification sont requises pour la MFA (pas SMS, qui est vulnérable au changement de carte SIM)
Plate-forme | Organisation✅ Les plages IP de connexion sont limitées aux emplacements administratifs connus
Plate-forme | Organisation✅ Les alertes de connexion et les notifications de changement d’autorisation sont activées
Plate-forme | Organisation✅ Examens trimestriels de l’accès effectués avec une attestation documentée
Plate-forme | Organisation✅ Des procédures de bris de verre existent pour l’accès d’urgence avec l’audit après utilisation
Intégration | Comptes de service✅ Les flux OAuth sont utilisés pour des comptes d’intégration et de service (jamais nom d’utilisateur-mot de passe)
Intégration | Comptes de service✅ Des restrictions IP sont appliquées pour les utilisateurs de l’intégration
Intégration | Comptes de service✅ Les planifications de rotation des identifiants sont mises en œuvre (trimestriel ou par police)
Intégration | Comptes de service✅ Les modèles d’utilisation d’API anormaux sont surveillés via la Surveillance des événements
Intégration | Comptes de service✅ Chaque intégration a un compte de service dédié avec les autorisations minimales requises (pas partagé « utilisateur de l’intégration » avec un large accès)
Intégration | Comptes de service✅ Les comptes de service appliquent rigoureusement le moindre privilège, car ils fonctionnent sans surveillance

Anti-modèles

Où chercherÀ quoi ressemble mal
Plate-forme | Organisation⚠️ Les comptes à impact critique (administrateur, intégration, automatisation) ne sont pas identifiés, suivis ou inventoriés
Plate-forme | Organisation⚠️ Les administrateurs système utilisent la MFA par SMS au lieu de clés de sécurité matérielles ou d’applications d’authentification
Plate-forme | Organisation⚠️ Les comptes à impact critique n’ont pas d’heure de connexion ni de restrictions IP
Plate-forme | Organisation⚠️ Aucune alerte n’est configurée pour les changements de connexion ou d’autorisation sur les comptes privilégiés
Plate-forme | Organisation⚠️ L’accès aux comptes à impact critique n’est jamais révisé ou révisé de façon irrégulière (pas trimestrielle)
Plate-forme | Organisation⚠️ Aucune procédure de bris de verre n’existe pour l’accès d’urgence
Intégration | Comptes de service⚠️ Un seul compte « Utilisateur d’API » est partagé entre plusieurs intégrations avec l’autorisation Modifier toutes les données
Intégration | Comptes de service⚠️ Les comptes de service utilisent l’authentification nom d’utilisateur-mot de passe lorsque OAuth est disponible
Intégration | Comptes de service⚠️ Les identifiants de compte de service utilisent des mots de passe statiques inchangés depuis des années (pas de rotation)
Intégration | Comptes de service⚠️ Les comptes de service ont des privilèges excessifs au-delà de ce qu’exige l’intégration
Intégration | Comptes de service⚠️ Les schémas d’utilisation d’API anormaux pour les comptes de service ne sont pas surveillés

Modèles

Où chercherÀ quoi ressemble le bien
Plate-forme | Processus✅ Le cycle de vie de l’identité comprend : Provisionnement (créer avec l’accès de base), Ajustement de l’accès (accorder/révoquer à mesure que les rôles changent), Recertification périodique (validation trimestrielle), Déprovisionnement (révoquation immédiate)
Plate-forme | Organisation✅ SCIM (Système de gestion des identités inter-domaines) est implémenté pour le provisionnement automatisé auprès des fournisseurs d’identité
Plate-forme | Processus✅ Provisionnement crée des comptes avec une fonction de travail de correspondance d’accès de base, déclenchée par des événements système RH
Plate-forme | Processus✅ L’ajustement de l’accès accorde des autorisations supplémentaires lorsque les rôles s’étendent et révoque les autorisations lorsque les rôles changent
Plate-forme | Processus✅ La recertification périodique a lieu tous les trimestres où les responsables examinent et valident l’accès de leurs équipes
Plate-forme | Processus✅ Le déprovisionnement révoque immédiatement l’accès lorsque l’emploi prend fin ou lorsque le rôle ne nécessite plus Salesforce
Plate-forme | Organisation✅ La détection automatisée identifie les utilisateurs qui ne se sont pas connectés sous 90 jours et déclenche des workflows d’examen de l’accès
Plate-forme | Organisation✅ Le provisionnement juste à temps (JIT) crée automatiquement des utilisateurs à partir de l’authentification unique lorsque nécessaire

Anti-modèles

Où chercherÀ quoi ressemble mal
Plate-forme | Organisation⚠️ Le provisionnement SCIM n’est pas implémenté malgré l’intégration du fournisseur d’identité
Plate-forme | Processus⚠️ Les nouveaux utilisateurs sont créés manuellement sans procédure d’intégration standard
Plate-forme | Processus⚠️ L’accès initial des utilisateurs est incohérent ou basé sur la copie d’utilisateurs existants
Plate-forme | Processus⚠️ Les changements d’accès pour les changements de rôle ou les transferts sont retardés ou incomplets
Plate-forme | Processus⚠️ L’embarquement est retardé ; les anciens employés gardent l’accès après la cessation d’emploi (pas la désactivation le jour même)
Plate-forme | Organisation⚠️ Aucune automatisation n’existe pour le provisionnement utilisateur (création manuelle d’utilisateur uniquement)
Plate-forme | Processus⚠️ Aucune campagne de recertification de l’accès n’existe (pas de bilan trimestriel ou annuel)
Plate-forme | Processus⚠️ L’accès inutile identifié lors de la recertification n’est pas retiré
Plate-forme | Processus⚠️ La recertification de l’accès n’est pas rigoureuse pour les comptes privilégiés, l’accès inter-organisations, les utilisateurs externes
Plate-forme | Organisation⚠️ Les comptes dormants (pas de connexion depuis plus de 90 jours) s’accumulent sans révision ni désactivation