Парольная политика в инфраструктуре: требования ФСТЭК, AD и реализация в UserGate

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

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

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

Требования к идентификации и управлению доступом закреплены в нормативных документах, которые регулируют защиту персональных данных и инфраструктуры:

• Закон №152-ФЗ о персональных данных.
• Приказ ФСТЭК № 21 — требования к идентификации пользователей, блокировке после ошибок входа и регистрации действий.
• Постановление Правительства РФ № 1119 — уровни защищённости и необходимость контроля доступа
• Приказ ФСТЭК № 239 — если инфраструктура относится к КИИ.
• ГОСТ Р 57580 — для финансовых организаций.

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

Регуляторы не задают конкретную длину пароля. Они проверяют, работает ли система идентификации в целом:

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

Если парольная политика настроена только в домене, но шлюз не сопоставляет пользователя с трафиком и не фиксирует его действия, идентификация считается реализованной частично.

Система управления паролями: связка AD, UserGate и журналов событий

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

Три уровня контроля доступа пользователей

Рабочая схема строится на интеграции трёх компонентов.

Каталог учётных записей (Active Directory / LDAP).
Каталог хранит пользователей и группы и задаёт параметры паролей: длину, сложность, срок действия, запрет повторов и блокировку после ошибок входа. На проверке смотрят именно эти настройки и аудит входов на контроллерах домена. Если блокировка отключена или пароль можно бесконечно менять, требования не выполнены.

Шлюз безопасности и точка аутентификации (UserGate NGFW).
UserGate принимает подключение пользователей, аутентифицирует их через AD/LDAP и сопоставляет сетевые сессии с учётными записями. На этом этапе подключают второй фактор и ограничения по источникам доступа. Доступ к сегментам сети выдают группам пользователей, а не подсетям. В журналах фиксируется имя учётной записи и применённое правило.

Регистрация событий безопасности.
События входов, отказов и действий пользователей передаются в централизованное хранилище журналов: Log Analyzer, SIEM или syslog-сервер. Архив нужен для расследований и подтверждения требований к регистрации событий.

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

При подключении по VPN шлюз должен связать сетевую сессию с учётной записью AD и применить правила доступа по группам.

В схеме участвуют три функциональных компонента:

• AD/LDAP — хранит пользователей и группы, отвечает на запросы каталога.
• UserGate — одно устройство, которое выполняет две функции: VPN-концентратор и межсетевой экран. Принимает подключение, аутентифицирует пользователя, применяет сетевые правила и пишет логи.
• Хранилище журналов — Log Analyzer UserGate, SIEM или syslog-сервер. Держит события столько, сколько требуют регламент и аудит.

Для проверяющего важны два результата:

• доступ к сегменту ИСПДн выдаётся группам, а не любому VPN-клиенту;
• в журналах видно имя пользователя и применённое правило, а не только IP-адрес.

Шаг 1. Подготовка AD: группы доступа и политика паролей в домене

1. Выделите группы доступа

Не используйте общие группы вроде Domain Users. Создайте отдельные группы под задачи:

• ISPDN_Users — доступ к приложениям и сервисам ИСПДн
• ISPDN_Admins — административный доступ
• VPN_Allowed — право подключаться к VPN
• при необходимости — группы по сервисам: ISPDN_App1_Users, ISPDN_DB_ReadOnly

Так разделяют два уровня: право подключиться к VPN и право работать с ИСПДн. Это базовый принцип разграничения.

2. Определите способ получения групп

UserGate может получить членство в группах двумя способами:

• при аутентификации через LDAP/AD шлюз выполняет LDAP-запрос и получает список групп сразу;
• через UserID/SSO-механизм шлюз сопоставляет пользователя с сессией и подтягивает группы из AD.

Для VPN обычно применяют первый вариант: аутентификация в AD → получение групп → применение правил.
В инфраструктурах с централизованной аутентификацией возможен вариант RADIUS + AD.

3. Проверьте базовые условия

Перед настройкой убедитесь:

• DNS корректно разрешает доменные имена;
• время синхронизировано между AD, UserGate и клиентами (NTP);
• при использовании LDAPS настроено доверие к сертификату контроллера домена.

Синхронизация времени нужна для Kerberos-сценариев и корректной корреляции событий в журналах.

Шаг 2. Аутентификация VPN через AD и MFA в UserGate

Критичный принцип: VPN-сессия должна быть привязана к учётной записи. Без этого правила по пользователям работать не будут.

1. Подключите каталог

На UserGate настраивают источник пользователей:

• LDAP/AD-коннектор (обычно LDAPS);
• сервисную учётку с правом чтения пользователей и групп.

После подключения проверьте:

• шлюз находит пользователя по логину;
• шлюз видит его членство в группах.

Если группы не подтягиваются, разграничение доступа по пользователям не заработает.

2. Настройте VPN-профиль

В параметрах VPN указывают:

• источник аутентификации: LDAP/AD или RADIUS;
• допуск к VPN только для группы VPN_Allowed.

Так ограничивают сам факт подключения.

3. Используйте MFA при удалённом доступе

Удалённый доступ к ИСПДн без второго фактора повышает риск компрометации.
Модель угроз часто требует MFA для VPN. Реализация зависит от принятой схемы: встроенный механизм, RADIUS-сервер или внешний сервис.

Шаг 3. Разделите зоны и маршруты

Типичная ошибка — VPN-клиент получает доступ ко всей сети.

Настройте дисциплину:

• отдельная зона VPN;
• отдельная зона ИСПДн;
• доступ между зонами только через правила NGFW;
• проверенные маршруты без обходных путей.

Отдельно проверьте NAT.
Маскарадинг VPN-клиентов в один адрес допустим, но правила доступа должны строиться по пользователям. Если правила строятся только по IP, в логах потеряется связь между трафиком и учётной записью.

Шаг 4. Настройте правила по группам AD

Правила применяются к пользователям только при корректной идентификации сессии. После аутентификации UserGate сопоставляет трафик с учётной записью и группами.

1. Разрешающие правила

Пример:

• источник: зона VPN
• пользователь/группа: ISPDN_Users
• назначение: сервер или подсеть ИСПДн
• сервис: конкретные порты
• действие: allow
• логирование: включено

Так доступ получают только нужные сотрудники.

2. Запрет по умолчанию

После разрешающих правил добавляют deny:

• источник: зона VPN
• назначение: зона ИСПДн
• пользователь: any
• действие: deny
• логирование: включено

Разрешено только явно заданное.

3. Доступ к управлению шлюзом

Управляющий интерфейс:

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

Этот пункт всегда проверяют.

Шаг 5. Настройте журналирование

Нужны два типа журналов:

Логи VPN	Логи межсетевых правил
учётная запись; время входа; IP-адрес клиента; результат; фактор аутентификации.	источник и назначение; сервис; имя правила; пользователь; действие.

Логи хранятся в Log Analyzer UserGate, SIEM, на syslog-сервере.

Локальное хранение на шлюзе используют как буфер. Для аудита требуется централизованное хранилище.

Сохраняйте историю за проверяемый период и включите логирование в правилах.

Шаг 6. Контрольные проверки администратора

1. Шлюз сопоставляет трафик с пользователем

Проверка:

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

Если отображается только IP, идентификация не работает.

2. Журналы фиксируют вход и действия

Должны быть:

• событие входа в VPN;
• событие доступа к сервису ИСПДн;
• событие отказа при попытке лишнего доступа.

Время и логин должны совпадать.

3. Доступ открыт только нужным группам

Проверка:

• учётка из ISPDN_Users получает доступ;
• учётка из VPN_Allowed без этой группы — нет;
• в журнале видно правило и причину отказа.

Почему аудит требует имя пользователя в логах

IP-адрес в VPN динамический. По нему нельзя доказать, кто именно работал с ИСПДн.
Регулятор требует идентифицировать субъекта доступа.

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

Аудит учетных записей и контроль доступа после изменений

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

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

Связность между сегментами

После изменений убедитесь, что правила не расширили доступ к зонам ИСПДн. Проверьте порядок правил, маршруты и NAT. Одно широкое разрешение или неверно указанная зона может открыть доступ между сегментами, даже если политика задумывалась как ограничивающая.

Идентификация пользователя на шлюзе

Шлюз должен получать учётную запись из AD или LDAP и применять правила по группам. В мониторинге сессий и журналах должно отображаться имя пользователя. Если после изменений снова видны только IP-адреса, контроль доступа считается неполным.

Фиксация входов и действий

Проверьте журналы шлюза и системы аутентификации. В них должны появляться события входов пользователей, административных сессий, разрешённых соединений и отказов. События должны передаваться в централизованное хранилище — Log Analyzer, SIEM или syslog-сервер — и храниться установленный срок.

Работа блокировок и MFA

Проверьте блокировку учётных записей после ошибок входа и параметры политики паролей в каталоге. Убедитесь, что второй фактор применяется при каждом подключении по VPN и для административного доступа к шлюзу. Временные исключения и «вечные» сервисные пароли после работ должны быть возвращены в нормальный режим.

Привязка профилей безопасности к правилам

IPS, антивирус и другие профили должны быть подключены к тем разрешающим правилам, через которые идёт доступ к сегментам ИСПДн. Если профиль не привязан к правилу, трафик проходит без проверки.

Целостность базовых сервисов

Проверьте синхронизацию времени, DNS и доступность каталога. Рассинхронизация времени ломает Kerberos-аутентификацию и искажает журналы событий. Потеря связи с AD/LDAP приводит к отказам входа и к тому, что правила по группам перестают применяться.

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

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

Общие учётные записи администраторов

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

Отключённая блокировка после ошибок входа

Порог блокировки учётной записи в домене, VPN или RADIUS временно снимают на время работ и забывают вернуть. Учётная запись остаётся без защиты от перебора. Механизм блокировки проверяют после любых изменений политики доступа.

Шлюз не сопоставляет трафик с пользователем из AD

Пользователь подключается по VPN или работает в домене, но межсетевой экран видит только IP-адрес. Правила применяются к подсетям, а не к группам. В журналах нет имён пользователей, поэтому нельзя подтвердить, кто подключался к системам с ПДн. После изменений схемы аутентификации или зон проверяют, что UserGate получает учётную запись и группы и применяет user-based правила.

Недостаточный срок хранения журналов

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

MFA включена частично

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

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

Политика паролей в организации: что должно быть настроено в AD и UserGate

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

Разграничение доступа выполняют по группам пользователей. На шлюзе безопасности правила строят на основе доменных групп, а не подсетей. Тогда доступ к сегментам автоматически закрывается при изменении учётной записи или увольнении сотрудника. Если в правилах указаны только IP-адреса, привязка к пользователю теряется, а контроль доступа становится формальным.

Журналирование фиксирует входы пользователей, административные действия и обращения к защищённым сегментам. Шлюз записывает события локально и передаёт их во внешнюю систему хранения: Log Analyzer, SIEM или syslog-сервер. Без централизованного архива невозможно подтвердить, кто подключался и какие действия выполнял. После изменений конфигурации проверяют срок хранения и полноту записей.

Точка входа пользователей должна проверять учётную запись до доступа в сеть. Речь идёт о VPN, доменной аутентификации или порталах доступа. После успешной проверки шлюз сопоставляет трафик с пользователем и его группами. Если шлюз видит только IP-адрес, правила применяются к подсетям, а не к людям.

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

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

Главное

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

Связка AD, UserGate и журналов событий формирует систему управления паролями.
Каталог учётных записей хранит пользователей и параметры паролей, UserGate сопоставляет трафик с конкретными людьми и применяет правила по группам, а журналы фиксируют действия. Без этой связки в логах остаются только IP-адреса, а контроль пользователей не подтверждается.

MFA усиливает парольную политику там, где есть удалённый доступ и администрирование.

Второй фактор должен работать для VPN и администраторов. Частичное включение MFA оставляет инфраструктуру защищённой только паролем.

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

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

Эта схема настраивается через LDAP-интеграцию, VPN-доступ и MFA в UserGate. На бесплатном курсе по внедрению UserGate разбираем практическую настройку инфраструктуры, чтобы требования ФСТЭК и аудита ИСПДн выполнялись в рабочей среде: