Isolamento dei dati tra ambienti

Ogni ambiente KeenAuth (development, staging, production in ciascuno dei tuoi progetti) è un tenant separato. Utenti, organizzazioni, applicazioni, sessioni, chiavi, log ed eventi di un ambiente non sono mai visibili a un altro ambiente, incluso un altro ambiente del tuo stesso account. Questa pagina spiega come viene applicato questo confine.

Due linee di difesa indipendenti

Gli ambienti condividono uno schema di database, e ogni riga che appartiene a un ambiente riporta l'identificativo di quell'ambiente. L'isolamento è applicato due volte, e perché i dati attraversino il confine devono fallire entrambi i controlli nello stesso momento:

Ambito di ambiente tipizzato nell'applicazione. Ogni richiesta viene associata esattamente a un ambiente a partire dal suo nome host o dalla sua credenziale, prima che venga letto qualsiasi dato. Il codice che legge o scrive dati di ambiente non può aprire una transazione di database senza quell'ambito; una chiamata senza di esso viene rifiutata prima che la query venga eseguita.
Row-level security di PostgreSQL. Ogni tabella che contiene dati di ambiente ha la row-level security abilitata e forzata, quindi la policy si applica anche al proprietario della tabella. Ogni transazione imposta l'ambiente corrente, e una riga è visibile solo quando il suo ambiente corrisponde. Una transazione che non ha impostato un ambiente non vede alcuna riga. Nessun ruolo applicativo o di manutenzione può aggirare la row-level security.

Ogni tabella con ambito di ambiente inizia la sua chiave primaria e i suoi indici con l'identificativo dell'ambiente, così la condizione di isolamento non aggiunge una ricerca separata alle query.

Ricerche per token o chiave

Alcune richieste arrivano con un solo valore segreto, per esempio un codice di autorizzazione, un refresh token o una chiave API. KeenAuth individua questo valore tramite una ricerca basata solo sul digest e poi confronta l'ambiente del record memorizzato con quello della richiesta. Se sono diversi, il valore viene trattato come non valido.

Cosa vedi quando superi il confine

Tentativo	Risposta
Leggere una risorsa che appartiene a un altro ambiente	`404 Not Found`; la risposta non rivela che la risorsa esiste
Usare un access token emesso da un altro ambiente	`401 Unauthorized`; ogni ambiente ha il proprio issuer e le proprie chiavi di firma (JWKS)
Autenticarsi con un client registrato in un altro ambiente	`invalid_client`

Oltre il database

Lo stesso confine si applica a ogni altro luogo in cui vivono dati di ambiente:

Cache: ogni chiave di cache inizia con l'identificativo dell'ambiente.
Eventi e job: ogni evento interno porta con sé il proprio ambiente, e i consumer impostano il proprio ambito di database a partire da esso; ogni job in coda porta con sé l'ambiente a cui appartiene.
Chiavi: le chiavi di cifratura e di firma sono separate per ciascun ambiente.
Log: le righe di log riportano l'ambiente come campo, e la API dei log di ambiente restituisce solo le voci dell'ambiente che stai chiamando.
Lavoro in background: i job di manutenzione (pulizia per retention, cancellazioni) vengono eseguiti ambiente per ambiente, ciascuno nella propria transazione con ambito.

Spostare la configurazione da un ambiente a un altro (promozione della configurazione) copia solo le impostazioni. I segreti e i dati degli utenti finali o delle organizzazioni non fanno mai parte di un pacchetto di promozione.

Come viene testato l'isolamento

Una suite di test di isolamento tra tenant viene eseguita nella continuous integration di KeenAuth e blocca una modifica quando fallisce. Verifica che:

ogni tabella che contiene dati di ambiente abbia la row-level security abilitata e forzata;
ogni superficie API restituisca 404 o 401 per risorse, token e client di un altro ambiente;
i job in background e la pipeline di log ed eventi tocchino solo l'ambiente indicato nel loro input.

Un controllo dello schema rifiuta anche una nuova tabella di dati di ambiente priva della colonna dell'identificativo di ambiente.