Hur du säkrar din PostgreSQL-databas - 10 tips

När du har avslutat installationsprocessen av din PostgreSQL-databasserver är det nödvändigt att skydda den innan du går i produktion. I det här inlägget kommer vi att visa dig hur du stärker säkerheten kring din databas för att hålla din data säker och säker.

1. Klientautentiseringskontroll

När du installerar PostgreSQL skapas en fil med namnet pg_hba.conf i databasklustrets datakatalog. Den här filen kontrollerar klientautentisering.

Från den officiella postgresql-dokumentationen kan vi definiera filen pg_hba.conf som en uppsättning poster, en per rad, där varje post anger en anslutningstyp, ett klient-IP-adressintervall (om relevant för anslutningstypen), ett databasnamn, en användarnamn och den autentiseringsmetod som ska användas för anslutningar som matchar dessa parametrar. Den första posten med en matchande anslutningstyp, klientadress, begärd databas och användarnamn används för att utföra autentisering.

Så det allmänna formatet blir ungefär så här:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

Ett exempel på konfiguration kan vara följande:

# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     postgres              all             192.168.93.0/24         ident
# Reject any user from any host with IP address 192.168.94.x to connect
# to database "postgres
# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     postgres              all             192.168.94.0/24         reject

Det finns många kombinationer du kan göra för att förfina reglerna (den officiella dokumentationen beskriver varje alternativ i detalj och har några bra exempel), men kom ihåg att undvika regler som är för tillåtande, som att tillåta åtkomst för linjer med DATABASE all eller ADDRESS 0.0.0.0/0.

För att garantera säkerheten, även om du glömmer att lägga till en regel, kan du lägga till följande rad längst ned:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     all              all             0.0.0.0/0         reject

Eftersom filen läses uppifrån och ned för att hitta matchande regler, på detta sätt säkerställer du att du för att tillåta behörighet måste uttryckligen lägga till matchningsregeln ovan.

2. Serverkonfiguration

Det finns några parametrar på postgresql.conf som vi kan ändra för att förbättra säkerheten.

Du kan använda parametern listen_address för att styra vilka ips som får ansluta till servern. Här är en god praxis att endast tillåta anslutningar från kända ips eller ditt nätverk, och undvika allmänna värden som "*",,"0.0.0.0:0" eller "::", som talar om för PostgreSQL att acceptera anslutning från vilken IP-adress som helst.

Att ändra porten som postgresql kommer att lyssna på (som standard 5432) är också ett alternativ. Du kan göra detta genom att ändra värdet på portparametern.

Parametrar som work_mem, maintenance_work_mem, temp_buffer , max_prepared_transactions, temp_file_limit är viktiga att ha i åtanke ifall du får en överbelastningsattack. Det här är parametrar för uttalanden/sessioner som kan ställas in på olika nivåer (db, användare, session), så att hantera dessa på ett klokt sätt kan hjälpa oss att minimera effekten av attacken.

3. Användar- och rollhantering

Den gyllene regeln för säkerhet när det gäller användarhantering är att ge användarna den minsta mängd åtkomst de behöver.

Att hantera detta är inte alltid lätt och det kan bli riktigt rörigt om det inte görs bra från början.

Ett bra sätt att hålla privilegierna under kontroll är att använda rollen, gruppen, användarstrategin.

I postgresql anses allt vara en roll, men vi kommer att göra några ändringar i detta.

I denna strategi kommer du att skapa tre olika typer eller roller:

• rollroll (identifierad med prefixet r_)
• grupproll (identifierad med prefixet g_)
• användarroll (vanligtvis personliga namn eller programnamn)

Rollerna (r_roller) kommer att vara de som har privilegier över objekten. Grupprollerna ( g_ roles ) kommer att beviljas med r_ roles , så de kommer att vara en samling r_ roller. Och slutligen kommer användarrollerna att beviljas med en eller flera grupproller och kommer att vara de med inloggningsbehörighet.

Låt oss visa ett exempel på detta. Vi kommer att skapa en skrivskyddad grupp för exempelschemat och sedan bevilja den till en användare:

Vi skapar den skrivskyddade rollen och ger den objektprivilegier

CREATE ROLE r_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT USAGE ON SCHEMA example to r_example_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA example to r_example_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA example GRANT SELECT ON TABLES TO r_example_ro;

Vi skapar den skrivskyddade gruppen och tilldelar rollen till den gruppen

CREATE ROLE g_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION';
GRANT r_example_ro to g_example_ro;

Vi skapar rollen app_user och får den att "gå med" i skrivskyddad grupp

CREATE ROLE app_user WITH LOGIN ;
ALTER ROLE app_user WITH PASSWORD 'somePassword' ;
ALTER ROLE app_user VALID UNTIL 'infinity' ;
GRANT g_example_ro TO app_user;

Med den här metoden kan du hantera granulariteten för privilegierna och du kan enkelt bevilja och återkalla grupper av åtkomst till användarna. Kom ihåg att endast ge objektbehörighet till rollerna istället för att göra det direkt åt användarna och att bara ge användarna inloggningsbehörighet.

Det här är en bra praxis att uttryckligen återkalla offentliga privilegier för objekten, som att återkalla allmänhetens åtkomst till en specifik databas och bara ge den genom en roll.

REVOKE CONNECT ON my_database FROM PUBLIC;
GRANT CONNECT ON my_database TO r_example_ro;

Begränsa SUPERUSER-åtkomst, tillåt superanvändaranslutningar endast från localhost/unix-domän.

Använd specifika användare för olika ändamål, som specifika appanvändare eller backupanvändare, och begränsa anslutningarna för den användaren endast från de nödvändiga IP:erna.

4. Super User Management

Att upprätthålla en stark lösenordspolicy är ett måste för att hålla dina databaser säkra och undvika lösenordshack. För en stark policy, använd helst specialtecken, siffror, versaler och gemener och har minst 10 tecken.

Det finns också externa autentiseringsverktyg, som LDAP eller PAM, som kan hjälpa dig att säkerställa att ditt lösenord löper ut och policy för återanvändning, och även hantera kontolåsning vid autentiseringsfel.

5. Datakryptering (på anslutning ssl)

PostgreSQL har inbyggt stöd för att använda SSL-anslutningar för att kryptera klient/server-kommunikation för ökad säkerhet. SSL (Secure Sockets Layer) är standardsäkerhetstekniken för att upprätta en krypterad länk mellan en webbserver och en webbläsare. Denna länk säkerställer att all data som skickas mellan webbservern och webbläsare förblir privat och integrerad.

Eftersom postgresql-klienter skickar frågor i vanlig text och data också skickas okrypterad, är den sårbar för nätverkspoofing.

Du kan aktivera SSL genom att sätta parametern ssl på på i postgresql.conf.

Servern lyssnar efter både normala anslutningar och SSL-anslutningar på samma TCP-port och kommer att förhandla med alla anslutande klienter om huruvida SSL ska användas. Som standard är detta efter klientens val, men du har möjlighet att ställa in servern så att den kräver användning av SSL för vissa eller alla anslutningar med hjälp av konfigurationsfilen pg_hba som beskrivs ovan.

6. Datakryptering i vila (pg_crypto)

Det finns två grundläggande typer av kryptering, envägs och tvåvägs. På ett sätt bryr du dig aldrig om att dekryptera data till läsbar form, utan du vill bara verifiera att användaren vet vad den underliggande hemliga texten är. Detta används normalt för lösenord. I tvåvägskryptering vill du ha möjligheten att kryptera data samt tillåta behöriga användare att dekryptera den till en meningsfull form. Data som kreditkort och SSN skulle falla i denna kategori.

För envägskryptering ger krypteringsfunktionen paketerad i pgcrypto en extra säkerhetsnivå över md5-sättet. Anledningen är att man med md5 kan se vem som har samma lösenord eftersom det inte finns något salt (I kryptografi är ett salt slumpmässig data som används som en extra ingång till en envägsfunktion som "hasha" data, ett lösenord eller lösenordsfras), så att alla personer med samma lösenord kommer att ha samma kodade md5-sträng. Med krypta kommer de att vara annorlunda.

För data som du bryr dig om att hämta vill du inte veta om de två informationsbitarna är desamma, men du känner inte till den informationen och du vill att endast behöriga användare ska kunna hämta den. Pgcrypto tillhandahåller flera sätt att åstadkomma detta, så för ytterligare läsning om hur du använder det kan du kontrollera den officiella postgresql-dokumentationen på https://www.postgresql.org/docs/current/static/pgcrypto.html.

7. Loggning

Postgresql tillhandahåller en mängd olika konfigurationsparametrar för att styra vad, när och var som ska loggas.

Du kan aktivera sessionsanslutning/-nedkopplingar, långvariga frågor, temporära filstorlekar och så vidare. Detta kan hjälpa dig att få en bättre kunskap om din arbetsbelastning för att identifiera udda beteenden. Du kan få alla alternativ för att logga på följande länk https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html

För mer detaljerad information om din arbetsbelastning kan du aktivera modulen pg_stat_statements, som tillhandahåller ett sätt att spåra exekveringsstatistik för alla SQL-satser som körs av en server. Det finns några säkerhetsverktyg som kan mata in data från den här tabellen och generera en sql-vitlista, för att hjälpa dig att identifiera frågor som inte följer de förväntade mönstren.

För mer information https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.

8. Revision

PostgreSQL Audit Extension (pgAudit) tillhandahåller detaljerad sessions- och/eller objektgranskningsloggning via den vanliga PostgreSQL-loggningsfunktionen.

Grundläggande satsloggning kan tillhandahållas av standardloggningsfunktionen med log_statement =all. Detta är acceptabelt för övervakning och annan användning men ger inte den detaljnivå som vanligtvis krävs för en revision. Det räcker inte att ha en lista över alla operationer som utförs mot databasen. Det ska också vara möjligt att hitta särskilda uttalanden som är av intresse för en revisor. Standardloggningsfunktionen visar vad användaren begärde, medan pgAudit fokuserar på detaljerna om vad som hände medan databasen tillfredsställde begäran.

9. Lappar

Kontrollera PostgreSQL:s säkerhetsinformationssida regelbundet och ofta efter viktiga säkerhetsuppdateringar och patchar.

Tänk på att OS- eller bibliotekssäkerhetsbuggar också kan leda till en databasläcka, så se till att du håller patchen för dessa uppdaterade.

ClusterControl tillhandahåller en driftsrapport som ger dig denna information och kommer att utföra patchar och uppgraderingar åt dig.

10. Säkerhet på radnivå

Förutom SQL-standardens behörighetssystem som är tillgängligt via GRANT, kan tabeller ha radsäkerhetspolicyer som begränsar, per användare, vilka rader som kan returneras av normala frågor eller infogas, uppdateras eller raderas med datamodifieringskommandon. Den här funktionen är också känd som Row-Level Security.

När radsäkerhet är aktiverat i en tabell måste all normal åtkomst till tabellen för att välja rader eller modifiera rader tillåtas av en radsäkerhetspolicy.

Här är ett enkelt exempel på hur man skapar en policy för kontorelationen så att endast medlemmar i chefsrollen får åtkomst till rader och endast rader i deras konton:

CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);

Du kan få mer information om den här funktionen i den officiella postgresql-dokumentationen https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html

Om du vill veta mer, här är några resurser som kan hjälpa dig att bättre stärka din databassäkerhet...

• https://www.postgresql.org/docs/9.6/static/auth-pg-hba-conf.html
• https://www.postgresql.org/docs/9.6/static/ssl-tcp.html
• https://www.postgresql.org/docs/current/static/pgcrypto.html
• http://www.postgresonline.com/journal/archives/165-Encrypting-data-with-pgcrypto.html
• https://github.com/pgaudit/pgaudit
• https://www.postgresql.org/docs/9.6/static/pgstatstatements.html

Slutsats

Om du följer tipsen ovan blir din server säkrare, men det betyder inte att den kommer att vara okrossbar.

För din egen säkerhet rekommenderar vi att du använder ett säkerhetstestverktyg som Nessus, för att veta vilka dina huvudsakliga sårbarheter är och försöka lösa dem.

Du kan också övervaka din databas med ClusterControl. Med detta kan du i realtid se vad som händer i din databas och analysera det.