Bookafy Sikkerhet og personvern

Vanlige spørsmål om sikkerhet 

Har noen vesentlige sikkerhetsbrudd eller hendelser skjedd de siste 5 årene?

Nei.

Er privilegert og generisk kontotilgang tett kontrollert og gjennomgått med jevne mellomrom, minst

årlig?

Ja.

Hvilke data samles inn om brukeren? 

Programvaren samler inn data om kontoeieren og sluttkunden. Begge oppsettdataene er basert på dataene gitt av kontoeieren og sluttkunden. Vi samler ikke inn noen data utenom de frivillige dataene gitt av sluttbrukeren eller kontoeieren. 

Kontoeieren kan opprette tekstfelt for å samle inn forskjellige datapunkter ved bestilling, men kunden er fullstendig klar over at de samles inn ettersom sluttbrukeren ville skrive inn dataene i feltene. Sluttbrukeren eller kontoeieren kan be om sletting av data når som helst ved å sende en e-post til data@bookafy.com 

Til hvilke formål bruker appen dataene?

Appdataene brukes kun for transaksjonen sluttkunden har registrert seg for. Hvis du bruker en tredjepartsapp for å logge på med SSO, som Facebook eller Google, bruker vi kun denne tilkoblingen for kontotilgang. Vi bruker ikke data fra kontoen som kontakter, arrangementer, e-postmeldinger og vi legger ikke ut på dine vegne eller deltar i noen aktivitet på kontoen din. Den brukes kun til innlogging. 

Hva er brukerrettighetene for sletting av data og hvordan kan brukeren be om å få dataene slettet? 

Vi bruker dataene som samles inn fra kontoeieren (vår kunde) for å levere en bedre opplevelse til kontoeieren. Dette inkluderer alle steder AO har sittet fast, besøkt mange ganger, kan ha spørsmål om eller en feil. Vi bruker disse dataene til å kommunisere med våre kunder (Kontoeier) til rett tid med riktig budskap. 

For sluttbrukeren, vår kundes kunde… bruker vi kun disse dataene for transaksjonen (bestillingen) med kontoeieren. Vi markedsfører ikke til disse kundene, eller bruker deres data på noen annen måte. Dataene deres blir ikke solgt eller lånt… de forblir i systemet vårt. 

Både når det gjelder AO og sluttkunde, kan dataene deres slettes når som helst. AO kan sende en e-post til data@bookafy.com og be om at kontoen og dataene deres fjernes. Sluttkunden kan be om at dataene deres fjernes av AO. 

Er delte brukerkontoer forbudt for ansatte? Hva med kunder?

Ansatte har sine egne dedikerte kontoer. Kunder har også sine egne dedikerte kontoer, med kun tilgang til dataene deres.

Krever din passordkonstruksjon flere styrkekrav, dvs. sterke passord og bruker en tilfeldig sekvens av alfa-, numeriske og spesialtegn?

Vi krever minimum 6 tegn i passord på det grunnleggende passordadministrasjonsnivået. OWASP og NIST SP 800-63-3 passordpolicyalternativer kan være tilgjengelige i løpet av det kommende året.

Er nettverksgrensen beskyttet med en brannmur med inn- og utgangsfiltrering?

Ja. Alle brannmurer og lastbalanseringsfasiliteter leveres av Azure og Amazon AWS.

Er offentlige servere i en veldefinert demilitarisert sone (DMZ)?

Ja, dette er arvet fra Azures standard infrastruktursoning og Bookafy har regionale servere spredt over hele verden. 

Brukes intern nettverkssegmentering for ytterligere å isolere sensitive produksjonsressurser som PCI-data?

PCI-data lagres ikke da de kun er innrammet av Bookafy fra tredjepartsleverandører som Stripe og Authorize.net. Bookafy samler ikke inn data eller lagrer data. 

Er nettverksinntrengingsdeteksjon eller -forebygging implementert og overvåket?

Et bredt spekter av overvåkingsverktøy, supplert med varsler og varsler levert av Azure, forblir konstant på. Dette inkluderer inntrengningsdeteksjon og e-postbekreftelser om nettverkstilgang.

Er alle stasjonære datamaskiner beskyttet med regelmessig oppdaterte virus-, ormer-, spionprogrammer og skadelig kodeprogramvare?

Ja.

Er servere beskyttet ved hjelp av industriherdingspraksis? Er praksisen dokumentert?

Sikkerhetstjenester brukes regelmessig for å gi systemsikkerhetsrevisjoner. 

Er det aktiv leverandørpatchadministrasjon for alle operativsystemer, nettverksenheter og applikasjoner?

Ja. Dette leveres av Azure automatisk via deres tjeneste.

Blir alle produksjonssystemfeil og sikkerhetshendelser registrert og bevart?

Logger lagres i minimum 1 måned, med noen gjenværende opptil 6 måneder, avhengig av alvorlighetsgrad og nødvendig handling.

Gjennomgås sikkerhetshendelser og loggdata regelmessig?

Ja. Logger gjennomgås daglig, ukentlig og månedlig – avhengig av arten av logghendelsene.

Er det et dokumentert personvernprogram på plass med sikkerhetstiltak for å sikre beskyttelse av klientens konfidensielle informasjon?

Ja.

Er det en prosess på plass for å varsle klienter hvis det oppstår personvernbrudd?

Ja.

Lagrer, behandler, overfører du (dvs. «håndterer») personlig identifiserbar informasjon (PII)?

Ja.

I hvilket land eller hvilke land lagres PII?

De fleste av våre PII-data er lagret i USA. Vi er imidlertid i stand til å lagre kontodata for våre bedriftskunder i et spesifikt regionalt senter. Eksempel. Australske organisasjoner kan velge å ha dataene sine lagret på vår Canberra Azure-lokasjon. Eller europeiske land kan lagre i europeiske datasenter. 

Er systemloggene beskyttet mot endring og ødeleggelse?

Dette leveres av Azure og er sikkerhetskopiert på Dropbox Cloud Storage.

Er grense- og VLAN-inngangspunkter beskyttet av inntrengningsbeskyttelse og deteksjonsenheter som gir varsler når de er under angrep?

Ja. Disse tjenestene er inkludert i Azure-brannmuren vår som beskytter mot inntrenging og sender automatiserte varsler til utviklingsteamet vårt. 

Er logger og hendelser korrelert med et verktøy som gir advarsler om et angrep som pågår?

Ja, sikkerhetstjenesten vår inkluderer logging og varsler om angrep i sanntid. 

Hvordan skilles data fra andre klienter i løsningen, inkludert nettverk, front-ends, back-end-lagring og sikkerhetskopier?

Hver klientkonto er logisk atskilt fra andre klienter, gjennom bruk av en nødvendig vedvarende leietaker-identifikator på alle databaseposter.

I tillegg krever all applikasjonskode denne leietakeridentifikatoren for alle operasjoner – både lesing og skriving. Et automatisert testregime er også på plass for å beskytte kodeendringer mot regresjoner og mulig datakontaminering på tvers av leietakere.

Leietakeridentifikatoren er «hardt linked» til hver brukerkonto og håndheves logisk gjennom faste «WHERE»-klausuler på databasespørringer og tilsvarende tiltak for filtilgang. En plattformbruker kan ikke endre eller på annen måte koble fra økten eller kontoen sin fra denne leietakeridentifikatoren. Dermed er det ingen logisk mulighet for at en bruker har påloggingsautorisasjon under en annen leietakeridentifikator. Selv om de prøvde å få tilgang til sider med en annen leietakers ID, ville systemet avvise forespørselen på grunn av at brukerkontoen ikke er registrert på den forespurte leietaker-IDen.

Har du en hendelsesplan?

Ja, det opprettholdes et «levende dokument» som skisserer katastrofe- og hendelsesrespons

sjekklister, kontaktdetaljer og sentrale systemfasiliteter for å forstå og svare på hendelser.

Hvilket nivå av nettverksbeskyttelse er implementert?

Vi bruker Azures Web Application gateway (lastbalanser) og neste generasjons brannmur for å beskytte nettverket vårt av virtuelle maskiner som kjører på Azure Cloud. 

Tilbyr plattformen rapporter for ytelsesmålinger for Quality of Service (QOS) (ressursutnyttelse, gjennomstrømning, tilgjengelighet osv.)?

Slike beregninger er ikke gitt til kunder, bortsett fra tilgjengelighet og responstider i henhold til vår statusside på status.pingdom.com

Testes katastrofegjenopprettingsprogrammet minst årlig?

Ja, gjenopprettingssjekker og utført og testet årlig.

Hva er Recovery Time Objective (RTO) og Recovery Point Objective (RPO) for systemet?

RTO er 4 timer, med RPO er 1 time.

Tilbyr du backup- og gjenopprettingsplaner for individuelle klienter?

Alle aspekter er multi-tenanted, så sikkerhetskopier tas på tvers av hele klientbasen. Komplette sikkerhetskopier av filer kjøres hver 24. time, og dra nytte av Azure-database-sikkerhetskopier tatt hvert 5. minutt. Sikkerhetskopier lagres på Dropbox Cloud så vel som redundante virtuelle Azure-maskiner. 

Hva er maksimal tid som sikkerhetskopier beholdes?

Sikkerhetskopier av databaser på tidspunktet lagres i 30 dager, med generell sikkerhetskopiering av filer i minimum 90 dager.

Hva er forventet behandlingstid for en datagjenoppretting?

Enhver klientgjenoppretting i ethvert ikke-katastrofescenario må forespørres og planlegges med oss. Behandlingstid er mellom 1 og 2 virkedager. 

Kan en enkelt enhetskonto gjenopprettes uten å påvirke hele plattformen?

Hvis restaurering av en spesifikk post eller artefakt kreves av en klient, kan dette utføres online via en per forespørsel-basis og er kostnadsbelagt arbeid. Det er ingen innvirkning på plattformen eller kundekontoen.

Er høy tilgjengelighet gitt – dvs. e. der en serverforekomst blir utilgjengelig, blir en annen tilgjengelig?

Flere serverforekomster kjører på alle systemnivåer gjennom Azures virtuelle maskin, med nettapplikasjonsgateway som håndterer lastbalansering. Feil i en serverforekomst i datasenteret håndteres av Azure WAG, med problemforekomsten resirkulert og/eller fjernet og erstattet med en ny forekomst.

Er data lagret og tilgjengelig på et annet sted (datasenter) for å oppfylle kravene til nødgjenoppretting?

Ja. Alle data blir replikert til et andre datasenter som er forskjellig etter geografisk plassering, i tillegg til å ha sikkerhetskopiert data lagret på Dropbox Cloud Storage. .

Er failover-prosessen en aktiv/aktiv, automatisert overgangsprosess?

Feil i en serverforekomst i det primære datasenteret håndteres av Azure WAG-lastbalansere, med problemforekomsten resirkuler og/eller fjernes og erstattes med en ny forekomst.

Hvis hele datasenteret skulle ha en kritisk feil, er overgangen til det sekundære senteret en manuell prosess, ettersom vi må utføre en fullstendig vurdering av problemet først for å sikre at det ikke er noen enkle løsninger for å beholde den eksisterende primære. sentertilstedeværelse tilgjengelig. Hvis det fastslås at en flytting til det sekundære senteret er nødvendig, vil overgangen bli initiert manuelt for å oppfylle gjenopprettingsmålene.