Sikkerhed og data

Kryptering af data i en app: HTTPS, lagring og nøgler

“Data er krypteret” er først et brugbart svar, når I ved hvilke data, hvor de ligger, hvem der har nøglen, og hvad beskyttelsen ikke dækker. De fleste cloudtjenester kan klare meget af grundarbejdet, men appen skal stadig beskytte forbindelser, kopier, adgange og nøgler gennem hele dataflowet.

Udgivet 27. september 2026 · Ca. 12 minutters læsetid

Kryptering beskytter bestemte risici – ikke hele appen

Kryptering gør læsbare data uforståelige uden den rette nøgle. Beskyttelsen er vigtig, men dens effekt afhænger af, hvor nøglen findes, og hvor i datarejsen krypteringen sker. En kompromitteret brugerkonto eller backend kan ofte stadig læse data gennem appens normale funktioner, selv om disken er krypteret.

Lag	Beskytter især mod	Beskytter ikke alene mod
Under transport	Aflytning og ændring på netværket	En angriber med gyldig bruger- eller serveradgang
I hvile	Eksponeret lager, disk, snapshot eller backup uden nøgle	For brede roller eller et lækket database-login
I appen	Udvalgte følsomme felter, også over for dele af platformen	Kode eller proces, der både kan hente data og bruge nøglen

Adgangskontrol, logning, sikker kode, backup og beredskab er derfor stadig nødvendige. Kryptering er ét lag i et forsvar, ikke en erstatning for de andre.

Kortlæg alle steder data bliver læsbare

Begynd med et konkret dataflow for de mest følsomme oplysninger. Følg for eksempel en medarbejders CPR-nummer, en kundekontrakt eller en API-nøgle fra indtastning til sletning. Markér både den primære database og alle kopier.

Browser og enhed: formularfelter, lokal lagring, downloads, cache og midlertidige filer.
Forbindelser: browser til API, backend til database og trafik til mail-, betalings- og integrationsleverandører.
Vedvarende lagring: database, filområde, søgeindeks, analyseplatform og jobkø.
Driftskopier: backups, snapshots, replikaer, logs, fejlsporing, eksportfiler og supportudtræk.
Nøgler og adgang: hvem eller hvad kan dekryptere, og fra hvilke miljøer?

Hvis kun databasen er dokumenteret, er svaret ufuldstændigt. Den mest ubeskyttede kopi kan være en eksport i en fælles mappe eller en fuld request i fejlsporing.

Brug krypterede forbindelser hele vejen

HTTPS bruger TLS til at beskytte trafikken mellem browser og webtjeneste. OWASP anbefaler TLS på alle sider, ikke kun login. Samme princip gælder forbindelser bag frontend: API'er, databaser, webhooks og integrationskald skal afvise ukrypteret transport, hvor tjenesten understøtter det.

Kontrollér alle offentlige adresser. HTTP skal omdirigeres sikkert eller afvises, og certifikatet skal dække de domæner, brugerne faktisk åbner.
Kontrollér de skjulte forbindelser. Gennemgå database-URL, kø, objektlager og leverandørendpoints – et HTTPS-ikon i browseren siger intet om dem.
Lad platformen håndtere moderne TLS, når det er muligt. Dokumentér hvor certifikater fornyes, og hvordan fejl varsles.
Brug HSTS bevidst. Headeren kan få browsere til kun at bruge HTTPS, men domæner og underdomæner skal være klar, før en bred politik låses fast.

HTTPS beskytter ikke data efter modtagelse. Når backend har dekrypteret requesten, kan den stadig ende i en log, database eller backup. Hvert efterfølgende lag skal vurderes særskilt.

Bekræft platformens kryptering i hvile

Mange managed cloudtjenester krypterer lagrede data automatisk. Google Cloud beskriver standardkryptering af kundeindhold i hvile, Cloud Firestore krypterer data før de skrives til disk, og Azure beskriver både tjenesteadministrerede og kundeadministrerede nøgler. Det er nyttigt, men I skal kontrollere den konkrete tjeneste, plan, region og ressource – ikke antage at én platformsætning dækker alt.

Platformnøgle: Lavere driftsbyrde. Leverandøren beskytter og roterer nøglerne efter tjenestens model.
Kundestyret nøgle: Mere kontrol over adgang, deaktivering og revision, men også ansvar for tilgængelighed, rotation og recovery.
App-kryptering: Appen krypterer udvalgte værdier før lagring. Kan mindske nogle trusler, men gør søgning, indekser, fejlfinding og nøglehåndtering sværere.

Vælg ikke kundestyrede nøgler eller feltkryptering kun fordi det lyder stærkere. Beskriv først truslen og kravet. Ekstra nøglekontrol kan forbedre sikkerheden, men en slettet, deaktiveret eller utilgængelig nøgle kan også gøre virksomhedens egne data ulæselige.

Hold nøglen adskilt fra de krypterede data

Hvis appen selv krypterer data, må den aktive nøgle ikke ligge i frontend, samme databasetabel eller en fil i repository. Brug den sikre nøgle- eller secret-tjeneste, som jeres cloud eller platform stiller til rådighed, og giv kun den relevante backendidentitet adgang.

Adskil miljøer. Test og produktion skal ikke kunne dekryptere hinandens data.
Gem nøgleversion med ciphertext. Appen skal vide, hvilken godkendt nøgleversion der kan læse ældre data under rotation.
Brug gennemprøvede biblioteker og authenticated encryption. Opfind ikke algoritme, nonceformat eller nøgleafledning selv.
Begræns og log nøglebrug. En deployproces behøver ikke nødvendigvis samme dekrypteringsadgang som runtime.
Planlæg recovery før rotation. Dokumentér hvad der sker med gamle backups, købeskeder og data fra en tidligere nøgleversion.

En rotation er først bevist, når et isoleret miljø kan skrive med den nye nøgle, læse nødvendige ældre data og håndtere en utilgængelig nøgle uden skjult datatab.

Passwords skal hashes – ikke kunne dekrypteres

En app skal normalt aldrig kunne vise brugerens oprindelige password. OWASP anbefaler en moderne, langsom password-hash gennem en afprøvet identitetsløsning eller et egnet bibliotek – ikke reversibel kryptering og ikke en hurtig, almindelig hash alene.

Bruger I Firebase Authentication, Microsoft Entra ID, Supabase Auth eller en anden managed identitetstjeneste, bør appen normalt lade den tjeneste håndtere passwordet. Kortlæg stadig nulstilling, MFA, sessioner og kontogendannelse; kryptering af databasen gør ikke loginflowet sikkert af sig selv.

Typiske fejl og deres konsekvens

“Cloud betyder krypteret”: Backups, logs, eksportfiler eller en ekstern tjeneste er aldrig blevet kontrolleret.
Nøglen ligger ved siden af data: Samme databaseudtræk eller repository indeholder både ciphertext og vejen til at dekryptere det.
Frontend har hemmeligheden: Alt, der sendes til browseren, kan i praksis læses af brugeren eller misbruges ved en browserfejl.
Egen kryptografi uden plan: Forkert bibliotek, genbrugte værdier eller manglende integritetskontrol kan gøre beskyttelsen falsk.
Rotation er kun en kalenderaftale: Ingen ved, om ældre data og backups kan læses efter skiftet.
Kryptering bliver lig med GDPR: Behandlingsgrundlag, dataminimering, slettefrister, adgang og databehandleraftaler er stadig selvstændige krav.

En praktisk kontrol I selv kan gennemføre

1. Vælg ét følsomt dataflow. Følg alle forbindelser, lagre og kopier fra indsamling til sletning.
2. Saml bevis pr. led. Gem link til leverandørdokumentation, ressourceindstilling og ansvarlig – aldrig selve nøglen.
3. Kontrollér transport. Test offentlige domæner og de konfigurerede forbindelser fra backend til database og leverandører.
4. Kontrollér data i hvile. Medtag database, filer, backups, replikaer, logs og eksporter.
5. Gennemgå nøgleadgang. Find mennesker, runtimeidentiteter og automatiseringer, der kan bruge eller administrere nøgler.
6. Afprøv i et isoleret miljø. Rotér eller deaktiver en testnøgle, gendan en krypteret backup, og dokumentér både succes og sikker fejl.

GDPR artikel 32 nævner pseudonymisering og kryptering som mulige passende sikkerhedsforanstaltninger. Den konkrete løsning skal vælges efter risikoen; denne tekniske kontrol er derfor dokumentation til vurderingen, ikke en automatisk garanti for juridisk efterlevelse.

Tjekliste før andre får adgang til appen

☐ Følsomme data, forbindelser, lagre og kopier er kortlagt.
☐ HTTPS/TLS bruges på alle offentlige sider, API'er og relevante serviceforbindelser.
☐ Certifikatfornyelse og TLS-fejl overvåges af en navngiven modtager.
☐ Kryptering i hvile er verificeret for database, filer, backups, snapshots og logs.
☐ Valget mellem platformnøgle, kundestyret nøgle og app-kryptering er begrundet i en konkret risiko.
☐ Krypteringsnøgler ligger ikke i frontend, repository eller samme lager som data.
☐ Kun nødvendige runtimeidentiteter og administratorer kan bruge eller styre nøgler.
☐ Test og produktion bruger adskilte nøgler og adgange.
☐ Passwords håndteres af en egnet identitetsløsning eller stærk password-hashing – ikke reversibel kryptering.
☐ Logs, eksportfiler, lokale downloads og supportudtræk følger samme beskyttelsesniveau og slettefrist.
☐ Rotation, gammel nøgleversion, gendannelse og nødetilfælde er afprøvet uden produktionsdata.
☐ Kryptering er suppleret med adgangskontrol, overvågning, backup og dataminimering.

Relaterede guides

Officielle kilder

Fakta er kontrolleret mod aktuelle sikkerhedsvejledninger, cloudleverandørernes egen dokumentation og GDPR. Krypteringsmuligheder og nøgleansvar varierer mellem tjenester og planer, så kontrollér altid den konkrete ressource og konfiguration.

Er appen i brug, men krypteringen stadig et ubesvaret spørgsmål?

Startklar kan hjælpe med at kortlægge det eksisterende dataflow, kontrollere platformens faktiske beskyttelse og etablere nøgleadgang, test og dokumentation i den stack, appen allerede bruger.

Se Startklar-forløbet