TLS, nettverkstilgang og SQL-rettar svarar på ulike spørsmål
Å kryptere ei sambinding, sleppe inn ei kjelde og gje ei tabell er tre avgjerder. Gå gjennom dei i rekkjefølgje før du spør om TLS kan erstatte ein VPN.
Nokon føreslår å gje ein kunde ei PostgreSQL-innlogging slik at eit utgiftskrav fer kryptert frå ende til annan. Ein databaseadministrator treng ei ekte SQL-økt, og nokon andre føreslår i staden eit nettskjema. Begge framlegga løyser feil problem, fordi ingen av dei byrja med operasjonen kunden faktisk utfører. Gå gjennom dei tre avgjerdene i rekkjefølgje, og spørsmålet om TLS kan erstatte ein VPN svarar seg sjølv.
Start med operasjonen kunden treng
Skriv ned kva kunden skal oppnå. Å sende inn eit krav, lese éi rad i ein rapport og køyre ein ad hoc-spørjing er tre ulike operasjonar med tre ulike risikoprofilar.
Skriv deretter ned kven som sender førespurnaden. Ein kunde, ein støtteagent og ein administrator er ikkje utskiftbare sjølv når dei rører same tabell. Skilnaden avgjer kor mykje av spørjespråket kunden i det heile bør sjå.
Paret av svar avgjer grensesnittet. Alt etterpå er implementasjon, og dei fleste diskusjonar om kryptering er eigenleg diskusjonar om kva grensesnitt som vart valt.
Tre kontrollar, tre avgjerder
Autentisert TLS vernar sambindinga og avgjer kva TLS-identitetar som blir godtekne. Nettverkstilgang avgjer kva kjelder som i det heile kan nå lyttaren. Databaseautorisasjon avgjer kva objekt og handlingar ei rolle kan bruke.
Ingen av dei tre erstattar dei andre, noko tabellen gjer tydeleg.
| 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 rada du stolar på før du fjernar ei anna. Dei fleste slike design feilar fordi ein kontroll vart antatt i staden for konfigurert.
Direkte SQL held databasepolitikken ansvarleg
Med ei godkjend direkte sambinding held du både verifisering av tenesteidentitet og den tiltenkte tilgangspolitikken. Å slå på TLS gjer krypterte sambindingar tilgjengelege; det avviser ikkje ukrypterte med mindre tilgangskonfigurasjonen krev det gjennom hostssl-oppføringar.
Den skilnaden er verd å sjekke i den køyrande konfigurasjonen og ikkje i ein mal. Ein tenar som tilbyr TLS og godtar klartekst, er ikkje designet dei fleste trur dei har rulle ut. Les tilgangsreglane og sjå kva oppføringar som faktisk krev det. Den eine kontrollen skil ein tenar som kan kryptere frå ein som berre er kryptert.
Bruk rollar med berre dei rettane jobben treng, og gå gjennom eigarskap, nedarva medlemskap og breitt tildelte løyve. PostgreSQL sin rettsmodell er autoritetsgrensa for databaseobjekt.
Ein VPN kan avgrense kva einingar som når tenesta før databaseautentiseringa skjer, og ein tilgangsgateway kan gjere noko liknande. Ingen av dei fjernar behovet for å vedlikehalde den eksponerte komponenten, administrere legitimasjon og avgrense ressursbruken.
Klientsertifikat er legitimasjon, ikkje ein ACL
Eit klientsertifikat kan leggje til eit krav ved tilkopling. Innstillinga clientcert kan krevje eit betrudd sertifikat og, i strengare modus, eit tilhøve mellom sertifikatnamnet og databasebrukaren.
Det er ein sterkare legitimasjon. Det er ikkje ei autorisasjonsliste, og det gjer ikkje tenaren usynleg, fordi komponenten som godtar sambindinga framleis handsamar nettverkstrafikk og eit handtrykk. Å handsame eit sertifikat som ei tilgangsliste lèt dei faktiske løyva vere urørte. Det har òg ein tendens til å utvide sertifikatdistribusjonen, noko som skapar det neste problemet.
Eit sterkt sertifikat knytt til ei rolle med for mange rettar gjev ein godt autentisert administrator. Sjekk rolla før du feirar sertifikatet.
Vel det smalare grensesnittet når det passar
For eit utgiftskrav representerer eit applikasjonsendepunkt som godtar kravet, handhevar forretningsreglane og returnerer det tillatne resultatet for den brukaren, operasjonen betre enn ein generell SQL-konto.
Applikasjonen brukar deretter sin eigen avgrensa databaseidentitet, og kunden mottek aldri eit spørjespråk som funksjon. Det er ei mindre flate med færre måtar å ta feil på.
Dette er eit designval og ikkje ein påstand om at applikasjonskode automatisk er tryggare. Den koden må autentisere kallarane sine, autorisere kvar handling og validere inndataa sine, og dei eigne databasetilløyva betyr framleis noko.
Direkte SQL blir verande rett for menneske og verktøy som treng det i det godkjende arbeidet sitt. Kvalifiser det designet med rollar, nettverksomfang og driftsgrenser, og la dei andre klientane behalde det smalare grensesnittet. Å blande dei to gruppene i éi rolle er der diskusjonane byrjar.