Créer une solution SaaS multilocataire pour les entreprises canadiennes de technologies financières : le plan directeur de l’architecte
La décision de créer une plateforme multilocataire va bien au-delà d’un choix technique. Pour les jeunes entreprises canadiennes de technologies financières, il s’agit d’un engagement réglementaire. À l’heure actuelle, ce secteur est régi par le BSIF, CANAFE et la Loi 25. Votre architecture constitue donc votre première ligne de défense. Elle vous protège à la fois contre les atteintes à la sécurité des données et les manquements réglementaires.
Pour les responsables de la conformité, les chefs des TI bancaires et les fondateurs d’entreprises de technologies financières, la « mise à l’échelle » ne concerne pas seulement la vitesse. Elle exige le maintien d’une isolation stricte entre les locataires. Vous devez également composer avec les contraintes particulières des normes canadiennes applicables aux logiciels financiers. Votre infrastructure technologique doit donc respecter les protocoles canadiens du BSIF en matière de gestion des risques technologiques dès le premier jour.
Les trois modèles multilocataires : choisir votre rempart de conformité
Dans le secteur des technologies financières canadiennes, votre modèle d’isolation détermine la complexité de vos audits. Voici comment les trois principaux modèles se comparent aux exigences de conformité à la ligne directrice B-13 du BSIF pour les fournisseurs.
1. Base de données partagée et schéma partagé : le modèle par identifiant
Tous les locataires utilisent les mêmes tables. Ils sont séparés uniquement par un tenant_id.
- La réalité : cette approche est rentable. Toutefois, elle demeure un signal d’alarme pour les auditeurs de CANAFE et les chefs des TI bancaires.
- Le risque : une seule erreur logique dans votre ORM peut entraîner une fuite de données catastrophique. Dans un environnement de technologies financières réglementé, une exposition accidentelle est traitée comme une atteinte majeure.
2. Base de données partagée et schémas isolés : le modèle logique
Les locataires partagent une même instance de base de données, mais disposent d’espaces de noms distincts.
- La réalité : cette approche offre un compromis fonctionnel. Elle empêche les jointures SQL entre les locataires.
- Le verdict : elle convient aux applications présentant un risque moins élevé. Toutefois, la mise à l’échelle devient difficile lorsqu’un « voisin bruyant » affecte les autres locataires. Cette approche ne répond souvent pas aux exigences rigoureuses des lignes directrices du BSIF sur les cyberrisques applicables aux logiciels.
3. Une base de données isolée par locataire : la norme de référence
Chaque locataire dispose de sa propre instance physique ou virtuelle de base de données.
- La réalité : nous recommandons cette architecture pour les données « Restreintes » ou « Hautement confidentielles ».
- L’avantage : cette architecture assure une séparation physique des données. Si un organisme de réglementation vous interroge sur la ligne directrice B-10 du BSIF concernant la gestion des risques liés aux tiers, vous pouvez lui montrer directement la couche d’infrastructure.
Résidence des données : la contrainte canadienne
Les solutions SaaS canadiennes de technologies financières doivent respecter une souveraineté stricte des données. La LPRPDE et la Loi 25 accordent une grande importance à l’emplacement des renseignements financiers personnels.
Verrouillage régional
Vous ne pouvez pas compter sur des régions situées aux États-Unis. Votre infrastructure doit plutôt être ancrée en sol canadien. Assurez-vous qu’elle est déployée dans les régions suivantes :
- AWS : ca-central-1 (Montréal) ou ca-west-1 (Calgary)
- Azure : Canada Central (Toronto) ou Canada East (Québec)
- GCP : northamerica-northeast1 (Montréal) ou northamerica-northeast2 (Toronto)
Conseil de l’architecte : utilisez des « gardes régionaux » dans votre processus CI/CD. Ils empêchent le déploiement accidentel de services à l’extérieur du Canada.
IAM : la confiance zéro au niveau des locataires
La gestion des identités et des accès (IAM) exige une approche à deux niveaux. Vous gérez des organisations, et non seulement des utilisateurs individuels. Pour approfondir le sujet, consultez notre guide sur les solutions SaaS à confiance zéro pour les entreprises canadiennes réglementées : la stratégie complète.
La couche de la plateforme
Les ingénieurs internes ne devraient jamais disposer d’un « mode Dieu » permanent. Mettez plutôt en œuvre un accès juste-à-temps (JIT). Si un développeur doit résoudre un problème, il doit demander un accès limité dans le temps. Cet accès doit être audité et révoqué automatiquement.
La couche du locataire
Votre plateforme doit prendre en charge le principe Apportez votre propre identité (BYOID). Les grandes institutions s’attendent à une intégration SAML ou OIDC. Votre logique doit donc associer les identités externes à des rôles internes, comme responsable de la conformité ou directeur de succursale.
Intégration d’Interac et des services bancaires ouverts
L’intégration aux API d’Interac ou du projet de loi C-27 ajoute de la complexité.
- TLS mutuel (mTLS) : de nombreuses intégrations exigent une authentification par certificat. Votre architecture doit gérer ces certificats séparément pour chaque locataire.
- Limitation du débit par locataire : empêchez qu’une hausse soudaine des appels d’API d’un seul client entraîne un verrouillage global.
Journalisation des audits : l’exigence non négociable de CANAFE
Dans les technologies financières, si une action n’a pas été consignée, elle n’a pas eu lieu. Selon les lignes directrices de CANAFE et du BSIF, vous devez conserver des dossiers immuables pendant sept ans.
Pour assurer la conformité de votre plateforme, vos journaux doivent être :
- Associés au locataire : ajoutez un TenantID à chaque entrée.
- Externalisés : transférez les journaux vers un environnement en « ajout seulement », comme un compartiment S3 doté de la fonction Object Lock.
- Consultables : pendant les audits, vous devez pouvoir exporter les pistes propres à un locataire sans exposer les données des autres clients.
Le défi de l’évaluation des vulnérabilités et du test d’intrusion
Un test d’intrusion standard ne suffit pas. Pour une plateforme multilocataire de technologies financières, vous avez besoin d’une évaluation des vulnérabilités et d’un test d’intrusion (VAPT) axés sur l’« évasion du périmètre d’un locataire ».
L’administrateur d’un locataire peut-il récupérer les données associées au tenant_id d’un autre locataire? Votre rapport VAPT est un outil de vente essentiel. Lorsqu’une banque effectue une vérification diligente, ce rapport démontre votre conformité aux normes canadiennes du BSIF en matière de gestion des risques liés aux technologies.
Prêt à commencer?
La création d’une plateforme multilocataire au Canada exige une approche axée d’abord sur la conformité. Ne laissez pas les raccourcis architecturaux d’aujourd’hui devenir les obstacles réglementaires qui compromettront votre ronde de financement de série A.
Vous cherchez un partenaire pour examiner votre architecture? Discutez avec Espace InfoTech Canada Inc. de la création de plateformes SaaS sécurisées, évolutives et prêtes pour l’audit, conçues spécialement pour le marché canadien.