—

Безопасность личного кабинета: как защитить персональные данные клиентов

Бизнес и эффективность

24 июля 2026

Содержание

Коротко о безопасности личного кабинета
Чем рискует бизнес, если данные утекут
Откуда берутся утечки: типовые уязвимости личного кабинета
Технический контур защиты
Организационные меры и 152-ФЗ
Чек-лист: что включить в ТЗ подрядчику
Подведем итоги
Часто задаваемые вопросы про безопасность личного кабинета

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

Причина обычно не в сложной хакерской атаке, а в типовых ошибках, которые легко закрыть еще на этапе разработки. Разберем, откуда берутся утечки, какие технические и организационные меры защищают личный кабинет (ЛК) и что включить в техническое задание (ТЗ) подрядчику, чтобы заложить безопасность с самого начала.

Коротко о безопасности личного кабинета

Утечка персональных данных клиентов грозит компании штрафом от 3 до 15 млн рублей по закону № 420-ФЗ, а повторная утечка обойдется в 1-3% годовой выручки, но не менее 20 млн.
По закону № 152-ФЗ персональные данные хранят на серверах в России с защитой по требованиям ФСТЭК, берут у пользователя согласие на обработку и ведут регламент доступа сотрудников.
Базовая техническая защита включает шифрование данных в базе, хеширование паролей, двухфакторную аутентификацию, разграничение прав по ролям и логирование действий.
Чаще всего данные утекают из-за слабых паролей, хранения без шифрования, избыточных прав у сотрудников и устаревшего кода с известными уязвимостями.
Перед запуском кабинет с чувствительными данными проверяют на взлом (пентест) и по списку типовых уязвимостей OWASP Top 10.

Чем рискует бизнес, если данные утекут

Еще недавно штраф за утечку персональных данных был для бизнеса неприятностью, но все изменил закон № 420-ФЗ, который с 30 мая 2025 года ужесточил ответственность. Теперь суммы измеряются миллионами рублей, а за повторную утечку доходят до процентов от годовой выручки.

Размер штрафа для компании зависит от того, данные скольких людей утекли:

от 3 до 5 млн рублей, если пострадали от 1 000 до 10 000 человек;
от 5 до 10 млн рублей за утечку данных от 10 000 до 100 000 человек;
от 10 до 15 млн рублей, если пострадали более 100 000 человек.

Закон считает не только людей, но и число утекших записей о них, поэтому под верхнюю планку можно попасть даже при меньшем числе пострадавших. Отдельно наказывают утечку биометрии: за нее компания заплатит от 15 до 20 млн рублей независимо от масштаба.

За повторную утечку штраф считают уже от оборота: от 1 до 3% годовой выручки компании, но не менее 20 млн и не более 500 млн рублей. Для среднего бизнеса такая сумма сопоставима с годовой прибылью.

В 2025 году Роскомнадзор зафиксировал 118 случаев компрометации баз персональных данных — в сеть попали более 52 млн записей. Годом ранее утечек было 135, а объем украденных записей превышал 710 млн.

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

Откуда берутся утечки: типовые уязвимости личного кабинета

Злоумышленники редко тратят силы на сложный взлом. Они массово сканируют сайты и атакуют те, где находят типовую, давно известную ошибку. Такие проблемы собирает OWASP (Open Worldwide Application Security Project) — международная организация, которая ведет рейтинг самых частых уязвимостей веб-приложений OWASP Top 10. Список много лет возглавляют ошибки контроля доступа, а вместе с ними в топ входят слабая аутентификация, небезопасное хранение данных и уязвимости устаревших компонентов. Разберем, как эти четыре проблемы проявляются в личных кабинетах.

Слабая аутентификация

Форму входа атакуют первой, ведь это главная дверь в кабинет. Самый частый прием — перебор паролей, когда программа автоматически подставляет популярные комбинации, пока одна не подойдет. Если сервис не ограничивает число попыток и разрешает пароли вроде «123456» (он до сих пор возглавляет мировые рейтинги худших паролей), взлом становится делом времени.

Вторая слабость — привычка использовать один пароль на десятках сайтов. Когда утекает база одного сервиса, злоумышленники подставляют украденные пары логин-пароль на популярных площадках, где часть из них подходит. По отчету Verizon DBIR 2025, украденные учетные данные участвуют примерно в 88% взломов веб-приложений.

Хранение данных без защиты

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

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

Избыточные права доступа

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

Устаревший код и компоненты

Личный кабинет собирается на фреймворках, библиотеках и готовых модулях. В них регулярно находят уязвимости, а разработчики выпускают обновления с исправлениями. Если сервис годами живет без обновлений, известные дыры остаются открытыми, включая классические SQL-инъекции — внедрение вредоносных команд в запросы к базе данных через обычные поля форм.

Технический контур защиты

Надежный кабинет строится из нескольких обязательных слоев защиты. Каждый из них — обычный стандарт разработки, который достаточно заложить в проект с самого начала.

Шифрование данных в базе

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

Хеширование паролей

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

Двухфакторная аутентификация

Двухфакторная аутентификация (2FA) — это вход в два шага. После пароля пользователь подтверждает личность кодом из СМС, письма или приложения. Даже если пароль украден, войти в кабинет без второго фактора не получится.

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

Роли и права доступа

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

Как выглядит такое разделение на практике, покажем на платформе корпоративного обучения для ГК «ТехноПроф». Раньше компания работала на готовом решении, которому не хватало централизованного управления и разграничения доступа.

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

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

Читайте кейс про платформу корпоративного обучения для ГК «ТехноПроф»

Логирование действий

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

Организационные меры и 152-ФЗ

Технической защиты мало — кабинету нужны и организационные меры, ведь данные часто утекают через людей и процессы. Закон 152-ФЗ «О персональных данных» требует от компании и того, и другого, а Роскомнадзор штрафует за отсутствие мер даже сервисы, которые никто не взламывал.

Минимальный набор для владельца личного кабинета выглядит так:

Согласие на обработку данных. Пользователь дает его при регистрации, обычно галочкой у чекбокса, причем согласие должно быть осознанным. Передавать данные третьим лицам можно, только если это прямо прописано в согласии и указано, кому они уходят.
Политика конфиденциальности. Опубликованный на сайте документ объясняет, какие данные собираются, зачем и как защищаются.
Серверы, соответствующие закону. Базы с персональными данными россиян должны храниться на территории РФ, а требования к их защите устанавливает ФСТЭК (Федеральная служба по техническому и экспортному контролю).
Порядок доступа сотрудников. Внутренний регламент определяет, кто из команды работает с данными клиентов, в каком объеме и что происходит с доступами при увольнении.

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

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

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

Так результаты анализов видит только сам пациент, даже если приложение установил кто-то другой.

Читайте кейс про приложение для клиники «Энергетик»

Чек-лист: что включить в ТЗ подрядчику

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

Вот список требований, который можно взять за основу:

ограничение числа попыток входа и требования к минимальной сложности пароля;
хеширование паролей современным алгоритмом и запрет на хранение в открытом виде;
двухфакторная аутентификация — обязательная для кабинетов с платежами и чувствительными данными, настраиваемая для остальных;
шифрование персональных и платежных данных в базе;
ролевая модель — матрица ролей и прав доступа для клиентов и сотрудников, согласованная до начала разработки;
журнал действий пользователей и администраторов с фиксацией входов, просмотров и выгрузок;
размещение баз данных на серверах в РФ с уровнем защиты по требованиям ФСТЭК;
механика получения согласий на обработку данных и страница политики конфиденциальности;
тестирование безопасности перед запуском и план регулярного обновления компонентов после релиза.

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

Подведем итоги

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

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

Заказать разработку личного кабинета в Атвинте

Часто задаваемые вопросы про безопасность личного кабинета

Что такое персональные данные по 152-ФЗ?

Любая информация, по которой можно определить человека: ФИО, телефон, электронный адрес и адрес проживания. В отдельных случаях к персональным данным относят и IP-адрес, а голос становится ими, когда компания использует его для распознавания личности. Если личный кабинет хранит хотя бы имя и телефон клиента, компания уже считается оператором персональных данных со всеми обязанностями по закону.

Что такое OWASP и зачем о нем знать заказчику?

OWASP — международная организация, которая публикует рейтинг самых распространенных уязвимостей веб-приложений OWASP Top 10. Заказчику не нужно разбираться в каждом пункте. Достаточно попросить подрядчика проверить кабинет по этому списку перед запуском. Для опытной команды это стандартная практика.

Что такое CSRF-атака?

CSRF (Cross-Site Request Forgery, подделка межсайтовых запросов) — атака, при которой злоумышленник через браузер уже авторизованного пользователя незаметно выполняет за него действие вроде смены пароля или подтверждения платежа. Защищают от нее одноразовые токены в формах, которые подтверждают, что запрос отправил сам пользователь.

Что такое bcrypt и почему пароли нельзя хранить в открытом виде?

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

Обязательна ли двухфакторная аутентификация в личном кабинете?

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

Что такое пентест и когда он нужен?

Пентест (тест на проникновение) — проверка, при которой специалисты по безопасности легально пытаются взломать сервис и находят уязвимости раньше злоумышленников. Он нужен перед запуском кабинета с чувствительными данными и после крупных доработок. Небольшим сервисам в качестве минимального варианта подойдет проверка по списку OWASP Top 10 силами команды разработки.

Где должны храниться данные пользователей по закону?

Базы с персональными данными граждан России должны физически находиться на серверах в РФ. Уровень защиты серверов регулируют требования ФСТЭК. Это стоит проверить при выборе хостинга: часть зарубежных облачных сервисов не подходит под это требование.

Сколько стоит защита данных при разработке личного кабинета?

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

Услуги

Аналитика

Проведем исследования и предложим лучшие решения для продукта

Техническая поддержка

Обеспечим стабильность продукта, добавим новые функции и разделы

Разработка

Создадим надежную архитектуру и сильный функционал

Больше классных услуг нашей компании