Databehandling og lagring
Denne siden beskriver hvor data lagres, hvordan det flyter gjennom systemet, og hvilke krypteringsmekanismer som beskytter det.
Lagringslokasjoner
All data lagres innenfor EU/EØS. Vi benytter ingen datasentre utenfor EU for primær databehandling.
| Komponent | Leverandør | Region | Formål |
|---|---|---|---|
| Database (PostgreSQL) | Supabase (AWS) | eu-central-1 (Frankfurt) | All applikasjonsdata |
| Fillagring | Supabase Storage (AWS S3) | eu-central-1 (Frankfurt) | Opplastede filer og vedlegg |
| Dokumentlagring | Cloudflare R2 | EU | Genererte rapporter og dokumenter |
| Applikasjonshosting | Vercel | EU (via Edge Network) | Web-applikasjon og API |
| Bakgrunnsjobber | Railway | EU | Automatisk matching, rapportgenerering |
Kryptering
I transport (data in transit)
All kommunikasjon mellom brukerens nettleser og Revizo er kryptert med TLS 1.2 eller nyere. Dette gjelder:
- Nettleser → Revizo API (HTTPS)
- Revizo → Database (SSL/TLS)
- Revizo → Fillagring (HTTPS)
- Revizo → Tredjepartstjenester (HTTPS)
- Webhook-mottak (HTTPS med signaturverifisering)
HTTP Strict Transport Security (HSTS) er aktivert med max-age=63072000 (2 år), includeSubDomains og preload for å forhindre nedgradering til ukryptert forbindelse.
I ro (data at rest)
| Lag | Metode | Detaljer |
|---|---|---|
| Database | AES-256 | Supabase/AWS krypterer all data på disknivå |
| Fillagring | AES-256 | Supabase Storage og Cloudflare R2 krypterer lagrede filer |
| Applikasjonsnivå | AES-256-GCM | Sensitive hemmeligheter (API-tokens til regnskapssystemer) krypteres med en dedikert nøkkel før lagring i database |
Applikasjonsnivå-krypteringen bruker AES-256-GCM (Galois/Counter Mode), som gir både konfidensialitet og integritetsbeskyttelse. Krypteringsnøkkelen lagres som miljøvariabel og roteres ved behov.
Dataflyt
Brukerinteraksjon
Bruker (nettleser)
│
│ HTTPS / TLS 1.2+
│
▼
Vercel Edge Network (EU)
│
│ Clerk-autentisering
│ Sesjonsvalidering
│
▼
Next.js API-ruter
│
├── Inputvalidering (Zod)
├── RBAC-sjekk
├── Tenant-isolering
│
▼
PostgreSQL (Supabase, Frankfurt)
│
│ SSL/TLS, tenant_id-filter
│
▼
Respons til bruker
Import og avstemming
Fil-import (CSV/Excel/CAMT)
│
├── MIME-validering
├── Størrelsessjekk (maks 20 MB)
├── Filnavnsanering
│
▼
Supabase Storage (kryptert, tenant-scoped)
│
▼
Parser → Transaksjoner i database
│
▼
Smart Match (automatisk matching)
│
▼
Resultater tilgjengelig for bruker
Integrasjoner (Tripletex / Visma NXT)
Bruker kobler integrasjon
│
▼
API-tokens krypteres (AES-256-GCM)
│
▼
Lagres kryptert i database
│
▼
Ved synkronisering:
Token dekrypteres → API-kall → Data lagres → Token fjernes fra minne
Datakategorier
| Kategori | Eksempler | Sensitivitet | Kryptering |
|---|---|---|---|
| Brukeridentitet | Navn, e-post, Clerk-ID | Personopplysning | TLS + plattformkryptering |
| Regnskapsdata | Transaksjoner, saldoer, kontonumre | Konfidensiell | TLS + plattformkryptering |
| Kontaktdata | Navn, e-post, telefon, rolle | Personopplysning | TLS + plattformkryptering |
| Integrasjonstokens | API-nøkler til Tripletex/Visma | Svært sensitiv | AES-256-GCM (applikasjonsnivå) |
| Filer og vedlegg | CSV, Excel, PDF, bilder | Konfidensiell | TLS + plattformkryptering |
| AI-samtaler | Chat med AI-assistent | Kan inneholde PII | TLS + plattformkryptering |
| Hendelseslogg | Brukerhandlinger, tidspunkt | Intern | TLS + plattformkryptering |
Backup og gjenoppretting
Databasebackup
- Daglige snapshots via Supabase (automatisk)
- Point-in-time recovery (PITR) — gjenoppretting til ethvert tidspunkt innenfor oppbevaringsperioden
- Backup lagres kryptert i samme EU-region som produksjonsdatabasen
Applikasjonsbackup
- Daglig automatisk kode-backup via GitHub Actions
- Manuell backup før større endringer
- Alle backups tagges og kan gjenopprettes
Gjenopprettingstid
Ved en uventet hendelse er målet:
- RPO (Recovery Point Objective): Maks 1 time datatap (PITR)
- RTO (Recovery Time Objective): Maks 4 timer nedetid
Datasegregering
Hver organisasjon i Revizo har en unik identifikator (tenant_id) som sikrer at data aldri blandes mellom organisasjoner. Isolering håndheves i tre lag:
- Autentisering — Organisasjons-ID hentes fra den autentiserte sesjonen, aldri fra klienten
- Applikasjonslag — Alle databasespørringer filtrerer automatisk på
tenant_id - Database — Row Level Security (RLS) gir et ekstra sikkerhetsnett
Se Tilgangskontroll for mer om hvordan tilgang styres.
Sist oppdatert: Mars 2026