Коротка відповідь
Хостинг відповідає за фізичну й мережеву безпеку інфраструктури, де зберігаються дані: захищений дата-центр, шифрований доступ, бекапи, захист від злому сервера. Власник сайту відповідає за те, як саме дані збираються, обробляються і хто до них має доступ на рівні самого сайту й CMS. Це дві частини однієї відповідальності, і обидві важливі.
Що робить хостинг
- Фізична безпека сервера — контрольований доступ до обладнання в дата-центрі, поза межами зони підвищеного ризику.
- Мережевий захист — фаєрвол, захист від DDoS, ізоляція між клієнтськими акаунтами на сервері.
- Шифрований доступ — SSL/TLS для передачі даних між браузером відвідувача і сервером, щоб дані форми не йшли відкритим текстом.
- Бекапи — щоденні копії, які дозволяють відновити дані у разі технічного збою чи атаки, не втративши базу клієнтів повністю.
- Юрисдикція розміщення — сервер у ЄС підпадає під визнаний режим захисту персональних даних (GDPR), що само по собі підвищує рівень базових гарантій порівняно з юрисдикціями без такого регулювання.
Що залишається відповідальністю власника сайту
- Яка саме форма й навіщо збирає дані — чи є явна згода, чи зрозуміло клієнту, навіщо потрібен його номер телефону.
- Хто має доступ до адмінки й бази клієнтів — кількість акаунтів адміністратора, унікальність і складність паролів.
- Чи передаються дані третім сторонам — інтеграції з CRM, службами розсилок, рекламними системами.
- Політика конфіденційності на сайті — юридичний документ, що описує, як саме обробляються дані, обов'язковий елемент для будь-якого сайту, що збирає персональні дані.
- Актуальність CMS і плагінів — застаріла версія з відомою вразливістю робить весь рівень мережевого захисту хостингу менш ефективним, якщо дірка — у самому коді сайту.
Аналогія: хостинг — це як безпечний будинок з надійними замками і сигналізацією. А от хто саме має ключі від квартири всередині й кому їх передавали — відповідальність власника квартири, а не будівельної компанії.
Практичні кроки для власника сайту
- Перевірити, скільки людей мають адмін-доступ до бази клієнтів, і прибрати зайві акаунти.
- Переконатись, що форми на сайті мають явну згоду на обробку даних (чекбокс, посилання на політику конфіденційності).
- Тримати CMS і плагіни оновленими — детальніше в чек-листі безпеки сайту за 15 хвилин.
- Обмежити кількість зовнішніх інтеграцій, які отримують доступ до бази клієнтів, до реально необхідних.
А що при переносі бази клієнтів на новий хостинг?
Перенесення бази даних із персональними даними клієнтів — окремо чутлива операція: важливо, щоб копія передавалась захищеним каналом, а не відкритим email чи публічним посиланням. Загальний підхід до безпечного перенесення розібраний у статті перенос інтернет-магазину на новий хостинг без втрати замовлень.
Чому бекапи — теж про захист персональних даних
Захист даних — це не тільки про запобігання витоку, а й про запобігання втраті. Якщо база клієнтів існує в єдиному екземплярі й губиться через збій диска, це так само проблема захисту даних, як і злом. Щоденні бекапи поза сервером — базовий елемент цього захисту з боку хостингу, детально розібраний у статті як улаштовані щоденні бекапи поза сервером.
Що робити у випадку підозри на витік даних
Якщо є підозра, що база клієнтів могла потрапити в чужі руки (наприклад, після виявлення зламу сайту), правильна послідовність дій: зафіксувати факт і масштаб можливого витоку (які саме дані, скільки записів), змінити всі паролі доступу до адмінки й бази, повідомити відповідальних осіб у компанії. Покроковий розбір дій саме у випадку зламу сайту — у статті сайт зламали: порядок дій, поки не пізно. У серйозних випадках, залежно від обсягу й типу даних, може знадобитися юридична консультація щодо необхідності повідомлення постраждалих осіб.
Мінімізація даних: збирайте тільки те, що дійсно потрібно
Один із найпростіших, але недооцінених принципів захисту даних — не збирати зайвого. Якщо для оформлення замовлення потрібні ім'я, телефон і адреса доставки, немає сенсу додатково запитувати дату народження чи інші дані "про всяк випадок" — кожне додаткове поле в формі це додаткова відповідальність і додатковий ризик у разі витоку. Регулярний перегляд того, які саме дані реально збираються на сайті і чи всі вони дійсно використовуються, — гарна практика незалежно від розміру бізнесу.
Договір з хостингом як частина ланцюга відповідальності
При формальному підході до захисту персональних даних варто розглядати відносини з хостинг-провайдером як частину загального ланцюга обробки даних: провайдер технічно обробляє (зберігає) дані, які збирає власник сайту. Це схоже на модель "оператор і обробник даних" у термінології GDPR, навіть якщо формального договору про обробку даних (DPA) не укладено окремо. Для більшості звичайних сайтів малого й середнього бізнесу деталізований юридичний договір такого типу не є типовою вимогою, але розуміння цієї структури відповідальності допомагає усвідомлено підходити до вибору хостингу саме як до партнера, що бере на себе частину відповідальності за збережність даних.
Право клієнта на видалення своїх даних
Сучасна практика захисту персональних даних передбачає, що клієнт має право попросити видалити свої дані з бази компанії (право "бути забутим"). Технічно для власника сайту це означає потребу мати процес, який дозволяє знайти й видалити (чи анонімізувати) конкретного клієнта в базі даних — включно з пов'язаними записами в CRM, розсилках та інших системах, куди ці дані могли потрапити через інтеграції. Якщо такого процесу немає, варто продумати його заздалегідь, а не в момент, коли клієнт офіційно звернувся з таким запитом.
Сторонні скрипти й трекери — теж канал витоку даних
Форми на сайті — не єдине джерело потенційного витоку. Сторонні скрипти аналітики, чат-віджети, рекламні пікселі теж мають технічний доступ до частини даних на сторінці. Варто періодично переглядати, які саме сторонні скрипти підключені до сайту, і прибирати ті, що більше не використовуються, — забутий тестовий скрипт від сервісу, яким давно не користуються, це зайва точка ризику без жодної користі.
Резервне копіювання клієнтської бази окремо від решти сайту
Для бізнесу, де база клієнтів є особливо цінним активом (наприклад, накопичена роками історія замовлень постійних клієнтів), має сенс не покладатися виключно на загальний щоденний бекап усього сайту, а розглянути додатковий, окремий експорт саме клієнтської бази з певною періодичністю, який зберігається окремо і контролюється безпосередньо власником бізнесу. Це не заміна інфраструктурних бекапів хостингу, а додатковий рівень контролю над найціннішим активом бізнesu.