Sicurezza
Una sicurezza che sa di ospitalità.
Un identity provider vale quanto i muri tra i suoi tenant e la cura con cui tratta i segreti. Ecco come è costruito Usher Identity. Descriviamo ciò che fa il software; non dichiariamo alcuna certificazione.
Architettura
Domini separati, reti separate.
Le pagine di Usher Identity e l’issuer di ogni cliente risiedono su domini registrabili diversi. I database stanno su una rete che non può raggiungere internet, e l’unica via d’uscita è un proxy che controlla dove si sta andando.
- Caddy termina il TLS per ogni host e rimuove le intestazioni che solo i servizi di Usher Identity possono impostare.
- Il livello di autenticazione risponde per ogni ambiente, distinguendoli dall’host; nulla viene messo in cache per un host e servito a un altro.
- Ogni servizio si collega a Valkey con un proprio utente, limitato alle proprie chiavi. Non esiste un utente predefinito.
- Le istruzioni che contengono token e codici non vengono mai scritte nel log del database insieme ai loro valori.
Internet
Le persone, le tue app, i tuoi server
L’edge
Caddy: TLS, HSTS, rimuove le intestazioni interne
usheridentity.com
Sito e Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
Livello di autenticazione
Issuer e Lobby di ogni ambiente
Rete dei dati · nessuna via d’uscita
Postgres
Uno schema per ambiente
Valkey
Ogni servizio limitato alle proprie chiavi
L’unica via d’uscita
Proxy di uscita
Per ogni URL fornito da un cliente
Discovery, JWKS, logout
Solo indirizzi pubblici
Isolamento
Niente di importante in comune.
Ogni ambiente di un progetto ha il proprio schema Postgres, le proprie chiavi di firma e i propri segreti sigillati con la propria chiave dei dati. Il suo issuer è un host sul dominio dei tenant e i suoi cookie sono host-only, quindi un browser non invia mai il cookie di un ambiente a un altro.
usheridentity.com
Il sito, Usher Identity Console, gli account Usher Identity
*.usherid.com
Un issuer per ambiente, su un dominio separato
Utenti, sessioni e token risiedono in uno schema creato per questo ambiente. Le query vengono eseguite su quello schema, mai su una tabella condivisa con una colonna tenant.
Copia il client secret Google sigillato di Acme (produzione) in Northwind (produzione).
Cifratura dei dati inattivi
Cifratura a busta, legata al suo posto.
I segreti che affidi a Usher Identity sono sigillati con AES-256-GCM sotto una chiave dei dati che appartiene a un solo ambiente. Le chiavi dei dati sono a loro volta cifrate da una chiave master con versioni, conservata fuori dal database.
- Chiavi dei dati per ambiente
- Compromettere la chiave dei dati di un ambiente non rivela nulla su quella di un altro.
- Vincolo AAD
- L’ambiente e lo scopo sono vincolati in ogni testo cifrato, quindi un valore non può essere spostato tra righe o tenant.
- Chiavi con versioni
- Ogni valore sigillato registra la versione della chiave con cui è stato creato, così le chiavi si possono ruotare e i vecchi valori cifrare di nuovo.
- Autenticata
- Grazie al tag di GCM, un valore manomesso non si apre, invece di decifrarsi in qualcos’altro.
Chiave master
Conservata fuori dal database, con versioni
Chiave dei dati, una per ambiente
Cifrata dalla chiave master
Il segreto
Sigillato con AES-256-GCM sotto la chiave dei dati
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
Pratiche
I dettagli, curati con attenzione.
Password, se le usi
Sottoposte a hash con Argon2id al costo raccomandato da OWASP (19 MiB, due passaggi), con un limite a quante elaborazioni possono girare insieme, così un’ondata di accessi non può mettere fuori uso il servizio. Le nuove password vengono confrontate con le violazioni note tramite la range API di Have I Been Pwned, che vede solo un breve prefisso dell’hash della password. La lunghezza minima predefinita è di 12 caratteri.
Niente di salvato che si possa riutilizzare
Client secret, token, token dei magic link e codici via email sono conservati come hash. I codici di backup sono cifrati. Un codice di autorizzazione dura cinque minuti; un codice via email consente tre tentativi.
Limiti di frequenza su ogni porta
Accesso, registrazione, codici via email, magic link, reimpostazione della password e verifiche del secondo fattore hanno ciascuno il proprio limite: per esempio, dieci accessi con password al minuto e cinque codici via email ogni dieci minuti.
Una Content-Security-Policy rigorosa
Ogni pagina della Lobby riceve un nonce nuovo e una policy costruita intorno a esso: vengono eseguiti solo gli script di questa origine che portano il nonce, i moduli inviano dati solo alla stessa origine e gli altri siti non possono incorporare la pagina in un frame.
Un registro di controllo affidabile
Le modifiche a spazi di lavoro, progetti e ambienti vengono scritte in un registro di sola aggiunta, in cui ogni voce è concatenata con un hash a quella precedente, così una voce modificata o mancante si nota.
Un proxy di uscita per gli URL dei clienti
Ogni richiesta che Usher Identity fa a un indirizzo fornito da un cliente (OIDC discovery, JWKS, logout back-channel) esce attraverso un unico proxy. Risolve il nome una sola volta, rifiuta gli indirizzi privati, di loopback, link-local e dei metadati cloud, e si collega all’indirizzo che ha verificato, così il DNS rebinding non può trasformare l’URL di un cliente in uno interno.
Handle che non vengono mai assegnati due volte
L’handle di un ambiente di produzione è la prima etichetta del suo issuer. A Console si accede solo su invito, una Lobby segnalata per phishing viene sospesa, e un handle già usato non viene mai riassegnato, perché le vecchie app potrebbero ancora fidarsi dei suoi token.
Sessioni che finiscono quando lo decidi tu
Usher Identity verifica le proprie sessioni a ogni richiesta invece di fidarsi di una copia in cache, quindi una sessione che chiudi termina subito. I token di accesso hanno vita breve (dieci minuti per impostazione predefinita) e la tua API può farne l’introspezione.
Divulgazione responsabile
Hai trovato qualcosa? Dillo prima a noi.
Se pensi di aver trovato un problema di sicurezza in Usher Identity, ci farebbe piacere saperlo, e lavoreremo con te per risolverlo.
- Cosa hai trovato, dove e come riprodurlo.
- Cosa potrebbe farci qualcuno, per quanto ne sai.
- Come possiamo contattarti, e se desideri un riconoscimento pubblico.
Esegui i test solo su ambienti di tua proprietà, non accedere ai dati di altre persone e dacci un tempo ragionevole per risolvere il problema prima di renderlo pubblico. Per segnalare una pagina che si spaccia per un accesso Usher Identity, vedi Segnala un abuso.