GDPR og Databeskyttelse i Danmark: Et IT-sikkerhedsperspektiv

Som IT-sikkerhedsprofessionel i Danmark er det helt essentielt at have en solid forståelse for både GDPR (Databeskyttelsesforordningen) og den supplerende danske Databeskyttelseslov. Vi er ofte dem, der i praksis skal sikre, at organisationens systemer overholder de juridiske krav til behandling af persondata.

I denne artikel gennemgår vi de vigtigste koncepter fra lovgivningen samt principper fra anerkendt faglitteratur (Pedersen22, kap. 10 og Pfleeger, kap. 9 til 9.3), og hvordan de omsættes til praktisk IT-sikkerhed.

1. Lovgrundlaget: GDPR og Databeskyttelsesloven

GDPR (General Data Protection Regulation) er en EU-forordning, der trådte i kraft i maj 2018. Den gælder direkte i alle EU-lande og sætter en fælles, høj standard for beskyttelse af fysiske personers rettigheder.

Den danske Databeskyttelseslov supplerer og præciserer GDPR i en dansk kontekst (f.eks. angående alder for samtykke for børn og specifikke regler for behandling af CPR-numre, som er en national særregel).

Centrale roller

For at forstå ansvaret i IT-systemer, skal man kende to hovedroller:

  • Dataansvarlig (Data Controller): Den enhed (f.eks. en virksomhed), der bestemmer formålet med og midlerne til behandling af personoplysninger.
  • Databehandler (Data Processor): En enhed (f.eks. en cloud-udbyder eller et IT-konsulenthus), der behandler personoplysninger på vegne af den dataansvarlige. Behandlingen reguleres af en Databehandleraftale (DPA).

2. IT-sikkerhedskravene i GDPR (Artikel 32)

GDPR’s Artikel 32 stiller krav om “Behandlingssikkerhed”. Her slås det fast, at der skal implementeres “passende tekniske og organisatoriske foranstaltninger” for at sikre et sikkerhedsniveau, der passer til de aktuelle risici.

Dette understøttes direkte af “CIA-triaden”, som gennemgås indgående i faglitteraturen:

  1. Confidentiality (Fortrolighed): Sikring mod uautoriseret adgang til persondata. Metoder inkluderer stærk adgangskontrol (MFA), kryptering (både at-rest og in-transit) og pseudonymisering.
  2. Integrity (Integritet): Beskyttelse mod at oplysningerne ændres uautoriseret eller går tabt utilsigtet. Implementeres via backups, checksums og audit logs.
  3. Availability (Tilgængelighed): Evnen til rettidigt at genoprette adgangen til oplysningerne i tilfælde af et fysisk eller teknisk nedbrud. Dette kræver robust infrastruktur, Disaster Recovery (DR)-planer og redundans.

Disse principper afspejler tydeligt pointerne i Pfleeger, kap. 9, som omhandler “Privacy and Anonymity” samt “Database Security”, hvor det påpeges, at privatliv (privacy) kræver asymmetrisk dataminimering – man samler kun dét ind, man strict har brug for.

3. Privacy by Design og Privacy by Default

Ifølge Pedersen22 (kap. 10), der fokuserer på de praktiske organisatoriske aspekter af sikkerhed, understøtter GDPR “Privacy by Design” (Databeskyttelse gennem design) og “Privacy by Default” (Databeskyttelse gennem standardindstillinger).

Som IT-sikkerhedsprofessionelle skal vi sikre, at systemer fra fødslen (i arkitektur-fasen) bygges med databeskyttelse for øje:

  • Dataminimering: Indsaml kun de oplysninger, der er strengt nødvendige. Hvis vi ikke behøver en brugers fødselsdato, skal vi ikke designe databasen til at gemme den.
  • Automatisk sletning (Retention): Implementer rutiner, der automatisk sletter eller anonymiserer data, når de ikke længere er nødvendige for deres oprindelige formål.
  • Standardindstillinger: Brugerens data skal som standard have det mest restriktive privatlivsniveau (f.eks. skal et socialt system som udgangspunkt være ‘privat’ frem for ‘offentligt’).

4. Håndtering af brud (Data Breach)

Når teknologierne fejler, træder de organisatoriske rutiner (“Incident Response”) i kraft. GDPR fastslår, at et brud på persondatasikkerheden skal anmeldes til tilsynsmyndigheden (i Danmark: Datatilsynet) uden unødig forsinkelse og om muligt inden 72 timer, medmindre det er usandsynligt, at bruddet indebærer en risiko for de registreredes rettigheder.

Som teknisk ekspert skal man derfor designe systemer, der proaktivt understøtter opdagelse af brud (kompromittering, ransomware, data exfiltration) gennem:

  • SIEM (Security Information and Event Management)
  • Nettrafik-monitorering (DPI, IDS/IPS)
  • Effektiv log-håndtering

Konklusion

Compliance er ikke udelukkende en juridisk øvelse. Som IT-professionel fungerer loven (GDPR og Databeskyttelsesloven) som rammeværket, mens litteratur som Pedersen22 og Pfleeger giver os metoderne til implementering. Vores opgave er at bygge broen mellem juraen og databasen gennem kryptering, adgangskontrol, dataminimering og robust beredskab.

Kilder

> Quiz: Test din viden

1. Hvad er de tre krav i CIA-triaden, som GDPR Artikel 32 stiller?

2. Hvad bestemmer en Dataansvarlig i modsætning til en Databehandler?

3. Hvad skal Privacy by Design bygges ind fra?

4. Hvad kræver GDPR Artikel 32 ud over CIA-triaden?