Курс лекций «Проблемы безопасности в информационных технологиях»



жүктеу 4.51 Mb.
бет21/44
Дата13.09.2017
өлшемі4.51 Mb.
түріКурс лекций
1   ...   17   18   19   20   21   22   23   24   ...   44

Работа с Active Directory


Исходная (плоская) доменная структура, предложенная Microsoft, как вариант реализации SSO, имеет некоторые существенные недостатки. В частности, если в организации используется несколько доменов, и у пользователей возникает потребность в доступе к ресурсам других доменов, то администраторы вынуждены будут организовывать т.н. доверительные отношения (trust relationship). Пользователь по-прежнему будет при входе в сеть вводить пароль однократно, но, при обращении к ресурсам «чужого» домена, за счёт установленных между доменами доверительных отношений, прозрачно получит к ним доступ, не авторизуясь повторно.

Казалось бы, вполне разумное и адекватное решение, но оно имеет очевидные недостатки с точки зрения администрирования: при N-доменах администраторы будут вынуждены установить максимум · 2 доверительных отношений (умножение на 2 делается потому, что доверительные отношения по своей природе однонаправленные и для получения двунаправленной коммуникации необходимо создать отдельно входящее и исходящее отношение). Установление отношений по принципу «каждый-с-каждым» делается потому, что доверительные отношения в доменах Windows NT не обладают свойством транзитивности, т.е., если домен A доверяет домену B, а домен B доверяет домену C, то это не означает, что домен A доверяет домену C.

Очевидно, что с увеличением количества доменов установление между ними доверительных отношений превращается в серьёзную проблему для администраторов. Это было одной из побудительных причин, которой Microsoft руководствовалась при разработке своей Active Directory (AD). AD включает в себя множество технологий, как новых, так и адаптированных и модифицированных существующих. Например, одним из столпов AD является служба DNS (использующаяся для поиска ресурсов), доработанная Microsoft под свои нужды4. Также AD выступает в роли сервера каталога стандарта LDAP v3. LDAP (Lightweight Directory Access Protocol) – протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции авторизации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.

Ещё одним из краеугольных камней AD является протокол аутентификации Kerberos. Microsoft не разрабатывала его с нуля, для этого была адаптирована разработка MIT (Kerberos v5).

Вместо «плоской» структуры независимых доменов в Active Directory Microsoft «собрала» домены в иерархическую древовидную структуру. При этом между соседними доменами автоматически устанавливаются двунаправленные доверительные отношения, обладающие свойством транзитивности. Т.е., теперь нет необходимости устнавливать отношения по принципу «каждый-с-каждым». Домены, выстроенные в «дерево», произрастают из единого корня, от которого можно «вырастить» не одно «дерево», а несколько, т.н. «лес». «Лес» в AD является границей безопасности, а входящие в состав «леса» домены являются административной границей для администратора домена.



Рис.49 По умолчанию устанавливаются транзитивные доверительные отношения
Microsoft ввела в AD поддержку протокола LDAP. Всякая запись в каталоге LDAP состоит из одного или нескольких атрибутов и обладает уникальным именем (DN — Distinguished Name). Уникальное имя может выглядеть, например, следующим образом: «cn=Иван Петров, ou=Сотрудники, dc=example, dc=com». Но, в отличие от, например, новеловской eDir, в AD не выдержан полностью объектный подход. Невозможно дать права подразделению «ou=Сотрудники, dc=example, dc=com» – в AD OU (Organizational Unit) не является принципалом безопасности. Очень упрощённо, принципалами безопасности в AD могут быть только несколько объектов определённого класса, и только их SID-ы могут присутствовать в списках доступа (ACL) объектов. Принципалом безопасности является объект, который может быть аутентифицирован системой: пользователь, компьютер, поток или процесс, работающий в контексте безопасности пользовательской или компьютерной учётной записи, группа безопасности5, содержащая перечисленные типы учётных записей.

Группы безопасности


То, что OU не является принципалом безопасности, означает, что, к примеру, принципиально невозможно дать права печати на принтер всему подразделению, просто внеся SID подразделения в список доступа (ACL) принтера, как это легко и просто делается в Novell eDir. В AD вы должны включить в группу безопасности требуемые учётные записи, а уже этой группе назначить права для печати на принтер.

Кроме двух разных типов – security и distribution – группы разделяются по области действия. Область действия группы определяет диапазон, в котором применяется группа внутри домена. Помимо того, что группы могут содержать пользователей и компьютеры, они могут быть членами других групп, на них могут ссылаться списки ACL, фильтры объектов и групповых политик и пр. Граница диапазона области действия группы может определяться заданием режима работы домена. К основным характеристикам области действия групп можно отнести членство (определение принципалов безопасности, которые может содержать группа), репликация (определение области репликации группы), а также доступность (определение местонахождения группы, возможности включения этой группы в членство другой, добавление группы в список ACL). Существует четыре области действия групп: локальная, локальная в домене, глобальная и универсальная:




  • Локальная доменная группа (локальная группа в домене). Группы с областью действия локальные группы в домене предназначены для управления разрешениями доступа к ресурсам (permission) и функционируют в том случае, если домен работает на функциональном уровне не ниже Windows 2000. В том случае, если домен работает на уровне Windows NT или в смешанном уровне, то эти группы могут использоваться лишь как локальные группы. Такая группа определяется в контексте именования домена (её «не видно» в другом домене). Локальную группу в домене можно добавлять в списки ACL любого ресурса на любом рядовом компьютере домена и на сервере. В локальную группу в домене могут входить пользователи, компьютеры, глобальные и локальные группы из текущего домена, из любого другого домена леса, а также универсальные группы из любого домена леса. Другими словами, репликация и доступность такой группы позволяет ее использовать в пределах всего домена. В связи с этим, локальные группы в домене обычно используют для предоставления правил доступа во всём домене, а также для членов доверительных доменов. Чаще всего, с локальными группами в домене связаны сценарии, подобные следующему: вам нужно предоставить доступ к папке с документацией восьми пользователям из разных отделов. Вы должны учесть, что кто-либо из этих пользователей может перейти в другой отдел или уволиться и позже вам придется изменять разрешения доступа. Чтобы упростить такую рутинную работу, вы можете создать группу с локальной областью безопасности в домене и дать доступ к папке именно этой группе. После этого вы можете добавлять любых пользователей к этой группы, и все пользователи, входящие в состав этой группы, автоматически получат доступ к папке;

  • Глобальная группа. Чаще всего членами таких групп выступают пользователи и компьютеры. Глобальная группа может содержать пользователей, компьютеры и другие глобальные группы только из «своего» домена. Несмотря на это, глобальные группы могут быть членами любых универсальных и локальных групп как в своем домене, так и в другом доверяющем домене. Помимо этого, глобальные группы можно добавлять в списки ACL в домене, лесу и в доверяющем домене;

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

  • Локальная группа. Локальная группа доступна только на одном компьютере. Такая группа создается в базе данных диспетчера безопасности учетных записей обычного компьютера (сервера) и поэтому в домене управление локальными группами не нужно. В списках ACL можно использовать такие группы только на локальном компьютере. В другие системы такие группы не реплицируются, но эта группа содержит пользователей, компьютеры, глобальные и локальные группы в домене из своего домена, пользователей, компьютеры и глобальные и универсальные группы из любого домена леса.

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




Рис.50 Создание объекта Группа
Чтобы упростить понимание и запоминание, какие группы какие области действия имеют, какие объекты могут содержать, предлагается запомнить аббревиатуру AGUDLP, что расшифровывается как «AccountGlobalUniversalDomain LocalPermissions» (Учетная запись — Глобальная — Универсальная — Локальная в домене — Доступ), то есть запомнив эту аббревиатуру, вы не ошибетесь при назначении доступа к ресурсам.

Необходимо помнить один факт, который, будучи осознан, очень многих обескураживает и смущает: при работе в домене (AD) группы «Администраторы домена» и «Администраторы предприятия» по умолчанию являются (становятся) членами локальной группы «Администраторы». Т.е., администратор домена является локальным администратором на любом компьютере, вошедшем в домен. Локальный администратор может удалить группы «Администраторы домена» и «Администраторы предприятия» из локальной группы «Администраторы», но у администраторов домена (предприятия) есть техническая возможность вернуть членство в локальной группе «Администраторы», невзирая на желание/нежелание локального администратора системы. Это нужно понимать и принимать, как должное – если вы согласны с правилами работы в корпоративной сети, то эти правила, в частности, подразумевают, что в «вашей» локальной системе (даже на рядовой рабочей станции) появятся «чужие» администраторы.


Алгоритм аутентификации Kerberos


В AD, изменив структуру доменов из «плоской» в иерархическую («лес» со множеством деревьев), Microsoft модифицировала ещё одну из базовых технологий – технологию аутентификации пользователей. Вместо не очень хорошо себя зарекомендовавшего NTLM, был использован протокол Kerberos. Kerberos – это программная технология, разработанная в середине 1980-х гг. в Массачусетском технологическом институте (MIT) и претерпевшая с тех пор несколько серьёзных изменений. Базой для Kerberos в AD стал протокол версии v5.

Kerberos предназначен для решения следующей задачи. Имеется открытая (незащищённая) сеть, в узлах которой сосредоточены субъекты – пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен знать) секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа.

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

Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило – клиент) посылает Kerberos запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает так называемый билет (ticket, иногда переводится как мандат, токен), зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его содержимое с дополнительной информацией, присланной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные (ведь содержимое билета никому, кроме сервера и Kerberos, недоступно), т.е. продемонстрировал знание секретного ключа. Значит, клиент – именно тот, за кого себя выдает. Секретные ключи в процессе проверки подлинности не передавались по сети (даже в зашифрованном виде) – они только использовались для шифрования. Как организован первоначальный обмен ключами между Kerberos и субъектами и как субъекты хранят свои секретные ключи – отдельный вопрос.

Три составных части Kerberos включают в себя «Центр распределения ключей» (Key Distribution Center (KDC)), пользователя-клиента и сервер, к ресурсам которого хочет получить доступ клиент. KDC безусловно устанавливается как часть обеспечения контроллера домена (DC) и обеспечивает работу двух служб: «Службы аутентификации» (Authentication Service (AS)) и «Службы выдачи билетов» (Ticket-Granting Service (TGS)). На рисунке ниже представлен три типа обменов данными, которые происходят, когда клиент инициирует доступ к ресурсам сервера:


  1. AS Exchange

  2. TGS Exchange

  3. Client/Server (CS) Exchange




Рис.51 Обмен билетами в Kerberos
Во время начального входа в сеть пользователь обязан предоставить своё имя и пароль, чтобы их мог проверить AS (часть KDC). KDC имеет доступ к учётной информации пользователей в Active Directory. После успешной аутентификации пользователю предоставляется «Билет на получение билетов» (Ticket to Get Tickets (TGT)), который действителен для локального домена. TGT имеет по умолчанию время жизни 10 часов (или 7 суток) и может быть переполучен (обновлён) во время сессии, без необходимости повторного ввода пароля. TGT кешируется на локальной машине в «разрушаемой» памяти и используется для запроса доступа к сервисам в сети.

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

Если KDC п

Достарыңызбен бөлісу:

1   ...   17   18   19   20   21   22   23   24   ...   44


©kzref.org 2019
әкімшілігінің қараңыз

    Басты бет