Защита персональных данных в веб-приложениях: шифрование, доступ, журнал действий и удаление

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

Где данные прячутся

• Журналы приложения и сервера. Адрес запроса с почтой в параметре, тело запроса с телефоном, трассировка ошибки с полями формы.
• Резервные копии. Полная копия базы лежит дольше самой записи и часто защищена хуже основной базы.
• Тестовые стенды. Выгрузку с боевой базы «для проверки» оставляют навсегда, и доступ к стенду у всех разработчиков.
• Аналитика и сторонние виджеты. Скрипты подгружают на страницы с формами и получают всё, что на них отображается.
• Файлы. Сканы документов, вложения, выгрузки отчётов в общих папках и во временных каталогах.

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

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

• Поля, а не всё подряд. Шифрование каждого столбца усложняет поиск и отчёты. Выбираем поля, где риск высок (документы, реквизиты), остальное защищаем правами и шифрованием диска.
• Поиск по зашифрованному. Для точного совпадения хранится отдельный хеш с секретным ключом.
• Ключи отдельно от данных. Ключ в той же базе, что и данные, превращает шифрование в формальность. Ключи живут в хранилище секретов, есть порядок замены и план на случай утечки ключа.
• Обезличивание и псевдонимизация. Для аналитики и стендов идентификаторы заменяются случайными значениями, связь хранится отдельно и под более строгим доступом.

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

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

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

Отдельная тема — ИИ. Отправлять персональные данные во внешние облачные модели для данных ограниченного доступа чаще всего не подходит по требованиям заказчика. Если ассистент должен работать с карточками клиентов или обращениями, модель разворачивается на ваших серверах, как на странице частных языковых моделей. Проверку самого ИИ-решения на утечки описывает страница аудита ИИ.