Hoe u uw PostgreSQL-database kunt beveiligen - 10 tips

Nadat u het installatieproces van uw PostgreSQL-databaseserver hebt voltooid, moet u deze beveiligen voordat u in productie gaat. In dit bericht laten we u zien hoe u de beveiliging rond uw database kunt versterken om uw gegevens veilig te houden.

1. Controle clientverificatie

Bij het installeren van PostgreSQL wordt een bestand met de naam pg_hba.conf gemaakt in de datadirectory van het databasecluster. Dit bestand regelt de clientauthenticatie.

Uit de officiële postgresql-documentatie kunnen we het bestand pg_hba.conf definiëren als een set records, één per regel, waarbij elk record een verbindingstype specificeert, een client IP-adresbereik (indien relevant voor het verbindingstype), een databasenaam, een gebruikersnaam en de authenticatiemethode die moet worden gebruikt voor verbindingen die overeenkomen met deze parameters. Het eerste record met een overeenkomend verbindingstype, clientadres, aangevraagde database en gebruikersnaam wordt gebruikt om authenticatie uit te voeren.

Het algemene formaat zal er dus ongeveer zo uitzien:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

Een voorbeeld van een configuratie kan als volgt zijn:

# 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

Er zijn veel combinaties die u kunt maken om de regels te verfijnen (de officiële documentatie beschrijft elke optie in detail en heeft enkele geweldige voorbeelden), maar vergeet niet om regels te vermijden die te tolerant zijn, zoals toegang verlenen voor lijnen met DATABASE all of ADDRESS 0.0.0.0/0.

Om de veiligheid te garanderen, kunt u, zelfs als u vergeet een regel toe te voegen, de volgende rij onderaan toevoegen:

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

Omdat het bestand van boven naar beneden wordt gelezen om overeenkomende regels te vinden, zorgt u er op deze manier voor dat u voor het toestaan ​​van toestemming de bovenstaande overeenkomende regel expliciet moet toevoegen.

2. Serverconfiguratie

Er zijn enkele parameters op postgresql.conf die we kunnen wijzigen om de beveiliging te verbeteren.

U kunt de parameter listen_address gebruiken om te bepalen welke ips verbinding mogen maken met de server. Hier is een goede gewoonte om alleen verbindingen toe te staan ​​vanaf de bekende ips of uw netwerk, en vermijd algemene waarden zoals "*"",0.0.0.0:0" of "::", die PostgreSQL vertellen om verbinding vanaf elk IP-adres te accepteren.

Het wijzigen van de poort waarop postgresql zal luisteren (standaard 5432) is ook een optie. U kunt dit doen door de waarde van de poortparameter te wijzigen.

Parameters zoals work_mem, maintenance_work_mem, temp_buffer , max_prepared_transactions, temp_file_limit zijn belangrijk om in gedachten te houden voor het geval u een denial of service-aanval krijgt. Dit zijn statement-/sessieparameters die op verschillende niveaus kunnen worden ingesteld (db, gebruiker, sessie), dus als we deze verstandig beheren, kunnen we de impact van de aanval minimaliseren.

3. Gebruikers- en rolbeheer

De gouden regel voor beveiliging met betrekking tot gebruikersbeheer is om gebruikers de minimale hoeveelheid toegang te verlenen die ze nodig hebben.

Dit beheren is niet altijd gemakkelijk en het kan erg rommelig worden als het vanaf het begin niet goed wordt gedaan.

Een goede manier om de privileges onder controle te houden is om de rol, groep, gebruikersstrategie te gebruiken.

In postgresql wordt alles als een rol beschouwd, maar we gaan hier enkele wijzigingen in aanbrengen.

In deze strategie creëer je drie verschillende typen of rollen:

• rol rol (geïdentificeerd door prefix r_)
• groepsrol (geïdentificeerd door voorvoegsel g_)
• gebruikersrol (meestal persoonlijke of applicatienamen)

De rollen (r_ rollen) zullen degenen zijn die de privileges hebben over de objecten. De groepsrollen (g_rollen) worden toegekend met de r_rollen, dus het wordt een verzameling van r_rollen. En tot slot zullen de gebruikersrollen worden toegekend met een of meer groepsrollen en zullen degenen zijn met het inlogrecht.

Laten we hier een voorbeeld van laten zien. We zullen een alleen-lezen groep maken voor het example_schema en deze vervolgens aan een gebruiker toekennen:

We creëren de alleen-lezen rol en verlenen de objectrechten eraan

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;

We maken de alleen-lezen groep aan en kennen de rol toe aan die groep

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

We maken de app_user-rol en maken deze "aangesloten" bij de alleen-lezen groep

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;

Met deze methode kunt u de granulariteit van de privileges beheren en kunt u eenvoudig groepen toegang verlenen en intrekken aan de gebruikers. Vergeet niet om alleen objectrechten toe te kennen aan de rollen in plaats van dit rechtstreeks voor de gebruikers te doen en om het inlogprivilege alleen aan de gebruikers te verlenen.

Dit is een goede gewoonte om openbare privileges voor de objecten expliciet in te trekken, zoals de openbare toegang tot een specifieke database intrekken en deze alleen via een rol toekennen.

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

Beperk SUPERUSER-toegang, sta superuser-verbindingen alleen toe vanaf het localhost/unix-domein.

Gebruik specifieke gebruikers voor verschillende doeleinden, zoals specifieke app-gebruikers of back-upgebruikers, en beperk de verbindingen voor die gebruiker alleen vanaf de vereiste ips.

4. Supergebruikersbeheer

Het handhaven van een sterk wachtwoordbeleid is een must om uw databases veilig te houden en wachtwoordhacks te voorkomen. Gebruik voor een sterk beleid bij voorkeur speciale tekens, cijfers, hoofdletters en kleine letters en gebruik minimaal 10 tekens.

Er zijn ook externe authenticatietools, zoals LDAP of PAM, die u kunnen helpen ervoor te zorgen dat uw wachtwoord verloopt en het beleid opnieuw wordt hergebruikt, en ook om accountvergrendeling bij authenticatiefouten af ​​te handelen.

5. Gegevenscodering (op verbinding ssl)

PostgreSQL heeft native ondersteuning voor het gebruik van SSL-verbindingen om client/server-communicatie te versleutelen voor een betere beveiliging. SSL (Secure Sockets Layer) is de standaard beveiligingstechnologie voor het tot stand brengen van een versleutelde verbinding tussen een webserver en een browser. Deze koppeling zorgt ervoor dat alle gegevens die tussen de webserver en browsers worden uitgewisseld privé en integraal blijven.

Aangezien postgresql-clients query's in platte tekst verzenden en gegevens ook onversleuteld worden verzonden, is het kwetsbaar voor netwerkspoofing.

U kunt SSL inschakelen door de ssl-parameter aan te zetten in postgresql.conf.

De server luistert naar zowel normale als SSL-verbindingen op dezelfde TCP-poort en onderhandelt met elke verbindende client over het al dan niet gebruiken van SSL. Standaard is dit naar de keuze van de klant, maar u hebt de mogelijkheid om de server zo in te stellen dat het gebruik van SSL vereist is voor sommige of alle verbindingen met behulp van het hierboven beschreven pg_hba-configuratiebestand.

6. Gegevenscodering in rust (pg_crypto)

Er zijn twee basissoorten encryptie, eenrichtingsverkeer en tweerichtingsverkeer. Op de een of andere manier geeft u er nooit om de gegevens in een leesbare vorm te decoderen, maar u wilt alleen verifiëren dat de gebruiker weet wat de onderliggende geheime tekst is. Dit wordt normaal gesproken gebruikt voor wachtwoorden. Bij tweerichtingsversleuteling wilt u de mogelijkheid hebben om gegevens te versleutelen en geautoriseerde gebruikers toe te staan ​​deze in een zinvolle vorm te ontsleutelen. Gegevens zoals creditcards en SSN's vallen in deze categorie.

Voor eenrichtingscodering biedt de crypt-functie die is verpakt in pgcrypto een extra beveiligingsniveau boven de md5-manier. De reden is dat je met md5 kunt zien wie hetzelfde wachtwoord heeft omdat er geen salt is (in cryptografie is een salt willekeurige gegevens die worden gebruikt als extra invoer voor een eenrichtingsfunctie die gegevens "hashet", een wachtwoord of wachtwoordzin), zodat alle mensen met hetzelfde wachtwoord dezelfde gecodeerde md5-tekenreeks hebben. Met crypt zullen ze anders zijn.

Voor gegevens die u graag wilt ophalen, wilt u niet weten of de twee stukjes informatie hetzelfde zijn, maar u kent die informatie niet en u wilt dat alleen geautoriseerde gebruikers deze kunnen ophalen. Pgcrypto biedt verschillende manieren om dit te bereiken, dus voor meer informatie over het gebruik ervan kunt u de officiële postgresql-documentatie raadplegen op https://www.postgresql.org/docs/current/static/pgcrypto.html.

7. Loggen

Postgresql biedt een breed scala aan configuratieparameters om te bepalen wat, wanneer en waar te loggen.

U kunt sessieverbinding/-ontkoppelingen, langlopende query's, tijdelijke bestandsgroottes enzovoort inschakelen. Dit kan u helpen een betere kennis van uw werklast te krijgen om vreemd gedrag te identificeren. U kunt alle opties voor inloggen krijgen via de volgende link https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html

Voor meer gedetailleerde informatie over uw werklast kunt u de module pg_stat_statements inschakelen, die een manier biedt om uitvoeringsstatistieken bij te houden van alle SQL-instructies die door een server worden uitgevoerd. Er zijn enkele beveiligingstools die de gegevens uit deze tabel kunnen opnemen en een sql-witte lijst kunnen genereren om u te helpen bij het identificeren van zoekopdrachten die niet de verwachte patronen volgen.

Voor meer informatie https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.

8. Controle

De PostgreSQL Audit Extension (pgAudit) biedt gedetailleerde sessie- en/of object-auditregistratie via de standaard PostgreSQL-registratiefaciliteit.

Basisregistratie van verklaringen kan worden geleverd door de standaardregistratiefunctie met log_statement =all. Dit is acceptabel voor monitoring en ander gebruik, maar biedt niet het detailniveau dat doorgaans vereist is voor een audit. Het is niet voldoende om een ​​lijst te hebben van alle bewerkingen die op de database zijn uitgevoerd. Ook moet het mogelijk zijn om bepaalde uitspraken te vinden die voor een accountant van belang zijn. De standaard logfunctie laat zien wat de gebruiker heeft gevraagd, terwijl pgAudit zich richt op de details van wat er is gebeurd terwijl de database aan het verzoek voldeed.

9. Patchen

Controleer de beveiligingsinformatiepagina van PostgreSQL regelmatig en regelmatig voor kritieke beveiligingsupdates en patches.

Houd er rekening mee dat beveiligingsbugs in het besturingssysteem of bibliotheken ook kunnen leiden tot een databaselek, dus zorg ervoor dat u de patches hiervoor up-to-date houdt.

ClusterControl levert een operationeel rapport dat u deze informatie geeft en de patches en upgrades voor u zal uitvoeren.

10. Beveiliging op rijniveau

Naast het SQL-standaard privilegesysteem dat beschikbaar is via GRANT, kunnen tabellen een rijbeveiligingsbeleid hebben dat per gebruiker beperkt welke rijen kunnen worden geretourneerd door normale query's of kunnen worden ingevoegd, bijgewerkt of verwijderd door gegevenswijzigingsopdrachten. Deze functie wordt ook wel beveiliging op rijniveau genoemd.

Wanneer rijbeveiliging op een tabel is ingeschakeld, moet alle normale toegang tot de tabel voor het selecteren van rijen of het wijzigen van rijen worden toegestaan ​​door een rijbeveiligingsbeleid.

Hier is een eenvoudig voorbeeld van hoe u een beleid voor de accountrelatie kunt maken om alleen leden van de beheerdersrol toegang te geven tot rijen en alleen tot rijen van hun accounts:

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);

U kunt meer informatie over deze functie krijgen in de officiële postgresql-documentatie https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html

Als u meer wilt weten, vindt u hier enkele bronnen die u kunnen helpen uw databasebeveiliging beter te versterken...

• 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

Conclusie

Als u de bovenstaande tips opvolgt, is uw server veiliger, maar dit betekent niet dat deze onbreekbaar is.

Voor uw eigen veiligheid raden we u aan een beveiligingstesttool zoals Nessus te gebruiken, om te weten wat uw belangrijkste kwetsbaarheden zijn en deze proberen op te lossen.

U kunt uw database ook monitoren met ClusterControl. Hiermee kunt u in realtime zien wat er in uw database gebeurt en deze analyseren.