Revisionslog
Oversat fra den engelske original. Hvis de to versioner er forskellige, gælder den engelske. Oversættelsen er endnu ikke korrekturlæst af en dansk modersmålsbruger.
Revisionsloggen registrerer hver administrativ handling på din tenant: hvem gjorde hvad, hvornår, fra hvilken IP og på hvilken ressource. Opbevaringen sker i to niveauer: et søgbart varmt niveau med hele hændelsens indhold (actor, action, fields_json) i 90 / 180 / 365 / 730 dage — som standard 90 (standardplan) eller 365 (enterprise-planer) og konfigurerbart pr. tenant under Godkendelsespolitik → Opbevaring af revisionslog — og et kryptografisk kædearkiv i 3 år i T Cloud Public OBS WORM, der bevarer kædens ankerobjekter, efter at indholdet i det varme niveau er blevet redigeret væk. Compliance-eksporter dækker det søgbare vindue.
Den kryptografiske chain of custody (ankerkæde, merkle-forpligtelser i OBS) er beskrevet i Audit chain integrity.
Hvad der registreres
| Hændelsesklasse | Eksempler |
|---|---|
| Identitet | Login, SSO step-up, nulstilling af MFA, SCIM-provisionering, rolleændring |
| Repository | Repository oprettet, overført, arkiveret, slettet; branch protection ændret |
| Secrets | Secret oprettet, roteret, slettet (kun navnet, aldrig værdien) |
| Webhooks | Destination tilføjet, roteret, fjernet; levering afspillet igen |
| Politik | Regel for push protection tilføjet eller override anvendt; override af malware-scanning; afvisning af SAST-fund |
| Fakturering | Planskift, opdateret betalingsmetode, ændret loft |
| Dataeksport | Eksport sat i kø, hentet, udløbet |
Bemærk, hvad der ikke er med: almindelige læsninger (clone, visning, åbning af filer). Revisionsloggen er en log over administrative handlinger, ikke en adgangslog. Adgang til pakke- og container-registry’et (hver download, upload og sletning, med actor og klient-IP) står i den separate adgangslog for registry’et, som du kan læse via API’et, videresende til dit SIEM og få med i dataeksporten. Git clone og fetch logges endnu ikke pr. forespørgsel.
Gates for container-pulls
Registry’ets image-gates skriver deres afgørelser i revisionsloggen, så de når dit SIEM som alle andre hændelser:
| Action | Hvornår |
|---|---|
registry.pull.blocked | Et container-pull blev afvist |
registry.pull.would_block | Et pull blev leveret, som en gate ville have afvist: din blokeringshandling for image-scanning er warn, eller gaten kører i observationstilstand |
Actor er system:registry-pull-gate. Felterne i fields er:
| Felt | Betydning |
|---|---|
gate | image_scan (sårbarhedsfund på eller over din blokeringstærskel), image_malware (ondsindede pakker), registry_scan (et lag i imaget, som ClamAV fandt inficeret eller ikke kunne scanne) eller registry_blob (det samme for et lag, der hentes direkte via digest) |
image, ref, digest | Imaget, det tag eller den digest, der blev bedt om, og den digest, der blev leveret |
reason | Hvad gaten fandt, for eksempel layer-infected eller image-malware |
mode | enforce, warn (din blokeringshandling) eller shadow (observationstilstand) |
block_severity, finding_count | Kun image_scan: tærsklen og antallet af åbne fund på eller over den |
window_start | Den time, hændelsen dækker |
previous_window_start, previous_window_count | Den seneste tidligere time med en hændelse for samme nøgle, og hvor mange afgørelser den havde i alt; null for den første |
Én hændelse pr. time. Et CI-job, der henter et blokeret image i en løkke, ville ellers fylde loggen. Derfor er der én hændelse pr. image-digest, gate og afgørelse pr. UTC-time, skrevet ved timens første afgørelse. Yderligere afgørelser i samme time tælles, og antallet rapporteres på den næste hændelse for samme nøgle som previous_window_count. En times antal når altså dit SIEM med den næste hændelse for den digest, ikke ved timens udløb; antallet for den sidste time med pulls bliver ikke sendt. En blocked og en would_block for samme digest, eller to forskellige gates, er separate nøgler.
En registry.pull.blocked-hændelse udløser også din alert-webhook for security.pull.blocked, hvis du har abonneret på en. Hvert pull, tilladt eller ej, står i adgangslogen for registry’et.
Sådan læser du loggen
Administrationen → Rapporter → Revisionslog. Filtrér på actor (<username>), action (secret.created, role.changed, …), tidsrum eller berørt ressource. Standardvisningen er de seneste 7 dage.
Klik på en række for at folde JSON-indholdet ud. Følsomme felter (secret-værdier, OIDC-tokens, vedhæftninger med personoplysninger) redigeres væk, allerede når de skrives, så en udfoldet række viser aldrig en værdi, du ikke ville vise en kundes revisor.
CSV-eksport
Klik på Eksportér CSV i en filtreret visning for at få et øjebliksbillede. CSV-filen indeholder de rækker, der aktuelt er filtreret, dog højst 50.000 rækker pr. eksport. Til større tidsrum kan du sætte en fuld dataeksport i kø fra Rapporter → Dataeksport.
Via REST API
Revisionsloggen er tilgængelig i det offentlige API. Brug det, når du streamer hændelser ind i din egen analysepipeline, bygger et compliance-dashboard eller kører revisionsforespørgsler fra et script.
- Forespørg loggen
GET /_app/api/v1/orgs/:slug/audit(filtrér med?actor_kind=og?since=) - Verificér kædens integritet
GET /_app/api/v1/orgs/:slug/audit/integrity - Skift opbevaringsvindue
PATCH /_app/api/v1/orgs/:slug/auth-policybody:{ "audit_full_payload_retention_days": 365 }
Kræver et Personal Access Token (PAT) med scopet audit:read (eller policy:write for at ændre opbevaringsvinduet):
curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
"https://frem.sh/_app/api/v1/orgs/acme/audit?actor_kind=human&since=2026-01-01T00:00:00Z"Se referencen for det offentlige REST API for den fulde OpenAPI-specifikation.
SIEM-videresendelse
Hver hændelse i revisionsloggen sendes også til et HTTPS-endpoint pr. tenant, hvis du opsætter SIEM-videresendelse. Endpointet modtager hændelserne i realtid (inden for få sekunder efter handlingen) i et kompakt JSON-format; formatet er stabilt og versioneret.
Opbevaring
Revisionsposter opbevares i to niveauer:
- Niveauet med søgbart indhold — actor-navnet og
fields_json-indholdet for hver hændelse kan søges i administrationen / CSV-eksporten / SIEM-strømmen i det opbevaringsvindue, der er angivet nedenfor. - Det manipulationssikre kædeniveau — hver hændelses kryptografiske hash og kædeled bevares i 3 år (WORM-forankret med object lock i OBS). Det er det, der gør kæden beviseligt urørt, når der skal dokumenteres over for en revision; den forbliver intakt, også efter at redigeringen i indholdsniveauet har stemplet en række.
Opbevaring af søgbart indhold
| Plan | Standard | Forudindstillinger, du kan vælge |
|---|---|---|
| fremforge / starter | 90 dage | 90 / 180 / 365 / 730 |
| enterprise / enterprise_trial | 365 dage | 90 / 180 / 365 / 730 |
Loftet på 730 dage (≈2 år) holder den aktive tabel audit_events afgrænset. Alt derudover er WORM-niveauets opgave; har du brug for søgbar historik ud over 730 dage, så sæt en dataeksport i kø hvert kvartal, og arkivér den i dit SIEM.
Grænsen gælder kolonnerne for actor og fields_json: rækker, der er ældre end vinduet, beholder deres hash, tidsstempel og action-navn (så SOC 2- og DORA-rapportering stadig virker), men actor pseudonymiseres til redacted, og indholdet erstattes med {}. Den kryptografiske kæde brydes ikke af dette; redigeringen er en pseudonymisering på stedet, ikke en sletning.
Skift det søgbare vindue
Administrationen → Sikkerhed → Godkendelsespolitik → kortet Opbevaring af revisionslog. Vælg 90 / 180 / 365 / 730 dage. Bemærk:
- Forlængelse af vinduet (f.eks. 90 → 365): nye rækker kan søges i længere tid. Rækker, der allerede er redigeret under det tidligere vindue, forbliver redigerede — fremforge gendanner dem ikke.
- Afkortning af vinduet (f.eks. 365 → 90): den næste daglige redigeringskørsel redigerer hver række, der er ældre end det nye vindue. Redigeringen kan ikke fortrydes, når den først er udført; WORM-kæden påvirkes ikke.
Den action, der registreres i revisionsloggen for denne indstilling: tenant.auth_policy.audit_retention.updated (med antallet af dage før og efter i previous og next).
Compliance-forpligtelser
DPA bilag A.7 forpligter til grundniveauet på 90 dage + 3 års WORM. Enterprise-SLA’en forpligter til 365 dages søgbarhed + 3 års WORM. Du kan godt gå under planens standard i brugerfladen, men det ville bryde DPA’en — fremforge håndhæver ikke gulvet i kolonnen, det gør kontrakten. Hvis selve den daglige redigeringskørsel fejler (uafhængigt af at en kunde ændrer opbevaringen), overvåges og alarmeres det løbende.