Sikkerhedsdatablad
Introduktion
Dette dokument giver en samlet oversigt over Caseflows sikkerhedsforanstaltninger og overholdelse af gældende regler inden for Det Europæiske Økonomiske Samarbejdsområde (EØS). Det adresserer de mest almindelige kundebekymringer i relation til datasikkerhed, privatliv og datalagring. Dokumentet beskriver de kontraktuelle relationer med tredjeparter, de typer af data, der behandles om registrerede brugere på platformen, samt hvordan disse oplysninger beskyttes. Endelig redegøres der for de tiltag, der er implementeret for at sikre overensstemmelse med GDPR.
Terminologi
Den generelle forordning om databeskyttelse ("GDPR")
Den generelle forordning om databeskyttelse ("GDPR") trådte i kraft den 25. maj 2018. Den fokuserer på at styrke og ensrette databeskyttelsen for alle personer inden for EU. GDPR har en bred rækkevidde; den gælder for organisationer inden for EU såvel som organisationer uden for EU, hvis de tilbyder varer eller tjenester til personer, der bor i EU.
Dette whitepaper er ikke ment som juridisk rådgivning og bør ikke betragtes som sådan. Vi anbefaler på det kraftigste, at du søger juridisk rådgivning, hvis du er i tvivl om, hvordan GDPR påvirker din virksomhed (den dataansvarlige) og din brug af Caseflow (databehandleren).
Overholdelse af persondataforordningen:
Caseflows brugermodel
Anvendelsesniveau
Caseflow definerer fire forskellige brugerroller med adgang til data gennem applikationen:
Arrangører
Administratorer
Kandidater/deltagere
Bedømmere
Disse brugere har forskellige formål, og derfor er karakteren af de data, der gemmes om disse brugere, forskellig. I det følgende præsenteres de oplysninger, der behandles og/eller gemmes om hver type bruger.
Arrangør
En arrangør er en Caseflow-medarbejder, der er ansvarlig for at oprette organisationer og begivenheder og for at invitere Admins (kunderepræsentanter) via e-mail til at administrere begivenheder inden for deres egen organisation.
Arrangøren skal angive sit fulde navn, sin e-mailadresse og navnet på den organisation der oprettes - for at kunne oprette den eller de begivenheder, som administratorerne skal administrere. For disse begivenheder kan den pågældende arrangør se alle de kandidater/deltagere, der har tilmeldt sig, og alt det casemateriale, de har leveret, herunder vurderinger og scores.
Administrator
En administrator er en person, der af en organisation er udpeget til at opsætte en begivenhed. Eksempler på datafelter, som en administrator kan tilføje/ændre, er: eventnavn, tilmeldingsmuligheder, case konfiguration osv.
Ved registreringen skal administratorerne oplyse deres fulde navn og e-mailadresse. Caseflow har ikke brug for, eller gemmer, flere data om administratorer.
Administratorer kan se alle kandidater/deltagere, der har tilmeldt sig, har adgang til det casemateriale, der er indleveret af kandidaterne/deltagerne, og kan se de scores, der er givet for hvert casemateriale.
Kandidat/deltager
Den mest almindelige type bruger på Caseflow kaldes enten en kandidat eller en deltager, afhængigt af begivenhedens karakter:
Kandidaten bruges til rekrutterings-, uddannelses- og træningsbegivenheder
Deltager bruges til case-konkurrencer
Denne bruger tilmelder sig Caseflow-platformen og skal angive en e-mailadresse. Der kan anmodes om yderligere oplysninger, hvis det kræves af afsenderen af begivenheden (den dataansvarlige). Disse felter konfigureres af administrator(er) på vegne af den dataansvarlige på tidspunktet for opsætning af begivenheden og kan f.eks. omfatte: navn eller telefonnummer. Dette er ikke-udtømmende eksempler; de nøjagtige data, der indsamles, defineres pr. begivenhed.
Kandidater/deltagere har ikke adgang til casemateriale indsendt af andre brugere, og de kan heller ikke se listen over bedømmere eller administratorer. De kan ikke se deres egen score, medmindre administratoren vælger at gøre scoren synlig. I så fald vil brugerne kun se deres egen score og, hvis det er aktiveret, et gennemsnit for hele begivenheden, aldrig andres individuelle resultater.
Bedømmer
En bedømmer skal kun angive navn og e-mail ved registrering. En bruger kan kun blive bedømmer efter invitation fra en arrangør eller administrator - dette sker via e-mail. En bedømmer har tilladelse til at læse, gennemgå og rangordne casemateriale indsendt af kandidat(er)/deltager(e). Desuden har en bedømmer mulighed for at give feedback til kandidater/deltagere.
Bedømmere har ikke adgang til kandidat- / deltagerdata, da de er anonymiserede for dem. Bedømmere kan heller ikke se begivenhedens administratorer og arrangører og kan ikke administrere begivenhedens indhold.
Formålet med brugermodellen
Brugermodellen er implementeret for at skelne mellem de forskellige brugeres roller - nogle kan kræve flere/mindre privilegier end andre (f.eks. bedømmere). Ved at behandle de data, der er beskrevet i brugermodellen, er Caseflow i stand til at levere tjenester, der er i overensstemmelse med Caseflows brugeres interesser. Dette gælder for kandidater/deltagere, men også for arrangører og administratorer. Caseflows platform giver sådanne arrangører mulighed for yderligere kommunikation og støtte under et case-løsningsscenarie. Caseflow kræver kun det absolutte minimum af oplysninger (e-mail og navn, afhængigt af hvilken rolle) fra brugerne for at sikre, at brugere og enheder er unikke. Alle andre oplysninger på platformen gives frivilligt.
Caseflow bruger et passwordbaseret login-system. Hver bruger - uanset om det er arrangør, administrator, kandidat/deltager eller bedømmer - opretter sin egen adgangskode under tilmeldingsprocessen. Adgangskoder gemmes sikkert ved hjælp af industristandardiserede hashingalgoritmer og gemmes aldrig i almindelig tekst. Når brugerne logger ind, indtaster de deres e-mail og adgangskode via en sikker grænseflade. Glemte adgangskoder kan nulstilles via e-mail-baserede gendannelseslinks, som kun er gyldige i et begrænset tidsrum og udløber efter brug.
Systemniveau
Visse brugertyper har adgang til data gennem infrastrukturen. Disse brugere er betroede medlemmer af de autoriserede parter og Caseflows udviklings- og kundesuccesteam. Nogle udviklere og den tekniske leder er placeret uden for EØS, men ingen af disse Caseflow-medarbejdere har adgang til vores kunders eller brugeres personlige data:
Teknisk leder
Udviklere
Team for kundesucces
Teknisk leder
Den tekniske leder er et medlem af Caseflows udviklingsteam, som er ansvarlig for at opsætte CI (continuous integration) og CD (continuous deployment) pipelines på Azure (automatiske builds og deploys af nye applikationsversioner) og overvågning af applikationsinfrastrukturen på Azure (logs, sundhed) uden adgang til applikationsdataene.
Udviklere
Udviklerne af Caseflow-platformen har ingen adgang til infrastrukturen, herunder adgang til databasen og brugerfilerne.
Team for kundesucces
Kundesuccesteamet er Caseflow-medarbejdere, der arbejder inden for EØS. De får adgang til brugernes data via dashboards i Caseflow-applikationen for at forberede kandidat-/deltagerlister og rapporter til kunderne.
Caseflow Privatlivspolitik
Caseflow er baseret i Danmark, en del af EØS. Som sådan overholder Caseflow's teknologi, systemer og processer relevante juridiske krav med hensyn til databeskyttelse. Caseflow's fortroligheds- og cookiepolitik afspejler dette.
Kontrol af informationsadgang
Tjenesterne og databaserne er underlagt strenge sikkerhedsprotokoller, der leveres af Caseflow. Caseflow sikrer, at kun medarbejdere i EU har de nødvendige legitimationsoplysninger til at få adgang til disse tjenester - hvis det er absolut nødvendigt.
Desuden sikres et ekstra lag af sikkerhed ved at nægte adgang til ukendte IP-adresser, og Customer Lockbox for Azure er blevet aktiveret. Azure-serverne, der hoster tjenesterne, og som vedligeholdes af Caseflow, sikrer ISO-27001-certificering og giver mulighed for SOC2-revisionsrapporter fra tredjeparter efter anmodning fra en kunde under en passende NDA.
Opbevaring af data
Caseflows brugermodel indebærer, at oplysninger, som en registreret bruger har afgivet, gemmes i databaser, der tilgås via de tilknyttede applikationsservere. Data lagres på Azures databaseinfrastruktur i Vesteuropa.
Valget af Azure Cloud Services er baseret på deres evne til at håndtere høj belastning, sikre driftssikker performance og tilbyde global rækkevidde gennem CDN-teknologi. Azure er en af de største cloud-udbydere, der servicerer og hoster mange systemer. Med hensyn til databeskyttelse og compliance er Azure en af de førende udbydere:
Sikring af infrastrukturen
Servere og database
Alle applikationsservere og databaseservere kører i et virtuelt netværk, og adgangen til dem er reguleret af rollebaseret adgang (RBA). Sikker adgang er omfattende firewall-regler, der udtrykkeligt tillader adgang til ressourcerne i det virtuelle netværk. Reglerne er sat op på en sådan måde, at kun applikationsserverne kan få adgang til databasen. Al anden adgang er blokeret - selv hvis du har det rigtige link, brugernavn og password, kan du stadig ikke få adgang til databasen. Applikationsserverne kan kun tilgås af load balanceren og CD-infrastrukturen. Al anden adgang er blokeret - også selv om du kender den korrekte IP-adresse eller URL til serveren. Load balanceren er det eneste indgangspunkt fra det offentlige internet, og den håndhæver, at der kun er HTTPS-trafik. Det sikrer, at dataene er krypterede, at der ikke manipuleres med dem, og at vi taler med de tiltænkte brugere (hvilket beskytter mod angreb som man in the middle). Det skal bemærkes, at databaseserveren ikke kan tilgås fra LoadBalancers, selv om de deler det samme virtuelle netværk.
Caseflow har valgt at stramme sikkerhedsforanstaltningerne for at mindske risikoen for, at der sker utilsigtede fejl. Vi er klar over, at ikke kun ondsindede brugere kan udgøre en fare for dine data, men selv udviklerfejl, såsom at indstille en forkert URL ved en fejl eller udføre en forkert kommando til produktion i stedet for beta, kan også skade og lække data.
Opbevaring af filer
Filer, som brugerne uploader, gemmes på Azure-lagerservere og er beskyttet med en sikker nøgle. Det betyder, at hvis en bruger ønsker at uploade/tilgå en fil, skal vedkommende have en særlig forudunderskrevet nøgle udstedt af applikationsserverne, og den udsteder kun nøgler, der udløber efter en vis tid, til brugere, der er autoriserede og begrænset til deres aktuelle offentlige IP-adresse, så de ikke kan dele den forudunderskrevne nøgle.
CI/CD
Udrulning af nye versioner af applikationen er også en potentiel sikkerhedsrisiko, hvis det gøres manuelt - hvilket betyder, at driftsteamet skal have adgang til infrastrukturdelene. Caseflow har dog fuldstændig automatiseret denne proces med moderne CI/CD-principper og kræver ingen menneskelig interaktion. Det betyder, at hverken udviklere eller systemadministratorer har adgang til infrastrukturen eller de nødvendige legitimationsoplysninger. Udrulningen af applikationen håndteres fuldt ud af Continuous Deployment-pipelinen, som publicerer til serverne i det beskyttede VPC-miljø.
Adgangskoder, certifikater og andre adgangsoplysninger gemmes aldrig i kildekoden. Ved udrulning pakker Continuous Delivery-systemet applikationen med krypterede nøgler, som ikke er tilgængelige for udviklerteamet.
Mange angreb og lækager af data sker, fordi nogle systemer, selv om de tager mange sikkerhedsforanstaltninger, stadig er afhængige af andre pakker, der har sikkerhedsproblemer - og hackere kan udnytte disse svage led og få adgang til forbudte ressourcer. Caseflow bruger til en vis grad DevSecOps-principper til at sikre, at forældede afhængigheder i vores system bliver opdateret med det samme. Den automatiske release pipeline vil fejle, hvis den opdager sådanne afhængigheder - hvilket tvinger udviklerteamet til at opdatere dem. Nye versioner af pakker lapper og retter som regel sikkerhedssårbarheder ud over nye funktioner - og så længe vi holder os opdateret med dem, begrænser vi antallet af angreb, der kan ske.
Caseflow bruger Azure DevOps server, cloud hosted, til alle CI/CD pipelines, samt git til kodeversionskontrol. De automatiserede builds og releases udføres på Microsoft-hostede build-agenter. For at få adgang til Azure DevOps-serveren eller build-agenterne eller kodebasen eller CI/CD-pipelines skal du tilføjes som Caseflow-teammedlem i Caseflow-projektet på Azure DevOps-serveren. Azure DevOps server tilbyder, ud over CI/CD-processer, et helt værktøjssæt til håndtering af projekter, fra taskboards, teammedlemmer til kodeversionering, pakkefeeds, pull request og build-politikker, alt sammen på ét sted, i stedet for at bruge separate værktøjer til hver.
Foranstaltninger til databeskyttelse
Som databehandler har Caseflow til opgave at implementere passende tekniske og organisatoriske foranstaltninger for at sikre databeskyttelsesforanstaltninger. Disse omfatter, men er ikke udelukkende begrænset til:
Sikring af kryptering i hvile for personlige og alle data ved at bruge Azure-muligheden for transparent datakryptering til SQL Database.
Sikring af fortrolighed, integritet, tilgængelighed og modstandsdygtighed for behandlingssystemer ved at anvende de sikkerhedsforanstaltninger, der er nævnt i dette dokument, have flere instanser af serverne og anvende retry-mekanismer på applikationsniveau.
Begrænsning af, hvem der kan få adgang til personlige data, ved at kun ledende ingeniører har adgang til infrastrukturen for at sætte den op, anvende rettelser og ændringer i konfigurationen.
Sikre tilgængelighed og adgang til personlige data i tilfælde af en fysisk eller teknisk hændelse ved at kunne tilgå databasen og levere rapporter i tilfælde af en hændelse på applikationsserveren og ved regelmæssigt at tage backup af databasen og kunne gendanne den i tilfælde af en hændelse på databaseserveren.
Udføre regelmæssig test og evaluering af Caseflow-platformens sikkerhed med planlagte test af udviklerne hver anden uge og opdatere applikationen og infrastrukturen med sikkerhedsfunktioner.
Anvendelsesniveau
Caseflow sikrer databeskyttelse ved at bruge omhyggeligt udvalgte teknologistakke og udnytte deres sikkerhedsforanstaltninger, samt ved at anvende sikkerhedstjek og strenge valideringer i hele koden. Applikationen er også opbygget på en måde, så den består af front-end og back-end. Backend er hostet på den infrastruktur, der er beskrevet i de foregående afsnit. Frontenden serveres til brugernes maskiner og eksekveres der. Det er derfor, vi ikke gemmer nogen hemmelig information på frontenden og udelukkende bruger den til at præsentere data, der serveres af backenden. Back-end'en sørger for, at alle data bliver serveret til de rigtige brugere, der har adgang til dem.
Front end
Angular er et komplekst, men veldokumenteret framework, der tilbyder gode ud af boksen sikkerhedsforanstaltninger og regelmæssigt bliver opdateret og vedligeholdt af Google, da det bruges af de fleste af deres interne systemer.
Ved at bruge Angular som frontend får vi alle de sikkerhedsforanstaltninger, som Angular-frameworket tilbyder, ved at forhindre cross-site scripting, cross-site request forgery, cross-site script inclusion og også sanitizing af brugerinput for at nævne nogle få.
For at være beskyttet mod sådanne angreb følger Caseflow retningslinjerne ved ikke at generere HTML fra et brugerinput, ikke ændre den oprindelige angular-kode, holde sig opdateret, så snart det er muligt, ikke interagere direkte med DOM'en, bruge angular's medfølgende HttpClient og så videre. Ved at bruge Angular's routing-modul til al intern routing i applikationen, beskytter vi mod open redirect-angreb.
Det er på grund af alle de tidligere fordele, at Caseflow har brugt Angular til udvikling af frontenden til Caseflow.
Caseflow beskytter brugerne mod almindelige front-end-angrebsvektorer ved at gennemtvinge et sikkert, adgangskodebaseret login og sikre, at alle adgangsruter er godkendt. Login-grænsefladen kræver e-mail og adgangskode, og alle legitimationsoplysninger er beskyttet ved hjælp af industristandardiserede hashingalgoritmer. Mekanismer til nulstilling af adgangskode er sikret med tidsbegrænsede genoprettelseslinks, hvilket minimerer risikoen for uautoriseret adgang. Caseflow er klar over, at frontend-beskyttelse alene ikke er tilstrækkelig, og at ondsindede aktører kan forsøge at omgå brugergrænsefladen helt og målrette backend-slutpunkter direkte. Disse risici og de tilsvarende sikkerhedsforanstaltninger beskrives i næste afsnit.
Back end
Autentificering: Back-end er udviklet i .net core, hvilket gør det muligt for Caseflow hurtigt at udvikle nye funktioner. Det giver mønstre, der sikrer godkendelse og autorisation af alle anmodninger. Vi følger middleware-pipelinen fra Microsoft, som validerer tokens og afviser anmodningen (401 - unauthenticated) med det samme, uden at der udføres en eneste linje forretningslogik eller dataforespørgselskode. Dette filtrerer ethvert muligt angreb fra ondsindede brugere, der ikke er autentificerede.
Autorisation: Autorisationen er baseret på .net policy engine, som nægter adgang til alle brugere (selv godkendte), hvis de ikke har de nødvendige roller og adgangstilladelser. I bund og grund kan kandidater/deltagere kun få adgang til deres område (scope) af API'en og vil blive nægtet adgang til eventarrangørernes REST-endepunkter.
CORS: Vi tillader kun trafik fra specifikke domæner ved hjælp af CORS-politik - vi tillader ikke forespørgsler fra andre domæner, som vi ikke kender til. Da vi hoster flere konkurrencer på det samme domæne (challenge1 og challenge2 er begge hostet på *.caseflow.io), skal vi være forsigtige med angreb som session hijacking. Men da vi bruger token-baseret og ikke cookie-baseret autentificering, kan ondsindede scripts ikke påvirke cookien for en anden session, da den ikke eksisterer og ikke er relevant for vores applikation.
Database: Adgang til databasen er beskyttet mod ondsindede brugere ved aldrig at udføre brugerinput direkte. Alt brugerinput skal igennem valideringsfasen, hvor ugyldige anmodninger fejler hurtigt. Næste validering er på forretningslaget, hvor brugerinput konverteres til et domæneobjekt, hvor forretningsvalideringer finder sted - og fejler igen, hvis noget input er ugyldigt. Hvis alle valideringer består, udføres forespørgslerne af en ORM, som sikrer, at vi er beskyttet mod SQL-injection-angreb ved at udføre al databaseadgang gennem parameteriserede forespørgsler. Derudover bruger vi kodelinters, der ikke tillader commits af kode, der har Raw SQL-forespørgsler.
Praksis for gennemgang af kode
Nogle af ovenstående foranstaltninger er kun gyldige, hvis udviklerne følger standarderne - og her er der altid en chance for, at nogen ikke følger disse standarder (menneskelig fejl). For at afbøde dette problem har Caseflow indført strenge kodegennemgange, hvor alle teammedlemmer skal godkende ny kode, før den kommer ind i kodebasen. Der er erklæret politikker for repositoryet, så det er umuligt (forbudt) for ny kode at komme direkte ind i 'dev'- eller 'master'-grenene (da vi bruger gitflow-forgreningsstrategi) uden en pull-anmodning. Og for at en pull request kan blive færdiggjort eller flettet ind i dev-grenen, skal den opfylde politikkerne. En af politikkerne er, at alle teammedlemmer har gennemgået og testet koden, og at de godkender den. Først da kan den komme ind i kodebasen og blive publiceret til produktion.
Sårbarhedsstyringsprocedurer
Caseflow er klar over, at der før eller siden vil blive opdaget sårbarheder og andre trusler i systemet. Derfor er der defineret procedurer for, hvad der skal gøres i dette tilfælde. På infrastrukturniveau bruger Caseflow PaaS, så vi er sikre på, at serverne hele tiden er opdaterede, hvilket håndteres af cloud-udbyderen.
Detektering
Sårbarheder kan opdages af CI/CD-pipelinen i form af forældede pakker med bekræftede sårbarheder, fra overvågningen af Caseflow-applikationen med Application Insights, hvor hver anmodning, vellykket eller mislykket, logges og kan inspiceres, under test af applikationen fra udviklingsteamet eller rapporteret af applikationsbrugere.
Aktiv penetrationstest udføres som en del af CI/CD-processen ved hjælp af Whitesource.
Overvågning
Caseflow bruger Application Insights, en tjeneste fra Microsoft, som integreres fint med back-end. Det giver en bred vifte af log- og overvågningsfunktioner, herunder logning af anmodninger, parametre, udførelsestid, antal anmodninger, alarmer, hvis en anmodning tager for lang tid, og foreslår endda forbedringer.
Application Insights advarer også, hvis der opstår en ny mislykket anmodning, og leverer stacktrace, så udviklerne nemt kan løse problemet, og vi kan blive advaret, når der opstår et nyt problem i stedet for lejlighedsvis at tjekke, om der er et.
Prioritering
Så snart en sårbarhed opdages, prioriteres den af projektlederen og teamlederne.
Prioriteringen sker ved at tildele problemet en alvorlighedsgrad - som simpelthen er en værdi på en skala fra 1-4, hvor 1 er "kritisk", og 4 er "lav prioritet/nice to have".
Patchprocesser
En alvorlighedsgrad betegnet som "kritisk" betyder, at udviklerne skal stoppe, hvad de er i gang med, og straks undersøge og løse problemet. Derefter testes det lokalt, og hvis det lykkes, offentliggøres det og testes i beta-miljøet, som ligner produktionsmiljøet. Hvis testene er vellykkede i beta, frigives patchen til produktionsmiljøet og er tilgængelig for de almindelige brugere.
En anden sværhedsgrad kan betyde, at det vil blive løst i løbet af det aktuelle sprint, eller den laveste sværhedsgrad betyder, at det kan flyttes til næste sprint.
Uanset alvorlighedsgraden bliver alle problemer testet og frigivet til produktion på samme måde som beskrevet ovenfor.
Afsluttende bemærkninger
Caseflow sætter en ære i at opretholde førsteklasses sikkerhed for sine tjenester. Det er en af vores topprioriteter at imødekomme alle vores kunders bekymringer om privatlivets fred. Caseflow er i overensstemmelse med gældende lovgivning og retningslinjer for datasikkerhed.
Vi sætter pris på, at du tager disse spørgsmål lige så alvorligt, som vi gør. Hvis der er spørgsmål eller overvejelser, der ikke er blevet besvaret i denne artikel, vil vi med glæde hjælpe dig videre. Kontaktoplysninger kan findes på caseflow.io.