Персональные данные на сайте в Казахстане: почему одной политики конфиденциальности уже мало

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

На практике этого недостаточно. Если сайт принимает заявки, собирает имя, телефон или e-mail, использует аналитику, выдаёт именные документы либо хранит сведения о пользователях, важно не только опубликовать юридический документ, но и проверить, как данные обрабатываются технически.

Проблема часто возникает не в отсутствии одной конкретной страницы, а в несоответствии между тем, что написано в документах, и тем, что реально делает сайт.

Политика конфиденциальности — только начало

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

Но сам факт публикации Политики ещё не означает, что процессы обработки персональных данных организованы правильно.

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

1. Определите, какие данные сайт реально собирает

Начинать техническое обследование лучше не с шаблонов документов, а с простой инвентаризации.

Даже обычная форма обратной связи может передавать:

• имя;
• номер телефона;
• адрес электронной почты;
• название организации;
• текст обращения;
• IP-адрес и технические параметры соединения.

Если на сайте есть обучение, тестирование, личные кабинеты, сертификаты или другие сервисы, набор обрабатываемых сведений становится шире.

Поэтому для каждой формы и функции сайта стоит задать простой вопрос: действительно ли все запрашиваемые сведения необходимы для этой задачи?

2. Согласие должно работать не только визуально

Один из распространённых вариантов — обязательная галочка под формой с текстом согласия на обработку указанных данных для рассмотрения обращения и связи с пользователем.

Но наличие checkbox в HTML — только часть решения.

Серверный обработчик формы также должен проверять, передано ли согласие. Иначе автоматизированный запрос может быть отправлен непосредственно обработчику формы без взаимодействия с интерфейсом сайта.

Дополнительно полезно сохранять сведения, позволяющие подтвердить обстоятельства получения согласия:

• факт получения согласия;
• дату и время;
• версию текста согласия;
• ссылку или идентификатор действовавшей редакции документа.

3. Проверьте, куда данные уходят после отправки формы

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

Заявка может:

• сохраняться в базе данных сайта;
• записываться в файл;
• передаваться в CRM;
• отправляться на электронную почту;
• частично попадать в технические журналы.

Иногда владелец сайта уверен, что информация нигде не хранится, потому что форма «просто отправляет письмо». Но после получения такого письма почтовый ящик сам становится местом хранения персональных данных.

Для каждого места хранения полезно ответить на четыре вопроса:

Что хранится? Где хранится? Кто имеет доступ? Когда удаляется?

4. Срок хранения должен существовать не только на бумаге

Фраза «персональные данные хранятся не дольше необходимого» сама по себе мало что даёт администратору сайта.

Гораздо удобнее определить конкретные правила для разных процессов.

Например:

• обращения через формы — ограниченный срок после завершения взаимодействия;
• служебные журналы защиты — значительно более короткий период;
• данные выданных сертификатов — в течение срока, необходимого для проверки документа;
• временные попытки тестирования, rate-limit и защитные записи — только пока они нужны системе.

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

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

5. Cookie и аналитика тоже участвуют в обработке данных

Персональные данные появляются не только после заполнения формы.

Google Analytics, Яндекс Метрика, системы защиты от автоматизированных запросов и другие внешние сервисы могут получать техническую информацию о посетителе уже при загрузке страницы.

Поэтому Cookie-политика должна описывать фактическую конфигурацию сайта.

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

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

6. Сторонние сервисы нельзя забывать

Современный сайт редко работает полностью самостоятельно.

В обработке технических данных могут участвовать:

• хостинг-провайдер;
• почтовый сервер;
• Cloudflare или аналогичные средства защиты;
• Google Analytics;
• Яндекс Метрика;
• CRM и другие внешние системы.

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

7. Публичная проверка сертификатов и документов

Отдельного внимания требуют сайты, которые выдают именные сертификаты, дипломы или другие документы и позволяют проверить их подлинность через интернет.

Безопаснее использовать проверку по конкретному регистрационному номеру, чем публиковать открытый список всех участников.

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

Сам реестр при этом не должен быть доступен напрямую из публичного каталога сайта.

Дополнительно полезны:

• достаточно сложные регистрационные номера;
• ограничение количества запросов;
• защита от автоматического перебора;
• журналирование подозрительной активности;
• ограничение состава публикуемых сведений.

8. Необходимо ограничить административный доступ

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

Для систем, в которых хранятся персональные данные, следует проверить:

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

Особенно опасно хранить пароли почты, API-ключи и другие секреты внутри публично доступных файлов сайта.

9. Нужны минимальные внутренние правила

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

Для небольшой компании или ИП необязательно создавать десятки отдельных регламентов.

Практический внутренний комплект может состоять всего из трёх документов:

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

Главное — чтобы эти документы описывали реальные процессы, а не существовали исключительно для папки.

10. Что делать при инциденте

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

Организации полезно заранее определить базовый порядок действий:

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

Одна из распространённых ошибок — сразу удалять подозрительные файлы и очищать журналы, пытаясь «быстрее привести сервер в порядок». В результате уничтожаются следы, которые могли помочь установить источник и масштаб инцидента.

Проверьте свой сайт прямо сейчас

Ниже — интерактивная самопроверка. Отметьте пункты, которые действительно реализованы на вашем сайте, а не просто упомянуты в документах.

Чек-лист ничего не отправляет на сервер и не сохраняет выбранные ответы. Результат рассчитывается непосредственно в браузере.

Техническое обследование вместо проверки одной страницы

Основная ошибка — воспринимать защиту персональных данных исключительно как юридическую задачу.

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

Поэтому техническое обследование сайта должно охватывать всю цепочку:

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

И это гораздо полезнее скачанной из интернета Политики конфиденциальности, содержание которой не имеет отношения к реальной работе сайта.

Подробнее о техническом обследовании и услугах по кибербезопасности →