В чем разница между доменными и локальными учетными записями

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

Классический on-premises Active Directory остаётся базовым решением для управления доступом в большинстве российских организаций. Entra ID сохраняет применение в коммерческом секторе при работе с международными сервисами. Но их доля постепенно сокращается, особенно в системах, попадающих под жёсткие регуляторные требования ФСТЭК, ФСБ и Банка России.

Локальные учётные записи: основа автономной работы

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

1. Классические локальные (Local SAM) — хранятся исключительно в локальной базе данных Security Account Manager.

2. Учётные записи Microsoft — привязаны к облачному идентификатору. Даже при выборе «офлайн-учётки» Windows 10/11 активно предлагает связать профиль с аккаунтом Microsoft для синхронизации настроек, лицензий и параметров безопасности.

В системе изначально присутствуют две встроенные записи: Администратор и Гость. По умолчанию обе отключены, и это не случайность.

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

Встроенную запись Администратор не следует активировать для регулярной работы. Её роль — аварийный доступ на случай потери управления основными администраторами. Для рабочих задач лучше создать отдельную административную учётку с понятным назначением и строгим контролем использования.

Важное уточнение по записи Гость: в современных версиях Windows она отключена не просто так. Даже при принудительном включении она не обеспечивает автоматической очистки профиля после выхода. «Стирание» сессии достигается только через обязательные профили (mandatory profiles) и групповые политики. Использовать встроенного гостя в рабочих средах категорически не рекомендуется: его анонимность и слабая изоляция создают дополнительный вектор атак. Для временного доступа лучше создать ограниченную учётку с явным сроком действия и автоматическим отключением.

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

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

Практический лимит групп: теоретически пользователь может состоять в 1024 группах безопасности, однако размер маркера доступа (access token) ограничен. На практике стабильная работа наблюдается до 300–400 групп. Превышение приводит к ошибкам аутентификации и отказам в доступе к ресурсам.

Приоритет разрешений: явный запрет (Deny) действительно преобладает над разрешением (Allow) в большинстве сценариев доступа к файлам и реестру. Однако существуют исключения, связанные с правами владельца (Owner Rights), наследованием и явными разрешениями на уровне файловой системы, которые могут переопределять групповые политики.

Инструменты управления:

• Оснастка lusrmgr.msc (Локальные пользователи и группы) доступна только в редакциях Pro и Enterprise.

• В современных средах основным инструментом становится PowerShell. Он позволяет автоматизировать создание, аудит и модификацию учёток:

  Get-LocalUser
  Get-LocalGroup
  New-LocalUser -Name "WorkUser" -Password (Read-Host -AsSecureString)
  Add-LocalGroupMember -Group "Administrators" -Member "WorkUser"

• Для доменной среды используются Get-ADUser, Get-ADGroup, dsacls (для тонкой настройки ACL), а для анализа политик — gpresult /h report.html, rsop.msc и gpmc.msc.

Домен Active Directory: переход к централизованному управлению

Локальные учётки работают только на той машине, где созданы. В корпоративной сети с десятками или сотнями узлов управлять ими по отдельности невозможно. Решение — домен на базе Active Directory Domain Services (AD DS).

Домен — это логическая структура, объединяющая пользователей, компьютеры, принтеры и службы в единую базу данных, реплицируемую между контроллерами домена (DC). Доступ к любому сетевому ресурсу требует аутентификации на контроллере. Главное преимущество — централизация: администратор задаёт политики, настройки и права один раз, и они автоматически применяются ко всем целевым объектам. Локальные параметры рабочих станций при этом переопределяются доменными настройками.

Обработка групповых политик (GPO) происходит по строгому приоритету LSDOU:

1. Локальная политика (Local)

2. Сайт (Site)

3. Домен (Domain)

4. Подразделение (OU)

Политика, применённая последней, переопределяет предыдущие. Это поведение можно изменить:

• Принудительно (Enforced / No Override) — политика не будет переопределена нижестоящими.

• Блокировка наследования (Block Inheritance) — отключает применение политик от родительских контейнеров (кроме принудительных).

Домен также позволяет отразить организационную структуру компании в ИТ-архитектуре, делегировать управление отделам и строить контролируемые модели доступа. Хотя чистый on-prem AD DS считается зрелой, иногда устаревающей моделью в новых проектах, он остаётся ядром для большинства корпоративных сред России.

Современные модели защиты: LAPS, Tiering и Protected Users

Централизация требует усиленной защиты привилегированных учёток. В 2025–2026 гг. безопасность домена строится на трёх столпах:

1. LAPS (Local Administrator Password Solution)

В доменной среде критически важно управлять паролями локальных администраторов на рабочих станциях и серверах. Решение Microsoft — LAPS (в современных версиях — Windows LAPS) автоматически генерирует уникальный сложный пароль для встроенной записи Administrator на каждой машине, хранит его в AD (или Entra ID) и регулярно меняет. Без LAPS организации часто используют одинаковый локальный пароль на всех машинах, что превращает сеть в лёгкую цель для атак типа Pass-the-Hash и бокового перемещения (lateral movement).

2. Модель Tiering (Уровни управления)

Рекомендация Microsoft (модель ESAE) разделяет административные ресурсы на уровни:

• Tier 0: контроллеры домена, системы PKI, серверы управления идентификацией.

• Tier 1: серверы приложений, базы данных, файловые хранилища.

• Tier 2: рабочие станции пользователей, клиентское ПО.Администраторы каждого уровня используют выделенные учётки и рабочие станции. Запрещён вход учётками высшего уровня в среду нижнего уровня. Это физически прерывает цепочки атак на контроллеры домена.

3. Группа Protected Users

Специальная доменная группа, применяющая жёсткие ограничения к своим членам: запрет NTLM-аутентификации, отключение кеширования учётных данных на рабочих станциях, блокировка делегирования Kerberos, принудительное использование современных криптографических алгоритмов. Идеально подходит для Tier 0 и Tier 1 администраторов.

Дополнительные механизмы:

• Credential Guard / HVCI: изоляция учётных данных в защищённой виртуальной среде на основе виртуализации. Обязательно для узлов Tier 0.

• Ограничение сетевого входа встроенного администратора: через групповые политики Отклонить вход через службы удалённых рабочих столов и Отказать в доступе к компьютеру из сети.

Сравнительная таблица: Локальные / AD DS / Entra ID

Microsoft с 2022 года прекратила продажи новых лицензий и официальную поддержку в России. Многие компании работают на существующих лицензиях или через серые схемы, но для КИИ, банков и госсектора это создаёт серьёзные риски. Entra ID (облако) для многих организаций либо недоступен, либо используется с большими оговорками из-за требований локализации данных (152-ФЗ) и импортозамещения. Российские альтернативы ALD Pro, Astra Directory, MultiDirectory, Samba-based решения и др. активно продвигаются.

Аудит и мониторинг: от журналов событий до SIEM

Без видимости нет безопасности. В современных средах мониторинг учёток строится на нескольких уровнях:

1. Локальный и доменный аудит: обязательно включить политики Audit Credential Validation, Audit Logon Events, Audit Special Logon. Это фиксирует успешные и неудачные входы, а также использование привилегированных прав.

2. Ключевые идентификаторы событий (Event ID):

• 4624 — успешный вход

• 4625 — отказ во входе

• 4672 — назначены специальные привилегии (административный вход)

• 4776 — аутентификация NTLM (полезно для контроля легаси-протоколов)

1. Корпоративный мониторинг: журналы централизованно собираются в SIEM. В гибридных и доменных средах стандартом становятся Microsoft Defender for Identity (ранее Azure ATP) и Microsoft Sentinel, которые выявляют аномальные перемещения, подозрительные запросы Kerberos, попытки дампа учётных данных и lateral movement в реальном времени.

Практические рекомендации по безопасности

1. Стандартный пользователь — основа работы. Все повседневные задачи выполняются под учёткой без прав администратора. Повышение прав только через UAC или выделенные админские сессии.

2. Встроенные записи под контролем. Администратор и Гость отключены. Для администрирования созданы именованные учётки с чёткой принадлежностью к Tier-уровню.

3. LAPS обязателен. Развёрнут на всех рабочих станциях и серверах. Локальные администраторы удалены из группы Administrators на клиентских машинах через Restricted Groups или Group Policy Preferences.

4. Гибридная стратегия. При наличии удалённых сотрудников или SaaS-сервисов внедряется синхронизация AD DS с Entra ID. Аутентификация дополняется многофакторной проверкой (MFA) и условным доступом (Conditional Access).

5. Чистота политик. Групповые политики регулярно аудируются. Убираются конфликтующие правила, применяется Enforced только там, где это критично. Block Inheritance используется осознанно.

6. Мониторинг привилегий. Включён аудит специальных входов. Настроены оповещения на события 4625 (серийные отказы), 4672 (административные входы в нерабочее время), аномальные запросы к контроллерам домена.

7. Соответствие регуляторам. Архитектура доступа документируется, ведётся журнал изменений GPO, регулярно проводятся тесты на изоляцию Tier-уровней и устойчивость к Pass-the-Hash/Pass-the-Ticket.

Выбор между локальными учётками и доменом давно перестал быть бинарным. Эффективная ИТ-инфраструктура строится на гибридной модели: локальные учётки остаются аварийным и изолированным контуром, Active Directory обеспечивает строгий контроль и аудит в периметре, а облачные политики закрывают потребности удалённой работы и Zero Trust. Правильная настройка LAPS, разделение уровней управления, жёсткий аудит и современная криптография превращают эту архитектуру в надёжный фундамент, соответствующий как техническим, так и регуляторным требованиям.