Сайт зламали: перші кроки і правило 72 годин у Німеччині

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

Перший імпульс майже завжди однаковий: щось видалити і сподіватися, що пронесло. Саме з цього починати не можна — і це взагалі не той пункт, за яким зараз іде найтерміновіший відлік.

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

Перша година: зберігати, а не видаляти

Перш ніж щось лагодити, зафіксуйте стан.

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

Збережіть логи. Серверні, журнали доступу, усе, що дає хостер. Багато провайдерів зберігають їх лічені дні. Хто схаменеться на третій день, часто не отримує нічого.

Запишіть час, коли ви помітили інцидент. Звучить дрібно, але це точка відліку встановленого законом строку — про це трохи нижче.

Що можна і треба зробити одразу: перевести сайт в офлайн або поставити сторінку-заглушку. Це захищає відвідувачів і зупиняє поточну шкоду, не знищуючи слідів.

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

А чи точно щось сталося?

Не кожна дивина — злам. Перш ніж запускати всю процедуру, розберіться, що саме ви бачите.

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

Неоднозначні: сайт став повільним, не працює форма, розширення видає помилку. Це може бути атака, але частіше — конфлікт після оновлення або переповнена скринька.

Момент, який багато хто трактує хибно: невдалі спроби входу в логах — це не злам. Будь-яка публічно доступна форма авторизації збирає їх цілодобово, автоматично. Значення має лише успішна спроба.

Годинник на 72 години

Це та частина, яку майже всі недооцінюють, і причина, з якої «спочатку спокійно полагодимо» може обійтися дорого.

За ст. 33 DSGVO ви зобовʼязані повідомити про порушення захисту персональних даних компетентний наглядовий орган невідкладно і за можливості протягом 72 годин після того, як вам стало відомо про порушення.

Тут вирішують три деталі:

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

72 години йдуть безперервно. Вихідні та свята входять. Хто дізнався в пʼятницю о 16:00, зобовʼязаний повідомити до понеділка до 16:00.

Не треба закінчити аналіз. Ст. 33 абз. 4 прямо дозволяє поетапне повідомлення: спершу повідомляєте те, що відомо, решту досилаєте. Попереднє повідомлення допустиме — а прострочене доведеться обґрунтовувати.

Коли повідомляти не потрібно: якщо порушення імовірно не тягне ризику для прав і свобод фізичних осіб. Класичний випадок — дані, зашифровані за сучасним рівнем техніки, з нескомпрометованим ключем.

І що діє навіть без обовʼязку повідомляти: ст. 33 абз. 5 вимагає документувати кожен інцидент усередині компанії. Що сталося, які дані зачеплені, як ви оцінили ризик, що вжили. Навіть якщо висновок — повідомляти не треба, сама оцінка має бути відтворюваною.

Компетентний орган для підприємств, обʼєднань і осіб вільних професій — Landesdatenschutzbehörde вашої федеральної землі. У більшості є онлайн-форма.

Якщо ризик високий: ст. 34

Зʼявляється другий обовʼязок, якщо порушення імовірно означає високий ризик для зачеплених осіб. Тоді за ст. 34 DSGVO треба невідкладно повідомити й самих людей.

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

На практиці розрізняють три види порушень, і третій регулярно упускають:

• Конфіденційність — сторонні отримали доступ до даних.
• Цілісність — дані несанкціоновано змінено.
• Доступність — дані втрачено або знищено, наприклад шифрувальником чи видаленням резервних копій.

Третій випадок підлягає повідомленню, хоча назовні нічого не пішло. Безповоротна втрата може означати високий ризик для людей.

Чистка: у якому порядку

Лише тепер, маючи збережену копію і розвʼязане питання з повідомленням, беріться за прибирання.

Змініть усі доступи. Хостинг, база даних, облікові записи CMS, FTP, пошта. Зокрема ті, які здаються незачепленими. У кого був доступ до однієї ділянки, часто був доступ до більшого.

Перевірте, чи не зʼявилися чужі облікові записи. Частий прийом: зловмисник заводить собі додатковий акаунт адміністратора, щоб повернутися після зміни пароля. Пройдіть за списком користувачів.

Розгорніть резервну копію — але правильну. Вчорашня копія найчастіше вже містить злам. Потрібна копія до інциденту, а для цього спершу треба знати, коли він стався. Тому цей крок і не йде першим.

Оновіть усе. CMS, розширення, теми, серверне ПЗ. Найчастіший шлях усередину — відома вразливість у застарілому компоненті, для якої давно вийшло оновлення.

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

Як вийти з попередження Google

Якщо Google позначив сайт як шкідливий, після чистки попередження саме не зникне.

У Search Console для цього є розділ «Проблеми безпеки». Там видно, що знайшов Google, і звідти після чистки запитується перевірка. Зазвичай забирає кілька днів.

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

Якщо доступу до Search Console у вас немає, бо її налаштовував попередній виконавець, — це окрема проблема, і як її розвʼязувати, описано в іншій статті.

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

Профілактика помітно дешевша

Після інциденту — правильний момент, щоб змінити структуру, яка його допустила.

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

Зменшуйте площу атаки. Кожне непотрібне розширення — потенційно ще одна дірка. Видаляти, а не вимикати.

Резервні копії в окремому сховищі. Копія на тому самому сервері за шифрувальника марна. Окреме місце — і раз на рік перевіряти, що відновлення справді працює.

Двофакторна автентифікація на всіх адміністративних входах.

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

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

І правовий момент, який часто упускають: відповідальність за безпеку даних лежить на вас як на власнику сайту, а не на виконавцеві. Так само як і за Impressum із політикою конфіденційності — про це окрема стаття.

Часті запитання

Чи зобовʼязаний я завжди повідомляти про злам до наглядового органу? Ні, але виняток вужчий, ніж заведено думати. Повідомляти треба, щойно імовірно виникає ризик для прав і свобод фізичних осіб. Обовʼязку немає, якщо такого ризику імовірно не виникає — наприклад, за даних, зашифрованих за сучасним рівнем техніки, з нескомпрометованим ключем. Документувати інцидент треба в будь-якому разі.

З якого моменту йдуть 72 години? З моменту, коли вам стало відомо про порушення, а не з самого інциденту. Строк іде безперервно, включно з вихідними та святами.

А якщо через 72 години я ще не все зʼясував? Тоді подавайте попереднє повідомлення. Ст. 33 абз. 4 DSGVO прямо дозволяє досилати відомості поетапно. Неповне повідомлення у строк суттєво краще за повне після — за прострочення доведеться обґрунтовувати затримку.

Чи достатньо просто розгорнути резервну копію? Ні, і це може зашкодити. Резервна копія затирає сліди, за якими можна зрозуміти, чи витекли дані. До того ж свіжа копія найчастіше вже містить злам. Спершу збережіть поточний стан, зʼясуйте момент проникнення, і лише потім розгортайте копію, зроблену до нього.

Який орган мій? Для підприємств, обʼєднань і осіб вільних професій — Landesdatenschutzbehörde вашої федеральної землі. У більшості є онлайн-форма для подання.

Чи потрібно повідомляти клієнтів? Лише якщо для них імовірно виникає високий ризик — тоді невідкладно, за ст. 34 DSGVO. За ризику нижче цього порогу достатньо повідомлення до органу.

Я видалив файл зі шкідливим кодом. На цьому все? Найімовірніше ні. Якщо шлях усередину залишився відкритим, той самий код повернеться. А якщо було заведено додатковий акаунт адміністратора, однієї зміни пароля недостатньо. Інцидент закритий тоді, коли причину знайдено й усунуто.

Коротко

Зберігати до того, як лагодити. Відлік іде з моменту, коли помітили. Попереднє повідомлення дозволене і краще за запізніле.

І інцидент завершується не чистим сайтом, а закритою діркою.

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