Field-Level Security
La sécurité au niveau du champ contrôle qui peut voir ou modifier un champ, indépendamment de l'objet et de la mise en page où il apparaît, et c'est facile à manquer lors d'un déploiement.
Définition
La sécurité au niveau du champ (FLS) détermine si un profile ou permission set peut lire ou modifier un champ spécifique, indépendamment de l'accès au niveau de l'objet et indépendamment du fait que le champ soit visible sur une mise en page donnée : un champ peut être lisible au niveau FLS tout en étant masqué par la mise en page, ou pleinement accessible via FLS tout en restant invisible si un permission set ne l'accorde pas. Ajouter un nouveau champ à un objet n'accorde automatiquement l'accès à aucun profile ni permission set, donc un déploiement qui ajoute des champs sans déployer aussi les métadonnées de permission set ou de profile correspondantes livre couramment des champs que personne ne peut voir. Apex ne respecte le FLS que lorsque le code est explicitement écrit pour le vérifier, avec WITH SECURITY_ENFORCED, stripInaccessible, ou des vérifications manuelles, donc un trigger ou une classe qui saute ces vérifications peut lire ou écrire un champ auquel un utilisateur ne devrait pas avoir accès, un constat fréquent lors des revues de sécurité AppExchange. Notre checklist de revue de sécurité couvre le FLS dans le cadre d'un audit plus large.
Comment cela fonctionne dans Serpent
La comparaison d'orgs de Serpent révèle la dérive de sécurité au niveau du champ entre les sandbox et la production de la même façon que pour les autres métadonnées de permission, afin qu'un champ livré sans accès correspondant ne soit pas découvert via un ticket de support. Voir la gestion des orgs dans Serpent pour savoir comment la dérive des permissions est suivie.
Démarrez gratuitement. Sans carte bancaire, sans installation, sans engagement.
Configuration en moins de 15 minutes. Aucun recrutement DevOps nécessaire.