Tekniske kontroller som støtter etterlevelse

Health Insurance Portability and Accountability Act krever beskyttelse av pasientdata, tilgangskontroll og revisjonsspor.

• Ende-til-ende-kryptering sørger for at pasientdata aldri er synlige for servere
• Signert skrivehistorikk — hver endring er Ed25519-signert og viser hvem som skrev hva og når
• Finmasket tilgangskontroll med navngitte nøkler for ulike behandlingsteam
• Oppbevaring av data med strategier for tidsbasert sharding av databaser og arkivering
• Arbeid offline for helsepersonell i felt og avsidesliggende klinikker

⚠️ HIPAA krever i tillegg logging av lesetilgang, BAA-avtaler, administrative sikringstiltak og fysisk sikkerhet — dette må du selv sørge for rundt MindooDB.

Se bruksområder i helsesektoren → | Detaljerte mønstre →

Sarbanes-Oxley Act krever revisjonsspor for finansielle data, uforanderlige oppføringer og tilgangskontroll.

• Uforanderlige oppføringer gjennom append-only-arkitektur
• Kryptografisk integritet — hash-kjedede oppføringer beviser at ingen har endret dem i ettertid
• Komplett skrivehistorikk med signert opphav for revisjonskrav
• Tidsreise for å gjenskape enhver historisk tilstand
• Signerte endringer beviser opphavet til alle endringer

⚠️ SOX krever i tillegg interne kontroller, attestasjoner fra ledelsen og arbeidsdeling — det er organisatoriske oppgaver.

Se bruksområder i finansnæringen → | Detaljerte mønstre →

Personvernforordningen krever retten til å bli glemt, dataportabilitet, sporing av samtykke og innebygd personvern.

• Koordinert datasletting — purgeDocHistory() sprer sletteforespørsler via katalogdatabasen til alle synkroniserte klienter
• Dataportabilitet gjennom eksportfunksjoner for dokumenter
• Innebygd personvern gjennom ende-til-ende-kryptering
• Revisjonsspor for skriveoperasjoner — signert append-only-historikk over alle dataendringer

⚠️ Purge-forespørsler når klientene ved neste katalogsynkronisering — enheter som aldri kobler seg til igjen, beholder dataene. GDPR krever i tillegg samtykkehåndtering, oppnevning av personvernombud og protokoll over behandlingsaktiviteter — det er ditt ansvar.

Se mønstre for etterlevelse →

Payment Card Industry Data Security Standard krever beskyttelse av betalingskortdata, tilgangskontroll og revisjonsspor.

• Sterk kryptering — AES-256-GCM under lagring, RSA per bruker under overføring, TLS på linjen
• Tilgangskontroll med navngitte nøkler for begrenset tilgang til sensitive data
• Revisjonsspor for skriveoperasjoner — signert append-only-historikk over alle dataendringer

⚠️ PCI-DSS er en omfattende standard som dekker nettverkssegmentering, sårbarhetshåndtering, overvåking og mer. MindooDB dekker kravene til kryptering og tilgangskontroll — resten er ditt ansvar. Vurder om du i det hele tatt trenger å lagre kortdata.

Se mønstre for etterlevelse →

• ✅ Komplett skrivehistorikk (append-only)
• ✅ Kryptografiske signaturer (bevis på opphav)
• ✅ Manipulasjonssikre oppføringer (hash-kjedet)
• ✅ Tidsreise (gjenskap enhver tilstand)
• ✅ Endringer med tidsstempel

• ✅ Kryptering på klientsiden (AES-256-GCM)
• ✅ Finmasket tilgangskontroll (navngitte nøkler)
• ✅ Nøkkelhåndtering (passordbeskyttet KeyBag)
• ✅ Koordinert datasletting (purge via katalogdatabasen)
• ✅ Datasuverenitet (tenants på klientsiden)

• ⚙️ Logging av lesetilgang (på appnivå)
• ⚙️ Samtykkehåndtering (på appnivå)
• ⚙️ Rollebasert tilgangskontroll (med navngitte nøkler)
• ⚙️ Regler for oppbevaring av data (med tidsbasert sharding)
• ⚙️ Rapportering for etterlevelse (med revisjonsdata)

• Hver skriveoperasjon signeres kryptografisk med forfatterens Ed25519-nøkkel
• Tidsstempler følger med i hver endringsoppføring
• Dokumenthistorikk kan gås gjennom med iterateDocumentHistory()
• Tidsreise gjør det mulig å gjenskape enhver historisk tilstand
• Slettinger markeres med tombstones (historikken bevares)

Merk: MindooDB logger automatisk skriveoperasjoner (hvem som endret hva). Logging av lesetilgang (hvem som så hva) må bygges på appnivå.

• Bevise hvem som endret hva og når
• Gjenskape tilstanden på et hvilket som helst tidspunkt
• Vise dataintegritet for revisorer
• Bygge logging av lesetilgang på appnivå oppå denne historikken
• Støtte krav til bevissikring (legal discovery)

Se dokumentasjonen om tidsreise →

• Tidsbasert sharding — Opprett databaser per tidsrom (per år, per måned)
• Arkivdatabaser — Flytt gamle data til skrivebeskyttede arkivdatabaser
• Dokumentets livsløp — Merk dokumenter som arkivert i stedet for å slette dem
• Koordinert purge — Admin-signerte purge-forespørsler spres via katalogdatabasen; klientene utfører dem ved neste synkronisering

Se mønstre for datamodellering →

• Append-only betyr at data samler seg opp over tid
• Planlegg håndtering av vekst fra starten
• Bruk tidsbasert sharding for effektiv arkivering
• Vurder oppbevaringskrav per dokumenttype
• Koordinert purge spres til synkroniserte klienter; enheter som er offline, beholder dataene

Se mønstre for etterlevelse →