Sikkerhet, personvern og datahåndtering

1.1 Hostingleverandør — ServeTheWorld (Oslo)

ServeTheWorld er en norskeid hostingleverandør med datasenter i Oslo. De er underlagt norsk selskapsrett og norsk personvernlovgivning. Dette betyr at data kun kan utleveres etter norsk rettskjennelse — ikke gjennom amerikanske lover som CLOUD Act eller FISA 702.

• •Geografisk plassering: Oslo, Norge — all infrastruktur i norsk jurisdiksjon
• •Sertifisering: ISO 27001 for informasjonssikkerhet
• •Hardware: AMD EPYC Genoa, DDR5 og enterprise NVMe
• •Strømforsyning: 90–95% vannkraft — blant verdens laveste CO₂-fotavtrykk
• •Redundans: Ceph-replikering + VM-replikering til sekundær lokasjon
• •Latens: Under 5 ms for brukere i Norge

1.2 Serveroppsett

Buildex kjører på to dedikerte virtuelle servere hos STW. Separasjonen mellom applikasjons- og databaselaget er en sikkerhetsarkitektur-beslutning: en sårbarhet i ett lag gir ikke automatisk tilgang til det andre.

1.3 Datatyper og lagring

All kundedata — både filer og strukturerte data — lagres utelukkende på norske servere i Oslo.

2.1 Under overføring

• •All kommunikasjon mellom bruker og Buildex skjer via HTTPS med TLS 1.2 eller nyere
• •Filoverføring til Nextcloud skjer via kryptert WebDAV — direkte mellom klient og server, ingen mellomledd
• •API-kall mellom interne tjenester er krypterte og autentiserte
• •HSTS (HTTP Strict Transport Security) er aktivert — nettlesere tvinges til sikker tilkobling
• •TLS-terminering skjer på Caddy reverse proxy i samme datasenter som applikasjonen — ingen edge-leverandør utenfor Norge

2.2 I hvile

• •Fillagring: AES-256 kryptering på NVMe-disker (LUKS full-disk encryption)
• •Database: AES-256 kryptering på PostgreSQL-volumer
• •Sikkerhetskopier: Krypterte med samme standard som produksjonsdata
• •Passord: Lagres aldri i klartekst — bcrypt med høy kostnadsfaktor

3.1 Rollebasert tilgangsstyring (RBAC)

3.2 Row Level Security (RLS)

All datatilgang håndheves på databasenivå via PostgreSQL Row Level Security. Dette betyr at selv en teknisk feil i applikasjonskoden aldri kan resultere i at en bruker ser data fra en annen bedrift. Tilgangsreglene er definert direkte i databasen og kan ikke omgås. RLS er aktivert på alle tabeller som inneholder kundedata.

3.3 Isolasjon mellom bedrifter

Buildex er en multi-tenant plattform. Alle data er knyttet til en company_id og filteret håndheves på alle databasespørringer via RLS. Fillagringen i Nextcloud er organisert i separate mappestrukturer per bedrift, og ingen bruker kan aksessere en annen bedrifts område — verken via applikasjonen eller direkte mot lagringen.

4.1 Innloggingssikkerhet

• •JWT-tokens med kort levetid og automatisk fornyelse
• •Passord lagres med bcrypt-hashing — vi kan aldri lese ditt passord
• •Brute-force-beskyttelse: kontoer låses midlertidig etter gjentatte mislykkede innloggingsforsøk
• •Sesjoner invalideres umiddelbart ved utlogging
• •Separate miljøer for produksjon og staging — ingen testdata blandes med kundedata
• •Rate-limit-lag i applikasjonen blokkerer brute-force og automatiserte angrepsmønstre

4.2 To-faktor-autentisering (2FA) — roadmap

To-faktor-autentisering med TOTP (Time-based One-Time Password) — kompatibelt med Google Authenticator, Microsoft Authenticator og Authy — er planlagt og under implementering. Løsningen er teknisk støttet i Supabase og vil aktiveres for alle kontoer. Kontakt oss dersom dette er et krav for din bedrift — vi kan prioritere utrullingen.

5.1 Behandlingsgrunnlag

• •Avtale (GDPR art. 6(1)(b)): Opplysninger som er nødvendige for å levere tjenesten til kunden
• •Berettiget interesse (art. 6(1)(f)): Logging av tilgangshendelser for sikkerhet og revisjon
• •Samtykke (art. 6(1)(a)): PSI-registrering og biometrisk data (HMS-kort med bilde)

5.2 Hvilke personopplysninger behandles

5.3 Databehandleravtale (DPA)

Buildex inngår en standard databehandleravtale (DPA) i henhold til GDPR artikkel 28 med alle kunder. Avtalen regulerer:

• •Formål og omfang for databehandlingen
• •Tekniske og organisatoriske sikkerhetstiltak
• •Bruken av underdatabehandlere (se punkt 8)
• •Prosedyrer ved sikkerhetsbrudd og varsling til Datatilsynet
• •Dataeksport og sletting ved avtaleopphør

5.4 Sletting og dataeksport

Ved avtaleopphør har kunden rett til full eksport av alle data innen 60 dager. Etter denne perioden slettes alle data permanent fra produksjonssystemene. Backup-kopier beholdes i inntil 90 dager av tekniske årsaker og slettes deretter.

• •Eksportformat: CSV for strukturerte data, originalformat for filer
• •Eksport: Kostnadsfritt og leveres uten forsinkelse
• •Skriftlig slettingsbekreftelse: Utstedes på forespørsel

6.1 Hvorfor Buildex er omfattet

CRA dekker «produkter med digitale elementer», inkludert programvare med nedlastbare komponenter. Buildex leverer både webapplikasjon og native mobilapper for iOS og Android. Mobilappene er nedlastbare komponenter som drar plattformen inn under CRA, og webapplikasjonen kvalifiserer som «remote data processing solution» — en sentral del av produktets funksjonalitet.

6.2 Buildex sine forpliktelser

Som «manufacturer» under CRA må Buildex:

• •Bygge sikkerhet inn i produktet fra designfasen og dokumentere dette
• •Vedlikeholde en Software Bill of Materials (SBOM) for alle leverte komponenter
• •Håndtere sårbarheter aktivt gjennom hele produktets livsløp
• •Rapportere aktivt utnyttede sårbarheter til ENISA innen 24 timer (varsel), 72 timer (detaljert rapport) og 14 dager (sluttrapport)
• •Levere sikkerhetsoppdateringer kostnadsfritt i hele den definerte støtteperioden
• •Gjennomføre conformity assessment og CE-merke produktet før 11. desember 2027

6.3 Hvordan Buildex sin arkitektur forenkler CRA-etterlevelse

Buildex sin selvhostede arkitektur på norsk infrastruktur reduserer CRA-kompleksitet sammenlignet med plattformer som er bygget på amerikanske skytjenester:

• •Færre underdatabehandlere å kartlegge og dokumentere i leverandørkjeden
• •Én sammenhengende stack som kan undersøkes uten å vente på tredjeparts disclosure-tidslinjer
• •Kontroll over patch-tempo uten avhengighet av Microsoft eller AWS sine release-planer
• •Direkte tilgang til logger og forensics-data ved hendelser, uten tredjeparts-leverandør i mellom

6.4 Sårbarhetsdisclosure

Sikkerhetsforskere, kunder og andre kan rapportere sårbarheter konfidensielt til security@buildex.no. Buildex svarer på alle henvendelser innen 48 timer og følger Coordinated Vulnerability Disclosure-prinsipper. Rutinen er publisert på buildex.no/.well-known/security.txt.

6.5 Forholdet til andre regelverk

CRA komplementerer andre sikkerhets- og personvernregelverk Buildex etterlever:

• •GDPR — regulerer behandling av persondata (data-sentrert)
• •NIS2 — regulerer sikkerheten til organisasjoner som leverer kritiske tjenester (organisasjon-sentrert)
• •CRA — regulerer sikkerheten til selve produktet (produkt-sentrert)

Sammen utgjør disse en helhetlig regulatorisk ramme som Buildex sin fullt norske, selvhostede arkitektur er godt posisjonert til å møte.

6.1 Hva loggføres

• •Innlogginger og utlogginger (tidspunkt, IP-adresse, bruker)
• •Opplasting og nedlasting av filer (hvem, hva, når)
• •Opprettelse, endring og sletting av prosjekter og dokumenter
• •Tildeling og fjerning av brukerrettigheter
• •HMS-registreringer, avviksbehandling og sjekklistegjennomføringer
• •API-tilganger og feilhendelser

6.2 Oppbevaring av logger

Tilgangs- og aktivitetslogger oppbevares i minimum 12 måneder. Loggene er skrivebeskyttede og kan ikke slettes av vanlige brukere. All loggdata lagres på norske servere i Oslo.

8.1 Varslingsrutiner

• •Kunder varsles uten unødig opphold og senest 36 timer etter at bruddet er oppdaget
• •Varselet inneholder: hendelsens art, berørte data, sannsynlige konsekvenser og iverksatte tiltak
• •Buildex bistår kunden med eventuelle meldeplikter til Datatilsynet
• •Alle sikkerhetsbrudd dokumenteres internt uavhengig av alvorlighetsgrad

8.2 Beredskapsplan

Vi har en dokumentert beredskaps- og gjenopprettingsplan (Disaster Recovery Plan) med følgende målsettinger:

• •RTO (Recovery Time Objective): Mål 8 timer — systemet skal være operativt igjen innen 8 timer ved alvorlig hendelse
• •RPO (Recovery Point Objective): Mål 24 timer — maksimalt 24 timers datatap ved alvorlig hendelse
• •Backup-strategi: Daglige krypterte backups + Ceph-replikering + VM-replikering til sekundær lokasjon

Vi legger til nye underdatabehandlere kun etter varsling til berørte kunder og med mulighet for innsigelse.

9.1 Selvhostet — ikke underdatabehandlere

Følgende verktøy kjører på vår egen infrastruktur i Oslo og involverer ingen tredjeparter:

• •Monitorering: GlitchTip (feillogging), OpenReplay (sesjonsinnsikt), Umami (webstatistikk), Uptime Kuma (oppetid)
• •Plattform: Coolify — deployment og containerhåndtering
• •Backend: Selvhostet Supabase — autentisering, database, Storage API

10.1 Infrastrukturredundans

• •Lagring: Ceph-replikering på tvers av fysiske noder i datasenteret
• •Database: VM-replikering til sekundær lokasjon + daglige pg_dump-backups
• •Servere: To dedikerte VM-er (applikasjon + database) på AMD EPYC Genoa i ISO 27001-sertifisert datasenter
• •Planlagt vedlikehold: Varsles minimum 48 timer i forveien

10.2 Overvåkning

Systemet overvåkes kontinuerlig med selvhostede verktøy: GlitchTip for feillogging, OpenReplay for sesjonsinnsikt, Umami for webstatistikk og Uptime Kuma for oppetid. Alle verktøy kjører på samme norske infrastruktur som kundedataene — ingen driftsdata forlater Norge. Varsler sendes umiddelbart til driftsteamet ved kritiske hendelser.