Sikkerhedsdatablad
Introduktion
Dette dokument tjener som en oversigt over Caseflows sikkerhed og overholdelse af gældende regler inden for Det Europæiske Økonomiske Samarbejdsområde (EØS). I dette dokument behandles de mest almindelige kundebekymringer i forbindelse med sikkerhed, privatliv og opbevaring. Dette dokument skitserer kontraktlige aftaler med tredjeparter og uddyber dataaktiver, der er gemt i forhold til registrerede på platformen, og hvordan disse oplysninger er beskyttet. Desuden forklarer dette dokument de skridt, der er taget for at sikre overholdelse af de gældende GDPR-regler.
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).
GDPR-kompatibilitet:
Introduktion
Dette dokument tjener som en oversigt over Caseflows sikkerhed og overholdelse af gældende regler inden for Det Europæiske Økonomiske Samarbejdsområde (EØS). I dette dokument behandles de mest almindelige kundebekymringer i forbindelse med sikkerhed, privatliv og opbevaring. Dette dokument skitserer kontraktlige aftaler med tredjeparter og uddyber dataaktiver, der er gemt i forhold til registrerede på platformen, og hvordan disse oplysninger er beskyttet. Desuden forklarer dette dokument de skridt, der er taget for at sikre overholdelse af de gældende GDPR-regler.
Caseflows brugermodel
Anvendelsesniveau
Caseflows tjenester introducerer 4 forskellige typer af brugere, som kan få adgang til data gennem applikationen:
Arrangører
Administratorer
Deltagere
Dommere
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 eller -repræsentant, der har ansvaret for at starte en begivenhed og invitere (pr. e-mail) administratorer til at producere indhold og administrere aktiviteter relateret til begivenheden med Caseflows forudgående samtykke.
Arrangøren skal angive fuldt navn, e-mail og firmanavn ved registreringen - for først at oprette firmaet og den begivenhed, som administratorerne skal administrere. Arrangører kan også producere indhold og administrere aktiviteter relateret til begivenheden. Arrangører har dog ikke adgang til alle events - men kun til dem, de har oprettet. For disse events kan arrangørerne se alle de deltagere, der har tilmeldt sig, og alt det casemateriale, de har leveret, samt dommernes bedømmelser af materialet.
Administrator
En administrator er en person, der er udpeget til at repræsentere en organisation ved at udpege dommere og producere indhold til en begivenhed. En administrator har de nødvendige rettigheder til at tilføje og ændre profilen for den organisation, vedkommende repræsenterer. Eksempler på datafelter, som en administrator kan tilføje/ændre, er: firmaprofilbillede, firmanavn, firmawebsted, stiftelsesdato, branche, firmastørrelse 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 deltagere, der har tilmeldt sig arrangementet, har adgang til alle de casematerialer, som deltagerne har leveret til deres arrangement, og kan se den gennemsnitlige score, som dommerne har givet for hvert casemateriale.
Deltager
En deltager er den mest talrige type bruger. Deltagere tilmelder sig Caseflow-platformen. For at tilmelde sig skal en deltager angive en e-mailadresse. Efter tilmelding kan en deltager (ikke-obligatorisk) tilføje oplysninger til sin profilside. Et ikke-omfattende udvalg af oplysninger, som en profilside kan indeholde, ville være: profilbillede, færdigheder, CV, DoB, køn, fødested, nuværende bopæl, uddannelsesmæssig baggrund.
Deltagerne har ikke adgang til andre deltageres casemateriale, ej heller til listen over dommere og administratorer af arrangementet. Deltagerne kan ikke se deres score, medmindre administratoren beslutter at afsløre den. Men selv da kan deltagerne kun se deres egen score, og hvis administratoren beslutter at afsløre den; et gennemsnit på tværs af alle deltagere, dvs. ikke specifikke deltagere.
Deltagerens profil er offentlig på Caseflow - hvilket betyder, at enhver bruger, der kender den korrekte URL til deltageren, kan se hans profil og dermed de data, deltageren har leveret. Det er værd at bemærke, at denne URL også indeholder GUID. Dette er udelukkende gjort af forretningsmæssige årsager, da dette er et site til talentudvikling. Caseflow er klar over den potentielle risiko og kan nemt slå denne funktion fra - og til gengæld gøre deltagerprofilerne synlige kun for arrangørerne og administratorerne af de events, som deltageren deltager i.
Dommer
En dommer skal kun angive navn og e-mail ved registrering. En bruger kan kun blive dommer efter invitation fra en arrangør eller administrator - dette sker via e-mail. En dommer har tilladelse til at læse, gennemgå og rangordne casemateriale indsendt af deltager(e). Desuden har en Judge mulighed for at give feedback til deltagerne.
Dommerne har ikke adgang til deltagernes data, da de er anonymiserede for dem. Dommerne kan heller ikke se administratorerne og arrangørerne af eventet, og de kan ikke administrere eventets indhold.
Formålet med brugermodellen
Formålet med Caseflows brugermodel er at sikre, at besværet med at tilmelde sig flere casekonkurrencer og hackathons minimeres. Brugermodellen er også implementeret for at kunne skelne mellem forskellige brugeres roller - nogle kan kræve flere/mindre privilegier end andre (f.eks. dommere). Ved at behandle de data, der er skitseret i brugermodellen, er Caseflow i stand til at levere tjenester, der er i overensstemmelse med Caseflows brugeres interesser. Dette gælder for deltagere, men også for arrangører, som ofte repræsenterer en organisation, der søger viden om et specifikt problem. Caseflows platform giver sådanne arrangører mulighed for yderligere kommunikation og støtte under et caseløsningsscenarie. Caseflow kræver kun det absolutte minimum af information (fuldt navn og e-mail) fra brugerne for at sikre, at brugere og enheder er unikke. Alle andre oplysninger på platformen gives frivilligt.
Caseflow gemmer ikke nogen form for password - hver gang en bruger (arrangør, administrator, deltager eller dommer) ønsker at logge ind, modtager de et unikt link, der er gyldigt i en bestemt periode, på deres e-mail. De skal klikke på linket for at komme ind på Caseflow-platformen. Hvert nyt login genererer et nyt unikt link, som ugyldiggør tidligere links i processen.
Systemniveau
Der er specifikke typer af brugere, som kan få adgang til data gennem infrastrukturen. Disse brugere er betroede medlemmer af de autoriserede parter og Caseflows udviklings- og ledelsesteam. 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
Ledelsesteam
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, ingen adgang til databasen og brugerfilerne.
Ledelsesteam
Ledelsesteamet er Caseflow-medarbejdere, der arbejder fra EØS. De har adgang til brugernes data via dashboards i PowerBI for at kunne analysere statistikker og udarbejde 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
Caseflow's brugermodel indebærer, at oplysninger fra en registreret persisteres i databaser, der er tilgængelige fra tilknyttede applikationsservere. Data gemmes på Azure databaseinfrastruktur (Vesteuropa).
Caseflow valgte Azure cloud service providers, fordi de tilbyder commodities som opskalering til store trafikstigninger, computerkraft, leveringsevne over CDN for at nævne nogle få. 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
Publicering eller frigivelse 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 ingen udviklere eller driftsingeniører har adgang eller legitimationsoplysninger til infrastrukturen. Continuous Deployment-pipelinen tager sig af at udgive applikationen på serverne i den beskyttede VPC.
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 og dataansvarlig 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.
Forreste ende
Angular har en stejl indlæringskurve, men det tilbyder gode sikkerhedsforanstaltninger ud af boksen og bliver regelmæssigt 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 social hacking ved at kræve, at de åbner et link, som vi sender til dem via e-mail, hver gang de logger på applikationen, et link, der kun er gyldigt i en begrænset periode - hvilket betyder, at potentielle angribere også skal have adgang til deres e-mailindbakke. At have sikkerhed på front-end er langt fra nok til at have et beskyttet datasæt, da ondsindede brugere altid kan bruge andre værktøjer til at udføre endpoints direkte på serversiden og dermed springe front-end helt over.
Bageste ende
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 autentificerede), hvis de ikke har de nødvendige roller og adgangstilladelser. I bund og grund kan deltagere kun få adgang til deres område (scope) af API'en og vil blive nægtet adgang til eventarrangørernes REST-slutpunkter.
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, og det er cloud-udbyderens ansvar.
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".
Lapning
En alvorlighedsgrad på "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 har nøje undersøgt de gældende love 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.