TLS, hyrja në rrjet dhe privilegjet SQL u përgjigjen pyetjeve të ndryshme
Kriptimi i një lidhjeje, pranimi i një burimi dhe dhënia e një tabele janë tri vendime. Kaloni nëpër to me radhë përpara se të pyesni nëse TLS mund të zëvendësojë një VPN.
Dikush propozon t'i jepet një klienti një hyrje PostgreSQL që një kërkesë shpenzimi të udhëtojë e kriptuar nga fillimi në fund. Administratori i bazës së të dhënave ka nevojë për një sesion të vërtetë SQL, dhe dikush tjetër propozon në vend të kësaj një formular web. Të dyja propozimet zgjidhin problemin e gabuar, sepse asnjëra nuk filloi nga operacioni që klienti kryen në të vërtetë. Kaloni nëpër tri vendimet me radhë dhe pyetja nëse TLS mund të zëvendësojë një VPN përgjigjet vetë.
Filloni nga operacioni që i duhet klientit
Shkruani çfarë duhet të arrijë klienti. Dërgimi i një kërkese, leximi i një rreshti të një raporti dhe ekzekutimi i një pyetjeje të menjëhershme janë tri operacione të ndryshme me tri profile rreziku të ndryshme.
Pastaj shkruani kush e bën kërkesën. Një klient, një agjent mbështetjeje dhe një administrator nuk janë të këmbyeshëm edhe kur prekin të njëjtën tabelë. Diferenca përcakton sa e gjuhës së pyetjeve duhet të shohë ndonjëherë klienti.
Çifti i përgjigjeve përcakton ndërfaqen. Gjithçka pas kësaj është zbatim, dhe shumica e debateve për kriptimin janë në fakt debate për atë se cila ndërfaqe u zgjodh.
Tre kontrolle, tri vendime
TLS i vërtetuar mbron lidhjen dhe përcakton cilat identitete TLS pranohen. Hyrja në rrjet përcakton cilat burime mund të arrijnë fare dëgjuesin. Autorizimi në bazën e të dhënave përcakton cilat objekte dhe veprime mund të përdorë një rol.
Asnjëri nga të tre nuk zëvendëson të tjerët, gjë që tabela e bën të qartë.
| 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 |
Lexoni rreshtin ku mbështeteni përpara se të hiqni një tjetër. Shumica e këtyre modeleve dështojnë sepse një kontroll u supozua në vend që të konfigurohej.
SQL i drejtpërdrejtë e mban politikën e bazës së të dhënave përgjegjëse
Me një lidhje të drejtpërdrejtë të miratuar, mbani si verifikimin e identitetit të shërbimit ashtu edhe politikën e synuar të aksesit. Aktivizimi i TLS i bën lidhjet e kriptuara të disponueshme; nuk refuzon ato të pakriptuara nëse konfigurimi i aksesit nuk e kërkon këtë përmes hyrjeve hostssl.
Kjo diferencë ia vlen të kontrollohet në konfigurimin që po funksionon dhe jo në një shabllon. Një server që ofron TLS dhe pranon tekst të thjeshtë nuk është modeli që shumica mendojnë se kanë vendosur. Lexoni rregullat e aksesit dhe shihni cilat hyrje e kërkojnë vërtet. Ai kontroll i vetëm ndan një server të aftë për kriptim nga një server vetëm i kriptuar.
Përdorni role vetëm me privilegjet që kërkon puna, dhe rishikoni pronësinë, anëtarësimin e trashëguar dhe lejet e dhëna gjerësisht. Modeli i privilegjeve të PostgreSQL është kufiri i autoritetit për objektet e bazës së të dhënave.
Një VPN mund të kufizojë cilat pajisje arrijnë shërbimin përpara se të ndodhë vërtetimi në bazën e të dhënave, dhe një portë aksesi mund të bëjë diçka të ngjashme. Asnjëra nuk e heq nevojën për të mirëmbajtur komponentin e ekspozuar, për të menaxhuar kredencialet dhe për të kufizuar përdorimin e burimeve.
Certifikatat e klientit janë një kredencial, jo një ACL
Një certifikatë klienti mund të shtojë një kërkesë në momentin e lidhjes. Cilësimi clientcert mund të kërkojë një certifikatë të besuar dhe, në modalitetin më të rreptë, një lidhje midis emrit të certifikatës dhe përdoruesit të bazës së të dhënave.
Ky është një kredencial më i fortë. Nuk është një listë autorizimi, dhe nuk e bën serverin të padukshëm, sepse komponenti që pranon lidhjen përpunon ende trafik rrjeti dhe një shtrëngim duarsh. Trajtimi i një certifikate si listë aksesi i lë lejet reale të paprekura. Gjithashtu ka tendencë të zgjerojë shpërndarjen e certifikatave, gjë që krijon problemin e radhës.
Një certifikatë e fortë e lidhur me një rol me privilegje të tepërta prodhon një administrator të vërtetuar mirë. Kontrolloni rolin përpara se të festoni certifikatën.
Zgjidhni ndërfaqen më të ngushtë kur përshtatet
Për një kërkesë shpenzimi, një pikë fundore aplikacioni që pranon kërkesën, zbaton rregullat e biznesit dhe kthen rezultatin e lejuar të atij përdoruesi e përfaqëson operacionin më mirë sesa një llogari e përgjithshme SQL.
Pastaj aplikacioni përdor identitetin e vet të kufizuar në bazën e të dhënave, dhe klienti nuk merr kurrë një gjuhë pyetjesh si veçori. Kjo është një sipërfaqe më e vogël me më pak mënyra për të gabuar.
Ky është një opsion projektimi dhe jo pohimi se kodi i aplikacionit është automatikisht më i sigurt. Ai kod duhet të vërtetojë thirrësit e tij, të autorizojë çdo veprim dhe të validonte hyrjen e tij, dhe lejet e tij në bazën e të dhënave ende kanë rëndësi.
SQL i drejtpërdrejtë mbetet i saktë për njerëzit dhe mjetet, puna e miratuar e të cilëve e kërkon atë. Kufizoni atë model me role, shtrirje rrjeti dhe kufij operativë, dhe lërini klientët e tjerë të mbajnë ndërfaqen më të ngushtë. Përzierja e dy popullsive në një rol është vendi ku fillojnë debatet.