Access groups Pega mal configurés : la fuite de données qui ne ressemble pas à un piratage

Quand on parle de fuite de données, l'imaginaire se peuple de hackers, de ransomwares et de bases exfiltrées en pleine nuit. La réalité, sur une plateforme Pega de gestion de la relation client ou de traitement de dossiers, est souvent plus banale et tout aussi grave : la donnée n'a pas été volée, elle a simplement été montrée à la mauvaise personne.

Le modèle de sécurité de Pega repose sur un empilement précis : les access groups rattachent un utilisateur à un ou plusieurs rôles ; les access roles portent des privilèges (Access of Role to Object, ARO) ; et des règles plus fines — Access When, Access Control Policies, restrictions au niveau ligne et colonne — déterminent qui voit quoi, jusqu'à la propriété. C'est puissant, mais c'est aussi un terrain où une erreur de modélisation ne déclenche aucune alerte.

Un access group trop large, un rôle hérité qui cumule des privilèges non prévus, une Access Control Policy oubliée sur un objet sensible : et soudain, un opérateur de back-office peut consulter des dossiers, des coordonnées, des éléments de santé ou des données bancaires qu'il n'aurait jamais dû voir. Pas de hacker. Juste un écran qui s'affiche pour quelqu'un qui n'y avait pas droit.

Beaucoup de prestataires croient qu'une violation de données suppose une attaque. Le RGPD est explicite sur le contraire. Une violation de données à caractère personnel est définie comme une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l'altération, la divulgation ou l'accès non autorisé à des données. Le mot clé est « accès non autorisé » : il englobe parfaitement l'access group mal configuré.

Autrement dit, dès qu'un opérateur peut accéder à des données qui ne relèvent pas de sa fonction, vous êtes potentiellement face à une violation, même si aucune donnée n'est sortie de l'entreprise. Les conséquences pour le responsable de traitement (votre client final) sont lourdes :

• L'obligation de documenter la violation dans un registre interne.
• Selon le risque, la notification à la CNIL dans un délai contraint.
• Le cas échéant, l'information des personnes concernées.
• Une exposition à des sanctions administratives en cas de négligence dans la sécurité du traitement.

Le principe de minimisation des accès — chacun ne voit que ce qui lui est nécessaire — n'est pas une bonne pratique optionnelle : c'est une traduction directe des exigences du RGPD en matière de sécurité du traitement.

Sur le papier, le responsable de traitement est votre client. Mais le consultant Pega qui a modélisé les access groups et configuré les privilèges n'est pas hors-jeu pour autant.

Si l'exposition résulte d'une erreur de modélisation imputable à votre intervention — un rôle mal scopé, une Access Control Policy absente alors qu'elle était spécifiée, un cumul de privilèges que vous auriez dû cloisonner — votre responsabilité de prestataire peut être recherchée pour faute professionnelle. Et comme pour les pénalités de SLA, l'intégrateur ou l'ESN qui subit la réclamation du client peut se retourner contre vous.

Le consultant n'est pas responsable du traitement, mais il est responsable de la qualité de ce qu'il livre. Une habilitation mal cloisonnée est un livrable défectueux comme un autre.

Votre meilleure protection en amont est la traçabilité de la spécification : qui a défini la matrice d'habilitations ? Avez-vous implémenté ce qui était demandé, ou improvisé ? Une matrice d'accès validée par le client, des revues documentées et un historique clair des règles de sécurité déplacent la frontière de la responsabilité — et facilitent grandement votre défense.

Une violation de données génère deux familles de coûts très différentes, et il est essentiel de savoir laquelle votre contrat couvre.

La première relève de votre responsabilité civile professionnelle classique : les dommages que votre faute cause à autrui — au client, et par ricochet aux personnes concernées. C'est le terrain de la faute de modélisation.

La seconde est spécifiquement cyber, et c'est là que l'assurance cyber (ou l'option Cyber adossée à votre RC Pro) prend tout son sens. Elle couvre la gestion opérationnelle de la violation :

• Les frais d'expertise technique pour qualifier l'incident et délimiter le périmètre des données exposées.
• L'accompagnement dans les obligations de notification (CNIL, personnes concernées).
• Les frais de remédiation et de gestion de crise.
• La défense en cas de mise en cause et la prise en charge de certaines conséquences pécuniaires.

Pour un consultant Pega qui manipule au quotidien les access groups d'applications brassant des données clients sensibles, cette option n'est pas un supplément cosmétique. C'est la garantie qui transforme une violation potentiellement ruineuse en incident géré.

Pour rendre le risque concret, déroulons un enchaînement que connaissent les architectes Pega. Un consultant intervient pour ajouter une fonctionnalité à une application de gestion de dossiers clients. Le métier demande qu'un nouveau profil d'opérateur puisse traiter une catégorie de cases supplémentaire. Solution rapide : rattacher ce profil à un access group existant qui contient déjà les bons privilèges pour cette catégorie.

Le problème, c'est que cet access group hérite aussi d'un access role historique, conçu pour une autre population, et qui ouvre l'accès à des objets sensibles — coordonnées complètes, pièces justificatives, éléments contractuels confidentiels. En réutilisant le groupe « parce qu'il marchait », le consultant accorde silencieusement à la nouvelle population bien plus que ce que le métier avait demandé.

Personne ne s'en aperçoit. L'application fonctionne, les utilisateurs voient ce dont ils ont besoin — et, en prime, ce dont ils ne devraient jamais voir. Le défaut reste invisible jusqu'au jour où un audit, une plainte ou un contrôle le révèle.

Ce scénario illustre pourquoi la sécurité Pega exige une discipline particulière : la commodité (réutiliser un groupe existant) est précisément le chemin le plus court vers l'exposition. La rigueur consiste à composer l'habilitation à partir des besoins réels, pas à recycler ce qui existe.

La meilleure assurance reste de ne pas provoquer le sinistre. Sur la sécurité Pega, ces réflexes réduisent considérablement le risque d'exposition :

1. Partir d'une matrice d'habilitations validée par le client : ne jamais improviser les access groups sans référentiel écrit.
2. Appliquer la minimisation : chaque rôle ne porte que les privilèges strictement nécessaires, jamais « par sécurité » un peu plus.
3. Cloisonner les données sensibles avec des Access Control Policies au niveau objet, et au besoin au niveau propriété.
4. Tester les habilitations négativement : vérifier non seulement que chacun voit ce qu'il doit voir, mais surtout qu'il ne voit pas le reste.
5. Auditer les héritages de rôles : un access group qui hérite de plusieurs rôles peut cumuler des privilèges inattendus.
6. Documenter chaque décision de sécurité pour tracer ce qui relève de la spécification client et ce qui relève de votre implémentation.

Ces gestes ne suppriment pas le risque, mais ils le rendent maîtrisé et défendable. Et lorsqu'un incident survient malgré tout, c'est la combinaison de votre rigueur documentaire et de votre couverture cyber qui fait la différence entre une frayeur et une catastrophe.