“Механизмы идентификации и аутентификации не просто фиксируют, кто и откуда пришёл, — они задают границы доверия в системе. Всё остальное — журналы, шифрование, разграничение прав — строится поверх этого фундамента.”
Таблица мер по уровням защищённости
Требования к идентификации и аутентификации (ИАФ) дифференцированы в зависимости от уровня защищённости (УЗ) обрабатываемых персональных данных, определённого по модели угроз. Для базового уровня (УЗ-4) достаточно контроля за доступом сотрудников, а высокие уровни (УЗ-1, УЗ-2) требуют защиты по принципу «нулевого доверия», включая устройства и внешних пользователей.
| Мера защиты | УЗ-4 | УЗ-3 | УЗ-2 | УЗ-1 |
|---|---|---|---|---|
| ИАФ.1: Сотрудники оператора | ✓ | ✓ | ✓ | ✓ |
| ИАФ.2: Устройства (рабочие станции, серверы) | ✗ | ✗ | ✓ | ✓ |
| ИАФ.3: Управление идентификаторами (учётными записями) | ✓ | ✓ | ✓ | ✓ |
| ИАФ.4: Управление средствами аутентификации (паролями, токенами) | ✓ | ✓ | ✓ | ✓ |
| ИАФ.5: Защита обратной связи при вводе аутентификационных данных | ✓ | ✓ | ✓ | ✓ |
| ИАФ.6: Внешние пользователи (клиенты, партнёры) | ✓ | ✓ | ✓ | ✓ |
ИАФ.2 обязательна только для УЗ-1 и УЗ-2, так как модели угроз для этих уровней предполагают высокие риски компрометации через несанкционированное подключение устройств к инфраструктуре.
Детальный разбор мер защиты
Требования каждой меры ИАФ в реальных проектах выходят за рамки простого включения галочек в таблице. Их реализация затрагивает архитектуру системы, процессы управления и технические детали.
ИАФ.1 — Сотрудники оператора
Уникальный идентификатор (логин) и надёжное средство аутентификации — основа для всех последующих мер контроля доступа. Процесс делится на два этапа:
- Идентификация: Субъект (сотрудник) предъявляет системе свой идентификатор, заявляя, кто он такой. Пример: ввод логина или предъявление смарт-карты.
- Аутентификация: Система проверяет, соответствует ли заявленная идентичность действительности, используя один или несколько факторов — знание (пароль), владение (токен), свойство (отпечаток пальца).
Для УЗ-3 и выше требуется как минимум двухфакторная аутентификация (2FA). Групповые и общие учётные записи строго запрещены.
ИАФ.2 — Идентификация и аутентификация устройств
Любое устройство, подключаемое к информационной системе, должно быть легитимным участником. Это предотвращает доступ с потерянного ноутбука или подключение вредоносного устройства к корпоративной сети. Основные методы:
- MAC-адресация и контроль портов (NAC): Базовый метод, уязвимый для подмены MAC-адреса.
- Аутентификация по сертификатам (802.1X/EAP-TLS): «Золотой стандарт». Устройство доказывает свою подлинность, предъявляя клиентский сертификат, подписанный доверенным центром сертификации.
- Аппаратные идентификаторы (TPM, токены): Используется встроенный криптопроцессор для безопасного хранения ключей и проведения операций.
Для российских систем с УЗ-1/2 сертификаты должны выпускаться с использованием отечественных криптоалгоритмов (ГОСТ Р 34.10-2012) через интегрированные с Active Directory решения, такие как КриптоПро CSP.
ИАФ.3 — Управление идентификаторами
Это жизненный цикл учётной записи: создание, активация, обслуживание (смена ролей) и обязательное своевременное удаление при увольнении сотрудника или выводе устройства из эксплуатации. Автоматизация этих процессов через системы управления идентификацией (IdM) типа Microsoft Identity Manager или Oracle Identity Governance критически важна для предотвращения «зомби-аккаунтов».
ИАФ.4 — Управление средствами аутентификации
Касается защиты самих секретов — паролей, закрытых ключей, seed-фраз для TOTP. Пароли должны храниться только в виде криптографических хэшей с использованием стойких алгоритмов (bcrypt, Argon2). Смена паролей по графику — устаревшая практика; современные рекомендации (NIST) предписывают менять пароль только при подозрении на компрометацию, но усиливать его сложность и требовать многофакторную аутентификацию.
ИАФ.5 — Защита обратной связи
Система никогда не должна уточнять, что именно введено неверно: логин или пароль. Сообщение должно быть универсальным: «Неверные учётные данные». Это защищает от атак перебора по списку логинов и анализа времени отклика, который может косвенно подтвердить существование учётной записи.
ИАФ.6 — Внешние пользователи
Клиенты, партнёры, контрагенты проходят через те же принципы, но часто в иной технической реализации. Используются внешние порталы с аутентификацией через SMS, мобильные приложения или одноразовые пароли (TOTP). Для высоких УЗ подключаются российские решения для квалифицированной электронной подписи или аппаратные токены.
Практическая реализация для разных УЗ
Реализация требований ИАФ напрямую зависит от присвоенного уровня защищённости.
УЗ-4 (Базовый)
- Уникальные логины и пароли для каждого сотрудника.
- Минимальная длина пароля — 8 символов.
- Блокировка учётной записи после 5 неудачных попыток входа.
- Политика регулярной смены паролей (обычно каждые 60-90 дней).
- Запрет на использование учётных записей по умолчанию (admin, root).
УЗ-3 (Повышенный)
- Всё для УЗ-4, плюс обязательная двухфакторная аутентификация для привилегированных учётных записей.
- Минимальная длина пароля увеличивается до 12 символов с обязательным использованием разных категорий символов.
- Внедрение системы управления идентификацией для автоматизации жизненного цикла учётных записей.
- Обязательное журналирование всех успешных и неуспешных попыток аутентификации.
УЗ-2/1 (Высокий и очень высокий)
- Строгая многофакторная аутентификация для всех пользователей с использованием российских СКЗИ (аппаратные токены типа JaCarta/Rutoken, биометрия).
- Обязательная идентификация и аутентификация всех устройств в сети (по сертификатам ГОСТ).
- Короткие сроки действия сессий (15-30 минут) с обязательной повторной аутентификацией.
- Шифрование трафика аутентификации с использованием российских алгоритмов.
- Интеграция событий аутентификации в систему SIEM для мониторинга аномалий.
# Пример конфигурации политики паролей в GPO для УЗ-1 Политика паролей: Минимальная длина: 12 Требования к сложности: включено Минимальный срок действия пароля: 1 день Максимальный срок действия пароля: 60 дней Вести историю паролей: 24 пароля Хранить пароли с обратимым шифрованием: отключено Политика блокировки: Порог блокировки: 5 неудачных попыток Длительность блокировки: 30 минут Сброс счётчика блокировки: через 30 минут
Ключевое требование ФСТЭК для всех уровней — необратимое хранение паролей. Пароли должны хэшироваться с использованием криптостойких алгоритмов и «соли» для защиты от атак по радужным таблицам.
Рекомендации по внедрению и типичные ошибки
Начинать нужно не с закупки дорогостоящих токенов, а с аудита. Составьте полный реестр всех учётных записей (пользователей, служб, устройств), определите их владельцев и критичность. Сверьте текущие политики паролей с требованиями нужного УЗ.
Ошибки, сводящие эффективность ИАФ к нулю:
- «Мёртвые души»: Неотозванные учётные записи уволившихся сотрудников — главный источник инцидентов.
- Слабая энтропия паролей: Политика «8 символов, без требований к сложности» взламывается перебором за часы.
- Отсутствие контроля за привилегированными учётными записями: Общий административный доступ или хранение паролей в незашифрованных файлах.
- Прозрачная обратная связь: Сообщения «пользователь не найден» или «неверный пароль» помогают злоумышленнику.
- Игнорирование аутентификации устройств: Особенно критично для УЗ-1/2, где несанкционированное устройство в сети может стать плацдармом для атаки.
Внедрение начинается с регламентов: создайте документ, описывающий процессы выдачи, изменения, блокировки и удаления учётных записей. Затем автоматизируйте эти процессы средствами Active Directory, IdM-систем или скриптов. Только после наведения порядка с процессами имеет смысл внедрять технически сложные решения вроде PKI-инфраструктуры на ГОСТах или аппаратных токенов.
ИАФ как системообразующий элемент
Механизмы идентификации и аутентификации — это не отдельный модуль, а фундаментальный слой безопасности. Он определяет, кто или что может быть доверенным субъектом в системе. Без чёткого ответа на этот вопрос все последующие меры — разграничение прав, аудит, шифрование — теряют смысл, так как непонятно, кого именно они контролируют и защищают. Корректно реализованная ИАФ создаёт основу для моделей контроля доступа (RBAC, ABAC), обеспечивает надёжную атрибуцию событий в журналах аудита и позволяет строить архитектуру безопасности от доверенной идентичности, а не от периметра.