Isolation des tenants et limites

L'isolement des tenants et des limites est le fondement d'une architecture multi-tenante. Objectif : que les actions d'un locataire n'affectent jamais les données, la sécurité et les SLO de l'autre, et que les ressources soient distribuées de manière équitable et prévisible. Ci-dessous, une carte pratique des solutions, du niveau de données à la planification informatique et à la gestion des incidents.

1) Modèle de menace et objectifs

Menaces

Fuite de données entre locataires (logique/par cache/par logs).
« Noisy neighbor » : dégradation des performances due aux surtensions chez un client.
Escalade des privilèges (erreur dans la stratégie d'accès).
Facturation-dérive (non-conformité d'utilisation et de calcul).
Scripts tolérants aux pannes en cascade (un incident conduit au downtime de beaucoup).

Objectifs

Isolation stricte des données et des secrets.
Limites/quotas et planification équitable.
Audit transparent, observabilité et facturation.
Localisation des incidents et récupération rapide per tenant.

2) Niveaux d'isolation (modèle de bout en bout)

1. Données

'tenant _ id'dans les clés et index, Row-Level Security (RLS).
Cryptage : hiérarchie KMS → clé locataire (KEK) → clés de données (DEK).
Circuits séparés/OBD aux exigences élevées (Silo), cluster commun c RLS pour l'efficacité (Pool).
Les politiques de rétention et le « droit à l'oubli » per tenant, crypto-shredding clés.

2. Calculs

Quotas CPU/RAM/IO, pools de worker par tenant, files d'attente « pondérées ».
Isolation GC/heap (conteneurs/réglages JVM/Runtime), limites sur le parallélisme.
Per-tenant autoscaling + backpressure.

3. Réseau

Segmentation : private endpoints/VPC, ACL par 'tenant _ id'.
Rate limiting et per-tenant connection caps à la frontière.
Protection contre les DDoS/bots en tenant compte du plan/priorité.

4. Opérations et processus

Migrations de paravent, backups, DR, feature-flags.
Incidents - « micro-blast rayon » : fusion par 'tenant _ id'.

3) Contrôle d'accès et contexte du locataire

AuthN: OIDC/SAML; les tokens portent 'tenant _ id', 'org _ id', 'plan', 'scopes'.
AuthZ : RBAC/ABAC (rôles + attributs de projet, département, région).
Contexte à la frontière : La passerelle API extrait et valide le contexte du tenant, complète les limites/quotas, écrit dans les trajets.
Principe du « double cadenas » : vérification dans le service + RLS/politique OBD.

4) Données : schémas, cache, logs

• Shared-schema (row-level) : un maximum d'efficacité, un RLS strict est obligatoire.
• Per-schema : compromis d'isolation/opérabilité.
• Per-DB/cluster (Silo) : pour VIP/réglable.

Cache : préfixes de clés 'tenant : {id} :...', TTL par plan, protection contre le cache-stampede (lock/early refresh).

Logs/métadonnées : pseudonymisation complète des PII, filtres par 'tenant _ id', interdiction de « scanner » les logs des différents locataires.

5) Limiter le trafic et les opérations

Mécaniciens de base

Token Bucket : éclats lissés, paramétrage 'rate '/' burst'.
Leaky Bucket : stabilisation throughput.
Fenêtre fixe/Sliding Window : quotas simples/précis par fenêtre temporelle.
Limites de concurrence : caps pour les requêtes/jobs simultanées.

Où appliquer

À la frontière (passerelle L7/API), la protection principale et la « panne rapide ».
Au cœur (dans les services/files d'attente) - pour le deuxième circuit et « fair share ».

Stratégies

Par tenant/plan/endpoint/type d'opération (API publiques, exportations lourdes, actions admin).
Priority-aware : VIP obtient plus de « burst » et le poids dans l'arbitrage.
Idempotency-keys pour des retraits sécurisés.

Exemple de profils (concepts)

Starter : 50 req/s, burst 100, 2 exportations parallèles.
Business : 200 req/s, burst 400, 5 exportations.
Enterprise/VIP : 1000 req/s, burst 2000, workers dédiés.

6) Quotas et planification équitable (fairness)

Quotas de ressources : stockage, objets, messages/min, tâches/heure, taille des files d'attente.
Weighted Fair Queuing/Deficit Round Robin : accès « pondéré » aux workers partagés.
Per-tenant worker pools : isolation rigide pour les clients bruyants/critiques.
Contrôle d'admission : échec/dégradation jusqu'à ce que les quotas soient épuisés.
Backoff + jitter : retards exponentiels pour ne pas synchroniser les surtensions.

7) Observabilité et facturation per tenant

Balises obligatoires : 'tenant _ id', 'plan', 'region', 'endpoint', 'status'.
SLI/SLO per tenant: p95/p99 latency, error rate, availability, utilization, saturation.
Utilisation-métriques : compteurs par opérations/octets/secondes CPU → agrégateur de factures →.
L'idempotence de la facturation : snapshots à la frontière, protection contre les doubles pertes/pertes d'événements.
Segments Dashboards : VIP/locataires réglementés/nouveaux locataires.

8) Incidents, dégradations et DR « par locataire »

Fusion par 'tenant _ id' : Arrêt d'urgence/câblage d'un locataire spécifique sans impact sur les autres.
Graceful Degradation : read-only mode, files d'attente vers le « bac à sable », tâches retardées.
RTO/RPO per tenant : valeurs cibles de récupération et de perte pour chaque plan.
Exercice : « jours de jeu » réguliers avec débranchement du locataire bruyant et vérification du DR.

9) Conformité (résidence, intimité)

Pinning tenant à la région ; des règles claires pour les flux croisés régionaux.
Audit de l'accès aux clés/données, journal des opérations admin.
Gestion de l'exportation et de l'exportation de données per tenant.

10) Mini-repères : Comment rassembler

Flux de requête

1. Edge (API Gateway) : TLS → extraire 'tenant _ id' → valider le token → appliquer rate/quotas → placer les tracés.
2. Policy Engine : contexte 'tenant _ id/plan/features' → décision sur l'itinéraire et les limites.
3. Service : Vérification des droits + étiquettes 'tenant _ id' → utilisation de la base de données sous RLS → cache préfixe.
4. Collecte d'utilisation : compteurs d'opérations/octets → agrégateur → facturation.

Données

Schéma/OBD de stratégie (row-level/per-schema/per-DB).
KMS : clés par locataire, rotation, crypto-shredding lors de la suppression.

Calculs

Files d'attente avec échelles, pools de worker per tenant, caps par concurrency.
Autoscaling par métriques per-tenantes.

11) Pseudo-politiques (pour l'orientation)

yaml limits:
starter:
req_per_sec: 50 burst: 100 concurrency: 20 exports_parallel: 2 business:
req_per_sec: 200 burst: 400 concurrency: 100 exports_parallel: 5 enterprise:
req_per_sec: 1000 burst: 2000 concurrency: 500 exports_parallel: 20

quotas:
objects_max: { starter: 1_000_000, business: 20_000_000, enterprise: 100_000_000 }
storage_gb: { starter: 100,   business: 1000,    enterprise: 10000 }

12) Chèque-liste avant la vente

• Source unique de vérité 'tenant _ id' ; Il se promène et se loge partout.
• RLS/ACL est activé au niveau OBD + contrôle de service (double serrure).
• Clés de chiffrement per tenant, rotation/suppression documentée (crypto-shredding).
• Limites/quotas à la frontière et à l'intérieur ; sursaut et « burst » testés.
• Fair-queuing et/ou workers dédiés pour les VIP ; caps на concurrency.
• SLO et alertes per-tenants ; dashboards par segments.
• La collecte d'utilisation est idempotente ; le couplage avec la facturation a été vérifié.
• Les DR/incidents sont localisés avant le locataire ; la fusion par 'tenant _ id' fonctionne.
• Les caches/logs sont divisés par locataires ; PII est masqué.
• Les procédures de migration/backup/export sont plus favorables.

13) Erreurs typiques

RLS désactivé/contourné par l'utilisateur « de service » - risque de fuite.
Limite mondiale unique → « noisy neighbor » et violation de SLO.
Caches/files d'attente partagées sans préfixe → intersection de données.
La facturation compte selon les loges qui sont perdues pendant les pics.
L'absence de fusion en cascade.
Migration en un seul coup sans pouvoir arrêter le problème 'tenant _ id'.

14) Sélection rapide de la stratégie

Réglementé/VIP : Données silo (per-DB), workers dédiés, quotas stricts et résidence.
SaaS de masse : Shared-schema + RLS, limites fortes à la frontière, fair-queuing à l'intérieur.
Charge « bruyante/pulsante » : gros « burst » + caps de concurrence rigides, backpressure et priorités par plan.

Conclusion

L'isolement des tenants et des limites est une question de frontières et de justice. Un 'tenant _ id'clair à travers la pile, le RLS et le cryptage des données, la limitation et les quotas à la frontière et au cœur, un planificateur équitable, l'observation et la localisation des incidents - tout cela offre une sécurité, une qualité prévisible et une facturation transparente pour chaque locataire, même avec une croissance agressive de la plate-forme.