Identitet før adgang
Konsollen bruger en verificeret Hours-identitet og kontrollerer den aktive konto gennem det eksisterende serverlag. Et påstået bruger-id fra requestens body accepteres ikke som identitet. Roller læses fra serverens egne data, og følsomme konsolhandlinger kræver den relevante rolle og tofaktor.
Partnergatewayen bruger egne opaque tokens. De er ikke Supabase-JWT’er og giver ikke automatisk adgang til PostgREST, storage eller realtime. Tokenets digest peger på en konkret app- og grantrelation, som kontrolleres igen ved brug.
Mindste nødvendige adgang
Scope, apprevision, kundeorganisation, udløb, kontireferencer og eventuelt bogføringsmandat skal alle passe til operationen. En enkelt positiv kontrol er ikke nok. Et godkendt appreview kan eksempelvis ikke tilsidesætte en tilbagekaldt kundegrant.
Skrive- og læserettigheder er adskilt. Kundens grant gives af organisationsejeren med tofaktor, for valgte konti og højst 90 dage. Output bygges som en eksplicit projektion og ikke som en generisk serialisering af en intern række. Bankdata og betalingsudførelse indgår ikke i den eksterne allowlist, og ingen læsning returnerer bank-, betalings-, afsender-bankkonto- eller Stripe-felter.
Databasegrænsen
Partner-API'ets kontroldata er adskilt fra de tabeller, som almindelige klienter kan tilgå, og der er ingen politikker, der åbner dem for anonyme eller almindeligt autentificerede klienter. De privilegerede funktioner er beregnet til serverens service-rolle. En klient kan ikke kalde en privilegeret funktion direkte med en selvvalgt aktør.
En sådan model afhænger af korrekte grants, funktionsejerskab, search_path, default privileges og alternative adgangsveje. Rækkeniveausikkerhed alene er ikke et adfærdsbevis, så kontrollerne skal kunne efterprøves på den faktiske installation.
Regnskab og samtidighed
Gatewayen genbruger Hours’ eksisterende bogføringsfunktion og gemmer kvittering og outbox i det transaktionelle forløb. Idempotens og låserækkefølge forhindrer, at samtidige retries skaber dubletter, eller at en grant læses i en forældet tilstand efter en ventet lås.
Samtidighed bør afprøves med parallelle tokens, genforsøg, reviewændringer, refresh-rotation og tilbagekaldelser, med kontrol af de faktiske rækker og udfald og ikke kun statuskoder.
Sandboxisolation
Sandbox har sit eget projekt og egne credentials. URL- og projektreference kontrolleres, og klienten falder ikke tilbage til produktionsprojektet ved konfigurationsfejl. De syntetiske regnskabsreferencer oprettes kun i testprojektet.
Topbjælken er et UX-signal. Den erstatter ikke miljøbindingen i token, serverkonfiguration og databaseplane. Produktionscredentials kan ikke anvendes på teststien, og en ugyldig sandboxkonfiguration stopper før provisionering.
Egress og secrets
Client secrets og tokens gemmes som digests. Webhooks kræver derimod en hemmelighed, som arbejderen kan bruge til signering; den lagres krypteret med en serverstyret nøgle og appbinding. En nøgle kan roteres uden at blive indlejret i klientbundlet.
Webhookdestinationen kontrolleres som offentlig HTTPS, DNS-adresser kontrolleres, og den valgte IP bindes til forbindelsen. Redirects følges ikke. Understøttelsen omfatter offentlig IPv4, ikke en komplet IPv6-egressprofil.
Persondata, aftaler og bevis
Appens formål, dataminimering, retention, sletning og underleverandører skal vurderes som en del af den konkrete relation. En appgodkendelse er ikke en certificering, og denne dokumentation er ikke en juridisk godkendelse af enhver integrationsmodel.
Tilbagekaldelse er ikke i sig selv en komplet sletteproces. Kundens rettighedsoversigt, interne reviewroller, eksport af auditbevis og håndtering af mistede MFA-faktorer hører til samme vurdering.
Sikkerhedskontakt og dokumenter
Hours drives af Hours v/ Martin Kristensen, enkeltmandsvirksomhed, CVR 34 97 22 81. Sikkerhedsspørgsmål og fund kan sendes til msk@hours.dk.
Hours Docs på docs.hours.dk er det autoritative sted for Hours’ dokumenter. Se dokumentcenter og versionering.