Défaillances de la séparation des données

En 2019, une grande plateforme cloud a révélé qu’un bogue dans son infrastructure de base de données partagée avait entraîné le renvoi de données de clients dans des réponses API appartenant à d’autres locataires. Le bogue se situait dans la couche de requêtes : un mécanisme de cache avait associé des résultats de requêtes au mauvais contexte de locataire, renvoyant les enregistrements d’un client à l’appel API d’un autre client. La base de données sous-jacente contenait les données de tous les locataires dans les mêmes tables, séparées par des identifiants de locataire. La base de données elle-même ne disposait d’aucun mécanisme pour imposer l’isolation des locataires : celle-ci reposait entièrement sur les couches applicative et de requêtes. Lorsque ces couches ont présenté un bogue, la base de données n’avait rien en dessous pour empêcher l’exposition des données entre locataires. Le bogue a été découvert par un client qui a remarqué qu’il recevait des enregistrements qu’il ne reconnaissait pas. Il était en production depuis une durée que le fournisseur a refusé de préciser dans sa communication publique. La séparation reposait entièrement sur le code. Le code avait un bogue. La base de données ne pouvait pas faire la différence.

Qu’est-ce que le problème des défaillances de séparation des données, réellement ?

La séparation des données dans les environnements multilocataires est l’approche architecturale et technique utilisée pour garantir que les données d’un client ne peuvent pas être consultées depuis la session authentifiée d’un autre client. Dans les déploiements monolocataires, où chaque client dispose de sa propre base de données, de sa propre instance applicative et de sa propre infrastructure, la séparation physique du déploiement offre de solides garanties de séparation. Dans les déploiements multilocataires, où plusieurs clients partagent les mêmes tables de base de données, le même code applicatif et la même infrastructure, la séparation dépend de contrôles logiques qui doivent être correctement mis en œuvre et appliqués de manière cohérente au niveau des couches applicative et de requêtes.

La vulnérabilité de l’isolation des locataires au niveau applicatif est l’enjeu central de la sécurité multilocataire. Une clause WHERE qui filtre les enregistrements par identifiant de locataire est une mise en œuvre correcte de l’isolation des locataires lorsqu’elle s’exécute correctement. Lorsqu’un bogue de cache associe le mauvais contexte de locataire à une réponse, lorsqu’un chemin de code omet le filtre par locataire, lorsqu’une opération de masse s’applique à tous les locataires alors qu’elle devrait n’en concerner qu’un, ou lorsqu’une erreur de configuration permet un accès API entre locataires, dans chacun de ces scénarios, la base de données ne fait rien pour empêcher l’exposition entre locataires, car elle contient les données de tous les locataires et ne dispose d’aucun contrôle d’accès au niveau du locataire. L’isolation repose entièrement sur la couche applicative, et la couche applicative a des bogues.

Les alternatives architecturales à l’isolation au niveau applicatif offrent des garanties de séparation plus solides, pour des coûts opérationnels variables. Les déploiements à schéma par locataire donnent à chaque client son propre schéma de base de données dans le même moteur de base de données, ce qui fournit une isolation au niveau du schéma imposée par la base de données elle-même plutôt que par le code applicatif. Les déploiements à base de données par locataire donnent à chaque client sa propre instance de base de données, ce qui offre la garantie d’isolation la plus forte, équivalente à un déploiement monolocataire. Ces approches sont plus coûteuses à exploiter que la multilocation à tables partagées et ne sont pas proposées par toutes les plateformes SaaS, mais elles représentent une posture de risque sensiblement différente en matière de sécurité de la séparation des données.

Les défaillances de séparation des données se concentrent autour de cinq schémas de vulnérabilité précis dans les environnements multilocataires :

• Bogues des filtres par locataire au niveau applicatif : défauts de code qui entraînent l’omission, la mauvaise application ou le contournement des filtres par identifiant de locataire dans certains chemins de code, ce qui permet un accès aux données entre locataires
• Erreurs de contexte de locataire dans la couche de cache : mécanismes de cache qui associent des résultats de requêtes ou des réponses API à un contexte de locataire erroné, servant les données d’un client à la session d’un autre client
• Exposition entre locataires lors d’opérations de masse : opérations d’administration ou de maintenance qui s’appliquent à tous les locataires alors qu’elles devraient être limitées à un locataire précis
• Manipulation des paramètres API : paramètres d’identifiant de locataire dans les appels API qu’un client peut modifier pour accéder aux ressources d’un autre locataire si le contexte de locataire n’est pas vérifié de manière indépendante côté serveur
• Exposition par canaux auxiliaires dans l’infrastructure partagée : attaques temporelles, exposition de mémoire partagée ou schémas de contention des ressources dans une infrastructure partagée qui laissent fuir des informations entre les charges de travail des locataires

Pourquoi c’est important

Les défaillances de séparation des données comptent pour le TPRM, car elles représentent une catégorie de risque propre aux plateformes multilocataires, susceptible d’exposer les données d’un client à d’autres clients sans l’intervention d’aucun attaquant, du fait de bogues, d’erreurs de configuration et de défauts de conception inhérents à l’architecture multilocataire. Le bogue de la plateforme cloud décrit en introduction n’a nécessité aucun attaquant. Un client correctement authentifié a reçu des données erronées dans la réponse API. La séparation a échoué à cause d’un défaut logiciel, pas d’une attaque.

Le risque multilocataire est qualitativement différent du risque d’un déploiement monolocataire. Dans un déploiement monolocataire, une défaillance de sécurité expose les données de ce client. Dans un déploiement multilocataire, une défaillance de séparation expose les données de n’importe quel client à la session de n’importe quel autre client : le périmètre d’exposition potentiel est l’ensemble des locataires de la plateforme, et pas seulement le client touché par la défaillance. Un bogue qui provoque une fuite de données entre locataires constitue à la fois une violation pour chaque client dont les données ont été exposées et une violation pour chaque client qui a reçu des données qui n’étaient pas les siennes.

Pour les praticiens du TPRM, l’évaluation de la séparation des données exige de comprendre le mécanisme architectural d’isolation des locataires, et pas seulement de confirmer que la séparation existe en tant que propriété déclarée. La multilocation à tables partagées avec isolation au niveau applicatif, le schéma par locataire et la base de données par locataire représentent des postures de risque sensiblement différentes, et la question d’évaluation « vos données sont-elles séparées ? » ne permet pas de les distinguer.

Là où la plupart des équipes se trompent

L’échec le plus constant consiste à considérer la séparation des données comme une propriété binaire, séparées ou non, sans interroger le mécanisme architectural qui la met en œuvre. Le fournisseur d’une plateforme multilocataire à tables partagées qui confirme la séparation des données dit vrai : les données des clients sont séparées logiquement par identifiant de locataire. La question de savoir si cette séparation logique peut échouer à cause d’un défaut logiciel est une question d’architecture que la confirmation binaire ne traite pas.

Le deuxième échec consiste à ne pas interroger les tests d’intrusion entre locataires. Des tests qui confirment que l’application impose correctement l’isolation des locataires dans des conditions normales ne confirment pas que cette isolation résiste dans des conditions adverses, c’est-à-dire qu’un client qui tente d’accéder aux données d’un autre locataire par la manipulation des paramètres API, la modification des requêtes ou des techniques de contournement connues ne peut pas y parvenir. Les tests d’intrusion entre locataires constituent un objectif de test spécifique, qui doit figurer explicitement dans le périmètre pour être réalisé.

• Accepter la confirmation de la séparation sans connaître le mécanisme architectural : tables partagées, schéma par locataire et base de données par locataire représentent des postures de risque différentes
• Aucun test d’intrusion entre locataires : tests de sécurité qui ne tentent pas explicitement de contourner l’isolation des locataires
• Risque lié à l’isolation au niveau applicatif non évalué : s’en remettre à l’exactitude du code pour la séparation des locataires sans contrôles architecturaux indépendants
• Aucune question sur l’isolation des locataires dans la couche de cache : les mécanismes de cache comme vecteur spécifique de vulnérabilité de la séparation
• Exposition entre locataires lors d’opérations de masse non traitée : opérations d’administration susceptibles d’affecter plusieurs locataires

À quoi ressemblent les bonnes pratiques

Les programmes matures de séparation multilocataire mettent en œuvre une défense en profondeur, en appliquant l’isolation des locataires à plusieurs niveaux architecturaux, de sorte qu’une défaillance à un niveau soit interceptée par les contrôles d’un autre. Les filtres par locataire au niveau applicatif, les politiques de sécurité au niveau des lignes de la base de données, l’isolation au niveau du schéma et les tests d’intrusion entre locataires se combinent pour offrir une assurance de séparation qu’aucun niveau architectural ne peut fournir à lui seul.

• Politiques de sécurité au niveau des lignes de la base de données : sécurité au niveau des lignes imposée par la base de données, qui ajoute un niveau de séparation indépendant du code applicatif
• Schéma ou base de données par locataire pour les données les plus sensibles : isolation architecturale que le moteur de base de données impose indépendamment du code applicatif
• Tests d’intrusion entre locataires : objectifs de test explicites visant à contourner l’isolation des locataires par manipulation de l’API, exploitation du cache et contournement des filtres au niveau applicatif
• Revue du code d’isolation des locataires : revue de code de sécurité ciblée sur la mise en œuvre et l’exhaustivité du filtrage par locataire sur tous les chemins d’accès aux données
• Validation du contexte de locataire dans la couche de cache : tests explicites des mécanismes de cache pour détecter toute association de contexte entre locataires

Outils

Mettre en œuvre et tester la séparation des données multilocataire exige à la fois des contrôles architecturaux et des outils de test conçus spécifiquement pour vérifier l’isolation des locataires.

Sécurité au niveau des lignes de la base de données : PostgreSQL RLS, Oracle VPD, SQL Server RLS

Les fonctionnalités de sécurité au niveau des lignes des bases de données relationnelles assurent une isolation des locataires imposée par la base de données, en appliquant au niveau du moteur des politiques d’accès qui limitent chaque session aux lignes correspondant à son contexte de locataire. La fonctionnalité Row Level Security de PostgreSQL permet de définir des politiques qui filtrent les résultats des requêtes par identifiant de locataire au niveau de la base de données, ce qui fournit un point d’application de la séparation indépendant de la couche applicative. Pour les praticiens du TPRM, demander si le fournisseur utilise des politiques de sécurité au niveau des lignes de la base de données en plus du filtrage par locataire au niveau applicatif pose la question de la défense en profondeur de la séparation, que la confirmation d’un seul niveau ne traite pas.

Tests de sécurité multilocataires : Burp Suite, OWASP Testing Guide for Multi-Tenant

Les tests d’intrusion entre locataires exigent une méthodologie de test spécifique : énumérer les identifiants de locataire, tenter de manipuler les paramètres API, tester l’accès aux ressources entre locataires et vérifier que le contexte de locataire est imposé côté serveur pour tous les points de terminaison API. Pour les praticiens du TPRM, exiger que le contournement de l’isolation entre locataires soit un objectif explicite des tests d’intrusion permet de savoir si le test de sécurité multilocataire le plus spécifique a été réalisé.

Isolation des charges de travail cloud : AWS Organizations, Azure Management Groups, GCP Resource Hierarchy

Pour les fournisseurs qui utilisent une infrastructure cloud, l’isolation des charges de travail entre locataires peut être mise en œuvre au niveau du compte ou du projet cloud, ce qui fournit une séparation au niveau de l’infrastructure qui complète l’isolation des bases de données et des applications. Pour les praticiens du TPRM, demander si les locataires ayant les exigences de sensibilité les plus élevées peuvent être hébergés sur une infrastructure isolée plutôt que partagée permet de savoir s’il existe des options d’isolation architecturale pour les déploiements les plus à risque.

Enjeux de gouvernance

Le défi de gouvernance que pose la séparation des données multilocataire tient au fait que le risque est architectural (il découle de la décision de conception d’utiliser une infrastructure partagée) et que les risques architecturaux exigent des mesures d’atténuation architecturales que les seuls contrôles ne peuvent pas entièrement remplacer. Le filtrage par locataire au niveau applicatif peut être rendu plus robuste grâce à des contrôles de défense en profondeur, à la revue de code et aux tests. Il ne peut pas être rendu équivalent à l’isolation par base de données par locataire, car la différence architecturale fondamentale (le code applicatif peut avoir des bogues, alors que l’isolation au niveau de la base de données est imposée par le moteur de base de données) ne peut être supprimée par aucune quantité de revue de code.

Pour les programmes de TPRM, l’approche pratique en matière de gouvernance consiste à comprendre l’architecture multilocataire de chaque plateforme de fournisseur critique et à évaluer le mécanisme de séparation en conséquence. Les fournisseurs à tables partagées appellent des questions plus précises sur les tests entre locataires, l’isolation du cache et les contrôles de défense en profondeur. Les fournisseurs à schéma par locataire appellent des questions sur le contrôle des accès entre schémas. Les fournisseurs à base de données par locataire offrent la garantie de séparation la plus forte, mais doivent tout de même être interrogés sur les contrôles d’accès entre bases de données et sur l’isolation de l’infrastructure.

• Interrogez précisément l’architecture multilocataire : tables partagées, schéma par locataire ou base de données par locataire
• Exigez que les tests d’intrusion entre locataires figurent explicitement dans le périmètre des exigences d’évaluation de la sécurité des fournisseurs
• Interrogez la sécurité au niveau des lignes de la base de données : l’isolation des locataires existe-t-elle au niveau de la base de données en plus du niveau applicatif ?
• Interrogez l’isolation des locataires dans la couche de cache : tests spécifiques des mécanismes de cache pour détecter toute exposition de contexte entre locataires
• Envisagez une infrastructure dédiée par locataire pour les déploiements les plus sensibles : demandez si des options de base de données par locataire ou de compte par locataire sont disponibles

Si vous êtes une petite équipe

Ajoutez deux questions à vos évaluations des fournisseurs SaaS multilocataires. Premièrement : quel est le mécanisme architectural de votre isolation des données des locataires, c’est-à-dire les données des clients sont-elles séparées par des colonnes d’identifiant de locataire dans des tables partagées, par des schémas distincts pour chaque client ou par des instances de base de données distinctes pour chaque client ? Deuxièmement : vos tests d’intrusion tentent-ils explicitement d’accéder aux données d’un locataire depuis la session d’un autre locataire en utilisant ses identifiants, c’est-à-dire le contournement de l’isolation entre locataires a-t-il été défini comme objectif de test ? Ces deux questions font immédiatement apparaître la posture de risque architecturale et indiquent si elle a été spécifiquement testée.

• Interrogez le mécanisme précis d’architecture multilocataire : tables partagées, schéma ou base de données par locataire
• Demandez si le contournement de l’isolation entre locataires est un objectif explicite des tests d’intrusion
• Demandez s’il existe des politiques de sécurité au niveau des lignes de la base de données en plus du filtrage par locataire au niveau applicatif
• Pour les déploiements les plus sensibles, demandez si des options d’infrastructure dédiée sont disponibles

Ce qu’il faut exiger

Demandez directement :

« Quel est le mécanisme architectural de votre isolation des données des locataires : les tables de données des clients sont-elles partagées avec un filtrage par identifiant de locataire au niveau applicatif, ou chaque client dispose-t-il d’un schéma distinct ou d’une instance de base de données distincte ? »

« Vos tests d’intrusion tentent-ils explicitement d’accéder aux données d’un locataire depuis la session d’un autre locataire, en testant notamment la manipulation des paramètres API, la modification des requêtes et le contexte de locataire dans la couche de cache, et le contournement de l’isolation entre locataires est-il un objectif de test défini ? »

« Mettez-vous en œuvre des politiques de sécurité au niveau des lignes de la base de données qui imposent l’isolation des locataires au niveau du moteur de base de données, indépendamment de votre filtrage par locataire dans la couche applicative ? »

Preuves attendues

• Description de l’architecture multilocataire : mécanisme d’isolation précis
• Confirmation du périmètre des tests d’intrusion entre locataires : contournement de l’isolation comme objectif explicite
• Confirmation de la sécurité au niveau des lignes de la base de données ou d’une autre isolation architecturale
• Preuves des tests d’isolation des locataires dans la couche de cache

Un fournisseur qui répond à la question de l’architecture par « notre plateforme est multilocataire avec séparation des données » a confirmé l’intention. Demandez précisément si cette séparation est imposée au niveau de la base de données par des politiques de sécurité au niveau des lignes, ou seulement au niveau de la couche applicative par un filtrage sur l’identifiant de locataire. La base de données ne peut pas mentir sur ce qu’elle impose. La couche applicative peut comporter des bogues que la couche base de données détecterait.

Comment le prouver

La séparation des données multilocataire est traitée par les Trust Services Criteria SOC 2 relatifs à la confidentialité et à la disponibilité, par les contrôles ISO 27001 relatifs à la séparation des informations et par les référentiels de sécurité du cloud, notamment les contrôles CIS. Démontrer la diligence raisonnable exige de prouver que le mécanisme de séparation a fait l’objet d’une évaluation architecturale et de tests spécifiques, et pas seulement qu’il a été confirmé en tant que propriété déclarée.

• Registres d’évaluation des fournisseurs documentant le mécanisme d’architecture multilocataire et les contrôles de défense en profondeur
• Confirmation du périmètre des tests d’intrusion entre locataires
• Preuves de la sécurité au niveau des lignes de la base de données ou d’une isolation architecturale
• Preuves des tests d’isolation de la couche de cache

À retenir

Dans une plateforme multilocataire à tables partagées, l’isolation des locataires est une clause WHERE. Lorsqu’elle est appliquée correctement, les données sont séparées. Lorsqu’un bogue la fait omettre, l’applique au mauvais contexte ou qu’une erreur de cache la contourne, la base de données n’a rien en dessous pour empêcher l’exposition entre locataires, car elle ne sait pas à quel locataire appartiennent les données qu’elle renvoie. Elle sait ce que l’application a demandé. L’application a demandé la mauvaise chose. La confirmation de la séparation des données vous indique que le fournisseur a l’intention de garder séparées les données des locataires. Le mécanisme architectural vous indique comment. Le périmètre des tests d’intrusion vous indique si ce mécanisme a été spécifiquement validé dans des conditions adverses. Les trois questions comptent. La confirmation n’est que la première.