Turvalisus KKK 

Kas viimase 5 aasta jooksul on esinenud olulisi turvarikkumisi või -intsidente?

Ei.

Kas privilegeeritud ja üldiste kontode juurdepääsu kontrollitakse rangelt ja vaadatakse perioodiliselt üle, vähemalt

igal aastal?

Jah.

Milliseid andmeid kasutaja kohta kogutakse? 

Tarkvara kogub andmeid kontoomaniku ja lõppkliendi kohta. Mõlemad andmed põhinevad kontoomaniku ja lõppkliendi esitatud andmetel. Me ei kogu mingeid andmeid, mis ei kuulu lõppkasutaja või kontoomaniku poolt vabatahtlikult antud andmetele. 

Kontoomanik võib luua tekstivälju, et koguda broneerimisel erinevaid andmepunkte, kuid klient on täielikult teadlik kogutavatest andmetest, kuna lõppkasutaja sisestab andmed väljadele. Lõppkasutaja või kontoomanik võib igal ajal taotleda andmete kustutamist, saates selleks e-kirja aadressil data@bookafy.com. 

Milleks rakendus andmeid kasutab?

Rakenduse andmeid kasutatakse ainult selle tehingu jaoks, mille lõppklient on allkirjastanud. Kui kasutate SSO abil sisselogimiseks kolmanda osapoole rakendust, näiteks Facebooki või Google’i, kasutame seda ühendust ainult kontole juurdepääsu saamiseks. Me ei kasuta konto andmeid, nagu kontaktid, sündmused, e-kirjad, ega postita teie nimel ega osale teie kontol toimuvas tegevuses. Seda kasutatakse ainult sisselogimiseks. 

Millised on kasutaja õigused andmete kustutamiseks ja kuidas saab kasutaja taotleda andmete kustutamist? 

Kasutame kontoomanikult (meie kliendilt) kogutud andmeid, et pakkuda kontoomanikule paremat kasutuskogemust. Siia kuuluvad kõik kohad, kus AO on kinni jäänud, mida ta on mitu korda külastanud, mille kohta tal võib olla küsimusi või mille kohta ta võib olla viga. Me kasutame neid andmeid selleks, et suhelda oma klientidega (kontoomanikuga) õigel ajal ja õige sõnumiga. 

Lõppkasutajale, meie kliendi kliendile… me kasutame neid andmeid ainult kontoomanikuga tehtava tehingu (broneeringu) jaoks. Me ei turusta neid kliente ega kasuta nende andmeid muul viisil. Nende andmeid ei müüda ega laenata… need jäävad meie süsteemi. 

Nii volitatud ettevõtja kui ka lõppkliendi andmed võib igal ajal kustutada. AO võib saata e-kirja aadressil data@bookafy.com ja taotleda oma konto ja andmete eemaldamist. Lõppklient võib taotleda, et volitatud ametiasutus eemaldaks tema andmed. 

Kas töötajate ühiskasutuskontod on keelatud? Mis saab klientidest?

Töötajatel on omaette kontod. Klientidel on ka oma eraldi kontod, millel on juurdepääs ainult nende andmetele.

Kas teie paroolide konstrueerimine nõuab mitmekordseid tugevusnõudeid, st tugevaid paroole ja kasutab juhuslikku tähe-, numbri- ja erimärkide jada?

Nõuame paroolide haldamisel põhilisel tasemel vähemalt 6 tähemärki. OWASP ja NIST SP 800-63-3 paroolipoliitika valikud võivad olla saadaval tuleval aastal.

Kas võrgu piirid on kaitstud tulemüüriga, millel on sisenemis- ja väljumisfiltreerimine?

Jah. Kõik tulemüürid ja koormuse tasakaalustamise võimalused on ette nähtud Azure’i ja Amazon AWSi poolt.

Kas avalikud serverid asuvad hästi määratletud de-militariseeritud tsoonis (DMZ)?

Jah, see on päritud Azure’i vaikimisi infrastruktuuri tsoneerimisest ja Bookafy on jaotatud piirkondlikud serverid üle kogu maailma. 

Kas sisevõrgu segmenteerimist kasutatakse tundlike tootmisressursside, näiteks PCI-andmete täiendavaks isoleerimiseks?

PCI-andmeid ei salvestata, kuna Bookafy raamib neid ainult kolmandate osapoolte pakkujatelt, nagu Stripe ja Authorize.net. Bookafy ei kogu andmeid ega salvesta andmeid. 

Kas võrgus on rakendatud ja jälgitud sissetungituvastust või -tõrjet?

Lai valik seirevahendeid, mida täiendavad Azure’i pakutavad teated ja hoiatused, on pidevalt sisse lülitatud. See hõlmab sissetungi tuvastamist ja e-posti kinnitusi võrgule juurdepääsu kohta.

Kas kõik lauaarvutid on kaitstud regulaarselt ajakohastatud viiruste, usside, nuhkvara ja pahatahtliku koodi tarkvara abil?

Jah.

Kas serverid on kaitstud tööstusharu karastamistavade abil? Kas tavad on dokumenteeritud?

Turvateenuseid kasutatakse regulaarselt süsteemi turvaauditite tegemiseks. 

Kas kõigi operatsioonisüsteemide, võrguseadmete ja rakenduste puhul on olemas aktiivne tootjapoolne paranduste haldamine?

Jah. Seda pakub Azure automaatselt oma teenuse kaudu.

Kas kõik tootmissüsteemi vead ja turvasündmused on salvestatud ja säilitatud?

Logisid säilitatakse vähemalt 1 kuu, mõned neist jäävad kuni 6 kuuks, sõltuvalt nende tõsidusest ja vajalikest meetmetest.

Kas turvasündmused ja logiandmed vaadatakse korrapäraselt üle?

Jah. Logid vaadatakse üle iga päev, nädalas ja kuus – sõltuvalt logisündmuste laadist.

Kas on olemas dokumenteeritud eraelu puutumatuse tagamise programm koos kaitsemeetmetega, mis tagavad kliendi konfidentsiaalse teabe kaitse?

Jah.

Kas on olemas protsess, mille abil teavitatakse kliente, kui esineb mõni eraelu puutumatuse rikkumine?

Jah.

Kas te säilitate, töötlete, edastate (st “töötlete”) isikuandmeid (PII)?

Jah.

Millises riigis või riikides säilitatakse isikuandmeid?

Enamik meie PII-andmetest on salvestatud USAs. Siiski on meil võimalik salvestada meie äriklientide kontoandmeid konkreetses piirkondlikus keskuses. Näide. Austraalia organisatsioon võib valida, et tema andmeid hoitakse meie Canberra Azure’i asukohas. Või Euroopa riigid saavad salvestada Euroopa andmekeskuses. 

Kas süsteemi logid on kaitstud muutmise ja hävitamise eest?

Seda pakub Azure ja seda varundatakse Dropboxi pilvesalvestusse.

Kas piir- ja VLAN-i sisenemispunktid on kaitstud sissetungikaitse- ja tuvastusseadmetega, mis annavad hoiatusi, kui neid rünnatakse?

Jah. Need teenused on kaasatud meie Azure’i tulemüüri, mis kaitseb sissetungi eest ja saadab automaatseid hoiatusi meie arendusmeeskonnale. 

Kas logid ja sündmused on korrelatsioonis vahendiga, mis annab hoiatusi käimasoleva rünnaku kohta?

Jah, meie turvateenus sisaldab logimist ja hoiatusi rünnakute kohta reaalajas. 

Kuidas on andmed lahenduse sees eraldatud teistest klientidest, sealhulgas võrkudest, esipunktidest, tagasisalvestusest ja varundustest?

Iga kliendikonto on loogiliselt eraldatud teistest klientidest, kasutades nõutavat püsivat üürniku identifikaatorit kõigis andmebaasi kirjetes.

Lisaks nõuab kogu rakenduskood seda üürniku identifikaatorit kõigi operatsioonide jaoks – nii lugemiseks kui ka kirjutamiseks. Samuti on kehtestatud automatiseeritud testimise kord, et kaitsta koodimuudatusi regressioonide ja võimaliku rentnike vahelise andmete saastumise eest.

Rentniku identifikaator on “kõvasti seotud” iga kasutajakontoga ja seda rakendatakse loogiliselt andmebaasi päringute fikseeritud “WHERE” klauslite ja samaväärsete meetmetega failidele juurdepääsu puhul. Platvormi kasutaja ei saa oma seanssi või kontot muuta ega muul viisil lahti siduda selle rentniku identifikaatoriga. Seega ei ole loogilist võimalust, et kasutajal on sisselogimisõigus teise rentniku identifikaatori all. Isegi kui nad üritasid siseneda lehekülgedele, kasutades teise üürniku ID-d, lükkas süsteem taotluse tagasi, kuna kasutajakonto ei olnud registreeritud soovitud üürniku ID-le.

Kas teil on juhtumite lahendamise plaan?

Jah, säilitatakse “elavat dokumenti”, milles kirjeldatakse katastroofidele ja intsidentidele reageerimist.

kontrollnimekirjad, kontaktandmed ja peamised süsteemi vahendid intsidentidest arusaamiseks ja neile reageerimiseks.

Milline on võrgu kaitse tase?

Kasutame Azures Web Application gateway’d (koormuse tasakaalustaja) ja Next Generation Firewall’i, et kaitsta meie Azure Cloudis töötavate virtuaalmasinate võrku. 

Kas platvorm pakub aruandeid teenusekvaliteedi (QOS) tulemuslikkuse mõõtmiseks (ressursside kasutamine, läbilaskevõime, kättesaadavus jne)?

Selliseid näitajaid ei esitata klientidele, välja arvatud kättesaadavus ja vastamisajad vastavalt meie staatuse leheküljele status.pingdom.com.

Kas katastroofide taastamise programmi testitakse vähemalt kord aastas?

Jah, taastamiskontrollid ja -testi viiakse läbi ning neid testitakse igal aastal.

Milline on süsteemi taastumisaja eesmärk (RTO) ja taastumispunkti eesmärk (RPO)?

RTO on 4 tundi, RPO on 1 tund.

Kas te pakute üksikklientidele varundus- ja taastamisplaane?

Kõik aspektid on mitmekülgsed, nii et varukoopiaid tehakse kogu kliendibaasist. Täielikke failide varukoopiaid tehakse iga 24 tunni järel ja need saavad kasu Azure’i andmebaasi punktuaalsetest varukoopiatest, mis tehakse iga 5 minuti järel. Varukoopiaid hoitakse Dropboxi pilvepakendis ja ka üleliigsetel Azure’i virtuaalmasinatel. 

Milline on maksimaalne aeg, mille jooksul varukoopiaid säilitatakse?

Andmebaasi punktuaalsed varukoopiad säilitatakse 30 päeva, üldised failide varukoopiad vähemalt 90 päeva.

Milline on andmete taastamise eeldatav aeg?

Iga kliendi taastamist mis tahes mitte-katastroofistsenaariumi korral tuleb taotleda ja planeerida koos meiega. Toimetulekuaeg on 1-2 tööpäeva. 

Kas üksiku üksuse konto saab taastada, ilma et see mõjutaks kogu platvormi?

Kui klient soovib konkreetse kirje või artefakti restaureerimist, saab seda teha veebipõhiselt iga taotluse alusel ja see on tasuline töö. See ei mõjuta platvormi ega kliendikontot.

Kas kõrge kättesaadavus on tagatud – i. e. kui üks serveri instants muutub kättesaamatuks, kas teine muutub kättesaadavaks?

Azure’i virtuaalmasina kaudu töötavad kõikidel süsteemitasanditel mitu serveriinstantsi, kusjuures veebirakenduste värav tegeleb koormuse tasakaalustamisega. Andmekeskuses oleva serveri instantsi tõrgetega tegeleb Azure WAG, kusjuures probleemne instants võetakse ringlusse ja/või eemaldatakse ja asendatakse uue instantsiga.

Kas andmed on salvestatud ja kättesaadavad teises asukohas (andmekeskuses), et täita katastroofide taastamise nõudeid?

Jah. Kõik andmed replitseeritakse teise andmekeskusesse, mis erineb geograafilise asukoha järgi, samuti on varundatud andmed salvestatud Dropboxi pilvesalvestusse. .

Kas ümberlülitusprotsess on aktiivne/aktiivne, automaatne ümberlülitusprotsess?

Esmase andmekeskuse serveri instantsi tõrgetega tegelevad Azure WAG koormuse tasakaalustajad, kusjuures probleemne instants taaskasutatakse ja/või eemaldatakse ja asendatakse uue instantsiga.

Juhul kui kogu andmekeskuses peaks tekkima kriitiline rike, siis on üleminek sekundaarkeskusele käsitsi, kuna peame esmalt teostama probleemi täieliku hindamise, et tagada, et olemasoleva esmase keskuse olemasolu säilitamiseks ei ole lihtsaid lahendusi. Kui on kindlaks tehtud, et on vaja liikuda sekundaarkeskusesse, siis algatatakse üleminek käsitsi, et saavutada taastamise eesmärgid.