TLS, netværksadgang og SQL-rettigheder besvarer forskellige spørgsmål
At kryptere en forbindelse, lukke en kilde ind og give en tabel er tre beslutninger. Gå dem igennem i rækkefølge, før du spørger, om TLS kan erstatte en VPN.
Nogen foreslår at give en kunde et PostgreSQL-login, så en udgiftsanmodning rejser krypteret fra ende til anden. En databaseadministrator har brug for en rigtig SQL-session, og en anden foreslår i stedet en webformular. Begge forslag løser det forkerte problem, fordi ingen af dem begyndte med den handling, kunden faktisk udfører. Gå de tre beslutninger igennem i rækkefølge, og spørgsmålet om TLS kan erstatte en VPN besvarer sig selv.
Begynd med den handling, kunden har brug for
Skriv ned, hvad kunden skal opnå. At indsende en anmodning, læse én række i en rapport og køre en ad hoc-forespørgsel er tre forskellige handlinger med tre forskellige risikoprofiler.
Skriv derefter ned, hvem der stiller anmodningen. En kunde, en supportagent og en administrator kan ikke udskiftes, selv når de rører den samme tabel. Forskellen afgør, hvor meget af forespørgselssproget kunden overhovedet bør se.
Det par af svar afgør grænsefladen. Alt derefter er implementering, og de fleste diskussioner om kryptering er i virkeligheden diskussioner om, hvilken grænseflade der blev valgt.
Tre kontroller, tre beslutninger
Autentificeret TLS beskytter forbindelsen og afgør, hvilke TLS-identiteter der accepteres. Netværksadgang afgør, hvilke kilder der overhovedet kan nå lytteren. Databaseautorisation afgør, hvilke objekter og handlinger en rolle må bruge.
Ingen af de tre erstatter de andre, hvilket tabellen gør tydeligt.
| 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 |
Læs den række, du stoler på, før du fjerner en anden. De fleste af disse design fejler, fordi en kontrol blev antaget i stedet for konfigureret.
Direkte SQL holder databasepolitikken ved magten
Med en godkendt direkte forbindelse skal du bevare både verifikation af tjenesteidentitet og den tilsigtede adgangspolitik. At slå TLS til gør krypterede forbindelser tilgængelige; det afviser ikke ukrypterede, medmindre adgangskonfigurationen siger det gennem hostssl-poster.
Den forskel er værd at kontrollere i den kørende konfiguration frem for i en skabelon. En server, der tilbyder TLS og accepterer klartekst, er ikke det design, de fleste tror, de har udrullet. Læs adgangsreglerne, og se hvilke poster der faktisk kræver det. Den ene kontrol adskiller en server, der kan kryptere, fra en server, der kun krypterer.
Brug roller med kun de rettigheder, jobbet har brug for, og gennemgå ejerskab, nedarvet medlemskab og bredt tildelte tilladelser. PostgreSQLs rettighedsmodel er autoritetsgrænsen for databaseobjekter.
En VPN kan begrænse, hvilke enheder der når tjenesten, før databaseautentificering sker, og en adgangsgateway kan gøre noget lignende. Ingen af dem fjerner behovet for at vedligeholde den eksponerede komponent, styre legitimationsoplysninger og begrænse ressourceforbruget.
Klientcertifikater er en legitimationsoplysning, ikke en ACL
Et klientcertifikat kan tilføje et krav på forbindelsestidspunktet. Indstillingen clientcert kan kræve et betroet certifikat og i den strengere tilstand en forbindelse mellem certifikatets navn og databasebrugeren.
Det er en stærkere legitimationsoplysning. Det er ikke en autorisationsliste, og det gør ikke serveren usynlig, fordi komponenten, der accepterer forbindelsen, stadig behandler netværkstrafik og et håndtryk. At behandle et certifikat som en adgangsliste lader de faktiske tilladelser være urørte. Det har også tendens til at udvide certifikatdistributionen, hvilket skaber det næste problem.
Et stærkt certifikat knyttet til en rolle med for mange rettigheder giver en velautentificeret administrator. Kontroller rollen, før du fejrer certifikatet.
Vælg den smallere grænseflade, når den passer
For en udgiftsanmodning repræsenterer et applikationsendepunkt, der accepterer anmodningen, håndhæver forretningsreglerne og returnerer den pågældende brugers tilladte resultat, handlingen bedre end en generel SQL-konto.
Applikationen bruger derefter sin egen begrænsede databaseidentitet, og kunden får aldrig et forespørgselssprog som en funktion. Det er en mindre overflade med færre måder at tage fejl.
Dette er en designmulighed og ikke en påstand om, at applikationskode automatisk er sikrere. Den kode skal autentificere sine kaldere, autorisere hver handling og validere sit input, og dens egne databasetilladelser betyder stadig noget.
Direkte SQL forbliver korrekt for mennesker og værktøjer, hvis godkendte arbejde kræver det. Kvalificér det design med roller, netværksomfang og driftsgrænser, og lad de andre klienter beholde den smallere grænseflade. At blande de to populationer i én rolle er der, hvor diskussionerne begynder.