Varaa suojaus ja tietosuoja

Turvallisuus FAQ 

Onko viiden viime vuoden aikana tapahtunut merkittäviä tietoturvaloukkauksia tai -tapauksia?

Ei.

Ovat etuoikeutettuja ja yleisiä tilin käyttöoikeuksia valvotaan tiukasti ja tarkistetaan säännöllisin väliajoin, vähintään

Vuosittain?

Kyllä.

Mitä tietoja käyttäjästä kerätään? 

Ohjelmisto kerää tietoja tilinomistajasta ja loppuasiakkaasta. Molemmat asetukset perustuvat tilinomistajan ja loppuasiakkaan toimittamiin tietoihin. Emme kerää muita tietoja kuin loppukäyttäjän tai tilinomistajan vapaaehtoisesti antamia tietoja. 

Tilin omistaja voi luoda tekstikenttiä eri tietojen keräämiseksi varauksen yhteydessä, mutta asiakas on täysin tietoinen kerättävistä tiedoista, koska loppukäyttäjä kirjoittaa tiedot kenttiin. Loppukäyttäjä tai tilin omistaja voi pyytää tietojen poistamista milloin tahansa lähettämällä sähköpostia osoitteeseen data@bookafy.com. 

Mihin tarkoituksiin sovellus käyttää tietoja?

Sovelluksen tietoja käytetään vain siihen tapahtumaan, johon loppuasiakas on kirjautunut. Jos käytät SSO-kirjautumiseen kolmannen osapuolen sovellusta, kuten Facebookia tai Googlea, käytämme tätä yhteyttä vain tilinkäyttöön. Emme käytä tilin tietoja, kuten yhteystietoja, tapahtumia tai sähköpostiviestejä, emmekä julkaise puolestasi tai osallistu mihinkään toimintaan tililläsi. Sitä käytetään vain kirjautumiseen. 

Mitkä ovat käyttäjän oikeudet tietojen poistamiseen ja miten hän voi pyytää tietojen poistamista? 

Käytämme tilinomistajalta (asiakkaaltamme) kerättyjä tietoja tarjotaksemme tilinomistajalle paremman käyttökokemuksen. Tämä sisältää kaikki paikat, joihin AO on jäänyt jumiin, joissa hän on käynyt useita kertoja, joista hänellä saattaa olla kysyttävää tai joissa hänellä voi olla vika. Käytämme näitä tietoja kommunikoidaksemme asiakkaidemme (tilinomistajien) kanssa oikeaan aikaan oikealla viestillä. 

Loppukäyttäjä, asiakkaamme asiakas… käytämme näitä tietoja vain tilinomistajan kanssa tehtävän tapahtuman (varauksen) yhteydessä. Emme markkinoi näille asiakkaille emmekä käytä heidän tietojaan millään muulla tavalla. Heidän tietojaan ei myydä tai lainata… ne pysyvät järjestelmässämme. 

Sekä AO:n että loppuasiakkaan tiedot voidaan poistaa milloin tahansa. AO voi lähettää sähköpostia osoitteeseen data@bookafy.com ja pyytää tilin ja tietojen poistamista. Loppuasiakas voi pyytää, että valtuutettu viranomainen poistaa hänen tietonsa. 

Onko jaetut käyttäjätilit kielletty työntekijöille? Entä asiakkaat?

Työntekijöillä on oma tilinsä. Asiakkailla on myös omat erilliset tilinsä, joilla on pääsy vain tietoihinsa.

Vaatiiko salasanasi useita lujuusvaatimuksia eli vahvoja salasanoja ja käyttää satunnaista alfa-, numero- ja erikoismerkkien sarjaa?

Tarvitsemme vähintään 6 merkkiä salasanoja perus salasanan hallinta tasolla. OWASP- ja NIST SP 800-63-3 -salasanakäytäntövaihtoehdot saattavat olla käytettävissä tulevana vuonna.

Onko verkon raja suojattu palomuurilla, jossa on sisään- ja ulospääsysuodatus?

Kyllä. Azure ja Amazon AWS ovat tarjoaa kaikki palomuurit ja kuormituksen tasaustilat.

Ovatko julkiset palvelimet hyvin määritellyllä De-Militarized Zone (DMZ)?

Kyllä, tämä periytyy Azuren oletusinfrastruktuurin kaavoituksesta, ja Bookafyllä on alueellisia palvelimia eri puolilla maailmaa. 

Käytetäänkö sisäisen verkon segmentointia herkkien tuotantoresurssien, kuten PCI-tietojen, eristämiseen?

PCI-tietoja ei tallenneta, koska niitä kehystää vain Bookafy kolmannen osapuolen palveluntarjoajilta, kuten Stripe ja Authorize.net. Bookafy ei kerää tai tallenna tietoja. 

Toteutetaanko ja seurataanko verkon tunkeutumisen havaitsemista tai ehkäisyä?

Laaja valikoima seurantatyökaluja, joita täydennetään Azuren toimittamilla ilmoituksilla ja hälytyksillä, ovat jatkuvasti käytössä. Tämä sisältää tunkeutumisen havaitseminen ja sähköpostivahvistukset verkkoon.

Ovatko kaikki pöytäkoneet suojattu säännöllisesti päivitettävin viruksilla, mato-, vakoilu- ja haittaohjelmaohjelmilla?

Kyllä.

Onko palvelimet suojattu alan karkaivuuskäytännöillä? Dokumentoituja käytäntöjä?

Turvallisuuspalveluja käytetään säännöllisesti järjestelmien turvallisuustarkastusten tekemiseen. 

Onko käytössä toimittaja korjaustiedostojen hallinta kaikille käyttöjärjestelmille, verkkolaitteille ja sovelluksille?

Kyllä. Azure tarjoaa tämän automaattisesti palvelun kautta.

Kirjataanko ja säilytetäänkö kaikki tuotantojärjestelmän virheet ja suojaustapahtumat?

Lokit säilytetään vähintään 1 kuukausi, ja jotkut jäljellä jopa 6 kuukautta, riippuen vakavuus ja toiminta tarvitaan.

Tarkistetaanko suojaustapahtumia ja lokitietoja säännöllisesti?

Kyllä. Lokit tarkistetaan päivittäin, viikoittain ja kuukausittain – riippuen lokitapahtumien luonteesta.

Onko käytössä dokumentoitutietosuojaohjelma, jossa on suojatoimia asiakkaan luottamuksellisten tietojen suojaamiseksi?

Kyllä.

Onko käytössä prosessi, joka ilmoittaa asiakkaille, jos tietosuojaloukkauksesta ilmenee?

Kyllä.

Tallennatko, käsittelet, lähetät (eli ”kahva”) Henkilötiedot (PII)?

Kyllä.

Missä maassa tai missä maissa henkilötietoja säilytetään?

Suurin osa pii-tiedoistamme tallennetaan Yhdysvaltoihin. Voimme kuitenkin tallentaa yritysasiakkaidemme tilitiedot tiettyyn aluekeskukseen. Esimerkki. Australialainen organisaatio voisi halutessaan tallentaa tietonsa Canberra Azure -sijaintiimme. Tai Euroopan maat voivat tallentaa tiedot eurooppalaiseen datakeskukseen. 

Onko järjestelmälokit suojattu muutoksilta ja tuhoutumiselta?

Tämän tarjoaa Azure ja se varmuuskopioidaan Dropbox Cloud Storageen.

Ovatko raja- ja VLAN-saapumispaikat suojattu tunkeutumissuoja- ja havaitsemislaitteilla, jotka antavat hälytyksiä hyökkäyksen aikana?

Kyllä. Nämä palvelut sisältyvät Azure-palomuuriin, joka suojaa tunkeutumiselta ja lähettää automaattisia hälytyksiä kehitystiimillemme. 

Korreloiko lokit ja tapahtumat työkalulla, joka varoittaa käynnissä olevasta hyökkäyksestä?

Kyllä, tietoturvapalvelumme sisältää reaaliaikaisen lokitiedonkeruun ja hälytykset hyökkäyksistä. 

Miten tiedot erotetaan muista ratkaisun asiakkaista, kuten verkottumisesta, etupäästä, taustatallennustilasta ja varmuuskopioista?

Jokainen asiakastili erotetaan loogisesti muista asiakkaista käyttämällä vaadittua pysyvää vuokraajan tunnusta kaikissa tietokantatietueissa.

Lisäksi kaikki sovelluskoodi edellyttää tätä vuokraajan tunnusta kaikille toiminnoille – sekä luku- että kirjoitustoiminnoille. Käytössä on myös automaattinen testausjärjestelmä, jolla suojataan koodimuutoksia regressioilta ja mahdolliselta vuokralaisten väliseltä tiedontakondaatiolta.

Vuokraajan tunniste on ”kiinteä linkitetty” jokaiseen käyttäjätiliin, ja se pannaan loogisesti täytäntöön tietokantakyselyiden ja vastaavien tiedostojen käytön mittareiden WHERE-lauseiden avulla. Käyttöympäristön käyttäjä ei voi muuttaa istuntoaan tai tiliään tästä vuokraajan tunnuksesta tai poistaa sen linkittävän sen. Näin ollen ei ole loogista mahdollisuutta, että käyttäjä llä olisi kirjautumisvaltuutus eri vuokraajan tunnisteessa. Vaikka he yrittäisivät käyttää sivuja käyttämällä eri vuokraajan tunnusta, järjestelmä hylkäisi pyynnön, koska käyttäjätiliä ei ole rekisteröity pyydettyyn vuokraajan tunnukseen.

Onko sinulla tapahtumavalmiussuunnitelma?

Kyllä, säilytetään ”elävä asiakirja”, jossa hahmotellaan katastrofi- ja vaaratilanteiden

tarkistuslistoja, yhteystietoja ja keskeisiä järjestelmätiloja häiriöiden ymmärtämiseksi ja niihin vastaamiseksi.

Minkä tasoinen verkon suojaus on toteutettu?

Käytämme Azuresin Web Application gatewayta (kuorman tasapainottaja) ja seuraavan sukupolven palomuuria suojaamaan Azure Cloudissa toimivien virtuaalikoneiden verkkoamme. 

Tarjoaako alusta raportteja QOS(Quality of Service) -suorituskykymittauksista (resurssien käyttö, suoritusteho, saatavuus jne.)?

Tällaisia tietoja ei toimiteta asiakkaille, lukuun ottamatta saatavuus- ja vastausaikatauluja tilasivumme mukaisesti status.pingdom.com

Onko katastrofien palautusohjelma testattu vähintään vuosittain?

Kyllä, elpyminen tarkastuksia ja suoritetaan ja testataan vuosittain.

Mikä on järjestelmän palautumisajan tavoite (RTO) ja toipumispisteen tavoite?

RTO on 4 tuntia, ja RPO on 1 tunti.

Tarjoatko varmuuskopiointi- ja palautussuunnitelmia yksittäisille asiakkaille?

Kaikki näkökohdat ovat usean vuokralaisen, joten varmuuskopiot otetaan koko asiakaskunnan. Täydelliset tiedostojen varmuuskopiot suoritetaan 24 tunnin välein, ja ne hyötyvät Azure-tietokantapisteestä 5 minuutin välein otettujen aikavarmuuskopioiden aikana. Varmuuskopiot tallennetaan Dropbox Cloud -pilvipalveluun sekä tarpeettomiin Azure-virtuaalikoneisiin. 

Mikä on varmuuskopioiden enimmäisaika?

Tietokanta point-in-time varmuuskopiot säilytetään 30 päivää, yleinen tiedostojen varmuuskopiot 90 päivää vähintään.

Mikä on tietojen palauttamisen odotettu läpimenoaika?

Kaikki asiakkaan palautukset kaikissa muissa kuin katastrofitilanteissa on pyydettävä ja ajoitettava kanssamme. Toimitusaika on 1-2 arkipäivää. 

Voiko yksittäisen entiteettitilin palauttaa vaikuttamatta koko alustaan?

Jos asiakas vaatii tietyn tietueen tai artefaktin palauttamista, se voidaan suorittaa verkossa pyyntökohtaisesti ja se on maksullista työtä. Alustalla tai asiakastilillä ei ole vaikutusta.

Onko korkea saatavuus tarjotaan – i. E. jossa yksi palvelinesiintymä ei ole käytettävissä, tuleeko toinen saataville?

Useita palvelinesiintymiä suoritetaan kaikilla järjestelmätasoilla Azuren virtuaalikoneen kautta, ja Web-sovellusyhdyskäytävä käsittelee kuormituksen tasausta. Palvelinesiintymän virhe palvelinkeskuksessa käsittelee Azure WAG, ja ongelmaesiintymä kierrätetään ja/tai poistetaan ja korvataan uudella ilmentymällä.

Tallennetaanko tiedot ja ne ovat käytettävissä toisessa paikassa (palvelinkeskuksessa) palautusvaatimusten täyttämiseksi?

Kyllä. Kaikki tiedot replikoidaan toiseen palvelinkeskukseen, joka vaihtelee maantieteellisen sijainnin mukaan sekä varmuuskopioituun tietoon Dropbox Cloud Storageen. .

Onko vikasietoprosessi aktiivinen/aktiivinen, automaattinen siirtymisprosessi?

Ensisijaisen palvelinkeskuksen palvelinesiintymän vikaa käsitellään Azure WAG-kuormituksen tasaajissa, ja ongelmaesiintymä kierrättää ja/tai poistaa ja korvata uudella esiintymällä.

Siinä tapauksessa, että koko palvelinkeskuksessa oli kriittinen vika, siirrytään toiseen keskukseen on manuaalinen prosessi, koska meidän on tehtävä täydellinen arvio ongelmasta ensin varmistaaksemme, ettei ole olemassa olevaa ensisijaista keskusta koskevia yksinkertaisia kiertoteitä. läsnäoloa. Jos on määritetty, että siirtyminen toissijaiseen keskukseen on tarpeen, siirtyminen aloitetaan manuaalisesti tavoitteen palautustavoitteiden saavuttamiseksi.