Sikkerhed i PostgreSQL-databaser

Advarsel

Denne side refererer til sikkerhedstekniske termer og anbefalinger for egenkontrol og opsætning af PostGreSQL databaser. For yderligere information vedr. ‘Datatilsynet anbefalinger for logning af brugernes anvendelser af personoplysninger’, læs dette Link

Denne side giver et teknisk overblik over de sikkerhedsemner, der typisk er relevante at forholde sig til, når en PostgreSQL-database skal driftes lokalt i en kommune, herunder hvor databasen indeholder CPR-data og andre følsomme persondata. Siden er ikke en garanti for compliance, men et opslagsværk over de kontroller og mekanismer, som PostgreSQL stiller til rådighed, og som bør vurderes op imod kommunens egne sikkerhedskrav, risikovurderinger og databehandleraftaler.

Note

Leverancer af Geodata Connect / Kommune omfatter ikke installation og implementering af PostGreSQL database. For korrekt opsætning i hht. sikkerhedsnmæssig overholdelse og lokal styring af governance, henvises til at det er den interne IT medarbejdere der sikrer installation og aktivering.

Geopartner rådgiver og vejleder gerne inden for erfaringer og ‘best practice’.

Relevans for Geodata Connect-leverancer

Når Geodata Connect leverer data til en lokal PostgreSQL-database i kommunen, herunder data der kan indeholde eller kobles med CPR-data (fx via Ejerfortegnelsen eller Tingbogen), bør ovenstående emner - særligt adgangsbegrænsning, logning og databehandleraftaler - indgå i kommunens vurdering af databaseopsætningen, uanset om databasen driftes af kommunen selv eller af en ekstern driftsleverandør.

Sikkerhedsindsatser omkring persondata

Sikkerheden omkring persondata bygges typisk op i lag (“defense in depth”), hvor hvert lag skal kompromitteres, før data reelt kan tilgås uautoriseret. Dette skal ses som forslag til forebyggende indsatser og ikke som en udtømmende liste af forhold omkring informationssikkerhed.

Sikkerhedslag i en PostgreSQL-database

De enkelte lag i illustrationen er beskrevet nærmere herunder:

Governance & compliance

Databehandleraftaler, retsgrundlag, DPIA og slettepolitik - rammen der definerer, hvem der må behandle data, til hvilket formål og hvor længe.

Netværkssikkerhed

Segmentering, firewall-regler og TLS sikrer, at databasen kun kan tilgås fra betroede netværk og at trafikken er krypteret undervejs.

Adgangskontrol

Roller, mindste rettigheds princip, sikrer at kun autoriserede brugere/systemer kan se data - og kun det, de har behov for.

Kryptering

TLS i transit, disk-/filsystemkryptering at rest og evt. kolonnekryptering (pgcrypto) af fx CPR-numre beskytter data, selv hvis andre lag fejler.

Logning & audit

Forbindelses- og forespørgselslogning (evt. via pgaudit) går på tværs af alle lag og gør det muligt at dokumentere, hvem der har tilgået hvilke data.

Data omfattet GDPR i den lokale database

Da databasen kan rumme indehold, omfattet gældende regler iflg. databeskyttelsesforordningen (GDPR), er der en række tekniske forhold, som bør have særlig opmærksomhed:

Autentificering og adgangskontrol

Emne	Beskrivelse
Autentificeringsmetode	pg_hba.conf bør konfigureres til scram-sha-256 (ikke md5 eller trust), og adgang bør begrænses pr. IP/subnet, database og bruger
Rollemodel	Brug af navngivne, granulære roller frem for delte generiske brugere, samt adskillelse mellem applikations-, administrator- og læserettigheder
Mindste rettigheds princip	Applikationsroller bør kun have de rettigheder (SELECT/INSERT/UPDATE/DELETE), der er nødvendige på de specifikke skemaer/tabeller
Superuser-adgang	Antallet af konti med SUPERUSER-rettighed bør minimeres og aktivt overvåges
Row-Level Security	Kan anvendes til at begrænse adgang til rækker baseret på fx organisatorisk tilhørsforhold

Netværkssikkerhed

• Databasen bør som udgangspunkt ikke være tilgængelig direkte fra internettet, men kun fra definerede interne netsegmenter eller via VPN.
• Forbindelser bør kræve TLS/SSL (ssl = on i postgresql.conf), så data i transit er krypteret mellem klient og database.
• Netværkssegmentering og firewall-regler bør begrænse, hvilke servere/tjenester der overhovedet kan oprette forbindelse til databaseporten (som udgangspunkt 5432).
• Ved dataleverancer fra eksterne kilder (fx Geodata Connect) bør forbindelsen mellem kilde og mål ligeledes være krypteret og afgrænset til de nødvendige IP-adresser.

Kryptering af data

• I transit: TLS/SSL på forbindelsen mellem klient/applikation og database.
• At rest: PostgreSQL har ikke indbygget Transparent Data Encryption (TDE) som en del af kernen. Kryptering af data på disk opnås typisk via kryptering på filsystem- eller diskniveau (fx BitLocker, LUKS).
• Kolonnekryptering: Extension pgcrypto kan bruges til at kryptere udvalgte kolonner på applikations- eller databaselaget.
• Nøglehåndtering: Uanset krypteringsmetode bør der være en klar proces for opbevaring, rotation og adgang til krypteringsnøgler, adskilt fra selve databasen.

Logning og audit

Emne	Beskrivelse
Standardlogning	log_connections, log_disconnections og log_statement i postgresql.conf giver grundlæggende sporbarhed af forbindelser og forespørgsler
Udvidet audit-logning	Extension pgaudit giver mere detaljeret og strukturaret logning af DML/DDL-operationer, egnet til compliance- og revisionsformål
Central logopsamling	Logs bør sendes til et centralt log-/SIEM-system (SIEM=Security Information and Event Management), så de ikke kun findes lokalt på databaseserveren
Opbevaring af logs	Der bør defineres en opbevaringsperiode for logs, der matcher kommunens krav til sporbarhed og revision

Patch- og versionsstyring

• PostgreSQL bør holdes på en understøttet major-version, da ældre versioner udgår af support (End of Life) og ikke længere modtager sikkerhedsopdateringer.
• Sikkerhedsopdateringer (minor versions) bør løbende overvåges og installeres efter kommunens patch-proces.
• Der bør være en testet procedure for opgradering af major-versioner, herunder test af kompatibilitet med tilhørende extensions (fx PostGIS).

Backup, gendannelse og drift

• Der bør foreligge en testet backup- og gendannelsesstrategi (fx pg_dump, pg_basebackup kombineret med WAL-arkivering til Point-In-Time Recovery).
• Backupdata bør beskyttes med samme (eller strengere) sikkerhedsniveau som den oprindelige database, herunder kryptering og adgangsbegrænsning.
• Der bør være en dokumenteret procedure og et testet mål for gendannelsestid (RTO) og datatab (RPO), som er godkendt af kommunens IT-sikkerhedsansvarlige.

Miljøadskillelse

• Test-, udviklings- og produktionsmiljøer bør være adskilt, så data - ikke uforvarende kopieres til mindre sikrede test-/udviklingsmiljøer.
• Hvis testdata er nødvendige, bør følsomme felter anonymiseres eller pseudonymiseres, frem for at anvende reelle produktionsdata.

Compliance og referencerammer

Følgende referencerammer kan med fordel inddrages, når sikkerheden i en kommunal PostgreSQL-opsætning skal vurderes:

• ISO/IEC 27001, som mange kommuner allerede er certificeret efter eller arbejder ud fra.
• CIS Benchmarks for PostgreSQL, som indeholder konkrete, tekniske konfigurationsanbefalinger.
• Rammearkitekturen for den fælleskommunale digitalisering, som beskriver principper for informationssikkerhed på tværs af kommunale it-systemer.
• Databeskyttelsesforordningen (GDPR) og CPR-loven, som stiller specifikke krav til behandling af personoplysninger og CPR-numre, herunder krav om passende tekniske og organisatoriske sikkerhedsforanstaltninger.