TLS, mrežni pristup i SQL privilegije odgovaraju na različita pitanja
Šifriranje veze, puštanje izvora i dodjela tablice tri su odluke. Prođite ih redom prije nego što pitate može li TLS zamijeniti VPN.
Neko predlaže da se kupcu da PostgreSQL prijava kako bi zahtjev za trošak putovao šifriran od početka do kraja. Administratoru baze podataka treba prava sesija SQL, a neko drugi umjesto toga predlaže web obrazac. Oba prijedloga rješavaju pogrešan problem, jer nijedan nije počeo od radnje koju klijent zapravo izvodi. Prođite tri odluke redom i pitanje o tome može li TLS zamijeniti VPN samo će se odgovoriti.
Pođite od radnje koja klijentu treba
Zapišite što klijent mora postići. Podnošenje zahtjeva, čitanje jednog retka izvještaja i pokretanje ad hoc upita tri su različite radnje s tri različita profila rizika.
Zatim zapišite ko upućuje zahtjev. Kupac, agent podrške i administrator nisu zamjenjivi čak i kada diraju istu tablicu. Razlika odlučuje koliko upitnog jezika klijent uopće treba vidjeti.
Par odgovora odlučuje o sučelju. Sve nakon toga je implementacija, a većina rasprava o šifriranju zapravo su rasprave o tome koje je sučelje odabrano.
Tri kontrole, tri odluke
Autentificirani TLS štiti vezu i odlučuje koje se TLS identitete prihvaćaju. Mrežni pristup odlučuje koji izvori uopće mogu doći do slušatelja. Autorizacija u bazi podataka odlučuje koje objekte i radnje uloga smije koristiti.
Nijedna od tri ne zamjenjuje ostale, što tablica izričito pokazuje.
| 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 |
Pročitajte redak na koji se oslanjate prije nego što uklonite drugi. Većina ovakvih dizajna propada jer je kontrola pretpostavljena, a ne konfigurirana.
Izravni SQL zadržava politiku baze podataka na čelu
Uz odobrenu izravnu vezu zadržite i provjeru identiteta usluge i predviđenu politiku pristupa. Uključivanje TLS-a čini šifrirane veze dostupnima; ono ne odbija nešifrirane osim ako konfiguracija pristupa to ne zahtijeva kroz hostssl unose.
Tu razliku vrijedi provjeriti u pokrenutoj konfiguraciji, a ne u predlošku. Poslužitelj koji nudi TLS i prihvaća običan tekst nije dizajn za koji većina ljudi misli da ga je postavila. Pročitajte pravila pristupa i pogledajte koji unosi to doista zahtijevaju. Ta jedna provjera razdvaja poslužitelj sposoban za šifriranje od poslužitelja samo sa šifriranjem.
Koristite uloge samo s privilegijama koje posao treba i pregledajte vlasništvo, naslijeđeno članstvo i široko dodijeljena dopuštenja. Model privilegija PostgreSQL granica je ovlasti za objekte baze podataka.
VPN može ograničiti koje naprave dolaze do usluge prije autentifikacije u bazi podataka, a pristupni gateway može učiniti nešto slično. Nijedno ne uklanja potrebu za održavanjem izložene komponente, upravljanjem vjerodajnicama i ograničavanjem korištenja resursa.
Klijentski certifikati su vjerodajnica, a ne ACL
Klijentski certifikat može dodati uvjet u trenutku povezivanja. Postavka clientcert može zahtijevati pouzdan certifikat i, u strožem načinu rada, vezu između imena certifikata i korisnika baze podataka.
To je jača vjerodajnica. To nije popis autorizacije i ne čini poslužitelj nevidljivim, jer komponenta koja prihvaća vezu i dalje obrađuje mrežni promet i rukovanje. Tretiranje certifikata kao popisa pristupa ostavlja stvarne dozvole netaknutima. Također obično proširuje distribuciju certifikata, što stvara sljedeći problem.
Snažan certifikat vezan uz ulogu s prekomjernim ovlastima daje dobro autentificiranog administratora. Provjerite ulogu prije nego što proslavite certifikat.
Odaberite uže sučelje kada odgovara
Za zahtjev za trošak aplikacijska krajnja točka koja prihvaća zahtjev, provodi poslovna pravila i vraća dopušteni rezultat tog korisnika predstavlja radnju bolje od općeg računa SQL.
Aplikacija zatim koristi vlastiti ograničeni identitet u bazi podataka, a kupac nikada ne dobiva upitni jezik kao značajku. To je manja površina s manje načina da se pogriješi.
Ovo je dizajnerska opcija, a ne tvrdnja da je aplikacijski kod automatski sigurniji. Taj kod mora autentificirati svoje pozivatelje, autorizirati svaku radnju i provjeriti svoj ulaz, a njegove vlastite dozvole u bazi podataka i dalje su važne.
Izravni SQL ostaje ispravan za ljude i alate čiji odobreni posao to zahtijeva. Uvjetujte taj dizajn ulogama, mrežnim opsegom i operativnim granicama, a ostalim klijentima ostavite uže sučelje. Miješanje dviju populacija u jednoj ulozi mjesto je gdje rasprave počinju.