TLS, nettverkstilgang og SQL-rettigheter svarer på forskjellige spørsmål
Å kryptere en forbindelse, slippe inn en kilde og gi en tabell er tre beslutninger. Gå gjennom dem i rekkefølge før du spør om TLS kan erstatte en VPN.
Noen foreslår å gi en kunde en PostgreSQL-innlogging slik at et utgiftskrav reiser kryptert fra ende til ende. En databaseadministrator trenger en ekte SQL-økt, og noen andre foreslår i stedet et nettskjema. Begge forslagene løser feil problem, fordi ingen av dem begynte med operasjonen kunden faktisk utfører. Gå gjennom de tre beslutningene i rekkefølge, og spørsmålet om TLS kan erstatte en VPN besvarer seg selv.
Start med operasjonen kunden trenger
Skriv ned hva kunden skal oppnå. Å sende inn et krav, lese én rad i en rapport og kjøre en ad hoc-spørring er tre forskjellige operasjoner med tre forskjellige risikoprofiler.
Skriv deretter ned hvem som sender forespørselen. En kunde, en støtteagent og en administrator er ikke utskiftbare selv når de berører samme tabell. Forskjellen avgjør hvor mye av spørrespråket kunden i det hele tatt bør se.
Paret av svar avgjør grensesnittet. Alt etterpå er implementasjon, og de fleste diskusjoner om kryptering er egentlig diskusjoner om hvilket grensesnitt som ble valgt.
Tre kontroller, tre beslutninger
Autentisert TLS beskytter forbindelsen og avgjør hvilke TLS-identiteter som godtas. Nettverkstilgang avgjør hvilke kilder som i det hele tatt kan nå lytteren. Databaseautorisasjon avgjør hvilke objekter og handlinger en rolle kan bruke.
Ingen av de tre erstatter de andre, noe tabellen gjør tydelig.
| 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 |
Les raden du stoler på før du fjerner en annen. De fleste slike design feiler fordi en kontroll ble antatt i stedet for konfigurert.
Direkte SQL holder databasepolicyen ansvarlig
Med en godkjent direkte forbindelse beholder du både verifisering av tjenesteidentitet og den tiltenkte tilgangspolicyen. Å slå på TLS gjør krypterte forbindelser tilgjengelige; det avviser ikke ukrypterte med mindre tilgangskonfigurasjonen krever det gjennom hostssl-oppføringer.
Den forskjellen er verdt å sjekke i den kjørende konfigurasjonen og ikke i en mal. En server som tilbyr TLS og godtar klartekst, er ikke designet de fleste tror de har rullet ut. Les tilgangsreglene og se hvilke oppføringer som faktisk krever det. Den ene kontrollen skiller en server som kan kryptere fra en som bare er kryptert.
Bruk roller med bare de rettighetene jobben trenger, og gjennomgå eierskap, nedarvet medlemskap og bredt tildelte tillatelser. PostgreSQLs rettighetsmodell er autoritetsgrensen for databaseobjekter.
En VPN kan begrense hvilke enheter som når tjenesten før databaseautentiseringen skjer, og en tilgangsgateway kan gjøre noe lignende. Ingen av dem fjerner behovet for å vedlikeholde den eksponerte komponenten, administrere legitimasjon og begrense ressursbruken.
Klientsertifikater er legitimasjon, ikke en ACL
Et klientsertifikat kan legge til et krav ved tilkobling. Innstillingen clientcert kan kreve et betrodd sertifikat og, i strengere modus, et forhold mellom sertifikatnavnet og databasebrukeren.
Det er en sterkere legitimasjon. Det er ikke en autorisasjonsliste, og det gjør ikke serveren usynlig, fordi komponenten som godtar forbindelsen fortsatt behandler nettverkstrafikk og et håndtrykk. Å behandle et sertifikat som en tilgangsliste lar de faktiske tillatelsene være urørt. Det har også en tendens til å utvide sertifikatdistribusjonen, noe som skaper det neste problemet.
Et sterkt sertifikat knyttet til en rolle med for mange rettigheter gir en godt autentisert administrator. Sjekk rollen før du feirer sertifikatet.
Velg det smalere grensesnittet når det passer
For et utgiftskrav representerer et applikasjonsendepunkt som godtar kravet, håndhever forretningsreglene og returnerer den tillatte resultatet for den brukeren, operasjonen bedre enn en generell SQL-konto.
Applikasjonen bruker deretter sin egen begrensede databaseidentitet, og kunden mottar aldri et spørrespråk som funksjon. Det er en mindre flate med færre måter å ta feil på.
Dette er et designvalg og ikke en påstand om at applikasjonskode automatisk er sikrere. Den koden må autentisere sine kallere, autorisere hver handling og validere inndataene sine, og dens egne databasetillatelser betyr fortsatt noe.
Direkte SQL forblir riktig for mennesker og verktøy hvis godkjente arbeid krever det. Kvalifiser det designet med roller, nettverksomfang og driftsgrenser, og la de andre klientene beholde det smalere grensesnittet. Å blande de to gruppene i én rolle er der diskusjonene begynner.