Sikkerhet
Sikkerhet og personvern er en del av arkitekturen, ikke et påheng. Under beskriver vi hvordan Veisla er bygget, lag for lag, og hva hvert lag faktisk gjør.
| Lag | Slik oppfyller Veisla det |
|---|---|
| 1 · Klientlag | Next.js 16 og React 19 med server-renderte komponenter, likt i applikasjon og kontrollplan. |
| 2 · API og backend-logikk | Typet App Router-API med autorisering på server-siden per forespørsel og strukturert feilhåndtering. |
| 3 · Database og lagring | Database-per-tenant: hver kunde har sin egen isolerte database (Azure Postgres / Neon), uten delte tabeller mellom kunder. |
| 4 · Autentisering og tilgang | Rollebasert tilgangskontroll, per-tenant sesjoner og enkeltpålogging (SSO) per kunde. |
| 5 · Hosting og utrulling | GitHub Actions med Azure OIDC: ingen langlivede skynøkler, ingen hemmeligheter i kildekoden, produksjon bak et godkjenningssteg. |
| 6 · Sky og compute | Microsoft Azure Container Apps med eget isolert kjøremiljø per kunde. |
| 7 · CI/CD og versjonskontroll | Hemmeligheter hentes fra Azure Key Vault og GitHub Secrets (aldri i repoet); godkjent produksjonsmiljø som port før rollout. |
| 8 · Isolasjon mellom kunder | Fysisk adskilte databaser per kunde fremfor row-level security i én delt base — kundedata ligger aldri sammen. |
| 9 · Rate limiting | Brute-force-beskyttelse på innlogging og publikumsvendte endepunkter. |
| 10 · Caching og CDN | Per-tenant edge via Azure Front Door: hver kunde betjenes under eget vertsnavn; ingen delt applikasjonscache av kundedata. |
| 11 · Lastbalansering og skalering | Container Apps skalerer per kunde etter last, uavhengig mellom kunder. |
| 12 · Feilsporing og logging | Feilsporing på server, klient og edge med personopplysninger skrubbet; strukturert logging med tenant- og korrelasjons-ID; alt bruk av administrativt databasetilgang revideres — uten at resultatrader logges. |
| 13 · Tilgjengelighet og gjenoppretting | Planlagte per-tenant databasedumper og idempotent replay av betalingswebhooks. |