TLSek, sareko sarrerak eta SQL baimenek galdera desberdinei erantzuten diete
Konexio bat enkriptatzea, iturri bat onartzea eta taula bat ematea hiru erabaki dira. Egin horiek ordenan TLSek VPN bat ordezkatu dezakeen galdetu aurretik.
Norbaitek bezeroari PostgreSQL saio-hasiera bat ematea proposatzen du, gastu-eskaera bat muturretik muturrera enkriptatuta joan dadin. Datu-baseko administratzaileak benetako SQL saio bat behar du, eta beste norbaitek web formulario bat proposatzen du horren ordez. Bi proposamenek problema okerra konpontzen dute, ez baitziren bezeroak benetan egiten duen eragiketatik abiatu. Egin hiru erabakiak ordenan eta TLSek VPN bat ordezkatu dezakeen galderak berak erantzungo du.
Hasi bezeroak behar duen eragiketatik
Idatzi bezeroak zer lortu behar duen. Eskaera bat bidaltzea, txosten baten errenkada bat irakurtzea eta unean uneko kontsulta bat exekutatzea hiru eragiketa desberdin dira, hiru arrisku-profil desberdinekin.
Gero idatzi nork egiten duen eskaera. Bezero bat, laguntza-agente bat eta administratzaile bat ez dira trukagarriak taula bera ukitzen dutenean ere. Aldaerak erabakitzen du zenbat kontsulta-lengoaia ikusi behar lukeen bezeroak.
Erantzun-pareak interfazea erabakitzen du. Hortik aurrerako guztia inplementazioa da, eta enkriptatzeari buruzko eztabaida gehienak, egiaz, zein interfaze aukeratu zen jakiteko eztabaidak dira.
Hiru kontrol, hiru erabaki
Autentifikatutako TLSek konexioa babesten du eta zein TLS identitate onartzen diren erabakitzen du. Sareko sarrerak erabakitzen du zein iturrik irits daitezkeen entzulearengana. Datu-basearen baimenak erabakitzen du rol batek zein objektu eta ekintza erabil ditzakeen.
Hiruretariko batek ere ez du bestea ordezkatzen, taulak argi erakusten duenez.
| 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 |
Irakurri oinarritzat duzun errenkada beste bat kendu aurretik. Diseinu horietako gehienek huts egiten dute kontrol bat konfiguratu beharrean suposatu zelako.
SQL zuzenak datu-basearen politika mantentzen du buruan
Onartutako konexio zuzen batekin, mantendu bai zerbitzuaren identitatearen egiaztapena bai aurreikusitako sarbide-politika. TLS pizteak konexio enkriptatuak erabilgarri jartzen ditu; ez ditu enkriptatu gabekoak baztertzen sarbide-konfigurazioak hostssl sarreren bidez hala eskatzen ez badu.
Aldaera hori exekuzioko konfigurazioan egiaztatzea merezi du, ez txantiloi batean. TLS eskaintzen duen eta testu arrunta onartzen duen zerbitzari bat ez da jende gehienak zabaldu uste duen diseinua. Irakurri sarbide-arauak eta ikusi zein sarrerek eskatzen duten benetan. Egiaztapen bakar horrek enkriptatzeko gai den zerbitzaria soilik enkriptatuta dagoenetik bereizten du.
Erabili lanak behar dituen pribilegioak soilik dituzten rolak, eta berrikusi jabetza, oinordetzan jasotako kidetza eta zabalki emandako baimenak. PostgreSQLren pribilegio-eredua da datu-baseko objektuen autoritate-muga.
VPN batek murriztu dezake zein gailuk iristen diren zerbitzura datu-basearen autentifikazioa gertatu aurretik, eta sarbide-pasabide batek antzeko zerbait egin dezake. Bietako batek ere ez du kentzen esposatutako osagaia mantentzeko, kredentzialak kudeatzeko eta baliabideen erabilera mugatzeko beharra.
Bezero-ziurtagiriak kredentziala dira, ez ACL bat
Bezero-ziurtagiri batek baldintza bat gehi dezake konexioaren unean. clientcert ezarpenak ziurtagiri fidagarri bat eska dezake eta, modu zorrotzenean, ziurtagiriaren izenaren eta datu-baseko erabiltzailearen arteko erlazioa.
Hori kredentzial sendoagoa da. Ez da baimen-zerrenda bat, eta ez du zerbitzaria ikusezin bihurtzen, konexioa onartzen duen osagaiak sare-trafikoa eta esku-ukaldi bat prozesatzen jarraitzen baitu. Ziurtagiri bat sarbide-zerrenda gisa tratatzeak benetako baimenak ukitu gabe uzten ditu. Ziurtagirien banaketa zabaltzeko joera ere badu, eta horrek hurrengo arazoa sortzen du.
Pribilegio gehiegiko rol bati lotutako ziurtagiri sendo batek ondo autentifikatutako administratzaile bat sortzen du. Egiaztatu rola ziurtagiria ospatu aurretik.
Aukeratu interfaze estuena egokia denean
Gastu-eskaera baterako, eskaera onartzen duen, negozio-arauak betearazten dituen eta erabiltzaile horren emaitza baimendua itzultzen duen aplikazio-muturreko puntu batek eragiketa hobeto adierazten du SQL kontu orokor bat baino.
Gero aplikazioak bere datu-baseko identitate mugatua erabiltzen du, eta bezeroak ez du inoiz kontsulta-lengoaiarik jasotzen ezaugarri gisa. Hori gainazal txikiagoa da, oker egoteko modu gutxiagorekin.
Hau diseinu-aukeraketa bat da, eta ez aplikazio-kodea automatikoki seguruagoa dela dioen baieztapena. Kode horrek bere deitzaileak autentifikatu, ekintza bakoitza baimendu eta bere sarrera baliozkotu behar ditu, eta bere datu-baseko baimenek oraindik garrantzia dute.
SQL zuzena egokia izaten jarraitzen du lan onartuak hala eskatzen dien pertsonentzat eta tresnentzat. Kalifikatu diseinu hori rolekin, sare-eremuarekin eta muga operatiboekin, eta utzi gainerako bezeroei interfaze estuena mantentzen. Bi populazioak rol bakarrean nahastea da eztabaidak hasten diren tokia.