Un fournisseur de logiciels RH dans le cloud exploitait une plateforme SaaS multilocataire servant plus de trois cents entreprises clientes. Lorsque l'un de ses plus gros clients a subi une violation, déclenchée par un identifiant administrateur compromis, l'équipe de réponse aux incidents du fournisseur a mené l'investigation et a confiné la violation en quarante-huit heures. Son investigation a conclu que la violation avait été confinée au locataire touché et ne s'était pas étendue aux données d'autres clients. Cette conclusion reposait sur l'analyse des journaux d'accès aux données du locataire touché et sur les contrôles de segmentation réseau entre les environnements des locataires. Trois semaines plus tard, un second client a contacté le fournisseur après avoir découvert que ses données RH avaient été consultées depuis une adresse IP inconnue. L'investigation conjointe qui a suivi a révélé que l'attaquant initial, après avoir obtenu l'accès au locataire du premier client, avait identifié une vulnérabilité dans la couche d'isolation des locataires du fournisseur, à savoir une erreur de configuration des contrôles d'accès à la base de données partagée qui permettait à l'attaquant d'accéder à certaines tables au-delà des limites entre locataires. L'investigation initiale du fournisseur avait confirmé que l'attaquant ne s'était pas déplacé latéralement dans le réseau, ce qui était exact, mais n'avait pas détecté qu'il avait accédé à des données d'autres locataires par la couche base de données mal configurée. L'approche d'investigation a vérifié les contrôles réseau. L'attaque a exploité la couche des données.
Que recouvre réellement le problème de la détection des attaques entre locataires ?
La détection des attaques entre locataires consiste à identifier le moment où une compromission de sécurité touchant l'environnement d'un client sur une plateforme multilocataire a accédé, ou pourrait accéder, aux environnements d'autres clients par l'intermédiaire de composants d'infrastructure partagés. Les plateformes multilocataires partagent l'infrastructure pour fournir des services économiques : bases de données, ressources de calcul, réseaux et intergiciels partagés. Ces composants partagés créent des voies potentielles d'accès entre locataires lorsque les contrôles d'isolation censés empêcher un locataire d'accéder aux données d'un autre présentent des vulnérabilités ou des erreurs de configuration.
La lacune de la méthodologie d'investigation est la défaillance de détection précise. Les investigations post-violation dans les environnements multilocataires se concentrent généralement sur le locataire compromis : elles analysent l'accès de l'attaquant dans l'environnement de ce locataire, confirment que l'isolation des locataires au niveau du réseau a tenu et déterminent l'étendue des données consultées dans le locataire compromis. Cette méthodologie d'investigation identifie avec exactitude les déplacements latéraux au niveau du réseau. Elle peut passer à côté des accès entre locataires au niveau des données, c'est-à-dire des attaques qui exploitent des autorisations mal configurées de bases de données partagées, des défauts de contrôle d'accès des API ou d'autres vulnérabilités de la couche des données pour accéder aux données d'autres locataires sans effectuer le déplacement latéral au niveau du réseau que l'investigation recherche.
L'hypothèse d'isolation des locataires est la cause profonde. Les plateformes multilocataires mettent en œuvre l'isolation des locataires à plusieurs couches (réseau, application et données), et la méthodologie d'investigation de l'équipe de sécurité tend à vérifier la couche dans laquelle elle a le plus confiance. Un fournisseur doté d'une solide isolation réseau peut vérifier cette couche de manière approfondie tout en étant moins systématique dans ses vérifications de la couche des données. Un attaquant qui a étudié l'architecture du fournisseur sait quelle couche d'isolation cibler pour accéder à d'autres locataires.
- Investigation vérifiant la couche réseau alors que l'attaque utilisait la couche des données
- Hypothèse d'isolation des locataires non testée de manière exhaustive après la violation
- Isolation multicouche non vérifiée : réseau confirmé, mais couche des données non vérifiée
- Notification tardive du second locataire : trois semaines d'exposition sans notification pour le client B
- Accès entre locataires via l'infrastructure partagée absent de la liste de contrôle des investigations de violation
Pourquoi c’est important
La détection des attaques entre locataires est importante pour la TPRM, car les clients des plateformes multilocataires font face à un risque de violation qui prend naissance dans l'environnement d'un autre client, un risque qui échappe entièrement à leur contrôle et qui dépend de la capacité du fournisseur à détecter les accès entre locataires et à informer les clients concernés. Le client qui se fie à la conclusion de l'investigation du fournisseur selon laquelle « la violation ne s'est pas propagée » doit comprendre quelle méthodologie d'investigation a produit cette conclusion et si cette méthodologie détecterait les techniques précises d'accès entre locataires pertinentes pour l'architecture du fournisseur.
La conséquence du retard de notification est la dimension réglementaire. Un retard de trois semaines dans la notification d'un second client dont les données ont été consultées signifie un retard de trois semaines dans la réponse de ce second client à la violation et dans son calendrier de notification réglementaire. Le délai de notification prévu par le GDPR pour le second client commence à courir lorsqu'il en prend connaissance, mais son exposition a effectivement commencé lorsque l'attaquant a accédé à son locataire, et non lorsqu'il a reçu la notification tardive du fournisseur.
Là où la plupart des équipes se trompent
La défaillance la plus constante consiste à accepter l'assurance du fournisseur quant au confinement d'une violation sans comprendre la méthodologie d'investigation qui a produit cette assurance. Un confinement entre locataires confirmé par une analyse de la couche réseau ne confirme pas le confinement au niveau de la couche des données.
- Assurance de confinement de la violation acceptée sans examen de la méthodologie d'investigation
- Tests d'isolation multicouches non vérifiés : couche réseau, couche des données et couche applicative
- Aucun audit côté client des accès entre locataires à son propre locataire lors d'une violation touchant un autre client
- Revue des contrôles d'accès à la base de données partagée non déclenchée par un incident touchant un autre client
- Périmètre de l'investigation du fournisseur non examiné à la recherche de lacunes méthodologiques
À quoi ressemblent les bonnes pratiques
Les protocoles matures de réponse aux incidents entre locataires examinent toutes les couches de l'infrastructure partagée (réseau, application et données) lorsqu'une violation est détectée dans un locataire quel qu'il soit, et vérifient explicitement à chaque couche qu'aucun accès entre locataires n'a eu lieu.
- Investigation multicouche entre locataires : les couches réseau, application et données sont toutes vérifiées
- Examen des journaux d'accès à la base de données partagée pour tous les locataires lorsque l'un d'eux subit une violation
- Test d'isolation entre locataires comme étape standard des investigations de violation
- Notification proactive des colocataires lorsque l'infrastructure partagée est concernée par l'investigation
- Documentation de l'architecture d'isolation des locataires examinée lors de l'investigation de la violation
Outils
Sécurité du cloud : plateformes CSPM, SIEM natifs du cloud avec visibilité entre locataires
Les plateformes de gestion de la posture de sécurité du cloud qui surveillent l'infrastructure multilocataire peuvent offrir une visibilité sur les accès entre locataires, en identifiant les cas où des composants partagés sont consultés au-delà des limites entre locataires. Pour les professionnels de la TPRM, demander si la surveillance CSPM du fournisseur couvre les tentatives d'accès aux données entre locataires constitue une question précise sur la surveillance de l'isolation.
Enjeux de gouvernance
Le défi de gouvernance de la détection entre locataires tient à la nécessité d'élargir le périmètre de l'investigation. Lorsqu'une violation est détectée dans un locataire, rechercher un accès entre locataires dans toute l'infrastructure partagée exige un accès à tous les environnements des locataires, auquel l'équipe d'investigation n'a pas forcément accès habituellement et qui peut soulever des questions de confidentialité pour les autres clients. La solution de gouvernance consiste à intégrer la vérification de l'isolation entre locataires à la liste de contrôle standard des investigations de violation avant que des incidents ne l'exigent.
- Demander la méthodologie d'investigation entre locataires : ce qui est vérifié lorsqu'un locataire, quel qu'il soit, subit une violation
- Demander si les journaux d'accès à la base de données partagée sont examinés pour tous les locataires lors d'une investigation
- Demander la documentation de l'architecture d'isolation des locataires : ce qui est partagé, ce qui est isolé
- S'informer de la notification proactive des colocataires lorsque l'infrastructure partagée est en cause
- Demander des preuves de tests d'intrusion entre locataires portant sur les composants de l'infrastructure partagée
Si vous êtes une petite équipe
Pour votre fournisseur multilocataire le plus important, posez deux questions. Premièrement : lorsque le locataire d'un autre client de votre plateforme subit une violation, quelle est votre procédure d'investigation pour déterminer si la compromission a permis d'accéder aux données d'un autre locataire, et plus précisément, cette procédure vérifie-t-elle la couche d'accès à la base de données et la couche d'accès applicative, et pas seulement les déplacements au niveau du réseau ? Deuxièmement : si cette investigation identifiait un risque d'accès entre locataires, à quel moment nous informeriez-vous, même si l'investigation n'avait pas confirmé d'accès à notre locataire ? Ces deux questions révèlent la profondeur de l'investigation et le déclencheur de notification en cas de violation touchant un colocataire.
- S'informer de la méthodologie d'investigation entre locataires : quelles couches sont vérifiées
- Demander à quel moment les colocataires sont informés lors d'une investigation portant sur une violation touchant un colocataire
- Demander une présentation de l'architecture d'isolation des locataires
- S'informer de la visibilité sur les journaux d'accès à la base de données partagée pendant les investigations
Ce qu’il faut exiger
Demandez directement :
« Lorsque le locataire d'un autre client de votre plateforme subit une violation, votre procédure d'investigation vérifie-t-elle spécifiquement si l'attaquant a accédé à des composants de l'infrastructure partagée, y compris les couches d'accès aux bases de données, qui pourraient permettre un accès aux données entre locataires, et à quel moment serions-nous informés ? »
Preuves attendues
- Liste de contrôle de l'investigation entre locataires : quelles couches sont vérifiées
- Déclencheur et délai de notification des colocataires
- Documentation de l'architecture d'isolation des locataires
- Procédure de revue des contrôles d'accès à la base de données partagée
Il faut demander à un fournisseur qui confirme l'isolation des locataires quelle méthodologie d'investigation confirme l'isolation après une violation, en particulier si la couche des données est vérifiée en plus de la couche réseau. L'architecture d'isolation décrit la conception. La méthodologie d'investigation décrit la manière dont l'isolation est vérifiée lorsque la conception est mise à l'épreuve par un attaquant.
Comment le prouver
- Registres de la méthodologie d'investigation entre locataires
- Documentation de l'architecture d'isolation des locataires
- Procédure de notification des colocataires
- Preuves des tests d'isolation multicouches
À retenir
L'investigation a confirmé que la violation ne s'était pas propagée par le réseau. L'attaquant a utilisé la couche base de données. Les deux affirmations étaient exactes en même temps. La méthodologie d'investigation a vérifié une couche et confirmé le confinement sur cette couche. L'attaquant a exploité une autre couche. Trois semaines plus tard, le client B a été informé. La violation était active dans son locataire depuis trois semaines après la première confirmation de confinement par le fournisseur. L'isolation entre locataires exige une investigation multicouche : réseau, application et données. Une méthodologie d'investigation qui ne vérifie que la couche dans laquelle l'équipe a le plus confiance laisse les autres couches à l'état d'hypothèses non vérifiées. Demandez la méthodologie d'investigation. Confirmez que toutes les couches sont incluses dans le périmètre.