Depuis une dizaine d’années, je forme des architectes Cloud chez CentraleSupélec Executive Education. La plateforme de la Fresque du Climat a été pour moi l’occasion de mettre en pratique certains patterns d’architecture multi-tenant que j’enseigne. Voici mon retour d’expérience…
Multi-tenant, kesako ?
Pour rappel, les architectures multi-tenant (multi locataires, en français) permettent de créer des offres SaaS (Software as a service) avec une étanchéité entre les organisations utilisatrices, tout en utilisant un logiciel et une infrastructure communs.
Chaque organisation cliente gère et paramètre son environnement avec ses employées, en toute isolation vis-à-vis des autres organisations.
Les exemples classiques d’offres multi-tenant sont Office 365, Google Workspace, Salesforce CRM, Atlassian Jira, etc.
Dans le cas de la Fresque du Climat, nos fonctions métiers principales sont :
- L’organisation d’atelier de sensibilisation au changement climatique, avec une billetterie grand public
- Le suivi de la progression des animateurs bénévoles
- La mise à disposition d’outils pour les communautés locales
- La gestion des demandes de sensibilisation par des organisations (entreprises, services publics, enseignement)
Nous disposons d’un tenant principal pour l’association et d’autres tenants pour des grandes entreprises qui souhaitent un environnement isolé.
Principes d’isolation
Il existe 3 patterns classiques d’architecture multi-tenant.
- Réservation d’une instance de base de données par tenant : Cette option est la plus sécurisée, mais elle est très complexe à gérer pour les Devs et les Ops.
- Réservation d’un schéma dans une base de données commune : cette option masque les données des autres tenants, évitant le risque de collision en cas de bug applicatif.
- Partage des tables elles-mêmes, avec discrimination des lignes par un champ dédié : cette option est la plus simple pour les Devs et les Ops, mais elle comporte un risque de collision de données entre tenant, en cas de bug applicatif.
A la Fresque du Climat, nous avons fait le choix numéro 2 de réservation d’un schéma.
Pour renforcer la sécurité, nous y avons ajouté un chiffrement des données avec une clé propre à chaque tenant. Ainsi, si une collision survenait, la donnée ne serait pas déchiffrable avec la mauvaise clé. En effet, le service est accédé :
- Sur org-a.service.net en utilsant la clé A
- Sur org-b.service.net en utilsant la clé B
Stockage des clés de chiffrement
Le principe de sécurité est de ne pas faire sortir une clé de chiffrement de son coffre-fort : les requêtes de déchiffrement/chiffrement sont envoyées au coffre-fort et traitées en son sein.
Il existe 2 patterns principaux pour le stockage et la protection des clefs :
- Un coffre-fort logiciel, qui isole les clés avec une protection logicielle. On peut donner l’exemple HashiCorp Vault déployable on premises ou dans le Cloud, ou des coffres intégrés à une offre Cloud (AWS KMS, GCP Cloud KMS, etc.).
- Un coffre-fort HSM (Hardware Security Module) qui isole les clés avec une protection matérielle, plus sécurisée. On peut donner l’exemple du HSM Luna de Thalès déployable on premises, ou des HSM intégrés à une offre Cloud (GCP Cloud HSM, AWS CloudHSM, etc.)
Certaines grandes entreprises demandent aux opérateurs SaaS de requêter leur coffre-fort préexistant, on premise, on appelle ce principe HYOK (Hold Your Own Key).
A la Fresque du Climat, nous avons fait le choix d’un coffre-fort logiciel intégré à une offre Cloud pour des raisons de compromis entre Sécurité et coût/complexité.
Fédération d’identité
Le principe de la fédération d’identité, en contexte SaaS, est de déléguer l’authentification au fournisseur d’identité (Identity provider) du client. Il est intéressant à plusieurs titres :
- Il évite le stockage des secrets hors du SI Client (cf. HYOK)
- Il évite au fournisseur SaaS de développer une gestion de l’authentification (renouvellement des mots de passe, authentification multi-facteurs)
- Il offre une bonne ergonomie à l’utilisateur qui n’a pas besoin de s’authentifier plusieurs fois (principe du single sign on)
en 2024, Il existe 2 standards principaux pour la fédération d’identité :
- SAML (Security Assertion Markup Language) créé en 2002, et reposant sur SOAP du W3C, et utilisé en contexte d’entreprise
- OpenID Connect, un standard récent (2014) et basé sur OAuth, et utilisé en contexte grand public
A la Fresque du Climat, nous avons fait le choix de SAML, par souci de maximiser l’interopérabilité en contexte d’entreprise. Une partie de nos tenants utilise donc une fédération SAML avec leur propre fournisseur d’identité.
Réduction de la surface d’attaque
Les outils SaaS font l’objet de nombreuses attaques. En effet,car certains hackers cherchent à réaliser un exploit en trouvant une faille dans des offres connues (Google, Microsoft…).
Il est donc nécessaire de se prémunir du risque Cyber avec différents types de Firewalls :
- VPC (Virtual Private Cloud) pour faire du filtrage de ports
- Firewall DDoS pour contrer les attaques par déni de service (couches 3 et 4 du modèle OSI)
- Web Application Firewall pour contrer les attaques OWASP sur la couche applicative (couche 7 du modèle OSI)
A la Fresque du Climat, nous avons fait le choix d’implémenter ces 3 types de firewalls. Nous avons aussi fait une restriction par liste blanche (whitelist) des domaines permettant de s’inscrire sur la billetterie de chaque tenant.
Pseudonymisation des données personnelles
Enfin, nous avons fait le choix de pseudonymiser les données personnelles des utilisateurs inactifs, au bout d’une durée déterminée par chaque tenant. Cette pseudonymisation répond à 2 besoins :
- Respecter la règle du RGPD sur la durée de rétention
- Limiter la quantité de données personnelles dérobées en cas d’exploit réussi par un hacker
Dans un prochain article, je ferai un retour d’expérience sur notre architecture Cloud Ready.