Sådan sikrer du din PostgreSQL-database - 10 tips

Når du har afsluttet installationsprocessen af ​​din PostgreSQL-databaseserver, er det nødvendigt at beskytte den, før du går i produktion. I dette indlæg vil vi vise dig, hvordan du hærder sikkerheden omkring din database for at holde dine data sikre og sikre.

1. Klientgodkendelseskontrol

Når du installerer PostgreSQL, oprettes en fil med navnet pg_hba.conf i databaseklyngens datamappe. Denne fil styrer klientgodkendelse.

Fra den officielle postgresql-dokumentation kan vi definere filen pg_hba.conf som et sæt poster, én pr. linje, hvor hver post specificerer en forbindelsestype, et klient-IP-adresseområde (hvis relevant for forbindelsestypen), et databasenavn, en brugernavn og godkendelsesmetoden, der skal bruges til forbindelser, der matcher disse parametre. Den første post med en matchende forbindelsestype, klientadresse, anmodet database og brugernavn bruges til at udføre godkendelse.

Så det generelle format vil være noget som dette:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

Et eksempel på konfiguration kan være som følger:

# 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

Der er mange kombinationer, du kan lave for at forfine reglerne (den officielle dokumentation beskriver hver mulighed i detaljer og har nogle gode eksempler), men husk at undgå regler, der er for tilladelige, såsom at tillade adgang for linjer ved hjælp af DATABASE all eller ADDRESS 0.0.0.0/0.

For at sikre sikkerhed, selvom du glemmer at tilføje en regel, kan du tilføje følgende række nederst:

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

Da filen læses fra top til bund for at finde matchende regler, sikrer du på denne måde, at for at tillade tilladelse skal du udtrykkeligt tilføje matchningsreglen ovenfor.

2. Serverkonfiguration

Der er nogle parametre på postgresql.conf, som vi kan ændre for at forbedre sikkerheden.

Du kan bruge parameteren listen_address til at kontrollere, hvilke ips der får lov til at oprette forbindelse til serveren. Her er en god praksis kun at tillade forbindelser fra de kendte ips eller dit netværk, og undgå generelle værdier som "*",,"0.0.0.0:0" eller "::", som vil fortælle PostgreSQL at acceptere forbindelse fra enhver IP.

Ændring af porten, som postgresql vil lytte på (som standard 5432) er også en mulighed. Du kan gøre dette ved at ændre værdien af ​​portparameteren.

Parametre som work_mem, maintenance_work_mem, temp_buffer, max_prepared_transactions, temp_file_limit er vigtige at huske på, hvis du har et lammelsesangreb. Dette er sætnings-/sessionsparametre, der kan indstilles på forskellige niveauer (db, bruger, session), så klog håndtering af disse kan hjælpe os med at minimere virkningen af ​​angrebet.

3. Bruger- og rollestyring

Den gyldne regel for sikkerhed med hensyn til brugeradministration er at give brugerne den mindste mængde adgang, de har brug for.

Det er ikke altid nemt at styre dette, og det kan blive rigtig rodet, hvis det ikke gøres godt fra begyndelsen.

En god måde at holde privilegierne under kontrol er at bruge rollen, gruppen, brugerstrategien.

I postgresql betragtes alt som en rolle, men vi vil lave nogle ændringer til dette.

I denne strategi vil du oprette tre forskellige typer eller roller:

• rollerolle (identificeret med præfikset r_)
• grupperolle (identificeret med præfikset g_)
• brugerrolle (generelt personlige eller applikationsnavne)

Rollerne (r_roller) vil være dem, der har privilegier over objekterne. Grupperollerne (g_roller) vil blive tildelt med r_rollerne, så de vil være en samling af r_roller. Og endelig vil brugerrollerne blive tildelt en eller flere grupperoller og vil være dem med login-privilegiet.

Lad os vise et eksempel på dette. Vi vil oprette en skrivebeskyttet gruppe for eksempel_skemaet og derefter tildele den til en bruger:

Vi opretter skrivebeskyttet-rollen og giver 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 opretter skrivebeskyttet gruppe og tildeler rollen til denne gruppe

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

Vi opretter rollen app_user og får den til at "melde sig ind i" skrivebeskyttet gruppe

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;

Ved at bruge denne metode kan du administrere privilegiernes granularitet, og du kan nemt tildele og tilbagekalde grupper af adgang til brugerne. Husk kun at tildele objektprivilegier til rollerne i stedet for at gøre det direkte for brugerne og kun at tildele login-rettigheder til brugerne.

Dette er en god praksis eksplicit at tilbagekalde offentlige rettigheder på objekterne, som at tilbagekalde offentlig adgang til en specifik database og kun give den gennem en rolle.

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

Begræns SUPERUSER-adgang, tillad kun superbrugerforbindelser fra localhost/unix-domæne.

Brug specifikke brugere til forskellige formål, såsom specifikke app-brugere eller backup-brugere, og begræns forbindelserne for denne bruger kun fra de påkrævede IP'er.

4. Superbrugerstyring

Vedligeholdelse af en stærk adgangskodepolitik er et must for at holde dine databaser sikre og undgå adgangskodehack. For en stærk politik skal du fortrinsvis bruge specialtegn, tal, store og små bogstaver og have mindst 10 tegn.

Der er også eksterne godkendelsesværktøjer, såsom LDAP eller PAM, der kan hjælpe dig med at sikre din adgangskodeudløbs- og genbrugspolitik og også håndtere kontolåsning ved godkendelsesfejl.

5. Datakryptering (på forbindelse ssl)

PostgreSQL har indbygget support til at bruge SSL-forbindelser til at kryptere klient/server-kommunikation for øget sikkerhed. SSL (Secure Sockets Layer) er standardsikkerhedsteknologien til at etablere et krypteret link mellem en webserver og en browser. Dette link sikrer, at alle data, der sendes mellem webserveren og browsere, forbliver private og integrerede.

Da postgresql-klienter sender forespørgsler i almindelig tekst, og data også sendes ukrypteret, er det sårbart over for netværksspoofing.

Du kan aktivere SSL ved at indstille ssl-parameteren til on i postgresql.conf.

Serveren lytter efter både normale forbindelser og SSL-forbindelser på den samme TCP-port og vil forhandle med enhver tilsluttende klient om, hvorvidt SSL skal bruges. Som standard er dette efter klientens valg, men du har mulighed for at konfigurere serveren til at kræve brug af SSL for nogle eller alle forbindelser ved hjælp af pg_hba-konfigurationsfilen beskrevet ovenfor.

6. Datakryptering i hvile (pg_crypto)

Der er to grundlæggende former for kryptering, en-vejs og to-vejs. På én måde er du ikke ligeglad med at dekryptere dataene til en læsbar form, men du vil blot bekræfte, at brugeren ved, hvad den underliggende hemmelige tekst er. Dette bruges normalt til adgangskoder. I tovejskryptering vil du have muligheden for at kryptere data samt tillade autoriserede brugere at dekryptere dem til en meningsfuld form. Data såsom kreditkort og SSN'er falder i denne kategori.

Til envejskryptering giver krypteringsfunktionen pakket i pgcrypto et ekstra sikkerhedsniveau over md5-måden. Årsagen er, at man med md5 kan se, hvem der har den samme adgangskode, fordi der ikke er noget salt (I kryptografi er et salt tilfældige data, der bruges som et ekstra input til en envejsfunktion, der "hasher" data, en adgangskode eller adgangssætning), så alle personer med den samme adgangskode vil have den samme kodede md5-streng. Med krypt vil de være anderledes.

For data, som du interesserer dig for at hente, ønsker du ikke at vide, om de to oplysninger er ens, men du kender ikke disse oplysninger, og du ønsker, at kun autoriserede brugere skal kunne hente dem. Pgcrypto tilbyder flere måder at opnå dette på, så for yderligere læsning om, hvordan du bruger det, kan du tjekke den officielle postgresql-dokumentation på https://www.postgresql.org/docs/current/static/pgcrypto.html.

7. Logning

Postgresql giver en bred vifte af konfigurationsparametre til at kontrollere hvad, hvornår og hvor der skal logges.

Du kan aktivere sessionsforbindelse/afbrydelser, langvarige forespørgsler, midlertidige filstørrelser og så videre. Dette kan hjælpe dig med at få et bedre kendskab til din arbejdsbyrde for at identificere mærkelig adfærd. Du kan få alle mulighederne for at logge på følgende link https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html

For mere detaljeret information om din arbejdsbyrde kan du aktivere modulet pg_stat_statements, som giver et middel til at spore eksekveringsstatistikker for alle SQL-sætninger, der udføres af en server. Der er nogle sikkerhedsværktøjer, der kan indlæse dataene fra denne tabel og generere en sql-hvidliste, for at hjælpe dig med at identificere forespørgsler, der ikke følger de forventede mønstre.

For mere information https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.

8. Revision

PostgreSQL Audit Extension (pgAudit) giver detaljeret sessions- og/eller objektauditlogning via standard PostgreSQL-logningsfaciliteten.

Grundlæggende sætningslogning kan leveres af standardlogningsfaciliteten med log_statement =alle. Dette er acceptabelt til overvågning og anden brug, men giver ikke det detaljeringsniveau, der generelt kræves til en revision. Det er ikke nok at have en liste over alle de operationer, der udføres mod databasen. Det skal også være muligt at finde særlige erklæringer, som er af interesse for en revisor. Standardlogningsfaciliteten viser, hvad brugeren anmodede om, mens pgAudit fokuserer på detaljerne om, hvad der skete, mens databasen imødekom anmodningen.

9. Patching

Tjek PostgreSQL's side med sikkerhedsoplysninger regelmæssigt og ofte for kritiske sikkerhedsopdateringer og patches.

Husk, at sikkerhedsfejl i operativsystemet eller biblioteker også kan føre til en databaselæk, så sørg for at holde patchen for disse opdateret.

ClusterControl leverer en driftsrapport, der giver dig disse oplysninger og vil udføre patches og opgraderinger for dig.

10. Sikkerhed på rækkeniveau

Ud over SQL-standard privilegiesystemet, der er tilgængeligt via GRANT, kan tabeller have rækkesikkerhedspolitikker, der begrænser, pr. bruger, hvilke rækker der kan returneres af normale forespørgsler eller indsættes, opdateres eller slettes af datamodifikationskommandoer. Denne funktion er også kendt som Row-Level Security.

Når rækkesikkerhed er aktiveret på en tabel, skal al normal adgang til tabellen til valg af rækker eller ændring af rækker tillades af en rækkesikkerhedspolitik.

Her er et simpelt eksempel på, hvordan man opretter en politik for kontorelationen, så kun medlemmer af administratorrollen får adgang til rækker og kun rækker af deres konti:

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å flere oplysninger om denne funktion i den officielle postgresql-dokumentation https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html

Hvis du gerne vil vide mere, er her nogle ressourcer, der kan hjælpe dig med bedre at styrke din databasesikkerhed...

• 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

Konklusion

Hvis du følger tipsene ovenfor, vil din server være mere sikker, men det betyder ikke, at den er ubrydelig.

For din egen sikkerhed anbefaler vi, at du bruger et sikkerhedstestværktøj som Nessus, for at vide, hvad dine vigtigste sårbarheder er, og forsøge at løse dem.

Du kan også overvåge din database med ClusterControl. Med dette kan du i realtid se, hvad der sker inde i din database, og analysere det.