Votre instance ServiceNow est-elle sur-autorisée ?
Le contrôle d'accès sur ServiceNow ne casse rarement d'un coup - il dérive, une exception « ajoutons juste le rôle » après l'autre, jusqu'à ce que plus personne ne puisse dire qui voit quoi, ni pourquoi.
D'où vient réellement la sur-autorisation
Presque personne ne cherche délibérément à sur-autoriser une table. Cela s'accumule à travers des décisions individuellement raisonnables que personne ne revoit ensuite.
Rôles au niveau table plutôt qu'au niveau enregistrement
Un rôle requis pour voir n'importe quel enregistrement d'une table, alors que le besoin réel n'était que « les enregistrements assignés à cette personne ».
Conditions ACL qui s'appliquent à tout le monde
Un script de condition resté d'une phase de test, ou écrit de façon assez large pour s'évaluer vrai quel que soit le demandeur.
Dérogations admin laissées activées
Ajoutées pour un correctif ponctuel pendant un incident, jamais revues une fois l'incident clos.
ACL de niveau champ manquantes sur des champs sensibles
La table elle-même est protégée, mais un champ précis contenant des données sensibles n'a aucune restriction supplémentaire.
Attributions de rôles orphelines
Un rôle attribué à un groupe pour un projet terminé depuis longtemps - l'accès n'a jamais été révoqué car personne n'en a la responsabilité.
Comment le vérifier réellement, sans deviner
Une revue d'accès n'a généralement pas besoin d'un nouvel outil - elle a besoin de quelqu'un qui lise réellement ce qui existe déjà.
Lire l'ACL, pas seulement son nom
Une ACL au nom explicite peut quand même avoir une condition ou un script accordant bien plus que ce que son nom laisse penser. Le seul moyen de le savoir est de lire les champs réels de condition et de script de sys_security_acl, par opération et par table.
Rechercher spécifiquement les dérogations admin
Elles sont conçues pour être temporaires par nature - un passage rapide sur les ACL actives à la recherche de l'une encore activée est l'une des vérifications les plus utiles disponibles.
Recouper les rôles avec l'usage réel
Un rôle qui existe sur le papier n'est pas la même chose qu'un rôle sur lequel quelqu'un s'appuie réellement. Comparer qui détient un rôle avec qui a réellement accédé aux données qu'il protège fait remonter les attributions dont plus personne ne se souvient.
Schémas à auditer en premier
- ACL sans condition et sans script
- Accès en écriture large au niveau table pour une étape de workflow étroite
- Rôles hérités via une appartenance à un groupe dont personne ne se souvient
- Champs sensibles sans ACL de niveau champ
- ACL liées à la sécurité non modifiées depuis plus d'un an
La version manuelle ne passe pas à l'échelle
Une vraie revue d'accès signifie lire réellement chaque ACL pertinente, recouper les détenteurs de rôles avec l'usage réel - et recommencer le trimestre suivant, car la dérive ne s'arrête jamais. C'est exactement le genre de travail à la fois réellement utile et réellement fastidieux, ce qui explique qu'il soit sans cesse repoussé.
Cette revue exécutée en continu, automatiquement
Notre propre plateforme, neo.ai, lit la condition et la combinaison de rôles réelles de chaque ACL active selon un calendrier, juge si l'accès correspond réellement à ce que l'enregistrement protège, et ne fait remonter que ce qui mérite vraiment un regard. C'est l'une des sept catégories qu'elle surveille sur une instance ServiceNow.