Trust CenterTiltak
Tekniske og organisatoriske tiltak
En oppsummering av tiltakene som beskytter data i FlowDule: hvem som kan komme inn, hvordan data holdes adskilt og kryptert, hva som blir logget, og hvordan data blir slettet.
Sikkerhet som er bygget inn i plattformen
Personvernforordningens artikkel 32 krever at både behandlingsansvarlig og databehandler treffer egnede tekniske og organisatoriske tiltak. Denne siden gir en oversikt over FlowDules sikkerhetsmodell i et språk som kan brukes i deres egen dokumentasjon. Oversikten er informativ: det bindende sikkerhetsnivået fremgår av den aksepterte databehandleravtalen og det versjonsbundne TOMS-vedlegget, som har forrang ved uoverensstemmelse.
Beskrivelsen dekker identitet og tilgang, adskillelse av data mellom kjeder, kryptering, sporbarhet, dataintegritet, sletting og drift.
Les TOMS-vedleggetTiltak
Tiltakene dekker fem områder
Identitet og tilgang, kundeadskillelse, kryptering, sporbarhet og dataintegritet.
- Identitet og tilgang
Innlogging og tilgangskontroll
Innlogging skjer via AWS Cognito med signerte tokens. Tilgang styres av brukerens rolle og av hvilken kjede og hvilken lokasjon brukeren hører til. Har en bruker ikke tilgang, blir forespørselen avvist uten å avsløre om data i det hele tatt finnes.
- Kundeadskillelse
Hver kjedes data er adskilt
Data hører til én kjede om gangen. Kundeadskillelse håndheves i de relevante lagene: brukergrensesnitt, API, applikasjonslogikk, database og filtilgang, der databasens row-level security er konfigurert til å avvise forespørsler utover kjeden brukeren er logget inn på. Tilgang vurderes etter kundetilhørighet, rolle, lokasjon og den relevante arbeids- eller behandlingsrelasjonen.
- Kryptering
Kryptering under overføring og i journalen
Kommunikasjon med FlowDule beskyttes med moderne transportkryptering. Produksjonen bruker kryptering ved lagring for relevante databaser, filer og sensitive felter, og journaldata feltkrypteres med AES-256 og kjedespesifikke nøkler i AWS KMS. Øvrige detaljer om den kryptografiske implementeringen og nøkkeltilgang utleveres ved behov via sikker kanal.
- Sporbarhet
Handlinger skal kunne spores til en bruker
Relevante handlinger med klient- og journaldata skal kunne spores til en identifisert bruker eller en entydig systemkomponent. Logger beskyttes mot uautorisert endring og lesing, har dokumentert oppbevaringsfrist og unngår journaltekst, passord og tokens. Tilgangsloggen viser hvem som har sett eller endret en journal, og kunden er ansvarlig for å kontrollere egne brukeres arbeidsrelaterte oppslag.
- Dataintegritet
Originalen blir stående
Journalnotater versjoneres. En rettelse skjer som et tillegg, og den opprinnelige teksten bevares, slik at journalen kan leses slik den så ut den gangen.
Kundeadskillelse
Adskillelse i hvert lag
Kundeadskillelse håndheves i brukergrensesnitt, API, applikasjonslogikk, database og filtilgang. Har en bruker ikke tilgang, blir forespørselen avvist uten å avsløre om data i det hele tatt finnes.
- BrukergrensesnittSjekketAvviser
- APISjekketAvviser
- ApplikasjonslogikkSjekketAvviser
- Database med row-level securitySjekketAvviser
- FiltilgangSjekketAvviser
Svar etter rolle, lokasjon og relasjonSvaret avslører ikke om data finnes
Sletting
Sletting følger en dokumentert oppbevaringsprofil
Kundens oppbevaringsprofil fastsettes etter faggruppe, land, datakategori og formål. Sletting skal omfatte relevante databaser, filer, delinger, køer, hurtigbuffere, eksportfiler og andre aktive kopier, mens sikkerhetskopier fases ut gjennom dokumentert rotasjon. Reglene for hvor lenge journaldata lagres, og hva som skjer ved en forespørsel om sletting, er beskrevet for seg.
Se oppbevaring av journaldataDrift
Drift, sikkerhetskopi og løpende kontroll
Produksjonen kjører hos Kinsta (Sevalla) i Google Clouds datasentre: API, database, bookingsider og webapp. Cloudflare leverer edge og TLS foran alle Sevalla-apper og lagrer medier og databasesikkerhetskopier i Cloudflare R2. Innlogging (AWS Cognito), e-post (Amazon SES), KI-tjenestene og nøklene til feltkryptering av journaldata (AWS KMS) ligger hos AWS. Leverandører og overføringsgrunnlag fremgår av listen over underdatabehandlere.
Databasen sikkerhetskopieres daglig med 30 dagers rotasjon, og som ledd i gjenopprettingsprosedyren skal gjenoppretting prøves ut i et isolert miljø, der registrerte slettinger og legal holds brukes på nytt før miljøet åpnes.
Automatiske varsler reagerer på feil, mislykkede skrivinger til revisjonsloggen, masseoppslag i journaler og nye plattformeiere. Sårbarhets- og endringsstyring, patching, nøkkelrotasjon og hendelsesberedskap er faste krav til driften.
Se sikkerhetAvtalegrunnlaget bak tiltakene
- DatabehandleravtaleAvtalen mellom dere som behandlingsansvarlig og FlowDule som databehandler. De bindende tiltakene etter artikkel 32 fremgår av det versjons- og hashbundne TOMS-vedlegget, som aksepteres sammen med databehandleravtalen. Denne siden er bare en informativ oppsummering.
- UnderdatabehandlereListen over leverandører som behandler data på vegne av FlowDule, og hvordan endringer varsles.
- TOMS-vedleggDe bindende tekniske og organisatoriske tiltakene
Dokumentasjon
Trenger dere en detaljert beskrivelse til revisjonen deres?
Det aksepterte TOMS-vedlegget registreres med tittel, versjon og dokumenthash sammen med aksepten deres. Kontroll begynner normalt med den aksepterte TOMS og leverandørdokumentasjon, og detaljer som kan kompromittere sikkerheten eller andre kunders fortrolighet, utleveres bare via en sikker og fortrolig prosess. Skriv til privacy@flowdule.com med ønsket kontroll og periode.