Книги, научные публикации
Pages: | 1 | ... | 8 | 9 | 10 | 11 | 12 | ... | 15 | Distributed Systems Guide Microsoft 2000 Server Microsoft Press Распределенные системы Книга 1 2000 Server Москва 2001 Я fl I (I Г К I P УДК 004 ББК 32.973.26-018,2 М59 Microsoft ...
-- [ Страница 10 ] --Предпочтительнее доступ группам, а не индивидуальным пользова телям, при этом уровень полномочий подстраивается под нужды ее членов.
Этот метод упрощает своевременное обновление ACL в сетях, где ис числяются тысячами, а объекты - миллионами. Членством в группах централизованно, администраторы могут менять уровень полномочий отдельных пользователей, включая или исключая их из групп.
Кроме того, администрирование облегчается имеющейся в Windows 2000 функци ей вложения групп. Созданную в одном домене группу можно добавить к группе, созданной в другом домене или к универсальной группе всего дерева доверенных доменов. В результате уровень авторизации сотрудников, меняющих место работы внутри удается легко изменить прибегая к корректировке отдель ных объектов ACL.
Как и отдельные участники безопасности, группы в Windows 2000 имеют свои идентификаторы безопасности. Таким образом, уровень авторизации пользователя определяется списком идентификаторов безопасности, который включает в себя собственный SID и S1D всех безопасности, в которые он входит.
ГЛАВА 11 Проверка подлинности Подробнее о том, как операционная система уровень авторизации пользователя, Ч в главе 12 Управление доступом.
Подготовка данных авторизации средствами Когда для подлинности протокол список идентифицирующих участника безопасности и группы, в которые тот входит, дается на локальный компьютер в поле данных авторизации сеанса. Сбор данных выполняется в два этапа: когда Windows билет и при создании билета сеанса с сервером в домене.
Когда запрашивает центр распространения ключей его домена обращается к Active Directory. В учетной пользователя имеется атрибут с его а также атрибуты с SID каждой группы безопасности домена, членом ко торой этот пользователь является. Возвращаемый в ответ на запрос список в авторизации билета TGT. В многодоменном окру жении также запрашивает в каталоге универсальные включающие самого пользователя или одну из его доменных групп Если таковые обнаруживаются, SID этих групп также добавляются к списку в поле данных авторизации билета TGT.
Когда пользователь запрашивает билет сеанса с сервером, KDC серверного домена копирует содержание поля авторизации в соответствующее поле би лета сеанса. Если домен сервера отличается от домена пользователя, шивает у Active Directory группы безопасности локального домена, включающие самого пользователя или одну из групп безопасности, в которую тот входит. Если такие существуют, их SID добавляются к списку в поле данных авториза ции билета сеанса.
Использование службами данных авторизации В Windows 2000 службы действуют в собственном контексте безопасности, только если они пытаются получить доступ к ресурсам от своего Обычно это про исходит, когда они обслуживают сами себя -- считывают или записывают мацию реестра, осуществляют привязку к портам, а лю бые другие не с обработкой клиентских запросов. Служба, выполняющая какие-либо действия для клиента, представляет этого клиента и дей ствует в его контексте Это что кроме верификации клиен та, службам Windows 2000 приходится учитывать некоторые его характеристики, а его уровень авторизации в системе.
Когда служба обслуживает сама себя на компьютере под Win dows она вызывает метод интерфейса SSPI, получить доступ к своим реквизитам (секретному ключу учетной записи, под кото рой данная служба выполняется). Затем она подключается к порту и ожидает сообщений от клиентов.
Получив запрос на соединение и служба просит Kerbcros SSP проверить им удостоверения, метод Context интерфейса SSPI и передавая в аргументе билет сеанса клиента вместе с описате лем секретного ключа службы. SSP проверяет аутентичность этого билета, откры вает его и LSA содержание поля авторизации. Если в этих данных содержатся SID, использует их для создания маркера доступа, ЧАСТЬ 2 Безопасность в распределенных системах в локальной системе. Кроме того, LSA базу данных, чтобы выяснить, не является ли пользователь или одна из его членом группы локальной системы. Если такие группы су ществуют, добавляет их идентификаторы безопасности в маркер доступа.
Затем LSA подтверждает службе, что клиент идентифицирован, и при лагает ссылку на клиентский маркер доступа.
Получив подтверждение, служба закрывает соединение с клиентом и, ме тод маркер доступа клиента к олицетво ряющему его потоку. Запрашивая доступ к объекту, этот поток предъявляет маркер клиента. система проверяет права доступа, сравнивая SID, заклю ченные в маркере клиента, и SID в ACL объекта. Обнаружив одинаковые иденти фикаторы безопасности, операционная система проверяет ACL, предоставлен ли этому SID уровень доступа, запрошенный Если авторизованный доступа соответствует запрошенному, потоку разрешается доступ к объекту. В про тивном случае доступ не предоставляется, Подписывание данных авторизации Билеты сеанса шифруются секретным ключом учетной записи, под которой запус кается служба. Получая доступ к описателю своих удостоверений, служба получа ет доступ и к этому ключу. Вероятна ситуация, когда недобросовестный пользова тель, подлинной сетевой учетной записью, но с ограниченными пра вами на локальном компьютере установит нем свою службу. Далее этот пользо ватель может запросить билет сеанса со службой. Служба, расшифровывав билет, изменит данные авторизации, добавив S1D привилегированной группы, за ново зашифрует измененный билет и, метод предъя вит его В результате уровень полномочий пользователя на компьютере, на котором выполняется служба, повысится.
Для предотвращения такой ситуации подписывает данные авторизации пе ред их в билет сеанса. При изменении данных подпись теряет силу. LSA на компьютере под управлением Windows 2000 всегда проверяет данных авторизации в билетах сеанса, которые предъявляют в вызовах AcceptSecurity службы, не относящиеся к доверенным, то есть выполняющиеся под учетной записью локальной системы. Эта учетная запись применяется которые устанавливаются вместе с операционной системой, как, например, основ ная служба сервера. Другие службы тоже способны выполняться под учетной за писью локальной системы, однако разрешить это могут только группы Administrators (Администраторы). Предполагается, что службу ад министратор гарантирует ее безопасность.
Если билет сеанса предъявляет приложение, не выполняющееся контексте ло кальной системы, у подтверждение подписи данных авто ризации билета. Обмен происходит по механизму удаленного вызова процедур по каналу, открытому службой Net Logon (Сетевой вход в систему) меж ду и контроллером домена. на подтверждение не выходят за границы домена, так как билеты сеансов всегда и следова тельно, в них данные авторизации всегда подписываются до мена, в котором находится запрашиваемый компьютер, ГЛАВА 11 Проверка подлинности Интерактивный вход в систему Пользователям свойственно полагать, что вход в систему под учетной записью до мена Windows 2000 предоставляет им доступ в сеть, что, конечно же, Ч полнейшее заблуждение. В действительности, если сетевая проверка подлинности по протоколу входящий в систему пользователь получает доступ только к службе проверки подлинности, ему предоставляется билет TGT, он может предъявлять, запрашивая билеты сеансов с другими службами домена.
Для входа в систему под доменной учетной записью с компьютера под управлени ем Windows 2000 всегда нужен по крайней мере один билет сеанса билет для ком пьютера, с которого этот вход осуществляется. Этому есть весьма простое объясне ние: нельзя работать на компьютере под управлением Windows 2000, не хотя бы некоторых из его системных служб. Пользователь системной службы ста новится ее клиентом, подлинность которого должна быть проверена, а для такой проверки требуется билет сеанса. Системные службы компьютера под ем Windows 2000 под учетной записью локальной системы, а при при соединении компьютера к домену Ч под учетной записью компьютера в домене.
Пользователи домена получают доступ к службам, выполняющимся в контексте ло кальной предъявляя билет сеанса для компьютера, на котором эти служ бы выполняются, и для интерактивно входящих в систему пользователей исключе ния не делаются. Для получения доступа к службам компьютера пользователям также приходится предъявить билет сеанса.
Процедура входа в систему Вход с учетной записью в домене Windows 2000 в с клавиа туры компьютера под управлением Windows 2000 выполняется в три этапа.
1. Пользователь запрашивает доступ к службе TGS домена.
Запрос осуществляется при помощи AS-обмена между Kerberos SSP компьюте ра и домена учетной записи пользователя. В ответ пользователь получает билет который при последующем обмене с 2. Пользователь запрашивает билет для Запрос выполняется при между Kerberos SSP компьютера и домена учетной записи компьютера. В ответ пользователь получает би лет сеанса, который понадобится для последующих запросов к служ бам компьютера.
3. Пользователь доступ к службам локальной системы компьютера, При этом Kerberos SSP компьютера предъявляет билет сеанса LSA компьютера.
Если учетные компьютера и пользователя находятся в разных доменах, не обходимо выполнить дополнительные Прежде чем запросить билет се с поставщик Kerberos SSP должен получить от домена пользователя билет TGT для службы распространения ключей домена компьюте ра. Поставщик поддержки может получить билет сеанса с компьюте ром, предъявив TGT центру распространения ключей домена компьютера.
Процесс входа в систему от настройки и конфигурации компьютера. При обычной Windows 2000 пользователи входят в сис тему с помощью пароля. Специальная Windows 2000 позволяет 514 ЧАСТЬ 2 Безопасность в распределенных системах пользователям входить в систему по смарт-карте. Несмотря на сходство основных процедуры, эти способы входа в систему немного различаются.
Вход в систему с помощью пароля Предположим, что и Workstation, которым она обычно пользуется, хранятся в домене Чтобы войти в систему, Алиса нажи мает CTRL+ALT+DEL. Эта комбинация клавиш к системе (Secure Sequence, SAS), или SAS-после для компьютеров с обычной Windows 2000.
В ответ служба переключает рабочий стол в режим входа в систему и вызывает (Graphical Identification and динамически под ключаемую библиотеку поддержки графического интерфейса идентификации и проверки GINA в службы Winlogon и отвечает за от пользователя для входа в систему, упаковку ее в циальную структуру данных и пересылку в LSA для проверки. Существуют, конеч но же, версии созданные сторонними разработчиками, однако мы рассмот рим только загрузку службой компонента операцион ной системы Windows 2000. MSGINA отображает стандартное диалоговое окно вхо да в систему.
Алиса вводит свое имя пользователя и пароль и выбирает West в имен до менов. Когда она щелкает кнопку ОК, диалоговое окно закрывается и MSGINA передает информацию службе Winlogon. Winlogon направляет эту ин формацию на подтверждение в LSA, вызывая метод Получив структуру данных, содержащую информацию Алисы, неза при помощи односторонней хэш-функции преобразует пароль в ретный ключ. LSA преобразованный пароль в кэше от куда его извлекают для шифрования или расшифровки.
Чтобы входную информацию Алисы и создать для нее в системе на LSA должен получить:
Х действительный билет TGT для доступа к TGS;
Х действительный билет сеанса для доступа к компьютеру.
LSA получает эти билеты при SSP, который обменивается сооб щениями с KDC домена, как это показано на рис.
Центр распределения !
ключей (KDC) Х Служба Билет TGT для домена LSA S Служба TGS Билет для S р Рис. 11-8. Обмен по протоколу Kerberos при интерактивном входе в систему Ниже приведены содержание и последовательность сообщений.
ГЛАВА 11 Проверка 1. направляет службе проверки домена West сообщение в котором содержатся:
Х основное имя пользователя (Алиса);
Х имя в котором хранится учетная запись Х предварительной сек ретным ключом, из пароля Алисы.
2. Служба проверки подлинности сообщение-ответ в котором содержатся:
Х общий ключ сеанса для Алисы и зашифрованный секретным полученным из пароля Алисы;
Х билет TGT для центра ключей домена West, ный секретным ключом В билете находятся общий ключ сеанса для и Алисы и данные авторизации Алисы.
Данные авторизации состоят из SIO учетной записи Алисы, SID групп домена которых является Алиса, а также SID универсаль групп предприятия, в которые входит Алиса или одна из ее доменных групп.
3. направляет службе центра домена West со общение-запрос в котором содержатся:
Х имя компьютера (Workstation);
Х имя домена, к которому относится компьютер (West);
Х билет Алисы;
Х аутентификатор, общим ключом сеанса Алисы и KDC.
4. сообщение-ответ в котором содержатся:
Х общий ключ сеанса для и Workstation, зашифрованный общим клю чом сеанса Алисы и Х билет сеанса с Workstation для Алисы, зашифрованный общим секретным ключом Workstation и КОС.
Билет сеанса содержит общий ключ сеанса Workstation и а также авторизации из билета TGT Алисы.
Получив билет сеанса Алисы, расшифровывает с помощью секретного клю ча компьютера и данные авторизации. Затем он направляет запрос данных локального диспетчера (Security Account Manager, SAM), пытаясь выяснить, в какие локальные безопасности ком пьютера входит Алиса и не предоставлены ли ей какие-либо дополнительные пользовательские права на локальном компьютере. LSA добавляет возвращенные в ответ на запрос к списку, извлеченному из данных авториза ции билета. Весь список для создания маркера доступа. Описатель маркера доступа возвращается службе Winlogon вместе с идентификатором сеанса Алисы в системе и подтверждением действительности, предоставленной ею входа.
Winlogon создает для нее объект станции (window и некоторые объекты рабочего стола закрепляет за ней маркер доступа и запускает обо лочку, которую она будет использовать для взаимодействия с компьютером. Map 51 б ЧАСТЬ 2 в распределенных системах Алисы всем процессами ею в течение сеанса в Вход в систему с помощью смарт-карты При обычном входе в систему первоначально подтверждает свою личность, подтверждая знание секрета, известного только пользователю и Общим секретом является криптографический ключ, преобразованный из пароля Так как один и тот же ключ применяется как для шифрова ния, так и для расшифровки, общие секретные ключи называют симметричными.
Криптографический ключ, из пароля пользователя, только во время для:
Х шифрования клиентом предварительной проверки Х расшифровки этой информации центром распространения ключей;
Х КОС ключа сеанса входа в систему;
Х расшифровки этого ключа клиентом.
Для поддержки входа в систему с смарт-карты, стандартный механизм AS-обмена в Windows 2000 дополняется расширением с при менением открытых ключей. В отличие от криптографии общего ключа, криптог рафия с применением открытых ключей асимметрична, то есть в ней используют ся два разных ключа: один для шифрования, а другой для расшифровки. Оба клю ча, необходимые для этих действий, составляют пару клю чи.
Если вместо пароля используется смарт-карта, хранящаяся на ней пара ключей за меняет общий ключ, преобразованный из пароля пользователя. Закрытый ключ из вестен только владельцу пары и никогда разглашается. Открытый ключ предос тавляется с кем владелец желает обмениваться конфиденциальной информа цией.
В шифрования с применением открытых ключей протокола Kerheros оригинальный AS-обмен изменен. В Windows 2000 шифрует пользовательс кий ключ сеанса в системе открытым ключом пользователя, а клиент расшифровы вает его своим закрытым ключом.
Процесс входа в систему начинается пользователем его смарт-карты в считывающем устройстве компьютера. Эта процедура является SAS-последова компьютера под управлением Windows 2000, для использования смарт-карт, по аналогии с комбинацией клавиш для компьютера, для входа с помощью пароля. Далее служба вызывает которая диалоговое окно входа в систему.
На этот раз пользователю требуется только свой PIN-код (personal iden tification number).
Как и при входе в систему по паролю, вызывает и ляет LSA предоставленную пользователем информацию для входа в систему. LSA применяет PIN-код для доступа к смарт-карте, на которой находится закрытый ключ пользователя и сертификат Х509 версии 3 с его открытым ключом.
Все криптографические операции с использованием этих ключей на смарт-карте.
ГЛАВА 11 Проверка подлинности Kerberos SSP компьютера клиента в в качестве данных предвари тельной проверки сертификат с открытым ключом в проверяет сертификата, извле кает открытый ключ и использует для шифрования ключа сеанса в системе.
Затем он возвращает клиенту ключ сеанса в системе и билет в сообщении-ответе Обладая соответствующим закрытым клиент его для расшифровки ключ сеанса. Дальнейший обмен клиента и KDC шифруется ключом сеанса в системе. Оставшаяся часть процесса проверки подлинности проходит так же, как и при обычном входе в систему.
Подробнее о типах смарт-карт и о Windows 2000 устройствах ния смарт-карт - на Web-странице Web Resources по адресу ссылка Microsoft Windows Hardware Compatibility List.
Управление доступом Операционная система Microsoft Windows 2000 файлы, приложения и другие ресурсы от несанкционированного использования. Хотя Вам уже должно быть как назначать привилегии и разрешения, мы решили пояснить, что в представляют собой привилегии и разрешения, для чего они нужны и как они работают. Надеемся, это поможет Вам эффективно управлять ре сурсами, избежать рисков и устранять проблемы по их В этой главе Модель управления доступом Права Идентификаторы безопасности Маркеры доступа Дескрипторы безопасности Списки доступом Проверка доступа и аудит См. также Х Подробнее о том, как диагностировать, восстанавливать и устранять неполадки в Active Directory, Ч в главе 10 и устранение а также восстановление данных в Active Directory.
Х Подробнее о проверке подлинности Ч в главе И Х Подробнее о правах пользователя в приложении Г пользователей.
Х Подробнее о известных идентификаторах безопасности - в приложении Д Наиболее известные идентификаторы ГЛАВА 12 Управление доступом Модель управления доступом Работа систем в Windows 2000 основана на технологиях, разработанных для Windows NT. В принципе, обе системы одинако во управляют к ресурсам. Если Вы знакомы с Windows NT 4.0 или более версиями Windows NT, то что их модель управления доступом име ет некоторые Проверка подлинности на основе пользователей. В Windows NT любое запущен ное пользователем приложение выполняется в своем а в пользова тельском контексте Такое приложение выполняет только действия, разрешенные пользователю. Например, приложение Microsoft Word получит доступ только к тем к которым его Если тот же Word открывает другой пользователь, приложению становятся доступны тс до кументы, к которым имеет доступ именно этот пользователь. В Windows 2000 эта функция модели управления доступом усовершенствована. Приложе ния выполняются в ограниченном безопасности, в котором они облада ют меньшими привилегиями и более ограниченным чем их Избирательный доступ к защищенным объектам. В Windows NT пользователь Ч владелец объекта определяет, кто и каким образом может его Он вправе предоставлять на различные виды доступа только определен ным пользователям или группам. Например, владелец объекта файл может доставить на чтение и запись всей и этом запретить на запись определенному члену этой группы. В Windows 2000 владельцам предос тавлено разрешать или запрещать доступ как к отдельным свойствам объек тов типа, так и к объекту в целом.
Наследование разрешений. Windows NT позволяет управлять разрешениями для объектов, создаваемых в объекте-контейнере, установив для контейнера мые разрешения, для папки в разделе будут наследоваться всеми вновь создаваемыми в ней папками и файлами. В 2000 установленные для контейнера разрешения наследуются как уже существующими объектами, так и вновь создаваемыми.
Windows NT позволяет управлять пользователями и группами, обладающими правом выполнять административные ции или предпринимать действия, затрагивающие ресурсы всей системы.
администратор может одной группе пользователей право ного входа в систему, а другой, более Ч право загружать и выгружать устройств. Групповая политика в Windows 2000 позволяет централизован но управлять административными привилегиями на всех компьютерах домена, Аудит системных событий. В Windows NT функция аудита используется для об попыток обойти защиту или для создания контрольного следа админи стративных действий в системе. Например, регистрировать в журнале безопаснос ти неудачные попытки входа в систему. В также отразится изменение дру гим политики аудита, заключающееся в отмене регистрации не удачных попыток входа в систему. Групповая в Windows 2000 позволяет управлять пользователями, которым разрешено оперировать жур безопасности домена.
520 ЧАСТЬ 2 Безопасность в распределенных системах Основные понятия В управлении доступом, как и в любой другой сфере, применяется специальная Сейчас мы расскажем, как некоторые понятия в кон тексте модели управления доступом Windows 2000.
Участник безопасности (security principal) это пользователь, группа, или служба. Участники безопасности обладают учетными Локальные учетные записи управляются учетных записей (Security Account Manager, SAM) компьютера, а учетные записи домена Ч службой катало гов Active Directory.
Идентификатор безопасности (security identifier, SID) это значение, которое уникально идентифицирует пользователя, службу или компьютер предпри ятия. S1D каждой учетной в момент ее создания. Механиз мы управления доступом в Windows 2000 различают безопасности по SID, а не по именам.
Контекст безопасности (security context) это информация, описывающая отли чительные черты участника безопасности и его возможности при работе на компь ютере. В Windows 2000 любые действия выполняются в определенном контексте безопасности, которого подсистема безопасности определяет разрешен ные процессу и его потокам действия с компьютера, а также участников безопасности, несущих за действия Маркер доступа (access Ч это структура данных, содержащая SID участни ка безопасности, всех групп, членом которых он является, и список его (прав пользователя) на локальном компьютере. Маркер до ступа присваивается каждому участнику безопасности, входящему как локально (с клавиатуры компьютера), так и удаленно (по сети). Маркер доступа определяет безопасности для действий участника безопасности на Поток (thread) Ч это исполняемая часть процесса. поток рас сматривать как программный код, для процессора. Процесс мо жет несколько одновременно выполняющихся потоков. Операционная сис тема координирует их работу, определяя приоритеты выполнения Субъект (subject) это выполняющийся в контексте безопасности участ ника безопасности, прошедшего Прежде чем допустить субъекта к операций на защищенном подсистема безопаснос проводит проверку доступа она сравнивает информацию в маркере доступа субъекта с данными в дескрипторе безопасности объекта. Таким образом проверя ется, разрешены ли субъекту им действия.
Олицетворение (impersonation) это потока действовать в отличном от процесса, к которому он относится. Олицет ворение разработано для приложений, где оно применяется в службах. Выполняя собственные действия, служба работает в собственном контек сте безопасности, а при обработке клиентского запроса Ч в контексте безопасности клиента.
Объект (object) Ч это любой которым может управлять программа про цесс. Объекты включают в себя только ресурсы, которые можно наблюдать в интерфейсе пользователя, например файлы, принтеры, разделы реестра, объекты Active Directory и рабочий стол Windows, но и ресурсы, которые увидеть ГЛАВА 12 Управление доступом нельзя Ч процессы, потоки и маркеры доступа. Объект может выступать как логическое хранилище других объектов. Такие объекты называются контейне рами. Объекты, не способные содержать другие объекты, называются конечными объектами (не-контейнерами). Объекты-контейнеры содержат как конечные объек ты, так и другие объекты-контейнеры. Например, в объекте файловой сис темы могут находиться как объекты файл (конечные объекты), так и другие объекты (контейнеры). В иерархии объектов отношение между контейне ром и его содержимым описывается терминами (parent) для нера и (child) для находящегося в нем объекта. Понятие родственных от ношений тина родитель потомок часто используется для концепции наследования объектов, в которой дочерний объект наследует ленные характеристики (например, ограничения родительского объекта.
Защищенный объект object) Ч это любой объект, который выделять в общее пользование. В 2000 у объектов есть дескрипторы, сведения о порядке управления доступом к объекту.
Дескриптор безопасности (security descriptor) Ч структура данных, в которой со держится информация о защищаемом Дескриптор иденти фицирует владельца объекта по его STD. У объекта с разрешения ми в дескрипторе безопасности находится таблица дос (discretionary access control list, DACL) с пользова телей и групп, которым или доступ к нему. Если для объекта задан порядок аудита, дескриптор его безопасности также содержит таблицу доступом (system access control list, SACL), в которой опреде лен порядок выявления попыток доступа к нему.
Владелец Ч это участник безопасности, обладающий правом разрешать или запрещать доступ к объекту. Первым владельцем объекта обычно является участник связанный с создавшим объект потоком. Владелец объекта вправе изменить его принадлежность, предоставив дру гому участнику безопасности разрешение Take ownership владельца). По умолчанию члены встроенной группы Administrators (Администраторы) компью тера могут стать владельцами любых объектов на компьютере.
Разрешение (permission) Ч это право произвести одну или несколько операций с объектом. Разрешения определяются владельцем объекта. Поскольку бор) о порядке доступа к объекту принимается данный тип управ ления доступом в Windows 2000 называется доступом (discretionary access control).
Право пользователя (user right) Ч это право совершить операцию, влияние просто на отдельный объект, а на компьютер в целом. Права теля (также известные как привилегии) предоставляются администраторами от пользователям или группам при настройке политики безопасности ком пьютера. Несмотря на то, что правами пользователя можно управлять централизо ванно средствами групповой политики, они локально. Пользователям, как правило, различные права на разных компьютерах.
Право доступа (access right) Ч это разрешение с точки зрения субъекта. Когда пользователь конкретный человек, разрешает или доступ средствами диалогового окна Access Control Settings управления доступом), ре 522 ЧАСТЬ 2 Безопасность в распределенных системах его действий в виде записей (access control АСЕ) в DACL объекта. В интерфейсе пользователя разрешение выра жено словом или фразой. В АСЕ то же самое выражается набором би флагов в маске доступа. Каждому битовому флагу соответствует право дос тупа - определенная которую можно совершить над Как работает управление доступом Детали работы управления доступом весьма сложны, но в чертах процесс выглядит достаточно просто: субъекты совершают действия объекта ми. В открывает Алиса является субъектом, или аген том действия, открывает Ч это само действие, а файл Ч объект действия. Похожая терминология используется и в Windows 2000.
Вместе с тем необходимо обратить на некоторые важные отличия. Когда мы говорим Алиса открывает файл, то подразумеваем, что на самом деле файл открывает не сама Алиса, а программа. Точнее, программа выполняется как процесс, состоящий из потоков, и в действительности файл открывает один из них. Потоки - это единственные объекты, выполняющие действия на компьютере.
терминах управления доступом субъектом всегда является поток.
Чтобы получить доступ к объекту, потоку необходимо идентифицировать в подсистеме безопасности операционной системы. У потока нет реквизитов безопасности Ч он его получить от участника безопасности, например от Алисы. При входе в систему реквизиты безопасности заключаются в мар кер доступа, связанный с ее сеансом в Когда Алиса запускает приложение, оно выполняется как процесс, являющийся сеанса в системе. Процесс приложения и каждый из его выполнения получают по марке ра доступа Алисы. Когда одному из потоков приложения необходимо открыть представляется как агент Алисы, предъявляя ее маркер доступа. Таким ответственность за все, что поток делает с файлом от лица Алисы лежит на ней.
Естественно, что потоки не открывают файлы так, как это делают пользователи, Потоки - это всего лишь на компьютере отрезки программного кода, и они взаимодействуют с объектами при помощи одного из интерфейсов прикладного программирования (API). Что бы поток открыл файл, его код должен содержать, например, команду:
Второй аргумент вызова функции CreateFile указывает желаемый прав до ступа (GENERICWRITE), сообщающий системе, что поток желает файл и изменить его. работают другие функции API. При вызове API необходимо, указав требуемый уровень доступа, со общить, какие действия над объектом Вы Прежде позволить потоку запрашиваемые действия, система проверяет, обладает ли с потоком участник уров нем доступа, запрошенным потоком. В проверки доступа сравнивается информация маркера доступа потока со сведениями дескриптора объекта:
ГЛАВА 12 Управление доступом Х из маркера доступа извлекается информация о S1D, идентифицирующая связан ного с потоком и групп, которых является этот пользователь;
Х из DACL дескриптора извлекаются записи управления доступом, в которых указано, какими правами доступа к объекту обладают и группы и в каких правах им отказано.
Подсистема безопасности ищет в объекта записи управления доступом, от носящиеся к и групп в маркере доступа пото ка. Она по очереди проверяет все для каждого SID, пока не находит ту, которая или запрещает доступ пользователю или одной из его или пока не проверит все АСЕ. Если проверены все АСЕ в DACL и так и не уда лось разрешен или запрещен необходимый потоку доступ, подсистема запрещает доступ к объекту. Этот показан на рис. 12-1.
Субъект Дескриптор безопасности Маркер групп проверяет о привилегиях записи DACL Запись управления доступом (АСЕ) ! Запись управления доступом Запись управления Запись управления доступом доступом найдена Запись управления доступом Рис. 12-1. Проверка запроса на доступ Порядок расположения записей управления доступом в DACL весьма На пример, в DACL объекта одна АСЕ может разрешать доступ группе, а другая -- за прещать доступ членом этой группы. Если в процеду ре проверки доступа АСЕ-запись, доступ группе пользователя, будет обработана прежде чем АСЕ, запрещающая доступ пользователю, то пользователь получит доступ к объекту. Попятно, что такой результат явно Обычно АСЕ располагаются в (canonical) порядке, согласно которо му запрещающие располагаются до разрешающих. В случае сначала об рабатываются доступ а потом разрешающие.
Однако иногда порядок не срабатывает. В примера рассмот рим показанную в таблице 524 ЧАСТЬ 2 Безопасность в системах Таблица 12-1. Неканонический порядок расположения АСЕ Тип Разрешение Allow (Разрешить) Administrators Full Control (Полный доступ) Deny (Запретить) Network (Сеть) Read (Чтение) Allow (Разрешить) Users Read (Чтение) Эта DACL администраторам доступ к объекту при входе в систему ло кально и по сети и ограничивает без административных полномо чий, предоставляя им доступ, только при локальном входе в систему. Хотя эта и не является канонической, она выполняет важную задачу, как и другие неканонические DACL. Однако применение неканонических DACL не запрещает но и не приветствуется, так как их действие иногда сложно понять. Неканони ческую DACL нельзя создать при помощи интерфейса пользователя, но возможно Ч программными средствами, Описание канонического порядка в данном дано кратко. Мы, не рассказываем о порядке АСЕ. от родительского объекта. Подроб нее о каноническом порядке Ч в разделе Порядок записей управления доступом в DACL далее в этой главе.
Права Право это разрешение выполнить операцию. В Windows 2000 только одно право безоговорочно - право пользователя разрешать или запрещать доступ к ресурсам, которыми он владеет. Все прочие права должны быть предо ставлены, а, значит, их можно отозвать. С точки ют два вида прав: разрешения и пользователей.
Разрешения Разрешение (permission) предоставляет право совершить операцию с определенным объектом, например файлом. Разрешения предоставляют владельцы: они могут любому пользователю или безопасности позволить любые действия над объектом из тех, которые позволены самим, том числе разрешить стать вла дельцем объекта.
Совет Несмотря на то, что выдаются отдельным их гораздо эффективнее давать группам безопасности. Лучше один предоставить право на какие-то действия чем повторять эту операцию многократно, для каждого члена группы. Все входящие в группу безопасности, полу чают разрешения, установленные для этой группы.
разрешения, заданного в явной форме, подразумевает запрещение до к соответствующим операциям над объектом. Например, если Алиса разре шит чтение своего файла только группе Marketing, не этой доступ будет закрыт.
В разрешении можно отказать и в явной форме. Например, если Алиса не желает предоставлять Бобу для чтения к файлу несмотря на то, что он входит в группу Marketing, она вправе Бобу чтение этого файла. На практике так и следует использовать явный запрет Ч предоставлять ГЛАВА 12 Управление доступом большему числу пользователей а потом исключать нее (Боб) или подмножества.
Каждое разрешение, предоставляемое владельцем объекта пользователю или груп пе, хранится в виде записи управления доступом в таблице входящей в со став дескриптора безопасности объекта. В интерфейсе пользователя АСЕ отобра жаются как Entries (Элементы разрешений) в диалоговом окне Access Control Settings (Параметры управления На рис. 12-2 записи управления в DACL файла Алисы.
1 (a Рис. 12-2. Разрешения для Алисы Примечание Разрешения на уровне файлов установить только для файлов распложенных на томе NTFS. На томе FAT разрешения устанавливаются лишь для ресурсов, но они не распространяются на файлы и папки, хранящиеся в со вместно используемом ресурсе. Более того, для ресурсов на томе FAT только сетевой доступ и никак не влияют на доступ пользовате лей, непосредственно работающих на компьютере. По этой причине применять фай ловую систему FAT на общих нежелательно, рекомендуется применять тома NTFS.
Установка разрешений для объектов Active Directory Разрешения для объектов Active Directory устанавливаются так же, как и для тов тома NTFS в окне Windows Explorer (Проводник Windows). Щелкните кнопкой мыши объект, в меню выберите Properties (Свойства) и в от крывшемся диалоговом окне Properties (Свойства) перейдите на вкладку Security (Безопасность).
Если Вы пользуетесь оснасткой Active Directory Users and Computers Directory Ч пользователи и компьютеры) в диалоговом Properties (Свойства) 526 ЧАСТЬ 2 Безопасность в распределенных системах может вкладки 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 может доступом к папке и всем ее содержимым, устанавливая для этой папки разреше ния, применяющиеся не только для нес самой, но и для всех объектов в ней. На пример, можно установить для объекта-папки разрешение на чтение группе Mar Если это разрешение реализовать, установив флажок This folder, subfolders and files (Для этой папки, се и файлов), его действие будет перенесено на все находящиеся в папке объекты. Группа Marketing получит доступ на чтение как к самой папке, так и ко всем и файлам. для объектов Active Directory переносятся Владелец контейнера в Directory имеет возможность разрешить доступ к определенному типу объектов в контейнере, предоставляя его для остальных типов дочерних Напри мер, владелец объекта (organizational unit, вправе дать разре шение на чтение группе Marketing и перенести его на дочерние объекты подразделе ния определенного типа. В частности, его на объекты Contact (Контакт), разрешение будет относиться только к но не к объек там User (Пользователь) или каким-либо объектам других типов. Другими распространение разрешений контейнеров на дочерние объекты в Active Directory типом объектов. На томах NTFS такая функция недоступна.
Установка разрешений на уровне свойств Разрешениями для объектов Active можно управлять на двух уровнях:
Х на уровне объекта. Разрешения, на уровне объекта, ся ко объекту. Так, разрешение на уровне объекта позво лит определенной группе, например Account Operators (Операторы со здавать в нем объекты;
Х на уровне свойств. Разрешения, на уровне свойств, ся только к отдельным свойствам объекта. Так, для объекта мож но задать разрешение на уровне позволяющее определенному пользо ГЛАВА 12 Управление доступом например Principal Self (то есть пользователю, представленному объек том), изменять свойство Home (Домашний адрес) этого объекта.
на уровне свойств нельзя управлять из диалогово го окна Access Control Settings (Параметры управления доступом), но начать сле дует именно с него. Чтобы открыть диалоговое окно Access Control Settings, выбе рите нужный объект в одном из инструментов, для управления Active Directory, например в Active Users and Computers Directory и компьютеры). Щелкните объект правой кнопкой в контекстном меню выберите Properties (Свойства), в открывшемся окне Properties (Свойства) перейдите на вкладку Security (Безопасность) и щелк ните Advanced (Дополнительно).
Чтобы добавить новое разрешение на уровне свойств, щелкните Add (Добавить) и в открывшемся диалоговом окне Permission Entry (Элемент разрешения) щелкни те вкладку Properties (Свойства). Список доступных разрешений на уровне свойств в Permissions (Разрешения), Для просмотра или редактирования действующих разрешений на уровне откройте диалоговое окно Access Control Settings (Параметры досту пом), выделите сначала один из элементов в Permission Entries разре шений), а затем View/Edit (Показать/Изменить). В диалоговом окне Permission Entry (Элемент разрешения) перейдите на вкладку Properties (Свой ства). Разрешения на уровне свойств перечислены в панели Permissions (Разреше ния). на уровне свойств для объекта-пользователя Алиса, Authenticated Users проверку), на рис.
Х :
Read П Home П Home П Home П Drive E П Write Home J Home a E Write Home Phone a Read home Phone : a Write Home Phone [Others) П ;
Read Initials П Х Х Cancel Рис. Разрешения на уровне свойств для объекта-пользователя На вкладке Properties (Свойства) все свойства а только те, которые требуются для управления доступом. Сами свойства объектов 528 ЧАСТЬ 2 в распределенных системах Active Directory и типы объектов в схеме. Типов и свойств (или атри бутов) объектов множество, поэтому для облегчения управления в интерфейсе отображаются только их небольшая часть. Отображаемое подмноже ство определяется фильтром.
Список типов и свойств, пропущенных фильтром объектов и попавших на вкладку, хранится в файле расположенном в папке на кон троллере домена. Фильтр можно модифицировать, добавляя или убирая из списка отдельные записи. Dssec.dat Ч это текстовый файл следующего формата:
= = Фильтр пропускает объект, если за объекта в квадратных скобках в следую щей строке проставлен знак @, которому присваивается значение 7. Чтобы не ото бражать этот объект, нужно изменить значение на 0. Имена отображаемых тов следуют за строкой с указанием типа объекта. Для отображаемых атрибутов ус танавливается значение 7, а для скрытых - 0.
Изменения, внесенные в файл Dssec.dat, не во вкладке Properties (Свой ства) до перезагрузки оснастки Active Directory and Computers Direc tory - пользователи и компьютеры) или любой другой служебной программы, при мененной для просмотра свойств. фильтра считываются при инициализа ции программы.
Подробнее о типах объектов и их атрибутах Ч в главе 4 Схема Active Маска доступа Разрешения в записях доступом (access control entry, АСЕ) представлены одним или несколькими битами в величине называемой маской па (access Запрашивая доступ к объекту, поток указывает требуемый тип до ступа в маске доступа. Во время проверки доступа операционная система сравнивает потоком маску доступа с масками доступа в записях управления доступом DACL объекта. На рис. 12-4 показана структура маски доступа.
11 Х 27 Х : Х 22 21 15, Х Зарезерви- Стандартные права доступа права доступа Обозначения GR (Generic Read) - чтение GW (Generic Write) - запись GE (Generic GA (Generic All) - все AS право доступа к 12-4. Структура маски доступа Каждый бит соответствует праву доступа отдельной операции или серии опера ций, которые можно совершить над Установка бита в маске мого доступа информирует о что поток нуждается в праве совершить соответ ствующую операцию. С другой стороны, установленный бит в маске доступа АСЕ указывает, в зависимости от типа АСЕ, разрешение или соответству ющей ГЛАВА 12 Управление Многие права доступа в маске доступа соответствуют которые мож но через пользователя, по и исключения.
торые из них вправе установить только определенный процесс, например создаю щий объект, и они для модификации средствами пользовательского интерфейса. Далее перечислены тины прав доступа в маски доступа, при нятой в Windows 2000.
Общие права доступа. Эти права применяются ко всем объектам, но их значение различается для объектов разных типов. Каждый тип объекта устанавливает соответствие отдельных общих прав доступа и стандартных и прав доступа. В таблице 12-2 общие права Таблица 12-2. Общие права доступа Константа в Win32 API GENERIC_ALL ни запись и исполнение на GENERIC_READ на чтение Доступ на Стандартные права доступа. Эти права более чем общие права доступа, тем не менее их для операций с большинством объектов. В таблице 12- стандартные права доступа.
Таблица 12-3. Стандартные права доступа Константа в Win32 API Значение DELETE Право удалить объект Право дескриптора безопасности за исключением SYNCHRONIZE Право использовать объект для Некоторые типы не поддерживают это право доступа Право DACL в дескрипторе безопасности объекта владельца в дескрипторе Право доступа к SACL (system access control list). Оно ограничивает читать и вносить в системную таблицу доступом (SACL) объекта, уп равляющую его аудитом. Операционная система разрешает доступ к SACL только при условии, что маркер доступа субъекта содержит привилегию Manage auditing and security log аудитом и журналом права доступа. В каждом типе объектов опре делен собственный набор прав о списке особых прав для ных типов объектов Ч на Web-странице Web Resources по адресу microsoft.com/windows2000/reskit/webresources, ссылка Microsoft Platform Development Kit (SDK).
Расширенные права В Active Directory управление пользователями, имеющими право опре деленные операции с объектом или одним его свойств, осуществляется так же, как и в файловой системе NTFS, настройкой Вместе с тем ка некоторых операций не связана с определенными свойствами. Этим 530 ЧАСТЬ 2 в распределенных системах может потребоваться управление доступом. Например, предоставление или в Send (Отправить как), которое обычно программы тронной почты для выяснения, ли пользователю отправлять почту от лица другого пользователя. Средства управления доступом к нестандартным дей ствиям или операциям называются расширенными правами (extended rights), Расширенные права не определяются маской доступа. У каждого расширенного права имеется свой глобально уникальный идентификатор Ему соответ ствует объект класса в папке расширенных прав Extended-Rights container конфигурации леса. Запись управления до ступом (АСЕ), которая расширенное право, содержит ветствующий определенному объекту класса Access Right.
Список расширенных прав не является чем-то раз и определенным. Раз работчики могут новые расширенные права для нестандартных операций, добавляя объекты класса Access Right в расширенных прав леса. Под о создании расширенных прав Ч на Web-странице Web Resources по адресу ссылка Microsoft Platform Software Development Kit (SDK), Средства служебной программы I Edit позволяют просмотреть содержание контейнера конфигурации, чтобы расширенные права, в лесе, Дабы отобразить все множество расширенных прав, определенных в лесе, те Edit, разверните узел Configuration и щелкните контейнер Extended-Rights. На риг. 12-5 показан расширенных прав леса в окне программы ADSI Edit.
Name CNЩ Edit If] cess Right О LJ с cat LJ a LJ Я О Й ffl | Рис. 12-5. Контейнер расширенных прав Подробнее об использовании Edit для просмотра контейнера Ч в главе 2 Хранение в Active Directory.
Несмотря на то, что система по-разному обращается с обычными и расширенными правами доступа, в интерфейсе пользователя эта разница незамет на. права отображаются наряду с обычными на вклад ке Security (Безопасность) страниц свойств объектов. Управляют расширенными правами так же, как и устанавливая флажок соответствующего параметра.
ГЛАВА 12 Управление доступом Права пользователей Право пользователя - это разрешение совершить операцию, которая влияние на всю систему, а на отдельный ее объект. Существует два типа прав права вход а систему (logon rights) и привилегии (privileges). Пра ва на вход в систему регламентируют способ доступа к компьютеру (с клавиатуры, по сети, как служба или как пакетной обработки) пользователей и прочих участников безопасности. Привилегии определяют, кому предоставлено равлять системными ресурсами Ч устанавливать время, загружать и выг ружать драйверы устройств, производить архивирование или восстановление фай лов и папок, а также выполнять другие действия, влияющие на всю систему в це лом. Полный список прав и их описание Вы найдете в Г пользователей.
В отличие от разрешений, которые предоставляются владельцем объекта, права пользо вателя и настраиваются в политике безопасности компьютера. Чтобы уз нать о правах пользователей на компьютере, войдите в систему под гой учетной записью, откройте папку Administrative Tools (Администрирование) в Control Panel (Панель управления) и запустите Local Security Policy (Локальная политика На рис. 12-6 User Rights прав пользователя) в политике безопасности компьютера, входящего в Act as of the operating system to Authenticated Users Account Policies up files and directories Server Policies,.
traverse Audit Policy User the system Security pagefile Public a token object Л IP Security on Local Create access to this from as a as a logon locally computer and user account;
Х from a remote system Server security audits Рис. 12-6. Назначение прав пользователей об использовании Local Security Policy (Локальная безопасности) конфигурирования локальной политики Ч в главе книги Распределенные системы. Книга 2. Ресурсы Microsoft Windows 2000 Server. (Русская 2001).
Конфликты между привилегиями и разрешениями В большинстве случаев конфликты между и разрешениями кают, когда права, для администрирования системы, пересекаются с правами владения ресурсами. В такой привилегия обладает более высо ким приоритетом, чем разрешение.
532 ЧАСТЬ 2 Безопасность в распределенных системах Например, для выполнения стандартной административной задачи архивирования файлов и программа архивирования должна открыть все папки в томе получить список в каждой из них, прочитать атрибуты всех файлов и дан ные в файлах, для которых установлен атрибут архивирования. Практически не возможно согласовать предоставление такого доступа с владельцами всех файлов и папок, все необходимые права включают в привилегию Back up files and directories (Архивирование файлов и каталогов, По умолчанию она предоставляется двум встроенным группам Ч Administrators ры) и Backup Operators (Операторы архива). Любой обладающий этой привилеги пользователь может получить доступ ко всем файлам компьютера для архиви рования системы. Эта привилегия не дает права к файлам и папкам для выполнения любых других действий. Оператор архива не сумеет, например, от крыть файл в редакторе, если, конечно, владелец файла явно не предоставил ему такое разрешение.
Способность стать владельцем файлов и других объектов Ч еще один пример как необходимость поддержки системы администратором берет верх над правом пользователя управлять доступом. Обычно владельцем объекта становятся только при наличии соответствующего от текущего владельца. Для этого тот установить Take Ownership (Смена владельца) на объекте тома В Active Directory аналогичное разрешение называется Modify Owner (Сме на владельца). Получив такое разрешение, новый владелец может делать с объек том все, что угодно, вплоть до запрета доступа к нему предыдущему владельцу. Ста новится понятно, почему пользователи предоставляют разрешение Take Ownership (Смена владельца) или Modify Ownership (Смена владельца). Вместе с тем, случается, сотрудники увольняются из компании, не позаботившись о переда че владения принадлежащих им ресурсов. В этом случае Вам пригодится гия Take ownership of files or other objects (Овладение файлами или иными объек тами, Обладающий этой вправе стать владельцем объекта без разрешения текущего владельца. По умолча нию эта привилегия только встроенной группе (Адми нистраторы). Обращаться с ней надо позволяет администраторам стать ресурсов и передать их другим с по мощью разрешения Take Ownership или Modify Ownership.
Идентификаторы безопасности Идентификатор безопасности (security ID, Ч это уникальное выражение пе ременной длины, служащее для идентификации участника безопасности или груп пы безопасности. Windows 2000 использует SID в следующих компонентах управ ления доступом:
Х в маркерах доступа (access token). Один SID в маркере доступа идентифициру ет представленного этим маркером, а дополнительные S1D Ч группы безопасности, членом которых является этот пользователь;
Х в дескрипторах безопасности (security descriptor). Один SID в дескрипторе бе зопасности объекта идентифицирует владельца объекта, а другой Ч основную группу владельца;
ГЛАВА 12 Управление доступом Х в записи управления доступом (access control entry, АСЕ). Каждая АСЕ содер жит SID, идентифицирующий или группу, для которой доступ раз решен, запрещен или отслеживается системой аудита.
SID учетной записи или группы создается системой в момент ее создания. SID ло кальной учетной записи или группы создается (Local Security компьютера и хранится вместе с осталь ной учетной записи в защищенной области реестра. SID доменной учетной записи или группы безопасности (security authority) домена и хранится в атрибута объекта или в Active SID уникальны в пределах области запи си или группы. S1D локальных учетных записей и групп уникальны на ре, где они были созданы, то есть SID не может принадлежать двум учетным записям или группам Аналогично SID всех учет записей и групп уникальны в предприятия. SID любой i домене учетной записи или группы никогда не совпадает с SID учетной записи или группы, в другом домене того же самого предприятия, S1D также во времени. Центры безопасности никогда один и тот же SJD дважды и не используют повторно SID удаленных учетных записей.
Предположим, у Алисы есть учетная запись домене Windows 2000, она увольня ется, а затем возвращается в ту же но на другую должность. При увольнении Алисы администратор удалил ее учетную запись, а вместе с ней и D, Когда Алиса возвратится на новую должность в ту же создаст учетную запись, a Windows 2000 для нее Ч новый SID. Этот безопасности не совпадает со старым, и поэтому пи одно из ных старой учетной записи прав доступа не перейдет к новой учетной записи сы. Таким образом, две учетные записи Алисы представляют двух совершенно раз ных участников безопасности.
Структура идентификатора безопасности Идентификатор безопасности (security SID) это структура данных в двоичном формате, переменное число Первые значения в структуре несут информацию о структуре SID, а остальные обозначают создав шие SID центры (например, Windows 2000) и а также опреде ленного участника безопасности или группу. На рис. 12-7 показана структура S1D.
Число разделов Редакция Источник идентификатора Раздел Ч Доменный идентификатор Раздел Ч Относительный идентификатор Рис. 12-7. Структура SID Далее перечислены структуры SID.
534 ЧАСТЬ 2 Безопасность в распределенных системах Редакция (Revision) Ч это версия структуры SID. Всем идентификато рам безопасности, Windows NT и Windows номер редакции 1.
Источник идентификатора authority) это идентификатор центра бе наивысшего уровня, способный для данного типа участ ников безопасности. Например, центра безопасности группы Everyone равно 1 (World Authority), а идентификатор отдельных за или групп Windows NT и Windows 2000 - 5 (NT Authority), Разделы набор идентификаторов одного или более безопасности (это наиболее важная информация в Совместно все эти за исключением идентифицируют домен в предприятии. Эта часть набора (domain identifier).
относящуюся к домену учетную или пу. Это значение является (relative identifier, RID). SID можно более наглядно, преобразовав SID из двоичного в формат:
Х S Ч свидетельствует, что строка является SID;
Х номер редакции;
Х X Ч идентификатора;
Х Y Ч набор разделов где количество значений, соответствующее поля Число разделов Count) на рис. 12-7.
Наиболее важная информация SID в наборе разделов. Первая часть набора Ч это идентификатор. Эта часть S1D важна для с несколькими так как именно доменный идентификатор различать созданные в разных доменах. После дний элемент в ряду значений это относительный идентифика тор, позволяющий различать учетные записи или группы внутри домена. В домене не может быть двух учетных записей или групп с идентификаторами.
Вот пример SID группы (Администраторы) в тизованном строковом представлении SID:
S-1-5-32- В этом SID:
Х номер редакции Ч 1;
Х источник Ч 5 (NT Authority);
Х доменный Ч Х относительный идентификатор Ч 544 (Administrators).
Значение доменного идентификатора в SID учетных записей и групп всегда равно 32. Эта значение идентифицирует домен Builtin, существующий на компьютерах под управлением Windows NT или Windows 2000. Нет необходи мости различать встроенные записи и группы различных поскольку область их локальна - либо для отдельного компьютера, либо, ГЛАВА 12 Управление доступом если в сетевом домене имеется доменных контроллеров, для группы ком один логический компьютер. Однако встроенные учет ные и группы отличать друг от друга в домене для это го в SID всех учетных записей и групп имеются уникальные относительные иденти фикаторы. 544 относительного идентификатора идентифициру ет группу Administrators Ни у какой другой учетной пли в пет S1D с 544, Рассмотрим еще один пример: глобальная группа Domain Admins ры домена) есть в каждом домене, поэтому SID каждой из них индивидуален. Так, SID группы Reskit\Domain Admins таков:
Здесь:
Х номер редакции Ч 1;
Х источник Ч 5 (NT Authority);
Х доменный идентификатор - (Reskit);
Х относительный идентификатор 512 (Domain Admins).
SID группы Admins отличается от других групп Domain Admins того же самого своим доменным идентификатором, 21-1004336348 Никакой другой домен в не это значение в качестве доменного идентификатора. SID группы Admins отличается от других и групп, созданных в домене Reskit, от носительным идентификатором 512. Ни у одной другой учетной или груп пы в домене нет значением 512.
Выделение относительных Создание уникальных относительных идентификаторов для учетных записей и групп, создаваемых на изолированном компьютере и хранящихся в базе управляемой локальным диспетчером учетных записей безопасности (Security Accounts Manager, SAM), представляет особой трудности. Чтобы безопасности, SAM компь ютера просто отслеживает прежде значения относительных иден тификаторов, Процесс уникальных относительных идентификаторов в сетевом домене более сложен. Б сетевых доменах Windows 2000 может быть контроллеров с Active Directory, хранящих информацию учетных записей. Это оз начает, что в домене существует столько экземпляров (реплик) базы дан ных учетных записей, сколько в нем доменных контроллеров. Более того, любая из существующих реплик базы учетных записей доступна для Новые записи могут создаваться на любом контроллере домена, при этом измене ния, в Active Directory на любом из контроллеров реплициру ются на все остальные контроллеры. Процесс в базы данных записей одного хозяина в реплики всех остальных называется операцией с хозяевами operation).
Процесс создания относительных является операци ей одиночного хозяина operation). В ней одному контроллеру домена роль хозяина идентификаторов (relative identifier master, 536 ЧАСТЬ 2 в распределенных системах или master). Он отдельные подмножества относительных идентифи каторов всем остальным контроллерам домена. Когда в реплике Active Directory на одном из контроллеров домена доменная учетная запись или груп относительный идентификатор для ее SID извлекается из пула дан контроллеру домена относительных Когда запас тельных идентификаторов на контроллере домена подходит к он вает новый пул у хозяина относительных идентификаторов.
Контроллер ответственен за то, чтобы относительные идентификаторы не использовались повторно. идентификаторов следит, чтобы относительных в выделяемых пулах повторялись.
Благодаря такому механизму все в домене учетные записи и группы по относительные Подробнее об операциях Ч в 7 операциями одиночного хозяина*.
Отличия SID и При создании новой доменной учетной пользователя или группы Active Directory сохраняет ее SID в Object-SID (objectSID) объекта пользова или Новому также присваивается глобально идентификатор (GUID) 128-разрядное значение, не только в пред приятии, но и во всем мире. Кроме объектов-пользователей и есть у всех объектов, создающихся в Active Directory. GUID каждого объек та хранится в его свойстве Object-SID (objectSID).
Внутренние механизмы Active Directory применяют GUID для идентификации объектов. Например, GUID является одним из свойств объекта, которые публику ются в глобальном каталоге. Если у пользователя имеется учетная на пред приятии, его легко в глобальном по у, Таким образом, поиск по Ч один из наиболее надежных способов найти не обходимый объект. Значения других свойств объекта могут меняться, но GUID Ч никогда. GUID сохраняется до конца существования объекта.
Несмотря на то, что идентификаторы безопасности иногда меняются, SID объекта остается прежним. перемещаются, и вместе с ними могут переме щаться их учетные записи, а группы остаются в доменах, в которых они созданы, Предположим, что Алиса переезжает из Америки в Европу, продолжая работать в той же компании. Ее учетную запись можно переместить вместе с ней, Для администратору предприятия достаточно переместить ее объект из в Reskit\Euro. В этом случае объекту учетной записи Али сы понадобится новый SID. Так как S1D этого создан в домене его часть, соответствующая доменному идентификатору, уникальна только для домена. В домене Euro SID учетная Алисы получит другой иден тификатор. Соответствующая относительному идентификатору часть SID также только в пределах домена, следовательно, при домена от носительный идентификатор тоже поменяется.
Таким образом, при перемещении объекта между доменами ему присваивается новый SID, который располагается в свойстве Object-SID. Перед значения старое копируется в другое свойство объекта-пользовате ля - Это Каждый раз при пере ГЛАВА 12 Управление доступом в новый домен создастся новый SID, который писывается в а старьте значения перемещаются в Когда пользователь входит в систему и успешно проходит проверку проверки подлинности домена запрашивает у Directory все SID дан ного пользователя - как текущий, так и старые, а также S1D групп. Все S1D клиенту, подлинность которого проверялась, и включаются в маркер ступа. При попытке пользователя получить доступ к ресурсу все его указанные в его маркере доступа (в том числе и SID из SID ведется история идентификаторов безопасности. Определяя по рядок доступа пользователей к ресурсу на основе их должностных обязанностей, администратору следует устанавливать его для целых групп, а отдельных пользо вателей. Таким образом, он сможет легко корректировать доступ пользователей к ресурсам в случае изменения их должностей и перехода в другие отделы, просто удаляя их из одних групп и добавляя их в другие. Однако желательно, чтобы до ступ пользователя не зависел от перемещений его записи между Свойство позволяет реализовать. Когда пользователь переме щается в другой домен, нет необходимости список управления (ACL) ресурсов. Пользователь доступ, даже если нового SID в по есть старый SID, указанный в маркере доступа среди SID пользовательских групп.
Причина, по которой для идентификации используются SID, а не обрат ная совместимость. В Windows NT для пользователей и групп ACL ресурсов применяются SID. Чтобы при обновлении операционной системы не пришлось менять ACL всех ресурсов только из-за того, что новая схема лучше, в 2000 списки управления доступом идентифицируют но SID, а не по GUID. ресурсов Active не исключение. Пользователь получает доступ к политики на S1D пользователя, а не Известные идентификаторы безопасности некоторых SID одинаковы во всей системе. Они называются известными SID так как идентифицируют пользователей и груп пы общего типа. Вот некоторые S1D этой группы.
Everyone (Все) в общую автоматически включается каж дый, кто работает на компьютере, в том числе и пользователей. Источ ник этого S1D Ч 1 (World Authority). У SID есть только один раздел Ч 0 (Null RID).
Creator Owner (Создатель-владелец) Ч тип пользователя Creator Owner (Создатель-владелец) служит заполнителем в наследуемой АСЕ. При АСЕ система SID пользователя Creator Owner (Создатель-Владелец) на SID текущего объекта. Источник этого SID Ч 3 (Creator Authority). У этого STD есть только раздел 0 (Null RID).
Principal Self (Self) этот тип общего пользователя служит е лем (placeholder) в объекта и компьютер в Active Directory. предоставленное Principal Self, дается участнику сти, который При проверке доступа операционная система SID пользователя Principal Self SID представленного объектом 538 ЧАСТЬ 2 системах Источник для этого 5 (NT Authority). У SID есть один раздел - Существуют и другие известные SID. Их список приведен в приложении Наи более известные идентификаторы безопасности*.
Маркеры доступа Маркер доступа (access token) это защищенный объект, содержащий идентифи кационную информацию и о привилегиях, связанных с учетной записью Когда клиент входит в систему или пытается создать сетевое с компьютером под управлением Windows 2000, проверяется подлинность входных Если ее результат ный, служба входа в систему возвращает пользователя и его групп Администратор локальной безопасности (Local Security Authority, LSA) компьютера применяет эту для создания маркера до ступа, содержащего возвращенные входа в систему SID и список приви политикой локальной груп пам безопасности. Экземпляр маркера доступа ко всем и потокам, в контексте пользователя. При взаимодей ствии потока с защищенным объектом или при попытке выполнить системную за дачу, для которой нужны привилегии, система устанавливает уровень авторизации, проверяя прикрепленный к потоку маркер доступа.
Содержание маркера доступа Маркер доступа содержит полное описание контекста безопасности процесса или потока, в том числе и данные, перечисленные ниже.
Пользователь SID учетной Если пользователь входит в систему под учетной записью локального компьютера, его SID извлекается из базы данных учетных записей, поддерживаемой локальным диспетчером (Security Account Manager, SAM). При входе в систему под учетной записью домена, его S1D извлекается из свойства объекта в Active Directory.
Группы (Groups). Список групп безопасности, в которые входит пользователь.
В этот список также включены S1D из свойства объекта тель, представляющего учетную в Active Directory.
Привилегии (Privileges). Список привилегий, пользователю и его группам безопасности на локальном компьютере.
Владелец (Owner). SID пользователя или его группы который ста новится по умолчанию любого объекта, создаваемого им самим или переданного ему во владение.
Основная группа (Primary Group). основной группы безопасности пользова теля. Эта информация используется только подсистемой POSIX и игнорируется остальной частью Windows 2000.
Стандартная избирательная таблица управления доступом (Default Discretionary Access Control Встроенный набор разрешений, который операционная систе ма устанавливает для создаваемых объектов, если не предоставлено никакой другой информации доступом. Стандартная DACL ГЛАВА 12 Управление доступом полный доступ для Creator Owner (Владелец-создатель) и System Подробнее об доступом, применяющейся по умолчанию для новых объектов в разделе вновь далее в Источник (Source). Процесс, который вызвал создание маркера доступа, например петчер диспетчер локальной сети или сервер удаленного вызова процедур.
Тип (Туре). Значение, является ли маркер доступа основным кером или маркером олицетворения. Основной маркер доступа Ч это маркер до ступа, контекст безопасности процесса. Маркер это маркер доступа, который может использоваться потоком для временной рабо ты другом безопасности, например в контексте безопасности клиента, Уровень Level). Значение, которое показывает, в какой мере служба может контекст клиента, ного данным маркером доступа.
Статистика Информация о самом маркере доступа. Используется ренними операционной системы.
Ограничивающие SID (Restricting Необязательный список SID, добавляе мый в маркер доступа обладающим создания ченного маркера. Такие доступ потока до уровня более низкого, чем предоставленный пользователю.
Идентификатор сеанса (Session ID). Значение, указывающее, соединен или пет маркер доступа с клиента службы терминалов.
Олицетворение Олицетворение Ч это способность потока действовать в контексте безопасности, отличном от контекста процесса, к которому Олицетворение разра ботано для приложений, где оно применяется в службах. Выпол няющаяся в клиента служба в мере является самим клиентом. Один из ее потоков использует маркер доступа, представляя удо стоверения клиента для получения доступа к объектам.
Основное назначение олицетворения Ч чтобы проверка доступа по к клиенту, а не к службе. Применение реквизитов вызыва ет, в от разрешений клиента, как сужение, так и расширение доступа.
Предположим, к примеру, что па файловом сервере файлы с конфиден информацией, защищенные средствами Чтобы клиент не мог лучить несанкционированный доступ к информации в этих файлах, обращаясь к ним, служба клиента, Каждый процесс обладает маркером (primary marker), контекст связанной с процессом пользовательской учетной записи.
Пользователь, связанный с процессом приложения, Ч это просто человек, запус тивший эту программу. Когда же дело касается службы, то это не так. Службы выполняются под собственными учетными записями и в своем сте безопасности. Системные службы, установленные вместе с операционной си стемой, выполняются под записью локальной Другие службы можно также настроить на выполнение под этой учетной записью или выдел им отдельные учетные записи в локальной системе или Active Directory.
540 ЧАСТЬ 2 Безопасность в распределенных системах нее об установке и настройке домена Ч в главе 5 Публикация служб в Active Directory.
Основной маркер службы связан с в процессе службы и с потоками, от лица Он учет ную запись службы, группы этой учетной записи и ее привилегии. Эта ция используется при проверке когда служба доступ к объек там, для ее собственной работы.
Обслуживая клиента, служба создает рабочий поток и с ним клиентский маркер доступа. маркер доступа называется маркером оли (impersonation token). Он клиента, его группы и вилегии. Эта информация используется при проверке доступа, когда поток запра шивает доступ к ресурсам от лица клиента. Завершив работу в режиме олицетворе поток применяет первичный маркер и из контекста ти клиента в собственный контекст безопасности службы.
Механизм олицетворения на рис.
Серверный Управляющий поток Х от лица Self маркер Х Выполняет Рабочий поток вызов Х Выполняет запрос клиента Х Возвращается к контексту Self Основной маркер и маркер олицетворения в службе Уровни олицетворения возможно, когда клиент позволить серверу в определенной степени стать этим клиентом. Выбирая уровень олицетворения при подключении к службе, процесс клиента может определять, в какой степени служба дей ствовать от имени клиента. уровень клиент информи рует службу о пределах, в которых она имеет право действовать от его имени.
не в состоянии выбирать уровень олицетворения. Он указывается в коде в виде сведений о качестве безопасно сти (Security Quality of Service, Существуют четыре уровня: анонимный (anonymous), (identify), (impersonate) и делегирова ния (delegate). Анонимный уровень никогда не поддерживался. В версиях, ствующих Windows 2000, поддерживались только два уровня и олицетворения. В Windows 2000 добавлена поддержка делегирования.
Анонимный уровень. Клиент службе. Служба может кли ента, но маркер олицетворения не содержит никакой информации о клиенте.
ГЛАВА 12 Управление доступом Уровень Службе разрешается получить информацию идентифи кации клиента и ее в собственном механизме безопасности, но не решается олицетворять клиента.
Уровень олицетворения. Если служба находится на том компьютере, что и кли ентский процесс, то разрешается доступ к сетевым ресурсам от лица Служба на удаленном компьютере может олицетворять клиента только при досту пе к ресурсам компьютера службы.
Уровень делегирования. Служба олицетворяет клиента не только доступе к ресурсам службы, но и при к ресурсам других компьютеров.
Этот поддерживается только в Windows 2000 и последующих этой системы.
Настройка клиентов и служб для делегирования Олицетворение работает па уровне только при соблюдении следую щих условий:
Х компьютеры, на которых выполняется клиентский процесс, серверный процесс, а также любые целевые службы, должны работать под управлением Windows и в доменах Windows 2000, так как для делегирования требуется поддержка про токола проверки Kerberos;
Х чтобы пользовательская учетная запись клиента имела на делегирование;
Х учетная запись службы должна иметь разрешение па делегирование.
Чтобы сконфигурировать учетную запись для делегирования, ните правой кнопкой объект в оснастке Active Directory Users 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 Directory Ч пользователи и компьютеры), в меню выберите Properties (Свойства) и в диалоговом окне Properties (Свойства) перейдите на вкладку General (Общие). Найдите и установите фла жок Trust computer for delegation компьютеру права представителя).
На рис. 12-10 как выглядит правильная установка.
542 ЧАСТЬ 2 Безопасность в распределенных системах Рис. 12-9. Проверка подлинности пользователя настроена для делегирования Рис. 12-10. Учетная запись компьютера доверена для делегирования ГЛАВА 12 Управление доступом Внимание! Доверяя делегирование, Вы позволяете делегирование всем службам, выполняющимся под учетной локальной системы. Таким обра зом, служба, па компьютере неосмотритель ным администратором и настроенная на выполнение в контексте локальной систе мы, может получить доступ к сетевым других пользовате лей. Предпочтительнее настроить систему так, чтобы делегирование, выполнялись в домене под своей учетной записью, кото рой управляют администраторы домена.
Учетная запись домена, под которой выполняется служба, должна быть для выполнения представителя (делегата). Чтобы скон фигурировать учетную запись для работы со службой, щелкните вой кнопкой объект в оснастке Active Directory Users and Com puters (Active Directory Ч пользователи и компьютеры), в контекстном меню берите Properties (Свойства) и в открывшемся диалоговом Properties (Свой перейдите на вкладку Account (Учетная запись). В списке параметров учет ной записи найдите и установите флажок Account is trusted for delegation (Учет ная запись доверена для На рис. показано, как выглядит пра вильная установка.
Г Account is delegation Do I Рис. 12-11. Учетная запись службы, доверенная для выполнения в качестве представителя Атрибуты SID в маркере доступа S1D каждого пользователя или группы может содержать в маркере доступа или два атрибута, порядок обращения с S1D при поверке доступа.
По этим атрибутам система определяет, что SID необходимо либо во 544 ЧАСТЬ 2 Безопасность в распределенных системах АСЕ (access control либо только в управления доступом, щих доступ. Атрибуты SID в таблице 12-4.
Таблица 12-4. Атрибуты SID Атрибут с атрибутом используется для проверки доступа. При этом система, все АСЕ, содержащие SID Только Windows 2000: SID с проверкой только (deny-only SID). При проверке доступа система проверяет АСЕ, которые запрещают доступ этому а все остальные записи управле ния доступом игнорирует Оба атрибута исключают друг друга. Если установлен один из них, другой Если не установлен ни один атрибутов, SID игнорируется.
Более того, ни один процесс не имеет права удалить из S1D атрибут проверки толь ко на запрет.
Ограниченные маркеры В Windows 2000 приложение может процесс в ограниченном кон тексте безопасности, чтобы в таком код меньши ми полномочиями, чем пользователь данного приложения. Например, при примене нии браузера для просмотра Web-страницы в небезопасной зоне, связанный с Web страницей код может на текущем компьютере с ограниченными приви легиями. (Эта функция в Microsoft Internet Explorer версии 5.0 и более ранних.) А при получении почты с вложением приложение, открывающее вложенный может выполняться с ограниченным доступом к ре сурсам компьютера. (Эта функция еще не доступна в Microsoft Outlook 2000.) Приложения создают ограниченный контекст безопасности для дочерних процес сов и потоков олицетворения, присваивая им маркеры token). Такие маркеры создаются путем отзыва отдельных привилегий Ч установ кой атрибута проверки только на запрет отдельных SID или добавлением списка ограничивающих SID к основному маркеру доступа.
Когда ограниченный таким образом процесс или поток пытается получить к защищенному объекту, система дважды проверяет доступ: обычные SID и SID только на после чего - ограничивающие SID. Доступ предоставляется только в том случае, если результаты обеих проверок Ч удовлет ворительны и запрошенные права доступа разрешены.
Подробнее о том, как создаются использующие марке ры на Web-странице Web Resources но адресу Microsoft Platform Software Kit (SDK).
Дескрипторы безопасности Связанная с объектом информация доступом содержится в дескрипто ре (security descriptor) объекта. Когда пользователь пытается выпол нить над объектом какие-либо действия, проверяет ГЛАВА 12 Управление доступом тор безопасности объекта, чтобы ли пользователю такие Информация, которая включается в дескриптор от типа объекта и от как этот был создан. В общем случае дескрипторы безо пасности содержат следующие данные:
Х какие пользователи владеют объектом;
Х каким пользователям и группам разрешен или запрещен Х для каких пользователей и групп должен вестись аудит доступа;
Х как объекты в контейнере наследуют от пего информацию доступом.
Части дескриптора безопасности Дескриптор безопасности собой двоичную структуру данных перемен ной длины. Бот из каких частей состоит дескриптор безопасности, Заголовок (Header) Ч содержит номер редакции и набор управляющих флагов, описывающих некоторые характеристики дескриптора порядок раз мещения в наличие отдельных дескриптора, а также как добав лялись и изменялись отдельные элементы, Владелец (Owner) Ч содержит SID объекта. Владелец объекта может изменять и предоставлять другим пользователям право становиться владельцем.
Основная группа Group) Ч содержит группы владельца. Эта используется только подсистемой и остальной частью Windows 2000.
Избирательная таблица управления доступом (Discretionary Access Control DACL) Ч является списком, состоящим из записей управления доступом (access control АСЕ). Таких записей может быть несколько, или они могут вообще отсутствовать. У каждой АСЕ имеется заголовок, информирующий о том, или запрещает АСЕ доступ к объекту, SID пользователя или группы и маска доступа, в которой перечислены операции. Содержанием объекта. Владелец может дать полномочия управления пользователям, предоставив им Permissions разрешений Системная таблица управления доступом Access Control List, SACL). SACL похожа на но она используется для проведения аудита, а не для доступом к объекту. При подлежащего аудиту действия си стема регистрирует событие в журнале У каждой записи управления доступом в SACL есть заголовок, в котором регистрируемое отказ или и то и другое), SID, указывающий, за каким пользователем или группой бе зопасности необходимо и маска доступа, в которой аудиту операции. управляют администраторы безопасности ло кальной системы Ч обладающие привилегией Manage auditing and security log (Управление аудитом и журналом безопасности). По эта назначается встроенной (Администраторы).
Размещение в памяти Существуют два типа размещения дескриптора безопасности в памяти: с относи тельной или абсолютной адресацией. Управляющий флаг в заголовке дескриптора 546 ЧАСТЬ 2 Безопасность в системах указывает, какой из этих двух форматов в деск рипторе безопасности.
Дескриптор безопасности с (self-relative) хранится в прерывном блоке и местоположение его элементов выражается в виде сме щения от начала этого блока. Для адреса любой части дескриптора бе процессу достаточно начальный адрес безопас ности. Указатель нужный дескриптора процесс определя ет, добавляя к этому адресу величину смещения элемента. (По этому его Ч дескриптор с относительной адресацией. Адреса его частей отсчитываются от его начала.) На рис. 12-12 пример дескрип тора безопасности с относительной адресацией.
Смещение Рис. Дескриптор безопасности с относительной адресацией Относительная адресация в дескрипторах объектов, ко торые должны храниться на диске, при помощи коммуникационного протокола или копироваться в память.
безопасности с адресацией (absolute) содержит не саму ин формацию, а указатели к ней. Этот формат позволяет располагать компоненты дес криптора безопасности по отдельности и собирать их в процессе работы. Он при меняется для которым не требуется постоянное хранилище, например для объектов, существующих только в течение жизни отдельного процесса. На рис. 12 13 показан пример размещения дескриптора безопасности с абсолютной адресаци ей.
Рис. 12-13. Дескриптор безопасности с абсолютной адресацией Управляющие флаги дескриптора безопасности Заголовок дескриптора безопасности содержит флагов, ко торые уточняют значение дескриптора безопасности или его компонентов. В Windows 2000 флаги играют важную роль в автоматическом перено се информации от родительских тов к дочерним (вложенным) объектам.
ГЛАВА 12 Управление доступом Управляющие флаги дескриптора в и изменя ются установкой или сбросом флаги дескриптора безопасности перечислены в таблице 12-5.
Таблица 12-5. Управляющие флаги дескриптора безопасности Флаг Значение SE AUTO 2000: досту пом в DACL этого объекта переносятся на объекты.
Этот флаг не устанавливается в дескрипторах ности Windows NT, которая не автомати АСЕ SE DACL DEFAULTED DACL установлена по умолчанию, Этот флаг влияет на то, как система поряжается в отношении наследования.
система игнорирует этот если не установлен SE_DACL_PRESENT ' SE DACL PRESENT Дескриптор безопасности содержит DACL, Windows 2000: если этот флаг не установлен (DACL в дескрипторе отсутствует), необходимо установить Иначе ная система дескриптор безопасности SE DACL PROTECTED Windows 2000: DACL дескриптора не мо жет АСЕ. Если флаг дескриптор безопасности инфор мацию от родительского объекта SID основной группы установлен по умолчанию SID по умолчанию SE SACL AUTO Windows 2000: записи управления пом в SACL этого объекта на существую щие объекты.
Этот флаг не устанавливается в дескрипторах ности Windows NT, которая не автомати ческий наследуемых АСЕ SACL установлена по умолчанию.
SE SACL DEFAULTED флаг может на то. как операционная сис тема SACL в отношении наследования.
Операционная система игнорирует этот флаг, если не установлен SE_SACL_PRESENT Дескриптор безопасности содержит SACL Windows 2000: SACL дескриптора безопасности не мо SE_SACL_PROTECTED жет изменяться наследуемыми АСЕ Дескриптор безопасности с относительной SE SELF вся информация в блоке памя ти. Если этот флаг не установлен, дескриптор безопас ности является дескриптором с Источники информации управления доступом При создании объекта управления доступом сначала записывается и дескриптор безопасности. Впоследствии она может изменяться. В любом 548 ЧАСТЬ 2 Безопасность в распределенных системах в дескриптор безопасности поставляют следующие ис точники:
Х субъект, Х объекта, Х родительский объект.
Во время нового объекта дескриптор безопасности назначается субъектом.
В случае система создает на ос нове информации управления от родительского объек та. Если такой информации нет, операционная система по умолчанию, которая предоставляется объек тов данного типа.
После создания объекта информацию в его дескрипторе безопасности вправе кор владелец или другие обладающие соответствующими Изменения могут также исходить от родительского объекта, когда его владелец изменяет дескриптор контейнера. При любом редакти дескриптора безопасности объекта диспетчер объекта носит изменения па все объекты.
Субъекты Субъектом называется поток, в контексте безопасности, предос тавленном маркером доступа. Маркер доступа субъекта содержит информацию, используемую для создания дескрипторов безопасности новых создаваемых им объектов и для изменения дескрипторов существующих объектов. Эта информация в нолях.
Владелец (Owner). Это поле маркера содержит SID, идентифицирующий участника безопасности, который по умолчанию становится владельцем объектов, субъектом. Обычно по умолчанию указан в маркере досту па. Если пользователь группы Administrators (Администраторы), поле Default Owner (Владелец по умолчанию) содержит SID не самого пользователя, а Если входит в группу Domain Admins (Ад министраторы домена), владельцем объектов Active Directory, которые он создает или которые переходят его становится сам пользователь, а группа домена. Когда SID Default Owner маркера доступа субъек та копируется в поле объекта, в дескрипторе устанавлива ется управляющий флаг Основная группа (Primary Group). Это поле маркера доступа содержит SID основ ной группы пользователя. Когда из поля основной группы доступа субъекта копируется в поле основной группы дескриптора безопасности объекта, в дескрипторе безопасности устанавливается флаг Стандартная DACL Это поле маркера доступа может быть пус тым или содержать избирательную доступом (discretionary access control list, DACL). DACL присваивается дескриптору безопас ности нового объекта, когда никакой другой информации управ доступом. В этом случае в безопасности флаг SE DACL ГЛАВА 12 Управление Диспетчеры объектов Диспетчер объекта manager) может в определенных случаях новым объектам информацию по умолчанию. Требования к объектам разных типов отличаются, каждый тип обслуживается своим диспетчером объекта. В таблице 12-6 перечислены стандартные типы объектов и диспетчеры каждого из них.
Таблица 12-6. Диспетчеры объектов стандартных типов Тип объекта Диспетчер объекта Файлы и папки Файловая система NTFS ресурсы Служба сервера (Server Service) Объекты Active Directory Directory реестра Реестр Службы служб (Service Control Manager) Принтеры печати (Print Терминалы, станции, Диспетчер окон (Window Manger) рабочие столы и о по умолчанию, предоставляемых диспетчерами тов. - в справочной системе Windows 2000 раздел Объекты и диспетчеры объектов.
Родительские объекты Некоторые объекты способны включать в себя другие объекты. объект папка NTFS может содержать объекты-файлы и другие объекты-папки, а объект раздела реестра Ч объекты-подразделы. В Active Directory объект содержит другие объекты-подразделения, а также объекты груп па и компьютер. Объекты могут содержать объекты локонная стан ция (windows station), содержащие рабочий стол, которые, в свою очередь, яв ляются контейнером для объектов локно. Любой объект другого объек та называется объектом или (child object).
го объекта называется объектом (parent object).
Потомку разрешается наследовать информацию управления доступом от родитель ских объектов. Предположим, администратор сервера создал общий файловый ре состоящий из одной папки для хранения информа ции, в пользование. Поэтому администратор установил раз на рис. 12-14.
Ни одно из на рис. 12-14, не получено путем наследова ния, потому что администратор снял флажок Allow inheritable permissions parent to propagate to this object (Переносить наследуемые от родительского объекта разрешения на этот объект). Это действие администратора вызвало уста новку управляющего флага SE_DACL_PROTECTED дескриптора безопасности, предохраняющего дочернего объекта от наследования этой таблицы от ро дительского Приобретенные в результате разрешения называются ми (inherited permission). Разрешения, назначенные не по механизму наследования, называются установленными явно (explicit permissions). Один из способов отличить явно от унаследованного выделить в списке 550 ЧАСТЬ 2 Безопасность в распределенных системах Permission Entries (Элементы разрешений) и прочитать отображаемый под спис ком На рис. 12-14 второй элемент разрешений, а текст под гласит This permission is defined directly on this object (Это разрешение определе но в этом объекте). Другими словами, данное разрешение являет ся не унаследованным, а установленным явно.
Modify folder and to la and enable of Рис. 12-14. Окно настройки управления доступом папки группа Administrators Кроме того, в тексте на рис. 12-14 содержится сообщение This permission is inherited by child objects (Это разрешение наследуется дочерними Разрешения, переносимые с родительского объекта на дочерние, называются наследуемыми (inheritable Чтобы выяснить, какие из разрешений, уста новленных на родительском объекте, являются наследуемыми, достаточно взгля в Apply to (Применять) панели Permission Entries (Элементы разре шений). Текст This object only (Только для этого объекта) или This folder only (Только для этой папки) сообщает, что разрешение не наследуется объектами. Из разрешений на рис. три Ч наследуемые, а одно Проиллюстрируем наследование Предположим, что Алиса создала Будучи инженером, она назвала свою папку Engineering Data, Так как новый объект-папка Ч дочерний по отношению к DACL наследует разрешения из DACL объекта Разрешения на новом объекте па рис. 12-15. Обратите внимание, что Алиса сбросила флажок Allow inheritable permissions from parent to propagate to this object (Переносить наследуемые от родительского объекта на этот объект), разреше из DACL родительского объекта наследуются дочерним объектом. Унаследо ванные разрешения помечены (бледным) ярлыком связка ключей.
Такие разрешения действительны Ч нельзя только изменять параметры Унаследованные разрешения определяются на родительском объекте, для их корректировки достаточно модифицировать DACL родительского объекта.
ГЛАВА 12 Управление доступом Full Control This only Allow and files to tiasobjeEf all child and of Рис. 12-15, Окно настройки параметров управления доступом папки Engineering Data (владелец Ч Алиса) Несмотря на что унаследованные не вла дочернего объекта вправе добавлять в его явно решения. Предположим, что Алиса считает унаследованные предостав Creator Owner (Создатель-владелец), слишком строгими, они вносить изменения в файл только создавшему его пользователю. Ей же нужно, чтобы все члены группы могли редактировать и добавлять ин формацию в папку Engineering Data. Для этого этой группе явное позволяющее изменять все находящиеся в папке объекты. Если Алиса полагает, что сотрудники отдела маркетинга не работать с информацией в папке Engineering она может явным образом запретить группе Marketing пол ный доступ к этой папке, ее подпапкам и файлам. Результат изменений, внесенных Алисой в управления доступом, показан на рис.
Теперь в списке элементов разрешений на рис. 12-16 имеются два явных разреше ния, ярлыками, информирующими, что эти элементы можно ровать. Обратите внимание: явные разрешения размещаются вверху списка. Они расположены в том в порядке, в котором обрабатываются во время провер ки Явные расположены перед потому что они обрабатываются первыми. Расположение обусловлено нием, что владелец дочернего объекта добавляет явные для разрешений. В нашем примере (рис. 12-16) унаследованное шение позволяет группе Everyone (Все) читать содержимое папки, и лов. Алиса добавила явное разрешение, запрещаюшее полный доступ подмножеству группы Ч группе Marketing. Запись с явным запрещением расположен перед унаследованными поэтому обрабатывается раньше любого 552 ЧАСТЬ 2 Безопасность в распределенных системах Full Full Control and files on Рис. Окно с измененными параметрами управления доступом для папки Engineering Data Алиса установила оба явных для This subfolders, and files (Для этой папки, ее и файлов), поскольку дочерние объекты в ее папке долж ны наследовать новые бы папка Data располагалась на сервере управлением Windows NT, новые явные разрешения лись бы только на вновь в ней объекты. Модель используемая Windows NT, поддерживает только в момент создания объекта. Чтобы изменить разрешения для существующих объектов, Алисе при шлось бы дополнительно установить явные разрешения для каждой существующей и файла. Windows 2000 - это наследование после созда ния (то есть для уже объектов). Новые или наследуе мые разрешения в объекта автоматически на су ществующие дочерние объекты при изменении DACL родителя. В только что опи санном примере элемент, запрещающий группе Marketing доступ к Engineering Data, на подпапки. как только Алиса щелкнет Apply (Применить) в диалоговом Access Control Settings (Параметры управления доступом).
Автоматический перенос - это позволяю щий изменять во объектов, редактируя разрешения только на объекте верхнего уровня дерева. Предположим, что член группы Administrators (Администраторы) решил, что информация в папке и ее подпапках больше не предназначена для всех, и доступ к ней нужно закрыть группе Everyone так как в входят все обладающие доступом к в том числе и и гости. Доступ к папке предполагается предос тавить группе Authenticated Users (Прошедшие в которую входят толь ко пользователи, прошедшие проверку подлинности. Таким образом, требуется про сто заменить Everyone (Все) на Users (Прошедшие проверку) в элементах списка разрешений, как на рис. 12-17.
ГЛАВА 12 Управление доступом User: Read an Allow Authenticated Users CREATOR OWNER and files Рис. Окно с измененными параметрами управления доступом для папки После изменений управления доступом родительского объекта все на следуемые из DACL родительского объекта переносят ся в DACL и файлов. На рис. как это повлияет на разре шения группы Engineering Data.
Name Control and files Engineering Allow Full Control and Alice.
CREATOR OWNER Ful and to below.
where parent.
of Рис. 12-18. Новые унаследованные разрешения для группы Engineering Data 554 ЧАСТЬ 2 в распределенных системах Следует отметить, что перенос наследуемых с папки на пайку Data не изменяет в дочернем 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 (Смена В отличие от неотъемлемого права владельца это разрешение может быть По умолчанию объекта является участник безопасности, указан ный как владелец по умолчанию в маркере доступа, прикрепленном к создающему процессу. При создании объекта SID из поля владельца маркера доступа копирует ся в поле владельца дескриптора безопасности. Обычно владельцем по умолчанию становится текущий и системе. Исключение Ч когда пользователь входит в группы (Администраторы) или Domain Admins (Админис траторы домена). Тогда поле владельца пользовательского маркера доступа содер жит SID а не SID отдельной учетной записи пользователя. И это но: административные учетные записи должны исключительно для системы, а не для каких-либо других целей. Таким образом, созданными администратором объектами могут управлять другие админис траторы же группы.
Если административная например Administrators (Администраторы), вла деет объектом, право владельца изменять для этого объекта всем и каждому члену этой группы. Эта возможность зачас тую неизвестна администраторам. Предположим, войдя в систему учетной за писью члена группы Administrators (Администраторы), Алиса создала файл и зап ретила Бобу изменять его. Владельцем файла становится не сама Алиса, а Administrators, поэтому, если Боб также член группы он получает право Change Permissions (Смена разрешений) и, значит, вправе предоставить себе изменять файл, невзирая на попытки Алисы запретить ему это, ГЛАВА 12 доступом Предоставляя разрешение Take Ownership (Смена владельца), владельцы могут давать другим возможность становиться владельцами.
Аналогичное разрешение по отношению к объектам Active Directory и их владель цам Owner (Смена владельца). Оба относятся к од и тому же праву доступа - Единственное между ними - разные в оригинальном пользовательском того, пользователи с привилегией Take ownership of files or other objects (Овладе ние файлами или иными объектами) могут становить ся владельцами разрешения. По умолчанию эта привилегия назначается только группе Administrators (Администраторы).
Когда становиться владельцем объекта, S1D владельца по в маркере копируется в поле владельца дескриптора бе зопасности объекта. Если переходит к члену группы министраторы) или, для объектов Active Directory, к группы Domain Admins (Администраторы по становится группа, а не от пользователь. На рис. 12-19 вкладка Owner (Владелец) объекта папки, созданной Бобом, членом группы Administrators (Администраторы).
Рис. 12-19. Вкладка Owner (Владелец) объекта-папки Невзирая на то, что папку создал Боб, на вкладке Owner (Владелец) указан теку щий владелец объекта Ч группа При создании SID из поля владельца по маркер Боба помещается в поле владельца дескриптора безопасности объекта. Так как Боб является членом группы (Администраторы), указанная его маркере доступа в каче стве владельца по умолчанию группа администраторов становиться владельцем объекта. На рис. 12-19 показано, что Боб может сам стать владельцем объек та. Для этого ему надо просто выбрать свое имя в списке Change owner to (Изме владельца на) и щелкнуть Apply (Применить). Даже если Боб станет 556 ЧАСТЬ 2 Безопасность в распределенных системах любой член группы администраторов сможет вернуть право владения от лица группы. На самом деле член группы администраторов имеет право стать владель цем любого объекта независимо от того, кто им владел. Эта функ ция в систему, и ее невозможно отключить.
Следует обратить внимание на то, что на вкладке Owner (Владелец) (рис. 12-19) флажок Replace owner on all and objects (Заменить вла дельца и объектов). Став владельцем папки, Боб но может стать владельцем всех ее и файлов. Такое право дает ему член ство в администраторов. Обычным это доступно, только в дополнение к Take Ownership (Смена владельца) родительского объекта им предоставлено такое же разрешение для всех дочерних объектов.
На вкладке Owner (Владелец), показанной на рис. 12-19, отсутствует флажок, по зволяющий передавать право владения другим Таким образом обес печивается защита от возможного В случае он мог бы стать владельцем, выполнить ошибочные или вредоносные действия, а потом скрыть следы, передав кому-нибудь другому. Однако такая функция реа лизована для программ. Если у имеется доступ к ту, он может записывать новую информацию в поле Owner (Владелец) дескрипто ра объекта.
Чтобы проследить за изменением объектами, включить аудит событий смены владельца. На рис. 12-20 как включен аудит всех попы ток доступа Ownership (Смена владельца) к папке верхнего всех ее подпапок и файлов. При каждой смене в журнале безопасности регистрируется соответствующее событие.
and Рис. 12-20. Вкладка Auditing (Аудит) объекта-папки Подробнее о аудита системе Microsoft Windows 2000 Server.
ГЛАВА 12 Управление доступом Как установить владельца объекта Для необходимо иметь на разрешений объекта. При наличии необходимого типа узнать имя объекта не труда. Для большинства объектов достаточно щелк нуть значок объекта правой кнопкой мыши, в контекстном меню Properties (Свойства), в открывшемся диалоговом окне свойств перейти к вкладке Security а затем щелкнуть Advanced (Дополнитель но). Далее в диалоговом окне Access Control Settings (Параметры ния доступом) щелкните вкладку Owner (Владелец). Имя Вы уви дите в поле Current owner of this item (Текущий владелец элемента).
Для объектов и папок можно одновременно список вла дельцев нескольких объектов. Откройте окно командной строки, в нужный каталог и выполните команду Эта команда в бцах выводит имена владельцев и объектов. Имя не дится для к которым у пользователя отсутствует на разрешений.
Назначение и изменение основной группы Для доменных учетных записей группой по умолчанию является Domain Users (Пользователи домена). Чтобы изменить основную группу пользователя, от редактируйте свойства соответствующего ему объекта в Directory. Подробнее об изменении группы Ч в справочной системе Microsoft Windows 2000 Server.
При создании нового объекта создающий процесс может указать SID для поля Primary Group (Основная группа) объекта. Если основная группа не указана созда ющим процессом, ее SID копируется из поля основной группы по умолчанию мар кера доступа субъекта.
Подобная процедура когда пользователь становится объек та. Обычно действующий от лица пользователя поток не основную груп пу. В этом случае SID из поля группы по умолчанию маркера доступа субъекта в поле основной группы дескриптора безопасности объекта.
Списки управления доступом Список управления доступом (access control list, ACL) представляет собой упорядо ченный список записей доступом (access control entry, АСЕ), ющих защиту самого объекта и его свойств. Каждая АСЕ содержит участника и указывает набор прав доступа к выполнению которые ему разрешены, запрещены или для которых включен аудит.
Дескриптор объекта может содержать два списка управления доступом:
Х таблицу управления доступом (discretionary access control определяющую порядок доступа к объекту и групп;
Х системную таблицу управления доступом (system access control list, SACL), уп равляющую аудитом доступа.
Структура данных для ACL на рис. 12-21, 558 ЧАСТЬ 2 Безопасность в распределенных системах Размер ACL Число АСЕ АСЕ [1] Рис. 12-21. ACL ACL состоит из элементов:
размер ACL Ч число байт памяти, ACL. Размер от коли чества и размера его записей доступом;
редакция ACL Ч номер редакции структуры Структура ACL не сит от редакции, но структура содержащихся в нем записей управления доступом может изменяться. Номер редакции для большинства объектов 2, а для объектов Active Directory Ч 4;
число АСЕ Ч число записей управления доступом в ACL. Нулевое значение озна чает, что пуст и не содержит никаких записей, и следовательно, проверка нрав доступа останавливается;
АСЕ АСЕ Ч упорядоченный список записей управления доступом.
Может отсутствовать. Во время прав доступа АСЕ считываются в поряд ке размещения в Записи управления доступом Все АСЕ содержат следующую информацию управления доступом:
Х SID, пользователя или группу;
Х маску доступа, в которой права доступа;
Х битовых флагов, определяющих способность дочерних объектов наследо вать АСЕ;
Х флаг, на тип АСЕ.
Типы АСЕ Windows 2000 поддерживает шесть типов АСЕ. Три общих типа могут присутство вать в ACL любых объектов. Общие типы АСЕ перечислены в табли це 12-7. Остальные три типа АСЕ являются и встречаются только в ACL Active Directory Объектно-зависимые типы АСЕ лены таблице 12-8.
Таблица 12-7. Общие типы АСЕ Тип в для запрещения в для доступа System-audit Используется для регистрации попыток доступа (аудит) ГЛАВА 12 Управление доступом Таблица 12-8. Объектно-зависимые типы АСЕ Тип Описание Access-denied, object-specific Используется Б DACL для доступа к свойству или набору свойств или для того, чтобы ограничить насле для типа owed, object-specific Используется в DACL для доступа к свойству или набору свойств или для того, чтобы ограничить насле дование для определенного типа дочерних объектов System-audit, в для доступа к свойству или свойств или для того, чтобы чить для определенного типа дочерних объектов По сути, общие и объектно-зависимые АСЕ одинаковы. заключается в деталях управления и доступом к объектам.
АСЕ возможности по различны ми видами дочерних объектов, которые их наследуют. По существу, они различие только между контейнерами и объектами, не контейнера ми. Например, в DACL объекта-папки файловой системы может находиться общая АСЕ, позволяющая пользователей просматривать содержание папки.
Так как эта выполняется только с объектами-контейнерами, в разрешаю щей ее АСЕ устанавливается флаг CONTAINER_INHERIT_ACE. Эта АСЕ наследуется только контейнерными объектами в папке (то есть только другими объектами-папками). Объекты, не являющиеся контейнерами (то есть, объекты файлы), ее не унаследуют, Объектно-зависимые АСЕ обеспечивают более тонкое управление наследующими их дочерними объектами. Например, в объекта подразделение находится объектно-зависимая АСЕ, помеченная для наследования только объектами другие типы объектов, например объекты компьютер, ее не унаследуют.
Вот почему эти записи управления доступом называются объектно-зависимыми. Их наследование возможно для дочерних объектов лишь определенных типов.
Похожие отличия наблюдаются и в управлении доступом к объектам. Общие АСЕ применяются ко всему объекту. Если общая АСЕ предоставляет определенному пользователю доступ на чтение, возможность читать всю связанную с объектом информацию Ч как данные, так и свойства. Для большинства типов объектов это несущественное У объектов-файлов, к примеру, немного свойств, и все они служат скорее для описания объекта, чем для хранения информа ции. Большая часть информации в объекте-файле хранится в виде данных объекта, нет особой в индивидуальном управлении свойствами файла.
АСЕ могут относиться к отдельным или подмно жествам свойств объекта. Эти типы АСЕ встречаются только в ACL объектов Directory, которые, в отличие от объектов других типов, большую часть информа ции хранят в Зачастую требуется каждым из свойств объекта Active Directory по отдельности. Объектно-зависимые АСЕ вполне пригодны выполнения такой задачи. Например, при определении разрешений для объекта пользователь можно в одной АСЕ разрешить Self (то есть пользователю) доступ на запись свойства (Домашний телефон, а в другой объектно-зависимой АСЕ - запретить этому же 560 ЧАСТЬ 2 Безопасность в распределенных системах пользователю доступ к свойству Logon-Hours (Время входа в систему, logonHours), а также к другим ограничения на пользовательскую учет ную запись.
Структура общей АСЕ У всех управления (access entry, АСЕ) одина ковая структура данных (рис.
Размер АСЕ Тип АСЕ Флаги и аудита Маска доступа SID Рис. 12-22. Структура АСЕ типа Далее составные части АСЕ, Размер АСЕ (АСЕ Size) Ч число байт занимаемых АСЕ.
Тип АСЕ Туре) Ч действие АСЕ: разрешение, запрещение доступа или установку аудита.
Флаги наследования и аудита and Audit Flags) Ч битовых фла гов, наследованием и аудитом. Подробнее о флагах наследования Ч в далее в этой главе. В таблице 12-9 описаны флаги аудита.
Таблица 12-9. Флаги аудита Значение Имеет только в АСЕ системного аудита и объектов системного аудита. В доступа ука заны операции, которые должны регистрироваться в случае отказа в доступе Имеет только в АСЕ системного аудита и объектов системного аудита. В маске ука которые в в случае предоставления доступа Маска доступа (Access Mask) Ч 32-разрядное каждый бит которого со ответствует праву доступа для объекта. Биты можно установить или сбросить, а их зависит от типа АСЕ. если в АСЕ запрещающего типа установ лен бит. соответствующий нраву на чтение разрешений объек та запрещено. Если тот же бит установлен в чтение разреше ний объекта разрешено.
пользователя или группу, доступ которых управляется или отслеживается этой АСЕ.
Структура АСЕ На рис. 12-23 изображена структура объектно-зависимой АСЕ.
ГЛАВА 12 Управление доступом Размер АСЕ АСЕ Флаги наследования и аудита Маска доступа Тип объекта Тип Флаги объекта Рис. 12-23. Структура объектно-зависимой АСЕ Размер АСЕ, Тип АСЕ, наследования и и SID идентичны соответствующим элементам структуры данных АСЕ общего Основные различия между и объектно-зависимой АСЕ определяют остальные поля, они рассмотрены далее.
Флаги объекта Флаги объекта (Object Flags) информируют о наличии (или полей Тин объекта (Object Type) или Тип (Inherited Object Type).
В таблице 12-10 перечислены три возможных флага.
Таблица 12-10. Флаги объекта Флаг О (флаги отсутствуют) Поля Тип или Тип отсутствуют. В этом АСЕ применяется ко таким образом, в роли АСЕ тина применяется к свойству, или праву или управляет создавать типы объектов АСЕ может только определенным типом дочерних объектов Тип объекта Тип объекта который может на один из пере численных далее элементов, Х Тип дочернего объекта. АСЕ определяет, кому предоставлено право создавать внутри контейнера дочерние объекты определенного типа. Идентификатор зопасности в АСЕ пользователя или группу, созда вать этот тип дочернего объекта. Маска доступа содержит объектно-зави симое право доступа Х Свойство или подмножество свойств. АСЕ способностью или записывать отдельные свойства или подмножества Идентификатор безопасности в АСЕ идентифицирует пользователя или группу, способных полнять указанные действия. Маска доступа АСЕ содержит право или Х Расширенное право. АСЕ правом с расширенным правом. Идентификатор в S1D указывает теля или группу, которым предоставляется или блокируется 562 ЧАСТЬ 2 Безопасность в распределенных системах право. Маска доступа АСЕ содержит объектно-зависимое право Тип объекта-потомка Поле содержит GUID, на тип дочернего объекта, способного АСЕ. также управляется при помо щи флагов наследования АСЕ и защиты против наследования, устанавливаемой на дочернем объекте в управляющих флагах дескриптора безопасности.
DACL вновь создаваемых объектов Операционная система устанавливает в дескрипторах безопасности вновь создаваемых защищенных объектов типов по определенным правилам.
1. Объект получает DACL из дескриптора безопасности, указанного создающим процессом. Операционная система также переносит в DACL наследуемые управления доступом (если только установлен управляющий флаг и устанавливает управляющий флаг дескрип тора безопасности SE_DACL_PRESENT.
2. Если создающий не указывает дескриптор безопасности, си стема создает DACL объекта из управления доступом в DACL родительского объекта, после чего 3. Если в родительском объекте наследуемые АСЕ, систе ма у диспетчера объекта DACL по присваивает ее объек ту и затем флаги и 4. Если диспетчер объекта предоставляет DACL по умолчанию, операционная система ее из маркера доступа субъекта, после чего устанавливает флаги и FAULTED.
5. Если в маркере доступа субъекта по умолчанию нет, избирательная табли ца управления доступом новому объекту не назначается, и он становится доступ ным всем без каких-либо ограничений. Управляющий флаг при этом не устанавливается.
DACL вновь создаваемых объектов Active Directory Способ создания DACL нового объекта в Active Directory немного от метода, применяемого для объектов других типов. Вот два основных различия:
Х при создании DACL различаются общие и объектно-зависимые наследуемые АСЕ в дескрипторе безопасности объекта. Общие наследуемые АСЕ могут наследоваться дочерними объектами любых типов.
симые наследуемые АСЕ могут наследоваться объектом указанного типа;
Х предоставлять дескриптор безопасности может схема Active Directory. Каждый определенный в схеме класс объектов имеет атрибут Если ни создающий процесс, ни объект не предоставляет DACL новому объекту Active Directory, операционная система использует DACL из указанного в дескриптора безопасности по умолчанию.
При установке DACL в дескрипторе безопасности новых объектов Active Directory операционная система следует определенным правилам.
ГЛАВА 12 Управление доступом 1. Объект получаст из указанного создающим процессом. Если установлен управляющий флаг дескриптора операционная система в все насле дуемые записи и затем устанавливает флаг дескриптора 2. Если дескриптор операционная система ищет в DACL родительского объекта АСЕ, соот типу нового объекта. Если у родительского объекта есть наследуе мые объектно-зависимые АСЕ для объектов данного типа, систе ма строит DACL из наследуемых АСЕ, в него как общие, так и объект АСЕ, и затем устанавливает флаг 3. Если у родительского объекта отсутствуют наследуемые объектно-зависимые АСЕ для объектов данного типа, операционная система использует DACL по умолчанию из схемы Active Directory для объектов данного типа. Затем она ус танавливает флаги и 4. Если в схеме Active Directory нет DACL по умолчанию для типа, система обнаружить и присвоить объекту DACL по умолчанию в маркере доступа субъекта. В случае успеха она устанавливает флаги и 5. Если в маркере доступа субъекта нет DACL по умолчанию, DACL объек ту не присваивается, и доступ к нему открыт всем. При этом флаг не устанавливается.
SACL вновь создаваемых объектов При установке SACL в дескрипторе новых объектов система следует определенным правилам.
1. Если создающий процесс сам образом предоставляет SACL, операцион ная система помещает ее в дескриптор безопасности объекта. Если не установ лен управляющий флаг дескриптора безопасности система перемещает все наследуемые записи досту пом в SACL и управляющий флаг дескриптора безопасности SE_SACL_PROTECTED.
2. Если создающий процесс сам предоставляет операционная создает SACL объекта из наследуемых записей управления доступом в SACL родительского объекта и устанавливает управляющий флаг дескриптора безо пасности 3. Если у родительского объекта отсутствуют наследуемые АСЕ, операционная тема у диспетчера объекта SACL по умолчанию. Затем она ливает управляющие флаги дескриптора и 4. Если диспетчер объекта не предоставляет SACL по умолчанию, SACL новому объекту не назначается.
ACL Наследованием (inheritance) называется процесс переноса (копирования) записей управления доступом из ACL родительского объекта в ACL дочернего объекта. В 564 ЧАСТЬ 2 Безопасность в распределенных системах Windows 2000 АСЕ переносить из родительского объек та в дочерний, когда:
Х новый дочерний объект;
Х изменяется родительского объекта;
Х изменяется SACL родительского объекта.
В этой схеме любой объект может быть дочерним по отношению к другому объек ту. Родительскими объектами бывают только контейнеры. В Windows как в родители могут рецессивные (скрытые) гены, которые внешне ни как не Например, в списке управления доступом объекта-контейне ра находятся АСЕ, не действующие на сам контейнер, а существующие только для целей Они могут передаваться вниз с на уровень (из поколения в пока не дойдут до оконечного (ллистьево дочернего объекта, где вступят в законную силу, есть станут действующими (а не номинальными) записями управления доступом.
Механизм наследования зависит от двух условий: набора флагов в каждой АСЕ и правил наследования, встроенных в операционную систему.
Флаги наследования Заголовок АСЕ содержит набор (Inheritance управляю щих тем, как данная АСЕ наследуется и как она влияет на наследующий ее дочер ний объект. Флаги наследования в таблице 12-11.
Таблица 12-11. Флаги наследования Флаг Значение Windows 2000: АСЕ унаследована из DACL или SACL родительского объекта.
Этот флаг не устанавливается на явно заданных АСЕ, то есть тех АСЕ. которые определяются непосредственно на объекте INHERIT_ONLY_ACE Указывает, что данная АСЕ предназначена только для Эта АСЕ игнорируется при проверке доступа, ее можно переносить на дочерние объекты Если этот флаг не АСЕ является действующей, го есть при проверке доступа.
Наследуются как АСЕ, так и АСЕ с флагом только для Наследование или АСЕ определяется состоянием флагов и CONTAINER_INHERIT_ACE Контейнерные объекты наследуют эту АСЕ как действую Когда такая запись наследуется объек том, система снимает флаг _ACE Объекты, являющиеся контейнерами, наследуют эту АСЕ как действующую. Когда АСЕ наследуется таким объектом, система снимает флаг INHERIT ONLY_ACE.
объекты также наследуют эту АСЕ, но только для того, чтобы передать далее по наследству. Когда АСЕ наследуется контейнерным объектом, система устанавливает ГЛАВА 12 доступом Таблица 12-11. (продолжение) Флаг Значение Если АСЕ таким флагом, INHERIT_ACE системы сбрасывает флаги OBJECT_INHERIT_ АСЕ Это дальнейшее АСЕ объектов Правила наследования система интерпретирует флаги и другую относящую ся к наследованию информацию в соответствии с АСЕ, приведенными в таблице 12-12. одинаково как к так и к Операционная система передает АСЕ в объек ты, соблюдая предпочтительный, или (canonical), порядок. После пе реноса управления доступом система на всех унаследован ных АСЕ флаги и Таблица 12-12. Правила наследования Флаги Воздействие на дочерние Флаги отсутствуют Нет воздействия па ACL Только Дочерние объекты, не контейнера ми: АСЕ наследуются как действующие.
Дочерние объекты-контейнеры: АСЕ наследуют ся с установленным флагом только для насле если только не флаг Только Дочерние не являющиеся контейнера ми: родительские АСЕ не оказывают па дочерний объект.
Дочерние объекты-контейнеры: дочерний объект наследует действующую АСЕ.
АСЕ если только не уста флаг и Дочерние объекты, не ми: АСЕ как действующие.
Дочерние объекты-контейнеры: дочернин наследует АСЕ.
АСЕ является наследуемой, если только не уста новлен флаг Если АСЕ является действующей для дочернего система ус танавливает и переносит все общие права на права для дочернего та. Подобным образом система переносит общие (например, и конкретные SID. Если АСЕ предназначена только для никакие общие права или общие SID чтобы их можно было в даль нейшем корректно перенести, когда АСЕ будет унаследована следующим поколени ем объектов.
Когда контейнерный объект наследует АСЕ, которая одновременно является дей ствующей для контейнера и наследуется его потомками, может наследо вать две АСЕ. Это происходит в случаях, когда наследуемая АСЕ содержит общую 566 ЧАСТЬ 2 Безопасность в распределенных системах информацию. Контейнер наследует с флагом для содер жащую общую информацию, и АСЕ, в которой эта общая информа ция уже перенесена.
У АСЕ есть Тип объекта-наследника, содержится на тип объекта, который может ее наследо вать. Если такого идентификатора в этом иоле нет, наследование выполняется, как для стандартной АСЕ. Если GUID в поле присутствует, запись досту пом объектами с соответствующим GUID, если установлен флаг и контейнерами с соответствующим GUID, если установ лен флаг Порядок записей доступом в DACL Наиболее предпочтительный порядок управления доступом в (canonical). В Windows 2000 существует следующие правила канонического порядка:
Х явно устанавливаемые АСЕ в группу любыми унаследован ными записями управления доступом;
Х в группе явно устанавливаемых АСЕ АСЕ располагаются перед разрешающими АСЕ;
Х унаследованные АСЕ размещаются в том порядке, в каком они наследовались. Ч сначала АСЕ, унаследованные от родителя дочернего объекта, затем от де и так далее вверх по дереву объектов, Рис. 12-24 иллюстрирует порядок.
Размер ACL Редакция ACL Число АСЕ АСЕ: Доступ запрещен устанавливаемые АСЕ: Доступ разрешен АСЕ: Доступ запрещен АСЕ: Доступ разрешен Рис. 12-24. Канонический порядок Канонический порядок гарантирует, что явно установленные АСЕ запрещения об рабатываются каких-либо явно установленных АСЕ разрешений. Таким об разом, владелец объекта может установить доступ группе пользователей, например Everyone (Все), но закрывающие его подмножеству группы, например Marketing. Если АСЕ объекта расположены в каноническом порядке, запись управления доступом, доступ группе Marketing, пред шествует разрешающей доступ группе Everyone (Все). При проверке доступа система обрабатывает ЛСЕ в том порядке, в котором они располага ются в DACL объекта, следовательно, запрещающая АСЕ будет обработана В результате доступа члены группы Marketing, а всем про чим он будет разрешен.
Кроме того, канонический порядок обеспечивает обработку сначала явно установ ленных, а потом АСЕ. Это согласуется с концепцией избиратель ГЛАВА 12 Управление доступом (discretionary) управления доступом: доступом к дочерним объектам ет дочернего объекта, а Владелец дочернего объек та может определять непосредственно на объекте. Предположим, у объекта имеется наследуемая АСЕ. доступ группе Marketing. Допустим также, что владелец дочернего объекта добавляет в пего яв ную АСЕ, разрешающую доступ группы Marketing, Если АСЕ объекта расположены в каноническом порядке, явно установ доступ, предшествует любой из унаследован ных АСЕ, в том числе и АСЕ, доступ группе Marketing. В Боб получит доступ к объекту несмотря на то, что он является членом Marketing. Другим членам группы доступ будет закрыт.
DACL и DACL Дескриптор безопасности без DACL предоставляет доступ Дескриптор с пустой DACL не предоставляет доступа никому.
В Windows NT разработчику, желающему предоставить всем свободный дос туп к объекту, достаточно написать код создания объекта без DACL. В Win dows 2000 можно поступить также, но с небольшой поправкой: нужно допол нительно установить управляющий флаг дескриптора Если этого не сделать, объект приобретет DACL (а с и одну более записей управления доступом) но механиз му наследования, а эта таблица управления доступом совсем не предоставит доступ всем. Если у родительского объекта вооб ще не окажется дочерний объект DACL, то есть доступ к объекту будет закрыт всем. А это противоречит на создателя объекта.
Чтобы предоставить доступ к создаваемому Вашей объекту в Windows 2000 всем желающим, Вы должны назначить ему DACL с одной АСЕ, предоставляющей полный доступ группе Everyone Процедуры при обновлении системы После обновления системы с Windows 4.0 на Windows нение на канонический в DACL существующих объектов выполняется при первом же их дескрипторов Поскольку Windows 2000 ав томатически переносит АСЕ на существующие дочерние объекты, DACL всех объек тов, расположенных в иерархии ниже измененного объекта, также приводятся в со ответствие с каноническим порядком. В преобразованных дескрипторах безопаснос ти объектов устанавливаются флаги и АСЕ дочерние объекты происходит по следующим пра вилам:
Х при АСЕ дочерним объектом без DACL образуется дочерний объект с DACL, содержащей только унаследованную запись управления доступом;
Х наследовании АСЕ дочерним объектом с пустой DACL образуется дочер ний объект с DACL, содержащей только унаследованную запись управления 568 ЧАСТЬ Х при удалении наследуемой АСЕ из родительского объекта автомати все копии этой АСЕ, унаследованные объектами;
Х если автоматического наследования удаляет все АСЕ из DACL дочер него объекта, DACL дочернего объекта не уничтожается, а становиться пустым.
при преобразовании тома FAT в том NTFS Когда том FAT преобразуется в том NTFS, Windows 2000 устанавливает разреше ния па всех папках и файлах преобразованного тома. Разрешения, устанавливае мые на папках, показаны в 12-13, а на фай лах Ч в таблице 12-14. Все разрешения задаются в явно заданных АСЕ.
Таблица DACL существующих папок после преобразования в NTFS Тип Имя Разрешение Применяется Allow (Разрешить) System Full Control This folder only (Только для доступ) этой папки) (Разрешить) Full Control This folder only (Только для этой папки) Allow (Разрешить) АИ (Все) Full Control This folder, and (Полный доступ) files (Для этой ее и файлов) Таблица 12-14. DACL существующих файлов после преобразования FAT в NTFS Имя Разрешение Allow (Разрешить) System (Полный доступ) Allow (Разрешить) Administrators Control (Полный доступ) Allow (Разрешить) (Все) Ful l Control (Полный доступ) Только последняя управления доступом в DACL папки Ч наследуемая, по этому именно она новыми объектами в преобразованном томе. Б таб лице 12-15 показана DACL файлов и папок, созданных после Таблица 12-15. DACL новых файлов и папок после преобразования FAT в NTFS Тип Имя Разрешение (Все) Full Control (Полный доступ) Такая DACL не создает на под управлением Windows NT.
Однако на компьютерах под управлением Windows 2000 все не так просто. Пред некто, редактируя разрешения корня тома, удаля ет группе (Все) полный дос туп к панке, ее папкам и файлам. Так как в Windows 2000 изменения в наследу емых АСЕ переносятся вниз по дерену объектов, в наследуемых АСЕ корневого объекта дерева на дерево. Объекты, существовав шие до обладали установленными АСЕ, группе Everyone (Все) доступ. Эти АСЕ не были на них не влияли изменения корневого объекта. После преобразова ГЛАВА 12 доступом тома полный доступ группе к файлам и доставляется наследуемыми АСЕ. Если эти АСЕ будут удалены из всех файлов и папок, созданных после тома, у каждого из этих объектов ся пустая не доступа никому.
Дабы эту ошибку, добавьте новую наследуемую АСЕ в корневой объект и изменение вниз дереву объектов. Однако ошибки всегда луч ше предотвращать, чем исправлять. Вы избежите проблем, поменяв АСЕ корневого объекта на Это рекомендуется сделать сразу после FAT в Как избежать создания пустой DACL на преобразованном томе 1. Откройте Explorer и найдите значок диска преобразован ного тома.
2. Щелкните значок диска правой мыши и в контекстном меню выберите Properties (Свойства). В открывшемся диалоговом Properties (Свойства) к Security и щелкните Advanced (Дополни тельно).
3. В открывшемся диалоговом окне Access Control Settings (Параметры управле ния доступом) на вкладке Permissions (Разрешения) дважды запись Administrators (Администраторы);
4. В поле со Apply to (Применить) выберите This folder, subfolders files (Для этой папки, се и файлов).
5. Щелкните ОК.
6. На вкладке Permissions дважды щелкните System (SYSTEM), 7. В поле со списком Apply to выберите This folder, subfolders and files (Для этой папки, ее подпапок и файлов).
Внимание! Не следует устанавливать флажок Reset permissions on all child objects and enable propagation of inheritable permissions (Сбросить разрешения для всех дочерних объектов и включить перепое наследуемых разрешений). Пе ренос наследуемых разрешений уже включен по умолчанию. Установка этого флажка сбрасывает флаг безопасности в дескрипторах всех объектов и отзывает разрешения, явно на объектах. Ни одно из этих дей ствий не требуется для этой 8. Щелкните насколько раз ОК. чтобы закрыть все окна.
После внесения указанных новые наследуемые АСЕ распространятся на дочерние объекты, ниже корневой папки, и будут вновь создаваемыми в этом дереве и файлами.
Проверка доступа и аудит Когда субъект пытается получить доступ к объекту, диспетчер объекта Alarm, позволяющую узнать, разрешен или запрещен до ступ, а также ли аудит. Функция выполняет эту задачу в два этапа. Сна чала она определяет, или разрешен доступ для этого субъекта, а затем имеется ли необходимость создания записи аудита в журнале безопасности.
570 ЧАСТЬ 2 Безопасность в распределенных системах Проверка доступа Цель проверки доступа Ч определить, позволено ли совершить запраши ваемые им действия. Для этого используется функция В качестве входных данных она Х доступа субъекта;
Х маску запрашиваемого доступа субъекта;
Х дескриптор безопасности объекта.
Маска запрашиваемого (desired access mask) субъекта Ч это дли ной 32 бита, в которой каждый бит соответствует отдельному праву Уста новленные биты указывают на субъектом права, а сброшенные права, которые субъекту не требуются. Подробнее о маске доступа Ч в разделе Маска доступа ранее в этой главе.
Завершив проверку доступа, AccessCheckAndAuditAlarm диспетчеру объекта маску доступа access mask). Маска ленного доступа - это 32-разрядная структура, идентичная маске запрашиваемого доступа, за исключением того, что все биты в ней сброшены. В процес се проверки доступа при авторизации для каждого в маске доступа, бит, этому праву, устанавливается в маске доступа и сбрасывается в маске запрошенного доступа, сброса всех битов в маске доступа проверка доступа заверша ется. Маска предоставленного доступа возвращается вызывающему процессу.
При авторизации субъекта следует пра вилам. Они перечислены далее.
1. Если в дескрипторе безопасности объекта отсутствует DACL, маска ленного доступа устанавливается равной доступа, и провер ка доступа Субъект получает маску доступа, которую запрашивал.
2. Если маска запрошенного доступа проверка доступа завершается. Субъект получает доступ к объекту.
Pages: | 1 | ... | 8 | 9 | 10 | 11 | 12 | ... | 15 | Книги, научные публикации