Un fournisseur SaaS de santé employait douze analystes de données chargés de concevoir des tableaux de bord analytiques destinés aux clients et des rapports internes d’informatique décisionnelle. L’équipe d’analyse avait reçu un accès en lecture à la base de données de production lors de la création de la fonction analytique, une décision pragmatique qui lui permettait d’interroger toutes les données nécessaires aux rapports qu’on lui demandait de produire. En quatre ans, l’équipe était passée de trois à douze analystes, la base de données de production contenait désormais les enregistrements de plus de deux cents entreprises clientes, et l’autorisation d’accès n’avait jamais été réexaminée. Chaque analyste pouvait interroger les dossiers de patients, les données cliniques ou les informations administratives de n’importe quel client, sans restriction, sans journalisation et sans revue. L’accès était techniquement en lecture seule : aucune écriture, aucune suppression. Il était aussi totalement illimité : n’importe lequel des douze analystes pouvait interroger n’importe quel enregistrement de n’importe quel client à tout moment, sans approbation, sans justification et sans contrôle d’audit. Une enquête sur une violation de données, ouverte après qu’un blogueur spécialisé dans la santé eut publié des informations semblant provenir de l’intérieur du système, a fini par remonter jusqu’à un analyste qui interrogeait depuis plus d’un an des dossiers hors de son périmètre de travail. Les contrôles d’accès l’avaient toujours permis. Personne ne surveillait.
Qu’est-ce que le problème du risque lié aux accès analytiques des fournisseurs, concrètement ?
Le risque lié aux accès analytiques apparaît lorsque l’accès aux données accordé aux équipes d’analyse (les personnes chargées de concevoir des tableaux de bord, des rapports et des modèles analytiques) est nettement plus large que ce qu’exige une tâche analytique donnée, et qu’il est maintenu sans les contrôles d’accès, la journalisation et la fréquence de revue appliqués aux autres formes d’accès privilégié aux données. L’accès analytique est généralement mis en place de manière large lors de la création de la fonction (« donner à l’équipe d’analyse un accès en lecture à la base de données ») et rarement réexaminé à mesure que l’équipe s’agrandit, que les données consultées deviennent plus sensibles et que le périmètre de ce dont chaque analyste a réellement besoin pour son rôle évolue.
Le manquement au principe du moindre privilège est la principale lacune de gouvernance. Dans la plupart des organisations, les accès privilégiés (comptes d’administration, accès en écriture aux systèmes de production, accès au traitement des paiements) font l’objet d’un cadrage minutieux, de circuits d’approbation et de revues périodiques. Les accès analytiques sont souvent traités comme une catégorie distincte qui ne nécessite pas une gouvernance équivalente, parce qu’ils sont en lecture seule et semblent moins risqués. La qualification de lecture seule est exacte : les analystes ne peuvent généralement ni modifier ni supprimer de données. La qualification de risque moindre doit être nuancée : l’accès en lecture à des ensembles de données complets contenant des informations personnelles sensibles, des dossiers financiers ou des données de santé est moins risqué que l’accès en écriture aux mêmes données, mais il n’est en aucun cas faiblement risqué dans l’absolu. L’analyste qui a lu des dossiers de patients en vue d’une divulgation non autorisée n’avait pas besoin d’un accès en écriture. Il lui fallait l’accès en lecture que tout le monde avait jugé anodin.
Le problème du périmètre aggrave le problème d’accès. Dans les environnements SaaS multilocataires, les équipes d’analyse ont souvent accès aux données de l’ensemble de la clientèle plutôt qu’à celles de clients précis, parce qu’il est plus facile de concevoir des tableaux de bord et des rapports lorsque l’analyste peut interroger l’ensemble des données. Un fournisseur SaaS de santé dont l’équipe d’analyse doit concevoir un tableau de bord des résultats cliniques pour le client A n’a techniquement pas besoin d’accéder aux données du client B pour ce travail ; mais si l’autorisation accorde un accès complet en lecture à la base de données, la requête destinée au client A peut lire les enregistrements du client B tout aussi facilement. La fonction analytique exigeait un accès délimité. L’autorisation a fourni un accès non délimité. Le périmètre n’a jamais compté jusqu’à ce que l’analyste choisisse d’en sortir.
Les risques liés aux accès analytiques se concentrent autour de cinq schémas de défaillance précis dans les environnements des fournisseurs :
- Large accès en lecture aux bases de données pour les fonctions analytiques : les équipes d’analyse reçoivent un accès en lecture à l’ensemble des bases de données de production plutôt qu’un accès limité aux ensembles de données précis qu’exigent leurs tâches analytiques
- Accès analytiques aux données de plusieurs clients dans les environnements multilocataires : des équipes d’analyse ont accès aux données de l’ensemble de la clientèle alors que les tâches analytiques n’exigent l’accès qu’aux données de clients précis
- Accès analytiques exclus des revues d’accès : l’accès analytique en lecture seule n’est pas inclus dans les revues d’accès périodiques, car il est perçu comme intrinsèquement moins risqué que l’accès en écriture
- Aucune journalisation au niveau des requêtes pour les accès analytiques : les requêtes analytiques ne sont pas journalisées au niveau des enregistrements, ce qui rend impossible la détection d’un accès non autorisé aux données dans le périmètre de lecture autorisé
- Accès analytiques maintenus au-delà du rôle : des analystes qui changent de fonction ou quittent l’organisation conservent leur accès à la base de données analytique, car les processus de départ se concentrent sur l’accès aux systèmes et négligent les identifiants des plateformes d’analyse
Pourquoi c’est important
Le risque lié aux accès analytiques est important pour le TPRM, car le scénario de menace interne le plus susceptible de provoquer une violation de données clients d’ampleur chez un fournisseur SaaS multilocataire n’est pas une attaque externe sophistiquée : c’est un utilisateur analytique autorisé qui dispose d’un accès en lecture sans restriction à l’ensemble des données clients et qui choisit d’utiliser cet accès en dehors de son périmètre prévu. Les contrôles conçus pour protéger l’application principale (authentification, accès fondé sur les rôles, journalisation d’audit) s’appliquent aux utilisateurs autorisés qui accèdent aux données par l’interface de l’application. Ils n’empêchent pas un utilisateur analytique autorisé d’interroger n’importe quel enregistrement de la base de données à l’aide des identifiants de lecture qui lui ont été accordés pour un travail légitime.
La dimension multilocataire amplifie considérablement le risque. Un fournisseur SaaS de santé dont l’équipe d’analyse peut interroger n’importe quel dossier de patient de n’importe lequel de ses deux cents entreprises clientes a concentré le risque d’accès aux données des deux cents clients sur une équipe de douze personnes dont l’accès n’a jamais été revu. Chacun de ces deux cents clients a évalué la posture de sécurité des données du fournisseur et conclu que les données de ses patients étaient correctement protégées. Aucun d’entre eux n’a vérifié si l’équipe d’analyse du fournisseur pouvait interroger sans aucune restriction les dossiers de ses patients.
Pour les praticiens TPRM, cela crée une obligation d’évaluation précise qui va au-delà de la confirmation des contrôles d’accès. La question n’est pas seulement de savoir si le fournisseur dispose de contrôles d’accès fondés sur les rôles, mais si ces contrôles s’appliquent à la fonction analytique avec la même rigueur qu’aux autres rôles d’accès aux données, y compris le cadrage, la fréquence des revues et une journalisation au niveau des requêtes permettant de détecter des schémas d’accès non autorisés dans le cadre d’une autorisation d’accès légitime.
Là où la plupart des équipes se trompent
La défaillance la plus constante consiste à considérer l’accès en lecture seule comme équivalent à un accès à faible risque et, par conséquent, à ne pas appliquer aux accès analytiques le même niveau d’examen de gouvernance qu’aux accès avec privilèges d’écriture. L’accès en lecture seule à des ensembles de données sensibles complets est une autorisation d’accès aux données importante : la capacité de lire chaque dossier client, chaque transaction, chaque champ sensible est la même que celle qu’exige l’exfiltration de ces données, même si l’écriture et la suppression sont désactivées. La restriction en écriture réduit le rayon d’impact en cas d’utilisation abusive de l’accès, mais elle ne réduit pas l’exposition si les données sont lues et divulguées.
La deuxième défaillance consiste à ne pas interroger sur la journalisation au niveau des requêtes pour les accès analytiques. Les journaux d’accès au niveau de l’infrastructure confirment qu’un analyste s’est authentifié auprès de la base de données. Les journaux au niveau des requêtes confirment quels enregistrements il a effectivement extraits pendant sa session. La différence entre ces deux niveaux de journalisation est celle qui sépare le fait de savoir que quelqu’un était dans la pièce de celui de savoir ce qu’il y a lu. Pour des accès analytiques couvrant un ensemble de données clients multilocataire, la journalisation au niveau des requêtes est le seul mécanisme capable de détecter un accès non autorisé aux données d’autres clients dans le cadre d’une autorisation d’accès légitime.
- Considérer l’accès en lecture seule comme intrinsèquement moins risqué : l’accès en lecture à des données sensibles complètes suffit à permettre une exfiltration
- Accès analytiques exclus du moindre privilège : un large accès à la base de données accordé par commodité fonctionnelle plutôt que limité aux besoins de tâches précises
- Aucune journalisation au niveau des requêtes pour les sessions d’analyse : les journaux d’infrastructure confirment l’authentification, mais pas l’accès aux enregistrements au cours de la session
- Accès analytiques non revus selon la fréquence des revues d’accès : l’accès en lecture seule est traité comme une catégorie distincte et moins prioritaire
- Accès aux données d’autres clients non délimité : les accès analytiques multilocataires ne sont pas limités au sous-ensemble de clients concerné par le travail de chaque analyste
À quoi ressemblent les bonnes pratiques
Une gouvernance mature des accès analytiques applique le moindre privilège aux fonctions analytiques avec la même rigueur qu’aux accès avec privilèges d’écriture : limiter l’accès aux données nécessaires à des tâches analytiques précises, revoir périodiquement ce périmètre à mesure que les tâches évoluent et mettre en œuvre une journalisation au niveau des requêtes permettant de détecter des schémas d’accès incompatibles avec le périmètre de travail autorisé.
- Moindre privilège appliqué aux accès analytiques : accès limité aux ensembles de données, sous-ensembles de clients ou catégories de données précis qu’exige le rôle de l’analyste, et non un accès complet en lecture à la base de données
- Journalisation d’audit au niveau des requêtes : chaque requête analytique est journalisée avec l’identité de l’utilisateur, l’horodatage, les tables consultées et le nombre d’enregistrements, et examinée à la recherche de schémas anormaux
- Accès analytiques soumis à la même fréquence de revue que les accès en écriture : revues périodiques confirmant que le périmètre des accès analytiques reste proportionné au rôle actuel
- Restriction de l’accès aux données d’autres clients dans les environnements multilocataires : accès analytique limité à des sous-ensembles de clients précis pour lesquels l’analyste dispose d’une justification métier pour chaque client
- Sortie des accès aux plateformes d’analyse : identifiants des bases de données analytiques explicitement inclus dans les listes de contrôle de départ, au même titre que l’accès aux systèmes principaux
Outils
La gouvernance des accès analytiques exige à la fois des outils de contrôle d’accès fin pour l’infrastructure d’analyse et des outils de surveillance qui enregistrent l’activité au niveau des requêtes.
Contrôle d’accès des plateformes d’analyse : Databricks Unity Catalog, AWS Lake Formation, dbt
Les plateformes d’analyse modernes offrent un contrôle d’accès fin permettant de délimiter l’accès analytique au niveau des tables, des colonnes et des lignes, en limitant chaque analyste aux catégories de données précises qu’exige son travail. AWS Lake Formation offre une sécurité au niveau des colonnes et des lignes pour les environnements d’analyse fondés sur S3. Databricks Unity Catalog offre une gouvernance unifiée des accès sur les tables Delta Lake avec un contrôle d’accès fondé sur les attributs. Pour les praticiens TPRM, demander si la plateforme d’analyse du fournisseur utilise un contrôle d’accès fin plutôt qu’un accès complet en lecture à la base de données permet de mettre au jour l’architecture de gouvernance de son modèle d’accès analytique.
Surveillance de l’activité des bases de données : Imperva, IBM Guardium
Les plateformes DAM enregistrent l’activité au niveau des requêtes sur les bases de données, y compris les requêtes analytiques, et fournissent ainsi la piste d’audit au niveau des enregistrements que les journaux d’infrastructure n’offrent pas. Imperva propose en particulier une analyse du comportement des utilisateurs appliquée aux schémas de requêtes sur les bases de données, qui détecte les volumes d’accès anormaux et les schémas inhabituels de requêtes portant sur plusieurs clients. Pour les praticiens TPRM, demander si les requêtes analytiques sont journalisées au niveau des enregistrements et si une détection des anomalies est appliquée aux schémas d’accès analytiques permet de mesurer la profondeur de la surveillance des accès analytiques.
Gouvernance des identités : SailPoint, Saviynt
Les plateformes IGA intègrent les identifiants des plateformes d’analyse dans leurs flux de revue des accès, afin que les accès analytiques soient revus à la même fréquence que les autres rôles d’accès aux données au lieu d’échapper au périmètre des revues en tant que catégorie « en lecture seule ». Pour les praticiens TPRM, demander si l’accès aux plateformes d’analyse est inclus dans le programme de gouvernance des identités et de revue des accès du fournisseur constitue une question précise sur le périmètre de la gouvernance.
Enjeux de gouvernance
La difficulté de gouvernance des accès analytiques tient à la tension avec la productivité. Les équipes d’analyse ont besoin d’un accès aux données rapide et souple pour mener efficacement leur travail exploratoire ; des restrictions de requêtes et des circuits d’approbation pour chaque nouvelle analyse réduisent la rapidité qui fait la valeur de la fonction analytique. La réponse en matière de gouvernance n’est pas de supprimer la souplesse des accès analytiques, mais de délimiter cette souplesse de manière appropriée, en donnant accès aux catégories de données et aux sous-ensembles de clients qu’exige le rôle de l’analyste tout en restreignant l’accès aux données hors de ce périmètre. Les restrictions ne suppriment pas la capacité analytique. Elles suppriment l’accès à des données que l’analyste n’a aucune raison professionnelle d’interroger.
Pour les programmes TPRM, l’approche de gouvernance pratique consiste à inclure les accès analytiques dans l’évaluation des contrôles d’accès des fournisseurs en tant que catégorie d’accès distincte, sans supposer qu’ils sont couverts par la confirmation générale des contrôles d’accès, et à interroger spécifiquement sur le cadrage, la fréquence des revues et la journalisation au niveau des requêtes. La large autorisation d’accès analytique jamais réexaminée est le risque d’accès qui se cache au sein d’un programme de contrôle d’accès par ailleurs bien gouverné.
- Inclure les accès analytiques dans l’évaluation des contrôles d’accès des fournisseurs, sans supposer qu’ils sont couverts par la confirmation générale de l’accès fondé sur les rôles
- Interroger sur le périmètre des accès analytiques : accès complet en lecture à la base de données ou accès limité à des tables, des colonnes ou des sous-ensembles de clients précis
- Exiger une journalisation au niveau des requêtes pour les accès analytiques : une piste d’audit au niveau des enregistrements, et pas seulement des journaux d’authentification
- Interroger sur la fréquence de revue des accès analytiques : inclus dans les revues d’accès périodiques ou traités comme une catégorie distincte moins prioritaire
- Confirmer la sortie des accès analytiques : identifiants des plateformes d’analyse inclus dans le processus de départ
Si vous êtes une petite équipe
Ajoutez à votre évaluation des contrôles d’accès des fournisseurs une question portant spécifiquement sur la fonction analytique : combien de membres de votre équipe d’analyse ont accès aux données clients de production, quel est le périmètre de cet accès et quand a-t-il été revu pour la dernière fois ? Pour les fournisseurs multilocataires, demandez ensuite si les analystes peuvent interroger les données de clients autres que ceux sur lesquels porte leur travail. Ces deux questions mettent au jour l’étendue des accès analytiques que les évaluations standard des contrôles d’accès n’atteignent jamais.
- Demander combien d’analystes ont accès à la base de données de production et quel en est le périmètre
- Demander si les accès analytiques sont revus à la même fréquence que les accès avec privilèges d’écriture
- Demander s’il existe une journalisation au niveau des requêtes pour les sessions d’analyse
- Pour les fournisseurs multilocataires, demander si les accès analytiques sont limités à des sous-ensembles de clients précis
Ce qu’il faut exiger
Demandez directement :
« Combien de membres de votre équipe d’analyse disposent d’un accès en lecture aux bases de données de production contenant des données clients, et cet accès porte-t-il sur l’ensemble de la base de données ou est-il limité à des tables, des catégories de données ou des sous-ensembles de clients précis ? »
« Les requêtes analytiques sont-elles journalisées au niveau des enregistrements ? Plus précisément, pouvez-vous identifier quel analyste a interrogé quels dossiers clients au cours d’une session donnée, et ce journal est-il examiné à la recherche de schémas anormaux ? »
« Les accès à la base de données analytique sont-ils inclus dans vos revues d’accès périodiques, et quand l’accès de l’équipe d’analyse a-t-il été revu pour la dernière fois afin d’en vérifier la proportionnalité ? »
Preuves attendues
- Documentation du périmètre des accès analytiques : nombre d’analystes, étendue de l’accès, restriction du périmètre par client
- Confirmation de la journalisation au niveau des requêtes pour les sessions d’analyse
- Historique des revues des accès analytiques : inclus dans les revues périodiques, avec la date de la dernière revue
- Confirmation de la restriction de l’accès aux données d’autres clients dans les environnements multilocataires
Un fournisseur qui répond à la question sur le périmètre des accès analytiques par « notre équipe d’analyse n’a qu’un accès en lecture » a confirmé le type d’accès. Demandez précisément si cet accès en lecture couvre l’ensemble de la base de données de production ou s’il est limité à des catégories de données précises. Lecture seule et accès délimité sont des choix de gouvernance différents. Les deux sont en lecture seule. Un seul applique le moindre privilège.
Comment le prouver
La gouvernance des accès analytiques est abordée implicitement dans les principes de minimisation des données et de limitation des finalités du GDPR, dans les exigences de la norme PCI-DSS relatives au moindre privilège et dans les normes d’accès minimum nécessaire de la loi HIPAA. Démontrer la diligence requise exige de prouver que les accès analytiques ont été évalués comme une catégorie d’accès distincte, avec leur propre gouvernance de périmètre et de revue.
- Dossiers d’évaluation des fournisseurs consignant les questions sur le périmètre, la journalisation et la fréquence de revue des accès analytiques
- Confirmation de la journalisation au niveau des requêtes pour les sessions d’analyse
- Preuves de la restriction de l’accès aux données d’autres clients pour les fournisseurs multilocataires
- Inclusion des revues d’accès analytiques dans le programme IGA ou de revue des accès
À retenir
Un accès en lecture à tout reste un accès à tout. L’analyste qui a lu des dossiers de patients hors de son périmètre de travail n’avait pas besoin d’un accès en écriture pour le faire. Il lui fallait l’accès en lecture dont disposaient douze personnes et que personne n’avait revu depuis quatre ans. L’accès analytique est cette autorisation large, banalisée et jamais remise en question, qui existe parce qu’il était plus facile de dire « donnez à l’équipe d’analyse un accès en lecture à la base de données » que de définir ce dont chaque analyste a réellement besoin. Le moindre privilège s’applique à l’accès en lecture autant qu’à l’accès en écriture lorsque les données lues sont sensibles. La journalisation au niveau des requêtes s’applique aux sessions d’analyse autant qu’aux sessions d’administration lorsque les enregistrements lus appartiennent à des clients qui comptent sur le fournisseur pour contrôler qui les consulte.