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

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

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

Откройте любую базу утечек, и закономерность видна сразу. «123 456», короткие цифровые комбинации, элементарные шаблоны кочуют из одной утечки в другую.

Еще неприятнее другое: свыше 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 или руководитель службы ИБ. Согласование исключений идет коллегиально: ИБ описывает риск, ИТ отвечает за техническую выполнимость, бизнес решает вопрос сроков, юристы сверяют все с требованиями.

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

С 1 марта 2026 года вступили в силу требования ФСТЭК № 117, которые ужесточили правила аутентификации для государственных и окологосударственных информационных систем. Финансовый сектор ориентируется на ГОСТ Р 57 580.1 и отраслевые требования Банка России.

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

• администраторов любого уровня;
• удаленного доступа в любом виде: VPN, VDI, административные подключения извне;
• административных консолей и панелей управления;
• работы с финансами, персональными данными и коммерческой тайной.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее о наших продуктах в сфере кибербезопасности и управления ИТ-инфраструктурой на наших сайтах:

1. Услуги по кибербезопасности
2. Менеджер паролей ОдинКлюч
3. SSH/SFTP/RDP/VNC-клиент МС22
4. Платформа для инвентаризации ИТ-активов ОдинХаб