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



жүктеу 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 принимает запрос клиента на TGT, ответ AS будет включать две части: TGT, зашифрованный ключом, который знает и может расшифровать только KDC (TGS) и сеансовый ключ, зашифрованный хешем пользовательского пароля для дальнейшего взаимодействия с KDC. Так как клиент не может прочитать содержимое TGT, он должен «вслепую» предоставлять билет сервису TGS для получения билетов на сервис (service tickets). TGT включает в себя: вторую копию ключа сессии, имя пользователя, время окончания жизни билета.

Чтобы обратиться к ресурсам, пользователь представляет свой TGT службе TGS KDC. TGS проверяет предоставленный TGT (только KDC может его расшифровать) и создаёт пару билетов для клиента и удалённого сервера (держателя ресурса). Эта информация, известная как сервисный билет, локально кешируется на клиентской машине.

TGS получает клиентский TGT, читает его, использовав для расшифрования собственный ключ. Если TGS принимает клиентский запрос, генерируется пара ключей для клиента и сервера назначения. Клиент читает свою часть, используя сеансовый ключ TGS, полученный ранее в ответе от AS. Серверную часть ответа TGS клиент предоставляет серверу назначения на следующем этапе обмена клиент-сервер.

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

Клиент «вслепую» передаёт серверную часть сервисного билета серверу для установления клиент-серверного сеанса. Если требуется взаимная аутентификация, сервер назначения возвращает временную отметку, зашифрованную с использование сеансового ключа сервисного билета. Если временная отметка расшифруется успешно, это означает, что не только клиент аутентифицировал себя серверу, но и сервер проаутентифицировал себя клиенту. Сервер назначения никогда не общается напрямую с KDC. Это уменьшает последствия от возможной недоступности KDC во время работы.

Внутри KDC функции AS и TGS разделены. Это позволяет пользователям использовать TGT, полученный от AS в своём домене, для получения сервисных билетов от TGS из других доменов. Эта реализуется через т.н. ссылочные билеты (referral tickets).



После того, как между доменами были установлены доверительные отношения, ссылочные билеты могут предоставляться клиентам, запрашивающим доступ к сервисам в других доменах. При установлении доверительных отношений между двумя соседними доменами, генерируется междоменный ключ, который будет использован для выполения функций аутентификации KDC. На рисунке ниже приведён пример того, как клиент обращается к сервису в другом домене. Пользователь (клиент) из домена Entcert1.com запрашивает доступ к сервису из домена Entcert2.com. При этом будет использован ссылочный билет:


  1. Клиент обращается к KDC TGS своего домена, используя ранее полученный TGT. KDC распознаёт запрос на сеанс в «чужой» домен и отвечает ссылочным билетом для KDC из «чужого» домена.

  2. Клиент обращается к KDC из «чужого» домена с предоставленным ему ссылочным билетом. Этот билет зашифрован междоменным ключом. Если расшифрование прошло успешно, служба TGS из «чужого» домена возвращает сервисный билет для сервера, расположенного в Entcert2.com.

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



Рис.52 Междоменные ссылки
Когда в процесс вовлечено большее количество доменов, «ссылочный» процесс усложняется и начинает работать транзитивность доверительных отношений между доменами. В случае ручного установления доверительных отношений «каждого-с-каждым» это превратилось бы в задачу большой сложности. Использование свойства транзитивности резко упрощает проблему. На рисунке ниже приведён пример: домен Entcert1.com имеет установленные доверительные отношения с Entcert2.com. Entcert2.com, в свою очередь имеет доверительные отношения с Entcert3.com. Нет прямых доверительных отношений между Entcert1.com и Entcert3.com. Клиент из Entcert1.com доступается к сервису из домена Entcert3.com, получит требуемый сервисный билет за несколько шагов, описанных ниже:


  1. Используя TGS службу в домене Entcert1.com, получает ссылочный билет для KDC из домена Entcert2.com.

  2. Используя полученный ссылочный билет, предъявляемый TGS службе в домене Entcert2.com, получает ссылочный билет для Entcert3.com.

  3. Используя второй полученный ссылочный билет, предъявляемый TGS службе в домене Entcert3.com, получает сервисный билет для сервера в домене Entcert3.com.

  4. Используя полученный сервисный билет, производит необходимый обсен с сервером назначения, устанавливает пользовательский сеанс с требуемым сервисом в Entcert3.com.



Рис.53 Иллюстрация работы тразитивных междоменных доверительных отношений
В случае очень «глубокой» иерархической структуры может оказаться, что время, затрачиваемое клиентом на получение итогового сервисного билета, окажется неприемлемо большим. На этот случай можно создать т.н. «укороченные» доверительные отношения (shortcut trust), укорачивающие и ускоряющие получения необходимых ссылок:


Рис.54 Уменьшение количества ссылок созданием «укороченных» доверительных отношений
На рисунке слева тёмными стрелками показан стандартный путь от пользователя до домена с ресурсами, справа – этот же путь при установлении дополнительных «укороченных» доверительных отношений (светлая стрелка между User Domain и Resource Domain).




Достарыңызбен бөлісу:
1   ...   17   18   19   20   21   22   23   24   ...   44


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

    Басты бет