Почему сотрудник не должен работать с правами локального администратора

Сотруднику нужны определённые программы, доступ к корпоративным документам и возможность выполнять повседневную работу. Иногда для удобства ему предоставляют права локального администратора: чтобы не обращаться к IT-специалисту при установке программ или изменении настроек компьютера.

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

Если такая учётная запись окажется скомпрометирована, последствия могут затронуть не только документы самого сотрудника, но и безопасность всей системы. Особенно серьёзной становится ситуация, когда избыточные права предоставлены пользователям корпоративного сервера.

Что такое права локального администратора

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

Членство в этой группе может предоставляться как отдельной локальной учётной записи, так и доменному пользователю или доменной группе.

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

Локальный администратор и администратор домена — не одно и то же

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

Администратор домена имеет другой уровень полномочий, связанный с управлением инфраструктурой Active Directory. При этом доменные группы могут входить в локальные группы Administrators отдельных компьютеров.

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

Что может делать локальный администратор

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

Устанавливать и запускать программное обеспечение

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

Если пользователь запускает недоверенное приложение с повышенными правами, оно также может получить расширенные возможности на устройстве.

Изменять настройки операционной системы

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

Определённые действия могут ограничиваться доменными политиками, средствами защиты и дополнительными механизмами контроля. Тем не менее постоянное наличие административных полномочий расширяет возможности потенциально опасных действий.

Управлять локальными учётными записями

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

Изменять права на локальные ресурсы

В Windows доступ к файлам и каталогам регулируется разрешениями файловой системы NTFS. Административные полномочия могут позволить изменять разрешения и владельцев локальных объектов.

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

Почему это особенно опасно на корпоративном сервере

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

На сервере ситуация сложнее. Одновременно с ним могут работать десятки сотрудников, а на его дисках могут располагаться общие документы, бухгалтерские базы, приложения и другие важные для организации данные.

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

Как злоумышленники используют избыточные права

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

1. Первоначальная компрометация

Сотрудник может открыть вредоносное вложение, перейти на поддельную страницу авторизации или передать свои учётные данные в результате социальной инженерии.

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

2. Использование административных полномочий

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

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

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

3. Воздействие на сервер

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

Конкретные последствия зависят от конфигурации сервера, установленных защитных средств и доступности других ресурсов организации.

4. Распространение последствий

Отдельную опасность представляет использование одинаковых локальных административных паролей на нескольких компьютерах.

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

Дополнительные риски возникают, если администраторы используют привилегированные доменные учётные записи на менее защищённых компьютерах.

А разве UAC не защищает администратора?

Контроль учётных записей пользователей — User Account Control (UAC) — помогает отделять повседневное выполнение программ от операций, требующих повышенных привилегий.

Для многих административных операций Windows запрашивает подтверждение повышения прав или административные учётные данные.

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

В частности, для встроенной учётной записи Administrator действуют отдельные параметры режима одобрения администратором.

Как узнать, кто является локальным администратором

Первым этапом проверки является определение фактического состава локальной группы Administrators.

Для этого можно использовать стандартную консоль управления Windows или PowerShell.

Проверка через PowerShell

На обычном рабочем компьютере или рядовом сервере Windows Server 2022 выполните:

$admins = Get-LocalGroup -SID 'S-1-5-32-544'

Get-LocalGroupMember -Group $admins.Name |
    Select-Object Name, ObjectClass, PrincipalSource

Идентификатор S-1-5-32-544 обозначает встроенную группу Administrators независимо от языка установленной Windows.

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

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

На что обращать внимание при проверке

Важный момент: само по себе присутствие неизвестной учётной записи не доказывает компрометацию. Она может принадлежать системному компоненту, службе или ранее установленному приложению.

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

Как отследить изменение состава Administrators

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

Для этого в расширенной политике безопасности предусмотрена подкатегория Audit Security Group Management.

Основные события Windows

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

Пример просмотра событий

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

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4732,4733
    StartTime = (Get-Date).AddDays(-7)
} |
    Select-Object TimeCreated, Id, Message

Команда покажет только те записи, которые действительно сохранились в текущем журнале.

Если журнал Security уже перезаписан, восстановить более ранние изменения одной этой командой не получится. Именно поэтому проверку административных прав необходимо сочетать с правильной настройкой хранения событий.

Как правильно организовать административный доступ

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

1. Применять принцип минимальных привилегий

Каждый пользователь должен обладать только теми разрешениями, которые необходимы для выполнения его рабочих задач.

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

2. Разделять обычные и административные учётные записи

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

Такой подход позволяет уменьшить риск случайного запуска недоверенных программ с повышенными полномочиями.

3. Пересмотреть состав группы Administrators

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

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

4. Использовать уникальные административные пароли

Один и тот же пароль локального администратора на нескольких компьютерах увеличивает риск распространения последствий компрометации.

Для централизованного управления паролями локальных администраторов Microsoft предлагает Windows LAPS — Local Administrator Password Solution.

Windows LAPS поддерживается Windows Server 2022 при наличии необходимых обновлений, включая обновления от апреля 2023 года или более поздние.

При этом автоматическое создание и управление новой локальной учётной записью в рамках Windows LAPS доступно только в более новых версиях Windows. Для Windows Server 2022 следует планировать управление существующей локальной учётной записью.

5. Контролировать удалённые административные подключения

Административный доступ по RDP следует предоставлять ограниченному кругу ответственных специалистов.

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

Для важных серверов могут использоваться защищённые административные рабочие станции и централизованные средства удалённого доступа.

6. Настроить регистрацию административных действий

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

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

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

Почему не стоит просто удалить всех лишних администраторов

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

Необдуманное изменение групп способно привести к остановке важного программного обеспечения или потере административного доступа к серверу.

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

Техническая защита не отменяет обучение сотрудников

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

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

Поэтому WEB-LABS рекомендует дополнять технические меры повышением осведомлённости сотрудников в вопросах кибербезопасности.

Курс «Основы кибербезопасности для сотрудников»

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

Стоимость корпоративного обучения — 110 000 ₸ за группу до 20 сотрудников. Постоянный доступ к учебным материалам для последующего обучения новых сотрудников предоставляется в подарок.

Техническая документация Microsoft

• Локальные учётные записи и группа Administrators
• Принцип минимальных административных привилегий
• Настройки контроля учётных записей UAC
• Windows LAPS
• Событие 4732 — добавление участника в локальную группу