Как обеспечить соответствие требованиям ФСТЭК и 152-ФЗ при хранении паролей
Роскомнадзор провёл 118 расследований утечек персональных данных в 2025 году. Шесть компаний получили штрафы. В 2026 году практика ускоряется: минимальный штраф для юридических лиц по новой редакции КоАП — от 3 млн рублей, максимальный при повторном нарушении — до 500 млн.
Большинство компаний знают, что требования существуют. Но конкретный вопрос — что именно нужно сделать с паролями и доступами, чтобы соответствовать требованиям ФСТЭК и 152-ФЗ — остаётся без чёткого ответа.
В этой статье разбираем именно это: какие требования касаются управления паролями, что проверяет регулятор при расследовании и как выстроить техническую защиту, которая выдержит проверку.
Что говорит закон: требования к управлению паролями
Управление паролями и доступами упоминается в нескольких нормативных документах. Разберём каждый.
152-ФЗ и Постановление Правительства №1119
Федеральный закон №152-ФЗ «О персональных данных» устанавливает общие принципы защиты данных. Конкретные технические требования раскрывает Постановление Правительства №1119, которое определяет уровни защищённости информационных систем персональных данных (ИСПДн) и меры защиты для каждого.
Применительно к паролям и доступам постановление требует: установление правил доступа к персональным данным, регистрацию и учёт всех действий с персональными данными в системе, обнаружение фактов несанкционированного доступа.
На практике это означает три вещи: кто имеет доступ к данным должно быть определено и задокументировано, все действия с данными должны фиксироваться в журнале, несанкционированный доступ должен обнаруживаться автоматически.
Приказы ФСТЭК №17 и №21
Приказ №17 регулирует защиту государственных информационных систем (ГИС), приказ №21 — защиту информационных систем персональных данных в целом. Оба содержат детальные требования к управлению доступом.
Ключевые меры из этих приказов:
УПД.1 — Управление учётными записями пользователей. Создание, активация, блокировка и уничтожение учётных записей. Компания обязана иметь задокументированный процесс управления всем жизненным циклом учётных записей.
УПД.2 — Реализация ролевого управления доступом. Разграничение прав пользователей на основе ролей. Принцип минимальных привилегий — каждый пользователь имеет только те права, которые необходимы для его функций.
УПД.4 — Разделение полномочий. Администраторы системы не должны иметь неограниченного доступа к данным. Функции администрирования и работы с данными разделены.
РСБ.1 — Сбор, запись и хранение информации о событиях безопасности. Журналирование всех значимых событий: входы в систему, изменения прав доступа, операции с данными.
РСБ.3 — Защита информации о событиях безопасности. Журнал событий должен быть защищён от изменения и удаления.
ИАФ.1 — Идентификация и аутентификация пользователей. Требования к сложности паролей, сроку их действия, механизмам аутентификации.
ИАФ.3 — Управление аутентификационной информацией. Это прямое требование к паролям: хранение в защищённом виде, процедуры смены, контроль истории паролей.
Приказ ФСТЭК №239
Регулирует безопасность значимых объектов КИИ. Требования аналогичны приказам №17 и №21, но жёстче и обязательны для критической информационной инфраструктуры.
Что проверяет Роскомнадзор при расследовании инцидента
Понимание того, как именно работает проверка, помогает расставить приоритеты в подготовке.
При расследовании утечки Роскомнадзор запрашивает конкретные документы и данные. Вот что реально проверяется.
Модель угроз и политика обработки персональных данных. Документы должны существовать, быть актуальными и реально описывать вашу инфраструктуру, а не скачанный из интернета шаблон.
Организационно-распорядительная документация. Приказы о назначении ответственных за обработку данных, инструкции для пользователей, регламенты доступа. Если этих документов нет — это само по себе нарушение.
Реестр пользователей и матрица доступов. Кто имеет доступ к каким системам с какими правами. Регулятор должен получить этот ответ в структурированном виде, а не «ну у нас всё настроено».
Журнал событий. Кто авторизовался, когда, с какого IP, какие операции выполнял. Если журнала нет или он не охватывает весь период — это серьёзное отягчающее обстоятельство.
Свидетельства принятых технических мер. Настройки систем, скриншоты конфигураций, технические отчёты. Слова «у нас всё защищено» без документальных подтверждений не работают.
Скорость уведомления. По новому законодательству компания обязана уведомить Роскомнадзор об инциденте в течение 24 часов. Опоздание — отдельный состав правонарушения со штрафом до 3 млн рублей.
Четыре реальных дела 2025–2026 годов показали: суды смягчают или отменяют штрафы тогда, когда компания может документально подтвердить принятые меры защиты. Дело РЖД — показательный пример: апелляция отменила штраф именно потому, что компания смогла доказать наличие технических мер защиты.
Что конкретно нужно сделать: технические меры
Переходим от теории к практике. Вот конкретные технические меры, которые закрывают требования регуляторов применительно к паролям и доступам.
Мера 1. Централизованное хранение паролей с шифрованием
Требование: ИАФ.3 (управление аутентификационной информацией), Постановление №1119.
Пароли должны храниться в зашифрованном виде. Хранение паролей в открытом виде — в Excel, текстовых файлах, мессенджерах — прямое нарушение требований. При расследовании инцидента это становится доказательством недостаточности принятых мер.
Как это закрывает BearPass. Все пароли хранятся с шифрованием AES-256 и ГОСТ. Система разворачивается на серверах компании — данные не покидают периметр. Даже разработчики BearPass не имеют доступа к содержимому хранилища. Это можно документально подтвердить при проверке: архитектурная схема, технический паспорт системы.
Мера 2. Ролевое управление доступом
Требование: УПД.2 (ролевое управление доступом), УПД.4 (разделение полномочий).
Каждый пользователь должен иметь доступ только к тем ресурсам, которые необходимы для его функций. Это не просто рекомендация — это задокументированное требование с конкретным пунктом в приказах ФСТЭК.
Матрица доступов должна быть не только настроена технически, но и задокументирована. Регулятор может запросить документ, показывающий, какие роли имеют доступ к каким ресурсам.
Как это закрывает BearPass. Полноценный RBAC: роли, группы пользователей, гранулярные права на уровне папок и отдельных записей. Матрицу доступов можно экспортировать из консоли администратора и приложить к пакету документов для проверки.
Мера 3. Журналирование всех действий с учётными данными
Требование: РСБ.1 (сбор и хранение событий безопасности), РСБ.3 (защита журнала).
Это одно из наиболее критичных требований при расследовании инцидентов. Журнал должен фиксировать: кто авторизовался, когда, кто открывал или изменял пароли, кто менял права доступа.
Важный нюанс: журнал должен быть защищён от изменения. Если записи журнала можно отредактировать или удалить — это нарушение требования РСБ.3.
Как это закрывает BearPass. Журнал событий фиксирует все действия: авторизации, просмотры паролей, изменения записей, операции с правами доступа. Записи защищены от изменения — удалить запись из журнала незаметно невозможно. Фильтрация по пользователю, дате и типу события. Экспорт через syslog в SIEM-системы: KUMA, MaxPatrol SIEM, QRadar.
Мера 4. Управление жизненным циклом учётных записей
Требование: УПД.1 (управление учётными записями).
Создание, изменение, блокировка и удаление учётных записей должны выполняться по задокументированным процедурам. Доступы уволенных сотрудников должны отзываться немедленно — это прямое требование.
Как это закрывает BearPass. Kill Switch блокирует все активные сессии и отзывает все доступы мгновенно. Интеграция с LDAP и Active Directory автоматизирует процесс: увольнение в AD = автоматическая блокировка в BearPass. Журнал фиксирует момент отзыва доступов — это документальное подтверждение при проверке.
Мера 5. Политики паролей
Требование: ИАФ.1 (идентификация и аутентификация), ИАФ.3 (управление аутентификационной информацией).
Требования к сложности паролей должны быть не только задокументированы в политике, но и принудительно применяться технически. Политика, которая существует только на бумаге, не засчитывается.
Как это закрывает BearPass. Настраиваемые политики паролей: минимальная длина, требования к символам, срок действия, запрет повторов. Политики применяются принудительно на уровне системы — сотрудник не сможет сохранить пароль, не соответствующий требованиям. Политики можно настроить отдельно для каждой папки или категории ресурсов.
Мера 6. Двухфакторная аутентификация
Требование: ИАФ.1 для систем с повышенными требованиями к защите.
Для систем, обрабатывающих персональные данные специальных категорий или большого объёма, многофакторная аутентификация рекомендована или обязательна.
Как это закрывает BearPass. Поддержка TOTP (Google Authenticator и аналоги), биометрии (Face ID, Touch ID), аппаратных токенов (Рутокен), интеграция с «Мультифактором» через SAML SSO. 2FA можно сделать обязательной для всей организации на уровне политики.
Документация: что нужно подготовить
Технических мер недостаточно — нужна документация, которая подтверждает их наличие. Вот минимальный пакет применительно к управлению паролями и доступами.
Политика управления доступом. Документ, описывающий принципы выдачи и отзыва прав, ролевую модель, процедуры онбординга и offboarding. Не шаблон из интернета, а реальный документ про вашу инфраструктуру.
Матрица доступов. Таблица: роль → системы → уровень прав. Должна отражать актуальное состояние, а не то, как было задумано год назад.
Политика паролей. Требования к сложности, срокам действия, процедурам смены. Технически применяется через менеджер паролей — документально закреплена в политике.
Регламент реагирования на инциденты. Что делать при обнаружении компрометации пароля или несанкционированного доступа. Кто уведомляет Роскомнадзор, в какие сроки, по какому алгоритму.
Журнал аудита доступов. Не разовый снимок, а постоянно ведущийся журнал с возможностью предоставить выборку за любой период.
Приказ о назначении ответственного за обработку персональных данных. Без этого документа всё остальное теряет юридическую силу.
Практический чеклист: готовы ли вы к проверке
Пройдитесь по каждому пункту. Если хотя бы на три вопроса ответ «нет» или «не знаю» — есть пробелы, которые стоит закрыть до инцидента, а не после.
- Пароли от всех систем с персональными данными хранятся в зашифрованном виде, не в Excel и не в мессенджерах?
- Права доступа разграничены по ролям, задокументированы и отражают текущую реальность?
- Все действия с учётными данными фиксируются в журнале, который нельзя отредактировать незаметно?
- При увольнении сотрудника доступы отзываются в тот же день — и вы можете подтвердить это документально?
- Политики паролей применяются технически принудительно, а не только декларированы в документах?
- Включена двухфакторная аутентификация для систем с персональными данными?
- Есть документально оформленный регламент уведомления Роскомнадзора в течение 24 часов?
- Ваш менеджер паролей включён в Реестр отечественного ПО?
Смягчающие обстоятельства: как подготовка влияет на исход дела
Судебная практика 2025–2026 годов даёт чёткий ответ на вопрос, зачем выстраивать всё это до инцидента, а не после.
В деле РЖД апелляционный суд отменил штраф, указав что в материалах дела отсутствовали доказательства несоблюдения требований к защите. То есть компания смогла подтвердить, что меры были приняты — и это стало основанием для отмены.
В деле «Инвестиционных проектов» предупреждение вместо штрафа от 5 до 10 млн рублей — в том числе потому, что нарушение было первым и не причинило вреда.
Юристы, работающие с делами об утечках, единогласно указывают: наличие технических мер защиты, задокументированных до инцидента, — это главный аргумент для снижения штрафа или его отмены. Компания, у которой всё выстроено, но произошёл взлом, находится в принципиально другом положении, чем компания, где пароли хранились в Excel.
BearPass в контексте требований регуляторов
Разберём коротко, что именно закрывается при использовании BearPass.
Реестр отечественного ПО Минцифры №15427 — обязательное требование для объектов КИИ и госсектора. Закупка возможна по 44-ФЗ и 223-ФЗ без дополнительных согласований.
On-premise развёртывание на серверах компании — данные не покидают периметр. Соответствует требованию о локализации данных.
Шифрование AES-256 и ГОСТ — соответствие требованиям ИАФ.3 и Постановлению №1119 к хранению аутентификационной информации.
RBAC с документируемой матрицей доступов — требование УПД.2.
Журнал событий с защитой от изменений и экспортом в SIEM — требования РСБ.1 и РСБ.3.
Kill Switch и автоматический отзыв через LDAP — требование УПД.1 к управлению жизненным циклом учётных записей.
Настраиваемые политики паролей с принудительным применением — требование ИАФ.1.
Поддержка 2FA включая Рутокен и Мультифактор — требование ИАФ.1 для систем с повышенными требованиями.
Развёртывание занимает 1–2 часа. Полный онбординг команды — 3–5 дней. Подробная документация: docs.bearpass.ru
Итог
Требования ФСТЭК и 152-ФЗ к паролям и доступам можно свести к шести техническим мерам: централизованное зашифрованное хранение, ролевая модель доступа, журналирование всех событий, управление жизненным циклом учётных записей, принудительные политики паролей и двухфакторная аутентификация.
Каждая из этих мер должна быть не только реализована технически, но и задокументирована — потому что при проверке регулятора слов недостаточно, нужны документы и данные журналов.
Компании, выстроившие это до инцидента, имеют принципиально другие шансы при расследовании, чем те, кто начинает готовиться после утечки.