«Политика паролей, это не про красивые заголовки и длинные документы, которые никто не читает. Это про один единственный принцип: сколько стоит сломать ваш самый слабый пароль? Если вы считаете, что это вопрос для вашего отдела безопасности, вы ошибаетесь. Это вопрос для каждого, кто включает компьютер утром.»
Создание политики паролей (password policy) — задача, которая кажется рутинной и бюрократической. Многие компании берут готовый шаблон из интернета или копируют требования стандарта без понимания, зачем они нужны. В итоге получается документ, который либо слишком жёсткий и парализует работу, либо настолько мягкий, что не обеспечивает никакой защиты.
Настоящая политика паролей должна быть практичной, понятной и технически выверенной. Она не ограничивается требованиями к длине и сложности, а становится частью культуры информационной безопасности в компании.
От требований к сценариям: зачем вообще нужна политика паролей?
Часто политику паролей воспринимают как список запретов: нельзя использовать простые последовательности, нельзя повторять пароли. Но её цель — не усложнить жизнь пользователям, а затруднить работу злоумышленникам.
Основные сценарии атак, от которых защищает грамотная политика:
- Брутфорс (перебор): атака, при которой злоумышленник автоматически перебирает пароли из словаря или по определённому алгоритму. Современные видеокарты позволяют перебирать миллионы комбинаций в секунду. Слабая политика делает такую атаку успешной за минуты.
- Использование утекших данных (credential stuffing): люди повторяют пароли на разных сервисах. Если база логинов и паролей из какой-либо соцсети утекает в открытый доступ, злоумышленники автоматически проверяют эти связки на корпоративных порталах, банковских сайтах и в облачных сервисах. Политика должна предотвратить использование таких компрометированных данных.
- Социальная инженерия: простые пароли, связанные с личностью (дата рождения, имя ребёнка), легко угадать или узнать из открытых источников.
Поэтому политика, это не абстрактный документ, а технический барьер. Её эффективность можно измерить: например, оценить, сколько времени и вычислительных мощностей потребуется для взлома пароля, созданного по вашим правилам.
Ядро политики: обязательные и спорные требования
Давайте разберём по пунктам, какие требования действительно важны, а какие устарели или создают ложное чувство безопасности.
Длина пароля
Минимум 12 символов. Это аксиома. Всё, что короче, уже не соответствует современным вызовам. Длина — главный фактор, увеличивающий время перебора. Каждый дополнительный символ экспоненциально увеличивает количество возможных комбинаций. Для критичных систем (административные учётные записи, доступ к финансовым данным) стоит рассмотреть увеличение до 14-16 символов.
Сложность (использование разных типов символов)
Требование использовать заглавные буквы, цифры и специальные символы (!, @, #, $) — классика. Однако его эффективность переоценена. Пользователи часто следуют шаблону: Пароль123!. Это предсказуемо и легко учитывается в модифицированных словарях для брутфорса.
Более важно запретить очевидные и слабые комбинации:
- Последовательности клавиатуры:
qwerty,123456,1qaz2wsx. - Слова из словаря любого языка.
- Повторяющиеся символы:
aaaaaa,111111. - Информацию, связанную с пользователем или компанией (название компании, бренда, имена сотрудников).
Технически это реализуется через проверку пароля по словарям и регулярным выражениям при его установке.
История паролей и периодичность смены
Требование «менять пароль каждые 90 дней» — одно из самых спорных. Исследования показывают, что оно приводит к обратному эффекту:
- Пользователи начинают использовать шаблоны:
ПарольЛето2024!,ПарольОсень2024!. - Записывают пароли на стикерах или в незащищённых файлах.
- Слегка меняют старый пароль (добавляют цифру в конец), что сводит на нет смысл смены.
Более разумный подход — отказ от обязательной периодической смены для рядовых пользователей. Пароль нужно менять только при подозрении на компрометацию. Для административных учётных записей сроки можно сохранить, но увеличить интервал (например, до 180 дней) и сочетать с многофакторной аутентификацией (MFA).
История паролей (запрет на повторение последних 5-10 паролей) остаётся полезной, но её следует настраивать с умом, чтобы не вызывать раздражение.
Инструменты и проверки: что можно автоматизировать
Хорошая политика не должна ложиться на плечи пользователя. Её основные положения должны быть внедрены и контролироваться технически.
- Проверка на утечку: при смене или создании пароля система должна проверять его хеш (или его часть) по открытым базам утекших данных (Have I Been Pwned). Если пароль найден в утечке, система должна заблокировать его установку.
- Проверка по словарям: встроенная проверка не только на общеизвестные слабые пароли, но и на внутренние корпоративные термины, имена сотрудников из Active Directory.
- Инструменты для пользователей: вместо требования «придумайте сложный пароль» предложите сотрудникам менеджеры паролей (KeePass, Bitwarden). Эти инструменты не только генерируют и хранят криптостойкие пароли, но и позволяют не запоминать их. Корпоративная лицензия такого менеджера — инвестиция в безопасность.
Человеческий фактор: обучение и формулировки
Политика, написанная языком стандартов, будет проигнорирована. Важно донести её суть.
Вместо сухого пункта «Запрещено использование паролей, состоящих из повторяющихся символов», лучше написать: «Пароль 111111aaaaaa будет отклонён системой. Такой пароль может быть взломан за секунды». Объясняйте не только «что нельзя», но и «почему», а также «как сделать правильно».
Пример хорошей и плохой формулировки:
| Плохо | Хорошо |
|---|---|
| Пользователь обязан соблюдать требования к сложности пароля. | Система не примет пароль короче 12 символов или пароль, который есть в списках самых популярных (например, password или qwerty). Чтобы создать надёжный пароль, который не нужно запоминать, используйте корпоративный менеджер паролей. |
| Запрещено записывать пароли на бумажных носителях. | Пароль, записанный на стикере под клавиатурой, доступен любому, кто зайдёт в кабинет. Если сложно запомнить все пароли, это признак того, что пора начать использовать менеджер паролей. |
Регулярное обучение (короткие видеоролики, тесты) должно закреплять эти принципы, а не просто информировать о существовании документа.
Адаптация под разные роли: не всем подходит одно правило
Единая политика для всех — грубая ошибка. Учётная запись рядового сотрудника и учётная запись администратора домена или финансового директора имеют разный уровень риска.
Базовая политика (для всех сотрудников): минимальная длина 12 символов, проверка на утечки и словари, рекомендация использовать менеджер паролей, отмена обязательной ежеквартальной смены.
Усиленная политика (для привилегированных учётных записей):
- Минимальная длина 14-16 символов.
- Обязательное использование многофакторной аутентификации (MFA) везде, где это возможно.
- Более строгая история паролей (запрет на повторение последних 15 паролей).
- Обязательная периодическая смена (раз в 120-180 дней) в сочетании с MFA.
- Ограничение входа по IP-адресам или с определённых рабочих станций.
Политика для сервисных аккаунтов (service accounts): эти учётные записи используются программами и скриптами для взаимодействия между системами. Здесь обычная политика с частой сменой пароля не работает. Вместо этого:
- Использовать сверхдлинные (25+ символов) криптографически сгенерированные пароли, хранящиеся в специальных хранилищах секретов (HashiCorp Vault, CyberArk).
- По возможности отказываться от паролей в пользу аутентификации на основе сертификатов или ключей.
- Регулярно (но реже) менять пароли с помощью автоматизированных процессов, не требующих участия человека.
Соответствие регуляторным требованиям
В российском контексте ключевым документом является 152-ФЗ «О персональных данных». Хотя в нём нет детальных предписаний по составу пароля, он обязывает оператора принимать «необходимые организационные и технические меры» для защиты информации. Наличие задокументированной и технически реализованной политики паролей — часть этих мер.
Требования ФСТЭК России, в частности, руководящие документы (РД) и приказы, могут содержать более конкретные указания, например, минимальную длину пароля для систем определённого класса защищённости. При разработке политики необходимо сверяться с актуальными версиями этих документов.
простое копирование требований из стандарта без адаптации к реальным бизнес-процессам и техническим возможностям компании не обеспечит безопасность и может быть формально правильно, но практически бесполезно.
Практический чек-лист для составления политики
- Определите зоны риска: разделите всех пользователей и системы на категории (обычные сотрудники, администраторы, сервисные аккаунты, внешние пользователи).
- Установите базовые технические требования:
- Минимальная длина: 12 символов (для привилегированных — 14+).
- Запрет паролей из открытых словарей и утечек.
- Запрет очевидных последовательностей и личной информации.
- Решите вопрос со сменой паролей: откажитесь от обязательной частой смены для рядовых пользователей. Для критичных ролей установите увеличенный срок (120-180 дней) и обязательно добавьте MFA.
- Внедрите технические средства контроля:
- Настройте проверку паролей при установке (словари, утечки).
- Рассмотрите внедрение корпоративного менеджера паролей.
- Для администраторов и сервисных учётных записей внедрите хранилища секретов и MFA.
- Напишите документ понятным языком: разделите его на части для технических специалистов (требования к системам) и для конечных пользователей (понятные инструкции и объяснения).
- Обучите сотрудников: проведите обучение, которое объясняет не правила, а причины их существования и риски их нарушения.
- Настройте аудит и мониторинг: отслеживайте неудачные попытки входа, попытки подбора паролей. Периодически проводите проверки на соблюдение политики.
Итоговая политика не должна быть длинным документом, который пылится на полке. Это живой набор технических настроек, понятных правил и инструментов, которые работают на вас каждый день, делая вход злоумышленника в вашу систему слишком дорогим и сложным мероприятием.