Et udløbet TLS-certifikat forårsager normalt et driftsnedbrud: brugere kan ikke tilgå tjenesten, teams scrambler for at forny, tjenesten genoprettes. Men afhængigt af hvad der sker i den mellemliggende periode, kan den samme hændelse udgøre et databrud under GDPR — med 72-timers notifikationspligt og potentiel regulatorisk eksponering.
GDPR Artikel 32 kræver at organisationer implementerer passende tekniske foranstaltninger for at sikre et sikkerhedsniveau svarende til risikoen — inklusiv kryptering af personoplysninger. TLS-certifikater er den primære mekanisme der implementerer dette krav for data-in-transit. Når certifikater fejler, vakler krypteringslaget, og GDPR's forpligtelser begynder at gælde på måder som mange organisationer ikke har modelleret. Organisationer underlagt NIS2 bør også se vores artikel om NIS2 og certifikatstyring for de parallelle rapporteringskrav.
De fem fejlmodi og deres GDPR-implikationer
1. Udløbet certifikat → tjeneste utilgængelig. Browsere afviser forbindelser til tjenester med udløbne certifikater og viser advarsler som forhindrer brugere i at fortsætte. På overfladen er dette blot et nedbrud. GDPR-implikationen opstår hvis tjenesten behandler personoplysninger og nedbruddet forhindrer registrerede i at udøve rettigheder (adgang, sletning, portabilitet) inden for lovbestemte tidsfrister. Det er sjældent en anmeldelsespligtig hændelse i sig selv, men kan bidrage til akkumuleret overholdelseseksponering.
2. Udløbet certifikat → faldt tilbage til ukrypteret HTTP. Dette er den farlige konfiguration. Hvis en tjeneste er konfigureret til at acceptere HTTP-forbindelser som fallback, og certifikatet udløber, vil trafik automatisk tilbagevende til ukrypteret HTTP. Personoplysninger transmitteres nu i klartekst — et klassisk scenarie for "brud på sikkerheden af personoplysninger" som defineret i GDPR Artikel 4(12). 72-timers notifikation til tilsynsmyndighed gælder (Artikel 33). Notifikation til berørte personer kan kræves (Artikel 34).
3. Svag kryptografi. Et certifikat med 1024-bit RSA-nøgler, SHA-1-signatur eller forældet cipher suite implementerer teknisk set kryptering — men krypteringen er praktisk talt nedbrudt af nutidens standarder. Regulatorer begynder at betragte brug af forældet kryptografi som manglende overholdelse af Artikel 32's krav om "passende" tekniske foranstaltninger. Opdagelse af svag kryptografi hos en tilsynsmyndighed under et audit er et dårligt udgangspunkt for at demonstrere overholdelse.
4. Kompromitteret privat nøgle. Hvis en TLS privat nøgle eksponeres — via konfigurationsfejl, lagersikkerhedshændelse eller insider-trussel — er konsekvenserne alvorlige. En angriber med den private nøgle kan dekryptere tidligere optaget trafik (til den grad at forward secrecy ikke anvendes), udgive sig for serveren eller udføre man-in-the-middle angreb. Dette er et klart brud på sikkerheden af personoplysninger. Notifikation til tilsynsmyndighed er sandsynligvis påkrævet; notifikation til berørte personer afhænger af sandsynlighed og omfang af skade.
5. Svigagtig certifikatudstedelse. Hvis en angriber skaffer et certifikat til dit domæne fra en mis-udstedende CA, kan de implementere et man-in-the-middle angreb der er usynligt for brugere. Alle TLS-indikatorer vil se normale ud — hængelåsen vises, domænet matcher. Personoplysninger transmitteres til en angriberkontrolleret server. Dette er et alvorligt databrud med fuld notifikationspligt.
Hvornår er notifikation påkrævet
GDPR Artikel 33 kræver anmeldelse til tilsynsmyndigheden uden unødig forsinkelse og om muligt senest 72 timer efter at organisationen er blevet opmærksom på bruddet — medmindre det er usandsynligt, at bruddet indebærer en risiko for fysiske personers rettigheder eller frihedsrettigheder. Artikel 34 kræver underretning af de berørte personer hvis bruddet sandsynligvis vil indebære en høj risiko.
For certifikatrelaterede hændelser afhænger notifikationspligten primært af:
- Om personoplysninger faktisk var eksponeret, eller om potentiel eksponering var hypotetisk
- Eksponeringsvinduets varighed
- Følsomheden af de implicerede personoplysninger
- Sandsynlighed for at en angriber aktivt udnyttede vinduet
Et certifikat der udløb kl. 02:00 og fornyet kl. 02:15 på en intern tjeneste med minimal trafik er sandsynligvis ikke anmeldelsespligtigt. Et certifikat der tillod HTTP-fallback i 72 timer på en tjeneste der behandler sundhedsdata er klart anmeldelsespligtigt.
Praktiske skridt til at reducere jeres GDPR-eksponering
- Kortlæg personoplysningsstrømme til certifikat-endepunkter. Identificer hvilke endepunkter der transmitterer personoplysninger, og saml dem i en samlet TLS-certifikatoversigt. Disse er dine højeste prioriteter for certifikat-overvågning og korteste fornyelsesadvarsler.
- Håndhæv HTTPS og HSTS. Deaktiver HTTP som fallback. Implementer HSTS headers med lange max-age værdier. HSTS preloading forhindrer browsere i nogensinde at forsøge ukrypterede forbindelser.
- Overvåg alle endepunkter der behandler personoplysninger. Et certifikat I ikke ved eksisterer kan I ikke forny. CT-overvågning giver synlighed over certifikater udstedt til jeres domæner — inklusiv dem du måske ikke kendte til.
- Inkluder certifikat-hændelser i din brudsvurderingsproces. Din hændelsesrespons-runbook bør eksplicit adressere certifikatrelaterede hændelser og hvilke typer der udløser GDPR Artikel 33/34-notifikation.
- Dokumenter certifikat-kontroller i dit behandlingsregister. Artikel 30-registre bør inkludere certifikat-styring som en teknisk sikkerhedsforanstaltning. Dette demonstrerer accountability og giver en baseline for regulator-audits — se vores certifikatrevision-tjekliste for hvad revisorerne konkret beder om.
Hvad CertControl hjælper med
CertControl overvåger alle overvågede endepunkter for certifikat-tilstand og konfigurationsproblemer — udløb, svag kryptografi, ufuldstændige certifikatkæder og konfigurationer der tillader HTTP-fallback. Findings inkluderer GDPR-relevans-indikatorer: endepunkter der behandler personoplysninger vises med forhøjet alvorlighed, og fallback-til-HTTP-konfigurationer markeres som kritiske uanset certifikatets gyldighed.
Platformen vedligeholder en revisionslog over certifikat-tilstand over tid — så hvis en hændelse sker, har du en tidslinje over hvornår certifikater var gyldige, hvornår de udløb, og hvornår de blev fornyet. Denne dokumentation er værdifuld i enhver kommunikation med en tilsynsmyndighed.
Ofte stillede spørgsmål
Tæller et udløbet certifikat som et GDPR-databrud?
Det afhænger af fejlmodussen. Hvis certifikatet blot udløber og browsere afviser forbindelsen, udveksles der ingen data, og det er primært et tilgængelighedsnedbrud. Hvis tjenesten falder tilbage til ukrypteret HTTP og personoplysninger så transmitteres i klartekst, er det et brud på sikkerheden af personoplysninger der kan udløse anmeldelsespligt under artikel 33.
Hvornår starter GDPR's 72-timers frist?
Artikel 33 kræver anmeldelse til tilsynsmyndigheden uden unødig forsinkelse og om muligt senest 72 timer efter at organisationen bliver opmærksom på bruddet — medmindre det er usandsynligt, at bruddet indebærer en risiko for fysiske personers rettigheder. Fristen starter når organisationen bliver opmærksom, ikke når bruddet begyndte, men undersøgelsen af omfang og karakter skal stadig ske inden for det vindue.
Kan svag kryptografi i sig selv være et GDPR-problem?
Ja. Et certifikat med 1024-bit RSA-nøgler, SHA-1-signatur eller forældede cipher suites giver ikke meningsfuld kryptering over for en motiveret angriber. Regulatorer betragter i stigende grad brug af forældet kryptografi som manglende overholdelse af artikel 32's krav om passende tekniske foranstaltninger.
Hvordan reducerer HSTS certifikatrelateret GDPR-risiko?
HTTP Strict Transport Security med en lang max-age fortæller browsere at de skal afvise almindelige HTTP-forbindelser til jeres tjenester. Det forhindrer fallback-til-HTTP-fejlmodussen der gør et certifikatudløb til en databeskyttelseshændelse, fordi klienter ikke transmitterer personoplysninger i klartekst.
Hvad afgør om en certifikatfejl er anmeldelsespligtig?
Det afhænger primært af om personoplysninger faktisk var eksponeret, eksponeringsvinduets varighed, følsomheden af de implicerede oplysninger og sandsynligheden for at en angriber udnyttede vinduet. Et certifikat der udløb kl. 02:00 og blev fornyet kl. 02:15 på en intern tjeneste er sjældent anmeldelsespligtigt, mens 72 timers HTTP-fallback på en tjeneste med sundhedsdata klart er det.