May nagmumungkahi na bigyan ang isang kliyente ng pag-login sa PostgreSQL upang ang claim sa gastos ay maglakbay nang naka-encrypt mula simula hanggang dulo. Ang administrador ng database ay nangangailangan ng tunay na sesyon ng SQL, at may ibang nagmumungkahi ng web form sa halip. Parehong mali ang problemang nilulutas ng dalawang mungkahi, dahil wala sa kanila ang nagsimula sa operasyong aktwal na ginagawa ng kliyente. Dumaan sa tatlong desisyon nang sunod-sunod at ang tanong kung maaaring palitan ng TLS ang isang VPN ay sasagot sa sarili nito.

Magsimula sa operasyong kailangan ng kliyente

Isulat kung ano ang dapat makamit ng kliyente. Ang pagsusumite ng claim, pagbasa ng isang hilera ng ulat at pagpapatakbo ng agarang query ay tatlong magkaibang operasyon na may tatlong magkaibang profile ng panganib.

Pagkatapos isulat kung sino ang gumagawa ng kahilingan. Ang kliyente, ahente ng suporta at administrador ay hindi mapagpapalit kahit hinahawakan nila ang parehong talahanayan. Ang pagkakaiba ang nagtatakda kung gaano karami sa wika ng query ang dapat makita ng kliyente.

Ang pares ng sagot ang nagtatakda ng interface. Ang lahat pagkatapos nito ay implementasyon, at ang karamihan ng debate tungkol sa encryption ay talagang debate tungkol sa kung aling interface ang pinili.

Tatlong kontrol, tatlong desisyon

Pinoprotektahan ng authenticated na TLS ang koneksyon at nagtatakda kung aling mga identidad ng TLS ang tinatanggap. Ang pagpasok sa network ay nagtatakda kung aling mga pinagmulan ang maaaring makarating sa nakikinig. Ang awtorisasyon sa database ay nagtatakda kung aling mga bagay at aksyon ang maaaring gamitin ng isang tungkulin.

Wala sa tatlo ang pumapalit sa iba, na malinaw na ipinapakita ng talahanayan.

ControlWhat it decidesWhat it leaves open
Authenticated TLSConnection protection and which TLS identities are acceptedWhich tables a database user may touch
Restricted network entryWhich sources reach the listenerWhether an authenticated user should run a given statement
Database authorizationWhich objects and actions a role may useWhether the connection arrived by an approved path

Basahin ang hilerang pinagkakatiwalaan mo bago tanggalin ang isa pa. Karamihan sa mga disenyong ito ay nabibigo dahil ang isang kontrol ay ipinagpalagay sa halip na i-configure.

Ang direktang SQL ay nag-iiwan sa patakaran ng database na may pananagutan

Sa isang aprubadong direktang koneksyon, panatilihin ang parehong beripikasyon ng identidad ng serbisyo at ang nilalayong patakaran sa pag-access. Ang pag-on ng TLS ay ginagawang available ang mga naka-encrypt na koneksyon; hindi nito tinatanggihan ang hindi naka-encrypt maliban kung hinihingi ito ng configuration ng access sa pamamagitan ng mga entry na hostssl.

Ang pagkakaibang iyon ay sulit suriin sa tumatakbong configuration at hindi sa isang template. Ang server na nag-aalok ng TLS at tumatanggap ng plain text ay hindi ang disenyong inaakala ng karamihan na na-deploy nila. Basahin ang mga patakaran sa access at tingnan kung aling mga entry ang tunay na nangangailangan nito. Ang isang pagsusuring iyon ay naghihiwalay sa server na may kakayahang mag-encrypt mula sa isang naka-encrypt lamang.

Gumamit ng mga tungkuling may pribilehiyong kailangan lamang ng trabaho, at suriin ang pagmamay-ari, minanang pagiging miyembro at malawak na ibinigay na mga pahintulot. Ang modelo ng pribilehiyo ng PostgreSQL ang hangganan ng awtoridad para sa mga bagay ng database.

Maaaring limitahan ng VPN kung aling mga aparato ang nakakarating sa serbisyo bago mangyari ang authentication sa database, at ang isang gateway ng access ay maaaring gumawa ng katulad. Wala sa dalawa ang nag-aalis ng pangangailangang alagaan ang nakalantad na component, pamahalaan ang mga kredensyal at limitahan ang paggamit ng mapagkukunan.

Ang mga sertipiko ng kliyente ay isang kredensyal, hindi isang ACL

Ang sertipiko ng kliyente ay maaaring magdagdag ng kundisyon sa oras ng koneksyon. Ang setting na clientcert ay maaaring mangailangan ng pinagkakatiwalaang sertipiko at, sa mas mahigpit na mode, ng kaugnayan sa pagitan ng pangalan ng sertipiko at ng user ng database.

Iyon ay isang mas matibay na kredensyal. Hindi ito listahan ng awtorisasyon, at hindi nito ginagawang di-nakikita ang server, dahil pinoproseso pa rin ng component na tumatanggap ng koneksyon ang trapiko ng network at isang handshake. Ang pagtrato sa sertipiko bilang listahan ng access ay iniiwan ang tunay na mga pahintulot na hindi nagagalaw. May tendensiya rin itong palawakin ang distribusyon ng sertipiko, na lumilikha ng susunod na problema.

Ang matibay na sertipikong nakakabit sa isang tungkuling may labis na pribilehiyo ay gumagawa ng mahusay na na-authenticate na administrador. Suriin ang tungkulin bago ipagdiwang ang sertipiko.

Piliin ang mas makitid na interface kapag angkop

Para sa isang claim sa gastos, ang endpoint ng aplikasyon na tumatanggap ng claim, nagpapatupad ng mga patakaran ng negosyo at nagbabalik ng pinapayagang resulta ng user na iyon ay kumakatawan sa operasyon nang mas mahusay kaysa sa isang pangkalahatang account ng SQL.

Pagkatapos ay ginagamit ng aplikasyon ang sarili nitong limitadong identidad sa database, at hindi kailanman natatanggap ng kliyente ang wika ng query bilang isang feature. Iyon ay isang mas maliit na surface na may mas kaunting paraan upang magkamali.

Ito ay isang opsyon sa disenyo at hindi isang pag-aangkin na ang code ng aplikasyon ay awtomatikong mas ligtas. Kailangang i-authenticate ng code na iyon ang mga tumatawag nito, awtorisahan ang bawat aksyon at beripikahin ang input nito, at mahalaga pa rin ang sarili nitong mga pahintulot sa database.

Ang direktang SQL ay nananatiling tama para sa mga tao at kasangkapan na ang aprubadong trabaho ay nangangailangan nito. Limitahan ang disenyong iyon sa mga tungkulin, saklaw ng network at mga hangganan ng operasyon, at hayaang panatilihin ng ibang mga kliyente ang mas makitid na interface. Ang paghahalo ng dalawang populasyon sa isang tungkulin ang lugar kung saan nagsisimula ang mga debate.

Kaugnay na mga artikulo