Эффективное использование мощных идентификаторов

Администраторы, не использующие встроенных участников безопасности (well-known security principal), вряд ли представляют себе их сложность и широкие функциональные возможности. В Windows Server 2003 появились новые встроенные участники безопасности, и эта статья поможет освоить способы их применения для управления доступом к ресурсам Windows. Но прежде чем перейти к подробному описанию способов управления, хочу коротко пояснить, что представляют собой участники безопасности вообще и встроенные участники безопасности в частности. Затем мы подробно рассмотрим управление этими сложными элементами. Участник системы безопасности Windows — это аутентифицированный элемент, который использует ресурсы (например, файлы, принтеры), приложения или службы, размещенные на компьютерах Windows. Каждый участник безопасности имеет уникальный идентификатор, встроенный как SID.

Встроенные участники — отдельная категория участников безопасности. Они представляют собой особые сущности, определенные заранее и управляемые подсистемой безопасности Windows. Примерами могут служить учетные записи Everyone, Authenticated Users, System, Self и Creator Owner.

В отличие от типовых участников безопасности, этих участников нельзя переименовать или удалить. Невозможно также создать собственных встроенных участников безопасности; они одинаковы во всех системах Windows, хотя список встроенных участников безопасности в разных версиях слегка различается. Кроме того, встроенный участник безопасности имеет один и тот же SID в любой системе Windows. Например, SID S-1-5-10 всегда предоставляется участнику Self, а SID S-1-3-0 всегда представляет участника Creator Owner.

Обзор встроенных участников безопасности

В табл. 1 перечислены встроенные участники безопасности Windows 2003, Windows XP Service Pack 2 (SP2) и Windows 2000. В табл. 2 приведен список встроенных участников безопасности, введенных в Windows 2003; звездочкой отмечены участники, поддерживаемые XP SP2. Для каждого встроенного участника безопасности в таблице указан соответствующий SID. Список всех встроенных SID Windows приведен также в статье Microsoft «Well-known security identifiers in Windows operating systems» по адресу http://support.microsoft.com/?kbid=243330. Большинство встроенных участников безопасности, перечисленных в табл. 1 и 2, будут подробнее описаны ниже.

В Windows 2003 появились встроенные участники безопасности Local Service, Network Service, Digest Authentication, NTLM Authentication, Remote Interactive Logon, SChannel Authentication, Restricted Code, Other Organization и This Organization. Эти новые участники видны в Active Directory (AD), только если контроллер домена (DC), которому принадлежит роль эмулятора PDC, работает на Windows 2003. Для контроллеров доменов, созданных как на Windows 2003, так и на Windows 2000, необходимо сначала передать роль мастера данной операции контроллеру домена Windows 2003. Эта процедура документирована в статье Microsoft «Local Service and other well-known security principals do not appear on your Windows Server 2003 domain controller» по адресу http://support.microsoft.com/?kbid=827016. Данное ограничение не должно оказать заметного влияния на инфраструктуру AD, так как многие новые компоненты, использующие нового встроенного участника безопасности Windows 2003, требуют уровня однородного функционирования Windows 2003.

Большинство встроенных участников безопасности, перечисленные в табл.1 и 2 (например, Everyone, Authenticated Users), можно увидеть как встроенные группы участников безопасности. В отличие от типовых групп, операционная система (не администратор) автоматически управляет членством, которое зависит от ряда условий. Например, в XP и Windows 2000 операционная система автоматически вводит пользователя в группу Interactive, если данный пользователь работает локально за компьютером, на котором размещен ресурс, или если пользователь зарегистрировался на этом компьютере через соединение RDP. В Windows 2003 такой пользователь вводится в группу Remote Interactive Logon.

Встроенные группы участников безопасности можно рассматривать и как динамические группы, так как операционная система динамически определяет их членов. Их не следует путать с динамическими группами LDAP на базе запросов, которые были впервые представлены в Windows 2003 Authorization Manager (AzMan).

Интересная особенность встроенных участников безопасности — способ их репликации между экземплярами AD. Они могут применяться к тысячам объектов AD, но реплицируются только их имена, а не членство в группах. В результате нельзя использовать классический запрос AD и административный инструментарий для выяснения их членства в группах. Из-за способов использования встроенных участников безопасности хранить информацию об их членстве не требуется. Основная роль встроенных участников безопасности — обеспечить SID, который можно добавить в маркер доступа пользователя, когда тот регистрируется в системе или обращается к ресурсу. Присутствие конкретного встроенного участника безопасности дает пользователю определенные разрешения в системе или при обращениях к ресурсу. Просмотреть содержимое маркера доступа можно с помощью инструмента WhoAmI с ключом /all (WhoAmI поставляется c Windows 2003 и с Microsoft Windows 2000 Resource Kit) или такого бесплатного инструмента, как SecTok (который можно загрузить по адресу http://www.joeware.net), как показано на экране 1.

Администрирование встроенных участников безопасности

Встроенные участники безопасности существуют во всех операционных системах Windows, установленных как в домене, так и автономно. Однако в автономные системы вводятся не все встроенные участники безопасности. Кроме того, как объяснялось ранее, список встроенных участников безопасности в разных версиях операционных систем немного различается.

В домене Windows объекты AD, представляющие встроенных участников безопасности, хранятся в контейнере WellKnown Security Principals под контейнером Configuration. Для просмотра содержимого контейнера используется оснастка ADSIEdit консоли Microsoft Management Console (MMC) (экран 2). В автономной системе встроенные участники безопасности хранятся в локальной базе данных безопасности (Security Account Manager, SAM).

Встроенных участников безопасности можно добавить к другим группам и спискам управления доступом (ACL) объектов Windows. В AD можно даже делегировать разрешения встроенным участникам безопасности. Как ни странно, при первой попытке добавить встроенного участника безопасности в другую группу его не удается найти в оснастке Active Directory Users and Computers консоли MMC. Необходимо знать правильное имя встроенного участника безопасности; для поиска объекта нельзя задействовать инструментарий выбора объектов оснастки Active Directory Users and Computers. Дело в том, что в оснастке Active Directory Users and Computers сделан акцент на управление данными в контексте именования домена AD, а встроенные участники безопасности хранятся в контексте именования конфигурации AD. Та же проблема возникает при использовании оснастки MMC Local Users and Groups. В этом случае встроенные участники безопасности скрыты от пользователя.

В оснастке Active Directory Users and Computers встроенный участник безопасности отображается в контейнере ForeignSecurityPrincipals. Например, если ввести встроенного участника безопасности Authenticated Users в группу Print Operators, то элемент Authenticated Users будет добавлен в контейнер ForeignSecurityPrincipals (экран 3). Следует отметить, что в легкочитаемых именах большинства встроенных участников безопасности присутствует строка NT AUTHORITY. NT AUTHORITY — диспетчер безопасности во встроенном домене безопасности Windows, который существует в каждой системе Windows.

Встроенных участников безопасности можно добавлять в другие группы или в списки управления доступом (ACL) к ресурсам из командной строки. Это можно сделать с помощью команд Net Group и Net Localgroup. Например, чтобы добавить группу Interactive в локальную группу Backup Operators, следует ввести команду

net localgroup «Backup
Operators» Interactive /add

Добавить встроенный участник безопасности в список ACL ресурса можно с помощью утилиты командной строки subinacl.exe из комплекта ресурсов Microsoft Windows Server 2003 Resource Kit. Комплект можно загрузить по адресу http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en.

Например, чтобы предоставить группе Local Service право чтения в разделе реестра MyApplication, следует ввести команду

subinacl /keyreg MyApplication
/grant=»Local Service»=r

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

Authenticated Users и Everyone

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

Встроенный участник безопасности группа Everyone представляет собой надмножество группы Authenticated Users и охватывает ее и учетную запись Guest. Членство в группе определяется сложными правилами. В табл. 3 показаны специфические члены групп Authenticated Users и Everyone. В службе Active Directory (AD) версий Windows XP и Windows 2000 учетная запись Anonymous автоматически имеет членство в группе Everyone, но не в Authenticated Users. В Windows Server 2003 AD и Windows XP Service Pack 2 (SP2) учетная запись Anonymous по умолчанию не является членом группы Everyone, но ее можно поместить туда, установив параметр политики безопасности Network Access: Let Everyone permissions apply to anonymous users. Этот режим еще можно активизировать, присвоив параметру реестра HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetControlLSAEveryoneIncludes Anonymous (REG_DWORD) значение 1. Учетная запись Anonymous не является членом групп Authenticated Users.

System, Local Service и Network Service

В Windows 2000 и более ранних версиях службы и приложения независимых поставщиков обычно выполняются в контексте безопасности встроенного участника безопасности System (также именуемого учетной записью LSA или Local System). System функционирует как учетная запись данного компьютера в сети и как таковая представлена в сети именем Domain namemachine name$. Имя учетной записи в локальной системе NT AUTHORITYSystem. Учетная запись не имеет пароля, которым должен управлять администратор: используются данные учетной записи компьютера, автоматически назначаемые и управляемые Windows.

Разрешения System сопоставимы с учетной записью root в UNIX. При запуске службы или приложения в контексте безопасности System данная служба или приложение располагает почти неограниченными разрешениями в системе Windows. Например, если служба регистрируется на контроллере домена (DC) с использованием встроенного участника безопасности System, то она получает права локальной системы на DC. Получив контроль над службой, злоумышленник может внести изменения в AD. Следует быть осторожным — действуя в соответствии с принципом минимальности достаточных разрешений, лучше избегать использования System.

Чтобы не нарушать принципы и избежать риска, связанного с System, в Windows 2003 и XP SP2 предусмотрено два альтернативных варианта учетных записей: Local Service и Network Service. Local Service предоставляет минимальный уровень разрешений службам, которым достаточно доступа только к локальным ресурсам. Службы Smart Card, Remote Registry и Telnet используют учетную запись Local Service. Служба, работающая от имени Local Service, обращается к сетевым ресурсам в нуль-сеансе с учетными данными Anonymous. Чтобы настроить службу на использование Local Service, следует ввести NT AUTHORITYLocalService во вкладке Log On диалогового окна Alerter Properties. Пароль не требуется.

Network Service обеспечивает минимальный уровень разрешений для служб, которым необходим доступ к другим компьютерам в сети. Как и служба с разрешениями System, служба Network Service обращается к сетевым ресурсам с данными учетной записи компьютера. Службам Domain Name System (DNS) и Remote Procedure Call (RPC) по умолчанию присваиваются разрешения Network Service. Чтобы настроить службу на использование Network Service, следует ввести NT AUTHORITYNetworkService на вкладке Log On диалогового окна Alerter Properties. Пароль не нужен.

This Organization и Other OrganizationWindows 2003 располагают встроенными участниками безопасности This Organization и Other Organization, которые относятся к новой функции безопасности при доверительных отношениях между лесами, именуемой селективной аутентификацией и брандмауэром аутентификации. Селективная аутентификация позволяет определить дополнительный уровень управления доступом к ресурсам между лесами. Например, селективную аутентификацию можно использовать для выполнения регистрации на компьютере, а затем предоставить или запретить доступ к объектам на данном компьютере.

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

С помощью мастера Trust Wizard или свойств доверительного отношения можно настроить доверительные отношения в лесу или внешние по отношению к лесу для селективной аутентификации. Для настройки селективной аутентификации из диалогового окна Properties доверительных отношений следует перейти на вкладку Authentication и активизировать Selective Authentication.

Режим селективной аутентификации может быть назначен, только если доверяющий домен или лес работают на функциональном уровне Windows 2003. Можно назначить селективную аутентификацию при настройке доверительных отношений для домена Windows NT 4.0, если нужно ограничить доступ к ресурсам домена Windows 2003.

Если лес или внешнее доверительное отношение используют селективную аутентификацию, а пользователь пытается обратиться к ресурсу в другом лесу (задействуя доверительные отношения между лесами), то Windows добавляет к маркеру доступа пользователя встроенного участника безопасности Other Organization. Пользователи, которые обращаются к ресурсам, применяя доверительное отношение между лесами, по умолчанию имеют в своем маркере доступа встроенного участника безопасности This Organization. Когда пользователь задействует доверительные отношения в лесу или внешнее отношение между лесами без селективной аутентификации, Windows добавляет This Organization к маркеру доступа данного пользователя. В этом случае членство в группе This Organization такое же, как в группе Authenticated Users.

Если в маркере доступа имеется встроенный участник безопасности Other Organization, то серверы ресурсов проверяют, действительно ли пользователь, запросивший доступ, имеет разрешение Allowed-to-Authenticate на сервере ресурсов. Разрешение Allowed-to-Authenticate можно установить из редактора ACL для объекта «компьютер». Если пользователь имеет разрешение Allowed-to-Authenticate, то аутентификация между лесами проходит успешно. На этапе аутентификации сервер ресурсов проверяет наличие определенных разрешений для Other Organization, а затем, соответственно, разрешает или запрещает доступ к ресурсам.

Restricted Code

Windows добавляет к маркеру доступа пользователя встроенного участника безопасности Restricted Code при выполнении команды RunAs с параметром Run this program with restricted access в Windows 2003 или параметром Protect my computer and data from unauthorized program activity в XP. Для учетных записей с большими разрешениями (например, administrator) RunAs — удобный способ переключиться в контекст безопасности пользователя с минимальными правами при запуске программы. Таким образом, снижается опасность запуска вредоносной программы в контексте безопасности с большими разрешениями.

Если маркер доступа пользователя располагает встроенным участником безопасности Restricted Code, то Windows отменяет все разрешения для пользователя, кроме Bypass Traverse Checking. В результате приложение не может получить доступ к профилю пользователя, и разрешается только доступ по Read к базам данных настроек в реестре HKEY_LOCAL_MACHINE и HKEY_CURRENT_USER.

Restricted Code — удобный способ применять минимальные разрешения, не запоминая имен двух пользовательских учетных записей и двух паролей. Вместо использования RunAs для переключения в контекст безопасности с минимальными разрешениями можно применить RunAs для перехода в ограниченный вариант текущего контекста безопасности учетной записи — без ввода данных второй учетной записи. Более подробно о RunAs и использовании в ней Restricted Code рассказано в статье Аарона Маргосиса «Running Restricted» по адресу http://blogs.msdn.com/aaron_margosis/archive/ 2004/09/10/227727.aspx.

Типы Logon и Authentication

В Windows 2003, XP и Windows 2000 имеются встроенные участники безопасности, которые операционные системы добавляют в маркеры доступа других встроенных участников безопасности в зависимости от типа регистрации участника. Эти встроенные участники безопасности типа регистрации — Batch, Dialup, Interactive, Network, Service и Terminal Server User. Terminal Server User предназначен для всех пользователей, зарегистрированных с использованием режима совместимости с приложениями Terminal Services 4.0

Windows 2003 и XP SP2 дополнены встроенным участником безопасности Remote Interactive Logon, который идентифицирует пользователей, регистрирующихся с помощью версий Terminal Services для Windows 2003 или XP либо через соединение Remote Desktop.

Windows 2003 также дополнена тремя встроенными участниками безопасности типа аутентификации — NTLM Authentication, SChannel Authentication и Digest Authentication. Эти участники отражают в маркере доступа участника протокол аутентификации, который использовался участником для аутентификации в Windows. Следует отметить, что Microsoft не предоставила участников для аутентификации Kerberos и Basic.

Для более детального управления авторизацией можно использовать встроенные участники безопасности как типа регистрации, так и типа аутентификации. Эти новые участники позволяют назначить пользователям различные уровни доступа к ресурсам в зависимости от протокола аутентификации (например, NTLM, Digest, SSL) и типа регистрации (т. е. консоли или через терминальные службы).

Self, Creator Owner и Creator Group

Несколько иерархических структур объектов Windows (в том числе AD, реестр и файловая система) обеспечивают наследование разрешений. Разрешения определяются в родительском объекте, а затем автоматически передаются дочерним объектам. Windows располагает встроенными участниками безопасности Self, Creator Owner и Creator Group для администрирования разрешений в этих иерархических структурах.

Как правило, все три участника вводятся в список управления доступом (ACL) родительского объекта, а затем дочерние объекты наследуют этих участников следующим образом.

  • Дочерние объекты наследуют разрешения, назначенные для Creator Owner в родительском объекте таким образом, что учетная запись, которая создает дочерний объект, является владельцем объекта и явно получает специальные разрешения на дочерний объект. Например, если администратор AD устанавливает разрешение Write в свойствах определенного пользовательского объекта для Creator Owner в организационной единице (OU), то пользователь, который создает новый объект типа пользователь в OU, получает разрешение Write на этот объект.
  • Creator Group функционирует аналогично Creator Owner, но вместо добавления разрешений дочернему объекту для Creator Owner следует назначать или отменять разрешения для Creator Group, которая затем переносит разрешения для первичной группы владельца объекта на дочерний объект.
  • Self заполняет место для объекта. Например, администратор AD добавляет разрешение записи в атрибут postalAddress объекта "пользователь" для учетной записи Self в списке ACL этой организационной единицы. При создании нового объекта "пользователь" с именем Jan в этой OU пользователь Jan будет иметь разрешение Write для атрибута postalAddress (пользователю Jan разрешается обновлять данные о почтовом адресе в объекте типа "пользователь" AD). Следует обратить внимание, что те же разрешения Self на другой объект типа "пользователь" не позволят пользователю Jan редактировать атрибут postalAddress другого пользователя, так как разрешение для Self не связано с учетной записью Jan.

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

Мощный, но сложный инструмент

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

Жан де Клерк - Член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press). jan.declercq@hp.com