Sikkerhed & hosting

Al kunde-data og backup hostes fysisk i Danmark. Vores produktionsmiljø kører på et k3s Kubernetes-cluster i et privat datacenter i Danmark. Backup går til en Synology NAS — ligeledes i Danmark.

Vi anvender ikke hyperscaler-services (AWS, Azure, GCP eller lignende) i forbindelse med KISMS-løsningen, og der er ingen tredjelandsoverførsler.

• Brugere logger ind med engangskode (OTP) sendt til arbejds-e-mail. Ingen statiske kodeord.
• JWT-session 30 dage. Kan revokeres centralt af tenant_admin.
• Roller efter least-privilege: slutbruger → systemansvarlig → systemejer → centerchef → direktion, samt fag-roller dpo og informationssikkerhed.
• Centerchef-rollen er scope-filtreret til kommunens fagcentre — har kun adgang til egne systemer.
• Conscient Systems-medarbejdere har ikke rutinemæssig adgang til kommunens data. Superadmin-funktion er audit-logget og kun aktiveres ved eksplicit support-anmodning.

Hver kommunes data er beskyttet i to lag:

• App-lag: Hver request resolverer brugerens tenant_id fra JWT-token. Alle endpoints filtreres automatisk på dette ID via central dependency-injection.
• DB-lag — Postgres Row Level Security (RLS): Database-policies håndhævertenant_id::text = current_setting('app.tenant_id') direkte på row-niveau. Selv hvis en programmør laver en fejlbehæftet query, kan den ikke krydse kommuner.

Dette er defence-in-depth — to uafhængige lag der hver for sig vil afsløre en isolation-fejl.

Alle væsentlige ændringer (godkendelser, risiko-accept, dokument-udgivelser, Spørgeramme-svar) logges i en SHA-256 prev_hash-kæde. Hver ny audit-event indeholder hash'en af den forrige — som en lille blockchain.

Tabellen er append-only via Postgres-trigger der nægter UPDATE og DELETE. Audit-trail kan IKKE ændres eller slettes efter optagelse, hverken af kommunens egne brugere eller af Conscient Systems-medarbejdere. Dette giver en uforfalskelig beviskæde der kan eftervises ved behov.

• TLS 1.2+ overalt (Let's Encrypt-certifikat, automatisk fornyet via Traefik).
• HSTS aktivt, kun HTTPS.
• Database-trafik mellem backend og Postgres er internt i k3s-cluster (privat netværk).
• Backup krypteret med restic AES-256.
• Sessions-tokens (JWT) signeret med HS256 og roteres-bar nøgle.

• Hver nat: fuld database-dump + filer (RWO PVC-snapshot) til Synology NAS.
• Synology beholder rullende 7 daglige + 4 ugentlige + 6 månedlige backups.
• Test-restore-drill kvartalsvis.
• Recovery Time Objective (RTO): < 4 timer for kritisk drift.
• Recovery Point Objective (RPO): < 24 timer (næste natlige backup).

Ved opdaget sikkerhedsbrud underrettes berørte kommuners tenant_admin og DPO senest 24 timer efter opdagelsen. Underretningen indeholder de oplysninger, der er nødvendige for at kommunen kan vurdere og underrette Datatilsynet inden for 72 timer. NIS 2-relaterede hændelser noteres desuden i KISMS' hændelses-modul.

Vi gennemfører månedlige sårbarhedsscanninger af KISMS-løsningen via vores egen scanning-platform vulnscan.cscloud.dk — som bygger på industri-standard værktøjer (OWASP ZAP, Nuclei). Resultat-rapport kan rekvireres af tenant_admins under NDA.

• Container-images bygges fra officielle baser (python:3.11-slim, node:20-alpine, postgres:16).
• Internt billed-register med htpasswd-auth — ingen pull fra ukendte registre.
• Afhængigheder pinnet i requirements.txt og package-lock.json. Sårbarheds-scan via vulnscan.cscloud.dk (internt).

Sikkerhedsspørgsmål kan rettes til info@cscloud.dk. Ansvarlig disclosure af sårbarheder honoreres efter aftale.