Уровни администрирования и SoD: разделение учётных записей

В большинстве небольших компаний у администратора одна учётная запись — доменный администратор. Он читает под ней почту, открывает вложения, заходит на рабочие станции пользователей по просьбе, а потом тот же пароль и тот же сеанс работают на контроллере домена. Достаточно одной заражённой станции с вошедшим на ней администратором, и вредонос получает всё. Модель уровней администрирования решает это правилом: учётная запись высшего уровня не должна «касаться» машин нижнего. Рядом стоит родственная тема — конфликт полномочий (SoD): один человек не должен единолично совершать действия, которые должны контролировать друг друга. Ниже как это выглядит на практике и как проверить.

Привилегированный доступ и его контроль: привилегированный доступ, PAM. Типичные ошибки AD, которые это закрывает: аудит Active Directory.

Три уровня

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

Уровень	Что входит	Какие учётные записи
0. Управление средой	Контроллеры домена, центры сертификации, серверы управления учётными записями и обновлениями, всё, что может изменить права на других уровнях	Администраторы домена и предприятия; входят только на узлы уровня 0 и со станций администрирования
1. Серверы и приложения	Серверы приложений, баз данных, файловые, виртуализация	Администраторы серверов; свои записи, не имеющие прав на уровне 0
2. Рабочие места	Станции пользователей, принтеры, мобильные устройства	Служба поддержки; права только на станции

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

Упрощение для небольшой компании

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

У каждого администратора две учётные записи: обычная (почта, браузер) и административная (только администрирование). Административная не имеет почтового ящика и не выходит в интернет.
Для доменных прав отдельная третья запись, которая используется только на контроллерах домена.
Административные записи входят только с узла-посредника (jump-хост или выделенная рабочая станция администратора), а не с обычного ноутбука: jump-хост.

Этого достаточно, чтобы вредонос с рабочей станции не получил сразу домен. Остальное — усиление по мере роста.

Шаг 1. Отдельные учётные записи по уровням

Именование должно показывать уровень: adm-t0-ivanov для уровня 0, adm-t1-ivanov для серверов, ivanov для обычной работы. Записи уровня 0 создаются в отдельном подразделении и входят в нужные группы только там.

New-ADOrganizationalUnit -Name "Admin-T0" -Path "DC=example,DC=com" -ProtectedFromAccidentalDeletion $true
New-ADUser -Name "adm-t0-ivanov" -SamAccountName "adm-t0-ivanov" -Path "OU=Admin-T0,DC=example,DC=com" `
  -AccountPassword (Read-Host -AsSecureString "Пароль") -Enabled $true -ChangePasswordAtLogon $true
Add-ADGroupMember -Identity "Domain Admins" -Members "adm-t0-ivanov"
Add-ADGroupMember -Identity "Protected Users" -Members "adm-t0-ivanov"

Ожидаемо: учётная запись создана в OU уровня 0 и состоит в группе Protected Users. Эта группа отключает для её членов устаревшие и небезопасные способы входа: NTLM, делегирование, кэширование паролей; Kerberos используется с укороченным сроком жизни билетов. Риск: у членов группы перестают работать некоторые старые приложения, поэтому проверьте на тестовой учётной записи.

Шаг 2. Запрет входа высших учётных записей на нижние уровни

Правило должно быть технически обеспечено, а не просто записано в инструкции. Через групповую политику: на подразделения уровней 1 и 2 назначьте для группы администраторов уровня 0 право «Deny log on locally», «Deny log on through Remote Desktop Services» и «Deny access to this computer from the network»:

# Политика на OU серверов и рабочих станций:
# Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment
#   Deny log on locally                          → G-Tier0-Admins
#   Deny log on through Remote Desktop Services  → G-Tier0-Admins
#   Deny access to this computer from the network → G-Tier0-Admins

Аналогично для уровня 1 на рабочих станциях (группа G-Tier1-Admins). Применяйте сначала к тестовому OU: ошибка в политике лишит администраторов доступа к серверам. Для Linux-серверов аналог — отдельные группы администраторов по классам узлов и правила HBAC: FreeIPA.

Шаг 3. Проверка: заходят ли высшие учётные записи куда не надо

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

Get-WinEvent -ComputerName srv-app-02 -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-30)} |
  ForEach-Object {
    $x = [xml]$_.ToXml(); $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    if ($d.TargetUserName -like 'adm-t0-*') {
      [pscustomobject]@{ Время = $_.TimeCreated; Учётка = $d.TargetUserName; ТипВхода = $d.LogonType; Адрес = $d.IpAddress }
    }
  } | Select-Object -First 20

Ожидаемо: пустой вывод. Строка означает, что высшая запись вошла на сервер уровня 1: или правило не применено, или администратор нарушил порядок. В обоих случаях нужен разбор. Эти проверки можно превратить в оповещение: аномалии доступа в Wazuh.

Конфликт полномочий (SoD)

SoD (Segregation of Duties) — правило, по которому ключевые операции должны требовать участия двух людей. Классический пример: сотрудник не должен и заводить нового поставщика, и платить ему. В ИБ типичные конфликты такие.

Одно полномочие	Не должно совпадать с	Чем это опасно
Выдавать права доступа	Согласовывать эти права	Человек сам себе даёт любой доступ
Администрировать систему	Проверять журналы этой системы	Администратор может скрыть свои действия
Разрабатывать код	Выкладывать в продуктив без проверки	В продуктив попадает непроверенный или вредоносный код
Менять резервные копии	Менять данные в продуктиве	Можно уничтожить данные и копии одновременно
Заводить контрагента и счета	Подтверждать платежи	Основа мошенничества с платёжными реквизитами

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

#!/usr/bin/env python3
"""Поиск конфликтов полномочий.
Использование: sod_check.py access_review.csv conflicts.csv
conflicts.csv: group_a,group_b,описание"""
import csv
import sys
from collections import defaultdict

member = defaultdict(set)
for r in csv.DictReader(open(sys.argv[1], encoding='utf-8-sig')):
    member[r['user'].lower()].add(r['group'])

found = 0
for c in csv.DictReader(open(sys.argv[2], encoding='utf-8-sig')):
    for user, groups in member.items():
        if c['group_a'] in groups and c['group_b'] in groups:
            print(f"КОНФЛИКТ: {user} состоит в {c['group_a']} и {c['group_b']} ({c['описание']})")
            found += 1
print(f'Найдено конфликтов: {found}', file=sys.stderr)
sys.exit(1 if found else 0)

Ожидаемо: список пользователей в двух несовместимых группах, код выхода 1 при наличии. Каждый конфликт разбирается: либо снимается одно из полномочий, либо оформляется исключение с компенсирующей мерой.

Когда разделить нельзя: компенсирующие меры

В команде из трёх человек разделение «администратор» и «аудитор журналов» невозможно: людей не хватает. Тогда конфликт не оставляют без внимания, а закрывают другими мерами.

Двойной контроль. Критичные операции (выдача привилегий, изменение правил экрана) выполняются в паре: один делает, второй проверяет перед применением.
Независимый журнал. События администраторов уходят на отдельный сервер, к которому у них нет прав на изменение: Wazuh. Просматривает их другой человек или руководитель.
Запись сессий и временный доступ. Привилегии выдаются на время работ, команды записываются: PAM.
Регулярный пересмотр. Конфликтные пары попадают в квартальный аудит с подтверждением руководителя.

Исключение оформляется письменно: пара полномочий, почему нельзя разделить, какие меры компенсируют, срок пересмотра.

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

Что хранить	Что показывает
Описание многоуровневой модели: список уровней, подразделений, правил и групп	Система учётных записей по уровням внедрена
Выгрузка настроек: групповые политики запрета входа, список членов `Protected Users`	Запреты обеспечены технически
Результаты проверки журналов на входы высших записей на нижние уровни	Нарушения выявляются
Список конфликтных пар и отчёты `sod_check.py`, решения по найденному	Выявление конфликтов полномочий автоматизировано

Диагностика

Симптом	Причина и что делать
Администраторы работают под доменными учётными записями «как удобнее»	Нет отдельных записей или инструкции. Выдайте записи по уровням и отзовите повседневные доменные права
После запрета входа перестали работать задачи по расписанию	Служебные записи не вынесены. Назначьте им отдельные учётные записи нужного уровня
В журналах входы уровня 0 на серверах	Политика не применена или администратор обошёл. Проверьте OU и результат `gpresult`, проведите разбор
Конфликтов тысячи	Список групп слишком общий. Оставьте пары, действительно опасные, остальное — через квартальный аудит
Невозможно разделить полномочия	Мало людей. Оформите исключение и включите компенсирующие меры

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

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

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

У каждого администратора есть отдельные обычная и административная записи.
Администратор уровня 0 не может войти на тестовый сервер уровня 1: запрет срабатывает.
Проверка журналов за последний месяц показывает отсутствие входов высших записей на нижние уровни либо разобранные случаи.
Скрипт sod_check.py на тестовых данных находит искусственно созданный конфликт.
Для оставшихся конфликтов есть исключения с компенсирующими мерами и сроком пересмотра.

Источники

Microsoft Learn, модель корпоративного доступа (Enterprise Access Model): learn.microsoft.com.
Microsoft Learn, группа Protected Users: learn.microsoft.com.
NIST SP 800-53 Rev. 5, разделение обязанностей (AC-5): csrc.nist.gov.
CIS Control 5, управление учётными записями: cisecurity.org/controls.