Книги, научные публикации
Pages: | 1 | ... | 10 | 11 | 12 | 13 | 14 | ... | 18 | Distributed Systems Guide Microsoft Windows 2000 Server Microsoft Press Распределенные системы Книга 1 Microsof Windows 2000 ...
-- [ Страница 12 ] --Получив билет сеанса Алисы, LSA расшифровывает его с помощью секретного клю ча компьютера и извлекает данные авторизации. Затем он направляет запрос базе данных локального диспетчера учетных записей безопасности (Security Account Manager, SAM), пытаясь выяснить, в какие локальные группы безопасности ком пьютера входит Алиса и не предоставлены ли ей какие-либо дополнительные пользовательские права на локальном компьютере. LSA добавляет возвращенные в ответ на запрос SID-идентификаторы к списку, извлеченному из данных авториза ции билета. Весь список используется для создания маркера доступа. Описатель маркера доступа возвращается службе Winlogon вместе с идентификатором сеанса Алисы в системе и подтверждением действительности, предоставленной ею ипгюр мации входа.
Winlogon создает для нее объект оконной станции (window station) и некоторые объекты рабочего стола Алисы, закрепляет за ней маркер доступа и запускает обо лочку, которую она будет использовать для взаимодействия с компьютером. Map Безопасность в распределенных системах 51 б ЧАСТЬ кер доступа Алисы передается всем процессами приложений, запускающимся ею в течение сеанса в системе.
Вход в систему с помощью смарт-карты При обычном входе в систему пользователь первоначально подтверждает КОС свою личность, подтверждая знание секрета, известного только пользователю и КОС. Общим секретом является криптографический ключ, преобразованный из пароля пользователя. Так как один и тот же ключ применяется как для шифрова ния, так и для расшифровки, общие секретные ключи называют симметричными.
Криптографический ключ, преобразованный из пароля пользователя, применяется только во время AS-обмена для:
Х шифрования клиентом информации предварительной проверки подлинности;
Х расшифровки этой информации центром распространения ключей;
Х шифрования КОС ключа сеанса входа в систему;
Х расшифровки этого ключа клиентом.
Для поддержки входа в систему с помощью смарт-карты, стандартный механизм AS-обмена Kerberos в Windows 2000 дополняется расширением шифрования с при менением открытых ключей. В отличие от криптографии общего ключа, криптог рафия с применением открытых ключей асимметрична, то есть в ней используют ся два разных ключа: один для шифрования, а другой для расшифровки. Оба клю ча, необходимые для этих действий, составляют пару лоткрытый/закрытый клю чи.
Если вместо пароля используется смарт-карта, хранящаяся на ней пара ключей за меняет общий ключ, преобразованный из пароля пользователя. Закрытый ключ из вестен только владельцу пары и никогда не разглашается. Открытый ключ предос тавляется всем, с кем владелец желает обмениваться конфиденциальной информа цией.
В расширениии шифрования с применением открытых ключей протокола Kerheros оригинальный AS-обмен изменен. В Windows 2000 КОС шифрует пользовательс кий ключ сеанса в системе открытым ключом пользователя, а клиент расшифровы вает его своим закрытым ключом.
Процесс входа в систему начинается с1 размещения пользователем его смарт-карты в считывающем устройстве компьютера. Эта процедура является SAS-последова телыюстыо компьютера под управлением Windows 2000, сконфигурированного для использования смарт-карт, по аналогии с комбинацией клавиш CTRL+ALT+DEL для компьютера, настроенного для входа с помощью пароля. Далее служба Winlogon вызывает MSG1NA, которая открывает диалоговое окно входа в систему.
На этот раз пользователю требуется ввести только свой PIN-код (personal iden tification number).
Как и при входе в систему по паролю, MSGINA вызывает LsaLogonUscr и направ ляет LSA предоставленную пользователем информацию для входа в систему. LSA применяет PIN-код для доступа к смарт-карте, на которой находится закрытый ключ пользователя и сертификат стандарта Х509 версии 3 с его открытым ключом.
Все криптографические операции с использованием этих ключей выполняются на смарт-карте.
Проверка подлинности ГЛАВА Kerberos SSP компьютера клиента направляет в КОС в качестве данных предвари тельной проверки подлинности сертификат с открытым ключом пользователя в сообщении KRB_AS_REQ. KDC проверяет действительность сертификата, извле кает открытый ключ и использует его для шифрования ключа сеанса в системе.
Затем он возвращает клиенту зашифрованный ключ сеанса в системе и билет TGT в сообщении-ответе KRBAS_REP. Обладая соответствующим закрытым ключом, клиент использует его для расшифровки ключ сеанса. Дальнейший обмен клиента и KDC шифруется ключом сеанса в системе. Оставшаяся часть процесса проверки подлинности проходит так же, как и при обычном входе в систему.
Подробнее о типах смарт-карт и о поддерживаемых Windows 2000 устройствах чте ния смарт-карт - на Web-странице Web Resources по адресу soft.com/windows2000/reskit/webresources, ссылка Microsoft Windows Hardware Compatibility List.
ГЛАВА Управление доступом Операционная система Microsoft Windows 2000 защищает файлы, приложения и другие ресурсы от несанкционированного использования. Хотя Вам уже должно быть известно, как назначать привилегии и разрешения, мы решили пояснить, что в действительности представляют собой привилегии и разрешения, для чего они нужны и как они работают. Надеемся, это поможет Вам эффективно управлять ре сурсами, избежать ненужных рисков и устранять проблемы по мере их появления.
В этой главе Модель управления доступом Права 52- Идентификаторы безопасности Маркеры доступа Дескрипторы безопасности Списки управления доступом Наследование ACL Проверка доступа и аудит См. также Х Подробнее о том, как диагностировать, восстанавливать и устранять неполадки в Active Directory, Ч в главе 10 Выявление и устранение неполадок, а также восстановление данных в Active Directory.
Х Подробнее о проверке подлинности Ч в главе И Проверка подлинности.
Х Подробнее о правах пользователя - в приложении Г Права пользователей.
Х Подробнее о известных идентификаторах безопасности - в приложении Д Наиболее известные идентификаторы безопасности.
Управление доступом ГЛАВА Модель управления доступом Работа систем безопасности в Windows 2000 основана на технологиях, изначально разработанных для Windows NT. В принципе, обе операционные системы одинако во управляют доступом к ресурсам. Если Вы знакомы с Windows NT 4.0 или более ранними версиями Windows NT, то знаете, что их модель управления доступом име ет некоторые особенности.
Проверка подлинности на основе пользователей. В Windows NT любое запущен ное пользователем приложение выполняется не в своем собственном, а в пользова тельском контексте безопасности. Такое приложение выполняет только действия, разрешенные пользователю. Например, приложение Microsoft Word получит доступ только к тем документам, к которым разрешен доступ его пользователю. Если тот же Word открывает другой пользователь, приложению становятся доступны тс до кументы, к которым имеет доступ именно этот пользователь. В Windows 2000 эта функция модели управления доступом значительно усовершенствована. Приложе ния выполняются в ограниченном контексте безопасности, в котором они облада ют меньшими привилегиями и более ограниченным доступом, чем пользователь, их запустивший.
Избирательный доступ к защищенным объектам. В Windows NT пользователь Ч владелец объекта определяет, кто и каким образом может его использовать. Он вправе предоставлять разрешения на различные виды доступа только определен ным пользователям или группам. Например, владелец объекта файл может пре доставить разрешение на чтение и запись всей группе и при этом запретить доступ на запись определенному члену этой группы. В Windows 2000 владельцам предос тавлено право разрешать или запрещать доступ как к отдельным свойствам объек тов определенного типа, так и к объекту в целом.
Наследование разрешений. Windows NT позволяет управлять разрешениями для объектов, создаваемых в объекте-контейнере, установив для контейнера наследуе мые разрешения. Например, разрешения, установленные для папки в разделе NTFS будут наследоваться всеми вновь создаваемыми в ней папками и файлами. В Windows 2000 установленные для контейнера разрешения наследуются как уже существующими объектами, так и вновь создаваемыми.
Административные привилегии. Windows NT позволяет управлять пользователями и группами, обладающими правом выполнять различные административные функ ции или предпринимать действия, затрагивающие ресурсы всей системы. Например, администратор может предоставить одной группе пользователей право интерактив ного входа в систему, а другой, более малочисленной Ч право загружать и выгружать драйверы устройств. Групповая политика в Windows 2000 позволяет централизован но управлять административными привилегиями на всех компьютерах домена, Аудит системных событий. В Windows NT функция аудита используется для об наружения попыток обойти защиту или для создания контрольного следа админи стративных действий в системе. Например, регистрировать в журнале безопаснос ти неудачные попытки входа в систему. В журнале также отразится изменение дру гим администратором политики аудита, заключающееся в отмене регистрации не удачных попыток входа в систему. Групповая политика в Windows 2000 позволяет централизованно управлять пользователями, которым разрешено оперировать жур налами безопасности компьютеров домена.
Безопасность в распределенных системах 520 ЧАСТЬ Основные понятия В управлении доступом, как и в любой другой сфере, применяется специальная терминология. Сейчас мы расскажем, как используются некоторые понятия в кон тексте модели управления доступом Windows 2000.
Участник безопасности (security principal) Ч это пользователь, группа, компьютер или служба. Участники безопасности обладают учетными записями. Локальные учетные записи управляются диспетчером учетных записей безопасности (Security Account Manager, SAM) компьютера, а учетные записи домена Ч службой катало гов Active Directory.
Идентификатор безопасности (security identifier, SID) - это значение, которое уникально идентифицирует пользователя, группу, службу или компьютер предпри ятия. S1D присваивается каждой учетной записи в момент ее создания. Механиз мы управления доступом в Windows 2000 различают участников безопасности по SID, а не по именам.
Контекст безопасности (security context) это информация, описывающая отли чительные черты участника безопасности и его возможности при работе на компь ютере. В Windows 2000 любые действия выполняются в определенном контексте безопасности, средствами которого подсистема безопасности определяет разрешен ные процессу и его потокам действия с объектами компьютера, а также участников безопасности, несущих ответственность за действия потока.
Маркер доступа (access token) Ч это структура данных, содержащая SID участни ка безопасности, SID-идентификаторы всех групп, членом которых он является, и список его привилегий (прав пользователя) на локальном компьютере. Маркер до ступа присваивается каждому участнику безопасности, входящему как локально (с клавиатуры компьютера), так и удаленно (по сети). Маркер доступа определяет контекст безопасности для действий участника безопасности на компьютере.
Поток (thread) Ч это исполняемая часть процесса. Упрощенно поток можно рас сматривать как программный код, предназначенный для процессора. Процесс мо жет иметь несколько одновременно выполняющихся потоков. Операционная сис тема координирует их работу, определяя приоритеты выполнения потоков.
Субъект (subject) это поток, выполняющийся в контексте безопасности участ ника безопасности, прошедшего проверку подлинности. Прежде чем допустить субъекта к выполнению операций на защищенном объекте, подсистема безопаснос ти проводит проверку доступа она сравнивает информацию в маркере доступа субъекта с данными в дескрипторе безопасности объекта. Таким образом проверя ется, разрешены ли субъекту запрашиваемые им действия.
Олицетворение (impersonation) это способность потока действовать в контексте безопасности, отличном от контекста процесса, к которому он относится. Олицет ворение разработано для клиент-серверных приложений, где оно применяется в службах. Выполняя собственные действия, служба работает в собственном контек сте безопасности, а при обработке клиентского запроса Ч в контексте безопасности клиента.
Объект (object) Ч это любой ресурс, которым может управлять программа или про цесс. Объекты включают в себя не только ресурсы, которые можно наблюдать в интерфейсе пользователя, например файлы, папки, принтеры, разделы реестра, объекты Active Directory и рабочий стол Windows, но и ресурсы, которые увидеть Управление доступом ГЛАВА 12 нельзя Ч сеансы, процессы, потоки и маркеры доступа. Объект может выступать как логическое хранилище других объектов. Такие объекты называются контейне рами. Объекты, не способные содержать другие объекты, называются конечными объектами (не-контейнерами). Объекты-контейнеры содержат как конечные объек ты, так и другие объекты-контейнеры. Например, в объекте папка* файловой сис темы могут находиться как объекты файл (конечные объекты), так и другие объекты папка (контейнеры). В иерархии объектов отношение между контейне ром и его содержимым описывается терминами родительский (parent) для контей нера и дочерний (child) для находящегося в нем объекта. Понятие родственных от ношений тина родитель потомок очень часто используется для описания концепции наследования объектов, в которой дочерний объект наследует опреде ленные характеристики (например, ограничения безопасности) родительского объекта.
Защищенный объект (securable object) Ч это любой объект, который разрешается выделять в общее пользование. В Windows 2000 у всех защищенных объектов есть дескрипторы, содержащие сведения о порядке управления доступом к объекту.
Дескриптор безопасности (security descriptor) Ч структура данных, в которой со держится информация о защищаемом объекте. Дескриптор безопасности иденти фицирует владельца объекта по его STD. У объекта с установленными разрешения ми в дескрипторе безопасности находится избирательная таблица управления дос тупом (discretionary access control list, DACL) с SID-идентификаторами пользова телей и групп, которым разрешен или запрещен доступ к нему. Если для объекта задан порядок аудита, дескриптор его безопасности также содержит системную таблицу управления доступом (system access control list, SACL), в которой опреде лен порядок выявления подсистемой безопасности попыток доступа к нему.
Владелец (owner) Ч это единственный участник безопасности, обладающий неотъем лемым правом разрешать или запрещать доступ к объекту. Первым владельцем объекта обычно является участник безопасности, связанный с создавшим объект потоком. Владелец объекта вправе изменить его принадлежность, предоставив дру гому участнику безопасности разрешение Take ownership (Смена владельца). По умолчанию члены встроенной группы Administrators (Администраторы) компью тера могут стать владельцами любых объектов на компьютере.
Разрешение (permission) Ч это право произвести одну или несколько операций с объектом. Разрешения определяются владельцем объекта. Поскольку решение (вы бор) о порядке доступа к объекту принимается пользователем, данный тип управ ления доступом в Windows 2000 называется избирательным управлением доступом (discretionary access control).
Право пользователя (user right) Ч это право совершить операцию, оказывающую влияние не просто на отдельный объект, а на компьютер в целом. Права пользова теля (также известные как привилегии) предоставляются администраторами от дельным пользователям или группам при настройке политики безопасности ком пьютера. Несмотря на то, что правами пользователя можно управлять централизо ванно средствами групповой политики, они применяются локально. Пользователям, как правило, предоставляются различные права на разных компьютерах.
Право доступа (access right) Ч это разрешение с точки зрения субъекта. Когда пользователь конкретный человек, разрешает или запрещает доступ средствами диалогового окна Access Control Settings (Параметры управления доступом), ре Безопасность в распределенных системах 522 ЧАСТЬ зультат его действий сохраняется в виде записей управления доступом, (access control entry, АСЕ) в DACL объекта. В интерфейсе пользователя разрешение выра жено словом или фразой. В АСЕ то же самое разрешение выражается набором би товых флагов в маске доступа. Каждому битовому флагу соответствует право дос тупа - определенная операция, которую можно совершить над объектом, Как работает управление доступом Детали работы механизма управления доступом весьма сложны, но в общих чертах процесс выглядит достаточно просто: субъекты совершают действия над объекта ми. В предложении Алиса открывает файл Алиса является субъектом, или аген том действия, открывает Ч это само действие, а файл Ч объект действия. Похожая терминология используется и в Windows 2000.
Вместе с тем необходимо обратить внимание на некоторые важные отличия. Когда мы говорим Алиса открывает файл, то подразумеваем, что на самом деле файл открывает не сама Алиса, а программа. Точнее, программа выполняется как процесс, состоящий из потоков, и в действительности файл открывает один из них. Потоки - это единственные объекты, реально выполняющие действия на компьютере. И терминах управления доступом субъектом всегда является поток.
Чтобы получить доступ к объекту, потоку необходимо идентифицировать себя в подсистеме безопасности операционной системы. У самого потока нет реквизитов безопасности Ч он должен его получить от участника безопасности, например от Алисы. При входе в систему реквизиты безопасности Алисы заключаются в мар кер доступа, связанный с ее сеансом в системе. Когда Алиса запускает приложение, оно выполняется как процесс, являющийся частью се сеанса в системе. Процесс приложения и каждый из его потоков выполнения получают по экземпляру марке ра доступа Алисы. Когда одному из потоков приложения необходимо открыть файл, он представляется как агент Алисы, предъявляя ее маркер доступа. Таким образом, ответственность за все, что поток делает с файлом от лица Алисы лежит на ней.
Естественно, что потоки не открывают файлы так, как это делают пользователи, Потоки - это всего лишь выполняющиеся на компьютере отрезки программного кода, и они взаимодействуют с объектами при помощи одного из предоставляемых операционной системой интерфейсов прикладного программирования (API). Что бы поток открыл файл, его код должен содержать, например, следующую команду:
hfile=CreateFile(pRzFile,GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL);
Второй аргумент вызова функции CreateFile указывает желаемый набор прав до ступа (GENERICWRITE), сообщающий операционной системе, что поток желает открыть файл и (возможно) изменить его. Аналогично работают другие функции API. При вызове функций API необходимо, указав требуемый уровень доступа, со общить, какие действия над объектом Вы будете производить.
Прежде чем позволить потоку выполнить запрашиваемые действия, операционная система проверяет, обладает ли связанный с потоком участник безопасности уров нем доступа, запрошенным потоком. В процессе проверки доступа сравнивается информация маркера доступа потока со сведениями дескриптора безопасности объекта:
ГЛАВА 12 Управление доступом Х из маркера доступа извлекается информация о S1D, идентифицирующая связан ного с потоком пользователя, и SID-идентификаторы групп, членом которых является этот пользователь;
Х из DACL дескриптора безопасности извлекаются записи управления доступом, в которых указано, какими правами доступа к объекту обладают определенные пользователи и группы и в каких правах доступа им отказано.
Подсистема безопасности ищет в DACL объекта записи управления доступом, от носящиеся к SID-идентификаторам пользователя и групп в маркере доступа пото ка. Она по очереди проверяет все АСЕ-записи для каждого SID, пока не находит ту, которая разрешает или запрещает доступ пользователю или одной из его групп, или пока не проверит все АСЕ. Если проверены все АСЕ в DACL и так и не уда лось определить, разрешен или запрещен необходимый потоку доступ, подсистема безопасности запрещает доступ к объекту. Этот процесс показан на рис. 12-1.
Субъект Объект SID пользователя Дескриптор безопасности Маркер SID-идентификаторы доступа групп Система проверяет SACL Информация о привилегиях записи DACL Прочая информация доступа пом (ACEs) Запись управления доступом (АСЕ) ! Запись управления доступом (АСЕ) Запись управления Запись управления доступом (АСЕ) доступом найдена Запись управления доступом (АСЕ) Рис. 12-1. Проверка запроса на доступ Порядок расположения записей управления доступом в DACL весьма важен. На пример, в DACL объекта одна АСЕ может разрешать доступ группе, а другая -- за прещать доступ пользователю, являющемуся членом этой группы. Если в процеду ре проверки доступа АСЕ-запись, разрешающая доступ группе пользователя, будет обработана прежде чем АСЕ, запрещающая доступ пользователю, то пользователь получит доступ к объекту. Попятно, что такой результат явно нежелателен.
Обычно АСЕ располагаются в каноническом (canonical) порядке, согласно которо му запрещающие АСЕ располагаются до разрешающих. В этом случае сначала об рабатываются запрещающие доступ АСЕ, а потом разрешающие.
Однако иногда канонический порядок не срабатывает. В качестве примера рассмот рим DACL, показанную в таблице 12-1.
ЧАСТЬ 2 Безопасность в распределенных системах Таблица 12-1. Неканонический порядок расположения АСЕ Тип Имя Разрешение Allow (Разрешить) Administrators (Администраторы) Full Control (Полный доступ) Deny (Запретить) Network (Сеть) Read (Чтение) Allow (Разрешить) Users (Пользователи) Read (Чтение) Эта DACL разрешает администраторам доступ к объекту при входе в систему ло кально и по сети и ограничивает пользователей без административных полномо чий, предоставляя им доступ, только при локальном входе в систему. Хотя эта DACL и не является канонической, она выполняет важную задачу, как и другие неканонические DACL. Однако применение неканонических DACL не запрещает ся, но и не приветствуется, так как их действие иногда сложно понять. Неканони ческую DACL нельзя создать при помощи интерфейса пользователя, но возможно Ч программными средствами, Описание канонического порядка в данном обзоре дано кратко. Мы, например, не рассказываем о порядке АСЕ. унаследованных от родительского объекта. Подроб нее о каноническом порядке Ч в разделе Порядок записей управления доступом в DACL далее в этой главе.
Права Право - это разрешение выполнить операцию. В Windows 2000 только одно право предоставляется безоговорочно - право пользователя разрешать или запрещать доступ к ресурсам, которыми он владеет. Все прочие права должны быть предо ставлены, а, значит, их можно отозвать. С точки зрения администратора существу ют два вида прав: разрешения и права пользователей.
Разрешения Разрешение (permission) предоставляет право совершить операцию с определенным объектом, например файлом. Разрешения предоставляют владельцы: они могут любому пользователю или группе безопасности позволить любые действия над объектом из тех, которые позволены им самим, в том числе разрешить стать вла дельцем объекта.
Совет Несмотря на то, что разрешения выдаются отдельным пользователям, их гораздо эффективнее давать группам безопасности. Лучше один раз предоставить право на какие-то действия группе, чем повторять эту операцию многократно, для каждого члена группы. Все пользователи, входящие в группу безопасности, полу чают разрешения, установленные для этой группы.
Отсутствие разрешения, заданного в явной форме, подразумевает запрещение до ступа к соответствующим операциям над объектом. Например, если Алиса разре шит чтение своего файла только группе Marketing, остальным пользователям не членам этой группы доступ будет закрыт.
В разрешении можно отказать и в явной форме. Например, если Алиса не желает предоставлять Бобу доступ для чтения к файлу несмотря на то, что он входит в группу Marketing, она вправе запретить Бобу чтение этого файла. На практике именно так и следует использовать явный запрет Ч сначала предоставлять разре Управление доступом ГЛАВА 12 шение большему числу пользователей (группа Marketing), а потом исключать из нее отдельные элементы (Боб) или подмножества.
Каждое разрешение, предоставляемое владельцем объекта пользователю или груп пе, хранится в виде записи управления доступом в таблице DACL. входящей в со став дескриптора безопасности объекта. В интерфейсе пользователя АСЕ отобра жаются как Permission Entries (Элементы разрешений) в диалоговом окне Access Control Settings (Параметры управления доступом). На рис. 12-2 показаны записи управления доступом в DACL файла Алисы.
Рвгдагаюл Eritries lAltftf Al ice (RE ЗКПЫ ice).Allow Marketing (RESKIHmarkehng;
AfowinheHtable peirrasdbns:fiqm paefS (a propagate [Q this Х Рис. 12-2. Разрешения для файла Алисы Примечание Разрешения на уровне файлов можно установить только для файлов распложенных на томе NTFS. На томе FAT разрешения устанавливаются лишь для общих ресурсов, но они не распространяются на файлы и папки, хранящиеся в со вместно используемом ресурсе. Более того, разрешения для общих ресурсов на томе FAT ограничивают только сетевой доступ и никак не влияют на доступ пользовате лей, непосредственно работающих на компьютере. По этой причине применять фай ловую систему FAT на общих томах нежелательно, рекомендуется применять тома NTFS.
Установка разрешений для объектов Active Directory Разрешения для объектов Active Directory устанавливаются так же, как и для объек тов тома NTFS в окне Windows Explorer (Проводник Windows). Щелкните правой кнопкой мыши объект, в контекстном меню выберите Properties (Свойства) и в от крывшемся диалоговом окне Properties (Свойства) перейдите на вкладку Security (Безопасность).
Если Вы пользуетесь оснасткой Active Directory Users and Computers (Active Directory Ч пользователи и компьютеры) в диалоговом окне Properties (Свойства) Безопасность в распределенных системах 526 ЧАСТЬ может не оказаться вкладки Security (Безопасность). Отображение параметров бе зопасности объекта относится к дополнительным функциям этой оснастки. Если в диалоговом окне Properties (Свойства) выбранного объекта отсутствует вкладка Security (Безопасность), закройте диалоговое окно Properties, щелкнув Cancel (Отмена), а затем в меню View (Вид) оснастки Active Directory Users and Com puters (Active Directory Ч пользователи и компьютеры) отметьте команду Advanced Features (Дополнительные функции).
Вкладка Security (Безопасность) показывает только верхний уровень параметров управления доступом объекта. Чтобы получить полную информацию, в том числе и сведения о том, как дочерние объекты наследуют разрешения объекта-контейне ра, щелкните кнопку Advanced (Дополнительно). В диалоговом окне Access Control Settings (Параметры управления доступом) перейдите на вкладку Permissions (Разрешения). Если объект является контейнером, список Permission Entries (Элементы разрешений) показывает, какие разрешения относятся только к самому объекту (то есть только к контейнеру), какие только к дочерним объектам (то есть только к объектам в контейнере) и какие применяются только для опреде ленного типа дочерних объектов (например, только для объектов-пользователей).
Вид этой вкладки отличается от вида аналогичной вкладки для объектов тома NTFS, что отражает важное различие между переносом разрешений контейнера в Active Directory и на томах NTFS. Владелец папки на томе NTFS может управлять доступом к папке и всем ее содержимым, устанавливая для этой папки разреше ния, применяющиеся не только для нес самой, но и для всех объектов в ней. На пример, можно установить для объекта-папки разрешение на чтение группе Mar keting. Если это разрешение реализовать, установив флажок This folder, subfolders and files (Для этой папки, се подпапок и файлов), его действие будет перенесено на все находящиеся в папке объекты. Группа Marketing получит доступ на чтение как к самой папке, так и ко всем вложенным подпапкам и файлам. Разрешения для объектов Active Directory переносятся немного иначе. Владелец контейнера в Active Directory имеет возможность разрешить доступ к определенному типу объектов в контейнере, не предоставляя его для остальных типов дочерних объектов. Напри мер, владелец объекта ^подразделение (organizational unit, OU) вправе дать разре шение на чтение группе Marketing и перенести его на дочерние объекты подразделе ния определенного типа. В частности, если его распространить на объекты Contact (Контакт), разрешение будет относиться только к объектам-контактам, но не к объек там User (Пользователь) или каким-либо объектам других типов. Другими словами, распространение разрешений контейнеров на дочерние объекты в Active Directory определяется типом объектов. На томах NTFS такая функция недоступна.
Установка разрешений на уровне свойств Разрешениями для объектов Active Directory можно управлять на двух уровнях:
Х на уровне объекта. Разрешения, установленные на уровне объекта, применяют ся ко всему объекту. Так, разрешение на уровне объекта подразделение позво лит определенной группе, например Account Operators (Операторы учета), со здавать в нем дочерние объекты;
Х на уровне свойств. Разрешения, установленные на уровне свойств, применяют ся только к отдельным свойствам объекта. Так, для объекта пользователь мож но задать разрешение на уровне сиойств, позволяющее определенному пользо Управление доступом ГЛАВА 12 вателю, например Principal Self (то есть пользователю, представленному объек том), изменять свойство Home Address (Домашний адрес) этого объекта.
Разрешениями на уровне свойств нельзя управлять непосредственно из диалогово го окна Access Control Settings (Параметры управления доступом), но начать сле дует именно с него. Чтобы открыть диалоговое окно Access Control Settings, выбе рите нужный объект в одном из инструментов, применяющихся для управления Active Directory, например в оснастке Active Directory Users and Computers (Active Directory пользователи и компьютеры). Щелкните объект правой кнопкой мыши, в контекстном меню выберите Properties (Свойства), в открывшемся диалогоном окне Properties (Свойства) перейдите на вкладку Security (Безопасность) и щелк ните Advanced (Дополнительно).
Чтобы добавить новое разрешение на уровне свойств, щелкните Add (Добавить) и в открывшемся диалоговом окне Permission Entry (Элемент разрешения) щелкни те вкладку Properties (Свойства). Список доступных разрешений на уровне свойств отобразится в панели Permissions (Разрешения), Для просмотра или редактирования действующих разрешений на уровне свойств, откройте диалоговое окно Access Control Settings (Параметры управления досту пом), выделите сначала один из элементов в Permission Entries (Элементы разре шений), а затем щелкните View/Edit (Показать/Изменить). В диалоговом окне Permission Entry (Элемент разрешения) перейдите на вкладку Properties (Свой ства). Разрешения на уровне свойств перечислены в панели Permissions (Разреше ния). Разрешения на уровне свойств для объекта-пользователя Алиса, предостав ленные группе Authenticated Users (Прошедшие проверку), показаны на рис. 12-3.
Мвшг JAulhenticaied Usm Х 1Jvbrtfi \ зфр!/ crto J7hiji;
b|ecionl>' :
^е(юзют DiWv^ f&OW :
П -J El Read Hcme Address П Write Home Address П 'Х Redd Home Directory П Wiite Home Director;
П E 3ead Horns Drive D a stifii;
- Х J Write Home Dnve i;
E -ledd Home P-me a Write Home Phone a :
Read home Phone [Others] a;
П Write Home Phone [Others) a Read Initials Write Initial;
П. !
ГЯ n ^J r :ХХ- :
Х Х Cancel Рис. 12-3. Разрешения на уровне свойств для объекта-пользователя На вкладке Properties (Свойства) перечислены не все свойства объекта, а только те, которые обычно требуются для управления доступом. Сами свойства объектов Безопасность в распределенных системах 528 ЧАСТЬ Active Directory и типы объектов определены в схеме. Типов и свойств (или атри бутов) объектов множество, поэтому для облегчения управления в интерфейсе пользователя отображаются только их небольшая часть. Отображаемое подмноже ство определяется фильтром.
Список типов и свойств, пропущенных фильтром объектов и попавших на вкладку, хранится в файле Dssec.dat, расположенном в папке %5#semroot%\System32 на кон троллере домена. Фильтр можно модифицировать, добавляя или убирая из списка отдельные записи. Dssec.dat Ч это текстовый файл следующего формата:
[Тип_объекта] 3= Имв_атрибута = Фильтр пропускает объект, если за типом объекта в квадратных скобках в следую щей строке проставлен знак @, которому присваивается значение 7. Чтобы не ото бражать этот объект, нужно изменить значение на 0. Имена отображаемых атрибу тов следуют за строкой с указанием типа объекта. Для отображаемых атрибутов ус танавливается значение 7, а для скрытых - 0.
Изменения, внесенные в файл Dssec.dat, не отразятся во вкладке Properties (Свой ства) до перезагрузки оснастки Active Directory Users and Computers (Active Direc tory - пользователи и компьютеры) или любой другой служебной программы, при мененной для просмотра свойств. Данные фильтра считываются при инициализа ции программы.
Подробнее о типах объектов и их атрибутах Ч в главе 4 Схема Active Directory.
Маска доступа Разрешения в записях управления доступом (access control entry, АСЕ) представлены одним или несколькими битами в 32-разрядной величине называемой маской досту па (access mask). Запрашивая доступ к объекту, поток указывает требуемый тип до ступа в маске доступа. Во время проверки доступа операционная система сравнивает представленную потоком маску доступа с масками доступа в записях управления доступом DACL объекта. На рис. 12-4 показана структура маски доступа.
11 Х Х :Х 15, Х i 22 27 7 6 5 4 3 2 1 ХХ Зарезерви- Стандартные Объектно-зависимые права доступа г ровано права доступа Обозначения GR (Generic Read) - чтение GW (Generic Write) - запись GE (Generic Execute) - исполнение GA (Generic All) - все AS право доступа к SACL Рис. 12-4. Структура маски доступа Каждый бит соответствует праву доступа отдельной операции или серии опера ций, которые можно совершить над объектом. Установка бита в маске запрашивае мого доступа информирует о том, что поток нуждается в праве совершить соответ ствующую операцию. С другой стороны, установленный бит в маске доступа АСЕ указывает, в зависимости от типа АСЕ, на разрешение или запрещение соответству ющей операции.
Управление доступом ГЛАВА 12 Многие права доступа в маске доступа соответствуют разрешениям, которые мож но установить через интерфейс пользователя, по существуют и исключения. Неко торые из них вправе установить только определенный процесс, например создаю щий объект, и они недоступны для модификации средствами пользовательского интерфейса. Далее перечислены тины прав доступа в формате маски доступа, при нятой в Windows 2000.
Общие права доступа. Эти права применяются ко всем объектам, но их значение различается для объектов разных типов. Каждый тип объекта устанавливает свое соответствие отдельных общих прав доступа и стандартных и объектно-зависимых прав доступа. В таблице 12-2 перечислены общие права доступа.
Таблица 12-2. Общие права доступа Константа в Win32 API Значение GENERIC_ALL Доступ ни чтение, запись и исполнение GENERIC_EXECIJTE Доступ на исполнение GENERIC_READ Доступ на чтение GENERIC_WRn>] Доступ на запись Стандартные права доступа. Эти права более узкие, чем общие права доступа, тем не менее их применяют для операций с большинством типов объектов. В таблице 12- перечислены стандартные права доступа.
Таблица 12-3. Стандартные права доступа Константа в Win32 API Значение DELETE Право удалить объект READ_CONTROL Право считывать информацию дескриптора безопасности объекта, за исключением SACL SYNCHRONIZE Право использовать объект для синхронизации. Некоторые типы объектов не поддерживают это право доступа WR1TE_DAC Право изменять DACL в дескрипторе безопасности объекта WRITE_OWNER Право менятт, владельца в дескрипторе безопасности объекта Право доступа к SACL (system access control list). Оно ограничивает право читать и вносить изменения в системную таблицу управления доступом (SACL) объекта, уп равляющую его аудитом. Операционная система разрешает доступ к SACL только при условии, что маркер доступа субъекта содержит привилегию Manage auditing and security log (Управление аудитом и журналом безопасности) (SeSecurityPrivilcge).
Объектно-зависимые права доступа. В каждом типе защищенных объектов опре делен собственный набор прав доступа.. Подробнее о списке особых прав для раз ных типов объектов Ч на Web-странице Web Resources по адресу microsoft.com/windows2000/reskit/webresources, ссылка Microsoft Platform Softv/are Development Kit (SDK).
Расширенные права В Active Directory управление пользователями, имеющими право совершать опре деленные операции с объектом или одним из его свойств, осуществляется так же, как и в файловой системе NTFS, - настройкой разрешений. Вместе с тем семанти ка некоторых операций не связана с определенными свойствами. Этим операциям Безопасность в распределенных системах 530 ЧАСТЬ тоже может потребоваться управление доступом. Например, предоставление или отказ в праве Send Ля (Отправить как), которое обычно проверяют программы элек тронной почты для выяснения, разрешено ли пользователю отправлять почту от лица другого пользователя. Средства управления доступом к нестандартным дей ствиям или операциям называются расширенными правами (extended rights), Расширенные права не определяются маской доступа. У каждого расширенного права имеется свой глобально уникальный идентификатор (GUID). Ему соответ ствует объект класса control AccessRight, хранящийся в папке расширенных прав Extended-Rights container контейнера конфигурации леса. Запись управления до ступом (АСЕ), которая предоставляет расширенное право, содержит GIJID, соот ветствующий определенному объекту класса control Access Right.
Список расширенных прав не является чем-то раз и навсегда определенным. Раз работчики могут создавать новые расширенные права для нестандартных операций, добавляя объекты класса control Access Right в контейнер расширенных прав леса. Под робнее о создании расширенных прав Ч на Web-странице Web Resources по адресу ссылка Microsoft Platform Software Development Kit (SDK), Средства служебной программы ADS I Edit позволяют просмотреть содержание контейнера конфигурации, чтобы узнать расширенные права, определенные в лесе, Дабы отобразить все множество расширенных прав, определенных в лесе, запусти те служебную программу ADSI Edit, разверните узел Configuration и щелкните контейнер Extended-Rights. На риг. 12-5 показан контейнер расширенных прав леса в окне программы ADSI Edit.
Name control A cces5 Right щ CNЩ Abandon-Replication '51 Edit Щ CW=Add-GLIIP :ontrci[A;
cessRioht Configurator Container О CN=C о г'igu ration, DC=reskitjDC= com s If] CN=<4locate-F'id5 zontrol Ac cess Right control AccessRight !+! LJ CN=DisplaySpecifie-rs jl] с N=C ertifi cat e- Enrollment contrcHAccessRight Хt.1 LJ CNЧLostAndFoundConfig Щ CTJ=Change- Darn a in- Master controlAccessRight Ш LJ С N=Partitions [Щ CTJ=Chanqe-Inf i astructure-M.. control AccessRight Я О CN=Physlcai LocaOons @] CN=Change-PDC Й Cj CM=Services :ontrol AccessRight ffl LJ CN-Sites :ontrol AccessRight -Х | ;
N=Well Несмотря на то, что операционная система по-разному обращается с обычными и расширенными правами доступа, в интерфейсе пользователя эта разница незамет на. Расширенные права отображаются наряду с обычными разрешениями на вклад ке Security (Безопасность) страниц свойств объектов. Управляют расширенными правами так же, как и разрешениями, устанавливая флажок соответствующего параметра. ГЛАВА 12 Управление доступом Права пользователей Право пользователя - это разрешение совершить операцию, которая оказывает влияние на всю систему, а не на отдельный ее объект. Существует два типа прав пользователей: права на вход а систему (logon rights) и привилегии (privileges). Пра ва на вход в систему регламентируют способ доступа к компьютеру (с клавиатуры, по сети, как служба или как задание пакетной обработки) пользователей и прочих участников безопасности. Привилегии определяют, кому предоставлено право vn равлять системными ресурсами Ч устанавливать системное время, загружать и выг ружать драйверы устройств, производить архивирование или восстановление фай лов и папок, а также выполнять другие действия, влияющие на всю систему в це лом. Полный список прав пользователей и их описание Вы найдете в приложении Г Права пользователей. В отличие от разрешений, которые предоставляются владельцем объекта, права пользо вателя определены и настраиваются в политике безопасности компьютера. Чтобы уз нать о правах пользователей на компьютере, войдите в систему под административ] гой учетной записью, откройте папку Administrative Tools (Администрирование) в Control Panel (Панель управления) и запустите Local Security Policy (Локальная политика безопасности). На рис. 12-6 показан контейнер User Rights AssigNment (Назначение прав пользователя) в политике безопасности компьютера, входящего в домен. 1. Effective Setting. S3 Act as part of the operating system [WAM_SEA-NA-LX-0:,N0; 1 Security Settings.a)Add workstation; to domam Authenticated Users -.' Jj Account Policies jHfj Back up files and directories Backup Operate, Server Ooeratоrs,Backup Operators,... -"Х5 Local Policies i.,.. ^JBypass traverse ctechng Authenticated Users,AdministratorSjE... j ,Administrators 1+1 'U? Security Options MO]Create a pagefile Administrator; Administrators,IWAM_SEA-fJA-DC-01,,,. Qj Public Key Policies ^Create a token object IWAM_SEA-NA-DC-01,NOAM\IWAM_.. Л IP Security Policies on Local Meeh 5!у Create permanent shared objects IWAM_SEA-riA-DC-CfJNQAMUWAM_,.,.N^Debug pracirams Adrmnistrators,IWAM.,5EA-rJA-DC-01,,., ^Deny access to this camputsr from t.. Щоепу boon as a batcn job.jjajDeny logoci as a service RJyDeny logon locally ?д]ЕпаЫе computer and user account; .. Х Server Operators,Admrnstrator! aa]Fcirce shutdown from a remote system Administrator Sol Generate security audits IWAM SEA-rJA-DC-Ql.NOAMUWAM -! _'J Рис. 12-6. Назначение прав пользователей Подробнее об использовании оснастки Local Security Policy (Локальная политика безопасности) конфигурирования локальной политики безопасности Ч в главе книги Распределенные системы. Книга 2. Ресурсы Microsoft Windows 2000 Server. (Русская Редакция, 2001). Конфликты между привилегиями и разрешениями В большинстве случаев конфликты между привилегиями и разрешениями воз] ги кают, когда права, необходимые для администрирования системы, пересекаются с правами владения ресурсами. В такой ситуации привилегия обладает более высо ким приоритетом, чем разрешение. Безопасность в распределенных системах 532 ЧАСТЬ Например, для выполнения стандартной административной задачи архивирования файлов и папок программа архивирования должна открыть все папки в томе NTFS, получить список объектов в каждой из них, прочитать атрибуты всех файлов и дан ные в файлах, для которых установлен атрибут архивирования. Практически не возможно согласовать предоставление такого доступа с владельцами всех файлов и папок, поэтому все необходимые права включают в привилегию Back up files and directories (Архивирование файлов и каталогов, SeBackupPrivilege). По умолчанию она предоставляется двум встроенным группам Ч Administrators (Администрато ры) и Backup Operators (Операторы архива). Любой обладающий этой привилеги ей пользователь может получить доступ ко всем файлам компьютера для архиви рования системы. Эта привилегия не дает права доступа к файлам и папкам для выполнения любых других действий. Оператор архива не сумеет, например, от крыть файл в редакторе, если, конечно, владелец файла явно не предоставил ему такое разрешение. Способность стать владельцем файлов и других объектов Ч еще один пример того, как необходимость поддержки системы администратором берет верх над правом пользователя управлять доступом. Обычно владельцем объекта становятся только при наличии соответствующего разрешения от текущего владельца. Для этого тот должен установить разрешение Take Ownership (Смена владельца) на объекте тома NTFS. В Active Directory аналогичное разрешение называется Modify Owner (Сме на владельца). Получив такое разрешение, новый владелец может делать с объек том все, что угодно, вплоть до запрета доступа к нему предыдущему владельцу. Ста новится понятно, почему пользователи неохотно предоставляют разрешение Take Ownership (Смена владельца) или Modify Ownership (Смена владельца). Вместе с тем, случается, сотрудники увольняются из компании, не позаботившись о переда че владения принадлежащих им ресурсов. В этом случае Вам пригодится привиле гия Take ownership of files or other objects (Овладение файлами или иными объек тами, SeTakeOwnershipPrivilege). Обладающий этой привилегией пользователь вправе стать владельцем объекта без разрешения текущего владельца. По умолча нию эта привилегия назначается только встроенной группе Administrators (Адми нистраторы). Обращаться с ней надо ответственно: она позволяет администраторам стать владельцем бесхозных ресурсов и передать их другим пользователям с по мощью разрешения Take Ownership или Modify Ownership. Идентификаторы безопасности Идентификатор безопасности (security ID, SID) Ч это уникальное выражение пе ременной длины, служащее для идентификации участника безопасности или груп пы безопасности. Windows 2000 использует SID в следующих компонентах управ ления доступом: Х в маркерах доступа (access token). Один SID в маркере доступа идентифициру ет клиента, представленного этим маркером, а дополнительные S1D Ч группы безопасности, членом которых является этот пользователь; Х в дескрипторах безопасности (security descriptor). Один SID в дескрипторе бе зопасности объекта идентифицирует владельца объекта, а другой Ч основную группу владельца; ГЛАВА 12 Управление доступом Х в записи управления доступом (access control entry, АСЕ). Каждая АСЕ содер жит SID, идентифицирующий пользователя или группу, для которой доступ раз решен, запрещен или отслеживается системой аудита. SID учетной записи или группы создается системой в момент ее создания. SID ло кальной учетной записи или группы создается администратором локальной безо пасности (Local Security Authority. LSA) компьютера и хранится вместе с осталь ной информацией учетной записи в защищенной области реестра. SID доменной учетной записи или группы создается центром безопасности (security authority) домена и хранится в виде атрибута объекта пользователь или группа в Active Directory. SID уникальны в пределах области применения идентифицируемой учетной запи си или группы. S1D локальных учетных записей и групп уникальны на компьюте ре, где они были созданы, то есть один SID не может принадлежать двум учетным записям или группам данного компьютера. Аналогично SID всех доменных учет ных записей и групп уникальны в пределах предприятия. SID любой созданно i и домене учетной записи или группы никогда не совпадает с SID учетной записи или группы, созданной в другом домене того же самого предприятия, S1D также уникальны во времени. Центры безопасности никогда не создают один и тот же SJD дважды и не используют повторно SID удаленных учетных записей. Предположим, у Алисы есть учетная запись в домене Windows 2000, она увольня ется, а затем вновь возвращается в ту же компанию, но на другую должность. При увольнении Алисы администратор удалил ее учетную запись, а вместе с ней и SI D, Когда Алиса возвратится на новую должность в ту же компанию, администратор создаст новую учетную запись, a Windows 2000 для нее Ч новый SID. Этот идеи" и фикатор безопасности не совпадает со старым, и поэтому пи одно из предоставлен ных старой учетной записи прав доступа не перейдет к новой учетной записи Али сы. Таким образом, две учетные записи Алисы представляют двух совершенно раз ных участников безопасности. Структура идентификатора безопасности Идентификатор безопасности (security identifier, SID) это структура данных в двоичном формате, содержащая переменное число значений. Первые значения в этой структуре несут информацию о структуре SID, а остальные обозначают создав шие SID центры безопасности (например, Windows 2000) и домен, а также опреде ленного участника безопасности или группу. На рис. 12-7 показана структура S1D. Число разделов Зарезервировано Редакция Источник идентификатора Раздел [1] Ч Доменный идентификатор Раздел [п] Ч Относительный идентификатор Рис. 12-7. Структура SID Далее перечислены элементы структуры SID. Безопасность в распределенных системах 534 ЧАСТЬ Редакция (Revision) Ч это версия структуры данного SID. Всем идентификато рам безопасности, созданным Windows NT и Windows 2000, присваивается номер редакции 1. Источник идентификатора (Identifier authority) это идентификатор центра бе зопасности наивысшего уровня, способный создавать SID для данного типа участ ников безопасности. Например, идентификатор центра безопасности SID группы Everyone (Вес) равно 1 (World Authority), а идентификатор отдельных учетных за писей или групп Windows NT и Windows 2000 - 5 (NT Authority), Разделы (Subauthorities) набор идентификаторов одного или более подчиненных центров безопасности (это наиболее важная информация в SID). Совместно все эти значения, за исключением последнего, идентифицируют домен в предприятии. Эта часть набора называется доменным идентификатором (domain identifier). Последнее значение набора идентифицирует относящуюся к домену учетную запись или груп пу. Это значение является относительным идентификатором (relative identifier, RID). Компоненты SID можно представить более наглядно, преобразовав SID из двоичного в строчный формат: S-R-X-Y'-Y2-.,.-Yr-'-Yn, где: Х S Ч свидетельствует, что строка является SID; Х R номер редакции; Х X Ч источник идентификатора; Х Y Ч набор разделов где п количество значений, соответствующее значению поля Число разделов (Suhauthority Count) на рис. 12-7. Наиболее важная информация SID представлена в наборе разделов. Первая часть набора (-Y'-Y^.-.-Y"" 1 ) Ч это доменный идентификатор. Эта часть S1D важна для предприятий с несколькими доменами, так как именно доменный идентификатор позволяет различать SID-идентификаторы, созданные в разных доменах. После дний элемент в ряду значений разделов (-Y") это относительный идентифика тор, позволяющий различать учетные записи или группы внутри домена. В домене не может быть двух учетных записей или групп с одинаковыми относительными идентификаторами. Вот пример SID встроенной группы Administrators (Администраторы) в стандар тизованном строковом представлении SID: S-1-5-32- В этом SID: Х номер редакции Ч 1; Х источник Ч 5 (NT Authority); Х доменный идентификатор Ч 32 (Builtin); Х относительный идентификатор Ч 544 (Administrators). Значение доменного идентификатора в SID встроенных учетных записей и групп всегда равно 32. Эта значение идентифицирует домен Builtin, существующий на всех компьютерах под управлением Windows NT или Windows 2000. Нет необходи мости различать встроенные учетные- записи и группы различных компьютеров, поскольку область их действия локальна - либо для отдельного компьютера, либо, ГЛАВА 12 Управление доступом если в сетевом домене имеется несколько доменных контроллеров, для группы ком пьютеров, представляющих один логический компьютер. Однако встроенные учет ные записи и группы необходимо отличать друг от друга в домене Builtin, для это го в SID всех учетных записей и групп имеются уникальные относительные иденти фикаторы. Значение 544 относительного идентификатора уникально идентифициру ет группу Administrators (Администраторы). Ни у какой другой учетной записи пли группы в домене Builtin пет S1D с относительным идентификатором 544, Рассмотрим еще один пример: глобальная группа Domain Admins (Администрато ры домена) есть в каждом домене, поэтому SID каждой из них индивидуален. Так, SID группы Reskit\Domain Admins таков: S-1-5-21-1004336348-1177238915-682003330- Здесь: Х номер редакции Ч 1; Х источник Ч 5 (NT Authority); Х доменный идентификатор - 21-1004336348-1177238915-682003330 (Reskit); Х относительный идентификатор - 512 (Domain Admins). SID группы Reskit\Domain Admins отличается от SID других групп Domain Admins того же самого предприятия своим доменным идентификатором, 21-1004336348 1177238915-682003330, Никакой другой домен в предприятии не использует это значение в качестве доменного идентификатора. SID группы Reskit\Domain Admins отличается от SID других учетных записей и групп, созданных в домене Reskit, от носительным идентификатором 512. Ни у одной другой учетной записи или груп пы в домене нет SID, оканчивающегося значением 512. Выделение относительных идентификаторов Создание уникальных относительных идентификаторов для учетных записей и групп, создаваемых на изолированном компьютере и хранящихся в базе данных, управляемой локальным диспетчером учетных записей безопасности (Security Accounts Manager, SAM), не представляет особой трудности. Чтобы предотвратить повторное создание идентификаторов безопасности, SAM изолированного компь ютера просто отслеживает использованные прежде значения относительных иден тификаторов, Процесс создания уникальных относительных идентификаторов в сетевом домене более сложен. Б сетевых доменах Windows 2000 может быть несколько домен., [ых контроллеров с Active Directory, хранящих информацию учетных записей. Это оз начает, что в сетевом домене существует столько экземпляров (реплик) базы дан ных учетных записей, сколько в нем доменных контроллеров. Более того, любая из существующих реплик базы данных учетных записей доступна для записи. Новые учетные записи могут создаваться на любом контроллере домена, при этом измене ния, внесенные в Active Directory на любом из контроллеров домена, реплициру ются на все остальные контроллеры. Процесс репликации изменений в реплике базы данных учетных записей одного хозяина в реплики всех остальных хозяев называется операцией с несколькими хозяевами (multimaster operation). Процесс создания уникальных относительных идентификаторов является операци ей одиночного хозяина (single-master operation). В ней одному контроллеру домена отводится роль хозяина относительных идентификаторов (relative identifier master, Безопасность в распределенных системах 536 ЧАСТЬ или RID master). Он выделяет отдельные подмножества относительных идентифи каторов всем остальным контроллерам домена. Когда в реплике Active Directory на одном из контроллеров домена создается новая доменная учетная запись или груп па, относительный идентификатор для ее SID извлекается из пула выделенных дан ному контроллеру домена относительных идентификаторов. Когда запас относи тельных идентификаторов на контроллере домена подходит к концу, он запраши вает новый пул у хозяина относительных идентификаторов. Контроллер домена ответственен за то, чтобы относительные идентификаторы не использовались повторно. Хозяин относительных идентификаторов следит, чтобы значения относительных идентификаторов в выделяемых пулах не повторялись. Благодаря такому механизму все созданные в домене учетные записи и группы по лучают уникальные относительные идентификаторы. Подробнее об операциях одиночного хозяина Ч в главе 7 Управление операциями одиночного хозяина*. Отличия SID и QUID При создании новой доменной учетной записи пользователя или группы Active Directory сохраняет ее SID в свойстве Object-SID (objectSID) объекта пользова тель* или группа. Новому объекту также присваивается глобально уникальный идентификатор (GUID) 128-разрядное значение, уникальное не только в пред приятии, но и во всем мире. Кроме объектов-пользователей и объектов-групп, GLJID есть у всех объектов, создающихся в Active Directory. GUID каждого объек та хранится в его свойстве Object-SID (objectSID). Внутренние механизмы Active Directory применяют GUID для идентификации объектов. Например, GUID является одним из свойств объекта, которые публику ются в глобальном каталоге. Если у пользователя имеется учетная запись на пред приятии, его легко найти в глобальном каталоге по GUID-идентификатор у, Таким образом, поиск по Object-GUID Ч один из наиболее надежных способов найти не обходимый объект. Значения других свойств объекта могут меняться, но GUID Ч никогда. GUID сохраняется до конца существования объекта. Несмотря на то, что идентификаторы безопасности иногда меняются, SID объекта группа остается прежним. Люди перемещаются, и вместе с ними могут переме щаться их учетные записи, а группы остаются в доменах, в которых они созданы, Предположим, что Алиса переезжает из Северной Америки в Европу, продолжая работать в той же компании. Ее учетную запись можно переместить вместе с ней, Для этого администратору предприятия достаточно переместить ее объект пользо ватель из Reskit\Noam в Reskit\Euro. В этом случае объекту учетной записи Али сы понадобится новый SID. Так как S1D этого объекта создан в домене Noam, его часть, соответствующая доменному идентификатору, уникальна только для этого домена. В домене Euro SID учетная запись Алисы получит другой доменный иден тификатор. Соответствующая относительному идентификатору часть SID также уникальна только в пределах одного домена, следовательно, при смене домена от носительный идентификатор тоже поменяется. Таким образом, при перемещении объекта пользователь между доменами ему присваивается новый SID, который располагается в свойстве Object-SID. Перед записью нового значения старое копируется в другое свойство объекта-пользовате ля - SID-History (sIDHistory). Это свойство многозначно. Каждый раз при пере Управление доступом ГЛАВА 12 мсщении объект а-пользователя в новый домен создастся новый SID, который за писывается в свойство Object-SID, а старьте значения перемещаются в SID-HisLory. Когда пользователь входит в систему и успешно проходит проверку подлинности, служба проверки подлинности домена запрашивает у Active Directory все SID дан ного пользователя - как текущий, так и старые, а также S1D групп. Все S1D воз вращаются клиенту, подлинность которого проверялась, и включаются в маркер до ступа. При попытке пользователя получить доступ к ресурсу применяются все его SID-идентификаторы, указанные в его маркере доступа (в том числе и SID из SID History). Понятно, почему ведется история идентификаторов безопасности. Определяя по рядок доступа пользователей к ресурсу на основе их должностных обязанностей, администратору следует устанавливать его для целых групп, а не отдельных пользо вателей. Таким образом, он сможет легко корректировать доступ пользователей к ресурсам в случае изменения их должностей и перехода в другие отделы, просто удаляя их из одних групп и добавляя их в другие. Однако желательно, чтобы до ступ пользователя не зависел от перемещений его учетной записи между домени ми. Свойство SID-History позволяет это реализовать. Когда пользователь переме щается в другой домен, нет необходимости менять список управления доступом (ACL) ресурсов. Пользователь получит доступ, даже если нового SID в ACL нет, по есть старый SID, указанный в маркере доступа среди SID пользовательских групп. Причина, по которой для идентификации используются SID, а не GUID, обрат ная совместимость. В Windows NT для идентификации пользователей и групп в ACL ресурсов применяются SID. Чтобы при обновлении операционной системы не пришлось менять ACL всех ресурсов только из-за того, что новая схема лучше, в Windows 2000 списки управления доступом идентифицируют пользователей но SID, а не по GUID. ACL ресурсов Active Director}-' не исключение. Пользователь получает доступ к объекту групповой политики на основании S1D пользователя, а не GUID. Известные идентификаторы безопасности Значения некоторых SID одинаковы во всей системе. Они называются наиболее, известными SID (well-known SIDs), так как идентифицируют пользователей и груп пы общего типа. Вот некоторые S1D этой группы. Everyone (Все) (S-1-1-0) в эту общую группу автоматически включается каж дый, кто работает на компьютере, в том числе и анонимных пользователей. Источ ник этого S1D Ч 1 (World Authority). У этого SID есть только один раздел Ч 0 (Null RID). Creator Owner (Создатель-владелец) (S-l-3-0) Ч тип пользователя Creator Owner (Создатель-владелец) служит заполнителем в наследуемой АСЕ. При наследовании АСЕ система заменяет SID пользователя Creator Owner (Создатель-Владелец) на SID текущего владельца объекта. Источник этого SID Ч 3 (Creator Authority). У этого STD есть только один раздел 0 (Null RID). Principal Self (Self) (S-l-5-10) этот тип общего пользователя служит заполни) е лем (placeholder) в АСЕ объекта пользователь, группа* и компьютер в Active Directory. Разрешение, предоставленное Principal Self, дается участнику безопасно сти, который представлен объектом. При проверке доступа операционная система заменяет SID пользователя Principal Self на SID представленного объектом участ 538 ЧАСТЬ 2 Безопасность в распределенных системах ника безопасности. Источник для этого S1D 5 (NT Authority). У этого SID есть только один раздел - 10 (Self RID). Существуют и другие известные SID. Их список приведен в приложении Д Наи более известные идентификаторы безопасности*. Маркеры доступа Маркер доступа (access token) это защищенный объект, содержащий идентифи кационную информацию и сведения о привилегиях, связанных с учетной записью пользователя. Когда клиент интерактивно входит в систему или пытается создать сетевое соединение с компьютером под управлением Windows 2000, проверяется подлинность входных реквизитов пользователя. Если ее результат положитель ный, служба входа в систему возвращает SID-идептификаторы пользователя и его групп безопасности. Администратор локальной безопасности (Local Security Authority, LSA) компьютера применяет эту информацию для создания маркера до ступа, содержащего возвращенные процессом входа в систему SID и список приви легий, назначенных политикой локальной безопасности пользователю или его груп пам безопасности. Экземпляр маркера доступа прикрепляется ко всем процессам и потокам, выполняющимся в контексте безопасности пользователя. При взаимодей ствии потока с защищенным объектом или при попытке выполнить системную за дачу, для которой нужны привилегии, операционная система устанавливает уровень авторизации, проверяя прикрепленный к потоку маркер доступа. Содержание маркера доступа Маркер доступа содержит полное описание контекста безопасности процесса или потока, в том числе и данные, перечисленные ниже. Пользователь (User). SID учетной записи пользователя. Если пользователь входит в систему под учетной записью локального компьютера, его SID извлекается из базы данных учетных записей, поддерживаемой локальным диспетчером учетных записей безопасности (Security Account Manager, SAM). При входе пользователя в систему под учетной записью домена, его S1D извлекается из свойства Object-SID соответствующего объекта пользователь в Active Directory. Группы (Groups). Список SID групп безопасности, в которые входит пользователь. В этот список также включены S1D из свойства SID-History объекта пользова тель, представляющего пользовательскую учетную запись в Active Directory. Привилегии (Privileges). Список привилегий, предоставленных пользователю и его группам безопасности на локальном компьютере. Владелец (Owner). SID пользователя или его группы безопасности, который ста новится по умолчанию владельцем любого объекта, создаваемого им самим или переданного ему во владение. Основная группа (Primary Group). SID основной группы безопасности пользова теля. Эта информация используется только подсистемой POSIX и игнорируется остальной частью Windows 2000. Стандартная избирательная таблица управления доступом (Default Discretionary Access Control List). Встроенный набор разрешений, который операционная систе ма устанавливает для создаваемых пользователем объектов, если не предоставлено никакой другой информации управления доступом. Стандартная DACL предостав Управление доступом ГЛАВА ляст полный доступ для Creator Owner (Владелец-создатель) и System (Система). Подробнее об информации управления доступом, применяющейся по умолчанию для новых объектов в разделе DACL вновь создаваемых объектов далее в этой главе. Источник (Source). Процесс, который вызвал создание маркера доступа, например дис петчер сеансов, диспетчер локальной сети или сервер удаленного вызова процедур. Тип (Туре). Значение, информирующее, является ли маркер доступа основным мар кером или маркером олицетворения. Основной маркер доступа Ч это маркер до ступа, представляющий контекст безопасности процесса. Маркер олицетворение это маркер доступа, который может использоваться потоком для временной рабо ты в другом контексте безопасности, например в контексте безопасности клиента, Уровень олицетворения (Impersonation Level). Значение, которое показывает, в какой мере служба может принимать контекст безопасности клиента, представлен ного данным маркером доступа. Статистика (Statistics). Информация о самом маркере доступа. Используется внут ренними механизмами операционной системы. Ограничивающие SID (Restricting SIDs). Необязательный список SID, добавляе мый в маркер доступа процессом, обладающим полномочиями создания ограни ченного маркера. Такие SID ограничивают доступ потока до уровня более низкого, чем предоставленный пользователю. Идентификатор сеанса (Session ID). Значение, указывающее, соединен или пет маркер доступа с сеансом клиента службы терминалов. Олицетворение Олицетворение Ч это способность потока действовать в контексте безопасности, отличном от контекста процесса, к которому он относится. Олицетворение разра ботано для клиент-серверных приложений, где оно применяется в службах. Выпол няющаяся в контексте безопасности клиента служба в определенной мере является самим клиентом. Один из ее потоков использует маркер доступа, представляя удо стоверения клиента для получения доступа к объектам. Основное назначение олицетворения Ч чтобы проверка доступа выполнялась по отношению к клиенту, а не к службе. Применение клиентских реквизитов вызыва ет, в зависимости от разрешений клиента, как сужение, так и расширение доступа. Предположим, к примеру, что па файловом сервере размещены файлы с конфиден циальной информацией, защищенные средствами DACL. Чтобы клиент не мог по лучить несанкционированный доступ к информации в этих файлах, обращаясь к ним, служба олицетворяет клиента, Каждый процесс обладает основным маркером (primary marker), описывающим контекст безопасности, связанной с процессом пользовательской учетной записи. Пользователь, связанный с процессом приложения, Ч это просто человек, запус тивший эту программу. Когда же дело касается службы, то это не так. Службы выполняются под собственными учетными записями и действуют в своем контек сте безопасности. Системные службы, установленные вместе с операционной си стемой, выполняются под учетной записью локальной системы. Другие службы можно также настроить на выполнение под этой учетной записью или выдел ггь им отдельные учетные записи в локальной системе или Active Directory. Подроб Безопасность в распределенных системах 540 ЧАСТЬ нее об установке и настройке служб домена Ч в главе 5 Публикация служб в Active Directory. Основной маркер службы связан с управляющим потоком в процессе службы и с остальными потоками, действующими от лица службы. Он идентифицирует учет ную запись службы, группы этой учетной записи и ее привилегии. Эта информа ция используется при проверке доступа, когда служба запрашивает доступ к объек там, необходимый для ее собственной работы. Обслуживая клиента, служба создает отдельный рабочий поток и связывает с ним клиентский маркер доступа. Клиентский маркер доступа называется маркером оли цетворения (impersonation token). Он идентифицирует клиента, его группы и при вилегии. Эта информация используется при проверке доступа, когда поток запра шивает доступ к ресурсам от лица клиента. Завершив работу в режиме олицетворе ния, поток применяет первичный маркер и возвращается из контекста безопаснос ти клиента в собственный контекст безопасности службы. Механизм олицетворения проиллюстрирован на рис. 12-8. Серверный процесс Управляющий поток Основной Х Выполняется от лица Self маркер Х Выполняет самообслуживачие Рабочий поток ХОжидает вызов м Х Выполняет запрос клиента Х Возвращается к контексту Self Рис.12-8. Основной маркер и маркер олицетворения в службе Уровни олицетворения Олицетворение возможно, когда клиент согласен позволить серверу в определенной степени стать этим клиентом. Выбирая уровень олицетворения при подключении к службе, процесс клиента может определять, в какой степени служба способна дей ствовать от имени клиента. Устанавливая уровень олицетворения, клиент информи рует службу о пределах, в которых она имеет право действовать от его имени. Пользователи не в состоянии выбирать уровень олицетворения. Он указывается в коде клиент-серверных приложений в виде сведений о качестве службы безопасно сти (Security Quality of Service, SQoS). Существуют четыре уровня: анонимный (anonymous), идентификации (identify), олицетворения (impersonate) и делегирова ния (delegate). Анонимный уровень никогда не поддерживался. В версиях, предше ствующих Windows 2000, поддерживались только два уровня идентификации и олицетворения. В Windows 2000 добавлена поддержка уровня делегирования. Анонимный уровень. Клиент неизвестен службе. Служба может олицетворять кли ента, но маркер олицетворения не содержит никакой информации о клиенте. Управление доступом ГЛАВА 12 Уровень идентификации. Службе разрешается получить информацию идентифи кации клиента и использовать ее в собственном механизме безопасности, но не раз решается олицетворять клиента. Уровень олицетворения. Если служба находится на том же компьютере, что и кли ентский процесс, то ей разрешается доступ к сетевым ресурсам от лица клиента. Служба на удаленном компьютере может олицетворять клиента только при досту пе к ресурсам компьютера службы. Уровень делегирования. Служба олицетворяет клиента не только при доступе к ресурсам компьютера службы, но и при доступе к ресурсам других компьютеров. Этот уровень поддерживается только в Windows 2000 и последующих керсиях этой операционной системы. Настройка клиентов и служб для делегирования Олицетворение работает па уровне делегирования только при соблюдении следую щих условий: Х компьютеры, на которых выполняется клиентский процесс, серверный процесс, а также любые целевые службы, должны работать под управлением Windows и в доменах Windows 2000, так как для делегирования требуется поддержка про токола проверки подлинности Kerberos; Х необходимо, чтобы пользовательская учетная запись клиента имела разрешение на делегирование; Х учетная запись службы должна иметь разрешение па делегирование. Чтобы сконфигурировать учетную запись пользователя для делегирования, щелк ните правой кнопкой объект пользователь в оснастке Active Directory Users and Computers (Active Directory пользователи и компьютеры), в контекстном меню выберите Properties (Свойства) и в открывшемся диалоговом окне Properties (Свойства) перейдите па вкладку Account (Учетная запись). В списке параметров учетной записи найдите флажок Account is sensitive and cannot be delegated (Учет ная запись важна и не может быть делегирована) и удостоверьтесь в том, что он не установлен (рис. 12-9). Настройка учетной записи службы зависит от того, является ли она учетной запи сью локальной системы или учетной записью пользователя домена. Если служба настроена на использование учетной записи локальной системы, компьютер, на ко тором она выполняется, должен быть доверен для делегирования. Чтобы сконфи гурировать соответствующим образом учетную запись компьютера, необходимо обладать на нем привилегией Enable computer and user accounts to be trusted for delegation (Разрешение доверия к учетным записям при делегировании). Щелкни те правой кнопкой мыши объект пользователь в оснастке Active Directory Users and Computers (Active Directory Ч пользователи и компьютеры), в контекстном меню выберите Properties (Свойства) и в открывшемся диалоговом окне Properties (Свойства) перейдите на вкладку General (Общие). Найдите и установите фла жок Trust computer for delegation (Доверять компьютеру права представителя). На рис. 12-10 показано, как выглядит правильная установка. Безопасность в распределенных системах 542 ЧАСТЬ User logon. Гтвте lJ Рис. 12-9. Проверка подлинности пользователя настроена для делегирования "Х : ' ' DNS чаге. |SEA'TiA-DC-02,noan-,je; kil согг. Рис. 12-10. Учетная запись компьютера доверена для делегирования Управление доступом ГЛАВА 12 Внимание! Доверяя компьютеру делегирование, Вы позволяете делегирование всем службам, выполняющимся под учетной записью локальной системы. Таким обра зом, не вызывающая доверия служба, установленная па компьютере неосмотритель ным администратором и настроенная на выполнение в контексте локальной систе мы, может получить доступ к сетевым ресурсам, олицетворяя других пользовате лей. Предпочтительнее настроить систему так, чтобы службы, поддерживающие делегирование, выполнялись в домене под своей доменной учетной записью, кото рой управляют администраторы домена. Учетная запись пользователя домена, под которой выполняется служба, должна быть доверенной для выполнения функций представителя (делегата). Чтобы скон фигурировать учетную запись пользователя для работы со службой, щелкните пра вой кнопкой объект пользователь в оснастке Active Directory Users and Com puters (Active Directory Ч пользователи и компьютеры), в контекстном меню вы берите Properties (Свойства) и в открывшемся диалоговом окне Properties (Свой ства) перейдите на вкладку Account (Учетная запись). В списке параметров учет ной записи найдите и установите флажок Account is trusted for delegation (Учет ная запись доверена для делегирования). На рис. 12-11 показано, как выглядит пра вильная установка. Г- ; ; .-,; : Account gptigns: V R: Account is trusted fof delegation ГЩ Accoutii il -ieiijittve and cannot be delega ГЩ Use DES encryption types EoHteacceut* Г~ Do гю( tequre feiberos paeaulhentieabeift I I Рис. 12-11. Учетная запись службы, доверенная для выполнения в качестве представителя Атрибуты SID в маркере доступа S1D каждого пользователя или группы может содержать в маркере доступа о; ,ни или два атрибута, определяющих порядок обращения с S1D при поверке доступа. По этим атрибутам система определяет, что SID необходимо проверять либо во в; тх Безопасность в распределенных системах 544 ЧАСТЬ АСЕ (access control entry), либо только в записях управления доступом, запрещаю щих доступ. Атрибуты SID перечислены в таблице 12-4. Таблица 12-4. Атрибуты SID Атрибут Описание SE_GROUP_ENABLED SID с этим атрибутом используется для проверки доступа. При этом система, проверяет все АСЕ, содержащие данный SID SE_GROUP_USE_FOR_DENY_ONLY Только Windows 2000: SID с проверкой только на.ытрст (deny-only SID). При проверке доступа система проверяет только АСЕ, которые запрещают доступ этому SID, а все остальные записи управле ния доступом игнорирует Оба атрибута взаимно исключают друг друга. Если установлен один из них, другой установить нальзя. Если не установлен ни один из атрибутов, SID игнорируется. Более того, ни один процесс не имеет права удалить из S1D атрибут проверки толь ко на запрет. Ограниченные маркеры В Windows 2000 приложение может запустить дочерний процесс в ограниченном кон тексте безопасности, чтобы выполняющейся в таком процессе код обладав меньши ми полномочиями, чем пользователь данного приложения. Например, при примене нии браузера для просмотра Web-страницы в небезопасной зоне, связанный с Web страницей код может выполняться на текущем компьютере с ограниченными приви легиями. (Эта функция недоступна в Microsoft Internet Explorer версии 5.0 и более ранних.) А при получении сообщении электронной почты с вложением приложение, открывающее вложенный файл, может выполняться с ограниченным доступом к ре сурсам компьютера. (Эта функция еще не доступна в Microsoft Outlook 2000.) Приложения создают ограниченный контекст безопасности для дочерних процес сов и потоков олицетворения, присваивая им ограниченные маркеры (restricted token). Такие маркеры создаются путем отзыва отдельных привилегий Ч установ кой атрибута проверки только на запрет в отдельных SID или добавлением списка ограничивающих SID к основному маркеру доступа. Когда ограниченный таким образом процесс или поток пытается получить доступ к защищенному объекту, система дважды проверяет доступ: сначала вес обычные SID и SID проверки только на запрет, после чего - ограничивающие SID. Доступ предоставляется только в том случае, если результаты обеих проверок Ч удовлет ворительны и запрошенные права доступа разрешены. Подробнее о том, как создаются приложения, использующие ограниченные марке ры на Web-странице Web Resources но адресу windows2000/reskit/webresources, ссылка Microsoft Platform Software Development Kit (SDK). Дескрипторы безопасности Связанная с объектом информация управления доступом содержится в дескрипто ре безопасности (security descriptor) объекта. Когда пользователь пытается выпол нить над объектом какие-либо действия, операционная система проверяет дескрин ГЛАВА 12 Управление доступом тор безопасности объекта, чтобы установить, разрешены ли пользователю такие операции. Информация, которая включается в дескриптор безопасности, зависит от типа объекта и от того, как этот объект был создан. В общем случае дескрипторы безо пасности содержат следующие данные: Х какие пользователи владеют объектом; Х каким пользователям и группам разрешен или запрещен доступ; Х для каких пользователей и групп должен вестись аудит доступа; Х как объекты в контейнере наследуют от пего информацию управления доступом. Части дескриптора безопасности Дескриптор безопасности представляет собой двоичную структуру данных перемен ной длины. Бот из каких частей состоит дескриптор безопасности, Заголовок (Header) Ч содержит номер редакции и набор управляющих флагов, описывающих некоторые характеристики дескриптора безопасности порядок раз мещения в памяти, наличие отдельных элементов дескриптора, а также как добав лялись и изменялись отдельные элементы, Владелец (Owner) Ч содержит SID владельца объекта. Владелец объекта может изменять разрешения и предоставлять другим пользователям право становиться владельцем. Основная группа (Primary Group) Ч содержит SID основной группы владельца. Эта информация используется только подсистемой POSIX и игнорируется остальной частью Windows 2000. Избирательная таблица управления доступом (Discretionary Access Control List, DACL) Ч является списком, состоящим из записей управления доступом (access control entry, АСЕ). Таких записей может быть несколько, или они могут вообще отсутствовать. У каждой АСЕ имеется заголовок, информирующий о том, разрегпа ет или запрещает данная АСЕ доступ к объекту, SID определенного пользователя или группы и маска доступа, в которой перечислены операции. Содержанием DACL управляет владелец объекта. Владелец может дать полномочия управления другим пользователям, предоставив им разрешение Change Permissions (Смена разрешений Х WRITE_DACL). Системная таблица управления доступом (Sysiein Access Control List, SACL). SACL похожа на DACL, но она используется для проведения аудита, а не для управления доступом к объекту. При совершении подлежащего аудиту действия операционная си стема регистрирует событие в журнале безопасности. У каждой записи управления доступом в SACL есть заголовок, в котором описано регистрируемое событрте (успех, отказ или и то и другое), SID, указывающий, за каким пользователем или группой бе зопасности необходимо следить, и маска доступа, в которой перечислены подлежащие аудиту операции. Содержанием SACL управляют администраторы безопасности ло кальной системы Ч пользователи, обладающие привилегией Manage auditing and security log (Управление аудитом и журналом безопасности). По умолчанию эта п] \и вилегия назначается встроенной группе Administrators (Администраторы). Размещение в памяти Существуют два типа размещения дескриптора безопасности в памяти: с относи тельной или абсолютной адресацией. Управляющий флаг в заголовке дескриптора Безопасность в распределенных системах 546 ЧАСТЬ безопасности указывает, какой из этих двух форматов используется в данном деск рипторе безопасности. Дескриптор безопасности с относительной адресацией (self-relative) хранится в не прерывном блоке памяти, и местоположение его элементов выражается в виде сме щения от начала этого блока. Для определения адреса любой части дескриптора бе зопасности процессу достаточно получить начальный адрес дескриптора безопас ности. Указатель на нужный элемент дескриптора безопасности процесс определя ет, добавляя к этому адресу величину смещения соответствующего элемента. (По этому его название Ч дескриптор с относительной адресацией. Адреса его частей отсчитываются от его начала.) На рис. 12-12 показан пример размещения дескрип тора безопасности с относительной адресацией. Смещение Рис. 12-12. Дескриптор безопасности с относительной адресацией Относительная адресация используется в дескрипторах безопасности объектов, ко торые должны храниться на диске, передаваться при помощи коммуникационного протокола или копироваться в память. Дескриптор безопасности с абсолютной адресацией (absolute) содержит не саму ин формацию, а указатели к ней. Этот формат позволяет располагать компоненты дес криптора безопасности по отдельности и собирать их в процессе работы. Он при меняется для объектов, которым не требуется постоянное хранилище, например для объектов, существующих только в течение жизни отдельного процесса. На рис. 12 13 показан пример размещения дескриптора безопасности с абсолютной адресаци ей. Рис. 12-13. Дескриптор безопасности с абсолютной адресацией Управляющие флаги дескриптора безопасности Заголовок дескриптора безопасности содержит набор управляющих флагов, ко торые уточняют значение дескриптора безопасности или его компонентов. В Windows 2000 управляющие флаги играют важную роль в автоматическом перено се наследуемой информации безопасности от родительских (контейнерных) объек тов к дочерним (вложенным) объектам. Управление доступом ГЛАВА 12 Управляющие флаги дескриптора безопасности хранятся в битовом поле и изменя ются установкой или сбросом отдельных бит. Управляющие флаги дескриптора безопасности перечислены в таблице 12-5. Таблица 12-5. Управляющие флаги дескриптора безопасности Флаг Значение SE DACL AUTO INHERITED Wndows 2000: наследуемые записи управления досту пом в DACL этого объекта переносятся на существую щие дочерние объекты. Этот флаг не устанавливается в дескрипторах безопас ности Windows NT, которая не поддерживает автомати ческий перенос наследуемых АСЕ SE DACL DEFAULTED DACL установлена по умолчанию, Этот флаг влияет на то, как операционная система рас поряжается DACL в отношении наследования. Операци онная система игнорирует этот флаг, если не установлен SE_DACL_PRESENT ' SE DACL PRESENT Дескриптор безопасности содержит DACL, Windows 2000: если этот флаг не установлен (DACL в дескрипторе безопасности отсутствует), необходимо установить SE_DACL_PROTECTED. Иначе операцион ная система признает дескриптор безопасности недей ствительным SE DACL PROTECTED Windows 2000: DACL дескриптора безопасности не мо жет изменяться наследуемыми АСЕ. Если.этот флаг w установлен, дескриптор безопасности наследует инфор мацию от дескриптора безопасности родительского объекта SID основной группы установлен по умолчанию SE_GROUP_DEFAULTED SID владельца установлен по умолчанию SE_OWNER_DEFAULTED Windows 2000: наследуемые записи управления досту SE SACL AUTO INHERITED пом в SACL этого объекта переносятся на существую щие дочерние объекты. Этот флаг не устанавливается в дескрипторах безопас ности Windows NT, которая не поддерживает автомати ческий перенос наследуемых АСЕ SACL установлена по умолчанию. SE SACL DEFAULTED Этот флаг может повлиять на то. как операционная сис тема распоряжается SACL в отношении наследования. Операционная система игнорирует этот флаг, если не установлен SE_SACL_PRESENT Дескриптор безопасности содержит SACL SE_SACL_PRESENT Windows 2000: SACL дескриптора безопасности не мо SE_SACL_PROTECTED жет изменяться наследуемыми АСЕ Дескриптор безопасности с относительной адресацией, SE SELF RELATIVE вся информация содержится в непрерывном блоке памя ти. Если этот флаг не установлен, дескриптор безопас ности является дескриптором с абсолютно]! адресацией Источники информации управления доступом При создании объекта информация управления доступом сначала записывается и дескриптор безопасности. Впоследствии она может изменяться. В любом случае Безопасность в распределенных системах 548 ЧАСТЬ записываемую в дескриптор безопасности информацию поставляют следующие ис точники: Х субъект, Х диспетчер объекта, Х родительский объект. Во время создания нового объекта дескриптор безопасности назначается субъектом. В противном случае операционная система создает дескриптор безопасности на ос нове информации управления доступом, унаследованной от родительского объек та. Если такой информации нет, операционная система использует информацию управления'доступом по умолчанию, которая предоставляется диспетчером объек тов данного типа. После создания объекта информацию в его дескрипторе безопасности вправе кор ректировать владелец или другие пользователи, обладающие соответствующими полномочиями. Изменения могут также исходить от родительского объекта, когда его владелец изменяет дескриптор безопасности контейнера. При любом редакти ровании дескриптора безопасности объекта контейнер диспетчер объекта пере носит изменения па все вложенные объекты. Субъекты Субъектом называется поток, выполняющийся в контексте безопасности, предос тавленном маркером доступа. Маркер доступа субъекта содержит информацию, используемую для создания дескрипторов безопасности новых создаваемых им объектов и для изменения дескрипторов существующих объектов. Эта информация размещена в нескольких нолях. Владелец (Owner). Это поле маркера доступа содержит SID, идентифицирующий участника безопасности, который по умолчанию становится владельцем объектов, создаваемых субъектом. Обычно владелец по умолчанию указан в маркере досту па. Если пользователь член группы Administrators (Администраторы), поле Default Owner (Владелец по умолчанию) содержит SID не самого пользователя, а административной группы. Если пользователь входит в группу Domain Admins (Ад министраторы домена), владельцем объектов Active Directory, которые он создает или которые переходят в его владение, становится не сам пользователь, а группа администраторов домена. Когда SID из ноля Default Owner маркера доступа субъек та копируется в поле владельца объекта, в дескрипторе безопасности устанавлива ется управляющий флаг SE_OWNER_DEFAULTED. Основная группа (Primary Group). Это поле маркера доступа содержит SID основ ной группы пользователя. Когда SID из поля основной группы маркера доступа субъекта копируется в поле основной группы дескриптора безопасности объекта, в дескрипторе безопасности устанавливается флаг SE_GROUP_DEFAULTED. Стандартная DACL (Delault DACL). Это поле маркера доступа может быть пус тым или содержать избирательную таблицу управления доступом (discretionary access control list, DACL). Стандартная DACL присваивается дескриптору безопас ности нового объекта, когда не предоставлено никакой другой информации управ ления доступом. В этом случае в дескрипторе безопасности устанавливается флаг SE DACL "DEFAULTED. Управление доступом ГЛАВА 12 Диспетчеры объектов Диспетчер объекта (objeci manager) может в определенных случаях предоставлять новым объектам информацию безопасности по умолчанию. Требования к объектам разных типов отличаются, поэтому каждый тип обслуживается своим диспетчером объекта. В таблице 12-6 перечислены стандартные типы объектов и диспетчеры каждого из них. Таблица 12-6. Диспетчеры объектов стандартных типов Тип объекта Диспетчер объекта Файлы и папки Файловая система NTFS Общие ресурсы Служба сервера (Server Service) Объекты Active Directory Active Directory Разделы реестра Реестр Контроллеры служб (Service Control Manager) Службы Диспетчер очереди печати (Print spooler) Принтеры Диспетчер окон (Window Manger) Терминалы, оконные станции, рабочие столы и окна Подробнее о разрешениях по умолчанию, предоставляемых диспетчерами объек тов. - в справочной системе Windows 2000 Server, раздел Объекты и диспетчеры объектов. Родительские объекты Некоторые объекты способны включать в себя другие объекты. Например, объект папка NTFS может содержать объекты-файлы и другие объекты-папки, а объект раздела реестра Ч объекты-подразделы. В Active Directory объект подразделение содержит другие объекты-подразделения, а также объекты пользователь, груп па и компьютер. Объекты терминал могут содержать объекты локонная стан ция (windows station), содержащие рабочий стол, которые, в свою очередь, яв ляются контейнером для объектов локно. Любой объект внутри другого объек та называется дочерним объектом или потомком (child object). Контейнер дочерне го объекта называется родительскими объектом (parent object). Потомку разрешается наследовать информацию управления доступом от родитель ских объектов. Предположим, администратор сервера создал общий файловый ре сурс, состоящий из одной папки PublicS, предназначенной для хранения информа ции, предоставляемой в общее пользование. Поэтому администратор установил раз решения, показанные на рис. 12-14. Ни одно из разрешений, показанных на рис. 12-14, не получено путем наследова ния, потому что администратор снял флажок Allow inheritable permissions frnm parent to propagate to this object (Переносить наследуемые от родительского объекта разрешения на этот объект). Это действие администратора вызвало уста новку управляющего флага SE_DACL_PROTECTED дескриптора безопасности, предохраняющего DACL дочернего объекта от наследования этой таблицы от ро дительского объекта. Приобретенные в результате наследования разрешения называются унаследованны ми (inherited permission). Разрешения, назначенные не по механизму наследования, называются установленными явно (explicit permissions). Один из способов отличить явно установленное разрешение от унаследованного выделить элемент в списке Безопасность в распределенных системах 550 ЧАСТЬ Permission Entries (Элементы разрешений) и прочитать отображаемый под спис ком текст. На рис. 12-14 выбран второй элемент разрешений, а текст под списком гласит This permission is defined directly on this object (Это разрешение определе но непосредственно в этом объекте). Другими словами, данное разрешение являет ся не унаследованным, а установленным явно. Modify This folder only Read Execute Пои Everyone This folde', subfclder; and dies АИо'.ч inheritable peiim.^ris ftcn parent to propagate la lh c-biлci Reset peirHiTiions or eJ^ild ob|ei.W and enable propagation of irih Рис. 12-14. Окно настройки параметром управления доступом папки PublicS [Владелец: группа Administrators (Администраторы)] Кроме того, в тексте на рис. 12-14 содержится сообщение This permission is inherited by child objects (Это разрешение наследуется дочерними объектами). Разрешения, переносимые с родительского объекта на дочерние, называются наследуемыми раз решениями (inheritable permissions). Чтобы выяснить, какие из разрешений, уста новленных на родительском объекте, являются наследуемыми, достаточно взгля нуть в столбец Apply to (Применять) панели Permission Entries (Элементы разре шений). Текст This object only (Только для этого объекта) или This folder only (Только для этой папки) сообщает, что разрешение не наследуется дочерними объектами. Из четырех разрешений на рис. 12-14 три Ч наследуемые, а одно нет. Проиллюстрируем наследование разрешений. Предположим, что Алиса создала в PublicS подпаттку. Будучи инженером, она назвала свою папку Engineering Data, Так как новый объект-папка Ч дочерний по отношению к PublicS, его DACL наследует разрешения из DACL объекта PublicS. Разрешения на новом объекте показаны па рис. 12-15. Обратите внимание, что Алиса не сбросила флажок Allow inheritable permissions from parent to propagate to this object (Переносить наследуемые от родительского объекта разрешения на этот объект), поэтому наследуемые разреше ния из DACL родительского объекта наследуются дочерним объектом. Унаследо ванные разрешения помечены неактивным (бледным) ярлыком связка ключей. Такие разрешения действительны Ч нельзя только изменять параметры элемента. Унаследованные разрешения определяются на родительском объекте, поэтому для их корректировки достаточно модифицировать DACL родительского объекта. ГЛАВА 12 Управление доступом Full Control This foioei only ; ..', Allow Subfoldeis and files onlji dealer Qwnei ull Control >Ч Allow Fiead&E*ec Tn : k№' iubfolders and file Everyone Ji?'Alkws mhenraoiij pel mission? horn patent to propagate to tiasobjeEf jЧ Reset pei missions un all child objects and enable'ptopagalion of n Рис. 12-15, Окно настройки параметров управления доступом папки Engineering Data (владелец Ч Алиса) Несмотря на то, что унаследованные разрешения не подлежат редактированию, вла делец дочернего объекта вправе добавлять в его DACL явно устанавливаемые раз решения. Предположим, что Алиса считает унаследованные разрешения, предостав ленные Creator Owner (Создатель-владелец), слишком строгими, поскольку они позволяют вносить изменения в файл только создавшему его пользователю. Ей же нужно, чтобы все члены группы Engineering могли редактировать и добавлять ин формацию в папку Engineering Data. Для этого она назначает этой группе явное разрешение, позволяющее изменять все находящиеся в папке объекты. Если Алиса полагает, что сотрудники отдела маркетинга не должны работать с информацией в папке Engineering Data, она может явным образом запретить группе Marketing пол ный доступ к этой папке, ее подпапкам и файлам. Результат изменений, внесенных Алисой в параметры управления доступом, показан на рис. 12-16, Теперь в списке элементов разрешений на рис. 12-16 имеются два явных разреше ния, помеченных ярлыками, информирующими, что эти элементы можно редакти ровать. Обратите внимание: явные разрешения размещаются вверху списка. Они расположены именно в том в порядке, в котором обрабатываются во время провер ки доступа. Явные разрешения расположены перед унаследованными, потому что они обрабатываются первыми. Расположение элементов обусловлено предположе нием, что владелец дочернего объекта добавляет явные разрешения для уточнения унаследованных разрешений. В нашем примере (рис. 12-16) унаследованное разре шение позволяет группе Everyone (Все) читать содержимое папки, гтодпапок и фай лов. Алиса добавила явное разрешение, запрещаюшее полный доступ подмножеству группы Everyone Ч группе Marketing. Запись с явным запрещением расположен перед унаследованными элементами, поэтому он обрабатывается раньше любого кз унаследованных элементов. Безопасность в распределенных системах 552 ЧАСТЬ Engineering AdmhishdtorsfNQAMV. Full Conliol r ul Control ЛВсе (NOAM Wee] Full Control and lies onty Cteatoi Owner Read&Enec s ID (aide is and files View/Edif. Allow inheiitabls реттЬъюп; iie-ir caienl to p Kpagate So ihii etjsct RegaS penwssionf on all c--fcl objec-si апё e Рис. 12-16. Окно с измененными параметрами управления доступом для папки Engineering Data Алиса установила оба явных разрешения для This folder, subfolders, and files (Для этой папки, ее подпапсж и файлов), поскольку дочерние объекты в ее папке долж ны наследовать новые разрешения. Если бы папка Engineering Data располагалась на сервере под управлением Windows NT, новые явные разрешения распространя лись бы только на вновь создаваемые в ней объекты. Модель управления доступом, используемая Windows NT, поддерживает наследование только в момент создания объекта. Чтобы изменить разрешения для существующих объектов, Алисе при шлось бы дополнительно установить явные разрешения для каждой существующей подпапки и файла. Нововведение Windows 2000 - это наследование после созда ния (то есть для уже существующих объектов). Новые или измененные; наследуе мые разрешения в DACL родительского объекта автоматически переносятся на су ществующие дочерние объекты при изменении DACL родителя. В только что опи санном примере элемент, запрещающий группе Marketing доступ к папке Engineering Data, распространится на подпапки. как только Алиса щелкнет Apply (Применить) в диалоговом окне Access Control Settings (Параметры управления доступом). Автоматический перенос наследуемых разрешений - это мощный метод, позволяю щий изменять разрешения во всем дереве объектов, редактируя разрешения только на объекте верхнего уровня дерева. Предположим, что член группы Administrators (Администраторы) решил, что информация в папке PublicS и ее подпапках больше не предназначена для всех, и доступ к ней нужно закрыть группе Everyone (Все), так как в нее входят все пользователи, обладающие доступом к сети, в том числе и анонимные пользователи и гости. Доступ к папке PublicS предполагается предос тавить группе Authenticated Users (Прошедшие проверку), в которую входят толь ко пользователи, прошедшие проверку подлинности. Таким образом, требуется про сто заменить Everyone (Все) на Authenticated Users (Прошедшие проверку) в двух элементах списка разрешений, как показано на рис. 12-17. Управление доступом ГЛАВА 12 Entries Permission, Authenticated User: Read (, Exe This folder, subloldore an Allow Authenticated Users Modify Т his folder onij Allow CREATOR OWNER FullGonbol Subfolders and files only Рис. 12-17. Окно с измененными параметрами управления доступом для папки PublicS После изменений параметров управления доступом родительского объекта все на следуемые разрешения из DACL родительского объекта автоматически переносят ся в DACL подпапок и файлов. На рис. 12-18 показано, как это повлияет на разре шения группы Engineering Data. Х,.- Name J.peamjaart Marketing :N0AMl.M 2) Denv Ful Control This Iclder, wbloloers and files This folder. subWders id tiles f^ Allow Engineering (NOAMV.. Wodity This loader, ?ubfolders and hies 3\ Allow Admh Orators [WO A. Full Control ' '. Х ^4Allow Alice (NDAMWIice] Full Control ' CREATOR OWNER Ful Control jubfcilders and ISes only The peinwsfon isinheijSeiifromtt5epai,n[obieclandcii:lrols atce.^ to sh* qbject Tijstop siott5,riectl'he сИесЫмм below. Toucan eduS-eperritissfetiOnliai the сЩе$ where tt$ (ttned Т his permisaOn- is inhered by child olpcts. Afow inheritable-petmisapis I'om parent tf* propagate to ths obieei. and.enable propagation of inheritable fffirftsssions. Рис. 12-18. Новые унаследованные разрешения для группы Engineering Data Безопасность в распределенных системах 554 ЧАСТЬ Следует отметить, что перенос наследуемых разрешении с папки PublicS на пайку Engineering Data не изменяет явные разрешения в дочернем DACL. Перенос насле дуемых разрешений па существующие дочерние объекты заменяет только унасле дованные разрешения. Вместе с тем, если явные разрешения тоже являются насле дуемыми, механизм переноса разрешений применяет их заново во время своего дви жения вниз но дереву. Например, оба явных разрешения, добавленные Алисой к DACL своей папки, наследуются дочерними объектами в ней. По мере продвиже ния вниз от папки Алисы процесс переноса обнаруживает указанные дополнитель ные наследуемые разрешения и применяет их к DACL всех дочерних объектов. У владельца родительского объекта есть возможность переопределить явные раз решения, дочерних объектов. Для этого достаточно установить флажок Reset permissions on all child objects and enable propagation of inheritable permissions (Сбросить разрешения для всех дочерних объектов и включить перенос наследуе мых разрешений) в диалоговом окне Access Control Settings (Параметры управле ния доступом) - в этом случае механизм переноса разрешений аннулирует явно ус тановленные разрешения дочерних объектов. Далее надо установить флажок Allow inheritable permissions from parent to propagate to this object (Переносить насле дуемые от родительского объекта разрешения на этот объект), то есть снять защи ту от наследования, возможно, установленную владельцем(ами). Назначение и изменение владельца У каждого объекта в Active Directory или на томе NTFS есть владелец, обычно это создавший его пользователь. Владелец обладает неявным правом позволять или запрещать другим пользователям работать с этим объектом, и это право нельзя от менить. Наряду с другими разрешениями владельцы могут давать пользователям разрешение Change Permission (Смена разрешений) (\VRITE_DACL). В отличие от неотъемлемого права владельца это разрешение может быть отозвано. По умолчанию владельцем нового объекта является участник безопасности, указан ный как владелец по умолчанию в маркере доступа, прикрепленном к создающему процессу. При создании объекта SID из поля владельца маркера доступа копирует ся в поле владельца дескриптора безопасности. Обычно владельцем по умолчанию становится текущий пользователь и системе. Исключение Ч когда пользователь входит в группы Administrators (Администраторы) или Domain Admins (Админис траторы домена). Тогда поле владельца пользовательского маркера доступа содер жит SID группы, а не SID отдельной учетной записи пользователя. И это оправда но: административные учетные записи должны применяться исключительно для администрирования системы, а не для каких-либо других целей. Таким образом, созданными одним администратором объектами могут управлять другие админис траторы той же группы. Если административная группа, например Administrators (Администраторы), вла деет объектом, неотъемлемое право владельца изменять разрешения для этого объекта принадлежит всем и каждому члену этой группы. Эта возможность зачас тую неизвестна администраторам. Предположим, войдя в систему под учетной за писью члена группы Administrators (Администраторы), Алиса создала файл и зап ретила Бобу изменять его. Владельцем файла становится не сама Алиса, а группа Administrators, поэтому, если Боб также член группы Administrators, он получает право Change Permissions (Смена разрешений) и, значит, вправе предоставить себе разрешение изменять файл, невзирая на попытки Алисы запретить ему это, Управление доступом ГЛАВА Предоставляя разрешение Take Ownership (Смена владельца), владельцы объектов NTFS могут давать другим пользователям возможность становиться владельцами. Аналогичное разрешение по отношению к объектам Active Directory и их владель цам называется Modify Owner (Смена владельца). Оба разрешения относятся к од ному и тому же праву доступа - WR1TE_O\VNER. Единственное различие между ними - разные названия в оригинальном пользовательском интерфейсе. Кроме того, пользователи с привилегией Take ownership of files or other objects (Овладе ние файлами или иными объектами) (SeTakeOwnershipPnvilegc) могут становить ся владельцами без разрешения. По умолчанию эта привилегия назначается только группе Administrators (Администраторы). Когда пользователь становиться владельцем объекта, S1D владельца по умолчанию в пользовательском маркере доступа копируется в поле владельца дескриптора бе зопасности объекта. Если владение переходит к члену группы Administrators (Ад министраторы) или, для объектов Active Directory, к члену группы Domain Admins (Администраторы домена), владельцем по умолчанию становится группа, а не от дельный пользователь. На рис. 12-19 показана вкладка Owner (Владелец) объекта папки, созданной Бобом, членом группы Administrators (Администраторы). Рис. 12-19. Вкладка Owner (Владелец) объекта-папки Невзирая на то, что папку создал Боб, на вкладке Owner (Владелец) указан теку щий владелец объекта Ч группа Administrators (Администраторы). При создании объекта SID из поля владельца по умолчанию маркер доступа Боба помещается в поле владельца дескриптора безопасности объекта. Так как Боб является членом группы Administrators (Администраторы), указанная в его маркере доступа в каче стве владельца по умолчанию группа администраторов становиться владельцем объекта. На рис. 12-19 показано, что Боб может сам стать владельцем этого объек та. Для этого ему надо просто выбрать свое имя в списке Change owner to (Изме нить владельца на) и щелкнуть Apply (Применить). Даже если Боб станет владеть Безопасность в распределенных системах 556 ЧАСТЬ цем, любой член группы администраторов сможет вернуть право владения от лица группы. На самом деле член группы администраторов имеет право стать владель цем любого объекта независимо от того, кто первоначально им владел. Эта функ ция встроена в систему, и ее невозможно отключить. Следует обратить внимание на то, что на вкладке Owner (Владелец) (рис. 12-19) имеется флажок Replace owner on all suhcontainers and objects (Заменить вла дельца подконтейнеров и объектов). Став владельцем этой папки, Боб одновремен но может стать владельцем всех ее подпапок и файлов. Такое право дает ему член ство в группе администраторов. Обычным пользователям это доступно, только если в дополнение к разрешению Take Ownership (Смена владельца) родительского объекта им предоставлено такое же разрешение для всех дочерних объектов. На вкладке Owner (Владелец), показанной на рис. 12-19, отсутствует флажок, по зволяющий передавать право владения другим пользователям. Таким образом обес печивается защита от возможного злоумышленника. В противном случае он мог бы стать владельцем, выполнить ошибочные или вредоносные действия, а потом скрыть следы, передав владение кому-нибудь другому. Однако такая функция реа лизована для программ. Если у процесса имеется доступ \VRITE_OWNER к объек ту, он может записывать новую информацию в поле Owner (Владелец) дескрипто ра безопасности объекта. Чтобы проследить за изменением владения объектами, достаточно включить аудит событий смены владельца. На рис. 12-20 показано, как включен аудит всех попы ток доступа Take Ownership (Смена владельца) к папке верхнего уровня PublicS, всех ее подпапок и файлов. При каждой смене владельца в журнале безопасности регистрируется соответствующее событие. i and files" Рис. 12-20. Вкладка Auditing (Аудит) объекта-папки Подробнее о включении аудита в (.-драночной системе Microsoft Windows 2000 Server. Управление доступом ГЛАВА 12 Как установить владельца объекта Для этого необходимо иметь доступ на чтение разрешений (READCONTROL) объекта. При наличии необходимого типа доступа узнать имя владельца объекта не составляет труда. Для большинства объектов достаточно щелк нуть значок объекта правой кнопкой мыши, в контекстном меню выбрать Properties (Свойства), в открывшемся диалоговом окне свойств перейти к вкладке Security (Безопасность), а затем щелкнуть Advanced (Дополнитель но). Далее в диалоговом окне Access Control Settings (Параметры управле ния доступом) щелкните вкладку Owner (Владелец). Имя владельца Вы уви дите в поле Current owner of this item (Текущий владелец этого элемента). Для объектов файлов и папок можно одновременно отобразить список вла дельцев нескольких объектов. Откройте окно командной строки, перейдите в нужный каталог и выполните команду DIR /Q,. Эта команда в разных стол бцах выводит имена владельцев и имена объектов. Имя владельца не выво дится для объектов, к которым у пользователя отсутствует доступ на чтение разрешений. Назначение и изменение основной группы Для доменных учетных записей основной группой по умолчанию является Domain Users (Пользователи домена). Чтобы изменить основную группу пользователя, от редактируйте свойства соответствующего ему объекта пользователь в Active Directory. Подробнее об изменении основной группы пользователя Ч в справочной системе Microsoft Windows 2000 Server. При создании нового объекта создающий процесс может указать SID для поля Primary Group (Основная группа) объекта. Если основная группа не указана созда ющим процессом, ее SID копируется из поля основной группы по умолчанию мар кера доступа субъекта. Подобная процедура применяется, когда пользователь становится владельцем объек та. Обычно действующий от лица пользователя поток не указывает основную груп пу. В этом случае SID из поля основной группы по умолчанию маркера доступа субъекта копируется в поле основной группы дескриптора безопасности объекта. Списки управления доступом Список управления доступом (access control list, ACL) представляет собой упорядо ченный список записей управления доступом (access control entry, АСЕ), определя ющих защиту самого объекта и его свойств. Каждая АСЕ содержит идентификатор участника безопасности и указывает набор прав доступа к выполнению действий, которые ему разрешены, запрещены или для которых включен аудит. Дескриптор безопасности объекта может содержать два списка управления доступом: Х избирательную таблицу управления доступом (discretionary access control list, DACL), определяющую порядок доступа к объекту пользователей и групп; Х системную таблицу управления доступом (system access control list, SACL), уп равляющую аудитом доступа. Структура данных для ACL показана на рис. 12-21, Безопасность в распределенных системах 558 ЧАСТЬ Размер ACL Редакция ACL Число АСЕ АСЕ [1] АСЕ[...] АСЕ[п] Рис. 12-21. Структура ACL ACL состоит из следующих элементов: размер ACL Ч число байт памяти, занимаемых ACL. Размер ACL зависит от коли чества и размера его записей управления доступом; редакция ACL Ч номер редакции структуры данных ACL. Структура ACL не зави сит от редакции, но структура содержащихся в нем записей управления доступом может изменяться. Номер редакции для большинства объектов 2, а для объектов Active Directory Ч 4; число АСЕ Ч число записей управления доступом в ACL. Нулевое значение озна чает, что ACL пуст и не содержит никаких записей, и следовательно, проверка нрав доступа останавливается; АСЕ [11, АСЕ[...], АСЕ [п] Ч упорядоченный список записей управления доступом. Может отсутствовать. Во время проверки прав доступа АСЕ считываются в поряд ке размещения в ACL. Записи управления доступом Все АСЕ содержат следующую информацию управления доступом: Х SID, идентифицирующий пользователя или группу; Х маску доступа, в которой указаны права доступа; Х набор битовых флагов, определяющих способность дочерних объектов наследо вать АСЕ; Х флаг, указывающий на тип АСЕ. Типы АСЕ Windows 2000 поддерживает шесть типов АСЕ. Три общих типа могут присутство вать в ACL любых защищенных объектов. Общие типы АСЕ перечислены в табли це 12-7. Остальные три типа АСЕ являются объектно-зависимыми и встречаются только в ACL объектов Active Directory Объектно-зависимые типы АСЕ перечис лены в таблице 12-8. Таблица 12-7. Общие типы АСЕ Тип Описание ^^ Access-denied Используется в DACL для запрещения доступа Access-allowed Используется в DACL для разрешения доступа System-audit Используется в SACL для регистрации попыток получения доступа (аудит) Управление доступом ГЛАВА 12 Таблица 12-8. Объектно-зависимые типы АСЕ Тип Описание Access-denied, object-specific Используется Б DACL для запрещения доступа к свойству или набору свойств или для того, чтобы ограничить насле дование для определенного типа дочерних объектов Асе ess-all owed, object-specific Используется в DACL для разрешения доступа к свойству или набору свойств или для того, чтобы ограничить насле дование для определенного типа дочерних объектов System-audit, object-specific Используется в SACL для регистрации попыток доступа к свойству или набору свойств или для того, чтобы ограни чить наследование для определенного типа дочерних объектов По сути, общие и объектно-зависимые АСЕ одинаковы. Различие заключается в деталях управления наследованием и доступом к объектам. Общие АСЕ предоставляют ограниченные возможности по управлению различны ми видами дочерних объектов, которые их наследуют. По существу, они проводят различие только между контейнерами и объектами, не являющимися контейнера ми. Например, в DACL объекта-папки файловой системы NTFS может находиться общая АСЕ, позволяющая группе пользователей просматривать содержание папки. Так как эта операция выполняется только с объектами-контейнерами, в разрешаю щей ее записи АСЕ устанавливается флаг CONTAINER_INHERIT_ACE. Эта АСЕ наследуется только контейнерными объектами в папке (то есть только другими объектами-папками). Объекты, не являющиеся контейнерами (то есть, объекты файлы), ее не унаследуют, Объектно-зависимые АСЕ обеспечивают более тонкое управление наследующими их дочерними объектами. Например, если в ACL объекта подразделение находится объектно-зависимая АСЕ, помеченная для наследования только объектами полгзо ватель, другие типы объектов, например объекты компьютер, ее не унаследуют. Вот почему эти записи управления доступом называются объектно-зависимыми. Их наследование возможно для дочерних объектов лишь определенных типов. Похожие отличия наблюдаются и в управлении доступом к объектам. Общие АСЕ применяются ко всему объекту. Если общая АСЕ предоставляет определенному пользователю доступ на чтение, он получает возможность читать всю связанную с объектом информацию Ч как данные, так и свойства. Для большинства типов объектов это несущественное ограничение. У объектов-файлов, к примеру, немного свойств, и все они служат скорее для описания объекта, чем для хранения информа ции. Большая часть информации в объекте-файле хранится в виде данных объекта, поэтому нет особой потребности в индивидуальном управлении свойствами файла. Объектно-зависимые АСЕ могут относиться к отдельным свойствам или подмно жествам свойств объекта. Эти типы АСЕ встречаются только в ACL объектов Active Directory, которые, в отличие от объектов других типов, большую часть информа ции хранят в свойствах. Зачастую требуется управлять каждым из свойств объекта Active Directory по отдельности. Объектно-зависимые АСЕ вполне пригодны ля выполнения такой задачи. Например, при определении разрешений для объекта пользователь можно в одной объектно-зависимой АСЕ разрешить Principal Self (то есть пользователю) доступ на запись свойства Phone-Home-Primary (Домашний телефон, homePhone), а в другой объектно-зависимой АСЕ - запретить этому же Безопасность в распределенных системах 560 ЧАСТЬ пользователю доступ к свойству Logon-Hours (Время входа в систему, logonHours), а также к другим свойствам, налагающим ограничения на пользовательскую учет ную запись. Структура общей АСЕ У всех записей управления доступом (access control entry, АСЕ) общего типа одина ковая структура данных (рис. 12*22). Размер АСЕ Тип АСЕ Флаги наследования и аудита Маска доступа SID Рис. 12-22. Структура АСЕ общего типа Далее перечислены составные части АСЕ, Размер АСЕ (АСЕ Size) Ч число байт памяти, занимаемых АСЕ. Тип АСЕ (АСЕ Туре) Ч уточняет действие АСЕ: разрешение, запрещение доступа или установку аудита. Флаги наследования и аудита (Inheritance and Audit Flags) Ч набор битовых фла гов, управляющих наследованием и аудитом. Подробнее о флагах наследования Ч в разделе Наследование далее в этой главе. В таблице 12-9 описаны флаги аудита. Таблица 12-9. Флаги аудита Флаг Значение FAILED_ACCESS_ACE_FLAG Имеет гмысл только в АСЕ системного аудита и объектов системного аудита. В маске доступа ука заны операции, которые должны регистрироваться в журнале в случае отказа в доступе SUCCESSFUL_ACCESS_ACE_FLAG Имеет смысл только в АСЕ системного аудита и объектов системного аудита. В маске доступа ука заны операции, которые должны регистрироваться в журнале в случае предоставления доступа Маска доступа (Access Mask) Ч 32-разрядное выражение, каждый бит которого со ответствует праву доступа для объекта. Биты можно установить или сбросить, а их значение зависит от типа АСЕ. Например, если в АСЕ запрещающего типа установ лен бит. соответствующий нраву на чтение разрешений, чтение разрешений объек та запрещено. Если тот же бит установлен в разрешающей АСЕ, чтение разреше ний объекта разрешено. SID идентифицирует пользователя или группу, доступ которых управляется или отслеживается этой АСЕ. Структура объектно-зависимой АСЕ На рис. 12-23 изображена структура объектно-зависимой АСЕ. Управление доступом ГЛАВА 12 Размер АСЕ Тип А С Е Флаги наследования и аудита Маска доступа Тип объекта Тип объекта-наследника Флаги объекта Рис. 12-23. Структура объектно-зависимой АСЕ Ноля Размер АСЕ, Тип АСЕ, Флаги наследования и аудита, Маска досту па и SID идентичны соответствующим элементам структуры данных АСЕ общего типа. Основные различия между общей и объектно-зависимой АСЕ определяют остальные поля, они рассмотрены далее. Флаги объекта Флаги объекта (Object Flags) информируют о наличии (или отсутствии) полей Тин объекта (Object Type) или Тип объекта-наследника (Inherited Object Type). В таблице 12-10 перечислены три возможных флага. Таблица 12-10. Флаги объекта ^^ Флаг Значение О (флаги отсутствуют) Поля Тип объекта или Тип объекта-наследника* отсутствуют. В этом случае 1 АСЕ применяется ко всему объекту, выступая. таким образом, в роли обычной АСЕ общего тина AC E_OBJECT_TYPE_P RESENT АСЕ применяется к свойству, подмножеству свойств или расширенному праву или управляет способностью создавать определенные типы дочерних объектов ACE_INHERITED_OBJECT_ АСЕ может наследоваться только определенным типом TYPE_PRESENT " дочерних объектов Тип объекта Поле Тип объекта содержит GU1D, который может указывать на один из пере численных далее элементов, Х Тип дочернего объекта. АСЕ определяет, кому предоставлено право создавать внутри контейнера дочерние объекты определенного типа. Идентификатор бе зопасности в АСЕ идентифицирует пользователя или группу, способных созда вать этот тип дочернего объекта. Маска доступа АСЕ содержит объектно-зави симое право доступа ADSRIGHT_DS_CREATE_CHILD. Х Свойство или подмножество свойств. АСЕ управляет способностью считывать или записывать отдельные свойства или подмножества свойств. Идентификатор безопасности в АСЕ идентифицирует пользователя или группу, способных вы полнять указанные действия. Маска доступа АСЕ содержит объектно-зависимое право ADS_R1GHT_DS_READ_PROP или ADS_RIGHT_DS_WRITE_PROR Х Расширенное право. АСЕ управляет правом выполнять операцию, связанную с расширенным правом. Идентификатор безопасности в S1D указывает пользова теля или группу, которым предоставляется или блокируется соответствующее Безопасность в распределенных системах 562 ЧАСТЬ право. Маска доступа АСЕ содержит объектно-зависимое право ADS_RTGHT_ DS_CONTROL_ACCESS. Тип объекта-потомка Поле Тип объекта-наследника* содержит GUID, указывающий на тип дочернего объекта, способного наследовать АСЕ. Наследование также управляется при помо щи флагов наследования АСЕ и защиты против наследования, устанавливаемой на дочернем объекте в управляющих флагах дескриптора безопасности. DACL вновь создаваемых объектов Операционная система устанавливает DACL в дескрипторах безопасности вновь создаваемых защищенных объектов большинства типов по определенным правилам. 1. Объект получает DACL из дескриптора безопасности, указанного создающим процессом. Операционная система также переносит в DACL все наследуемые записи управления доступом (если только не установлен управляющий флаг SE_DACL_PROTECTED) и затем устанавливает управляющий флаг дескрип тора безопасности SE_DACL_PRESENT. 2. Если создающий процесс, не указывает дескриптор безопасности, операционная си стема создает DACL объекта из наследуемых записей управления доступом в DACL родительского объекта, после чего устанавливает флаг SE_DACL_PRESENT. 3. Если в родительском объекте отсутствуют наследуемые АСЕ, операционная систе ма запрашивает у диспетчера объекта DACL по умолчанию, присваивает ее объек ту и затем устанавливает флаги SEDACL_PRESENT и SE_DACL_DEFAULTED, 4. Если диспетчер объекта не предоставляет DACL по умолчанию, операционная система извлекает ее из маркера доступа субъекта, после чего устанавливает флаги SE_DACL_PRESENT и S E_ D AC L_J3E FAULTED. 5. Если в маркере доступа субъекта DACL по умолчанию нет, избирательная табли ца управления доступом новому объекту не назначается, и он становится доступ ным всем без каких-либо ограничений. Управляющий флаг SE_DACL_PRESENT при этом не устанавливается. DACL вновь создаваемых объектов Active Directory Способ создания DACL нового объекта в Active Directory немного отличается от метода, применяемого для объектов других типов. Вот два основных различия: Х при создании DACL различаются общие и объектно-зависимые наследуемые АСЕ в дескрипторе безопасности родительского объекта. Общие наследуемые АСЕ могут наследоваться дочерними объектами любых типов. Объектно-зави симые наследуемые АСЕ могут наследоваться объектом указанного типа; Х предоставлять дескриптор безопасности может схема Active Directory. Каждый определенный в схеме класс объектов имеет атрибут defaultSecurityDescriptor. Если ни создающий процесс, ни родительский объект не предоставляет DACL новому объекту Active Directory, операционная система использует DACL из указанного в схеме дескриптора безопасности по умолчанию. При установке DACL в дескрипторе безопасности новых объектов Active Directory операционная система следует определенным правилам. ГЛАВА 12 Управление доступом 1. Объект получаст DACL из дескриптора безопасности, указанного создающим процессом. Если не установлен управляющий флаг дескриптора безопасности SE_DACL_PROTECTED, операционная система переносит в DACL все насле дуемые записи управления доступом и затем устанавливает управляющий флаг дескриптора безопасности SE_DACL_PRESENT. 2. Если создающий процесс не указывает дескриптор безопасности, операционная система ищет в DACL родительского объекта объектно-зависимые АСЕ, соот ветствующие типу нового объекта. Если у родительского объекта есть наследуе мые объектно-зависимые АСЕ для объектов данного типа, операционная систе ма строит DACL из наследуемых АСЕ, включая в него как общие, так и объект но-зависимые АСЕ, и затем устанавливает флаг SE_DACL_PRESENT. 3. Если у родительского объекта отсутствуют наследуемые объектно-зависимые АСЕ для объектов данного типа, операционная система использует DACL по умолчанию из схемы Active Directory для объектов данного типа. Затем она ус танавливает флаги SE_DACL_PRESENT и SE_DACL_DEFAULTED. 4. Если в схеме Active Directory нет DACL по умолчанию для объектов данного типа, операционная система пытается обнаружить и присвоить объекту DACL по умолчанию в маркере доступа субъекта. В случае успеха она устанавливает флаги SE_DACL_PRESENT и SE_DACL_DEFAULTED. 5. Если в маркере доступа субъекта нет DACL по умолчанию, DACL новому объек ту не присваивается, и доступ к нему открыт всем. При этом флаг SE_DACL_PRESENT не устанавливается. SACL вновь создаваемых объектов При установке SACL в дескрипторе безопасности новых объектов операционная система следует определенным правилам. 1. Если создающий процесс сам явным образом предоставляет SACL, операцион ная система помещает ее в дескриптор безопасности объекта. Если не установ лен управляющий флаг дескриптора безопасности SE_SACL_PROTECTED, операционная система перемещает все наследуемые записи управления досту пом в SACL и устанавливает управляющий флаг дескриптора безопасности SE_SACL_PROTECTED. 2. Если создающий процесс сам не предоставляет SACL, операционная система создает SACL объекта из наследуемых записей управления доступом в SACL родительского объекта и устанавливает управляющий флаг дескриптора безо пасности SESACL_PROTECTED. 3. Если у родительского объекта отсутствуют наследуемые АСЕ, операционная сис тема запрашивает у диспетчера объекта SACL по умолчанию. Затем она устанав ливает управляющие флаги дескриптора безопасности SE_SACL_PRESENT и SE_SACL_DEFAULTED. 4. Если диспетчер объекта не предоставляет SACL по умолчанию, SACL новому объекту не назначается. Наследование ACL Наследованием (inheritance) называется процесс переноса (копирования) записей управления доступом из ACL родительского объекта в ACL дочернего объекта. В Безопасность в распределенных системах 564 ЧАСТЬ Windows 2000 наследуемые АСЕ разрешается переносить из родительского объек та в дочерний, когда: Х создается новый дочерний объект; Х изменяется DACL родительского объекта; Х изменяется SACL родительского объекта. В этой схеме любой объект может быть дочерним по отношению к другому объек ту. Родительскими объектами бывают только контейнеры. В Windows 2000, как в генетике, родители могут нести рецессивные (скрытые) гены, которые внешне ни как не проявляются. Например, в списке управления доступом объекта-контейне ра находятся АСЕ, не действующие на сам контейнер, а существующие только для целей наследования. Они могут передаваться объектам-контейнерам вниз с уровня на уровень (из поколения в поколение), пока не дойдут до оконечного (ллистьево го) дочернего объекта, где вступят в законную силу, то есть станут действующими (а не номинальными) записями управления доступом. Механизм наследования зависит от двух условий: набора флагов наследования в каждой АСЕ и правил наследования, встроенных в операционную систему. Флаги наследования Заголовок АСЕ содержит набор флате наследования (Inheritance Flags), управляю щих тем, как данная АСЕ наследуется и как она влияет на наследующий ее дочер ний объект. Флаги наследования перечислены в таблице 12-11. Таблица 12-11. Флаги наследования Флаг Значение T Windows 2000: АСЕ унаследована из DACL или SACL IN IIER1TEDACE родительского объекта. Этот флаг не устанавливается на явно заданных АСЕ, то есть тех АСЕ. которые определяются непосредственно на объекте INHERIT_ONLY_ACE Указывает, что данная АСЕ предназначена только для наследования. Эта АСЕ игнорируется при проверке доступа, но ее можно переносить на дочерние объекты Если этот флаг не установлен, АСЕ является действующей, го есть обрабатывается при проверке доступа. Наследуются как действующие АСЕ, так и АСЕ с флагом только для наследования. Наследование или отсутствие наследования АСЕ определяется состоянием флагов OBJECTJNHERIT_ACE и CONTAINER_INHERIT_ACE CONTA1NER_INHERIT_ACE Контейнерные объекты наследуют эту АСЕ как действую щую. Когда такая запись наследуется контейнерным объек том, операционная система снимает флаг INIIERIT_ONLY_ACE OBJECT_INHERIT _ACE Объекты, не являющиеся контейнерами, наследуют эту АСЕ как действующую. Когда АСЕ наследуется таким объектом, операционная система снимает флаг INHERIT ONLY_ACE. Контейнерные объекты также наследуют эту АСЕ, но только для того, чтобы передать далее по наследству. Когда АСЕ наследуется контейнерным объектом, операционная система устанавливает флаг INHERIT_ONLY_ACE ГЛАВА 12 Управление доступом Таблица 12-11. (продолжение) Значение Флаг NO_PROPAGATE_ Если дочерний объект наследует АСЕ с таким флагом, оне INHERIT_ACE рационная системы сбрасывает флаги OBJECT_INHERIT_ АСЕ и CONTAINER JNHERIT_ACE Это предотвращает дальнейшее наследование АСЕ последу ющими поколениями объектов Правила наследования Операционная система интерпретирует флаги наследования и другую относящую ся к наследованию информацию в соответствии с правилами наследования АСЕ, приведенными в таблице 12-12. Эти'правила одинаково применимы как к DACL. так и к SACL. Операционная система передает наследуемые АСЕ в дочерние объек ты, соблюдая предпочтительный, или канонический (canonical), порядок. После пе реноса записей управления доступом система устанавливает на всех унаследован ных АСЕ флаги OBJECT_INHERIT_ACE и CONTAINERJNHERITJVCE. Таблица 12-12. Правила наследования Флаги наследования родительских АСЕ Воздействие на дочерние ДС Флаги отсутствуют Нет воздействия па дочерние ACL Только OBJECT_INHERIT_ACE Дочерние объекты, не являющиеся контейнера ми: АСЕ наследуются как действующие. Книги, научные публикации