Пароли в компании: современные правила и как их внедрить

Для чего и кому

Пароли в компании до сих пор часто держатся на правиле «менять каждый месяц или квартал», хотя для облачных учётных записей Microsoft 365 в Password policy recommendations советуют другое: не вводить срок действия паролей. Ниже: какие правила работают сейчас и как внедрить их так, чтобы сотрудники не сопротивлялись.

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

Второй ориентир: NIST SP 800-63B. Документ написан для государственных систем, поэтому для бизнеса он необязателен, но даёт понятную шкалу. На базовом уровне достаточно одного фактора, на втором нужны два разных фактора и вариант аутентификации, устойчивый к фишингу.

Кого это касается

Прежде всего компаний, которые работают с корпоративной почтой Microsoft 365 и имеют облачные (cloud-only) учётные записи: именно для них Microsoft даёт конкретные советы. Для Google Workspace, локального домена, VPN или 1С принципы те же, но нужные настройки ищите в документации каждого продукта. Физический доступ в помещения эти рекомендации не охватывают.

Что это меняет для бизнеса

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

Что понадобится

Права администратора в Microsoft 365 (или в системе, где вы управляете политикой), перечень сервисов с паролями и тестовая учётная запись без доступа к реальным данным. Также нужна памятка для сотрудников на одну страницу и пилотная группа из 5–10 человек из разных отделов.

На настройку хватит нескольких часов, на пилот понадобится несколько дней. Решение о правилах принимает руководитель, администратор лишь воплощает их в настройках.

Если нет администратора

Политику паролей может настроить внешний специалист, штатный сотрудник для этого не нужен. Если в вашей компании нет человека, который следит за учётными записями и политиками доступа, эти настройки и обучение пользователей можно передать команде TakeIT.

Шаги

Каждый шаг содержит действие и способ проверить, что оно сработало.

1. Составьте перечень систем с паролями: почта, VPN, удалённые рабочие столы, 1С, роутеры, общие учётные записи. Проверка: напротив каждой системы записаны владелец и тип входа (личный или общий).
2. Задайте длину и срок действия. Microsoft 365 требует минимум 8 символов, но рекомендует 14. Для облачных учётных записей политика фиксирована, изменить можно только срок действия, и Microsoft советует его не ограничивать. Поэтому 14 символов закрепите правилом компании (удобно объяснить это как длинную фразу из нескольких слов), а срок действия отключите по инструкции Microsoft «Set password expiration policy for Microsoft 365». Проверка: в настройках пароли отмечены как не истекающие, а в памятке указано 14 символов.
3. Заблокируйте простые пароли вроде abcdefg, password, monkey, 123456. Для этого Microsoft упоминает Microsoft Entra Password Protection; доступна ли функция в вашем плане, проверьте в документации. Проверка: на тестовой учётной записи попробуйте установить 123456, система должна отказать.
4. Включите обязательную регистрацию второго фактора (MFA) и попросите обновить контакты для восстановления: резервную почту, телефон или устройство для push-уведомлений. Проверка: в отчёте администратора все активные учётные записи имеют зарегистрированный метод, а для руководителей и бухгалтерии вы сверяете это отдельно.
5. Настройте сброс пароля с подтверждением через приложение аутентификации и риск-политики (identity protection risk policies, risk-based MFA): при подозрительном входе система попросит подтвердить личность. Доступность зависит от вашего плана, поэтому проверьте её в документации Microsoft. Проверка: проведите тестовый сброс на пилотной учётной записи и пройдите подтверждение.
6. Проведите пилот и разошлите памятку. В ней должны быть простые правила: не использовать рабочий пароль в других местах, не брать имена, даты рождения, любимые группы и распространённые фразы вроде Iloveyou. Проверка: пилотная группа входит без обращений в поддержку, а после рассылки вы видите, сколько запросов на сброс поступило.

Приоритеты

Сегодня: шаги 1 и 4, как минимум для администраторов и почты руководителей. На этой неделе: шаги 2, 3 и 5. При плановом пересмотре регламента безопасности: шаг 6 для всех отделов, закрепление правил в регламенте и включение их во вводный инструктаж для новых сотрудников.

Как внедрить без сопротивления

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

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

Как проверить результат

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

Отдельно сравните количество обращений «забыл пароль» с предыдущим периодом. Если оно резко выросло, вероятно, памятка непонятна или кто-то не обновил контакты для восстановления. Повторяйте тест слабого пароля и сверку MFA раз в квартал, а также после каждого изменения лицензий или политик.

Типичные ошибки

Оставить принудительную смену паролей вместе с новыми требованиями. Люди отвечают на это предсказуемыми вариациями, и разнообразие, ради которого всё затевалось, исчезает.

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

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

Оставить общие учётные записи. NIST в SP 800-63B отмечает, что защита рассчитана на кражу учётных данных, а не на добровольную передачу пароля коллегам, и технически выявить такое почти невозможно. Для общих сервисов лучше создать личные входы.

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

Вывод

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