Privatlivets ukrænkelige ret – når systemerne selv krænker

Når vi taler om retten til privatliv som “ukrænkelig”, lyder det i idealistisk forstand smukt. Men i praksis presses grænsen konstant — ikke kun af hackere og kriminelle, men af systemfejl, interne misbrug, leverandører og infrastrukturer, som vi ikke selv styrer fuldt ud.

Hvis vi tager dine fire skarpe spørgsmål som ramme, kan vi konkret vise: dette er ikke hypotetisk frygt – det sker lige nu, med vores data.

1. Hvem hoster infrastrukturen? (Azure, AWS, GCP …) og hvor går det galt?

Case: Microsoft og angreb fra “Midnight Blizzard”

I begyndelsen af 2024 blev Microsoft ramt af et angreb fra en statsstøttet aktør, som de kalder Midnight Blizzard (også kendt under aliaser som APT29, Cozy Bear). Microsoft Obsidian ZScaler

Angrebet benyttede en ældre, ikke-produktions testtenant, som ikke havde mange sikkerhedsforanstaltninger, og nåede via en kæde af OAuth-applikationer og delegation at kompromittere e-mails i Microsofts virksomhedsdomæne – herunder hos ledende medarbejdere. Microsoft Wiz

Det viser tydeligt: selv leverandører som Microsoft – der hoster massiv infrastruktur – kan blive indgangspunkt for kompromis. Det illustrerer også, at infrastrukturen ikke er neutral – hvis sikkerhedspraksis underlægges svagheder, rammes hele kæden.

Der er ikke dokumenteret tegn på, at kunders produktionsmiljøer hos Microsoft blev kompromitteret i dette tilfælde, men ydmygelsen ligger i at opretholde sikkerheden selv i “internal” systemer.

Det hjælper ikke at vælge “Azure/Google/AWS” som mantra — sikkerheden afhænger i høj grad af hvordan infrastrukturen konfigureres, isoleres og styres.

2. Hvor lagres metadataen? (DK, EU, USA …) – hvilke datastrømme rækker ud over grænserne?

Case: NewtoDenmark / NemLog-in og CPR-logging

I perioden 2. april 2019 til 13. september 2021 loggede systemer hos Ny i Danmark og SIRI CPR-numre via NemLog-in, fordi et test-logningssystem ikke blev slået fra, da det gik i produktion.
Disse logfiler var i et tidsrum offentligt tilgængelige via en webadresse, før systemet blev lukket.
Myndighederne erkendte fejlen og fjernede logfilerne med intervaller (mellem 20 min og to timer) — men de erkendte samtidig, at de ikke med fuld sikkerhed kunne fastslå, om uvedkommende havde haft adgang imellem. Ny i Danmark

Case: Dansk TastSelv / CPR-læk til Google & Adobe

I 2020 blev cirka 1,2 millioner danskere udsat for, at deres CPR-numre uforvarende blev sendt til Google og Adobe som del af URL-parameter i en webanmodning i forbindelse med TastSelv (skatteportal).
Fejlen skyldtes at webadressen (URL) i en opdateringsfunktion inkluderede CPR-nummeret og blev sendt videre til eksterne biblioteker (Google Hosted Libraries / Adobe).
Selvom myndighederne hævdede, at data var “krypterede” eller anonymiserede, blev begivenheden behandlet som en alvorlig sag om utilsigtet overførsel af identificerbare data til tredjepart uden at have kontrolleret lagringssted eller kontraktuelle sikringer tilstrækkeligt. Security Affairs

Metadata og sekundære data strømmer ofte udover nationale grænser – utilsigtet eller planlagt – og det er netop i disse “grey zones”, at privatliv ofte undermineres.

3. Underleverandører og backend-adgang: antivirus, CDN, analytics, push osv.

SDK’er og analytics som skjulte porte

Mange apps bruger tredjepartssdk’er til analytics, crash reports og push-notifikationer. Disse SDK’er opererer ofte med adgang til metadata, device-ID’er, tidsstempler og kontekstinformation.
I praksis kan de fungere som “stille databehandlere” – de får adgang, men offentligheden ser dem sjældent som “databehandlere” med fuld ansvar.

Eksempel: Firebase / Google’s backend har gentagne gange været genstand for sager om fejlkontrolleret database (misconfiguration) – hvor apps utilsigtet eksponerede data for tredjepartens infrastruktursiden. (Der er mange offentlige rapporter om Firebase læk på mobilapps)

Push-notifikationsteknologier (APNs, FCM) kan i visse tilfælde lække metadata (f.eks. hvilket device-id, hvilket tidspunkt, hvilke kanaler) som kan korrelere med brugeradfærd. (Forskning i sikre beskedapps har vist, at pushinfrastruktur kan afsløre “hvilken bruger modtog besked til hvilket tidspunkt.”)

Desuden kan CDN/Cache-leverandører, crashlytics-tjenester og CDN-front-end-leverandører få adgang til request-metadata (IP, headers, enhedsinfo), som kan opsamles, aggregeres og bruges til profilering.

4. Identifikatorer: UUID’er, device fingerprints og tvær-app-spor

Mobile annoncenetværk og ID’er

I mobilannoncemiljøer bruges “MAID” (Mobile Advertising ID, f.eks. IDFA på iOS eller GAID på Android) som en standard identifikator for at spore brugere tværs af apps.
I Norge fik Grindr en bøde, fordi man delte bruger-annoncetjeneste-ID’er, der kunne kombineres med følsomme oplysninger – i overensstemmelse med teorien om, at disse ID’er ikke er trivielt anonyme. (Norsk DPA-sag mod Grindr) Wikipedia Syteca

Lokations-SDK’er og datameglere

Flere analyser har vist eksempler, hvor apps integrerer SDK’er, som indsamler lokationsdata og assosierende device-id’er, og disse data videreformidles til datameglere og analytiske infrastrukturer. I USA har FTC indgrebet mod X-Mode (location data broker) vist, at lokationsdata med enhedsid kan sælges og spredes til tredjepartsaktører. (FTC-sagen mod X-Mode)

Kombinationen af device-id, tidsstempel og adfærdsmønstre kan gøre “anonymisering” hul i praksis — man kan matche poster på tværs af apps og sessions.

5. Insider-misbrug og lukkede systemer brudt indefra

Selv det mest “lukket” system er potentielt udsat — for medarbejdere med adgang kan misbruge, lække eller sælge data.

Case: Lyngby-Taarbæk Kommune

Lyngby-Taarbæk Kommune blev pålagt en bøde (DKK 350.000–400.000) fordi omkring 1.000 tidligere ansatte fortsat havde adgang til systemer, som indeholdt persondata, efter ansættelsen ophørte.
Det viser, at adgangsstyring ikke blev lukket tilstrækkeligt – og at tidligere ansatte potentielt kunne have misbrugt adgangen. Global Relay Intelligence & Practice

Case: Aalborg Universitet (AAU) CPR-fil ukrydset

AAU oplyste, at de havde haft en fil med over 60.000 CPR-numre i deres system, uden restriktioner over adgang i to år.
Selvom universitetet vurderede, at der ikke var tegn på misbrug, udstilles risikoen: medarbejdere kunne have læst eller kopieret disse numre — og systemet havde ikke logs eller begrænset adgang til at forhindre eller spore misbrug. Aalborg University

Case: “7 Insider Threats” eksempler

Flere udvalgte cases (f.eks. medarbejdere i luftfartsvirksomheder, finanssektoren) fremhæves i branchen som klassiske eksempler på, hvordan interne medarbejdere (med viden om systemernes struktur) eksporterer eller kopierer sensitive data. Syteca

Overordnet analyse og skæbneveje

Når vi samler alle disse eksempler og peger på dine fire spørgsmål, fremstår et mønster:

Hosting valg fritslår ikke sikkerhed: Selv leverandører som Microsoft kan kompromitteres – og leverandørers interne systemer er lige så sårbare som kundesystemerne.
Data- og metadataflyt er en kerne-risiko: Selvom data fysisk ligger i Danmark eller EU, kan metadata og logfiler strømme udenfor, utilsigtet eller via tredjepartssdk’er.
Backend og underleverandører er “skjulte behandlere”: Mange adgangspunkter (analytics, push, crashlytics, CDN) har reelt adgang til data og metadata – og kan fungere som “bagdøre.”
Device-id’er og fingerprint-teknikker underminerer anonymitet: Selv hvis data anonymiseres, kan kombinationen af tidsstempler, enheds-ID’er og mønstre lede til reidentifikation.
Indersiden er den mest oversete trussel: Selv teknologisk stærke systemer kan angribes indefra, hvis adgangsstyring, logning og “least privilege” ikke er håndhævet streng nok.

Derfor bør enhver digital ID-arkitektur, digital bevis-app eller national infrastruktur designes med disse præmisser:

Sikkerhed må bygges fra bunden og antage, at både interne og eksterne trusler eksisterer.
Systemarkitektur bør være modulær, isoleret og auditerbar — man bør kunne se dataflows, ansvarlige parter og adgangslinjer.
Transparens: borgere bør kunne få indsigt i hvilke underleverandører, cloud-leverandører og data-lag, som anvendes.
Logning og adgangskontrol skal være granulære og immutable (fx audittrails, zero-trust principper).
Adgang til device-id’er og SDK’er skal reguleres stramt – så annoncører og logtjenester ikke bliver skjulte bagmænd.

📡 Digital suverænitet var engang et mål – nu er det bare et hashtag.

Vores data er ikke bare “data” – de er os.
Når vi beder om digital identifikation, aldersbevis, sundhedsbeviser og alt andet i én app, overlader vi ikke kun kontrol – vi binder os til arkitektur, leverandører og teknologi, vi sjældent ser og endnu sjældnere forstår.

Hvis staten lancerer et økosystem for digital identitet, skal det være ærligt, gennemsigtigt og ansvarligt.
Lad os kræve:

At få vist arkitekturen.
At se leverandør-kæden.
At kende dataresidensen.
At medier og borgere kan auditere (f.eks. via uafhængige sikkerhedsrevisioner).

Ellers risikerer vi, at privatlivets “ukrænkelige” ret sakte bliver til en illusion.