Политика управления доступом: шаблон и отключение устаревших протоколов аутентификации

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

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

Чем политика доступа отличается от соседних документов

Политика остаётся короткой, потому что подробности живут в соседних документах и ссылках на них. Слишком длинная политика не читается, а нечитаемая — не исполняется.

Структура политики на одну-две страницы

ПОЛИТИКА УПРАВЛЕНИЯ ДОСТУПОМ
Версия 1.0, утверждена [дата], пересмотр не реже раза в год

1. Цель и область
1.1. Политика определяет порядок предоставления, изменения, контроля и отзыва доступа
     к информационным системам, сетям и данным [компании].
1.2. Распространяется на работников, подрядчиков и иных лиц, получающих доступ.

2. Принципы
2.1. Минимальные привилегии: только то, что нужно для работы.
2.2. Личная ответственность: каждая учётная запись принадлежит одному человеку
     или одной системе; общие учётные записи запрещены.
2.3. Разделение обязанностей: тот, кто согласует доступ, не выдаёт его себе.
2.4. Ограничение по времени: временный доступ имеет дату окончания.

3. Роли и ответственность
3.1. Владелец системы определяет роли и утверждает состав доступа.
3.2. Руководитель работника подтверждает необходимость доступа.
3.3. Ответственный за ИБ согласует привилегированный доступ, доступ к ПДн,
     удалённый доступ и исключения.
3.4. Администратор выдаёт и отзывает доступ по согласованной заявке.
3.5. Ответственные за создание, изменение и удаление учётных записей
     назначены распоряжением (приложение 1).

4. Порядок предоставления доступа
4.1. Доступ выдаётся по заявке в [трекер или форму]. Устные просьбы не исполняются.
4.2. Перечень доступов, требующих согласования с ИБ, приведён в приложении 2.
4.3. Стандартные роли по должности выдаются без согласования ИБ.

5. Привилегированный доступ
5.1. Административные права выдаются отдельной учётной записью.
5.2. Для привилегированных записей и всех удалённых подключений обязателен второй фактор.
5.3. Реестр привилегированных записей ведёт ответственный за ИБ и пересматривает ежеквартально.

6. Изменение и отзыв доступа
6.1. При переводе лишний доступ снимается в течение [1] рабочего дня.
6.2. При увольнении учётные записи блокируются в день увольнения.
6.3. Неактивные более [90] дней записи блокируются.
6.4. Права пересматриваются ежеквартально владельцами систем.

7. Технические требования
7.1. Запрещены протоколы LM и NTLMv1, SMBv1, telnet и FTP без шифрования.
7.2. Подключение к системам управления — только из сегмента управления.
7.3. События входа и изменения прав записываются в журнал и хранятся [12] месяцев.

8. Исключения
8.1. Исключения оформляются письменно, имеют срок и согласуются с ответственным за ИБ.

9. Контроль и пересмотр
9.1. Соблюдение проверяет ответственный за ИБ не реже раза в квартал.
9.2. Политика пересматривается ежегодно.

Приложения (список ответственных, перечень доступов для согласования с ИБ) живут отдельными файлами, потому что меняются чаще самой политики. Числа в квадратных скобках — ориентиры, подставьте свои и убедитесь, что вы действительно способны их выполнять.

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

Политика требует отключить небезопасные протоколы, но подтверждением служит не пункт документа, а проверка, что они действительно отключены. Начните с поиска: что используется сейчас. Отключение «вслепую» ломает старые приложения, принтеры-сканеры и устаревшие устройства, и после этого политику перестают воспринимать всерьёз.

LM и NTLMv1

LM и NTLMv1 — старые способы проверки пароля в Windows. Хэши легко подбираются, а перехваченную аутентификацию можно переиграть. Современная настройка — разрешить только NTLMv2 и, где возможно, отказаться от NTLM в пользу Kerberos. Проверка текущего значения на узле:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel, NoLMHash -ErrorAction SilentlyContinue

Ожидаемо: LmCompatibilityLevel равен 5 (отправлять только ответ NTLMv2, отказывать LM и NTLM), NoLMHash равен 1. Если значения нет, действует значение по умолчанию системы, и оно может быть слабее. Прежде чем менять, выясните, кто использует NTLMv1. Для этого ищите в журнале безопасности события входа с признаком версии:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)} |
  ForEach-Object {
    $x = [xml]$_.ToXml(); $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    if ($d.LmPackageName -eq 'NTLM V1') {
      [pscustomobject]@{ Время = $_.TimeCreated; Пользователь = $d.TargetUserName; Узел = $d.WorkstationName; Адрес = $d.IpAddress }
    }
  } | Select-Object -First 50

Ожидаемо: пустой вывод или список узлов и учётных записей, которые всё ещё ходят по NTLMv1. Выполняйте на контроллерах домена, где такие события регистрируются, и с включённым аудитом входа. Каждую найденную пару «пользователь, узел» разберите: чаще всего это старое приложение, принтер с отправкой на почту или файловое хранилище. Исправьте источник (обновите, перенастройте) или оформите исключение с датой. Только затем задайте значение групповой политикой: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: LAN Manager authentication level со значением «Send NTLMv2 response only. Refuse LM & NTLM». Применяйте сначала на тестовом подразделении, затем волнами: GPO и Ansible.

SMBv1

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

Ожидаемо: EnableSMB1Protocol становится False. Перед отключением проверьте, какие устройства ещё работают по SMBv1: сканеры и МФУ старых моделей, NAS. Из сети проверка делается так (только по своим узлам): nmap -p445 --script smb-protocols 192.0.2.20; в выводе не должно быть версии SMBv1.

Telnet, FTP и другие протоколы без шифрования

sudo ss -tlnp | grep -E ':(21|23|513|514) '
dpkg -l | grep -E 'telnetd|rsh-server|vsftpd|proftpd'

Ожидаемо: пустой вывод. Если на узле слушает порт 23 или 21, найдите службу и отключите её, а не закрывайте только на экране: так сервис не вернётся при изменении правил. Для сетевого оборудования отключите telnet в настройках и оставьте SSH: сегмент администрирования. Подробнее об экране: nftables и firewalld.

LDAP без подписи

Ещё одна частая находка в домене: LDAP-запросы без обязательной подписи и привязки канала. На контроллерах домена задаётся в групповой политике: Domain controller: LDAP server signing requirements — «Require signing». Проверьте, кто обращается без подписи: события 2889 в журнале Directory Service показывают клиентов, которые используют небезопасные привязки. Сначала список, потом переключение.

Как согласуются доступы

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

Как ввести политику в действие

1. Согласуйте текст с ИТ-директором, руководителем кадров и владельцами критичных систем. Требования, которые они не смогут выполнить, лучше увидеть до подписи.
2. Утвердите приказом, зафиксируйте версию и дату.
3. Проведите короткий разбор для администраторов (30 минут) и соберите подписи об ознакомлении: ознакомление с правилами.
4. Через месяц проверьте по пунктам: для каждого найдите след (заявка, настройка, журнал). Где следа нет, исправьте практику или документ.

Какие артефакты хранить

Диагностика

Где это в модели зрелости

Материал относится к направлению «Управление доступом» (хаб: управление доступом, карта: карта зрелости). На втором уровне утверждена политика управления доступом с процессом согласования, а технические меры включают принудительное отключение небезопасных протоколов аутентификации и подключения. Здесь оба элемента: текст и проверка. Третий уровень добавляет регламентированные процессы и пересмотры: квартальный аудит прав.

Как проверить

1. Политика утверждена, версия и дата указаны, подписи согласующих есть.
2. Для заявки за последний месяц видны поля и согласования, как предписывает политика.
3. На контроллере домена LmCompatibilityLevel равен 5, SMBv1 отключён.
4. В поиске NTLMv1 за неделю нет событий либо для каждого есть исключение с датой.
5. На выборке серверов и сетевых устройств telnet и FTP не слушают.

Источники

• Microsoft Learn, уровни проверки подлинности LAN Manager: learn.microsoft.com.
• Microsoft Learn, отключение SMBv1: learn.microsoft.com.
• CIS Control 5, управление учётными записями, и Control 6, управление доступом: cisecurity.org/controls.
• NIST SP 800-53 Rev. 5, семейство «Контроль доступа» (AC): csrc.nist.gov.