Чтобы защитить персональные данные в веб-приложении, нужно сделать восемь вещей и сделать их в правильном порядке: составить карту данных, перестать собирать лишнее, закрыть канал связи, ограничить доступ, правильно хранить пароли, зашифровать самое чувствительное, вести журнал действий и научиться удалять. Первые четыре стоят недорого и закрывают большую часть реальных утечек, дорогое шифрование полей идёт после них.
Юридическая сторона (политика обработки, согласия, уведомления, статус оператора) в статью не входит: её ведёт юрист заказчика, мы юридических консультаций не даём. Здесь только то, что делается в приложении и серверах. Как мы берёмся за такую работу, описано на странице «Защита персональных данных в веб-приложениях».
С чего начать: карта данных на одной странице
Любая защита опирается на перечень: что именно вы храните о людях. Без него не получится ответить ни на один вопрос службы безопасности, ни на запрос человека о его данных. Хватает таблицы, в которой на каждое поле, содержащее данные о человеке, записаны пять ответов. Ниже условный пример для кабинета сервисной компании.
| Поле | Зачем нужно | Где лежит | Кто видит | Срок |
|---|---|---|---|---|
| Фамилия и имя | Обращение и документы | База кабинета, учётная система | Менеджер клиента, бухгалтерия | Пока действует договор |
| Телефон | Связь по заявке | База кабинета, журнал вызовов | Менеджер, поддержка | Пока действует договор |
| Скан паспорта | Оформление договора | Файловое хранилище | Только юрист и бухгалтер | Срок определяет юрист |
| Адрес доставки | Выезд специалиста | База кабинета | Менеджер, диспетчер | До закрытия заявки плюс срок учёта |
| Комментарий к заявке | Описание проблемы | База кабинета, почта | Менеджер, поддержка | Пока действует договор |
Пример показывает типичные находки. Скан паспорта в реальных приложениях часто виден всему отделу, а здесь доступ ограничен двумя ролями. Комментарий дублируется в почте, а значит, живёт по правилам почты, а не кабинета. Если в графе «Зачем» нечего написать, поле собирают по привычке. Такое поле удаляют из формы: данные, которых нет, не утекут.
Заведите вторую таблицу для потоков: куда данные уходят (учётная система, почтовый сервис, аналитика, карты, платёжный провайдер) и на каком основании. Эти строки чаще всего оказываются сюрпризом.
Восемь мер по порядку: что дешевле и что даёт больше
Порядок ниже учитывает усилия и пользу. Первые четыре меры описывают скорее дисциплину, чем разработку, и закрывают самые частые причины утечек: забытые права, слабые пароли и данные, попавшие не туда.
| Шаг | Мера | Усилия | От чего защищает |
|---|---|---|---|
| 1 | Карта данных и отказ от лишних полей | Малые: несколько дней разбора | От утечки того, что вообще не нужно было хранить |
| 2 | Защищённый канал везде, включая внутренние обмены | Малые | От перехвата данных в сети и подмены страниц |
| 3 | Права: каждый видит только своё, проверка на сервере | Средние: роли и тесты | От чтения чужих записей по прямой ссылке и подбором номера |
| 4 | Хранение паролей и ключей: только хеш, секреты вне репозитория | Малые | От массового вскрытия учётных записей при утечке базы |
| 5 | Журнал действий с просмотрами и выгрузками | Средние | От ситуации, когда непонятно, кто и когда смотрел данные |
| 6 | Порядок с копиями, журналами ошибок и стендами | Средние | От тихих утечек вне основной базы |
| 7 | Шифрование чувствительных полей в приложении | Высокие: меняется поиск и отчёты | От чтения базы человеком с доступом к ней и от утечки копии |
| 8 | Сроки хранения, выгрузка и удаление по запросу | Средние или высокие: зависит от числа систем | От накопления данных и невозможности ответить человеку |
Шифрование стоит на седьмом месте не потому, что оно мало значит. Оно дорого и ломает поиск, и если до него не закрыты права и пароли, зашифрованное поле читается тем же способом, что и обычное, через уязвимость приложения.
Шифрование: три разных защиты под одним словом
Фраза «данные зашифрованы» ничего не говорит, пока не ясно, от чего именно. Таких защит три, и каждая отвечает на свой вопрос.
| Что шифруется | От чего защищает | От чего не защищает | Что проверить |
|---|---|---|---|
| Канал связи (TLS) | От перехвата и подмены данных между браузером и сервером, между сервисами | От ошибок самого приложения и от чтения базы | Все адреса отвечают по защищённому соединению; включён заголовок, запрещающий вернуться на незащищённый; ключи сайта обновляются |
| Диск или том | От кражи носителя, сервера или копии диска | От запроса в базу действующей учётной записью: база расшифровывает данные сама | Включено на серверах и на томах резервных копий |
| Поле в приложении | От чтения таблицы человеком с доступом к базе и от утечки копии | От уязвимости самого приложения: оно умеет расшифровать, значит, и злоумышленник через него | Ключ лежит отдельно от базы; есть порядок его замены |
Шифрование полей оправдано для небольшого числа значений: сканы документов, реквизиты, особые сведения. У него есть цена: по зашифрованному полю нельзя искать по части строки и сортировать, а для точного совпадения нужен отдельный хеш с секретным ключом. Решение принимают при проектировании, переделывать его в работающей системе трудно. Ключ, который хранится в той же базе, что и данные, превращает шифрование в формальность.
Пароли и ключи: самое частое и самое дешёвое
Здесь больше всего ошибок, которые исправляются за дни.
- Пароль пользователя не хранится. Хранится результат медленного хеширования с индивидуальной солью (argon2, bcrypt или scrypt). Быстрые хеши общего назначения для паролей не годятся. Если база попадёт в чужие руки, пароли должны остаться недоступными.
- Пароли не пересылаются. Ни по почте, ни в чате. «Забыли пароль» отправляет одноразовую ссылку со сроком, а не старый пароль: если вам когда-либо присылали пароль письмом, значит, он хранится в открытом виде.
- Секреты вне репозитория. Ключи доступа к базе и сервисам лежат в хранилище секретов или в защищённых переменных среды. Найденный в истории репозитория ключ считается раскрытым и заменяется, даже если файл давно удалён.
- Второй фактор там, где открываются большие объёмы. Для администраторов, поддержки и ролей с выгрузкой он обязателен. Подробнее о способах — в статье «SSO и MFA: что выбрать».
- Ограничение попыток входа. Без него пароли подбирают автоматически, и сильное хеширование не спасает слабый пароль.
Доступ: как выглядит принцип необходимости в коде
Принцип прост: сотрудник и клиент получают ровно то, что нужно для работы. В приложении его выражают пять правил.
- Права проверяет сервер на каждый запрос. Спрятанная кнопка ничего не защищает, если адрес запроса открыт.
- Просмотр списка и открытие карточки разделены. В списке достаточно имени и номера, полная карточка требует отдельного права.
- Выгрузка — отдельное право. Именно выгрузки уносят базы целиком, поэтому её получают единицы и её размер ограничен.
- Чувствительные поля маскируются. Телефон показывается частично, пока человек не нажал «показать», и это нажатие попадает в журнал.
- Доступ следует за должностью. Уволенный и переведённый на другой участок сотрудник теряют права в тот же день. Это нужно подкрепить связью с каталогом пользователей или процессом отзыва доступа.
Проверяется это прогоном: из-под каждой роли пытаются открыть чужие записи по прямым адресам, перебирая идентификаторы. Как устроены роли в кабинете, описано в статье про личный кабинет для партнёров, а изоляция данных клиентов в SaaS — в статье про мультиарендность.
Журнал действий: достаточно, чтобы расследовать, и не больше
Журнал отвечает на вопрос «кто, что и когда». Хороший журнал содержит событие, пользователя, время, адрес и основание, а плохой собирает копию самих данных и сам становится утечкой.
- Что писать. Вход и неудачные попытки, смену прав, открытие карточки с персональными данными, изменение и удаление, выгрузки, действия поддержки «от имени клиента».
- Чего не писать. Пароли, коды подтверждения, токены сессий, полные номера документов и тела запросов с формами. Достаточно идентификатора записи.
- Как хранить. Записи только добавляются, правка закрыта даже администратору; журнал лежит отдельно от основной базы и доступен узкому кругу.
- Кто читает. Журнал, который никто не смотрит, бесполезен. Назначьте ответственного и пороги: массовая выгрузка, вход из необычного места, всплеск неудачных попыток вызывают оповещение.
- Срок хранения. Записан в регламенте; журнал хранится дольше, чем нужен для расследования типичного происшествия, но не бессрочно.
Где данные утекают тихо: журналы ошибок, копии и стенды
Основная база обычно защищена лучше всего. Утечки случаются там, где данные оказались как побочный продукт.
| Место | Как туда попадают данные | Что делаем |
|---|---|---|
| Журналы ошибок и отладки | Исключение печатает объект целиком, адрес запроса содержит почту в параметре | Маскируем поля при записи, не пишем тела запросов, отключаем отладочный вывод в боевой среде |
| Тестовые стенды | Выгрузка боевой базы «для проверки», доступ у всех разработчиков | Обезличиваем при выгрузке: имена и контакты заменяются, структура и объёмы сохраняются |
| Резервные копии | Полная копия живёт дольше записи и защищена хуже | Шифруем копии, храним отдельно, проверяем восстановление, записываем срок жизни |
| Аналитика и виджеты | Скрипты на странице с формой получают всё, что на ней отображается | Убираем лишние, исключаем страницы с формами из сбора, проверяем, какие поля уходят |
| Почта и мессенджеры | Уведомления несут полное содержимое заявки | Отправляем ссылку на заявку, а не её текст |
| Выгрузки и файлы | Отчёт, сохранённый в общей папке, остаётся там навсегда | Временные файлы с очисткой по расписанию, выгрузка по защищённой ссылке со сроком |
Если внешний сервис получает персональные данные, запишите, какие именно, куда и на каком основании. Персональные данные граждан России обычно должны храниться на серверах в России, и вопрос о допустимости внешнего сервиса решает юрист. Для ИИ-сервисов правило строже: внешние облачные модели для таких данных чаще всего не подходят по требованиям заказчика, модель разворачивают на ваших серверах.
Десять вопросов разработчику, чтобы проверить всё без специалиста
Эти вопросы можно задать за час. Хороший ответ конкретен («вот таблица, вот настройка, вот тест»), плохой общий («используем современные методы»).
- Покажите карту данных: какие поля, где хранятся, сколько живут.
- Есть ли адреса приложения, которые отвечают без защищённого соединения?
- Как хранятся пароли, какой алгоритм? Что происходит при «забыли пароль»?
- Где лежат ключи и пароли сервисов? Есть ли они в истории репозитория?
- Что увидит клиент A, если подставить в адрес идентификатор записи клиента B?
- Кто может выгрузить базу клиентов и что остаётся в журнале после выгрузки?
- Что попадает в журнал ошибок при сбое формы входа или оплаты?
- На стендах боевые данные или обезличенные?
- Как давно проверялось восстановление из резервной копии и кто имеет к ней доступ?
- Как удалить человека целиком: из базы, файлов, поиска и сторонних систем?
Если на три и более вопроса нет ответа, начинайте с обследования, а не с покупки средств защиты. Это тот же принцип, что и в статье про OWASP Top 10: сначала понять, что есть.
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ за один-два процесса и 2–3 недели, 350 000 ₽ и 3–4 недели, если данные проходят через несколько систем. На выходе карта данных, проверка мер по слоям, список расхождений и план исправления по этапам с вилкой бюджета. Стоимость обследования вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.
Дальше, если нужно, доработка приложения этапами: шифрование полей, права, журнал, очистка и удаление, обезличивание стендов. Мы не даём юридических консультаций, не готовим документы по приказам регуляторов, не проводим аттестацию (лицензии ФСТЭК у нас нет) и не дежурим круглосуточно. Исходный код лежит в вашем репозитории с первого коммита, данные и ключи остаются на ваших серверах. Цены и сроки — на странице «Тарифы», описание услуги — на странице «Защита персональных данных в веб-приложениях».
Частые вопросы
Какие технические меры защиты персональных данных нужны в первую очередь?
Карта данных и отказ от лишних полей, защищённый канал, проверка прав на сервере и правильное хранение паролей. Они недорогие и закрывают самые частые причины утечек. Журнал действий, порядок с копиями и стендами идут следом, шифрование отдельных полей и автоматическое удаление последними.
Достаточно ли включить шифрование диска или HTTPS?
Нет. Защищённый канал спасает от перехвата по пути, шифрование диска — от кражи носителя. Ни то ни другое не защищает от запроса в базу действующей учётной записью и от ошибок самого приложения. Для этого нужны права, журнал и, для отдельных полей, шифрование в приложении.
Как правильно хранить пароли пользователей?
В виде результата медленного хеширования с индивидуальной солью, например argon2, bcrypt или scrypt. Сам пароль не хранится и не пересылается, восстановление идёт через одноразовую ссылку со сроком. Быстрые хеши общего назначения для паролей не подходят.
Нужны ли сертифицированные средства защиты?
Это определяет юрист и требования вашего заказчика или регулятора, а не мы. Если сертифицированная криптография нужна, средства и их настройку обеспечивает заказчик или лицензированная организация. Мы встраиваем вызовы в приложение и проверяем, что меры работают; лицензируемых работ по защите информации не проводим.
Как удалить данные человека, если они есть в резервных копиях?
Из копий точечно данные не удаляют. Записывают срок жизни копий, и удалённые по запросу данные уходят из них по его истечении. На обследовании фиксируется этот срок, а также места, где данные нужно стереть сразу: база, файлы, поисковый индекс, кэш и сторонние системы.
Можно ли отправлять персональные данные в ChatGPT или другие облачные модели?
Для персональных данных и данных ограниченного доступа внешние облачные модели чаще всего не подходят по требованиям заказчика. Если ассистент должен работать с такими данными, модель разворачивается на ваших серверах, а качество проверяется на вашей выборке.
Что делать с тестовыми стендами?
Не использовать боевую базу. При выгрузке данные обезличиваются: имена, телефоны и документы заменяются, структура и объёмы сохраняются. Тогда разработчик воспроизводит ошибки, а утечка стенда не раскрывает людей.
Сколько стоит такая работа?
Обследование стоит 200 000 ₽ за 2–3 недели (350 000 ₽ за 3–4 недели, если систем несколько), оно вычитается из первого этапа, если продолжаете с нами. Доработка приложения оценивается после обследования, этапами от 150 000 ₽. Сопровождение — 20 000, 60 000 или 120 000 ₽ в месяц.