Використовуйте Bookafy з упевненістю і приєднуйтесь до більш ніж 15 000 компаній, які довіряють Bookafy по всьому світу.
При підключенні до сторонніх додатків (icloud, google cal, outlook, exchange) Bookafy імпортує лише тему календаря, дату, час і тривалість, щоб заблокувати час в Bookafy для запобігання подвійних бронювань. Ми не імпортуємо, не зберігаємо і не використовуємо особисту інформацію або інформацію, що дозволяє ідентифікувати особу.
Bookafy не має доступу до будь-якої інформації у вашому підключеному календарі або обліковому записі електронної пошти, включаючи контакти, адресу електронної пошти або електронні листи. Адреси електронної пошти можуть бути використані для перевірки автентичності вашого облікового запису в Bookafy, але ми не збираємо жодної інформації, пов’язаної з вашими особистими даними.
Всі інтеграції з третіми сторонами здійснюються за допомогою автентифікації Oath. Це дозволяє Bookafy з’єднуватися зі сторонніми провайдерами, не бачачи, не збираючи і не зберігаючи ваші імена користувачів або паролі. Bookafy підключається за допомогою коду автентифікації, який надається при підключенні через Oath.
Лазурний
Bookafy розміщується на Azure. Ви можете прочитати про ретельні заходи безпеки Azure та AWS на їхніх сайтах.
Bookafy використовує всі вбудовані функції безпеки, конфіденційності та резервування платформи. Azure постійно відстежує ризики у своїх центрах обробки даних і проходить оцінку, щоб забезпечити відповідність галузевим стандартам. Операції центру обробки даних Azure акредитовано за такими стандартами: ISO 27001, SOC 1 і SOC 2/SSAE 16/ISAE 3402 (раніше SAS 70 Type II), PCI Level 1, FISMA Moderate та Sarbanes-Oxley (SOX).
AWS
Bookafy використовує AWS CDN для зображень. Bookafy використовує всі вбудовані функції безпеки, конфіденційності та резервування платформи. AWS постійно контролює свої центри обробки даних на предмет ризиків і проходить оцінку, щоб забезпечити відповідність галузевим стандартам. Операції центру обробки даних AW були акредитовані за стандартами ISO 27001, SOC 1 і SOC 2/SSAE 16/ISAE 3402 (раніше SAS 70 Type II), PCI Level 1, FISMA Moderate та Sarbanes-Oxley (SOX).
Резервні копії
Bookafy щодня виконує резервне копіювання всіх даних і кодової бази на надлишкових серверах у 2 різних географічних точках. Крім того, резервні копії коду та даних зберігаються у хмарному сховищі Dropbox.
Шифрування
Дані, які проходять через Bookafy, шифруються, як під час передачі, так і в стані спокою. Всі з’єднання від браузера до платформи Bookafy шифруються під час передачі за допомогою TLS SHA-256 з RSA-шифруванням. Bookafy вимагає HTTPS для всіх послуг.
Для конфіденційних даних, де оригінальні значення не потрібні, наприклад, наші власні паролі, ми хешуємо дані за допомогою алгоритму BCrypt. Якщо потрібні оригінальні значення, наприклад, дані автентифікації для доступу до календарів, вони шифруються за допомогою алгоритму AES-256-GCM з використанням унікальної, випадково згенерованої солі для кожного набору конфіденційних даних.
Безпечна передача на сервери
Bookafy використовує службу безпеки даних для автентифікації передачі даних між нашою командою розробників і віртуальними машинами. Всі дані зашифровані та захищені.
Обмін даними та доступ третіх сторін
Bookafy нікому не продає дані клієнтів. Ми не ділимося даними для міжканального маркетингу. Bookafy не надає доступ жодному сторонньому постачальнику, окрім як через підключення облікового запису за допомогою автентифікації Oath або ключа API. Обидві функції можна відключити в будь-який час з Bookafy або з стороннього додатку. В іншому випадку не існує третіх осіб, яким надаються дані, продаються дані або яким надаються дані з будь-якої причини.
Попередні перевірки
Всі співробітники Bookafy проходять ретельну перевірку перед прийняттям на роботу.
Навчання
Хоча ми зберігаємо мінімальну кількість даних про клієнтів і обмежуємо внутрішній доступ до них за принципом службової необхідності, всі співробітники проходять навчання з питань безпеки та обробки даних, щоб гарантувати, що вони дотримуються наших суворих зобов’язань щодо конфіденційності та безпеки ваших даних.
Конфіденційність
Усі працівники перед прийняттям на роботу підписали угоду про нерозголошення та угоду про конфіденційність.
Доступ до даних
Доступ до нашої виробничої інфраструктури надається лише уповноваженим працівникам, а використання менеджерів паролів для забезпечення надійних паролів та двофакторної авторизації, коли це можливо, є обов’язковим для всієї компанії.
Катастрофа
Ми маємо плани безперервності бізнесу та аварійного відновлення, які реплікують нашу базу даних і створюють резервні копії даних на декількох хмарних серверах у різних географічних регіонах і центрах обробки даних, щоб забезпечити високу доступність у разі аварії.
Надійність
Bookafy має історію безвідмовної роботи в 99.3% випадків
Нові функції
Bookafy розробляє нові функції за 3-тижневі спринти. Наші розгортання починаються на сервері розробки, потім на стадії постановки, а потім в реальному часі. Розгортання сервера в реальному часі відбувається в неділю вранці за тихоокеанським часом.
Контроль якості та тестування
Перед кожним розгортанням Bookafy проводить автоматизоване тестування, а також ручне тестування.
QA для серверів розробки та стадіальних серверів
Перед випуском Bookafy на живі сервери, код розгортається на серверах для тестування та розробки під час процесу QA. Після завершення тестування код додається до репозиторію для розгортання на реальних серверах на часовій шкалі спринт-циклу.
Моніторинг в реальному часі
Після того, як код потрапляє на наш виробничий сервер, наша команда QA запускає автоматизовані тести, ручні тести та використовує зовнішнє програмне забезпечення для моніторингу наших послуг. Зовнішнє програмне забезпечення працює 24/7 з оповіщеннями, які автоматично надсилаються нашій команді розробників у разі виникнення будь-яких проблем. Ці сповіщення відстежуються 24/7 і надсилаються текстовими повідомленнями та електронною поштою нашій команді.
Брандмауер
Bookafy розміщений на серверах Azure і використовує службу брандмауера Azure Next Generation Firewall Service, яка знаходиться за службою шлюзу веб-додатків Azure. Ця послуга включає захист від таких речей, як SQL-ін’єкції або неправильно сформовані HTTP-запити.
Запобігання шкідливому програмному забезпеченню та вірусам
Всі наші співробітники працюють за комп’ютерами, що належать компанії, на яких встановлено програмне забезпечення для захисту від шкідливого програмного забезпечення та вірусів. Наш офісний сервер захищений брандмауером для захисту від зовнішнього проникнення.
Сканування
На нашому внутрішньому сервері, комп’ютерах співробітників та хостингу даних постійно працює програмне забезпечення для сканування вразливостей.
Захист облікових даних для входу
Для наших зовнішніх додатків, які працюють з Bookafy, Bookafy не зберігає/збирає паролі. Вся автентифікація Bookafy використовує безпечне з’єднання Oath для надання доступу до Bookafy за допомогою захищеного токена, який використовується для кожного окремого облікового запису користувача. Приклади включають: Zoom, Stripe, Authorize.net, календар Google, Exchange, Office365, Outlook.com, Icloud, mailchimp тощо. Вся 3-я частина
Від’єднання
Коли обліковий запис скасовується або знижується до безкоштовного, всі з’єднання Oath автоматично відключаються від Bookafy до ваших сторонніх додатків.
Доступ до API
Весь доступ до даних через Bookafy здійснюється за допомогою механізму авторизації OAuth, який надає токени доступу, що можуть бути відкликані в будь-який час.
GDPR
Ми впровадили стандарти GDPR у практику роботи з даними, щоб гарантувати, що всі наші клієнти отримують підтримку та відповідають вимогам GDPR. Дізнайтеся більше про
Bookafy GDPR
.
Поширені запитання про безпеку
Чи траплялися значні порушення або інциденти безпеки за останні 5 років?
Ні.
Чи привілейований та загальний доступ до облікових записів суворо контролюється та переглядається щонайменше на періодичній основі
щороку?
Так.
Які дані збираються про користувача?
Програмне забезпечення збирає дані про власника облікового запису та кінцевого клієнта. Обидва налаштування базуються на даних, наданих власником акаунта та кінцевим клієнтом. Ми не збираємо жодних даних, окрім добровільно наданих кінцевим користувачем або власником облікового запису.
Власник акаунта може створювати текстові поля для збору різних даних під час бронювання, але клієнт повністю усвідомлює, які дані збираються, оскільки кінцевий користувач буде вводити дані в поля. Кінцевий користувач або власник облікового запису може запросити видалення даних у будь-який час, надіславши запит на електронну пошту data@bookafy.com.
Для яких цілей додаток використовує дані?
Дані додатку використовуються лише для транзакції, на яку підписався кінцевий клієнт. Якщо ви використовуєте сторонній додаток для входу в SSO, наприклад, Facebook або Google, ми використовуємо це з’єднання тільки для доступу до облікового запису. Ми не використовуємо дані з акаунта, такі як контакти, події, повідомлення електронної пошти, а також не публікуємо публікації від вашого імені і не беремо участі в будь-якій діяльності з вашого акаунта. Використовується тільки для входу в систему.
Які права мають користувачі на видалення даних і як користувач може подати запит на видалення даних?
Ми використовуємо дані, отримані від власника акаунта (нашого клієнта), щоб забезпечити кращий досвід для власника акаунта. Сюди входить будь-яке місце, де AO застряг, відвідував багато разів, де у нього можуть виникнути питання або помилка. Ми використовуємо ці дані, щоб зв’язатися з нашими клієнтами (власниками облікових записів) в потрібний час з потрібним повідомленням.
Для кінцевого користувача, клієнта нашого клієнта… ми використовуємо ці дані лише для здійснення транзакції (бронювання) з власником акаунта. Ми не проводимо маркетингових кампаній для цих клієнтів і не використовуємо їхні дані в будь-який інший спосіб. Їхні дані не продаються і не позичаються… вони залишаються в нашій системі.
Як у випадку з АТ, так і з кінцевим споживачем, їхні дані можуть бути видалені в будь-який час. АТ може написати на електронну пошту data@bookafy.com і попросити видалити свій обліковий запис і дані. Кінцевий споживач може вимагати від АО видалення своїх даних.
Чи заборонені спільні облікові записи для співробітників? А як щодо клієнтів?
Співробітники мають власні спеціальні рахунки. Клієнти також мають власні виділені акаунти, з доступом лише до своїх даних.
Чи вимагає ваша конструкція пароля багаторазових вимог до надійності, тобто надійні паролі використовують випадкову послідовність букв, цифр і спеціальних символів?
Ми вимагаємо мінімум 6 символів у паролях на базовому рівні управління паролями. У наступному році можуть з’явитися варіанти політики паролів OWASP і NIST SP 800-63-3.
Чи захищена межа мережі брандмауером з фільтрацією вхідного та вихідного трафіку?
Так. Всі брандмауери та засоби балансування навантаження надаються Azure та Amazon AWS.
Чи знаходяться публічні сервери в чітко визначеній демілітаризованій зоні (ДМЗ)?
Так, це успадковано від стандартного зонування інфраструктури Azure, і Bookafy має регіональні сервери, розкидані по всьому світу.
Чи використовується сегментація внутрішньої мережі для подальшої ізоляції чутливих виробничих ресурсів, таких як дані PCI?
Дані PCI не зберігаються, оскільки Bookafy лише отримує їх від сторонніх постачальників, таких як Stripe та Authorize.net. Bookafy не збирає і не зберігає дані.
Чи впроваджено та контролюється виявлення та запобігання вторгненням в мережу?
Широкий спектр інструментів моніторингу, доповнений сповіщеннями та попередженнями, що надаються Azure, залишається постійно увімкненим. Це включає в себе виявлення вторгнень і підтвердження доступу до мережі електронною поштою.
Чи всі комп’ютери захищені регулярно оновлюваним програмним забезпеченням від вірусів, черв’яків, шпигунських програм та шкідливого коду?
Так.
Чи захищені сервери за допомогою галузевих методів зміцнення? Чи задокументовані ці практики?
Служби безпеки регулярно проводять аудит безпеки системи.
Чи існує активне керування виправленнями для всіх операційних систем, мережевих пристроїв та програм?
Так. Azure надає це автоматично через свій сервіс.
Чи реєструються та зберігаються всі помилки виробничої системи та події безпеки?
Журнали зберігаються щонайменше 1 місяць, а деякі – до 6 місяців, залежно від ступеня тяжкості та необхідних дій.
Чи регулярно переглядаються події безпеки та дані журналів?
Так. Журнали переглядаються щодня, щотижня і щомісяця – залежно від характеру подій у журналі.
Чи існує задокументована програма конфіденційності з гарантіями захисту конфіденційної інформації клієнта?
Так.
Чи існує процес повідомлення клієнтів про порушення конфіденційності?
Так.
Чи зберігаєте ви, обробляєте, передаєте (тобто “обробляєте”) персональну інформацію (PII)?
Так.
В якій країні або країнах зберігається PII?
Більшість наших PII даних зберігається в США. Однак ми можемо зберігати дані рахунків наших корпоративних клієнтів у певному регіональному центрі. Приклад. Австралійські організації можуть вибрати зберігання своїх даних у нашому хмарному сховищі Canberra Azure. Або європейські країни можуть зберігати в європейському дата-центрі.
Чи захищені системні журнали від зміни та знищення?
Він надається Azure і зберігається в хмарному сховищі Dropbox.
Чи захищені точки входу в прикордонні та локальні мережі пристроями захисту та виявлення вторгнень, які сповіщають про атаку?
Так. Ці служби включені в наш брандмауер Azure, який захищає від вторгнень і надсилає автоматичні сповіщення нашій команді розробників.
Чи співвіднесені журнали та події з інструментом, який попереджає про атаку, що триває?
Так, наша служба безпеки включає в себе реєстрацію та оповіщення про атаки в режимі реального часу.
Як дані відокремлюються від інших клієнтів в рамках рішення, включаючи мережу, інтерфейс, внутрішнє сховище та резервне копіювання?
Кожен обліковий запис клієнта логічно відокремлений від інших клієнтів завдяки використанню обов’язкового постійного ідентифікатора орендаря в усіх записах бази даних.
Крім того, весь код програми вимагає цей ідентифікатор орендаря для всіх операцій – як читання, так і запису. Також впроваджено режим автоматизованого тестування для захисту змін у коді від регресій та можливого забруднення даних між користувачами.
Ідентифікатор орендаря “жорстко прив’язаний” до кожного облікового запису користувача і логічно забезпечується за допомогою фіксованих речень “ДЕ” у запитах до бази даних та еквівалентних заходів для доступу до файлів. Користувач платформи не може змінити або іншим чином відв’язати свій сеанс або обліковий запис від цього ідентифікатора орендаря. Таким чином, немає жодної логічної можливості для користувача мати авторизацію під іншим ідентифікатором орендаря. Навіть якщо вони намагалися отримати доступ до сторінок, використовуючи інший ідентифікатор орендаря, система відхиляла запит через те, що обліковий запис користувача не був зареєстрований на запитуваний ідентифікатор орендаря.
Чи є у вас план реагування на інциденти?
Так, ведеться “живий документ”, який описує реагування на катастрофи та інциденти
контрольні списки, контактні дані та ключові системні засоби для розуміння та реагування на інциденти.
Який рівень захисту мережі реалізовано?
Ми використовуємо шлюз веб-додатків Azure (балансувальник навантаження) і брандмауер наступного покоління для захисту нашої мережі віртуальних машин, що працюють у хмарі Azure.
Чи надає платформа звіти для вимірювання показників якості обслуговування (QOS) (використання ресурсів, пропускна здатність, доступність тощо)?
Такі показники не надаються клієнтам, окрім доступності та часу відгуку, як показано на нашій сторінці статусу на status.pingdom.com
Чи тестується програма аварійного відновлення щонайменше раз на рік?
Так, перевірки на відновлення виконуються і тестуються щорічно.
Що таке мета часу відновлення (RTO) та мета точки відновлення (RPO) системи?
RTO становить 4 години, а RPO – 1 годину.
Чи надаєте ви плани резервного копіювання та відновлення для індивідуальних клієнтів?
Всі аспекти є багатокористувацькими, тому резервні копії створюються для всієї клієнтської бази. Повні резервні копії файлів виконуються кожні 24 години, а резервні копії бази даних Azure створюються кожні 5 хвилин у режимі реального часу. Резервні копії зберігаються у хмарному сховищі Dropbox, а також на резервних віртуальних машинах Azure.
Який максимальний термін зберігання резервних копій?
Точкові резервні копії бази даних зберігаються протягом 30 днів, а загальні резервні копії файлів – щонайменше 90 днів.
Який очікуваний час відновлення даних?
Будь-яке відновлення клієнта в будь-якому сценарії, що не пов’язаний з катастрофою, повинно бути узгоджене з нами та заплановане. Термін виконання – від 1 до 2 робочих днів.
Чи можна відновити обліковий запис однієї організації, не впливаючи на всю платформу?
Якщо клієнту потрібна реставрація конкретного запису чи артефакту, вона може бути виконана в режимі онлайн на основі індивідуального запиту і є платною роботою. Це не впливає на платформу або обліковий запис клієнта.
Чи забезпечується висока доступність – i. e. коли один екземпляр сервера стає недоступним, чи стає доступним інший?
Кілька екземплярів серверів працюють на всіх рівнях системи через віртуальну машину Azure, а шлюз веб-додатків забезпечує балансування навантаження. Відмова екземпляра сервера в центрі обробки даних обробляється Azure WAG, при цьому проблемний екземпляр переробляється та/або видаляється і замінюється новим екземпляром.
Чи зберігаються та чи доступні дані в іншому місці (центрі обробки даних), щоб відповідати вимогам аварійного відновлення?
Так. Всі дані реплікуються до другого дата-центру, який відрізняється географічним розташуванням, а також має резервну копію даних, що зберігається у хмарному сховищі Dropbox. .
Чи є процес обходу відмови активним/активним, автоматизованим процесом перемикання?
Збій екземпляра сервера в основному центрі обробки даних обробляється балансувальниками навантаження Azure WAG, а проблемний екземпляр переробляється та/або видаляється і замінюється новим екземпляром.
Якщо весь центр обробки даних зазнає критичного збою, то перемикання на вторинний центр є ручним процесом, оскільки нам потрібно спочатку провести повну оцінку проблеми, щоб переконатися, що немає простих обхідних шляхів для збереження доступності існуючого первинного центру. Якщо буде визначено, що потрібен перехід до вторинного центру, то перемикання буде ініційовано вручну, щоб досягти цільових цілей відновлення.
