TLS, verkkopääsy ja SQL-oikeudet vastaavat eri kysymyksiin
Yhteyden salaaminen, lähteen päästäminen ja taulun myöntäminen ovat kolme päätöstä. Käy ne läpi järjestyksessä ennen kuin kysyt, voiko TLS korvata VPN:n.
Joku ehdottaa, että asiakkaalle annetaan PostgreSQL-kirjautuminen, jotta kulukorvaushakemus kulkee salattuna päästä päähän. Tietokannan ylläpitäjä tarvitsee todellisen SQL-istunnon, ja joku toinen ehdottaa sen sijaan verkkolomaketta. Molemmat ehdotukset ratkaisevat väärän ongelman, koska kumpikaan ei alkanut toiminnosta, jonka asiakas todella suorittaa. Käy kolme päätöstä läpi järjestyksessä, niin kysymys siitä, voiko TLS korvata VPN:n, vastaa itse itsensä.
Aloita toiminnosta, jonka asiakas tarvitsee
Kirjoita ylös, mitä asiakkaan on saavutettava. Hakemuksen lähettäminen, raportin yhden rivin lukeminen ja hetkellisen kyselyn suorittaminen ovat kolme eri toimintoa, joilla on kolme eri riskiprofiilia.
Kirjoita sitten ylös, kuka pyynnön tekee. Asiakas, tukivirkailija ja ylläpitäjä eivät ole vaihdettavissa, vaikka he koskisivat samaa taulua. Ero ratkaisee, kuinka paljon kyselykieltä asiakkaan pitäisi koskaan nähdä.
Vastauspari ratkaisee rajapinnan. Kaikki sen jälkeen on toteutusta, ja useimmat salauskeskustelut ovat oikeastaan keskusteluja siitä, mikä rajapinta valittiin.
Kolme valvontaa, kolme päätöstä
Todennettu TLS suojaa yhteyden ja ratkaisee, mitkä TLS-identiteetit hyväksytään. Verkkopääsy ratkaisee, mitkä lähteet voivat ylipäätään tavoittaa kuuntelijan. Tietokannan valtuutus ratkaisee, mitä objekteja ja toimintoja rooli saa käyttää.
Mikään kolmesta ei korvaa muita, minkä taulukko tekee selväksi.
| 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 |
Lue rivi, johon luotat, ennen kuin poistat toisen. Useimmat näistä suunnitelmista epäonnistuvat, koska valvonta oletettiin eikä sitä määritetty.
Suora SQL pitää tietokantakäytännön vastuussa
Hyväksytyllä suoralla yhteydellä säilytä sekä palvelun identiteetin varmennus että aiottu käyttöoikeuskäytäntö. TLS:n käyttöönotto tekee salatut yhteydet saataville; se ei hylkää salaamattomia, ellei käyttöoikeusmääritys vaadi sitä hostssl-merkintöjen kautta.
Tämä ero kannattaa tarkistaa käynnissä olevasta määrityksestä eikä mallipohjasta. Palvelin, joka tarjoaa TLS:n ja hyväksyy selkokielisen tekstin, ei ole se suunnitelma, jonka useimmat luulevat ottaneensa käyttöön. Lue käyttöoikeussäännöt ja katso, mitkä merkinnät todella vaativat sitä. Tämä yksi tarkistus erottaa salauskykyisen palvelimen vain salatusta palvelimesta.
Käytä rooleja, joilla on vain työn tarvitsemat oikeudet, ja tarkista omistajuus, peritty jäsenyys ja laajasti myönnetyt käyttöoikeudet. PostgreSQL:n oikeusmalli on tietokantaobjektien valtuutusraja.
VPN voi rajoittaa, mitkä laitteet tavoittavat palvelun ennen tietokantatodennusta, ja käyttöoikeusyhdyskäytävä voi tehdä jotain vastaavaa. Kumpikaan ei poista tarvetta ylläpitää altistettua komponenttia, hallita tunnuksia ja rajoittaa resurssien käyttöä.
Asiakasvarmenteet ovat tunniste, eivät ACL
Asiakasvarmenne voi lisätä vaatimuksen yhteyden muodostamisen yhteydessä. Asetus clientcert voi vaatia luotetun varmenteen ja tiukemmassa tilassa suhteen varmenteen nimen ja tietokannan käyttäjän välillä.
Se on vahvempi tunniste. Se ei ole valtuutusluettelo, eikä se tee palvelimesta näkymätöntä, koska yhteyden vastaanottava komponentti käsittelee edelleen verkkoliikennettä ja kättelyä. Varmenteen kohteleminen käyttöoikeusluettelona jättää todelliset käyttöoikeudet ennalleen. Se myös yleensä laajentaa varmenteiden jakelua, mikä luo seuraavan ongelman.
Liiallisilla oikeuksilla varustettuun rooliin kiinnitetty vahva varmenne tuottaa hyvin todennetun ylläpitäjän. Tarkista rooli ennen kuin juhlit varmennetta.
Valitse kapeampi rajapinta, kun se sopii
Kulukorvaushakemuksessa sovelluksen päätepiste, joka vastaanottaa hakemuksen, valvoo liiketoimintasäännöt ja palauttaa kyseisen käyttäjän sallitun tuloksen, edustaa toimintoa paremmin kuin yleinen SQL-tili.
Sovellus käyttää sitten omaa rajoitettua tietokantaidentiteettiään, eikä asiakas koskaan saa kyselykieltä ominaisuutena. Se on pienempi pinta, jolla on vähemmän tapoja mennä pieleen.
Tämä on suunnitteluvaihtoehto, ei väite, että sovelluskoodi olisi automaattisesti turvallisempaa. Sen koodin on todennettava kutsujansa, valtuutettava jokainen toiminto ja validoitava syötteensä, ja sen omat tietokantaoikeudet merkitsevät edelleen.
Suora SQL pysyy oikeana ihmisille ja työkaluille, joiden hyväksytty työ sitä vaatii. Rajaa tämä suunnitelma rooleilla, verkkolaajuudella ja toiminnallisilla rajoilla, ja jätä muille asiakkaille kapeampi rajapinta. Kahden joukon sekoittaminen yhteen rooliin on kohta, jossa keskustelut alkavat.