TLS, accesul în rețea și privilegiile SQL răspund la întrebări diferite
Criptarea unei conexiuni, admiterea unei surse și acordarea unei tabele sunt trei decizii. Parcurgeți-le în ordine înainte de a întreba dacă TLS poate înlocui un VPN.
Cineva propune să i se dea unui client o autentificare PostgreSQL pentru ca o cerere de cheltuieli să călătorească criptat de la un capăt la altul. Un administrator de baze de date are nevoie de o sesiune SQL reală, iar altcineva propune în schimb un formular web. Ambele propuneri rezolvă problema greșită, pentru că niciuna nu a pornit de la operația pe care clientul o execută de fapt. Parcurgeți cele trei decizii în ordine și întrebarea dacă TLS poate înlocui un VPN se răspunde singură.
Începeți de la operația de care are nevoie clientul
Notați ce trebuie să realizeze clientul. Trimiterea unei cereri, citirea unui rând dintr-un raport și rularea unei interogări ad hoc sunt trei operații diferite cu trei profiluri de risc diferite.
Apoi notați cine face cererea. Un client, un agent de suport și un administrator nu sunt interschimbabili chiar dacă ating aceeași tabelă. Diferența decide cât din limbajul de interogare ar trebui să vadă vreodată clientul.
Perechea de răspunsuri decide interfața. Tot ce urmează este implementare, iar majoritatea dezbaterilor despre criptare sunt de fapt dezbateri despre ce interfață a fost aleasă.
Trei controale, trei decizii
TLS autentificat protejează conexiunea și decide ce identități TLS sunt acceptate. Accesul în rețea decide ce surse pot ajunge măcar la procesul care ascultă. Autorizarea în baza de date decide ce obiecte și acțiuni poate folosi un rol.
Niciunul dintre cele trei nu le înlocuiește pe celelalte, ceea ce tabelul arată explicit.
| 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 |
Citiți rândul pe care vă bazați înainte de a-l elimina pe altul. Majoritatea acestor proiecte eșuează pentru că un control a fost presupus în loc să fie configurat.
SQL direct lasă politica bazei de date responsabilă
Cu o conexiune directă aprobată, păstrați atât verificarea identității serviciului, cât și politica de acces prevăzută. Activarea TLS face disponibile conexiunile criptate; nu le respinge pe cele necriptate decât dacă configurația de acces cere asta prin intrări hostssl.
Această distincție merită verificată în configurația care rulează, nu într-un șablon. Un server care oferă TLS și acceptă text simplu nu este proiectul pe care majoritatea cred că l-au implementat. Citiți regulile de acces și vedeți ce intrări o cer cu adevărat. Acea singură verificare separă un server capabil de criptare de unul doar criptat.
Folosiți roluri doar cu privilegiile de care are nevoie munca, și revizuiți proprietatea, apartenența moștenită și permisiunile acordate larg. Modelul de privilegii PostgreSQL este limita de autoritate pentru obiectele bazei de date.
Un VPN poate restricționa ce dispozitive ajung la serviciu înainte de autentificarea în baza de date, iar un gateway de acces poate face ceva similar. Niciunul nu elimină nevoia de a întreține componenta expusă, de a gestiona acreditările și de a limita utilizarea resurselor.
Certificatele de client sunt o acreditare, nu o ACL
Un certificat de client poate adăuga o cerință la momentul conectării. Setarea clientcert poate cere un certificat de încredere și, în modul mai strict, o relație între numele certificatului și utilizatorul bazei de date.
Aceasta este o acreditare mai puternică. Nu este o listă de autorizare și nu face serverul invizibil, pentru că componenta care acceptă conexiunea procesează în continuare trafic de rețea și un handshake. Tratarea unui certificat ca listă de acces lasă permisiunile reale neatinse. Tinde, de asemenea, să lărgească distribuția certificatelor, ceea ce creează următoarea problemă.
Un certificat puternic atașat unui rol cu privilegii excesive produce un administrator bine autentificat. Verificați rolul înainte de a sărbători certificatul.
Alegeți interfața mai îngustă când se potrivește
Pentru o cerere de cheltuieli, un punct final de aplicație care acceptă cererea, aplică regulile de afaceri și returnează rezultatul permis al acelui utilizator reprezintă operația mai bine decât un cont SQL generic.
Aplicația folosește apoi propria identitate restricționată în baza de date, iar clientul nu primește niciodată un limbaj de interogare ca funcționalitate. Este o suprafață mai mică, cu mai puține moduri de a greși.
Aceasta este o opțiune de proiectare și nu afirmația că codul aplicației este automat mai sigur. Acel cod trebuie să își autentifice apelanții, să autorizeze fiecare acțiune și să își valideze intrarea, iar propriile permisiuni în baza de date contează în continuare.
SQL direct rămâne corect pentru oamenii și instrumentele al căror lucru aprobat îl cere. Calificați acel proiect cu roluri, acoperire de rețea și limite operaționale, și lăsați celelalte clienți să păstreze interfața mai îngustă. Amestecarea celor două populații într-un singur rol este locul unde încep dezbaterile.