TLS, l’accés a la xarxa i els privilegis SQL responen a preguntes diferents
Xifrar una connexió, admetre una font i concedir una taula són tres decisions. Recorreu-les per ordre abans de preguntar si TLS pot substituir una VPN.
Algú proposa donar a un client un inici de sessió de PostgreSQL perquè una sol·licitud de despesa viatgi xifrada d’extrem a extrem. Un administrador de bases de dades necessita una sessió SQL real, i algú altre proposa en canvi un formulari web. Totes dues propostes resolen el problema equivocat, perquè cap no va partir de l’operació que el client fa realment. Recorreu les tres decisions per ordre i la pregunta sobre si TLS pot substituir una VPN es respon sola.
Partiu de l’operació que necessita el client
Escriviu què ha d’aconseguir el client. Enviar una sol·licitud, llegir una fila d’un informe i executar una consulta ad hoc són tres operacions diferents amb tres perfils de risc diferents.
Després escriviu qui fa la petició. Un client, un agent de suport i un administrador no són intercanviables encara que toquin la mateixa taula. La diferència decideix quant del llenguatge de consultes ha de veure mai el client.
La parella de respostes decideix la interfície. Tot el que ve després és implementació, i la majoria de discussions sobre xifratge són en realitat discussions sobre quina interfície s’ha triat.
Tres controls, tres decisions
TLS autenticat protegeix la connexió i decideix quines identitats TLS s’accepten. L’accés a la xarxa decideix quines fonts poden arribar a l’oient. L’autorització de la base de dades decideix quins objectes i accions pot usar un rol.
Cap dels tres substitueix els altres, cosa que la taula fa explícita.
| 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 |
Llegiu la fila en què us baseu abans de treure’n una altra. La majoria d’aquests dissenys fallen perquè un control es va suposar en lloc de configurar-se.
SQL directe manté la política de la base de dades al comandament
Amb una connexió directa aprovada, manteniu tant la verificació de la identitat del servei com la política d’accés prevista. Activar TLS fa disponibles les connexions xifrades; no rebutja les no xifrades tret que la configuració d’accés ho digui mitjançant entrades hostssl.
Val la pena comprovar aquesta distinció a la configuració en execució i no en una plantilla. Un servidor que ofereix TLS i accepta text pla no és el disseny que la majoria de la gent creu haver desplegat. Llegiu les regles d’accés i vegeu quines entrades ho exigeixen realment. Aquesta única comprovació separa un servidor capaç de xifrar d’un servidor només xifrat.
Useu rols només amb els privilegis que la feina necessita, i reviseu la propietat, la pertinença heretada i els permisos concedits àmpliament. El model de privilegis de PostgreSQL és el límit d’autoritat per als objectes de la base de dades.
Una VPN pot restringir quins dispositius arriben al servei abans que passi l’autenticació de la base de dades, i una passarel·la d’accés pot fer una cosa semblant. Cap de les dues no elimina la necessitat de mantenir el component exposat, gestionar les credencials i limitar l’ús de recursos.
Els certificats de client són una credencial, no una ACL
Un certificat de client pot afegir un requisit en el moment de la connexió. El paràmetre clientcert pot exigir un certificat de confiança i, en el mode més estricte, una relació entre el nom del certificat i l’usuari de la base de dades.
Això és una credencial més forta. No és una llista d’autorització, i no fa invisible el servidor, perquè el component que accepta la connexió encara processa trànsit de xarxa i un intercanvi de salutació. Tractar un certificat com una llista d’accés deixa intactes els permisos reals. També tendeix a ampliar la distribució de certificats, cosa que crea el problema següent.
Un certificat fort adjunt a un rol amb privilegis excessius produeix un administrador ben autenticat. Reviseu el rol abans de celebrar el certificat.
Trieu la interfície més estreta quan encaixi
Per a una sol·licitud de despesa, un punt final d’aplicació que accepta la sol·licitud, aplica les regles de negoci i retorna el resultat permès d’aquell usuari representa l’operació millor que un compte SQL general.
L’aplicació fa servir després la seva pròpia identitat restringida a la base de dades, i el client mai no rep un llenguatge de consultes com a funcionalitat. Aquesta és una superfície més petita amb menys maneres d’equivocar-se.
Aquesta és una opció de disseny i no una afirmació que el codi d’aplicació sigui automàticament més segur. Aquest codi ha d’autenticar els seus cridaners, autoritzar cada acció i validar la seva entrada, i els seus propis permisos a la base de dades encara importen.
SQL directe continua sent correcte per a persones i eines la feina aprovada de les quals ho requereix. Qualifiqueu aquest disseny amb rols, abast de xarxa i límits operatius, i deixeu que els altres clients mantinguin la interfície més estreta. Barrejar les dues poblacions en un sol rol és on comencen les discussions.