Une bonne montée de version, c'est une montée de version où il ne se passe rien. Du côté du cross-scope en Australia, c'est précisément le piège. Le jour de l'upgrade, tout continue de fonctionner. La casse arrive plus tard, le jour où quelqu'un active les contrôles, parfois sans réaliser que c'est ce qu'il vient de faire.
Ce que protège l'accès cross-scope
ServiceNow isole les applications les unes des autres. Une application scoped vit dans son propre namespace, et le code qui s'exécute à l'intérieur ne peut pas librement lire ou écrire des ressources appartenant à un autre scope. Quand une opération traverse cette frontière, la plateforme empile plusieurs niveaux de contrôle.
D'abord, les paramètres Application Access sur la table cible, qui décident si d'autres applications peuvent lire, créer, mettre à jour ou supprimer des enregistrements. Ensuite, l'enregistrement de privilège cross-scope, dans la table sys_scope_privilege, qui déclare qu'un scope source est autorisé à effectuer une opération précise sur une ressource précise dans un scope cible. Enfin, sur les applications qui l'implémentent, le Restricted Caller Access, qui exige une approbation explicite de l'administrateur avant qu'un scope tiers ne consomme la donnée.
Rien de tout cela n'est nouveau. Les privilèges cross-scope existent depuis que les applications scoped existent, et le Restricted Caller Access est arrivé avec London. Ce qui change avec Australia, ce n'est pas le mécanisme. C'est la valeur par défaut.
Deux instances, deux comportements
Une instance créée directement sous Australia démarre avec les contrôles cross-scope renforcés déjà activés. Une instance upgradée depuis Zurich vers Australia les conserve désactivés.
La logique de l'éditeur est facile à suivre : durcir les nouvelles instances, et éviter de casser des dizaines de milliers d'intégrations existantes le jour de l'upgrade. La conséquence pour vous est moins confortable. Deux instances affichant le même numéro de version peuvent se comporter différemment face exactement au même code.
C'est ce qui rend le diagnostic difficile. Une intégration qui passe dans un environnement peut échouer dans un autre, ou l'inverse, sans qu'aucune différence de configuration n'apparaisse dans un update set. La différence n'est pas dans le code livré. Elle est dans l'historique de l'instance.
Le corollaire est simple. Rien ne casse le jour de l'upgrade. Ça casse le jour où quelqu'un active les contrôles. Et cette personne peut être un administrateur appliquant une recommandation de durcissement, un audit de sécurité relevant le constat, ou une instance de sous-production fraîchement provisionnée pendant que la production reste sur son réglage hérité.
Un attribut de table porte la règle
Le contrôle se situe au niveau de la table, via l'attribut enforce_dot_walk_cross_scope_access.
// attribut de table, par table
enforce_dot_walk_cross_scope_access
// table créée avant Australia
// à ajouter manuellement
// créée après
// appliqué automatiquementDeux conséquences pratiques. D'abord, ce n'est pas un interrupteur global : il se règle table par table, ce qui exclut de traiter le sujet avec un seul bouton. Ensuite, tout votre parc de tables antérieur à Australia n'est pas couvert jusqu'à ce que quelqu'un fasse le travail explicitement.
Le mot important dans le nom de l'attribut est dot_walk. C'est la partie que personne n'inventorie.
Le dot-walk est l'angle mort
Quand les équipes préparent un upgrade, elles inventorient les intégrations qui écrivent. C'est le réflexe naturel : une écriture est visible, elle produit un enregistrement, elle apparaît dans une piste d'audit. Les lectures indirectes ne laissent rien de comparable.
Un dot-walk est une lecture indirecte, et elle traverse les tables. Une intégration qui interroge incident.caller_id.department.manager.email ne lit pas une table, elle en lit quatre. Chacune appartient à un scope, et chaque franchissement de frontière devient un contrôle à passer dès que l'enforcement est actif sur la table concernée.
Un connecteur de monitoring qui pousse des incidents enrichis avec le nom du site et le propriétaire du service, un flux RH qui ajoute des données de manager à une demande, un export vers un outil de reporting qui aplatit trois niveaux de référence : tout cela fonctionne aujourd'hui sans qu'un seul privilège cross-scope n'ait jamais été déclaré, parce que le comportement historique était permissif. Ils n'apparaissent dans aucun inventaire, précisément parce qu'ils n'ont jamais échoué.
Les intégrations non standard cassent en premier
Il y a un ordre assez net dans ce qui casse.
Les actions et les flows construits sur des tables autres qu'incident sont exposés en premier. Le socle ITSM standard bénéficie de privilèges livrés avec la plateforme et testés par l'éditeur. Dès que vous sortez de ce socle, vers une table métier, une table étendue ou un modèle d'incident fortement personnalisé, ces déclarations n'existent plus et vous devez les écrire vous-même.
Les implémentations d'incident fortement personnalisées suivent immédiatement. Une table incident étendue avec ses propres références vers des tables applicatives est fonctionnellement une intégration cross-scope permanente, même si personne ne l'a jamais décrite ainsi.
Et il y a une asymétrie qui vaut la peine d'être retenue. Les applications éditeur déclarent leurs privilèges dans leur package et sont testées face à l'enforcement, elles font donc apparaître une erreur explicite quand quelque chose manque. Vos propres applications scoped internes n'ont personne pour faire ce travail. Elles ne vous préviendront pas.
Quatre vérifications avant de monter de version
Listez toutes les intégrations qui lisent hors de leur scope. Pas seulement celles qui écrivent. Le point de départ le plus rapide est un balayage de sys_scope_privilege pour voir ce qui est déjà déclaré, avec une revue des applications dont le Runtime Access Tracking est réglé sur Tracking. Ce sont celles où la plateforme crée des enregistrements de privilège au fil de l'eau sans jamais refuser l'opération. La liste des privilèges créés automatiquement est un inventaire de vos vraies dépendances cross-scope, pas de celles que vous aviez prévues.
Sachez si chaque instance a été créée ou upgradée. Production, staging, développement, formation. La réponse peut différer d'une instance à l'autre, et cet écart est exactement ce qui produit les diagnostics impossibles.
Testez avec les contrôles activés, d'abord en sous-production. Activez l'enforcement sur les tables concernées dans une instance non-productive, puis rejouez les parcours d'intégration et les suites ATF. Les échecs apparaissent dans le journal système comme des refus explicites, typiquement une ScopeAccessNotGrantedException ou un message indiquant qu'une opération a été refusée en raison de la politique d'accès cross-scope de la table. Ces messages sont exploitables : ils nomment le scope source, la ressource cible et l'opération. C'est votre plan de remédiation.
Choisissez la date à laquelle vous les activez. Ne l'héritez pas. C'est la plus importante des quatre.
Le vrai sujet, c'est la maîtrise du calendrier
Hériter d'un comportement, c'est accepter que le basculement se produise à un moment que vous n'avez pas choisi, sur un périmètre que vous n'avez pas cartographié, généralement à cause d'une action de durcissement légitime menée par quelqu'un qui ne connaissait pas la dépendance.
Choisir la date, c'est l'inverse. Vous inventoriez, vous déclarez les privilèges dont vous avez besoin, vous testez, puis vous activez pendant une fenêtre où vos équipes sont disponibles.
Une remarque sur la remédiation, parce que le raccourci est tentant et coûteux. La bonne réponse n'est pas de désactiver globalement l'enforcement pour restaurer un comportement permissif. C'est de déclarer les privilèges cross-scope dont vous avez besoin, un par opération et par ressource, en n'accordant que ce qui est réellement utilisé. Reporter le durcissement ne fait que déplacer le problème au prochain upgrade, avec un parc plus lourd et une documentation encore plus mince.
Vérifiez sur votre propre instance
Le comportement décrit ici s'observe instance par instance. Avant de planifier quoi que ce soit, vérifiez l'état de l'attribut sur vos tables sensibles dans vos propres environnements, et confrontez-le aux notes de version de votre patch level Australia. Deux instances de votre parc peuvent ne pas vous donner la même réponse.
Y. Gassama, fondateur d'Abarys Digital.
Abarys Digital est un cabinet de conseil ServiceNow marocain indépendant qui travaille en nearshore pour la France et le Canada. Nous menons des analyses d'impact d'upgrade et des remédiations, avec vos équipes ou de bout en bout.
L'intelligence digitale, taillée pour vous !