Maîtriser l'Architecture Multi-Tenant SaaS Sécurisée avec Next.js et TypeScript

L'évolution rapide des modèles d'affaires digitaux a propulsé le Software as a Service (SaaS) au premier plan, offrant flexibilité, scalabilité et des coûts optimisés. Au cœur de nombreuses solutions SaaS innovantes se trouve l'architecture multi-tenant, une approche qui permet à une seule instance logicielle de servir de multiples clients, ou "tenants", tout en maintenant une isolation stricte de leurs données et configurations. Cependant, les avantages de cette mutualisation s'accompagnent de défis de sécurité complexes et cruciaux. Une défaillance dans la protection des données d'un tenant peut avoir des répercussions désastreuses pour tous les autres, soulignant l'impératif d'une architecture multi-tenant SaaS sécurisée dès la conception.

Chez Orbessia Studio, experts en développement web sur-mesure avec Next.js et TypeScript, nous comprenons que la sécurité n'est pas une fonctionnalité additionnelle, mais le fondement même de toute application SaaS réussie. Cet article explore en profondeur les principes, les défis et les meilleures pratiques pour bâtir des systèmes multi-tenant non seulement performants et évolutifs, mais surtout inviolables.

En bref : L'architecture multi-tenant SaaS sécurisée est une conception logicielle où une instance unique d'une application sert plusieurs clients (tenants), assurant une isolation stricte des données et des configurations de chacun, tout en protégeant l'ensemble contre les menaces externes et les fuites inter-tenants.

Comprendre les Fondamentaux de l'Architecture Multi-Tenant

L'architecture multi-tenant se caractérise par le partage des ressources informatiques – infrastructure, application et base de données – entre plusieurs clients, tout en donnant l'illusion à chaque client d'utiliser une instance dédiée. Ce modèle contraste avec l'architecture mono-tenant, où chaque client dispose de sa propre instance logicielle et de sa propre infrastructure. Les avantages du multi-tenant sont nombreux : des coûts d'infrastructure réduits grâce à la mutualisation, une maintenance simplifiée car une seule version du logiciel est déployée et mise à jour, et une scalabilité accrue permettant d'ajouter de nouveaux clients plus facilement et d'optimiser l'utilisation des ressources.

Cependant, cette mutualisation introduit des défis intrinsèques, en particulier en matière de sécurité. La principale préoccupation est l'isolation des données : comment garantir qu'un client ne puisse jamais accéder aux informations d'un autre client, même par accident ou par une tentative malveillante ? Au-delà de l'isolation des données, d'autres aspects de la sécurité, tels que l'authentification et l'autorisation, la gestion des secrets, la protection contre les attaques par déni de service (DDoS) et la conformité réglementaire, deviennent plus complexes dans un environnement partagé.

La conception d'une architecture multi-tenant SaaS sécurisée commence donc par une compréhension approfondie de ces compromis. Il ne s'agit pas seulement de protéger l'application contre les menaces externes, mais aussi de prévenir les "fuites" ou les accès non autorisés entre les tenants. Chaque décision architecturale, du choix de la base de données à la manière dont les API sont exposées, doit être prise en considérant son impact sur la sécurité de l'ensemble du système. C'est un exercice d'équilibre délicat qui exige une expertise technique pointue et une vigilance constante.

Les Enjeux Cruciaux de la Sécurité en Multi-Tenant

La sécurisation d'une application SaaS multi-tenant est un défi multifacette qui va bien au-delà des mesures de sécurité traditionnelles. Le fait de partager des ressources entre plusieurs entités introduit des vecteurs d'attaque et des vulnérabilités spécifiques qui doivent être méticuleusement adressés.

Isolation des Données : Le Cœur du Problème

C'est l'enjeu le plus critique. Si les données de plusieurs tenants résident sur la même base de données ou même sur le même serveur, il est impératif de garantir qu'aucun tenant ne puisse lire, modifier ou supprimer les données d'un autre. Une brèche dans l'isolation des données peut non seulement entraîner une perte de confiance massive, mais aussi des sanctions réglementaires sévères, notamment pour les données personnelles soumises au RGPD. Les risques incluent :

• Accès non autorisé : Un bug ou une mauvaise configuration pourrait permettre à un utilisateur d'accéder aux données d'un autre tenant.
• Fuite de données : Des erreurs dans les requêtes de base de données ou la logique applicative pourraient involontairement révéler des informations confidentielles à des tenants non autorisés.
• Pollution des données : Un tenant malveillant pourrait tenter d'injecter des données corrompues ou de modifier les données d'autres tenants.

Authentification et Autorisation Robuste

Dans un environnement multi-tenant, l'authentification doit non seulement vérifier l'identité de l'utilisateur, mais aussi l'associer correctement à son tenant. L'autorisation, quant à elle, doit s'assurer que l'utilisateur n'accède qu'aux ressources et fonctionnalités de son propre tenant, et uniquement à celles pour lesquelles il dispose des permissions nécessaires. Les défis incluent :

• Gestion des identités : Chaque tenant peut avoir ses propres utilisateurs, ses propres rôles et parfois même ses propres fournisseurs d'identité (SSO).
• Contrôle d'accès basé sur le tenant : Toutes les requêtes API et les accès aux données doivent inclure une vérification du tenant associé à l'utilisateur authentifié.
• Éviter les élévations de privilèges : Empêcher un utilisateur ou un tenant de contourner les contrôles d'autorisation pour accéder à des ressources ou des fonctionnalités qui lui sont interdites.

Vulnérabilités Spécifiques aux API et Applications Web

Les applications SaaS modernes reposent fortement sur les API. Dans un contexte multi-tenant, les API doivent être conçues avec une sécurité renforcée.

• API Security : Les points d'extrémité API doivent valider le tenant pour chaque requête. Les attaques courantes comme l'injection SQL, les scripts inter-sites (XSS) et les requêtes inter-sites forgées (CSRF) prennent une nouvelle dimension de risque dans un environnement partagé.
• DDoS (Distributed Denial of Service) : Une attaque contre un tenant pourrait potentiellement affecter la disponibilité de l'application pour tous les autres tenants. Des mécanismes de limitation de débit (rate limiting) et de protection DDoS sont essentiels.
• Gestion des secrets : Les clés API, les identifiants de base de données et autres informations sensibles doivent être stockés et gérés de manière ultra-sécurisée, en évitant toute fuite potentielle entre les environnements de développement, de staging et de production.

Conformité Réglementaire et Audits

Opérer un SaaS multi-tenant implique souvent de gérer des données sensibles, ce qui requiert une conformité stricte avec diverses réglementations (RGPD en Europe, CCPA en Californie, HIPAA pour la santé, etc.).

• Conformité des données : Assurer que les pratiques de stockage, de traitement et de suppression des données respectent les exigences légales de chaque juridiction où les clients opèrent.
• Audits réguliers : Des audits de sécurité et des tests de pénétration réguliers sont indispensables pour identifier et corriger les vulnérabilités avant qu'elles ne soient exploitées. Pour cela, s'appuyer sur les recommandations de la Google Search Central pour la sécurité est une excellente pratique.

Ces enjeux, bien que complexes, sont surmontables avec une architecture bien pensée et une approche de sécurité intégrée dès le début du processus de développement. Chez Orbessia Studio, nous mettons en œuvre ces principes dès la phase de conception de chaque développement SaaS pour nos clients.

Modèles d'Isolation des Données : Choisir la Bonne Approche

La manière dont les données des différents tenants sont isolées est l'une des décisions architecturales les plus fondamentales et les plus impactantes pour la sécurité d'une application multi-tenant. Il existe principalement trois modèles d'isolation, chacun avec ses avantages, ses inconvénients et ses implications en termes de sécurité.

1. Base de Données Séparée par Tenant (Siloed Database)

Dans ce modèle, chaque tenant dispose de sa propre base de données physique ou logique. C'est le niveau d'isolation le plus élevé.

• Avantages :
• Sécurité maximale : La séparation physique ou logique élimine presque totalement le risque de fuite de données entre tenants. Une compromission d'une base de données n'affecte pas les autres.
• Simplicité de la logique applicative : La couche applicative n'a pas besoin d'implémenter de logiques complexes pour filtrer les données par tenant, car chaque connexion est déjà spécifique à un tenant.
• Facilité de sauvegarde et restauration : Les opérations de gestion de données sont spécifiques à chaque tenant.
• Conformité : Plus facile à démontrer la conformité aux exigences réglementaires strictes.
• Inconvénients :
• Coût élevé : Chaque base de données nécessite ses propres ressources, ce qui augmente les coûts d'infrastructure et de maintenance.
• Complexité opérationnelle : Gérer et mettre à jour un grand nombre de bases de données peut devenir un défi opérationnel.
• Moins de scalabilité horizontale : La scalabilité est plus difficile à gérer que pour un système mutualisé.
• Cas d'usage : Idéal pour les applications traitant des données extrêmement sensibles (santé, finance), ou pour les clients nécessitant une personnalisation poussée de leur environnement de base de données.

2. Schéma Séparé dans une Base de Données Partagée (Shared Database, Separate Schema)

Ici, tous les tenants partagent la même instance de base de données, mais chacun dispose de son propre schéma (un ensemble de tables, vues, etc.).

• Avantages :
• Bon compromis sécurité/coût : Meilleure isolation que le modèle de table partagée, tout en mutualisant l'infrastructure de la base de données.
• Gestion simplifiée : Une seule instance de base de données à gérer.
• Scalabilité : Plus facile à scaler que les bases de données complètement séparées.
• Inconvénients :
• Logique applicative plus complexe : L'application doit gérer la sélection du schéma correct pour chaque tenant.
• Risque de performance : Un tenant très actif peut impacter les performances des autres si les ressources de l'instance de base de données sont saturées.
• Sécurité : Bien que les schémas soient séparés, ils résident sur la même instance, ce qui peut présenter un risque si la base de données elle-même est compromise.
• Cas d'usage : Fréquemment utilisé pour des applications SaaS de taille moyenne où la sécurité est primordiale mais les coûts doivent être maîtrisés.

3. Ligne par Tenant dans une Table Partagée (Shared Database, Shared Schema)

C'est le modèle le plus mutualisé, où toutes les données de tous les tenants sont stockées dans les mêmes tables, avec une colonne "tenant_id" pour identifier à quel client appartient chaque ligne.

• Avantages :
• Coût le plus bas : Mutualisation maximale des ressources, ce qui réduit considérablement les coûts d'infrastructure.
• Haute scalabilité : Très facile d'ajouter de nouveaux tenants et de gérer la croissance.
• Simplicité de déploiement : Une seule base de données à déployer et à maintenir.
• Inconvénients :
• Sécurité la plus faible : Risque le plus élevé de fuite de données si la logique applicative de filtrage par tenant est défaillante. Chaque requête doit impérativement inclure le tenant_id.
• Complexité de la logique applicative : Exige une discipline rigoureuse dans le code pour s'assurer que toutes les opérations de base de données sont filtrées par tenant_id.
• Performances : Les tables volumineuses peuvent nécessiter une indexation avancée pour de bonnes performances.
• Conformité difficile : Plus difficile de prouver l'isolation des données pour les réglementations strictes.
• Cas d'usage : Adapté aux applications avec des exigences de sécurité moins critiques ou pour des startups ayant besoin de minimiser les coûts de démarrage.

Tableau Comparatif des Modèles d'Isolation

Le choix du modèle dépendra des exigences spécifiques de l'application, du budget, des contraintes de performance et, surtout, des exigences de sécurité et de conformité. Une décision éclairée dès le début est cruciale pour une architecture multi-tenant SaaS sécurisée et durable.

Mise en Œuvre des Mécanismes de Sécurité avec Next.js et TypeScript

Une fois le modèle d'isolation des données choisi, il est impératif d'implémenter des mécanismes de sécurité robustes à tous les niveaux de l'application. L'utilisation de technologies modernes comme Next.js et TypeScript offre des outils puissants pour construire une architecture multi-tenant SaaS sécurisée.

Authentification et Autorisation Basées sur le Tenant

L'authentification doit non seulement vérifier l'identité de l'utilisateur, mais aussi l'associer à un tenant spécifique. Pour cela, des solutions comme Auth.js (anciennement NextAuth.js) ou des services d'identité tiers (Okta, Auth0) peuvent être intégrées. Une fois l'utilisateur authentifié, son tenantId doit être stocké de manière sécurisée (par exemple, dans un jeton JWT) et utilisé pour toutes les requêtes subséquentes.

L'autorisation doit ensuite utiliser ce tenantId pour filtrer l'accès aux ressources. C'est ici que Next.js, avec ses API Routes et ses middlewares, excelle.

#### Exemple de Middleware Next.js pour l'Identification du Tenant

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { getToken } from 'next-auth/jwt';

export async function middleware(req: NextRequest) {
  const secret = process.env.NEXTAUTH_SECRET;
  const token = await getToken({ req, secret });

  // Si l'utilisateur n'est pas authentifié, rediriger vers la page de connexion
  if (!token) {
    const url = req.nextUrl.clone();
    url.pathname = '/auth/signin';
    return NextResponse.redirect(url);
  }

  // Récupérer le tenantId depuis le token ou une base de données
  // Pour cet exemple, supposons que le tenantId est directement dans le token JWT
  const tenantId = token.tenantId as string | undefined;

  if (!tenantId) {
    // Gérer le cas où le tenantId est manquant dans le token
    return new NextResponse('Tenant ID missing', { status: 401 });
  }

  // Ajouter le tenantId aux headers de la requête pour les API Routes
  // C'est une méthode simple, pour une sécurité accrue, il est préférable
  // de passer le tenantId via le contexte de l'application ou des services internes
  const requestHeaders = new Headers(req.headers);
  requestHeaders.set('x-tenant-id', tenantId);

  return NextResponse.next({
    request: {
      headers: requestHeaders,
    },
  });
}

export const config = {
  matcher: ['/dashboard/:path*', '/api/:path*'], // Appliquer le middleware aux routes protégées
};

Ce middleware s'assure que chaque requête vers les routes protégées est authentifiée et porte l'identifiant du tenant.

Sécurisation des API Routes avec TypeScript

Dans les API Routes de Next.js, le tenantId peut être extrait des headers (comme dans l'exemple ci-dessus) ou du contexte de la requête pour filtrer les données.

// pages/api/data.ts
import type { NextApiRequest, NextApiResponse } from 'next';
import { db } from '../../lib/db'; // Votre client de base de données

type Data = {
  message: string;
  data?: any[];
};

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse<Data>
) {
  // Récupérer le tenantId du header (mis par le middleware)
  const tenantId = req.headers['x-tenant-id'] as string;

  if (!tenantId) {
    return res.status(401).json({ message: 'Tenant ID required' });
  }

  // Exemple de requête de données filtrée par tenantId
  try {
    // Supposons un modèle de base de données avec une colonne 'tenant_id'
    const tenantData = await db.items.findMany({
      where: {
        tenant_id: tenantId,
      },
    });
    res.status(200).json({ message: 'Data fetched successfully', data: tenantData });
  } catch (error) {
    console.error('Error fetching tenant data:', error);
    res.status(500).json({ message: 'Internal server error' });
  }
}

L'utilisation de TypeScript apporte une couche de sécurité supplémentaire en permettant un typage fort, réduisant ainsi les erreurs courantes et améliorant la robustesse du code.

Chiffrement des Données

• Données au repos : Toutes les données sensibles stockées en base de données ou sur des systèmes de fichiers doivent être chiffrées. Les fournisseurs de cloud comme AWS, Azure ou GCP offrent des services de chiffrement au repos (encryption at rest) qui peuvent être facilement activés.
• Données en transit : L'utilisation systématique du protocole HTTPS est non négociable. Les certificats SSL/TLS garantissent que toutes les communications entre le client et le serveur sont chiffrées, protégeant contre les écoutes (eavesdropping) et les attaques de l'homme du milieu (Man-in-the-Middle).

Gestion Sécurisée des Secrets

Les clés API, les identifiants de base de données, les clés de chiffrement et autres secrets ne doivent jamais être codés en dur ni stockés dans des dépôts de code publics.

• Variables d'environnement : Pour les environnements de développement et de staging, les variables d'environnement sont une solution.
• Gestionnaires de secrets : En production, l'utilisation de services dédiés comme AWS Secrets Manager, Azure Key Vault ou HashiCorp Vault est fortement recommandée. Ces services permettent de stocker, de gérer et de récupérer les secrets de manière sécurisée, avec des contrôles d'accès granulaires.

Logging, Monitoring et Alerting

Une architecture multi-tenant SaaS sécurisée n'est pas statique ; elle nécessite une surveillance continue.

• Logging détaillé : Enregistrer toutes les activités significatives, y compris les tentatives d'authentification réussies et échouées, les accès aux données sensibles et les erreurs applicatives, avec un tenantId associé à chaque log.
• Monitoring en temps réel : Utiliser des outils de monitoring pour détecter les comportements anormaux, les pics d'activité suspects ou les tentatives d'accès non autorisées.
• Système d'alerte : Mettre en place des alertes automatiques pour informer les équipes de sécurité en cas d'événements critiques, permettant une réponse rapide aux incidents.

Audits de Sécurité et Tests de Pénétration

Des audits de sécurité réguliers, y compris des tests de pénétration (pentests) menés par des tiers indépendants, sont essentiels pour identifier les vulnérabilités. Ces tests doivent spécifiquement cibler les risques liés au multi-tenant, comme les tentatives d'accès inter-tenant. Pour cela, s'inspirer des guides de sécurité du W3C et des bonnes pratiques documentées sur MDN Web Docs est un excellent point de départ.

En combinant ces mécanismes de sécurité avec l'agilité de Next.js et la robustesse de TypeScript, Orbessia Studio développe des solutions SaaS qui non seulement répondent aux exigences fonctionnelles, mais garantissent également une protection optimale des données de tous les clients.

Chez Orbessia Studio : Sécurité et Innovation au Quotidien

Chez Orbessia Studio, nous avons récemment été confrontés à un défi intéressant lors du développement d'une plateforme SaaS B2B innovante pour la gestion de services. Le client, opérant dans un secteur réglementé, exigeait un niveau d'isolation des données exceptionnel, tout en conservant les avantages de coûts et de maintenance d'une architecture multi-tenant.

Notre solution a été de combiner un modèle de "schéma séparé dans une base de données partagée" avec une couche de sécurité applicative très sophistiquée, construite avec Next.js et TypeScript. Nous avons mis en place un système de middleware Next.js, renforcé par des contrôles d'accès fins au niveau des API Routes. Chaque requête était non seulement authentifiée, mais aussi rigoureusement associée à un tenantId extrait d'un jeton JWT sécurisé, garantissant que chaque opération de base de données était strictement limitée au schéma du tenant concerné.

Pour assurer une résilience maximale, nous avons intégré des mécanismes de "circuit breaker" et de "rate limiting" directement dans nos API, protégeant ainsi l'ensemble de la plateforme contre des attaques potentielles ciblant un seul tenant. La robustesse de TypeScript nous a permis de typer nos requêtes et nos réponses, réduisant drastiquement les erreurs d'exécution qui auraient pu mener à des failles de sécurité.

Nous avons également mis en œuvre une gestion des secrets via un service cloud dédié, assurant que les informations sensibles ne soient jamais exposées. Pour la conformité, nous avons documenté chaque étape de notre processus de sécurisation, ce qui a grandement facilité l'audit de sécurité externe.

Ce projet nous a rappelé l'importance de ne jamais transiger sur la sécurité. Comme on le voit souvent sur des forums comme Reddit ou des discussions LinkedIn sur les meilleures pratiques de développement, la sécurité est un processus continu. Un membre de notre équipe a d'ailleurs partagé un thread sur LinkedIn détaillant l'importance des tests de pénétration réguliers pour les plateformes SaaS, une pratique que nous avons systématiquement appliquée ici. Nous avons même intégré des outils d'analyse statique de code (SAST) et dynamique (DAST) dans notre pipeline CI/CD pour détecter les vulnérabilités de manière précoce.

Cette expérience a non seulement renforcé notre expertise en matière d'architecture multi-tenant SaaS sécurisée, mais a aussi permis à notre client de lancer une plateforme avec une confiance inébranlable dans sa solidité et sa protection des données.

Conclusion : Bâtir l'Avenir du SaaS en Toute Sécurité

L'adoption d'une architecture multi-tenant est une stratégie puissante pour le développement d'applications SaaS, offrant des avantages indéniables en termes de coûts, de maintenance et de scalabilité. Cependant, le succès de cette approche repose entièrement sur la capacité à garantir une sécurité irréprochable pour chaque client. L'architecture multi-tenant SaaS sécurisée n'est pas une option, mais une exigence fondamentale qui doit être intégrée à chaque étape du cycle de vie du développement, de la conception initiale au déploiement et à la maintenance continue.

Les défis sont nombreux, allant de l'isolation stricte des données à la gestion robuste des identités et des accès, en passant par la protection contre les menaces spécifiques aux API et la conformité réglementaire. Négliger l'un de ces aspects peut avoir des conséquences dévastatrices, compromettant la confiance des utilisateurs, entraînant des pertes financières et des sanctions légales.

En s'appuyant sur des technologies modernes comme Next.js et TypeScript, et en adoptant une approche proactive de la sécurité – incluant des middlewares d'authentification et d'autorisation, le chiffrement des données, une gestion sécurisée des secrets, et des audits réguliers – il est tout à fait possible de construire des plateformes SaaS multi-tenant qui sont à la fois innovantes, performantes et inexpugnables.

Chez Orbessia Studio, notre engagement est de créer des solutions sur-mesure qui non seulement répondent aux besoins fonctionnels de nos clients, mais qui sont également conçues pour résister aux menaces les plus sophistiquées. Que ce soit pour une création de site vitrine avec des besoins spécifiques ou un projet de refonte de site web complexe, la sécurité est toujours au cœur de nos préoccupations. Nous sommes là pour vous accompagner dans la concrétisation de vos projets SaaS, en vous offrant l'expertise nécessaire pour une architecture multi-tenant SaaS sécurisée et pérenne. N'hésitez pas à nous contacter pour discuter de vos besoins.

Questions fréquentes

Qu'est-ce qu'une architecture multi-tenant SaaS ?

Une architecture multi-tenant SaaS est un modèle où une seule instance d'une application logicielle et son infrastructure sous-jacente sont utilisées pour servir plusieurs clients distincts, appelés "tenants". Chaque tenant a accès à sa propre instance logique de l'application, avec ses propres données et configurations, tout en partageant les mêmes ressources physiques du serveur et de la base de données. L'objectif est de mutualiser les coûts et la maintenance tout en offrant une expérience personnalisée à chaque client.

Pourquoi la sécurité est-elle si critique dans une architecture multi-tenant ?

La sécurité est critique car la mutualisation des ressources introduit des risques uniques. Si les données de plusieurs clients sont stockées ensemble, une faille de sécurité pourrait potentiellement exposer les données de tous les clients simultanément. Il est impératif d'assurer une isolation parfaite des données, une authentification et une autorisation rigoureuses pour éviter les fuites d'informations, les accès non autorisés entre tenants et les compromissions générales de la plateforme.

Comment assurer l'isolation des données entre les tenants ?

L'isolation des données peut être assurée par plusieurs modèles :

1. Base de données séparée par tenant : Chaque tenant a sa propre base de données, offrant la meilleure isolation.
2. Schéma séparé dans une base de données partagée : Les tenants partagent la même instance de base de données, mais chacun a son propre schéma.
3. Table partagée avec colonne `tenant_id` : Tous les tenants partagent les mêmes tables, et chaque ligne est identifiée par un tenant_id.

Le choix dépend des exigences de sécurité, de performance et de coût. Le modèle à table partagée exige la logique applicative la plus rigoureuse pour filtrer chaque requête par tenant_id.

Quel rôle jouent Next.js et TypeScript dans la sécurisation d'un SaaS multi-tenant ?

Next.js et TypeScript sont des outils puissants pour une architecture multi-tenant SaaS sécurisée. Next.js permet de créer des API Routes robustes et d'utiliser des middlewares pour l'authentification et l'identification du tenant avant d'accéder aux données. Le typage fort de TypeScript réduit les erreurs de programmation qui pourraient introduire des vulnérabilités, améliore la maintenabilité du code et facilite la collaboration en équipe. Ensemble, ils permettent de construire une couche applicative solide qui applique rigoureusement les contrôles de sécurité.

Faut-il faire des audits de sécurité pour une application SaaS multi-tenant ?

Oui, absolument. Les audits de sécurité réguliers et les tests de pénétration (pentests) sont indispensables pour une architecture multi-tenant SaaS sécurisée. Ils permettent d'identifier les vulnérabilités potentielles, les failles dans l'isolation des données ou les erreurs de configuration avant qu'elles ne soient exploitées par des acteurs malveillants. Ces audits doivent être menés par des experts indépendants et doivent inclure des scénarios spécifiques aux environnements multi-tenant, tels que les tentatives d'accès inter-tenant.