Sikkerhedstillæg

Dette tillæg ændrer ingen bestemmelse i databehandleraftalen. Det dokumenterer de sikkerhedsforanstaltninger, aftalens bilag C beskriver, og det svarer på de fem forhold, aftalen selv anfører som udokumenterede.

Aftalens version v1 er uændret, og aftrykket af den er det samme som før. Har du accepteret v1, gælder din accept uændret. Der er intet, du skal gøre.

Skal indholdet en dag stå i selve aftalen, sker det som en ny version ved siden af v1. Den gamle version bliver stående i produktet, og din accept af den bliver stående som dokumentation for, hvad der gjaldt, da du gav den. Det er den samme fremgangsmåde, aftalen allerede bruger.

Aftaleteksten står på /databehandleraftale. Hvad vi selv er dataansvarlige for, står på /privatliv.

Hver oplysning nedenfor står med en kilde og en dato. Det, vi ikke kan dokumentere, står som netop det. Vi skriver hellere et hul frem end en foranstaltning, der ikke findes.

Denne udgave dokumenterer gendannelsesprøven af database og filer 15. september 2026 samt kontotilknytning i portalens og læse-API’ets adgangslog. Øvrige observationer beholder deres oprindelige kildedato; de er ikke alle efterprøvet igen.

Aftalens ordlyd: «Kryptering i hvile og backup-frekvens hos database- og hostingleverandøren er leverandørernes forhold og er ikke selvstændigt efterprøvet af databehandleren.»

Produktionsdatabasen og appen drives hos leverandørerne. Databehandleren administrerer desuden lejede servere til drift og gendannelsesprøver, men kan ikke selv revidere leverandørernes datacentre. Her skelnes mellem vores egne kontroller og leverandørernes dokumenterede oplysninger.

Det, vi selv har efterprøvet

Aflæst i leverandørens administrations-API 3. september 2026 for det projekt, der bærer platformens data:

Regionen er den samme, som bilag C.5 i aftalen angiver. Postgres-versionen har betydning for backup-formen, og den står i punkt 2.

Det, leverandøren oplyser

Det, der stadig ikke er efterprøvet

Kryptering i hvile og backup-frekvens er fortsat leverandørens oplysning, ikke noget databehandleren selv har efterprøvet. Revisionsrapporten haves ikke. Aftalens forbehold på det punkt står altså ved magt. Det, der er kommet til, er en kilde, en dato og en aflæsning af projektets egne indstillinger.

Aftalens ordlyd: «Der er ikke fastsat en opbevaringstid for backups, og der er ikke gennemført en dokumenteret gendannelsestest.»

Opbevaringstiden er nu kendt

En fil, der slettes ved en fejl, kan gendannes fra en gennemført filbackup. Kopierne ligger i et særskilt, privat lager i samme Supabase-projekt. De beskytter mod sletning af originalen, men ikke mod tab af hele projektet eller leverandøren.

Den reelle sletningsfrist i rækken ovenfor står ikke i aftalens bilag C.4 i dag. Den hører hjemme som en præcisering i en fremtidig version af aftalen.

Database og filer er gendannet i en isoleret prøve

Den 15. september 2026 blev et krypteret udtræk af hele databasen gendannet i en separat testdatabase uden netværksadgang. Indholdet i alle 77 tabeller blev sammenlignet med samme øjebliksbillede fra produktionen. De 52 adgangsregler og tabellernes RLS-indstillinger stemte også. Prøven omfattede login-data, dokumentmetadata, interne funktioner og migrationshistorik.

Alle 7 dokumentfiler fra den normale filbackup 15. september kl. 04.30 UTC blev gendannet og kontrolleret med SHA-256. Filernes stier og størrelser stemte med den gendannede database, og indholdet stemte med originalerne ved kontrollen. I en særskilt adgangsprøve kunne testkontoen se sine egne boliger; en fremmed konto og en anonym bruger kunne ikke se dem. Kundekontoen kunne ikke læse administratorloggen.

Testmiljøet er lukket, og testdata i hukommelsen er fjernet. Krypterede testkopier er opbevaret uden for produktionsprojektet med særskilt beskyttet dekrypteringsnøgle. En efterfølgende prøve samme dag gendannede 81 tabeller og alle 7 filer fra den nye backupløsning med en separat nøglekopi. Indholdet stemte med udtrækket. Rotation er prøvet med testdata, og fejl- og raskmeldinger er modtaget i den interne driftsoversigt. Der er endnu ikke etableret en automatisk, uafhængig backup i fast drift: aktivering afventer afklaring af serverleverandørens aftaledækning og kundernes ændringsprocedure. En fuld omskiftning af app, login-tjeneste, mail og domæner til et nyt driftsmiljø er heller ikke afprøvet.

Kilde for oplysningerne om leverandørens database-backup: Supabase-dokumentationen om database-backups, læst 3. september 2026. Projektets abonnement og Postgres-version er aflæst i leverandørens administrations-API samme dag.

Aftalens ordlyd: «Der føres ikke en selvstændig log over administrativ adgang med en fastsat opbevaringstid.»

Platformen har en nøgle, der kan læse og skrive uden om databasens egne adgangsregler. Den bruges af de dele af produktet, der arbejder uden for en kundes egen session: baggrundsjob, lejerens adgang gennem et invitationslink, og de ruter, der skriver på vegne af en kunde. Nøglen ligger i driftsmiljøet hos hostingleverandøren og i databehandlerens udviklingsmiljø. Den sendes ikke til browseren og står ikke i kildekoden.

Det, loggen dækker

På 44 ruter og moduler er logkaldet lagt ind, når nøglen tages i brug, herunder den nye backupfunktion, som er slukket. De to kontotilknyttede forløb skriver desuden en linje, når kontoen er fundet eller adgangen godkendt. Der logges ikke en linje for hvert databaseopslag. Tabellen er aktiveret 14. september 2026. Skrivning, læsning med serveradgang og afvisning af kundeadgang er kontrolleret.

Linjen bærer fire felter:

Loggen registrerer tidspunkt, handling og kilde samt konto-id i de to beskrevne adgangsforløb. Konto-id er en personhenførbar reference. Loggen indeholder ikke navne, adresser, e-mailadresser, beløb eller dokumentindhold. Den er ikke en log over hvert enkelt databaseopslag eller alle manuelle administratorhandlinger.

Det daglige opbevaringsjob (kl. 06 UTC) er indrettet til at slette linjer ældre end 12 måneder. Jobbet kører kun, når dets adgangsnøgle er sat i driftsmiljøet.

Tabellen er lukket på samme måde som journalen over accepterede aftaler: adgangsreglerne er slået til, og der er ikke skrevet nogen regel, der åbner for en rolle, så hverken en besøgende eller en indlogget kunde kan læse den. Servernøglen, databasens ejerrolle og leverandørens administrationsflade kan.

Loggen skrives fejlsikkert. Kan linjen ikke skrives, fortsætter den handling, der skulle logges. Et dokumentationshul må ikke kunne standse en kundes arbejde.

Det, loggen ikke dækker

• Loggen dækker platformens egen brug af nøglen. Den dækker ikke opslag foretaget direkte i leverandørens administrationsflade eller forespørgselsværktøj. Hvilke logs leverandøren selv fører på Pro-abonnementet, og hvor længe de kan hentes, er ikke afklaret.

Aftalens ordlyd: «Der foreligger ikke skriftlige fortrolighedserklæringer for personer med adgang; kredsen er i dag én person, som er underlagt databehandlerens instruktionsbeføjelse.»

Selskabet har én medarbejder. Én person har adgang. Nøglen er derudover lagret i de systemer, databehandleren bruger til drift og udvikling; en opgørelse af dem er en åben opgave.

Der foreligger nu en fortrolighedserklæring som skabelon. Den er skrevet til databeskyttelsesforordningens artikel 28, stk. 3, litra b, og artikel 32, stk. 4. Den gælder også efter ophør, og den følger dansk ret. Den er klar til underskrift.

Den er ikke underskrevet. Kommer der flere til kredsen, underskriver de den, før adgangen gives.

Erklæringen kan udleveres på anmodning efter aftalens bilag C.7.

Aftalens ordlyd: «Der er ikke gennemført en overførselskonsekvensanalyse for overførslerne i bilag C.6.»

Bilag C.6 nævner to overførsler til USA: aflæsning af en kvittering hos Anthropic PBC, og mail-transport ad reservevejen hos Plus Five Five, Inc. Begge er beskrevet i aftalen, og den første sker kun ved kundens eget klik.

Der er nu udarbejdet et udkast til en analyse for begge. Udkastet følger de seks trin i Databeskyttelsesrådets anbefaling 01/2020: kortlægning af overførslen, overførselsgrundlaget, vurderingen af retstilstanden i modtagerlandet, supplerende foranstaltninger, de formelle skridt og den løbende genvurdering.

Det er et udkast og ikke en gennemført analyse. Den konkrete tjenestes aftale- og overførselsgrundlag samt relevante supplerende foranstaltninger skal færdigvurderes, før analysen kan afsluttes.

To ting, udkastet ikke kan svare på

• Hvor selve modelkaldet udføres geografisk. Platformens kald til Anthropic sætter ingen region, og der findes ingen bekræftelse fra leverandøren om, at behandlingen sker i EU. Ingen tekst fra os siger, at den gør, heller ikke denne.
• Hvad de to leverandører selv svarer på de spørgsmål, en analyse skal stille dem. Ingen af dem er endnu spurgt skriftligt.

Vil du ikke have overførsel ud af EU, kan du undlade at bruge AI-aflæsningen. Den er et tilvalg pr. kvittering og ikke en del af den løbende drift. Det står også i aftalens bilag C.6.

Overførsel B kan du ikke fravælge: fejler den europæiske mailvej, sendes mail via USA. Om reservevejen skal kunne slås fra, er en åben beslutning.

Aftalens bilag D.2 siger, at der ikke findes en døgnvagt, og at fristen på 24 timer derfor ikke kan holdes, hvis et brud sker, mens kontaktpersonen er utilgængelig. Det står ved magt. Her er, hvad der faktisk overvåges, så forbeholdet kan læses med det rigtige omfang.

Hvad det er, og hvad det ikke er

Det er overvågning af tilgængelighed. Den opdager, at platformen er nede eller svarer forkert, og den gør det hele døgnet. Den er ikke et system, der opdager brud på persondatasikkerheden. Et uautoriseret opslag i en database, der svarer normalt, udløser ingen alarm.

En skriftlig beredskabsprocedure er udarbejdet 15. september 2026. Den beskriver afgrænsning af hændelsen, sikring af beviser, kontakt til berørte kunder og opfølgning. Den ansvarlige skal underrette uden unødig forsinkelse og efter aftalens frist; utilgængelighed ophæver ikke forpligtelsen. Vurdering og underretning afhænger fortsat af én person. Der findes ingen døgnvagt, og en menneskelig reserve samt en kontaktøvelse mangler.

Databasens sikkerhedsfund og de to tidligere åbne triggerrettigheder er kontrolleret 7. september 2026. Kontrollen viser følgende:

1. Seksten tabeller har adgangsreglerne slået til, og der er ikke skrevet nogen regel, der åbner for en rolle. Det er en oplysning, ikke en advarsel: fravær af regler er netop det, der lukker tabellerne for en besøgende og for en indlogget kunde. Servernøglen, databasens ejerrolle og leverandørens administrationsflade kan læse dem. Journalen over accepterede aftaler er én af dem.
2. De to interne triggerfunktioner til lejerinvitation og lejerkonto kan ikke længere kaldes af rollerne anon og authenticated. Begge rollers udførelsesret er kontrolleret direkte i databasen. Rettelsen er registreret i migrationsjournalen som 20260905155217. Kontrollen beviser disse rettigheder, ikke hele platformens sikkerhed.
3. Leverandørens kontrol af lækkede adgangskoder er slået fra i indstillingerne. Den slås til med ét klik i leverandørens administrationsflade, og det kræver ejeren.

Kilde: leverandørens sikkerhedsgennemgang samt læsekontrol af migrationsjournal, funktionsrettigheder og tabellens eksistens 7. september 2026. Ved den daværende kontrol var logtabellen ikke oprettet. Den blev aktiveret og kontrolleret særskilt 14. september 2026, som beskrevet i punkt 3.

Databehandleraftalens version v1 er frosset: teksten har et aftryk, og en accept, der er givet, skal kunne slås op mod nøjagtig den ordlyd, kunden så. Derfor kan en fejl i ordlyden ikke rettes i v1. Tre steder siger aftalen noget andet end det, platformen gør. De står her med kilde og dato, og med den ordlyd, de får i næste version.

Indtil den version findes, gælder aftalens ordlyd som aftale. Afvigelserne nedenfor er alle af den art, at driften gør MINDRE, end aftalen beskriver, eller beskriver en foranstaltning med et forkert ord — ingen af dem udvider den behandling, den dataansvarlige har instrueret om.

1. Aftalen nævner påkrav blandt de mails, platformen sender

Aftalens ordlyd, bilag B: «Mail-transport: varsler, invitationer til lejere, kvitteringer og påkrav.» Samme ord står i bilag C.1's instruks og i bilag A.4's liste over modtagere.

Platformen sender aldrig et påkrav. Huslejefunktionen skriver et påkravsudkast, som den dataansvarlige selv sætter ind i et brev og sender, og påkravs-ruten registrerer alene, at han har sendt det — der er ingen udsendelse, ingen modtager og ingen automatik. Mail-transporten hos Google Workspace bærer altså varsler, invitationer til lejere og kvitteringer, ikke påkrav.

Kilde: app/api/bp/husleje/paakrav/route.js (ruten registrerer en dato, den sender ingenting) og lib/bp/graenser.js, hvis linje står på /funktioner. Efterprøvet 3. september 2026.

Ordlyden i v2, bilag B: «Mail-transport: varsler, invitationer til lejere og kvitteringer.»

2. Adgangskoden er ikke krypteret, som aftalen siger — den er hashet

Aftalens ordlyd, bilag A.3 — ordet er ikke rigtigt: «E-mailadresse, en krypteret adgangskode hos databaseleverandøren, hvornår lejeren sidst åbnede sin side, og hvornår adgangen lukkes.»

Aftalens ordlyd, bilag C.2. Ordet passer heller ikke her: «Opbevares krypteret hos databaseleverandøren, aldrig i klartekst — hverken den dataansvarliges eller lejerens. Databehandleren kan ikke læse dem.»

Adgangskoden opbevares som en saltet envejs-hash hos databaseleverandørens login-tjeneste. Forskellen er ikke sproglig: krypteret betyder, at nogen med en nøgle kan læse værdien frem igen, og det kan hverken databehandleren eller leverandøren her. Aftalen lover altså en svagere foranstaltning, end den, der faktisk er truffet.

Kilde: lejerens og kundens kodeord sendes udelukkende til leverandørens auth-tjeneste (app/(bp)/privatliv/page.jsx' egen begrundelse, og lib/bp/opbevaringsdata.js' afsnit 3b om lejerens login). Ingen tabel i platformen bærer en adgangskode. Efterprøvet 3. september 2026.

Ordlyden i v2, bilag A.3: «E-mailadresse, en adgangskode gemt som en saltet envejs-hash hos databaseleverandøren — hverken databehandleren eller leverandøren kan læse den frem igen — hvornår lejeren sidst åbnede sin side, og hvornår adgangen lukkes.»

Ordlyden i v2, bilag C.2: «Opbevares som en saltet envejs-hash hos databaseleverandøren, aldrig i klartekst og aldrig i en form, der kan læses tilbage.»

3. Aftalens note om telefonpasningen siger for lidt

Aftalens ordlyd, bilag B, om Ringback-telefonpasningen: den beskrives som en behandling, «hvor et helt opkald transskriberes og behandles af en sprogmodel», og som ikke er en del af produktet i dag. Noten tilføjer, at hvis den tages i brug, sker det som et selvstændigt bilag til aftalen med sin egen liste over underdatabehandlere, som den dataansvarlige skal acceptere særskilt.

Sætningen er sand om det, den handler om: der passes ingen telefon på den dataansvarliges vegne, og intet opkald til en kundes eget nummer behandles af platformen. Men den samme teknologi driver databehandlerens EGEN supportlinje, og det fremgår ikke af noten. Ringer den dataansvarlige til supportnummeret, transskriberes samtalen, og en sprogmodel laver et resumé.

Rollen er en anden. De opkald behandles ikke på den dataansvarliges vegne og hører ikke til denne aftale: databehandleren er selv dataansvarlig for dem, på grundlag af sin legitime interesse i at kunne besvare en henvendelse. Behandlingen står beskrevet i privatlivspolitikkens afsnit «Når du ringer til os», med leverandørerne, det, der gemmes, og fristerne.

Kilde: privatlivspolitikkens telefonafsnit og lib/bp/telefonlinje.js, som bærer den samme ordlyd ved siden af nummeret på /kontakt, /presse og /opret. Efterprøvet 3. september 2026.

Ordlyden i v2, noten i bilag B: «Ringback-telefonpasningen — hvor et helt opkald transskriberes og behandles af en sprogmodel — passer ingen telefon på den dataansvarliges vegne og er ikke en del af den tjeneste, denne aftale dækker. Databehandlerens egen supportlinje drives af samme teknologi; de opkald er databehandlerens egen behandling som dataansvarlig og er beskrevet i privatlivspolitikken, ikke her. Tages telefonpasningen i brug for den dataansvarlige, sker det som et selvstændigt bilag til denne aftale med sin egen liste over underdatabehandlere, og den dataansvarlige skal acceptere det særskilt.»

De tre rettelser er indarbejdet i et udkast til v2. Det konkrete behandlingsomfang og proceduren for ændring af eksisterende aftaler skal være afklaret, før v2 aktiveres. Indtil da er v1 uændret.

Listen afløser den, der står i aftalens bilag C.2.

• Om kortere gendannelsesinterval er slået til for projektet. Kræver et opslag i leverandørens administrationsflade.
• Den daglige filbackup ligger i samme Supabase-projekt. En uafhængig backupløsning med kryptering, rotation og fejlalarm er bygget og prøvet. Fast drift afventer leverandøraftale og kundernes ændringsprocedure; den nye tidsstyrede kørsel er slukket.
• Database og dokumentfiler er gendannet isoleret. En fuld omskiftning af hele tjenesten til et nyt driftsmiljø er ikke afprøvet.
• Kontotilknytning dækker udlejerportalens kontekst og godkendt læse-API-adgang. Øvrige kald og tværgående job har ikke fuld kontotilknytning; manuelle opslag hos leverandøren er ikke omfattet.
• Leverandørens SOC 2 Type 2-rapport kan ikke hentes på Pro-abonnementet, og databehandleren har den ikke.
• En opgørelse over, hvilke systemer servernøglen er lagret i.
• Om mail-reservevejen gennem USA skal kunne slås fra.
• Hvilke logs leverandøren selv fører over opslag i sin administrationsflade, og hvor længe de kan hentes.
• Fortrolighedserklæringen er ikke underskrevet.
• Overførselskonsekvensanalysen er et udkast. Flere leverandørforhold er afklaret gennem offentlige aftaler og registre; den samlede vurdering af dataflow og overførselsgrundlag mangler afslutning.
• Tre steder siger aftalens ordlyd noget andet end driften. De står i afsnittet ovenfor med kilde og med den formulering, de får i en ny version; rettelsen kræver, at den version skrives.
• Der findes ingen dokumentation for, i hvilken geografi kald til sprogmodellen udføres.
• Der er ingen automatisk opdagelse af brud på persondatasikkerheden, og der findes ingen døgnvagt.
• Kontrollen af lækkede adgangskoder er slået fra hos leverandøren.

Hvert punkt har en nedskrevet fremgangsmåde. Ansvaret ligger hos databehandlerens ejer.