Защита аутентификации в организации: пароли, роли и второй фактор

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

Для чего нужна парольная политика

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

Политика помогает установить единый минимум и распределить ответственность. Она отвечает на вопросы:

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

Какие учетные записи нужно разделить

Одни правила не подходят всем.

Пользовательские учетные записи принадлежат конкретным сотрудникам. Для них важны понятные требования, самостоятельная смена пароля и безопасное восстановление доступа.

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

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

Учетные записи подрядчиков должны иметь ограниченный срок действия и только те права, которые нужны для задачи.

Основные требования к паролям

Длина

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

Блок-лист

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

Правила состава

Обязательное сочетание прописных и строчных букв, цифр и специальных символов часто приводит к предсказуемым паролям вроде Password1!. NIST указывает, что польза жестких правил состава ограничена, а нагрузка на пользователей высока. Полный текст рекомендаций: NIST SP 800-63B-4.

Повторное использование

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

Хранение

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

Нужна ли регулярная смена пароля

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

Пароль точно нужно заменить, если:

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

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

Многофакторная аутентификация

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

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

Защита от подбора

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

В политике нужно закрепить:

• допустимое число ошибок;
• продолжительность блокировки или задержки;
• порядок разблокировки;
• события, о которых получает уведомление ИБ;
• исключения для сервисных процессов.

Пример структуры парольной политики

Документ можно построить так:

• Цель и область действия.
• Термины и типы учетных записей.
• Роли и ответственность.
• Требования к длине, блок-листу и повторному использованию.
• Правила хранения и передачи секретов.
• Требования к многофакторной аутентификации.
• Создание, изменение и удаление учетных записей.
• Восстановление доступа.
• Действия при компрометации.
• Контроль соблюдения и порядок пересмотра.

Конкретные числа и настройки нужно вынести в приложение или технический стандарт. Тогда ИТ-команда обновит параметры без полного пересмотра организационной политики.

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

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

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

Коротко о важном

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

Попробовать бесплатно

FAQ