Isolamento dei tenanti e limiti

L'isolamento dei tenanti e i limiti sono le fondamenta dell'architettura multi-tenante. Obiettivo: assicurarsi che le azioni di un inquilino non influiscano mai sui dati, sulla sicurezza e sulla SLO di un altro e che le risorse vengano distribuite in modo equo e prevedibile. Di seguito è riportata una mappa pratica delle soluzioni che vanno dal livello dei dati alla pianificazione dei calcoli e alla gestione degli incidenti.

1) Modello di minacce e obiettivi

Minacce

Perdita di dati tra gli affittuari (logica/cache/logi).
Noisy neighbor - Deterioramento delle prestazioni a causa dei picchi di un singolo client.
Escalation dei privilegi (errore nel criterio di accesso).
Browser (non corrispondenza tra uso e addebito).
Script di errore a cascata (l'incidente di uno porta al downtime di molti).

Obiettivi

Isolamento rigoroso di dati e segreti.
Limiti/quote per tenanti e pianificazione equa.
Controllo trasparente, osservabilità e billing.
Localizzazione degli incidenti e ripristino rapido per tenant.

2) Livelli di isolamento (modello trasversale)

1. Dati

«tenant _ id» in chiavi e indici, Row-Level Security (RLS).
Crittografia: la gerarchia KMS → KEK (KEK) → le chiavi dei dati (DEK).
Diagrammi/Database ad elevate esigenze (Silo), cluster con RLS comune per l'efficienza (Pool).
Policy retensing e «diritto di dimenticare» per tenant, crypto-shredding chiavi.

2. Calcoli

Quote CPU/RAM/IO, pool di worker per tenente, code «ponderate».
Isolamento GC/heap (contenitori/impostazioni JVM/Runtime), limiti per parallelismo.
Autoscaling per tenente + backpressure.

3. Rete

Segmentazione: private endpoint/VPC, ACL in'tenant _ id '.
Rate limiting e per-tenant connection caps al limite.
Protezione da DDoS/bot in base al piano/priorità.

4. Operazioni e processi

Migrazioni, backap, DR, feature-flags.
Gli incidenti sono «micro-blast-raggio», fiusing «tenant _ id».

3) Controllo dell'accesso e contesto dell'inquilino

AuthN: OIDC/SAML; i token portano «tenant _ id», «org _ id», «plan», «scopes».
AuthZ: RBAC/ABAC (ruoli + attributi di progetto, reparto, regione).
Contesto al confine: il gateway API recupera e valuta il contesto tenante, completa i limiti/quote, scrive nelle roulotte.
Il «doppio lucchetto» è un controllo del servizio + RLS/DB.

4) Dati: schemi, cache, fogli

• Shared-schema (row-level): massima efficienza, RLS rigoroso.
• Per-schema - Compromesso isolamento/operabilità.
• Per-DB/cluster (Silo): per VIP/regolabili.

Cache: prefissi di chiavi «tenant: {id}:...», TTL in base ai piani, protezione da cache-stamped (lock/early refresh).

Logi/metadati: Alias completo PII, filtri per «tenant _ id», disattivazione di «pendenza» dei fogli dei vari affittuari.

5) Limitazione del traffico e delle operazioni

Meccaniche di base

Token Bucket: picchi antialiasing, parametrizzazione «rate »/« burst».
Leaky Bucket - Stabilizzazione throughput.
Fissed Window/Sliding Window: quote semplici/precise per finestra di tempo.
Concurrency limits: caps per query simultanee/jobs.

Dove applicare

Al limite (gateway API L7) - Protezione di base e guasto rapido.
Nel cuore (servizi/code) - per il secondo tracciato e il «fair share».

Criteri

Per tenante/piano/endpoint/tipo di operazione (API pubbliche, esposizione pesante, admine-azione).
Priority-aware: VIP ottiene più «burst» e peso durante l'arbitraggio.
Idempotency-keys per i retrai sicuri.

Esempio di profili (concetti)

Starter: 50 req/s, burst 100, 2 esportazioni parallele.
Business: 200 req/s, burst 400, 5 esportazioni.
Enterprise/VIP: 1000 req/s, burst 2000, worker dedicati.

6) Quote e pianificazione equa (fairness)

Quote di risorse: archiviazione, oggetti, messaggi/min, operazioni/ora, dimensioni delle code.
Weighted Fair Queuing/Deficit Round Robin: accesso «ponderato» ai worker condivisi.
Per-tenant worker pools: isolamento rigido per i clienti rumorosi/critici.
Admision control: guasto/degrado prima dell'esecuzione quando le quote sono esaurite.
Backoff + jitter - Ritardi esponenziali per non sincronizzare i picchi.

7) Osservabilità e billing per tenant

I tag obbligatori sono «tenant _ id», «plan», «region», «endpoint», «status».
SLI/SLO per tenant: p95/p99 latency, error rate, availability, utilization, saturation.
Contatori per operazioni/byte/secondi CPU, aggregatore di fatture.
Idampotenza billing: snapshot al confine, protezione da doppi prelievi/perdita di eventi.
I dashboard sono segmenti VIP/regolabili/nuovi affittuari.

8) Incidenti, degrado e DR «per affittacamere»

Füsing'tenant _ id ': disattivazione di emergenza/trottling di un particolare inquilino senza influire sugli altri.
Modalità Graceful Delradation: modalità read-only, code per la cassetta di sabbia, operazioni rinviate.
RTO/RPO per tenant: obiettivi di ripristino e perdita per ogni piano.
Esercizi: «game days» regolari con disattivazione dell'affittuario rumoroso e controllo DR.

9) Conformità (residency, privacy)

Pinning tenante per la regione; Regole chiare per i flussi cross-regionali.
Controllo dell'accesso a chiavi/dati, registrazione delle attività admine.
Gestione dei dati per tenant e delle esportazioni.

10) Mini-arbitro: come mettere insieme

Flusso di query

1. Edge (API-gateway) - TLS è in grado di estrarre «tenant _ id» la validazione del token in modo da applicare rate/quotas in modo da le roulotte.
2. Polizze motore: contesto'tenant _ id/plan/features ', soluzione di percorso e limiti.
3. Utilità: Controllo dei diritti + etichetta'tenant _ id '. Utilizzo del database RLS con la cache del prefisso.
4. Raccolta Usage: contatori di transazioni/byte, aggregatore di → →.

Dati

Schema/database di strategia (row-level/per-schema/per-DB).
KMS: chiavi per locatore, rotazione, crypto-shredding durante l'eliminazione.

Calcoli

Code di bilancia, pool di worker per tenant, caps per concertency.
Autocaling per metriche per tenente.

11) Pseudo-criteri (per orientamento)

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) Foglio di assegno prima della vendita

• Un'unica fonte di verità «tenant _ id»; si scorre e si logora ovunque.
• RLS/ACL abilitato a livello di database + controllo di servizio (doppia serratura).
• Chiavi di crittografia per tenant, documentato rotazione/rimozione (crypto-shredding).
• Limiti/quote al confine e all'interno; sono stati testati picchi e «burst».
• Fair-queuing e/o worker dedicati per VIP; caps на concurrency.
• SLO e alert per tenanti; Dashboard per segmenti.
• La raccolta Usage è idipotente; La fusione con il biglietto è stata verificata.
• DR/incidenti localizzati fino all'inquilino; «tenant _ id» funziona.
• Cache/login suddivisi per affittacamere; PII mascherata.
• Le procedure di migrazione/backup/esportazione sono di tipo paramentale.

13) Errori tipici

RLS disattivato/disattivato dall'utente «di servizio» - Rischio di perdita.
Un unico limitatore globale di noisy neighbor e una violazione dello SLO.
Cache/code condivise senza prefissi per l'intersezione dei dati.
Billing fa i conti con le unità che si perdono ai picchi.
La mancanza di fusing a forma di serbatoio è una caduta a cascata.
Migrazioni «in un colpo solo» senza possibilità di bloccare'tenant _ id '.

14) Scelta rapida della strategia

Regolabili/VIP: Silo-Data (per-DB), worker dedicati, quote rigorose e residency.
SaaS di massa: Shared-schema + RLS, limiti forti al confine, fair-queuing all'interno.
Carico «rumoroso/pulsante»: grandi «burst» + rigidi concurrency-caps, backpressure e priorità dei piani.

Conclusione

L'isolamento dei tenenti e i limiti riguardano i confini e la giustizia. Nitide'tenant _ id 'attraverso stack, RLS e crittografia dei dati, limitazione e quote al confine e al cuore, pianificazione equa, osservabilità e localizzazione degli incidenti, tutto questo insieme fornisce sicurezza, qualità prevedibile e un biglietto trasparente per ogni inquilino, anche con la crescita aggressiva della piattaforma.