Политика паролей должна усложнять возможность компрометации учетных записей, не делая при этом безопасное поведение излишне трудным. Лучшие политики — это те, которые ясны, практичны и соответствуют реальной рабочей практике сотрудников. Они поощряют использование длинных уникальных паролей, поддерживают менеджеры паролей, требуют многофакторную аутентификацию там, где это необходимо, и избавляются от устаревших правил, толкающих пользователей к предсказуемому поведению.
В этой статье разобраны рекомендации по современной политике паролей: что делать, чего избегать, лучшие практики, а также представлен шаблон, который вы можете адаптировать для своей организации.
Что такое политика паролей?
Политика паролей — это набор правил, который определяет, как создаются, хранятся, используются, передаются, изменяются и защищаются пароли. Она распространяется на сотрудников, подрядчиков, администраторов, служебные учетные записи, а иногда и на клиентов — в зависимости от охвата систем.
Хорошая политика паролей должна отвечать на практические вопросы:
- Какой должна быть длина паролей?
- Разрешены ли парольные фразы?
- Могут ли пользователи вставлять пароли из менеджера паролей?
- Когда нужно менять пароль?
- Требуется ли многофакторная аутентификация?
- Как обрабатываются общие (shared credentials) учетные данные?
- Что делать, если есть подозрение на компрометацию пароля?
Цель — не создать самый сложный набор правил. Цель — снизить реальный риск.
Что рекомендуется делать в современной политике паролей
Требовать достаточную длину
Длина — одна из самых эффективных защит от угадывания и перебора паролей. Один общий минимум по всей организации обычно проще для понимания сотрудников и для контроля со стороны ИТ, чем отдельные требования для пользователей и администраторов. На практике рекомендуется требовать минимальную длину в 16 символов для всех учетных записей пользователей. Дольше — лучше, особенно если используются менеджеры паролей или случайно-сгенерированные парольные фразы.
Разрешать длинные пароли и парольные фразы
Пользователям должно быть разрешено создавать пароли, значительно превышающие минимальную длину. Избегайте малых максимальных ограничений, например 16 или 20 символов. Разумный максимум — минимум 64 символа, и многие системы поддерживают больше.
Парольные фразы разрешены при условии, что они длинные и не основаны на известных цитатах, песнях, названиях компаний или других предсказуемых фразах. Например, парольная фраза из нескольких случайных слов, как правило, надежнее короткого пароля с искусственными заменами символов.
Добиваться уникальности паролей
У каждого аккаунта должен быть уникальный пароль. Повторное использование паролей — одна из главных причин, по которым компрометация одной службы приводит к захвату других учетных записей. Менеджеры паролей делают использование уникальных паролей реальным, ведь пользователям не нужно всё запоминать.
Поддерживать менеджеры паролей
Политика должна явно разрешать и поощрять использование утверждённых менеджеров паролей. Пользователям должно быть разрешено вставлять пароли в формы входа, использовать автозаполнение и генерировать случайные пароли. Блокировка вставки выглядит как защита, но на деле мешает использовать надежные менеджеры паролей.
Проверять пароли по спискам скомпрометированных паролей
Пароли должны отклоняться, если они встречаются в известных списках утечек, списках популярных паролей или в черных списках компании. Это гораздо эффективнее, чем требовать обязательного использования заглавных букв, цифр или спецсимволов.
Требовать MFA везде, где это технически возможно
Многофакторная аутентификация должна быть включена везде, где это возможно, особенно на аккаунтах администраторов, для удаленного доступа, облачных сервисов, электронной почты, менеджеров паролей, финансовых систем и других критичных ресурсов. MFA не заменяет сильные пароли, но снижает риски при утечке учетных данных.
Отдавайте предпочтение MFA, устойчивой к фишингу: passkeys, аппаратные ключи, встроенные платформенные аутентификаторы. Обычно приложения-аутентификаторы лучше, чем SMS. MFA через SMS запрещается, если возможен любой другой способ, потому что телефонные номера могут быть перехвачены, заменены через SIM-swapping, перенесены или скомпрометированы в ходе восстановления аккаунта.
Это не теория. В 2018 году Reddit публично сообщил, что злоумышленники перехватили SMS-сообщения для двухфакторной аутентификации и получили доступ к внутренним системам: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. В 2021 году Coinbase сообщил, что злоумышленники украли криптовалюту как минимум у 6 000 клиентов, воспользовавшись уязвимостью в процедуре восстановления через SMS: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
Менять пароли после признаков компрометации
Пароль должен быть изменен, если есть доказательства или обоснованные подозрения его компрометации. Примеры: фишинг, наличие вредоносного ПО на устройстве, утечка учетных данных, подозрительная активность входа или случайное раскрытие пароля.
Защищать общие учетные данные должным образом
Общие пароли должны избегаться там, где возможны персональные учетные записи. Если без совместного использования не обойтись, такие учетные данные должны храниться в утвержденном менеджере паролей, к ним должен ограничиваться доступ уполномоченными лицами, а сам факт доступа — по возможности логироваться.
Защищать процесс сброса пароля
Восстановление доступа — часто наиболее уязвимое место. Процессы сброса должны проверять личность пользователя, быстро аннулировать ссылки, использовать одноразовые токены и уведомлять пользователя при смене пароля.
Чего НЕ делать в современной политике паролей
Не требовать частую смену паролей без причины
Обязательная регулярная смена каждые 30, 60 или 90 дней обычно приводит к более слабым паролям. Пользователи делают небольшие предсказуемые замены, например, меняют одну цифру или сезон. NIST в своих Digital Identity Guidelines снял требование регулярной смены без оснований и предписывает менять пароль только при признаках компрометации. Смотрите раздел 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Требуйте замену пароля при подозрении на компрометацию, смене роли, восстановлении доступа или если пароль перестал соответствовать политике.
Не полагаться только на требования к сложности
Требования вроде "добавьте заглавную, строчную, цифру и символ" не гарантируют силу пароля. Password1! соответствует множеству подобных требований, но всё равно слабый. Делайте акцент на длине, уникальности, случайности и сравнении со списками компрометаций.
Не блокировать копирование и вставку паролей
Запрет вставки затрудняет использование менеджеров паролей. Это толкает людей к коротким, легко вводимым паролям. Разрешайте вставку и автозаполнение, если только нет специальной документированной причины для запрета.
Не разрешать подсказки к паролю
Подсказки часто раскрывают слишком много. Если пользователь может запомнить ответ по подсказке — злоумышленник, скорее всего, тоже сможет угадать. Вместо этого используйте безопасные процессы восстановления.
Не хранить пароли в открытом виде
Никогда не храните пароли в открытом виде или с обратимым шифрованием. Пароли должны хешироваться современным, медленным, присоленным алгоритмом для хеширования паролей: Argon2id, bcrypt, scrypt или PBKDF2 (в зависимости от системы и требований законодательства).
Быстрые стандартные хеши вроде MD5, SHA-1, SHA-256 или SHA-512 не подходят для хеширования паролей — они слишком быстрые, что облегчает перебор после утечки базы. Подробнее — об эволюции хеширования паролей.
Не передавать пароли через чат или email
Пароли нельзя отправлять по электронной почте, в чатах, тикетах, документах или скриншотах. Используйте менеджеры паролей с безопасной функцией передачи данных и управлением доступом.
Не использовать личную или предсказуемую информацию
В паролях не должно быть имен, дат рождения, названий организаций, паттернов на клавиатуре, повторяющихся символов и типичных замен вроде @ вместо a или 0 вместо o. Злоумышленники начинают именно с таких вариантов.
Лучшие практики для организаций
Установить ясные минимальные требования
Формулируйте требования просто и понятно:
- Одна минимальная длина, например 16 символов для всех пользователей
- Максимум не менее 64 символов
- Разрешение на пробелы и распространённые символы
- Разрешение на парольные фразы и менеджеры паролей
- Отклонение скомпрометированных и типовых паролей
Особый порядок для привилегированных аккаунтов
Аккаунты администраторов, сервисные и доступ к производственным средам должны контролироваться строже. Требуйте более сложные пароли, MFA, ограниченный доступ, ведите мониторинг и немедленно изменяйте пароли при смене доступа.
Доступ по ролям и принцип наименьших привилегий
Сильные пароли не заменяют избыточные права. Пользователи должны получать доступ только к тем системам и секретам, которые им нужны для работы.
Мониторинг подозрительной активности
Фиксируйте необычные схемы входа, "невозможные путешествия", повторные ошибки входа, попытки с незнакомых стран, доступ вне рабочих часов. Политику паролей должны поддерживать мониторинг и реагирование на инциденты.
Обучение пользователей реальным угрозам
Обучение должно быть про повторное использование паролей, фишинг, фейковые страницы входа, MFA-усталость, безопасную передачу паролей и процедуру сообщения о подозрениях. Не обвиняйте пользователей — сделайте безопасное поведение простым.
Делайте политику короткой и выполнимой
Политика должна быть понятной. Если правила слишком объемные, размытые или жесткие — их обойдут. Лучшие политики — те, которые можно реально внедрить и проконтролировать.
Шаблон политики паролей для копирования
Используйте этот шаблон как отправную точку. Отредактируйте элементы в квадратных скобках под свою организацию, системы, уровень риска и правовые требования.
Политика паролей
Версия: [1.0]
Владелец: [Отдел безопасности / ИТ]
Дата вступления в силу: [ГГГГ-ММ-ДД]
Период пересмотра: [Каждые 12 месяцев]
1. Цель
Данная политика определяет требования к созданию, использованию, хранению, обмену и изменению паролей в [Название организации]. Цель — снизить риск несанкционированного доступа, кражи учетных данных, захвата аккаунтов и потери данных.
2. Область применения
Политика распространяется на всех сотрудников, подрядчиков, временный персонал, поставщиков услуг и любых других пользователей, имеющих доступ к системам, приложениям, сетям, облачным сервисам или данным [Название организации].
Политика применима к обычным учетным записям, привилегированным, сервисным, общим и ко всем системам, где используются пароли для аутентификации.
3. Требования к созданию паролей
Все пароли должны соответствовать следующим требованиям:
- Аккаунты пользователей должны иметь пароли не короче 16 символов.
- Пароли должны быть уникальными и не использоваться повторно в рабочих или личных аккаунтах.
- В паролях нельзя использовать имена, логины, названия компаний, даты рождения, паттерны клавиатуры, повторяющиеся символы и другую легко угадываемую информацию.
- Пароли не должны быть основаны на известных фразах, цитатах, песнях или типовых заменах символов.
- Пароли не должны встречаться в известных утечках или списках популярных паролей.
- В паролях разрешены пробелы, символы, цифры, заглавные и строчные буквы.
- Парольные фразы разрешены, если они длинные, уникальные и не основаны на предсказуемых или публичных выражениях.
4. Менеджеры паролей
[Название организации] требует или настоятельно рекомендует использовать утвержденный менеджер паролей для создания, хранения и обмена паролями.
Пользователи могут использовать генератор паролей, автозаполнение и вставку из утвержденного менеджера. Запрещено хранить пароли в браузерах, таблицах, документах, заметках, электронной почте, чатах, скриншотах или неутвержденных инструментах.
5. Многофакторная аутентификация
Многофакторная аутентификация (MFA) должна быть включена везде, где это технически возможно, включая, но не ограничиваясь:
- Аккаунты электронной почты
- Системы удаленного доступа
- Менеджеры паролей
- Облачные сервисы
- Административные аккаунты
- Финансовые, кадровые и другие критически важные системы
- Любые системы, определенные как [конфиденциальные / критичные]
При наличии необходимо использовать MFA, устойчивую к фишингу: passkeys, аппаратные ключи или встроенные платформенные аутентификаторы. Приложения-аутентификаторы предпочтительнее SMS. MFA через SMS запрещена, если возможен другой способ, и разрешается только при техническом отсутствии лучшей альтернативы.
6. Изменения пароля
Пароль необходимо сменить немедленно, если:
- Стал известен или подозревается компрометация.
- Пользователь ввел пароль на подозрительном/фишинговом сайте.
- Пароль был передан неавторизованному лицу.
- На устройстве пользователя обнаружено вредоносное ПО или несанкционированный доступ.
- Пароль найден в известной утечке данных.
- Изменилась роль или статус пользователя с привилегиями.
- ИТ или служба безопасности требует смены пароля.
Регулярное истечение пароля не требуется, если того не требует законодательство, договор, или особенности системы. Пароли нельзя менять путем мелких и предсказуемых изменений от предыдущего пароля.
7. Совместное использование паролей
Пароли нельзя передавать через электронную почту, чат, тикеты, документы, скриншоты, телефонные или устные сообщения.
Общие (shared) учетные данные допускаются только, если персональные учетные записи технически невозможны или явно одобрены [Безопасностью / ИТ]. Утвержденные общие данные должны храниться и передаваться через утвержденный менеджер с доступом только для авторизованных пользователей.
8. Привилегированные аккаунты
Привилегированные аккаунты должны иметь уникальные пароли, не используемые для обычных пользователей. Привилегированные аккаунты должны использовать MFA по возможности, а также регулярно пересматриваться.
Пароли привилегированных аккаунтов должны меняться при увольнении администратора, смене его роли, необходимости ограничения доступа или при подозрении на компрометацию.
9. Сервисные аккаунты и секреты приложений
Пароли сервисных аккаунтов, API-ключи, токены и секреты приложений должны храниться в одобренной системе управления секретами или в утвержденном менеджере паролей.
Данные сервисных аккаунтов нельзя жестко прописывать в исходном коде, файлах конфигурации, образах, документации или скриптах, если только это не защищено утвержденным процессом управления секретами.
10. Сброс пароля и восстановление доступа
Сброс пароля должен подтверждать личность пользователя до восстановления доступа. Ссылки и временные пароли — одноразовые, быстро истекают и передаются только по утвержденным каналам.
Пользователь обязан получать уведомление о смене или сбросе пароля. Временный пароль должен быть изменен при первом входе.
11. Технические меры
Системы, хранящие или обрабатывающие пароли, должны:
- Никогда не хранить пароли в открытом виде.
- Хешировать пароли с помощью утвержденного современного алгоритма с солью: PBKDF2, scrypt, bcrypt или Argon2.
- Не использовать MD5, SHA-1, SHA-256, SHA-512 и другие быстрые хеши стандартного назначения для хранения паролей.
- Ограничивать попытки аутентификации (rate limiting) или применять эквивалентные меры защиты.
- Отклонять наиболее распространённые, слабые и скомпрометированные пароли.
- Позволять вставку паролей из менеджеров паролей.
- Поддерживать разумную длину пароля, в том числе минимум 64 символа при технической возможности.
- Логировать события, связанные с безопасностью аутентификации.
12. Сообщение о подозрении на компрометацию
Пользователь обязан немедленно сообщить о подозрении на компрометацию пароля, фишинговой атаке, необычном окне входа, MFA, которое не инициировал, или неумышленном раскрытии пароля в [Контакт безопасности / ИТ].
13. Исключения
Исключения из данной политики фиксируются, оцениваются по рискам, ограничиваются по времени и утверждаются [Руководством по безопасности / ИТ]. Следует применять компенсирующие меры при наличии возможности.
14. Принудительное исполнение
Несоблюдение политики может привести к удалению доступа, обязательному обучению безопасности, дисциплинарным мероприятиям или иным мерам согласно политике [Название организации] и действующему законодательству.
15. Пересмотр
Политика пересматривается как минимум раз в год либо после значимых изменений в системах, угрозах, требованиях законодательства или бизнес-процессах.
Заключение
Сильная политика паролей не в том, чтобы усложнить жизнь пользователям. Она в устранении слабых привычек, поддержке менеджеров паролей, использовании MFA и быстрой реакции на утечку учетных данных. Держите политику практичной, выполнимой и ориентированной на реальные угрозы: фишинг, подбор паролей (credential stuffing), повторное использование паролей и компрометацию аккаунтов.
