TLS, sieťový vstup a oprávnenia SQL odpovedajú na rôzne otázky
Šifrovanie spojenia, vpustenie zdroja a udelenie tabuľky sú tri rozhodnutia. Prejdite ich v poradí, kým sa spýtate, či TLS môže nahradiť VPN.
Niekto navrhuje dať zákazníkovi prihlásenie do PostgreSQL, aby žiadosť o výdavok putovala šifrovane od začiatku do konca. Správca databázy potrebuje skutočnú reláciu SQL a niekto iný namiesto toho navrhuje webový formulár. Oba návrhy riešia nesprávny problém, pretože ani jeden nezačal pri operácii, ktorú klient skutočne vykonáva. Prejdite tri rozhodnutia v poradí a otázka, či TLS môže nahradiť VPN, si odpovie sama.
Začnite pri operácii, ktorú klient potrebuje
Zapíšte, čo má klient dosiahnuť. Podanie žiadosti, prečítanie jedného riadku správy a spustenie okamžitého dotazu sú tri rôzne operácie s tromi rôznymi rizikovými profilmi.
Potom zapíšte, kto žiadosť podáva. Zákazník, pracovník podpory a správca nie sú zameniteľní, aj keď sa dotýkajú tej istej tabuľky. Rozdiel určuje, koľko z dotazovacieho jazyka by mal klient vôbec vidieť.
Dvojica odpovedí určuje rozhranie. Všetko ďalšie je implementácia a väčšina sporov o šifrovaní sú v skutočnosti spory o to, ktoré rozhranie bolo zvolené.
Tri kontroly, tri rozhodnutia
Overené TLS chráni spojenie a určuje, ktoré identity TLS sa prijímajú. Sieťový vstup určuje, ktoré zdroje sa vôbec môžu dostať k počúvajúcemu procesu. Autorizácia v databáze určuje, ktoré objekty a akcie smie rola používať.
Žiadna z troch nenahrádza ostatné, čo tabuľka ukazuje výslovne.
| 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 |
Prečítajte si riadok, na ktorý sa spoliehate, skôr ako odstránite iný. Väčšina týchto návrhov zlyháva preto, že kontrola bola predpokladaná, a nie nakonfigurovaná.
Priame SQL necháva politiku databázy zodpovednú
Pri schválenom priamom spojení zachovajte overenie identity služby aj zamýšľanú politiku prístupu. Zapnutie TLS sprístupní šifrované spojenia; neodmieta nešifrované, ak to konfigurácia prístupu nevyžaduje cez položky hostssl.
Ten rozdiel stojí za kontrolu v bežiacej konfigurácii, nie v šablóne. Server, ktorý ponúka TLS a prijíma otvorený text, nie je návrh, o ktorom si väčšina myslí, že ho nasadila. Prečítajte pravidlá prístupu a pozrite, ktoré položky to skutočne vyžadujú. Táto jediná kontrola oddeľuje server schopný šifrovania od servera iba šifrovaného.
Používajte roly len s oprávneniami, ktoré práca potrebuje, a revidujte vlastníctvo, zdedené členstvo a široko udelené oprávnenia. Model oprávnení PostgreSQL je hranicou právomoci pre objekty databázy.
VPN môže obmedziť, ktoré zariadenia sa dostanú k službe pred autentizáciou v databáze, a prístupová brána môže urobiť niečo podobné. Ani jedno neodstraňuje potrebu udržiavať vystavený komponent, spravovať prihlasovacie údaje a obmedzovať využitie zdrojov.
Klientske certifikáty sú údaj, nie ACL
Klientsky certifikát môže pri pripojení pridať požiadavku. Nastavenie clientcert môže vyžadovať dôveryhodný certifikát a v prísnejšom režime vzťah medzi názvom certifikátu a používateľom databázy.
To je silnejší údaj. Nie je to zoznam autorizácie a nerobí server neviditeľným, pretože komponent prijímajúci spojenie stále spracúva sieťovú prevádzku a handshake. Zaobchádzanie s certifikátom ako so zoznamom prístupu necháva skutočné oprávnenia nedotknuté. Má tiež tendenciu rozširovať distribúciu certifikátov, čo vytvára ďalší problém.
Silný certifikát pripojený k role s nadmernými oprávneniami vytvára dobre overeného správcu. Skontrolujte rolu, kým certifikát oslávite.
Vyberte užšie rozhranie, keď sa hodí
Pre žiadosť o výdavok aplikačný koncový bod, ktorý žiadosť prijme, vynúti obchodné pravidlá a vráti povolený výsledok daného používateľa, predstavuje operáciu lepšie než všeobecný účet SQL.
Aplikácia potom používa vlastnú obmedzenú identitu v databáze a zákazník nikdy nedostane dotazovací jazyk ako funkciu. To je menší povrch s menším počtom spôsobov, ako urobiť chybu.
Toto je možnosť návrhu, nie tvrdenie, že aplikačný kód je automaticky bezpečnejší. Ten kód musí overovať svojich volajúcich, autorizovať každú akciu a validovať svoj vstup a jeho vlastné oprávnenia v databáze stále záležia.
Priame SQL zostáva správne pre ľudí a nástroje, ktorých schválená práca to vyžaduje. Kvalifikujte ten návrh rolami, sieťovým rozsahom a prevádzkovými limitmi a ostatným klientom nechajte užšie rozhranie. Miešanie oboch skupín v jednej role je miesto, kde sa spory začínajú.