- PVSM.RU - https://www.pvsm.ru -
В предыдущей статье данного цикла я немного вас ввел в курс дела и рассказал, что собой представляет динамический контроль доступа, чем он отличается от предоставления доступа на основе списков ACL, о его преимуществах, а также – буквально в двух словах – o наиболее частых сценариях, когда целесообразно применять данную функциональную возможность. Статья была немного громоздкой, наполненной исключительно теоретическим материалом, да и, вообще сложной для восприятия, так как в ней отсутствовали описания каких-либо пошаговых процедур.
Начиная с этой статьи, я постараюсь исправиться и рассказать вам о том, с чего же необходимо начинать знакомство с этой технологией. А начинать, как видно из самого заголовка статьи, следует ни с чего иного, как с утверждений (они же, как я уже писал в предыдущей статье, еще называются заявками, клаймами и прочими словами, которыми можно заменить claim), которые смело можно отнести к одной из основных составляющих динамического контроля доступа. Сейчас же я постараюсь дать как можно меньше теоретического материала и практически сразу перейти к пошаговой процедуре. Итак, что же вы для себя сможете почерпнуть из этой относительно небольшой статьи?
А в этой статье я вам поведаю:
Ну что же, чтобы сильно не затягивать вводную часть данной статьи, перейдем к первому разделу, который называется:
Боюсь ошибиться, но, вероятнее всего, в наше время уже не осталось такого пользователя, который хотя бы один раз не предоставлял доступ к какой-то своей общедоступной папке. Специально для этой цели, еще в далекие времена Windows NT, корпорация Microsoft ввела в операционные системы такое понятие как идентификация, которое плотно закрепилось на многие годы. Тут все очевидно: что, как я уже упоминал в одной из своих статей, доступ к файлам и ресурсам основывался непосредственно на идентификаторах безопасности. Получается, доступ к общедоступным файловым ресурсам предоставлялся, основываясь на том, удачно ли была пройдена проверка подлинности пользователя согласно его учетным данным. Конечно же, в большинстве случаев такие учетные данные представляли собой имя учетной записи и его пароль или же принадлежность пользователя к конкретной группе. Саму концепцию идентификации вы все прекрасно знаете и, полагаю, нет никакого смысла останавливаться на ней в очередной раз.
Но практика показывает, что в некоторых случаях (а таких случаев можно привести достаточно много) из-за членства в различных группах пользователям может случайно быть предоставлен доступ к таким ресурсам, доступ к которым им попросту не положен. Чтобы избавиться от таких случаев, в последней операционной системе от Microsoft было представлено новое понятие, которое называется, как вы догадались, утверждением. Рассмотрим, что же это такое.
Как сейчас поступает бОльшая часть населения, которая слышит новое или непонятное слово? Они заглядывают в Википедию. Что же там написано на этот счет? «Утверждение в лингвистике — особая форма предложения, которая в утвердительной форме выдвигает гипотезу относительно некоторого явления». Определенно это не то.
Что еще можно найти? «Логическое утверждение — это высказывание, образованное из других высказываний с помощью логических связок». Тоже не подходит. «Утверждение в программировании — это предикат, размещённый в программе и указывающий на то, что разработчик имеет в виду этот предикат в этом месте программы всегда истинным». Но все равно, похоже, что все это не то, что подразумевается в текущем контексте.
На самом деле, согласно официальной терминологии, утверждения представляют собой доверенный источник информации об учетной записи, пытающейся выполнить авторизацию, предоставляемую в атрибутах этой учетной записи, которая хранится в доменных службах Active Directory. К различным утверждениям можно отнести множество свойств, таких как идентификатор безопасности самого пользователя или его компьютера, подразделение, в котором может работать пользователь, его номер комнаты, город, в котором он живет. Причем стоит обратить внимание на то, что в одной записи может храниться несколько утверждений, что позволяет делать политики динамического контроля доступа достаточно гибкими, чтобы удовлетворить практически любые возможные потребности.
На этом этапе у вас может возникнуть вполне логичный вопрос: а что нам вообще дадут эти утверждения и какой в них смысл? При помощи утверждений можно ограничивать доступ как к файлам, так и к папкам. А что в утверждениях самое ценное, так это то, что все созданные утверждения будут публиковаться непосредственно в Active Directory. Причем, как я уже упоминал в предыдущей статье по этой технологии, для полноценного функционирования динамического контроля доступа в целом и утверждений в частности, нет каких-либо ограничений относительно функционального уровня домена или леса вашей организации.
Так как о связи Kerberos с утверждениями я подробно рассказывал в одной из статей по протоколу сетевой аутентификации Kerberos, ссылку на которую я давал в предыдущей статье данного цикла, сразу будем переходить к такой теме, как:
Согласно официальному определению, типом утверждения в Windows Server 2012 называется проверочное утверждение об объекте, с которым оно связано. Как вы уже, вероятнее всего, догадались, тип утверждения основывается на атрибуте Active Directory и служит для определения разрешений при разработке централизованных правил доступа. В операционной системе Windows Server 2012 вы можете использовать любой из следующих трех типов утверждений:
Потихоньку будем переходить к более интересной части. Если говорить точнее, то сейчас мы с вами рассмотрим условные выражения, которые относятся к подсистеме безопасности ОС, появившиеся в операционной системе Windows Server 2012 специально для того, чтобы можно было реализовать поддержку авторизации на основании утверждений.
Что собой представляют эти условные выражения, которые относятся к утверждениям? По сути, эти условные выражения представляют собою булевы или логические выражения, которые, как правило, включают в себя два операнда, разделенных специальным оператором. В качестве результата условных выражений всегда могут выступать лишь два значения, а если точнее, то это могут быть значения TRUE и FALSE. Здесь также стоит обратить внимание на то, что выражения ACE оцениваются как в случае с авторизацией, так и во время аудита доступа, поэтому как в первом, так и во втором случае можно использовать одни и те же выражения.
А что вообще происходит с этими выражениями? Я уже раньше писал о том, что подсистема LSA считывает требуемую информацию из PAC и создает токены доступа. После этого, на основании предоставленной пользователем информации, выполняется проверка доступа и, на основании разрешений, назначенных в маркере безопасности определяется, будет ли разрешен либо запрещен доступ к ресурсу конечному пользователю. Это все и так понятно. Однако, с появлением утверждений в информации о проверке подлинности Kerberos, помимо SIDа принципала безопасности, также появилась возможность включать и дополнительную информацию, которую можно найти в этих условных выражениях.
Сами утверждения представляют собой совокупность из таких сущностей, как тип утверждения и имя утверждения, причем обязательно они должны разделяться точкой (это вы увидите ниже). Первая часть, что очевидно, используется непосредственно для определения типа утверждения, который, как мы с вами выяснили в предыдущем разделе, может выступать в качестве User или Device. Перед упоминанием типа утверждения следует указывать символ @, за которым уже будет следовать сам тип. Часть с именем утверждения — это просто-напросто имя, которое вы можете задать такому утверждению при его создании.
Левая и правая части выражения утверждения должны сравниваться специальным оператором, причем в качестве правого операнда может быть буквенное значение, которое может представлять собой фрагмент значения левого операнда.
Всего можно выделить 13 операторов, которые, вероятнее всего, вам уже должны быть известны по работе с другими программными продуктами. Не буду подробно рассказывать о каждом таком операторе, а просто приведу их значения. Это оператор равно (==), не равно (!=), больше (>), меньше (<), больше или равно (>=), меньше или равно (<=), не (!), и (&&), или (||), содержит (Contains), то есть при использовании такого оператора левый операнд должен содержать фрагмент правого операнда; любое из (Any_Of), назначение которого в чем-то схоже с предыдущим оператором за исключением того, что в качестве значения может выступать лишь фрагмент значения правого операнда; член группы (MemberOf) – практически то же, что и содержит, только в качестве операнда выступает SID, а также оператор любой член группы (MemberOF_Any), что также можно сравнить с оператором любое из.
Теперь попробуем рассмотреть пример условных выражений, которые могут использоваться с утверждениями при реализации сценариев динамического контроля доступа. Например, возьмем следующее выражение:
User [1].Department==”Маркетинг” && (User [1].Title==”Финансист” || User [1].Title==”Маркетинг”)
Это выражение можно условно поделить на три части, причем каждая такая часть использует утверждения, да еще и вторая и третья части, которые находятся в скобках, будут обрабатываться одновременно. Теперь немного подробнее и по частям.
Исходя из приоритетов условных выражений, первыми должны выполняться выражения, которые расположены в скобках. Здесь в скобках можно найти два оператора: == и ||. Опять же, если смотреть по приоритетам, то первым всегда должен обрабатываться оператор ==. Следовательно, выражение обрабатывается слева направо.
Здесь в качестве типа утверждения пользователя выступает User [1].Title, которое отвечает за должность вашего сотрудника. Значит, мы проверяем, является ли должностью пользователя должность «Финансист». Предположим, что наш пользователь маркетолог, что означает, что в первом выражении значением будет FALSE, то есть ложь. Однако у нас между двумя выражениями установлен оператор ||, означающий логическое «ИЛИ». Это означает, что если второе выражение у нас будет истинным, то будет проверяться еще самое левое условное выражение.
В нашем случае, так как пользователь маркетолог, второе условное выражение в скобках примет значение TRUE, и это значит, что можно проверять условия дальше. На этом этапе у нас выходит следующее выражение:
User [1].Department==”Маркетинг” && (FALSE || TRUE)
Это означает, что можно выражение сократить еще сильнее, до:
User [1].Department==”Маркетинг” && TRUE
После этого проверяется самое левое условное выражение. Здесь, полагаю, все понятно. Проверяется, является ли отделом нашего пользователя «Маркетинг». Так как наш пользователь маркетолог, предположим, что его отдел, – это именно отдел маркетинга, и значит, выражение истинно. У нас получается следующее:
TRUE && TRUE
Так как оператор && представляет собой логическое «И», это означает, что оба условия должны быть истинными. В нашем случае так и есть. Следовательно, условие истинно и доступ будет предоставлен. Если бы здесь где-то фигурировало FALSE, то при операторе && оно бы превалировало, и в конечном счете мы бы получили результат FALSE.
Другими словами, у нас получается выражение, которое изображено на следующей иллюстрации:
Рис. 1. Пример условного выражение в диалоговом окне элементов разрешения для папки
ВОПРОС для внимательного читателя: что собой представляет следующее условное выражение, и как будет выполняться проверка, если учесть, что мы имеем дело все с тем же пользователем, о котором речь шла выше:
(User [1].Title==”Бухгалтер” || User [1].Title==”Финансист”) || User [1].Department!=”Служба поддержки”
Как вам известно, в схеме Active Directory можно найти описание всех объектов, с которыми можно работать в доменных службах Active Directory. И объекты технологии динамического контроля доступа ни в коем случае не являются исключением. Пока на данном этапе я не вижу смысла описывать все объекты, которые имеют то или иное отношение к текущей технологии, а просто отмечу, что таких объектов 9 (атрибутов, естественно, почти в трижды больше), но в случае с рассматриваемыми на этом этапе утверждениями, можно выделить лишь два объекта, а именно:
Объекты класса msDS-ClaimType изображены на следующей иллюстрации:
Рис. 2. Объекты класса msDS-ClaimType
Ввиду того, что в последней серверной операционной системе от Microsoft особое внимание разработчики старались уделить непосредственно таким инструментам, как «Центр администрирования Active Directory», а также командной оболочке Windows PowerShell, управлять своими типами утверждений вы сможете как при помощи первого, так и средствами второго средства. Так как было бы несправедливо рассматривать только лишь одно средство, в следующих разделах я покажу, каким образом можно работать с утверждениями, используя эти оба средства администрирования. А начнем мы, естественно, с
В принципе, и без того сугубо теоретическая часть сильно затянулась, поэтому без лишних прелюдий, пожалуй, буду переходить к сути. Итак, чтобы создать утверждение, которое будет использоваться для последующих централизованных политик доступа средствами центра администрирования Active Directory, нужно будет выполнить следующие действия:
Рис. 3. Открытие диалогового окна создания нового типа утверждения
Рис. 4. Раздел «Атрибут источника» создаваемого типа утверждения
Рис. 5. Раздел «Предложенные значения» создаваемого типа утверждения
Рис. 6. Диалоговое окно добавления предложенного значения
Более того, при работе с утверждениями помните, что у них может быть два состояния: включено и отключено. Отключенные утверждения так и остаются настроенными со своими уникальными идентификаторами, однако вы их просто не сможете в будущем использовать. Для того чтобы отключить тип утверждения, достаточно всего лишь выделить такой объект и из контекстного меню выбрать опцию «Отключить» (Disable).
Без PowerShell сейчас, как говорится, никуда. А если еще и учесть то, что в последней на это время серверной операционной системе от Microsoft были разработаны командлеты практически для любого действия, то очевидно то, что и в случае с технологией динамического контроля доступа вы можете воспользоваться богатейшими функциональными возможностями этой современной командной оболочки.
Стоит сразу обратить внимание на то, что для работы как с типами утверждений, так и с технологией динамического контроля доступа в частности, вам понадобится использовать модуль Active Directory для Windows PowerShell. Используя богатые возможность PowerShell, вы можете создавать, изменять, удалять, включать и отключать типы утверждений. То есть, грубо говоря, можете выполнять все те же операции, которые доступны средствами графического интерфейса в центре администрирования Active Directory.
Так как данная статья вышла увесистой, рассмотрим лишь создание двух типов утверждений (с предопределенными значениями и без таковых), а также отключение типа утверждения, для которого не были определены значения. Значит:
Чтобы создать новый тип утверждения, используется командлет New-ADClaimType. Вместе с этим командлетом вы можете использовать до 21 параметра, назначение которых очевидны из самого их наименования. Поэтому я подробно не буду останавливаться на каждом параметре, а сразу предлагаю рассмотреть пример создания нового типа утверждения. Используем следующий командлет:
New-ADClaimType –AppliesToClasses:@(‘user’) –Description:”Определение атрибута division” -DisplayName:”division” –IssingkeValued:$true –Server:”DC.biopharmaceutic.local” –ProtectedFromAccedentialDeletion:$true –SourceAttribute:”CN=Division,CN=Schema,CN=Configuration,DC=biopharmaceutic,DC=local”
Здесь обязательно обратите внимание на несколько моментов. Прежде всего, синтаксис параметра –AppliesToClasses следующий: вы указываете символ @, а затем в скобках и в кавычках указываете сам тип утверждения. Если вы хотите указать несколько типов, разделяйте их запятыми. Путь к атрибуту нужно указывать полностью, как это видно по предыдущей команде. Если вам нужно определить идентификатор, используйте параметр –ID и указывайте сам идентификатор в валидном формате, например, -ID:ad://ext/division:88d00962e3d07cd1.
Теперь посмотрим на более сложный пример, в котором попробуем вместе с типом утверждения еще и предопределить несколько значений. Попробуем создать тип утверждения для должности, где в качестве значений будут заданы маркетолог, бухгалтер и финансист:
New-ADClaimType -AppliesToClasses:@('user') -Description:"Должность сотрудника" -DisplayName:"title" -IsSingleValued:$true -Server:"DC.biopharmaceutic.local" -ProtectedFromAccidentalDeletion:$true -SourceAttribute:"CN=Title,CN=Schema,CN=Configuration,DC=biopharmaceutic,DC=local" -SuggestedValues:@((New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("Маркетолог", "Маркетолог", "Пользователь с должностью Маркетолог")), (New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("Бухгалтер", "Бухгалтер", "Пользователь с должностью Бухгалтер")), (New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("Финансист", "Финансист", "Пользователь с должностью Финансист")))
Как вы не могли не заметить, скрипт вышел намного массивнее. Здесь первые параметры практически идентичны, поэтому их разбирать нет смысла. А вот параметр –SuggestedValues, отвечающий за предложенные значения, может показаться весьма страшным. На самом деле, с ним все очень просто. Указывается параметр, после двоеточия следует указать символ @ и в скобках, при помощи командлета New-Object, нужно будет добавить объект Microsoft Active Directory Management ADSuggestedValueEntry с тремя значениями, определенными в скобках и разделенными запятыми. Перед добавлением каждого нового объекта следует ставить запятую и добавлять последний в дополнительных скобках. То есть все более-менее прозрачно.
И теперь третий пример, который позволит отключить созданный ранее тип утверждения без значений. Это можно реализовать, используя командлет, предназначенный для изменения типа утверждения. То есть сейчас мы будем использовать командлет Set-ADClaimType, естественно, с параметром -Enabled. Получается, следует выполнить такую команду:
Set-ADClaimType -Identity "CN=ad://ext/division:88d00968ab6e025f,CN=Claim Types,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local" -Enabled:$false
Здесь нужно обратить внимание на то, что значение параметра –Identity обязательно должно совпадать со значением такого типа утверждения из атрибута distinguishedName самого объекта типа утверждения. Опять же, как видите, нет ничего сложного.
Вывод команд в окне Windows PowerShell изображен на следующей иллюстрации:
Рис. 7. Командлеты, о выполнении которых было написано раньше
Следовательно, после того как все указанные выше действия будут выполнены, в окне центра администрирования Active Directory должны отображаться три объекта типа утверждения, причем один из них должен быть отключен. Это видно на следующей иллюстрации:
Рис. 8. Окно центра администрирования Active Directory
В принципе, здесь материал данной статьи подходит к концу. Я вам рассказал о том, что собой представляют утверждения, какие бывают типы утверждений, что такое условные выражения, а также вы узнали о том, как можно управлять типами утверждений при помощи таких средств как «Центр администрирования Active Directory» и Windows PowerShell.
Естественно, на этом знакомство с такой технологией как динамический контроль доступа не заканчивается, так как еще будет рассмотрено очень много интересных нюансов, процедур, возможностей и сценариев. Например, в следующей статье мы с вами поговорим о свойствах ресурсов.
Автор: hb860
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/active-directory/32764
Ссылки в тексте:
[1] User: http://habrahabr.ru/users/user/
[2] Источник: http://habrahabr.ru/post/177575/
Нажмите здесь для печати.