Entry Proxy: l’identità del tenant viene risolta già al primo ingresso nel sistema; da essa viene selezionata la chiave di crittografia per documento del tenant. Solo le richieste verificate con un’assegnazione valida del tenant possono accedere ai dati di quel tenant — applicato per tutto il ciclo di vita della richiesta.

Database (isolamento dei tenant a livello di riga, applicato dall’applicazione): ogni record contiene un ID tenant e ogni query è limitata al tenant autenticato. Questo viene applicato nell’applicazione e verificato di continuo tramite test automatizzati tra tenant nella nostra pipeline CI e nelle revisioni del codice. La Row-Level Security nativa del database (Postgres RLS) è prevista come livello di controllo aggiuntivo. Tutte le query utilizzano esclusivamente metodi parametrizzati e tipizzati — l’iniezione SQL è quindi prevenuta per architettura.

Storage: I dati dei clienti in S3 sono criptati con chiavi KMS specifiche per tenant (CMK). Ogni tenant ha la propria chiave di crittografia, assegnata già al momento dell’ingresso tramite l’Entry Proxy.

Autorizzazione: I controlli di autorizzazione basati su oggetti applicano controlli di accesso (ACL) a livello di singoli documenti, casi e altre entità — inclusa la delega e la scadenza.

API: L’ID del tenant viene risolto dai claim JWT autenticati. Ogni endpoint applica un controllo di accesso basato sui ruoli.