TLS, l’accesso alla rete e i privilegi SQL rispondono a domande diverse
Cifrare una connessione, ammettere un’origine e concedere una tabella sono tre decisioni. Percorrerle in ordine prima di chiedere se TLS può sostituire una VPN.
Qualcuno propone di consegnare a un cliente un accesso PostgreSQL perché una nota spese viaggi cifrata da un capo all’altro. Un amministratore di basi di dati ha bisogno di una vera sessione SQL, e qualcun altro propone invece un modulo web. Entrambe le proposte risolvono il problema sbagliato, perché nessuna è partita dall’operazione che il cliente esegue davvero. Percorrere le tre decisioni in ordine e la domanda se TLS possa sostituire una VPN si risponde da sola.
Partire dall’operazione che serve al cliente
Annotare che cosa il cliente deve ottenere. Inviare una nota spese, leggere una riga di un report ed eseguire una query estemporanea sono tre operazioni diverse con tre profili di rischio diversi.
Poi annotare chi fa la richiesta. Un cliente, un agente di supporto e un amministratore non sono intercambiabili anche quando toccano la stessa tabella. La differenza decide quanto del linguaggio di interrogazione il cliente debba mai vedere.
La coppia di risposte decide l’interfaccia. Tutto quel che segue è implementazione, e la maggior parte delle discussioni sulla cifratura sono in realtà discussioni su quale interfaccia è stata scelta.
Tre controlli, tre decisioni
TLS autenticato protegge la connessione e decide quali identità TLS sono accettate. L’accesso alla rete decide quali origini possono raggiungere l’ascoltatore. L’autorizzazione del database decide quali oggetti e azioni un ruolo può usare.
Nessuno dei tre sostituisce gli altri, come la tabella rende esplicito.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Leggere la riga su cui si conta prima di rimuoverne un’altra. La maggior parte di questi progetti fallisce perché un controllo è stato dato per scontato invece che configurato.
L’SQL diretto lascia la politica del database al comando
Con una connessione diretta approvata, conservare sia la verifica dell’identità del servizio sia la politica di accesso prevista. Attivare TLS rende disponibili le connessioni cifrate; non rifiuta quelle non cifrate, a meno che la configurazione di accesso lo richieda tramite voci hostssl.
Vale la pena controllare quella distinzione nella configurazione in esecuzione e non in un modello. Un server che offre TLS e accetta testo in chiaro non è il progetto che la maggior parte delle persone crede di avere distribuito. Leggere le regole di accesso e vedere quali voci lo richiedono davvero. Quell’unico controllo separa un server capace di cifrare da uno solo cifrato.
Usare ruoli con soli i privilegi che il lavoro richiede, e riesaminare proprietà, appartenenza ereditata e permessi concessi in modo ampio. Il modello dei privilegi di PostgreSQL è il confine di autorità per gli oggetti del database.
Una VPN può limitare quali dispositivi raggiungono il servizio prima che avvenga l’autenticazione del database, e un gateway di accesso può fare qualcosa di simile. Nessuno dei due elimina la necessità di mantenere il componente esposto, gestire le credenziali e limitare l’uso delle risorse.
I certificati client sono una credenziale, non un ACL
Un certificato client può aggiungere un requisito al momento della connessione. L’impostazione clientcert può richiedere un certificato fidato e, nella modalità più severa, una relazione tra il nome del certificato e l’utente del database.
Questa è una credenziale più forte. Non è un elenco di autorizzazione, e non rende invisibile il server, perché il componente che accetta la connessione elabora comunque traffico di rete e una stretta di mano. Trattare un certificato come un elenco di accesso lascia intatti i permessi reali. Tende anche ad ampliare la distribuzione dei certificati, il che crea il problema successivo.
Un certificato forte legato a un ruolo con privilegi eccessivi produce un amministratore ben autenticato. Controllare il ruolo prima di celebrare il certificato.
Scegliere l’interfaccia più stretta quando si adatta
Per una nota spese, un endpoint applicativo che accetta la nota, applica le regole di business e restituisce il risultato consentito di quell’utente rappresenta l’operazione meglio di un account SQL generico.
L’applicazione usa poi la propria identità ristretta nel database, e il cliente non riceve mai un linguaggio di interrogazione come funzionalità. È una superficie più piccola con meno modi di sbagliare.
Questa è un’opzione di progetto e non l’affermazione che il codice applicativo sia automaticamente più sicuro. Quel codice deve autenticare i suoi chiamanti, autorizzare ogni azione e validare il proprio input, e i suoi permessi nel database contano ancora.
L’SQL diretto resta corretto per le persone e gli strumenti il cui lavoro approvato lo richiede. Qualificare quel progetto con ruoli, perimetro di rete e limiti operativi, e lasciare che gli altri clienti mantengano l’interfaccia più stretta. Mescolare le due popolazioni in un solo ruolo è dove iniziano le discussioni.