TLS, nätverksinträde och SQL-behörigheter svarar på olika frågor
Att kryptera en anslutning, släppa in en källa och ge en tabell är tre beslut. Gå igenom dem i ordning innan du frågar om TLS kan ersätta en VPN.
Någon föreslår att ge en kund en PostgreSQL-inloggning så att ett kostnadsanspråk färdas krypterat från början till slut. En databasadministratör behöver en riktig SQL-session, och någon annan föreslår i stället ett webbformulär. Båda förslagen löser fel problem, eftersom inget av dem började med den operation som kunden faktiskt utför. Gå igenom de tre besluten i ordning och frågan om TLS kan ersätta en VPN besvarar sig själv.
Börja med den operation kunden behöver
Skriv ned vad kunden ska uppnå. Att skicka in ett anspråk, läsa en rad i en rapport och köra en ad hoc-fråga är tre olika operationer med tre olika riskprofiler.
Skriv sedan ned vem som gör begäran. En kund, en supportagent och en administratör är inte utbytbara ens när de rör samma tabell. Skillnaden avgör hur mycket av frågespråket kunden någonsin bör se.
Paret av svar avgör gränssnittet. Allt därefter är implementering, och de flesta diskussioner om kryptering är egentligen diskussioner om vilket gränssnitt som valdes.
Tre kontroller, tre beslut
Autentiserad TLS skyddar anslutningen och avgör vilka TLS-identiteter som accepteras. Nätverksinträde avgör vilka källor som överhuvudtaget kan nå lyssnaren. Databasauktorisering avgör vilka objekt och åtgärder en roll får använda.
Ingen av de tre ersätter de andra, vilket tabellen gör tydligt.
| 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 raden du förlitar dig på innan du tar bort en annan. De flesta sådana här konstruktioner misslyckas eftersom en kontroll antogs i stället för konfigurerades.
Direkt SQL håller databaspolicyn ansvarig
Med en godkänd direkt anslutning behåller du både verifiering av tjänstens identitet och den avsedda åtkomstpolicyn. Att slå på TLS gör krypterade anslutningar tillgängliga; det avvisar inte okrypterade om inte åtkomstkonfigurationen kräver det genom hostssl-poster.
Den skillnaden är värd att kontrollera i den körande konfigurationen och inte i en mall. En server som erbjuder TLS och accepterar klartext är inte den konstruktion som de flesta tror att de har rullat ut. Läs åtkomstreglerna och se vilka poster som faktiskt kräver det. Den enda kontrollen skiljer en server som kan kryptera från en som bara är krypterad.
Använd roller med bara de behörigheter jobbet behöver, och granska ägarskap, ärvt medlemskap och brett tilldelade rättigheter. PostgreSQLs behörighetsmodell är auktoritetsgränsen för databasobjekt.
En VPN kan begränsa vilka enheter som når tjänsten innan databasautentiseringen sker, och en åtkomstgateway kan göra något liknande. Ingen av dem tar bort behovet av att underhålla den exponerade komponenten, hantera autentiseringsuppgifter och begränsa resursanvändningen.
Klientcertifikat är en autentiseringsuppgift, inte en ACL
Ett klientcertifikat kan lägga till ett krav vid anslutningen. Inställningen clientcert kan kräva ett betrott certifikat och, i strängare läge, ett förhållande mellan certifikatets namn och databasanvändaren.
Det är en starkare autentiseringsuppgift. Det är inte en auktoriseringslista, och det gör inte servern osynlig, eftersom komponenten som tar emot anslutningen fortfarande bearbetar nätverkstrafik och en handskakning. Att behandla ett certifikat som en åtkomstlista lämnar de faktiska behörigheterna orörda. Det tenderar också att bredda certifikatdistributionen, vilket skapar nästa problem.
Ett starkt certifikat knutet till en roll med för stora behörigheter ger en väl autentiserad administratör. Kontrollera rollen innan du firar certifikatet.
Välj det snävare gränssnittet när det passar
För ett kostnadsanspråk representerar en applikationsslutpunkt som tar emot anspråket, upprätthåller affärsreglerna och returnerar den användarens tillåtna resultat operationen bättre än ett allmänt SQL-konto.
Applikationen använder sedan sin egen begränsade databasidentitet, och kunden får aldrig ett frågespråk som funktion. Det är en mindre yta med färre sätt att göra fel.
Detta är ett designval och inte ett påstående att applikationskod automatiskt är säkrare. Den koden måste autentisera sina anropare, auktorisera varje åtgärd och validera sin indata, och dess egna databasbehörigheter spelar fortfarande roll.
Direkt SQL förblir korrekt för människor och verktyg vars godkända arbete kräver det. Kvalificera den konstruktionen med roller, nätverksomfång och driftsgränser, och låt de andra klienterna behålla det snävare gränssnittet. Att blanda de två grupperna i en roll är där diskussionerna börjar.