Skip to main content

Sporbarhet, sikkerhet og kontroll

Alt som påvirker en rapports utfall lagres som audit-hendelser; rapporter sjekkes automatisk for avvik; og roller og tokens kan tilbakekalles på sekundnivå.

Audit-hendelser​

Følgende er audit-loggert:

DomeneEksempler på hendelser
AuthInnlogging, mislykket innlogging, PAT/SAT opprettet/tilbakekalt, gjenbruk av tilbakekalt refresh-token oppdaget
BrukereInvitasjon sendt/akseptert, rolleendring, deaktivering
Ekstern tilgangTilgang for ekstern regnskapsfører/rådgiver tildelt, fornyet, tilbakekalt (se API og autentisering)
RapportInnsending, godkjenning, avvisning, kommentarer, redigering, statusendring
FlytPublisering, simulering, trigger fyrte, condition evaluert, action utført, HTTP-respons
IntegrasjonerEksport startet/fullført/feilet, SCIM-operasjoner, regnskaps-sync
EnterpriseOrg koblet til/fra, kategori propagering, faktureringsendring

Hver hendelse inneholder: aktør (bruker eller system), tidspunkt (UTC), ressurs-ID, før/etter-snapshot der relevant, og en traceId for å koble hendelser i samme operasjon.

Lagringstid​

  • Operasjonell audit-logg: minimum 5 år (regnskapskrav i Norge).
  • Flow-traces og HTTP-forespørsel-respons: 90 dager med full payload, deretter aggregerte metadata.
  • PAT/SAT-bruk: detaljert i 12 måneder.

Tilgang​

  • Org-Admin ser audit-loggen for sin egen organisasjon (UI under Innstillinger → Sporbarhet og via API).
  • Enterprise.Admin ser audit på tvers av medlemsorganisasjoner.
  • Alminnelige brukere ser sin egen rapporthistorikk.

Kontroller og funn​

Rapporter, utgifter og vedlegg analyseres automatisk av et sett kontroller (checks). Hver kontroll kan produsere ett eller flere funn (findings) på en rapport:

  • Duplikat – samme vedlegg brukt på flere rapporter (kryptografisk fingerprint, SHA-256 over normalisert innhold)
  • Integritet – mulige tegn på manipulering eller AI-generert innhold i et vedlegg
  • Beløpsavvik – beløpet lest fra kvitteringen (OCR) stemmer ikke med beløpet ført på utlegget
  • Manglende kvittering – en utgift mangler kvittering, og beløpet er over organisasjonens grense for når kvittering kreves

Resultater vises som badges på rapportnivå og i en mer detaljert kontrollvisning for godkjenner og admin. Et funn med tilstrekkelig sikkerhet kan blokkere godkjenning inntil det er ryddet opp i; andre funn er rådgivende. Bare admin og godkjennere kan avvise eller bekrefte funn – innsenderen av rapporten kan ikke selv rydde opp i egne funn.

Org-admin kan konfigurere hvilke kontroller som er aktive for organisasjonen, og eventuelt justere terskelverdier, via check-policies-API-et.

Tokens og revokering​

TokenLevetidRevokering
Bruker-session (JWT)Kort (typisk 15 min) + refreshLogg ut / deaktiver bruker
PAT (ua_...)Til den expiresAt du valgteDELETE /users/pat/:id eller fra UI
SAT (uas_...)Avtalt ved bestillingChat på utleggsappen.no

Deaktivering av en bruker tilbakekaller alle deres PATs umiddelbart.

PAT- og SAT-listevisninger i API-et inkluderer et lastUsedAt-felt (siste vellykkede autentisering, oppdatert med inntil 15 minutters forsinkelse) – bruk det til å identifisere og rydde i ubrukte tokens. Verdien er null for tokens som ikke er brukt siden feltet ble innført.

Hva integrasjoner må ta hensyn til​

  • Behandle audit-signaler som forretningslogikk, ikke skjult metadata. Hvis du integrerer med rapporter eller vedlegg, skjul ikke funn (duplikat, integritet, beløpsavvik eller manglende kvittering) fra brukeren.
  • Funn hentes via GET /reports/:id/findings, og triageres via POST /findings/:id/dismiss|confirm|unresolve. De eldre /fingerprints/*-endepunktene er fjernet.
  • Rapportsvar inneholder antall funn per kontrolltype. Et tall på 0 betyr at kontrollen kjørte og ikke fant noe; fravær av nøkkelen betyr at kontrollen ikke er aktivert for organisasjonen – ikke tolk det ene som det andre.
  • Kvitteringer for en hel rapport kan hentes samlet via GET /reports/:id/attachments i stedet for å hente vedlegg per utlegg.
  • API-et sender ingen x-request-id-header. Oppgi eventId fra feilresponsens body (når den er satt) i feilmeldinger og support-henvendelser.
  • Webhooks (HTTP-forespørsel-action i flyt) skal være idempotente – vi kan re-fyre samme event ved retry.

Se også​