Взлом сервера и утечка базы клиентов: почему защита нужна заранее

Один инцидент - несколько проблем для бизнеса

Утечка клиентской базы может обернуться для компании многомиллионным штрафом. Для отдельных нарушений верхняя граница достигает 15 млн рублей. Последствия затрагивают и работу с инцидентом: нужно выяснить, какие сведения оказались доступны посторонним, ограничить доступ и восстановить работу проекта.

Представим интернет-магазин: сайт продолжает принимать заказы, а чужой человек уже получил доступ к базе покупателей. Владелец может не заметить проблему по внешнему виду сайта. Когда инцидент обнаружится, понадобится восстановить цепочку событий: как вошли в систему, что прочитали и какие действия выполнили.

Поэтому вопрос защиты возникает до атаки. Настройки, разграничение доступов и история событий позволяют подготовиться к ситуации, в которой времени на разбирательство будет мало.

Клиентская база , это не только паспортные данные

Персональные данные определяются через связь информации с конкретным или определяемым человеком. В зависимости от контекста к ним могут относиться имя, номер телефона, электронная почта, адрес доставки и история заказов, связанная с покупателем. Отсутствие паспортов в базе само по себе не выводит её из-под требований закона. Определение приведено в статье 3 закона № 152-ФЗ.

Для владельца сервера полезно начать с карты данных: какие сведения собирает сайт или бот, где они хранятся, кто может их выгрузить и какие копии существуют. Рабочая база , не единственное место хранения. Экспорт для менеджера, резервная копия и архив для разработчика тоже требуют внимания.

Когда возможен штраф до 15 млн рублей

Части 12-14 статьи 13.11 КоАП РФ связывают ответственность с действиями или бездействием оператора, приведшими к неправомерной передаче либо доступу, при отсутствии признаков уголовно наказуемого деяния. Для юридических лиц установлены следующие диапазоны:

3-5 млн рублей: от 1 тыс. до 10 тыс. субъектов и/или от 10 тыс. до 100 тыс. идентификаторов , часть 12;
5-10 млн рублей: от 10 тыс. до 100 тыс. субъектов и/или от 100 тыс. до 1 млн идентификаторов , часть 13;
10-15 млн рублей: более 100 тыс. субъектов и/или более 1 млн идентификаторов , часть 14.

Число строк в таблице не равно числу людей. Закон учитывает также идентификаторы. Меньший объём не означает отсутствия ответственности: возможны другие составы. Для повторных нарушений предусмотрены оборотные штрафы, а для специальных категорий и биометрических данных , отдельные составы. 15 млн рублей не являются общим пределом ответственности.

Почему будут смотреть на защиту до взлома

Статья 19 закона № 152-ФЗ обязывает оператора принимать правовые, организационные и технические меры защиты. Среди направлений , оценка угроз, правила доступа, регистрация действий с данными, обнаружение несанкционированного доступа, реагирование и восстановление.

Сам факт взлома не означает автоматического назначения максимального штрафа. Обстоятельства и вина подлежат установлению. Для юридического лица имеет значение, могло ли оно соблюдать требования и приняло ли зависящие от него меры. Это следует из статьи 2.1 КоАП РФ.

Практический вопрос для владельца: сможете ли вы показать, как были организованы доступы, какие настройки действовали и кто отвечал за реагирование? Формальная установка программы не отвечает на все эти вопросы. Нужны работающие меры и сведения об их применении.

Что проверить на Linux-сервере заранее

Начните с нескольких конкретных задач. Список ниже помогает организовать техническую проверку; полный состав обязательных мер определяется для конкретной информационной системы.

Доступы. Кто входит на сервер и в панели управления? Какие учётные записи и ключи остались у бывших сотрудников и подрядчиков? Для поддерживающих её сервисов настройте многофакторную аутентификацию.
Доступность сервисов. Какие компоненты должны принимать подключения из интернета? Ограничьте ненужный публичный доступ к базе и административным интерфейсам, согласовав изменения с работой приложения.
Обновления. Проверьте ОС, веб-сервер, приложение и зависимости. Назначьте ответственного за установку обновлений и проверку работоспособности после них.
Права приложения. Определите, какие данные и операции ему действительно нужны. Отдельно проверьте возможности выгрузки и административные функции.
Резервные копии. Ограничьте доступ к ним и проверьте восстановление. Возврат базы восстанавливает работу сервиса; сведения о раскрытии данных при этом нужно учесть в разборе инцидента.
Наблюдение. Определите, какие события собираются, где они сохраняются и кто разбирает тревоги. Сообщение о проблеме должно приводить к понятному действию.

Если сервер обслуживает внешний специалист, попросите показать результат этих проверок. Для обсуждения не обязательно знать все команды Linux: важно понимать, кто имеет доступ к вашим данным и что произойдёт при обнаружении подозрительной активности.

Какая история событий пригодится после инцидента

Полезно заранее собирать сведения об успешных и неуспешных входах, изменениях доступов, административных действиях и выгрузках. В записи должны быть понятны время, источник, действие и результат. Журналы самого приложения часто дают контекст, которого нет в системных логах: например, какой пользователь запросил экспорт клиентской базы.

Системные события и события приложения дополняют друг друга. Запись о заблокированном переборе пароля не доказывает, что утечки не было через другой путь. А отсутствие записи нельзя считать подтверждением отсутствия действия, если соответствующий журнал вообще не был включён.

Логи тоже нужно защищать от постороннего чтения, изменения и удаления. Не записывайте в них пароли, токены и полное содержимое клиентской базы. Практические принципы описаны в рекомендациях OWASP по журналированию.

Если утечка уже выявлена: есть сроки уведомления

При установлении факта неправомерной или случайной передачи либо доступа к персональным данным, повлёкших нарушение прав людей, часть 3.1 статьи 21 закона № 152-ФЗ предусматривает уведомление Роскомнадзора:

В течение 24 часов: первичные сведения об инциденте, предполагаемых причинах и вреде, принятых мерах и контактном лице.
В течение 72 часов: результаты внутреннего расследования и сведения о лицах, чьи действия стали причиной инцидента, при наличии.

Оба срока отсчитываются от момента выявления такого инцидента оператором, Роскомнадзором или иным заинтересованным лицом. Второе уведомление не означает дополнительные 72 часа после первого. На портале Роскомнадзора доступна форма уведомления об инциденте.

За невыполнение или несвоевременное выполнение этой обязанности часть 11 статьи 13.11 КоАП предусматривает для юридических лиц штраф 1-3 млн рублей.

Заранее определите, кто принимает решение об ограничении доступа, сохраняет необходимые сведения и готовит уведомление. Техническое устранение проблемы и выполнение обязанностей оператора нужно организовать параллельно.

Как в этой задаче помогает Light Defender

В Light Defender мы занимаемся защитой Linux-серверов. Наш открытый продукт Open Defender отслеживает попытки перебора SSH, веб-сервисов и баз данных, а также веб-разведку. В зависимости от включённых мониторов и выбранных режимов агент фиксирует события или блокирует источники по настроенным правилам.

События агентов можно собирать в Light Defender Dashboard: просматривать историю, получать уведомления и управлять конфигурациями подключённых серверов. Такая история помогает разбирать зафиксированную активность до и во время инцидента. Она не заменяет журналы действий с персональными данными внутри вашего приложения.

Защита сервера , часть общей системы мер. Агент не исправляет автоматически ошибки приложения, не заменяет организационные процедуры и не гарантирует освобождения от ответственности. Поэтому мы предлагаем и настройку защиты под конкретный проект: доступы, SSH, межсетевой экран, защиту базы и правила реакции нужно согласовать с тем, как работает ваш сервис.

Обсудить защиту сервера с Light Defender →

Что владелец бизнеса должен знать до атаки

Где хранятся данные клиентов? Кто может к ним обратиться? Кто заметит подозрительное действие? Из каких сведений можно будет восстановить ход событий? Кто отвечает за реагирование и уведомление?

Ответы на эти вопросы связывают техническую защиту с работой бизнеса. Если они пока сводятся к «сервером занимается разработчик», стоит проверить настройки и распределить ответственность до инцидента.

Сведения о законодательстве проверены на 14 октября 2026 года. Применимая квалификация зависит от обстоятельств инцидента; технический чек-лист не является полной проверкой соблюдения требований к обработке персональных данных.