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

Двухфакторная аутентификация — это вход, для которого одного пароля недостаточно: нужно ещё подтверждение через то, что есть только у владельца, — код из приложения, СМС, аппаратный ключ. Для персональных данных на сайте это защита от вполне обыденного сценария: подобранный, украденный или повторно использованный пароль от админки, CRM или хостинга. Закон не называет двухфакторную аутентификацию по имени, но статья 19 152-ФЗ и приказ ФСТЭК №21 требуют идентифицировать и аутентифицировать пользователей и защищать данные от несанкционированного доступа — и для доступа снаружи второй фактор оказывается самым дешёвым способом это выполнить.

Проверить бесплатно, какие нарушения 152-ФЗ видны на вашем сайте снаружи ←

Что такое двухфакторная аутентификация и от чего она защищает?

Аутентификация — проверка того, что вошедший действительно тот, за кого себя выдаёт. Факторы бывают трёх видов: то, что человек знает (пароль), то, что у него есть (телефон, ключ), и то, чем он является (биометрия). Двухфакторная аутентификация требует двух факторов разных видов: пароль плюс код с устройства. Два пароля подряд — это не два фактора.

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

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

Требует ли закон двухфакторную аутентификацию?

Прямо — нет. Ни 152-ФЗ, ни постановление Правительства №1119, ни приказ ФСТЭК №21 не содержат слов «двухфакторная» или «многофакторная». Нормы формулируют требования на уровне результата и классов мер, а не конкретных технологий, — и это правильно: технологии меняются быстрее законов.

Что именно требуется:

Оговорка о сроке годности: приказ ФСТЭК №21 на сентябрь 2026 года действует, но 24 июля 2026 года ФСТЭК опубликовала проект приказа, который отменяет его целиком и вводит другой состав мер. На момент публикации этой статьи проект не издан и в Минюсте не зарегистрирован — перед тем как ссылаться на таблицу базовых наборов, сверьтесь с актуальным статусом.

Ключевая мысль: приказ ФСТЭК №21 требует выбрать базовый набор мер по уровню защищённости, адаптировать его под систему и уточнить так, чтобы нейтрализовать актуальные угрозы. Если для вашей системы актуальна угроза кражи пароля администратора — а для сайта с админкой, доступной из интернета, она актуальна всегда, — мера «идентификация и аутентификация», реализованная одним паролем, эту угрозу не нейтрализует. Второй фактор — способ довести меру до результата. Как читать приказ владельцу обычного сайта, разобрано в статье «Приказ ФСТЭК №21 для владельца сайта».

Отдельно про надзор: часть 8 статьи 19 152-ФЗ адресует контроль ФСБ и ФСТЭК государственным информационным системам персональных данных, а также иным ИСПДн, которые эксплуатируются в государственных органах. Обычную коммерческую систему это не охватывает — но часть 9 той же статьи позволяет решением Правительства наделить ФСБ (и, отдельным решением, ФСТЭК) полномочиями по контролю и в негосударственных системах, эксплуатируемых при осуществлении определённых видов деятельности. То есть «нас точно никто не проверит» — не свойство закона, а текущее состояние. Обязанность оценивать эффективность мер не исчезает в любом случае, а после утечки вопрос «почему администратор входил по одному паролю» будет первым.

Где на сайте второй фактор нужен в первую очередь?

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

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

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

Третий приоритет — обычные личные кабинеты. Второй фактор по желанию пользователя, но обязательно — при смене адреса электронной почты и телефона: именно через их подмену чужой кабинет захватывают насовсем. Как та же логика работает против подделки запросов, разобрано в статье «Защита от CSRF-атак».

Есть и доступы, о которых забывают: API-ключи интеграций, учётные записи в облачных таблицах, куда сайт складывает заявки, аккаунты в конструкторах сайтов. Каждая из них — вход в персональные данные, и на каждую распространяется та же логика.

Какие способы второго фактора существуют и чем они различаются?

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

Первое — авторизация. Перечень допустимых способов авторизации пользователей на российских сайтах задаёт часть 10 статьи 8 закона 149-ФЗ (введена Федеральным законом №406-ФЗ от 31.07.2023, действует с 1 декабря 2023 года): номер телефона российского оператора подвижной радиотелефонной связи, ЕСИА, единая биометрическая система, иная информационная система российского юридического лица или гражданина РФ. Норма говорит о способе самого входа, а не о факторах подтверждения поверх него: соответствие определяется тем, чем пользователя авторизуют. Собственный логин с паролем на российском сайте в перечень укладывается сам по себе, и второй фактор к этому ничего не добавляет — но ничего и не нарушает. А вот вход целиком через иностранную учётную запись перечню не соответствует; подробности в статье «Штраф за кнопку „Войти через Google“» — сам запрет действует не с 2026 года, а с 1 декабря 2023-го, с 2026-го за него появился штраф.

Второе — сертифицированные средства. Условие здесь не уровень защищённости и не категория данных. Подпункт «г» пункта 13 Требований, утверждённых постановлением Правительства №1119, стоит в блоке требований к 4-му, самому низкому уровню защищённости и звучит так: «использование средств защиты информации, прошедших процедуру оценки соответствия требованиям законодательства Российской Федерации в области обеспечения безопасности информации, в случае, когда применение таких средств необходимо для нейтрализации актуальных угроз». Пункты 14–16 наследуют это требование для уровней с 3-го по 1-й, а пункт 4 приказа ФСТЭК №21 повторяет ту же условную конструкцию. Критерий, таким образом, один для всех уровней и завязан на модель угроз. Для доступа администратора небольшого сайта к CMS обычно достаточно встроенного второго фактора; сертифицированное средство понадобится тогда, когда без него конкретную актуальную угрозу не закрыть.

Третье, о чём в статьях про второй фактор почти не пишут: СМС-код — это обработка персональных данных. Номер телефона — персональные данные, а рассылка кодов подтверждения — отдельная цель обработки. Если сайт раньше телефон не собирал, включение СМС-фактора расширяет и состав обрабатываемых данных, и перечень целей. Значит, правится политика обработки, правится текст согласия в форме — и, если изменились сведения из уведомления, подаётся уведомление об изменении сведений в реестре операторов (часть 7 статьи 22 152-ФЗ). Как это оформляется, разобрано в статье «Уведомление об изменении сведений в реестре операторов». Обидно закрыть одну дыру и открыть другую — ровно ту, которую внешний мониторинг видит без всякого запроса.

Как внедрить второй фактор, не сломав вход?

Порядок, который не создаёт хаоса:

1. Составить реестр доступов. Кто, к какой системе, с какими правами. Без него нельзя проверить, что второй фактор включён у всех, — а «у всех, кроме одного» не работает.
2. Начать с самых опасных доступов — хостинг, база, почта домена, регистратор, админка CMS. Это несколько учётных записей, обычно у одного-трёх человек.
3. Выбрать способ для сотрудников — приложение-генератор как основной, резервные коды — обязательно, хранение резервных кодов — в менеджере паролей, а не в заметках.
4. Описать процедуру восстановления. Кто подтверждает сброс второго фактора, как он проверяет личность, где это фиксируется. Восстановление по ссылке из письма — нет.
5. Включить обязательность. Сделать второй фактор рекомендуемым — значит не сделать ничего: включат те, кому не лень. Для административных доступов он должен быть условием входа.
6. Ограничить время сессии. Бессрочная сессия администратора обесценивает второй фактор: достаточно один раз украсть cookie. Повторное подтверждение — при входе с нового устройства и при чувствительных действиях.
7. Включить журнал входов и оповещения о входе с нового устройства или из новой страны. Второй фактор не только блокирует чужой вход, но и делает попытки видимыми — это и есть «обнаружение фактов несанкционированного доступа» из статьи 19 152-ФЗ. Держите в голове, что будет дальше: если журнал показал чужой успешный вход, у оператора включается часть 3.1 статьи 21 152-ФЗ — уведомить Роскомнадзор об инциденте нужно в течение 24 часов, а о результатах внутреннего расследования — в течение 72 часов. Порядок действий в первые сутки разобран в статье «Утечка персональных данных: как обнаружить».
8. Распространить на подрядчиков. Разработчик, агентство, фрилансер входят в те же системы. Их учётные записи — под теми же правилами, а после окончания работ — удаляются.
9. Затем — пользователи. Сначала как опция и как обязательное подтверждение при смене контактов, потом — по мере готовности поддержки отвечать на вопросы «не приходит код».

На каждом шаге стоит проверять, что не появилось обходного пути. Самый частый: второй фактор включён в CMS, но панель хостинга открывает базу напрямую по одному паролю. Или в CRM второй фактор есть у пользователей, но API-ключ интеграции с полными правами лежит в коде сайта.

Какие ошибки сводят защиту на нет?

• Второй фактор «почти у всех». Одна учётная запись без него — и защиты нет. Проверять по реестру доступов, а не по ощущениям.
• Восстановление через почту без второго фактора. Тогда вся защита равна защите почтового ящика. Почта домена — первое, что нужно закрыть вторым фактором, и восстановление административных доступов не должно идти через самообслуживание.
• Общая учётная запись администратора. «Один логин на всех» исключает и второй фактор, и журнал: кто именно вошёл — неизвестно. Каждому человеку — своя учётная запись.
• Бессрочные сессии и «запомнить меня» навсегда. Украденная cookie сессии обходит второй фактор полностью. Срок жизни сессии и повторное подтверждение при чувствительных действиях.
• API-ключи и технические доступы вне контроля. Ключ интеграции с правами на экспорт — тот же администратор без второго фактора. Минимальные права, ротация, хранение вне кода.
• Резервные коды в общем чате. Их выдают один раз и хранят так же, как пароли.
• Уволенные и бывшие подрядчики. Второй фактор не помогает, если учётная запись человека, который ушёл год назад, до сих пор активна.

Как проверить свой сайт без пентеста?

Проверка занимает час и не требует специалиста:

• открыть реестр доступов (или составить его) и по каждой системе отметить, включён ли второй фактор у каждой учётной записи;
• попробовать восстановить пароль администратора: если хватает письма на почту, а у почты нет второго фактора, — это и есть дыра;
• посмотреть в CMS и CRM список активных пользователей и удалить тех, кого нет в компании;
• проверить, есть ли журнал входов и кто получает оповещения о входе с нового устройства;
• проверить срок жизни сессии администратора — открыть админку с устройства, на котором входили месяц назад;
• найти все API-ключи и ключи интеграций и проверить, где они хранятся и какие права имеют.

Всё это — внутренняя часть, снаружи её не видно. Внешнюю часть — какие формы собирают данные, какие сторонние сервисы их получают, есть ли политика и согласие — показывает бесплатный скан на rkn-ok.ru. Он не проверит второй фактор в вашей админке, но покажет, что регулятор и любой посторонний видят на сайте до всякого входа.

С чего начать

Если делать одно действие сегодня — включить второй фактор на почте домена и в панели хостинга. Это два доступа, через которые восстанавливаются все остальные, и без них любая другая защита обходится за пять минут. Затем — админка CMS и CRM, затем — реестр доступов и процедура восстановления. Пользовательские кабинеты — после того, как закрыты административные.

Что читать дальше

• Приказ ФСТЭК №21 для владельца сайта — какие меры из приказа относятся к обычному сайту
• Защита от CSRF-атак — как подделка запроса подменяет контакты в личном кабинете
• Content Security Policy и защита персональных данных — защита от чужих скриптов на страницах с формами

Источники: Федеральный закон №152-ФЗ «О персональных данных» — статья 19 (в том числе части 8 и 9), часть 3.1 статьи 21, часть 7 статьи 22; постановление Правительства РФ от 01.11.2012 №1119 — пункты 13–16 Требований; приказ ФСТЭК России от 18.02.2013 №21 — пункты 4, 6, 8–10 и группа мер ИАФ приложения; Федеральный закон №149-ФЗ «Об информации» — часть 10 статьи 8 (введена Федеральным законом №406-ФЗ от 31.07.2023).