В качестве протокола аутентификации, AD применяет Kerberos версии 5 для предоставления аутентификации между самим сервером и его клиентом. Kerberos v5 стал устанавливаемым по умолчанию протоколом аутентификации для Windows Server начиная с Windows Server 2003 и далее. Это не частный закрытый протокол; он является открытым стандартом. Тем самым Windows способен работать с любыми приложениями и службами, которые поддерживают тот же самый стандарт. Прежде чем мы рассмотрим улучшения безопасности AD DS (Active Directory Domain Service), для нас важно изучить как же работает аутентификация AD.

Рассматриваемый нами протокол Kerberos выстроен для защиты аутентификации между самим сервером и его клиентом в некой открытой сетевой среде. Самая основная концепция стоящая за аутентификацией состоит в том, что две стороны вначале согласовывают некий пароль (секрет), а затем используют его вдвоём для идентификации и удостоверения своей подлинности:

В нашем предыдущем примере, Dave и server A имеют обычные соединения. Они часто обмениваются конфиденциальными данными. Чтобы защищать такие соединения, они договариваются применять некий общий секретный код (1234) для проверки своей идентификации прежде чем обмениваться данными. Когда Dave делает начальное соединение, он передаёт свой секретный код server A и сообщает: Hey! I'm Dave Затем server A проверяет значение этого секретного кода чтобы удостовериться в его истинности. Если это так, он идентифицирует его как Dave и разрешает последующее подключение:

Взаимодействие между Dave и server A происходит в некой открытой сетевой среде, что означает, что также имеются прочие системы и пользователи. Same является ещё одним пользователем в той же самой инфраструктуре. Он знает о взаимодействии, которое происходит между Dave и server A. Те сведения, которыми обмениваются эти две стороны, имеют высокую ценность, а потому Same пытается получить их в свои руки. Он начинает выполнять сниффинг в той же самой сетевой среде чтобы отыскать значение используемого ими секретного кода. После того как он его обнаружит, он сможет взаимодействовать с server A и претендовать на то чтобы выступать от имени Dave, предоставляя это значение секретного кода, 1234. Однако server A не видит никакой разницы между запросами от Dave и Same, так как оба предоставляют верный секретный код.

Kerberos решает такой вызов безопасности при помощи использования симметричного криптографического ключа вместо секретных кодов. Он также использует их для шифрования и дешифрации. Само название Kerberos происходит от мощной трёхголовой собаки из Греческой мифологии. В точности как и сама мифическая трёхголовая собака, наш протокол Kerberos имеет три основных компонента:

Такая доверительная авторизация имеет название KDC (Key Distribution Center, Центра распространения ключей). Прежде чем подробно рассматривать Kerberos, давайте вначале рассмотрим как работает типичный обмен ключами:

Если повторно посетить наш сценарий, у нас теперь имеется на своём месте KDC. Вместо того чтобы взаимодействовать непосредственно с Server A, Dave следует в KDC и сообщает о необходимости доступа к Server A. Для Dave необходим некий симметричный ключ чтобы начать взаимодействие с Server A. Этот ключ должен использоваться только Dave и Server A. KDC принимает соответствующий запрос, вырабатывает некий ключ (Key D+S), а затем выпускает его для Dave и Server A. При первичном рассмотрении это кажется достаточно простым, однако с точки зрения Server A имеется ряд проблем.

Чтобы получить некое подключение от Dave, server A нуждается в наличии некой относящейся к Key D+S записи. Самый простой способ для этого состоит в хранении такого ключа в server A. Мы рассматриваем хранение лишь одного соединения с server A, но что если имеются сотни подключений, server A должен будет хранить все вовлечённые в это ключи. Что не выглядит практичным. Как и все прочие ресурсы, если такой сервер оказывается скомпрометированным, злоумышленники будут иметь доступ ко всем имеющимся ключам. Итак, есть ли лучший вариант для этого?

В некой среде AD, сам KDC устанавливается как часть имеющегося контроллера домена. Этот KDC отвечает за две основные службы: одной является AS (Authentication Service, Служба Аутентификации), а другой является TGS (Ticket-Granting Service, Служба предоставления квитанции).

В нашем предыдущем примере, когда Dave регистрируется в существующей системе, ему требуется доказать KDC что он в точности та персона, для кого сделана эта заявка. После того как он зарегистрирован, он отправляет своё имя пользователя в установленный KDC совместно с неким долговременным ключом (long-time key). Значение долговременного ключа вырабатывается на основе пароля Dave. Имеющийся в ПК Dave клиент Kerberos принимает его пароль и вырабатывает соответствующий криптографический ключ. Существующий KDC также сопровождает некую копию этого ключа в своей базе данных. После того, как этот KDC получает соответствующий запрос, он сверяет его имя пользователя и значение долговременного ключа со своими записями. Если всё это хорошо, данный KDC отвечает Dave неким ключом сеанса ключом (session key). Он именуется TGT (ticket-granting ticket, мандатом на выдачу квитанций).

Такой TGT содержит два момента:

Когда Dave получает этот ключ, он может применить свой долговременный ключ чтобы расшифровать значение ключа сеанса. После этого всё последующее взаимодействие с его KDC будет основываться на этом ключе сеанса. Такой ключ сеанса временный и обладает неким значением TTL (time-to-live, времени жизни).

Это значение ключа сеанса запоминается в энергозависимой оперативной памяти компьютера Dave. Теперь настало время запросить доступ к server A. Dave обязан снова вступить в контакт со своим KDC, однако в этот раз он применяет значение ключа сеанса, предоставленное ему этим KDC. Такой запрос содержит значение TGT и значение временного штампа, зашифрованные значением ключа сеанса и значением идентификатора службы (той службы, которая запущена на server A). После того как их KDC получает его, он использует свой долговременный ключ для дешифрации значения TGT и достаёт значение ключа сеанса. Дальше, применяя этот ключ сеанса, он расшифровывает значение временного штампа. Если полученное временное различие менее 5 минут, тогда он подтверждает что ключ получен от Dave.

Когда KDC подтвердил его в качестве законного запроса, он создаёт другую квитанцию, и уже она имеет название квитанции службы (service ticket). Она содержит два ключа: один для Dave, и один для server A. Оба ключа содержать значение запрашивавшей стороны (Dave), значение получателя, значение временного штампа, величину значения TTL и некий новый ключ сеанса, (который будет совместно применяться Dave и server A). Один из этих ключей шифруется при помощи долговременного ключа Dave, а другой шифруется с применением долговременного ключа server A. В самом конце, оба шифруются совместно посредством ключа сеанса между их KDC и Dave. Наконец, эта квитанция готова для отправки Dave. Dave дешифрует значение квитанции при помощи своего ключа сеанса. Он также находит свой ключ и дешифрует его при помощи своего долговременного ключа.

Данный процесс раскрывает значение нового ключа сеанса, который требуется разделять между Dave и server A. Затем Dave создаёт некий новый запрос, который содержит ключ server A, полученный из данной квитанции сервера, а также значение временного штампа, которое было зашифровано с применением этого нового ключа сеанса, созданного их KDC. После того как Dave отправит значение ключа server A, он расшифрует этот ключ при помощи своего долговременного ключа и выберет значение ключа сеанса. Применяя значение ключа сеанса, он способен расшифровать значение временного штампа для того чтобы удостовериться в верности аутентификации самого запроса. Как мы видим, в данном процессе отсутствует ответственность server A за отслеживание значения ключа, применяемого самим клиентом, а также не входит в ответственность этого клиента отслеживать уместность ключей.

Давайте немного забежим вперёд и рассмотрим как налаживается аутентификация в некой среде AD:

Приводимый ниже перечень суммирует шаги, вовлечённые в такой процесс аутентификации:

Существует ещё ряд моментов, которые реализовать для завершения данного процесса:

В этом разделе мы изучили то, что из себя представляет протокол Kerberos и как он работает с аутентификацией AD. Kerberos имеет встроенные свойства безопасности для защиты идентификации пользователя на протяжении самого процесса аутентификации, однако этого не достаточно для защиты идентичностей против возникающих угроз. По этой причине, в своём следующем разделе мы намерены рассмотреть различные методы, инструменты и функциональности, которые могут использоваться для дальнейшего усиления нашей среды AD.

В своём предыдущем разделе мы изучили то, как функционирует аутентификация AD. Как мы видели, протокол Kerberos сам по себе был построен для предотвращения компрометации идентичности. Это всё хорошо на бумаге, однако в реальности злоумышленники применяют множество методов и инструментов для атак на среды AD. По этой причине важно знать те свойства, техники и инструменты, которые мы можем применять для дальнейшей защиты AD.

В некой среде AD имеются различные типы задач управления. Управление контроллерами доменов, добавление/ управление/ удаление пользователей, добавление/ управление/ удаление групп, сброс паролей, а также добавление устройств в компьютеры - всё это лишь некоторые примеры. В каком-то обладающим структурой ИТ подразделении эти задачи управления должны быть ограничены различными ролями заданий.

В качестве некого примера давайте сделаем предположение, что ИТ подразделение Rebeladmin Corp. имеет первую линию (первый контакт поддержки), вторую линию (промежуточную) и третью линию (старшую) команд ИТ. При рассмотрении задач управления соответствующего AD, инженеры первой линии обычно вовлечены в такие задачи, как сбросы паролей пользователей, настройка новых учётных записей пользователей и групп, а также добавление устройств в домены.

Инженеры второй линии вовлечены в дополнительные задачи, такие как установка Групповых политик и выявление неисправностей Групповых политик с их устранением. Инженеры третьей линии обычно работают над такими задачами, как выявление и устранение более сложных неисправностей, установка контроллеров домена, изменение схемы, а также изменения физической и логической архитектуры.

При таком подходе мы можем группировать задачи управления AD в соответствии с имеющимися полномочиями различных ролей инженеров. Это позволяет различным ролям заданий получать в собственность различные задачи управления AD. В то же самое время, когда некая определённая роль задания назначена соответствующему владельцу задачи, должен иметься некий механизм предотвращения того, чтобы прочие команды не оказывали влияния на эту конкретную задачу. В качестве некого примера, когда инженеры третьей линии отвечают за изменение схемы AD, тогда должен иметься некий способ препятствия инженерам первой и второй линий от выполнения ими этого также. Если нам требуется запрещать/ разрешать пользователям или группам входу/ доступу к некой папке в файловом сервере (соответственно), мы можем делать это применяя полномочия (permissions). В точности также AD позволяет вам управлять авторизацией объектов или управлением задач пользователей и групп на основе полномочий. Управление полномочиями для имеющейся команды ИТ является сложной задачей, поскольку это касается не только полномочий. Это также имеет и социальную сторону. В целом, мы принимаем что администраторы являются заслуживающими доверия людьми; в то же время вы можете не знать большинство из них. А потому лучше предпринять меры предосторожности и разумно управлять полномочиями. Существует несколько способов управления полномочиями для задач управления AD:

AD имеет предварительно определённые роли администрирования. Каждая из этих ролей имеет подключёнными к ней заранее заданные полномочия. Если некому пользователю требуются эти роли полномочий, их учётные записи требуется добавить в надлежащую группу безопасности. Эти группы безопасности являются предварительно определёнными группами:

Полномочия доступа пользователя или группы для некой совместно используемой папки управляются соответствующим ACL. Аналогично мы способны определять полномочия для объектов AD. Это может применяться для индивидуальных объектов, или для конкретных площадки/ домена/ OU AD, а затем те же самые полномочия могут быть принудительно применены к объектам нижнего уровня.

В качестве примера у меня имеется группа безопасности с названием First Line Engineers, причём Liam выступает членом этой группы. Liam является инженером в европейском офисе. В имеющемся AD для Liam должно быть разрешено добавлять объекты пользователей только в подчинённом OU, который расположен под OU Europe. Однако ему не должно быть позволено удаление каких бы то ни было объектов под ним. Давайте посмотрим как мы это можем сделать при помощи ACL:

Это подтверждает что мы способны управлять полномочиями для задач управления AD с помощью ACL.

Метод передачи (делегирования) контроля также работает аналогично ACL, но упрощает управление привилегиями, поскольку он использует следующее:

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

Это также позволяет вам создавать некую индивидуальную задачу делегирования полномочий если она не покрывается уже перечисленным перечнем задач.

Аналогично ACL полномочия могут применяться к следующим уровням:

В качестве примера у меня имеется некая группа безопасности с названием Second Line Engineers, а Scott выступает её участником. Мне требуется разрешить участникам этой группы сброс паролей в OU=Users,OU=Europe,DC=rebeladmin,DC.

Для этого мне требуется проделать следующее:

Применяя эти три метода мы способны делегировать полномочия для задач администрирования AD. Это помогает нам назначать зоны ответственности для пользователей или групп чтобы удерживать среду AD жизнеспособной и безопасной.

Сложные пароли составляют основу базовых настроек безопасности, применяемую всеми администраторами. В нашей среде AD сложность пароля настраивается установками и настройками блокировок учётных записей, которые можно конфигурировать при помощи настроек GPO, которые размещаются в Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies. Вплоть до Windows Server 2008 существовала лишь одна политика паролей и блокирования учётных записей, которая могла применяться ко всем пользователям. Начиная с Windows Server 2008, Microsoft ввёл политики тонкой грануляции паролей, которые делают возможным для администраторов применять различные политики паролей и блокирования учётных записей для конкретных пользователей или групп. Это позволяет вам защищать привилегированные учётные записи при помощи более строгих политик чем учётные записи обычных пользователей. Эта функциональность продолжает оставаться во всех версиях AD DS после Windows Server 2008 и также доступна и в AD DS 2016.

Как- то раз я работал над аудитом AD для некого хэдж фонда. В качестве части отчёта я рекомендовал чтобы они применяли политики паролей с большей сложностью , поскольку они этого не делали. После того как я пояснил это, их менеджеры ИТ согласились и я настроил политику паролей и политику блокировки учётных записей. Через несколько дней я приехал на ту же самую площадку и те же менеджеры ИТ показали мне, что после того как была принудительно введена данная политика, их конечные пользователи стали стали записывать свои сложные пароли на самоклеящихся стикерах и бумажках. А следовательно, даже хотя настройки безопасности были установлены, в конце концов, это повлекло ещё большие проблемы с безопасностью, так как все прочие пользователи имели возможность видеть пароли друг друга на наклеенных записках. Тем не менее, применяя более тонко гранулированные политики паролей, администраторы способны применять различные настройки на основе имеющейся ситуации. В качестве примера, в то время как пользователи отдела продаж могут использовать пароли со сложностью в 5 символов, Для Администраторов Домена вы можете применять сложность паролей в 12 символов.

Политики тонкой настройки паролей обладает следующими ограничениями:

Когда вы используете тонко гранулируемые политики паролей, некоторые объекты могут иметь применёнными к ним множество политик тонкой грануляции паролей. Тем не менее, в каждый определённый момент времени, к некому объекту может применяться лишь одна политика пароля. Нет возможности даже соединять множество политик.

RSoP (Resultant Set of Policy, Получаемый в результате набор политик) использует значение атрибута msDS-PasswordSettingsPrecedence, который связывается со всеми политиками паролей чтобы принимать решение о значении побеждающей политики. Значением превосходства выступает некое целое значение, которое может устанавливать администратор. Более низкое значение превосходства означает более высокий приоритет. Когда к одному и тому же объекту применяется множество политик пароля, побеждает та политика, которая имеет самое низкое превосходство.

Приводимый ниже перечень дополнительно поясняет как в некой инфраструктуре работают политики паролей:

Имеются два способа применения политик тонкой грануляции паролей. Первый вариант состоит в применении ADAC (Active Directory Administrative Center), а второй заключается в использовании cmdlet PowerShell.

В ADAC проследуйте в System | Password Settings Container, затем щёлкните правой кнопкой и перейдите в New | Password Settings. Это откроет для вас окно, в котором мы можем определять необходимые установки паролей:

В этом окне политик мы можем определить само название политики, старшинство и настройки политик блокирования учётной записи. Directly Applies To выступает именно тем местом, в котором мы можем определить группы безопасности, являющиеся целью данной новой политики. В своём предыдущем примере я добавил в качестве таковой цели группу безопасности First Line Engineers..

Тонко настраиваемые политики паролей также можно создавать при помощи PowerShell:

New-ADFineGrainedPasswordPolicy -Name "Domain Admin Password Policy" -Precedence 1 `
-MinPasswordLength 12 -MaxPasswordAge "30" -MinPasswordAge "7" `
-PasswordHistoryCount 50 -ComplexityEnabled:$true `
-LockoutDuration "8:00" `
-LockoutObservationWindow "8:00" -LockoutThreshold 3 `
-ReversibleEncryptionEnabled:$false
		

В нашей предыдущей команде New-ADFineGrainedPasswordPolicy это именно тот cmdlet, который применяется для создания некой новой политики. -Precedence задаёт значение старшинства политики. Величины значений -LockoutDuration и -LockoutObservationWindow определяются в часах. Значение величины -LockoutThreshold определяет общее число допустимых попыток регистрации.

Установленные политики можно просмотреть при помощи ADAC или PowerShell:

Get-ADFineGrainedPasswordPolicy – Identity "Domain Admin Password Policy"
		

Наша предыдущая команда выполнит выборку следующих установок для заданных политик паролей:

Теперь у нас есть некая новая политика, а наш следующий шаг состоит в назначении объектов в неё. Нам требуется добавить в неё группу безопасности Domain Admin:

Add-ADFineGrainedPasswordPolicySubject -Identity "Domain Admin Password Policy" -Subjects "Domain Admins"
		

Наша предыдущая команда добавила имеющуюся группу Domain Admin Domain Admin Password Policy. В этом можно убедиться с помощь такой команды:

Get-ADFineGrainedPasswordPolicy -Identity "Domain Admin Password Policy" | Format-Table AppliesTo –AutoSize
		

Это подтверждает то, что выступает целью данной политики. Данное значение сохраняется под атрибутом AppliesTo.

Наша следующая комада также полезна для перечисления фильтрованных сведений о политике паролей:

Get-ADFineGrainedPasswordPolicy -Filter * | Format-Table Name,Precedence,AppliesTo –AutoSize
		

Это приведёт список всех тонких настроек политик совместно с Name, Precedence и значением цели.

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

Современные протоколы аутентификации хорошо осведомлены о таких видах угроз и применяют разнообразные технологии шифрования полномочий либо создают криптографические хэши для проверки аутентификации. Термин криптографический хэш (cryptographic hash) означает что некая строка пароля преобразуется в при помощи какого- то алгоритма в цифровую строку фиксированной длины.

Ранее в разделе Аутентификация AD мы наблюдали как работает аутентификация Kerberos при помощи хэшированных значений. Когда мы применяем хэшированные значения, имеющийся сервер аутентификации сравнивает такое предоставляемое паролем клиента значение хэша с тем значением хэша для этого пользователя, которое хранится в его базе данных. В имеющейся среде Windows эти хэши паролей хранятся в трёх различных местах:

База данных SAM хранит имена пользователей и хэш- значения NT (New Technology) в файле %SystemRoot%/system32/config/SAM. Он содержит все значения хэшей для учётных записей, которые являются локальными для этого компьютера. Текущая версия SAM не хранит в своём файле базы данных хэши LM (LAN Manager).

Самой первой введённой Microsoft схемой хэширования паролей была LM. Для хэширования она применяла алгоритм DES (Data Encryption Standard, Стандарта шифрования данных). Это наследуемая слабая схема и Microsoft настоятельно не рекомендует её применять. Она не поддерживает пароли длиннее 15 символов ASCII или парали не являющиеся чувствительными к регистру. Однако, все новые операционные системы, выпускавшиеся после Windows Vista для хэширования поддерживают алгоритм AES (Advanced Encryption Standard, Усовершенствованного стандарта шифрования).

По сравнению с паролем в открытом виде, для некого злоумышленника, почти невозможно вычислить значение самого пароля на основании его хэша. Даже если это будет возможно сделать, это потребует большой вычислительной мощности и времени. Однако, если вы можете отыскать само значения хэша вместо выуживания пароля, такое хэш значение может применяться для инициации соединения с имеющимся сервером от лица первоначального владельца этого хэша. Это звучит простым, однако на практике это всё ещё очень сложно, так как эти протоколы аутентификации имеют свои собственные механизмы для предотвращения применения злоумышленниками какого- то другого значения хэша. Когда дело касается Kerberos, он совместно с запросами и откликами при проверке аутентичности хэшей применяет временные штампы. NT (New Technology), NTLM v1 (New Technology LAN Manager) и NTLM v2 также применяют аналогичный механизм отклик- отзыв для аутентификации без раскрытия значения пароля.

Однако, даже хотя хэш значения не передаются непосредственно. LSASS хранит полномочия в памяти от имени пользователей с активными сеансами. LSASS может хранить полномочия в множестве видов, например, неком NT хэше, LM хэше, а также квитанциях Kerberos. Это необходимо для сопровождения активных сеансов и более быстрой последующей аутентификации. Он очищается в процессе перезагрузки, но этого может оказаться достаточным для злоумышленника чтобы выполнить выборку хэша и воспользоваться им для компрометации всей имеющейся инфраструктуры идентификации. Microsoft ввёл множество свойств и техник для защиты своей среды AD от атак передачи значения хэша (pass-the-hash), и в данном разделе мы намерены рассмотреть их подробно.

Группа безопасности Защищённых пользователей (Protected Users) была введена в Windows Server 2012R2 и продолжает своё существование в Windows Server 2016. Эта группа была разработана для предоставления учётных записей с высокими привилегиями лучшей защиты от атак воровства полномочий. Участники этой группы имеют применёнными не настраиваемую защиту. Чтобы применять группу Защищённых пользователей, PDC (Primary Domain Controller, Первичный контроллер домена) обязан быть запущенным с Windows Server 2012R2, как минимум, а компьютеры его клиентов должны работать как минимум с Windows 8.1 или Windows 2012 R2.

Когда некий участник этой группы регистрируется в Windows 8.1, Windows Server 2012 R2, Windows 10 или Windows Server 2016, тогда мы можем ожидать следующее:

Для присутствия свойств группы Защищённых пользователей не обязательно иметь некий домен, имеющий уровень функциональности Windows Server 2012 R2 или выше (минимумом является Windows Server 2008, так как Kerberos обязан использовать AES). Единственным требованием является запуск в соответствующем контроллере домена Windows Server 2012 R2 роли FSMO (Flexible Single-Master Operations, Гибких операций с единственным хозяином).

Когда установленная среда AD применяет уровни функциональности домена Windows Server 2012 R2 или Windows Server 2016, она предоставляет дополнительные защиты группам Защищённых пользователей, такие как:

Для начала мы можем просмотреть саму группу безопасности Protected Users, воспользовавшись такой командой:

Get-ADGroup -Identity "Protected Users"
		

Приводимый ниже снимок экрана отображает вывод для предыдущей команды:

Мы можем добавлять пользователей в группу Protected Users при помощи ADAC, ADUC MMC, а также PowerShell. Эта группа расположена в устанавливаемом по умолчанию в AD контейнере Users.

В нашем случае мы намерены добавить в группу Protected Users учётную запись для Adam при помощи такой команды:

Get-ADGroup -Identity "Protected Users" | Add-ADGroupMember –Members "CN=Adam,CN=Users,DC=rebeladmin,DC=com"
		

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

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

Get-ADGroupMember -Identity "Protected Users"
		

Для проверки этого мы намерены воспользоваться инструментом с названием mimikatz, который может применяться для экспериментов с безопасностью Windows.

Я регистрируюсь в неком компьютере в качестве пользователя Liam, причём он не является участником группы Protected Users. Когда я перечисляю его ключи из LSASSS для пользователей, я могу отчётливо наблюдать хэш NTLM Liam:

Когда я проделываю то же самое с Adam, который является участником группы Protected Users, я не могу видеть сохранённого в памяти LSASS значения хэша NTLM, поскольку находящиеся в защищённой группе участники не применяют NTLM и не сохраняют никаких полномочий в имеющемся кэше:

Обсуждённая группа безопасности Защищённых пользователей (Protected Users security group) была впервые введена в Windows Server 2012 R2. Она имеет встроенные возможности для защиты привилегированных учётных записей от атак кражи полномочий. В этом разделе мы изучили те технологии, которые стоят за (Protected Users security group. Мы также изучили необходимые настройки данной функциональности безопасности. В своём следующем разделе мы намерены рассмотреть ещё одно встроенное свойство безопасности, которое может применяться для предотвращения утечки полномочий при не безопасных подключений RDP.

При типичной атаке на инфраструктуру идентификации, самой первой целью, как правило, выступает учётная запись обычного пользователя или некого оконечного пункта. Это происходит по причине того, что учётные записи с высокими привилегиями и критически важные системы имеют расширенную защиту по сравнению с устройствами конечных пользователей. В большинстве сред такие системы и учётные записи постоянно отслеживаются и существует высокая вероятность того, что инженеры быстро распознают попытки регистрации без авторизации или необычное поведение. Учётная запись некого типичного пользователя не имеет требующихся привилегий или возможностей для выполнения больших разрушений, а вот у привилегированных учётных записей они имеются. После того как некий злоумышленник успешно осуществляет первоначальный прорыв, следующий искомый им момент состоит в получении в свои руки привилегированной учётной записи.

Когда они начинают беспорядочно вести себя в неком оконечном оборудовании и выполнять такие вещи, как удаление файлов, увеличивать потребление ЦПУ/ памяти, или разрушать приложения, тогда такой конечный пользователь обратится за помощью в ИТ подразделение. ИТ как правило являются участниками Enterprise Admins, Domain Admins, или по крайней мере группы локальных администраторов этого оконечного устройства. Для регистрации и выявления неисправностей им придётся применять привилегированные учётные записи. Если наш злоумышленник запустил в этой системе программу для сбора урожая паролей, тогда полномочия таких привилегированных учётных записей будут раскрыты.

В своём предыдущем разделе мы обсуждали как можно предотвращать сохранения в LSASS хэширования полномочий. Память LSASS сохраняет полномочия при выполнении чего- то из следующего списка:

RDP является наиболее распространённым методом для инженеров для удалённого доступа к компьютерам. Когда некий пользователь подключается к какой- то системе при помощи RDP, он отправляет мандат с параметрами доступа в этот удалённый компьютер в виде открытого текста. Когда компьютер скомпрометирован, это является проблемой безопасности. В Windows Server 2012 R2 Microsoft ввёл режим ограниченного администрирования RDP (restricted admin mode for RDP). При выборе для RDP этого режима, он не будет оправлять мандат с регистрационными данными в такой удалённый компьютер. После того как конкретный пользователь регистрируется через подобный ограниченный сеанс RDP, он не может подключаться к отличающимся от разделяемых в сетевой среде ресурсам. Такая функциональность также доступна и в Windows Server 2016.

Этот режим может применяться в Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 и Windows Server 2016.

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

После того как это сделано, мы можем подключаться к такому целевому компьютеру при помощи RDP с ограниченным режимом администрирования. Для этого соответствующий клиент удалённого рабочего стола требуется запускать в таком ограниченном режиме. Это можно сделать запуском команды mstsc /restrictedadmin.

Для проверки данной функциональности мы подключимся к некому участнику PC Windows 10 при помощи обсуждаемого ограниченного режима RDP. Данная учётная запись относится к Peter, причём он выступает участником группы Domain Admin:

Теперь, если мы попытаемся получить доступ к жёсткому диску другого компьютера, он высветит нам предупреждающее сообщение об ошибке Access is denied (Доступ отклонён). Имеющаяся учётная запись пользователя состоит в Domain Admin и это не может приводить к отказу в доступе. Он происходит по причине установленного ограниченного режима RDP, поскольку тот не способен применяться для ресурсов, отличающихся от совместно используемых в таком сеансе:

Аналогичное произойдёт, когда я попытаюсь добавить свой контроллер домена к имеющемуся Server Manager (Диспетчеру сервера) в этом удалённом компьютере. Это также высветит ошибку Access denied:

Данная функциональность минимизирует возможность риска компрометации учётных записей с высоким уровнем полномочий.

Высеченным в граните правилом при защите от атак передачи значения хэша (pass-the-hash) является предотвращение доверенным пользователям появляться в системах без доверия. Для размещения своей базы данных Rebeladmin Corp. применяет ферму MS SQL. В процессе настроек Сервера SQL инженеры пользуются учётными записями службы. Очевидно, что такие учётные записи службы SQL следует применять исключительно в Серверах SQL. Когда такие учётные записи возникают в компьютерах принимающих секретарей, что- то несомненно пошло не так. В Windows Server 2012 R2, Microsoft ввёл политики аутентификации и политики Бункеров (silos), которые могут применяться для ограничения использования учётных записей с высокими привилегиями только в выбранных системах.

Политики аутентификации

Политики аутентификации могут применяться для задания допустимого периода действия TGT протокола Kerberos и управления условиями контроля доступа на ограничение подписи пользователя.

Бункеры политик аутентификации

Бункеры политик аутентификации аналогичны контейнерам, в которые мы имеем возможность назначать учётные записи пользователей, учётные записи компьютеров и учётные записи служб. Далее этими учётными записями можно управлять через устанавливаемые политики аутентификации.

Данная функциональность нуждается в таких предварительных требованиях:

Создание политик аутентификации

Прежде чем мы создадим политики, нам требуется включить поддержку DAC для контроллеров домена и устройств. DAC позволяет администраторам применять полномочия и ограничения контроля доступа на основе правил, которые могут содержать характеристики этого устройства.

Для включения DAC в контроллерах домена выполните следующие шаги:

Чтобы включить DAC в компьютерах, выполните такие шаги:

В качестве некого примера, давайте создадим какую- то новую политику аутентификации с названием P_1hr_TGT и с временем жизни TGT в 60 минут:

New-ADAuthenticationPolicy -Name "AP_1hr_TGT" -UserTGTLifetimeMins 60 -Enforce
		

В нашей предыдущей команде -UserTGTLifetimeMins определяет значение времени жизни TGT для учётных записей пользователей, а параметр -Enforce вводит в действие ограничения политик.

Создание Бункеров политик аутентификации

Теперь, когда мы создали необходимую политику аутентификации, наш следующий шаг состоит в создании нового Бункера (silo) политики аутентификации. Моим требованием является создание некого Бункера политик для предотвращения доступа учётной записи пользователя Peter к REBEL-PC01.

Бункеры политик могут создаваться при помощи ADAC или cmdlet PowerShell New-ADAuthenticationPolicySilo:

Для данной демонстрации давайте создадим некий новый Бункер политики аутентификации с названием Restricted_REBEL_PC01:

New-ADAuthenticationPolicySilo -Name Restricted_REBEL_PC01 -UserAuthenticationPolicy AP_1hr_TGT -ComputerAuthenticationPolicy AP_1hr_TGT -ServiceAuthenticationPolicy AP_1hr_TGT -Enforce
		

В нашей предыдущей команде, -UserAuthenticationPolicy, -ComputerAuthenticationPolicy и -ServiceAuthenticationPolicy ссылаются на значения политик аутентификации, которые будут подключены к данному Бункеру политик. В нашем случае мы применяем лишь одну политику, однако если требуется, к данному Бункеру политик может быть подключено множество политик аутентификации , которые охватывают классы пользователей, компьютеров и служб.

Наш следующий этап состоит в добавлении соответствующих необходимых объектов в наш Бункер политик в качестве допустимых учётных записей. В моей демонстрации это будут учётная запись пользователя Peter и компьютер с названием REBEL-PC01.

В Бункер политик мы можем добавить эти объекты с помощью cmdlet PowerShell Grant-ADAuthenticationPolicySiloAccess:

Grant-ADAuthenticationPolicySiloAccess -Identity Restricted_REBEL_PC01 -Account Peter
		

Наша предыдущая команда добавила учётную запись Peter в Бункер политик Restricted_REBEL_PC01 в качестве разрешённой учётной записи.

Мы также можем скомбинировать её совместно с неким фильтром и затем добавить полученный результат в соответствующий Бункер политик:

Get-ADComputer -Filter 'Name -like "REBEL-PC01"' | Grant-ADAuthenticationPolicySiloAccess -Identity Restricted_REBEL_PC01
		

В нашей предыдущей команде мы отыскали имеющийся объект компьютера и затем передали результат в имеющийся Бункер политик.

После выполнения этого, нам требуется назначить Бункеры политик и саму политику аутентификации Peter и REBEL-PC01. Это можно выполнить при помощи Set-ADAccountAuthenticationPolicySilo:

Set-ADAccountAuthenticationPolicySilo -Identity Peter AuthenticationPolicySilo Restricted_REBEL_PC01 -AuthenticationPolicy AP_1hr_TGT
		

Наша предыдущая команда назначает имеющийся Бункер политик Restricted_REBEL_PC01 и установленную политику аутентификации AP_1hr_TGT учётной записи пользователя Peter.

Эти команды также могут подключаться к фильтрам:

Get-ADComputer -Filter 'Name -like "REBEL-PC01"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Restricted_REBEL_PC01 -AuthenticationPolicy AP_1hr_TGT
		

Наша предыдущая команда отфильтровывает объект компьютера AD REBEL-PC01 и затем назначает назначает ему и политику аутентификации и Бункер политик.

Самый последний шаг настройки состоит в задании необходимых условий контроля доступом для соответствующей политики AP_1hr_TGT. Это определяет необходимое условие для соответствующего устройства или хоста, с которых выполняют регистрацию пользователи. Данное условие для моей демонстрации будет применять значение Бункера политик конкретного пользователя:

Set-ADAuthenticationPolicy -Identity AP_1hr_TGT -UserAllowedToAuthenticateFrom "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"Restricted_REBEL_PC01`"))"
		

В нашей предыдущей команде устанавливаемое условие передаётся как некая строка SDDL (Security Descriptor Definition Language, Определяющего языка Дескриптора защиты). Вы можете получить дополнительные сведения относительно таких строк SDDL.

Это также можно изменять применяя окна свойств политик аутентификации в ADAC:

Это завершает необходимую настройку Бункера политик аутентификации и самой политики аутентификации. Политики аутентификации и Бункеры политик аутентификации предоставляют большую гибкость для защиты привилегированных учётных записей в критически важных системах.

В своих предыдущих разделах мы изучали свойства, которые были привнесены Microsoft для предотвращения атак передачи значения хэша (pass-the-hash). Эти типы атак всё ещё применяются злоумышленниками при атаках на инфраструктуры идентификации, а потому важно предотвращать такие атаки всякий раз когда это возможно и везде где это возможно. Однако сделает ли это безопасной на 100% нашу инфраструктуру идентификации? производители программного обеспечения, включая Microsoft, выпускают новые продукты, свойства, обновления безопасности и исправления ошибок для защиты систем, инфраструктур и рабочих процессов от различных видов угроз.

Все эти компании тратят множество средств ежегодно на исследования и разработку для защиты своего программного обеспечения, решений и потребителей от возникающих угроз. Однако мы всё ещё непрерывно наблюдаем новости относительно взломов безопасности инфраструктур идентификации. Как я себе представляю, это не проблема для технологии. Миф относительно атак нулевого дня больше не действует. При помощи всех этих технологий мы боремся против врагов человечества. Если используемый ими ранее метод больше не работает, они изыщут иной способ входа. Мы не способны закрыть все двери; нам следует ожидать вторжения в любое время.

JIT и JEA являются двумя различными подходами для безопасности инфраструктуры идентификации. В любой атаке на инфраструктуру идентификации враг преследует один общий момент. Для получения контроля над всей инфраструктурой ему требуется получить доступ к привилегированным учётным записям. Именно это должно быть результатом. JIT и JEA предназначены для действенного управления привилегиями в инфраструктуре идентификации. Они ограничивают то что могут делать противники в инфраструктуре идентификации даже в случае их прорыва.

В Главе 2, Службы домена Active Directory 2019 мы подробно изучали JIT и обсуждали как функциональность AD DS 2016 помогает делать это. Вследствие этого мы не намерены рассматривать эти детали снова в данной главе, однако я бы хотел перечислить несколько важных фактов:

Помимо всех этих фактов, AD DS 2016поодерживает участие в группах на временной основе. Такая функциональность может применяться для предоставления JIT администрирования.

JEA впервые было выпущено в 2014 и именно оно послужило первым подходом к администрированию JIT. JEA позволяет вам предоставлять привилегии на основе ролей вместо привилегий полного администрирования. Примером может служить наша Rebeladmin Corp. Команды ИТ ежемесячно запускают некий набор сценариев PowerSell для выработки отчётов относительно использования на протяжении месяца ресурсов в своём частном облачном решении. Для выполнения этого некий участник общей ИТ команды ежемесячно регистрируется в каком- то сервере и запускает данные сценарии. Те персоны, которые запускают эти отчёты, являются Domain Admins, так как для выполнения этого им требуется иметь административные полномочия. Однако этим пользователям не требуются привилегии Domain Admins для их повседневных задач в службе технической поддержки. Применяя JEA мы способны назначать в точности необходимые полномочия для запуска этих сценариев с определённого хоста вместо предоставления привилегий Domain Admins. Это целиком основанное на PowerShell решение. Он способно применяться со всем, что может управляться через PowerShell.

Microsoft AD DS уже обладает некой функциональностью, которая может применяться для ограничения административных полномочий, например администрирование на основе ролей и делегированное управление. Однако они всё ещё открыты для определённого риска безопасности:

при использовании JEA имейте в виду следующее:

JEA реализуется в виде конечных точек сеансов PowerShell. Оно содержит следующие файлы:

Одним из недостатков JEA является его ограниченность на PowerShell и не совместимость с обычными задачами и функциями на основе GUI.

Реализация JEA будет рассмотрена в Главе 16, Расширенное управление Active Directory с помощью PowerShell.

До сих пор мы изучали защиту идентификации в локальных средах AD. Однако в неком гибридном окружении идентификации также имеются и в самом облаке. Такие идентификации в целом синхронизируются из локальных сред AD с применением Azure AD Connect. Azure AD также имеет только облачные учётные записи. В некой гибридной среде нам также следует рассматривать защиту идентификации в самом облачном решении. Azure AD является управляемой службой, а потому мы не можем применять те же самые свойства,которые мы использовали в локальной среде AD. К тому же, вызовы бывают разными. В некой гибридной среде идентификация возникает в различных облачных службах, таких как SaaS (Software as a service), PaaS (Platform as a service), IaaS (Infrastructure as a service). Таким образом, потенциал для атак гораздо выше чем в локальной среде. В данном разделе мы намерены изучить некоторые службы и свойства, которые мы может применять для защиты идентификации в гибридной среде.

Как мы уже обсуждали это много раз, в некой атаке на идентичность противники имеют целью привилегированные учётные записи, поскольку именно они выступают ключами ко всему царству. Защищая привилегированные учётные записи, мы способны ограничивать ущерб даже в случае нарушения безопасности. В любой инфраструктуре у нас имеются разные типы администраторов, включая администраторов домена, локальных администраторов и администраторов служб, но в гибридной среде у нас к тому же имеются администраторы облака. Это подводит нас к следующим вопросам:

Некое решение состоит в отзыве этих полномочий. Да, это сработает, но сколько дополнительной работы нам потребуется проделать для восстановления данных полномочий когда они потребуются? И к тому же, насколько это практично? Это также обладает и социальным воздействием. Если вы спуститесь вниз к своим пользователям и сообщите им что вы намерены отозвать их административные привилегии, как они вам могут ответить? Пользователям всё- таки требуется привилегированный доступ к их приложениям и службам чтобы настраивать приложения и службы, управлять ими и устранять неисправности.

Azure AD PIM делает для нас возможным управление, контроль и мониторинг привилегированного доступа к приложениям и службам, подобным Azure AD, Office 365 и прикладным приложениям SaaS. Это в целом некий автоматизированный процесс (в зависимости от того, будут ли в него вовлечены автоматические удостоверения правил, или же они будут подтверждаться вручную), однако что более важно, мы запрашиваем полномочия всякий раз когда они нам требуются.

PIM обладает следующими ключевыми свойствами:

Для использования Azure AD PIM нам требуется одна из следующих платных лицензий:

Руководства по реализации

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

При пересмотре доступа нам следует рассмотреть выполнение следующего:

Я составил пошаговое руководство, поясняющее как включать пересмотр доступа PIM. Вы можете последовать ему воспользовавшись ссылкой.

Реализация

Я уже написал ряд блог постов, поясняющих как настраивать Azure PIM. Будьте любезны следовать им для реализации Azure PIMв своей среде:

До сих пор в этой главе мы обсуждали защиту идентификации. Хотя это и наиболее ценная часть в данной инфраструктуре, это не единственная ценность. В Главе 1, Основы Active Directory мы рассматривали как данные превращаются в новую нефть. Некоторые типы данных имеют большую ценность чем иные, причём такими типами данных с более высокой стоимостью выступают конфиденциальные/ чувствительные для персоны, группы, компании, организации или страны. Злоумышленники ищут идентификацию, так как скомпрометированные инфраструктуры идентификации позволяют им выполнять доступ к различным видам данных. Идентификация и полномочия доступа решают к какому виду данных некая персона может иметь доступ.

Как пример, некий руководитель компании имеет больше доступа к конфиденциальным данным относительно своей компании, чем он имеется у секретаря приёмной. Сама защита чувствительных/ конфиденциальных данных зависит не только от установленной защиты инфраструктуры идентификации, но также зависит и от людей.

Rebeladmin Inc. является поставщиком управляемого обслуживания. Она имеет команду продаж из 10 представителей. Das выступает участником команды продаж. Все в этой команде продаж обладают доступом к некому совместному файловому ресурсу. Доступ к таким совместным файловым ресурсам управляется полномочиями NTFS. В таком разделяемом файловом ресурсе имеется некий файл Excel, которые потенциально содержат записи для всех потенциальных лидеров продаж той команды, в которой они работают. В точности как и все прочие участники команды, Das также имеет к нему доступ. Данные из этого файла очень чувствительны для бизнеса. Один из приятелей Das также работает над предоставлением управляемой службы и Das желает поделиться этим файлом со своим другом. Поскольку он имеет доступ к этому файлу, ничто не препятствует ему отправить его по электронной почте своему другу или скопировать его на USB устройство. В данном примере Das не имеет никакого привилегированного доступа, так как он не ИТ администратор. Ему не придётся взламывать чью- то ещё учётную запись или систему для получения этих сведений. В этом контексте он был бы способен он имел бы возможность нанести большой вред своей компании. Итак, как мы можем защищать чувствительные данные?

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

Прежде чем защищать данные, нам требуется понимать какой вид данных нам требуется защищать и где они расположены. Для классификации данных AIP применяет метки (labels).

Моей дочери Salena сейчас 2 года. Она любит читать. Время от времени я беру её в библиотеку чтобы выбирать для ней книги. Когда она выбирает книги, она в основном смотрит на заголовки книг и помечает их. Такая метка ничто иное как просто цветовой код. Этот цветовой код относится к Оксфордовским уровням читателя. Каждый уровень имеет свой собственный цвет:

Она знает свой уровень и значение цветового кода для него. Поэтому без того чтобы переходить к самому содержимому, она запросто способна отыскать ту книгу, которая соответствует её уровню чтения. Кроме того, детский раздел в нашей библиотеке слегка беспорядочен, так как дети не возвращают книги на правильные полки, благодаря меткам она всё же в состоянии распознавать правильные книги. Классификация данных в AIP работает точно так же. В AIP мы можем создавать метки и применять их для разбиения на категории/ группировки данных. После того как метки созданы, мы можем применять их к данным используя ручной или автоматический методы. При ручных методах, нам приходится переходить к документам и помечать их в соответствии с надлежащей классификацией:

Когда же речь заходит об автоматическом методе, AIP позволяет нам выполнять классификацию на основании индивидуальных условий или предварительно заданных информационных видов, например, следующих:

Наш следующий пример показывает как имеющиеся правила автоматической классификации помечают документы на основании их содержимого:

Я уже написал несколько блог постов относительно классификации. Вы можете получить к ним доступ по следующим ссылкам:

В качестве технологии защиты AIP использует Azure RMS. Azure RMS является некой службой на основе облачного решения, которая использует идентификацию, шифрование и политики авторизации для защиты чувствительных данных по различным видам устройств (таким как ПК, ноутбуки, планшеты и мобильные телефоны). Он способен защищать данные также после того как они покидают локальное расположение в компании, а также способен защищать данные, хранимые в облаке, как если бы они хранились локально.

Azure RMS способен на следующее:

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

Помимо этого, AIP SDK позволяет людям строить свои собственные приложения с поддержкой Azure RMS.

Сопоставление Azure RMS и AD RMS

В Главе 14, Службы Управления правами Active Directory, мы изучали Azure RMS, а потому вы наверное уже можете начинать размышлять над тем, а почему бы нам не воспользоваться AD RMS для защиты данных, раз он делает почти то же самое. Тем не менее, существуют некоторые значительные отличия между этими двумя службами:

Как работает Azure RMS?

До сих пор мы обсуждали возможности AIP и Azure RMS. Но как это всё работает? Какие именно технологии стоят за этим? В данном разделе мы намерены рассмотреть это подробнее.

На неком верхнем уровне я бы объяснил процесс Azure RMS защиты документа следующим образом:

На верхнем уровне это звучит просто, но давайте пройдём данный процесс подробно с тем, чтобы мы смогли изучить стоящую за ним технологию.

Наилучшим способом понимания тех технологий, которые стоят за процессами шифрования и дешифрации состоит в проходе некого сценария. Andrew, некий потребитель Rebeladmin Inc., отправил документ с чувствительными сведениями другому потребителю, Selena. Он не желает чтобы кто- то ещё из его команды продаж имел его, поэтому он намерен применять AIP для защиты данного документа. Это самый первый раз, когда оба этих пользователя используют данное решение:

Так как это самый первый раз, когда Andrew и Selena используют данный AIP, им обоим требуется пройти через одноразовый процесс подготовки среды пользователя:

Это завершает процесс расшифровки, и в самом конце, Selena получила возможность открыть Защищённый документ. Этот предыдущий сценарий показал нам в точности то, что происходит за сценой когда мы защищаем и употребляем чувствительные сведения при помощи Azure RMS.

Сканер AIP

В некой гибридной облачной среде данные также хранятся и в локальных серверах. В основном, они запоминаются в совместных файловых ресурсах Microsoft. Данные к тому же могут быть доступны через локальные серверы SharePoint. Сканер AIP позволяет нам обнаруживать и применять те же самые метки, которые были заданы в политиках AIP для данных, сохранённых в совместно применяемых локальных файлах или серверах SharePoint:

Сканер AIP поступает как часть клиента AIP. Его можно выгрузить по ссылке. Сканер AIP применяет некую SQL базу данных для хранения самих настроек сканера. Сканер AIP проверяется самим арендатором AIP на защиту тех же самых типов данных.

Сканер AIP способен автоматически выявлять и классифицировать все данные в выбранном репозитории данных или запускаться в нём в режиме выявления и выдавать обратно отчёты проведённых поисков. Классификация данных через AIP сканер не выполняется в режиме реального времени, поэтому вам требуется принимать решение о том, насколько часто вы желаете запускать этот сканер.

Реализация AIP

Реализация AIP является обширной темой, которая выходит за рамки данной главы. Я написал серию блог постов охватывающих реализацию AIP, к которым можно получить доступ по следующим ссылкам:

Безопасность инфраструктуры AD является обширной темой для изложения в одной главе. Безопасность AD зависит не только от AD DC; она полагается на все уровни общей модели 7 уровней OSI. В самом начале этой главы мы изучили аутентификацию Kerberos и что в самом деле происходит за сценой когда некий пользователь пытается получить доступ к ресурсам в своей среде AD. Далее мы переместились к делегированию контроля полномочий, в котором мы изучили то, как делегировать полномочия пользователям, позволяя им выполнять лишь определённые административные задачи. После этого мы перешли к разделу атак передачи значения хэша (Pass-the-hash), где мы узнали об атаках передачи значения хэша.

Microsoft ввёл новые инструменты и свойства, которые могут применяться для предотвращения атак передачи значения хэша. Группа безопасности Защищённого пользователя, режим ограниченного RDP, политики аутентификации и Бункеры политик аутентификации это часть из этого. В данной главе мы изучили то как эти новые инструменты работают и как мы можем реализовывать их в своей среде AD. Далее мы перешли к администрированию JIT и JEA. Обе эти технологии могут применяться для управления привилегиями неким действенным и безопасным образом.

После этого мы изучили то, как мы можем защищать привилегированные идентификации в гибридных и исключительно облачных окружениях, применяя Azure AD PIM. В некой инфраструктуре , в то время как идентификация является очень дорогостоящим логическим элементом, это не единственная значимая сущность. Нам также требуется защищать в инфраструктуре чувствительные данные. В своём разделе AIP мы также изучили то как можно применять AIP для защиты чувствительных данных в некой гибридной среде.

В своей следующей главе мы рассмотрим управление AD при помощи PowerShell. Реализация JEA также будет рассмотрена как часть этого.