Единая политика аутентификации: как согласовать парольные правила, многофакторную защиту и восстановление доступа без дыр

Аутентификация — хрупкая система, состоящая из набора элементов, живущих по своим правилам. В Active Directory одни требования к паролям, в почте другие, в CRM вообще можно Qwerty123 поставить и никто слова не скажет.

МегаФон в 2025-м проверил много компаний — у 60% нашли дыры высокого и критического уровня. И проблемы с аутентификацией там отдельной строкой идут. Практика пентестов подтверждает это: большинство успешных взломов начинается с украденных или подобранных учеток.

Почему пароли такие слабые

Берете любую базу слитых паролей — сразу видно закономерность. «123456», короткие цифровые комбинации, простейшие шаблоны — они повторяются в утечках постоянно. Хуже то, что больше 90% паролей дублируются на разных сервисах.

Но это не потому, что люди тупые. У среднего сотрудника 10-15 систем с разными требованиями. Запомнить уникальный сложный пароль для каждой из них физически нереально. Вот и выбирают один простой, копируют его везде.

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

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

Типичная ситуация в российской компании: AD требует минимум 8 символов со сложностью, почтовик хочет 10, а в CRM можно вообще что угодно. Пользователь логично выбирает Qwerty123 и использует его везде, где проходит.

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

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

Что изменилось в требованиях

NIST SP 800-63B — мировой стандарт по аутентификации — пересмотрел подход к паролям. Убрали формальные требования, которые не работали на практике, оставили то, что реально защищает.

Регулярная смена каждые 60-90 дней больше не обязательна.

Исследования показали: люди просто добавляют цифру в конец или меняют одну букву в регистре. Безопасность не растет, раздражение копится. Теперь менять пароль надо только при подозрении на компрометацию.

Длина — минимум 8 символов, лучше 12-15. Для высоких уровней защиты обязательно проверять по базам слитых паролей. От требования «обязательно буква, цифра, спецсимвол» отказались: почти не усиливает пароль, зато запоминать сложнее.

В 2025-м появились слухи про гигантские сборники слитых учеток — говорят, до 16 миллиардов записей, якобы из Telegram, Google, Apple. Никто точно не подтвердил состав, но сам размах дает понять: если сотрудник использует один пароль на нескольких сервисах, а хоть один из них слили — все остальные под угрозой.

Вывод простой: проверять пароли по базам утечек надо обязательно. Обычным компаниям подойдут публичные сервисы вроде Have I Been Pwned, госструктурам и критичным системам лучше поднять локальные копии баз — так данные не уходят на сторону.

Еще две банальности, которые почему-то игнорируют: история паролей — минимум 10 предыдущих значений и блокировка после 10 неудачных попыток. Казалось бы, очевидно. Но на пентестах мы регулярно находим системы, где вообще нет ограничений на перебор. Брутфорсить такое — пять минут работы.

Как выглядит единая политика

Единая политика — не абстрактный регламент на 50 страниц. Это набор конкретных правил под разные ситуации: кто входит, откуда, в какую систему и с какими проверками.

А. Роли. Обычный пользователь, локальный админ, системный администратор, сервисная учетка — риски у каждой роли разные, защита тоже должна отличаться.

Обычный пользователь в офисе: пароль от 12-14 символов, проверка по базам утечек, блокировки, все в логах. MFA включается по ситуации: работаешь удаленно — включай, лезешь в чувствительные данные — тоже, система увидела что-то странное — попросит подтвердить личность дополнительно.

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

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

Б. Сценарии. Вход с рабочего компьютера в офисе — стандартные правила аутентификации. Заходишь удаленно через VPN или VDI — требования выше: MFA обязательна плюс проверка, что устройство корпоративное или хотя бы известное. Открываешь доступ к критичным данным — система может попросить подтвердить личность еще раз прямо по ходу работы. Восстанавливаешь доступ — это вообще отдельная история с обязательной проверкой личности и последующим аудитом всех действий.

В. Базовые требования. Минимальная длина пароля, проверка по базам утечек, блокировки после нескольких неудачных попыток, логи всех операций аутентификации и смены факторов доступа. От этого фундамента нельзя отступать просто так — только если есть задокументированная причина и план, как компенсировать риск.

Г. Исключения. Бывает, старая система физически не умеет работать с длинными паролями или вообще не поддерживает MFA. Тогда исключение записывается в документ, а риск компенсируется другими мерами: изолировать систему на сетевом уровне, усилить мониторинг, составить план миграции с реальными сроками. Владелец политики — CISO или руководитель службы ИБ. Исключения согласовываются коллегиально: ИБ объясняет риск, ИТ говорит, что технически возможно, бизнес решает, можно ли подождать, юристы проверяют на соответствие требованиям.

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

MFA: где реально нужна

С 1 марта 2026 года требования ФСТЭК №117 вступают в силу — они усиливают правила аутентификации для государственных и околоправительственных информационных систем. Для финансового сектора правила задаются ГОСТ Р 57580.1 и отраслевыми требованиями Банка России.

MFA однозначно нужна для:

— Администраторов всех уровней

— Любого удаленного доступа: VPN, VDI, административный доступ извне

— Всех административных консолей и панелей управления

— Доступа к финансам, персональным данным, коммерческой тайне

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

SMS-коды удобные, но рискованные: уязвимости сигнальных сетей SS7, атаки на SIM-карты через подмену в салоне связи. Приложения-аутентификаторы надежнее, но требуют смартфон. Аппаратные токены и смарт-карты с криптографией — самый устойчивый вариант для критичных систем, правда масштабировать их сложнее и дороже. Push-уведомления удобны, но есть риск так называемых MFA fatigue атак — когда злоумышленник заваливает пользователя запросами, пока тот случайно не подтвердит или не устанет отказывать. Стандарты FIDO2 хороши тем, что привязывают фактор аутентификации к конкретному устройству и сервису — фишинг становится бесполезным.

Восстановление — слабое место

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

С технической стороны восстановление доступа — это отдельный сценарий аутентификации, где риск изначально повышен. Если через процесс восстановления можно обойти MFA, если он выдает полноценный доступ без дополнительных проверок или если временный пароль живет неделями — это не процесс, это дыра в системе. Безопасная схема восстановления жестко ограничена: по времени действия, по количеству попыток, по объему прав. И после первого входа с временным паролем система должна требовать повторное подтверждение всех факторов аутентификации.

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

Секретные вопросы в 2025 году просто не работают. Любимый фильм, первая машина, кличка собаки — всё это легко найти в открытых источниках, особенно у людей, активных в соцсетях. Резервные коды восстановления должны храниться в корпоративном менеджере паролей, и пользователь не может сгенерировать новые без подтверждения личности. Временный пароль живет максимум 24 часа и срабатывает ровно один раз. Вошел — сразу меняй на постоянный пароль по всем правилам политики.

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

Как это внедрить технически

Централизованное управление доступом строится на базе корпоративных каталогов (Active Directory, FreeIPA) и систем управления идентификацией (IDM). Они позволяют задать единые требования к аутентификации для всей инфраструктуры разом. Критично важно, чтобы правила были одинаковые на всех платформах — если в Windows требуется 12 символов, а в Linux можно войти с 8, пользователи найдут самый простой путь и будут использовать его везде.

Веб-приложения стоит интегрировать с корпоративным провайдером аутентификации через SAML, OAuth или OpenID Connect — тогда получается единый вход и единые правила для всех систем. Это убирает риск появления слабых мест в отдельно стоящих системах. Если интеграция технически невозможна (совсем древнее приложение), требования к аутентификации в нем все равно должны соответствовать корпоративной политике.

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

Люди важнее технологий

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

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

Линию поддержки надо обучать отдельно. Каждый запрос на восстановление — потенциальная социальная инженерия до момента подтверждения личности.

С чего начать

Начинать надо с аудита: какие системы используют аутентификацию, какие требования к паролям применяются, где включена MFA, как организовано восстановление доступа. Отраслевая аналитика показывает: уязвимости высокого риска во внутренней инфраструктуре находят намного чаще, чем на внешнем периметре. Внутренняя сеть во многих компаниях — более уязвимая зона.

На основе аудита формируется единая политика с опорой на действующие регуляторные требования: ФСТЭК №117, ГОСТ Р 57580.1 для финансового сектора, признанные отраслевые практики. Политика согласовывается с ИТ, ИБ, бизнесом, юристами. Требования, которые нельзя реализовать или поддерживать на практике, будут игнорироваться.

Внедрение идет поэтапно: сначала критичные системы и привилегированные учетки, потом остальные. Пользователям надо дать время на адаптацию и поддержку на переходный период. Рост интереса к пентестам в 2025-м показывает: компании чаще осознают необходимость проверки изменений на практике.

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

Исследования и практика пентестов показывают: у значительной доли компаний до сих пор находят уязвимости высокого и критического уровня, включая дефекты в аутентификации и управлении доступом. Единая политика — не бюрократическое требование, а практический инструмент защиты. Согласованные правила для паролей, продуманная MFA и безопасные процессы восстановления доступа существенно повышают порог атаки. Системный подход к защите аутентификации перестал быть рекомендацией — сегодня это необходимость.

Автор: Игорь Пестов, специалист отдела внедрения АБП2Б, разработчика менеджера паролей ОдинКлюч.