Поширені запитання про безпеку 

Чи траплялися значні порушення або інциденти безпеки за останні 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, а проблемний екземпляр переробляється та/або видаляється і замінюється новим екземпляром.

Якщо весь центр обробки даних зазнає критичного збою, то перемикання на вторинний центр є ручним процесом, оскільки нам потрібно спочатку провести повну оцінку проблеми, щоб переконатися, що немає простих обхідних шляхів для збереження доступності існуючого первинного центру. Якщо буде визначено, що потрібен перехід до вторинного центру, то перемикання буде ініційовано вручну, щоб досягти цільових цілей відновлення.