/
Den gode sikkerhed i applikationer

Den gode sikkerhed i applikationer

(Principper for identitet, autorisation, databeskyttelse og borgertilknytning i DFDG – Det Fælles IT-baserede Datagrundlag)

1. Formål og anvendelsesområde

Denne side fastlægger de styrende sikkerhedsprincipper for alle applikationer, services og forretningsdomæner i DFDG (Det Fælles IT-baserede Datagrundlag).

Retningslinjerne:

  • Gælder for alle miljøer (udvikling, test, produktion)

  • Gælder for alle integrationer (brugeradgang og system-til-system)

  • Er normative og skal efterleves

  • Skal kunne danne grundlag for intern og ekstern revision

Sikkerhedsprincipperne er risikobaserede og skal anvendes med udgangspunkt i dokumenteret risikovurdering.

Denne side skal læses i sammenhæng med:

Hvor der er konflikt mellem denne side og overordnet sikkerhedspolitik, er politikken styrende.

2. Sikkerhed som forretningskrav

DFDG behandler personhenførbare data, herunder CPR-baserede opslag. Sikkerhed understøtter korrekt og lovlig myndighedsudøvelse.

Sikkerhedskrav udledes af:

Følgende principper er styrende:

2.1 Fortrolighed

Kun autoriserede personer og systemer må tilgå borgerdata.

2.2 Integritet

Data må ikke kunne ændres eller manipuleres uautoriseret.

2.3 Tilgængelighed

Autoriserede brugere og systemer skal have adgang, når forretningsbehovet kræver det.

2.4 Sikkerhed i flere uafhængige lag

Sikkerhed skal implementeres i flere uafhængige lag.

Kontroller i ét lag må ikke forudsætte korrekt funktion i et andet lag.

Identitet, autorisation, applikationslogik, platform og netværk skal hver især bidrage til den samlede beskyttelse.

Hvis ét lag kompromitteres, må øvrige lag fortsat begrænse skadeomfanget.

Sikkerhed vurderes samlet på tværs af lag.

3. Identitet (Autentifikation)

Autentifikation fastslår, hvem der tilgår systemet.

3.1 Brugervendte applikationer

Brugervendte applikationer skal anvende korrekt identitetsløsning afhængig af målgruppe.

Borgeradgang

  • Skal anvende MitID.

  • Autentifikation skal ske med den til enhver tid gældende nationale borgeridentitetsløsning.

  • Borgeridentitet må ikke forveksles med medarbejder- eller systemidentitet.

Sagsbehandler- og medarbejderadgang

  • Skal anvende MitID Erhverv.

  • Autentifikation skal kunne knyttes entydigt til medarbejder og juridisk enhed.

  • Rolle og organisatorisk tilknytning skal kunne indgå i autorisationsgrundlaget.

Fælles krav

  • Løsningen skal understøtte Single Sign-On (SSO).

  • Der skal anvendes stærk autentifikation.

3.2 System-til-system adgang (eksterne aftagere)

Eksterne aftagere af data fra DFDG skal autentificeres via OCES-certifikater.

  • Adgang skal ske via gyldigt OCES funktionscertifikat.

  • Certifikatet skal kunne knyttes entydigt til juridisk enhed.

  • Certifikatets gyldighed og status skal valideres ved hvert kald.

  • Certifikat alene giver ikke adgang til data (jf. autorisation).

3.3 Interne forretningsdomæner

Interne domæner skal understøtte token-baseret adgang.

  • Tokens skal være signeret og valideres ved hvert kald.

  • Claims skal verificeres før autorisation.

4. Autorisation og adgang til borgere

Autentifikation alene giver ikke adgang til data.

Autorisation er et selvstændigt og obligatorisk kontroltrin.

4.1 Overordnet princip

  • Autorisation skal ske før forretningslogik eksekveres.

  • Autorisation må ikke implementeres i UI eller ad hoc i domænelag.

  • Autorisation skal håndhæves centralt i API- eller pipeline-laget.

  • Least privilege-princippet skal anvendes.

4.2 Webservice-aftageres adgang til borgere

DFDG giver adgang til borgerdata via CPR-baserede opslag. Dette er en myndighedshandling og kræver dokumenterbar hjemmel.

Følgende skal være opfyldt:

  • Adgang til en borger må kun ske, hvis aftageren har lovlig hjemmel.

  • Adgang skal valideres pr. kald.

  • OCES-certifikat alene er ikke tilstrækkelig autorisation.

  • Autorisation skal baseres på:

    • Identitet

    • Rolle

    • Myndighedstilknytning

    • Konfigureret adgangspolitik

Systemet skal kunne dokumentere:

  • Hvilken myndighed eller juridisk enhed

  • Hvilken bruger eller systemidentitet

  • Hvilken borger (CPR)

  • Hvilket tidspunkt

  • Hvilken handling

Manglende autorisation skal:

  • Afvises

  • Logges

  • Kunne revideres

Adgangskontrol må ikke baseres på aftagerens egen erklæring om hjemmel.

5. Databeskyttelse

5.1 Kryptering

  • Al ekstern kommunikation skal ske over krypterede forbindelser.

  • Databasetrafik skal krypteres.

  • Administrationstilgang skal ske via krypterede kanaler.

5.2 Test- og udviklingsmiljøer

Testdata må ikke indeholde personhenførbare oplysninger uden kontrolforanstaltninger.

Scrambling skal ske i henhold til https://starwiki.atlassian.net/wiki/spaces/CITY/pages/203128898.

Scrambling skal som minimum omfatte:

  • Navn

  • Adresse

  • Kontaktoplysninger

  • Fritekstfelter

  • Adgangsoplysninger

Hvis CPR eller andre direkte personidentifikatorer anvendes i test- eller udviklingsmiljøer, gælder følgende:

  • Adgang skal ske via personligt login eller certifikat.

  • Adgang skal være begrænset efter least privilege.

  • Alle adgangsforsøg og dataopslag skal logges.

  • Miljøet skal sikkerhedsmæssigt behandles som et produktionsmiljø.

Dette indebærer, at miljøet er underlagt samme krav til:

  • Adgangskontrol

  • Kryptering

  • Logning

  • Patch management

  • Overvågning

Miljøer med CPR eller personhenførbare data må ikke klassificeres eller behandles som lavere sikkerhedsniveau end produktion.

6. Applikationssikkerhed

Applikationslaget udgør den største risiko for tab af fortrolighed, integritet og tilgængelighed.

Udvikling skal ske i overensstemmelse med:

6.1 Inputvalidering

  • Alt input skal valideres.

  • Der skal etableres beskyttelse mod SQL injection og XSS.

  • Data må ikke præsenteres uden rensning.

6.2 Sessionshåndtering

  • Sessionscookies skal være secure og httpOnly.

  • Sessioner skal have timeout.

  • Session IDs skal være uforudsigelige.

6.3 Hemmeligheder

  • Hardcoded passwords er forbudt.

  • Secrets må ikke lagres i klartekst.

  • Passwordkrav skal følge overordnet sikkerhedspolitik.

6.4 Kunstig intelligens og maskinlæring

  • Anvendelse af kunstig intelligens (AI), maskinlæring (ML) og generative modeller betragtes som en del af applikationslaget.

  • AI-komponenter skal behandles som sikkerhedskritiske softwarekomponenter.

  • AI må ikke implementeres uden forudgående risikovurdering.

6.4.1 Databeskyttelse ved AI

Hvis AI behandler personhenførbare oplysninger:

  • Behandlingsgrundlag skal være dokumenteret.

  • Dataminimering skal anvendes.

  • Produktionsdata må ikke anvendes til modeltræning uden særskilt godkendelse.

6.4.2 Modelstyring

  • Modelversion skal dokumenteres.

  • Modelopdateringer må ikke ske uden kontrol og godkendelse.

  • Automatisk opdatering af modeller er ikke tilladt uden eksplicit risikovurdering.

  • Modeller fra tredjepart skal have dokumenteret oprindelse.

6.4.3 Runtime-krav

AI-komponenter skal:

  • Køre i isoleret miljø.

  • Have begrænset adgang til interne systemer.

  • Have begrænset databaseadgang.

  • Have kontrolleret netværksadgang.

6.4.4 Logging

Følgende skal kunne dokumenteres:

  • Modelversion.

  • Input (i nødvendigt og lovligt omfang).

  • Output.

  • Tidsstempel.

  • Anvendt konfiguration.

Manglende sporbarhed betragtes som manglende sikkerhed.

7. Infrastruktur- og platformsikkerhed

Sikkerheden i applikationer og databaser er afhængig af den underliggende platform. Hvis platformen kompromitteres, kompromitteres hele løsningen.

Infrastruktur- og platformsikkerhed er derfor et centralt kontrolområde.

7.1 Operativsystem og platform

  • Operativsystemer skal være sikkert konfigureret.

  • Unødvendige services skal deaktiveres.

  • Patch management skal være etableret.

  • Sikkerhedsopdateringer skal implementeres rettidigt.

7.2 Databaseplatform

  • Applikationer må ikke anvende administrative databasebrugere (fx “sa”).

  • Brugerrettigheder skal tildeles efter least privilege.

  • Databasetrafik skal være krypteret.

  • Adgang til databaseadministration skal være begrænset.

Manglende konfigurationsmæssig sikring kan medføre uautoriseret direkte adgang til data.

7.3 Risikokæde

Sikkerhed skal implementeres nærmest data.

Hvis:

  • Platformen er sårbar

  • Databasen er forkert konfigureret

  • Applikationen mangler inputvalidering

… kompromitteres hele sikkerhedsmodellen.

Sikkerhed vurderes derfor samlet på tværs af lag.

7.4 Netværkssikkerhed

Adgang mellem komponenter skal begrænses til nødvendige forbindelser.
Netværkssegmentering skal anvendes.

8. Logging, overvågning og sporbarhed

Logging er et revisionskrav.

Følgende skal logges:

  • Loginforsøg

  • Adgang til borgerdata

  • Fejlede autorisationsforsøg

  • Administrative handlinger

Logs skal:

  • Være manipulationssikre

  • Opbevares iht. de gældende sikkerhedspolitikker.

  • Kunne fremlægges ved revision

  • Understøtte efterfølgende analyse og hændelseshåndtering

  • Skal opbevares adskilt fra applikationslaget

Manglende logning betragtes som manglende sikkerhed.

9. Ledelsens ansvar og godkendelse af sikkerhedsarkitektur

Sikkerhed i DFDG er et ledelsesansvar.

Ledelsen har ansvar for, at sikkerhedsarkitekturen er:

  • Risikobaseret

  • Lovmedholdelig

  • Dokumenteret

  • Implementeret

Sikkerhedsarkitektur må ikke ændres eller fraviges uden dokumenteret beslutning.

9.1 Godkendelseskrav

Følgende kræver ledelsesmæssig eller systemejer-godkendelse:

  • Overordnet identitets- og autorisationsmodel

  • Adgang til borgerdata

  • Integration med eksterne aftagere

  • Anvendelse af AI-komponenter

  • Væsentlige ændringer i sikkerhedskontroller

Godkendelse skal være dokumenterbar.

9.2 Risikoaccept

Afvigelser fra disse principper må kun ske efter:

  • Dokumenteret risikovurdering

  • Begrundet forretningsmæssigt behov

  • Eksplicit risikoaccept

Risikoaccept skal være tidsbegrænset.

Manglende godkendelse eller dokumentation betragtes som manglende styring.

10. Roller og ansvar

Sikkerhed er et fælles ansvar.

Systemejer

Har ansvar for, at sikkerhedskrav er defineret og efterleves.

Forretningsdomæneansvarlig

Har ansvar for korrekt implementering af autorisationsregler.

Udviklingsteams

Skal implementere sikkerhed i overensstemmelse med disse principper.

Drift

Har ansvar for platform-, database- og infrastruktur-sikkerhed.

11. Anti-patterns (må ikke forekomme)

  • Autorisation implementeret i UI

  • Certifikat = fuld adgang

  • Hardcoded secrets

  • Brug af administrative databasekonti

  • Manglende logning af borgeropslag

  • Adgang baseret på tillid fremfor validering

Tilgængelighed: https://starwiki.atlassian.net/was