Глава 2. Службы домена Active Directory 2019

Улучшения AD DS применяются к уровням функциональности его леса и домена. Обновление самой операционной системы или добавление контроллеров домена с запущенным Windows Server 2016 в некую имеющуюся инфраструктуру AD само по себе не имеет целью обновление существующих уровней функциональности леса и домена. Чтобы применить или проверить такие новые свойства AD DS 2016, вам необходимо иметь установленными уровни функциональности имеющихся леса и домена в Windows Server 2016. Значение минимальных уровней функциональности леса и домена которые вы можете исполнять в своей инфраструктуре идентификации зависит от значения версии самого старого запущенного вами контроллера домена.

Например, если у вас имеется в вашей инфраструктуре контроллер домена Windows Server 2008, даже если вы добавили некий контроллер домена Windows Server 2016, значение уровней функциональности леса и контроллера, которые требуется поддерживать в виде Windows Server 2008, пока не будет смещён из этой инфраструктуры самый последний контроллер Windows Server 2008.

Windows Server 2003 больше не поддерживается Microsoft. При общении с пользователями я всё ещё встречаюсь с организациями (включая банки, розничную продажу и фармацевтические компании), которые применяют Server 2003 в своих промышленных сетевых средах. Имеются достаточные причины для обновления с Server 2003. То же самое остаётся верным и для AD DS. Порой не просто выполнить обновление с одной версии на другую, в особенности в условиях ограниченного бюджета. Однако всегда важно оценивать тот риск, с которым сталкивается предприятие без обновления. Нам требуется быть внимательным к защите правильных моментов в верное время.

Уровни функциональности леса и домена Windows Server 2003 были признаны устаревшими в Windows Server 2016. То же самое произошло уже в Windows Server 2012R2; когда вы создаёте некий новый домен, вы больше не можете ни коим образом применять уровни функциональности леса и домена Windows Server 2003. Приводимый ниже снимок экрана отображает все доступные уровни функциональности леса для Windows Server 2016:

Приводимый далее снимок экрана отображает все доступные для Windows Server 2016 уровни функциональности домена:

Если ваш домен был первоначально создан с применением Windows Server 2003, а вам требуется выполнить миграцию в Windows Server 2016, вы всё ещё способны сделать это. Вы можете добавить некий контроллер с Windows Server 2016 и выполнить между ними миграцию имеющихся ролей FSMO (flexible single master operations, гибких операций с единственным хозяином). В некоторых документациях я наблюдал что люди постулируют что невозможно выполнить миграцию с 2003 на 2016 непосредственно, но это не так.

В Windows Server 2000 Microsoft ввёл свою FRS (File Replication Service, Службу репликации файла); она применялась для репликации имеющейся папки AD SYSVOL.

FRS имел множество проблем когда дело доходило до репликаций, в особенности в связи с производительностью. FRS всегда реплицирует весь файл целиком, вне зависимости от вида предпринимаемых нами изменений. Именно это сос авляет проблему для площадок AD, подключаемых медленными соединениями WAN. FRS не обладает поддержкой API или WMI (Windows Management Instrumentation, Инструментального управления Windows), которые могут применяться для отслеживания производительности. Он также не поддерживает механизмов отчётов о жизнеспособности. В Windows Server 2003 R2 FRS был заменён на DFSR ( Distributed File System Replication, репликацию распределённой файловой системой), а начиная с Windows ServFer 2008, DFSR применялся для репликации имеющихся папок SYSVOL.

DFSR поддерживает частичный файловый обмен (на уровне блоков) репликациями вместо файлов целиком. Это привело к более быстрой репликации и оптимизации использования полосы пропускания между площадками AD, объединяемыми подключениями WAN. Это также поддерживает сжатие файлов на уровне типов файлов. Общее число файлов доступных для обмена (как во входящем, так и в исходящем потоках) было увеличено по сравнению с FRS. DFSR к тому же имеет механизм самоизлечения в случае паролем файловой системы.

Начиная с Windows Server 2008R2 FRS была признана устаревшей и когда вы развёртываете некий новый домен с минимальным уровнем функциональности леса и домена Windows Server 2008, по умолчанию для репликации SYSVOL будет применяться DFRS. Когда вы выполняете миграцию из среды домена Windows Server 2003, миграция FRS в DFSR будет выполняться вручную. Именно это является тем шагом, о котором забывает большинство инженеров при осуществлении своей миграции с более старых версий. Признание FRS остаётся в силе и для Windows Server 2016. Все шаги миграции с FRS на DFSR работают точно так же и будут пояснены в Главе 11, Службы Active Directory. В своём следующем разделе мы намерены рассмотреть наиболее важные улучшения в AD 2016.

PAM был одной из самых обсуждаемых тем в презентациях, технических показах, ИТ форумах, блогах и встречах за последние несколько лет (начиная с 2014). Он стал некой направляющей темой, в особенности начиная с предварительных выпусков Windows Server 2016. В 2016 я оказался вовлечённым во множество презентаций и обсуждений относительно PAM.

Прежде всего это не какое- то свойство, которое вы способны включить несколькими кликами. Это сочетание множества технологий и методологий, которые поступают совместно и создают некий рабочий поток или, иными словами, некий способ жизни для администраторов. AD DS 2016 содержит свойства и возможности поддержки PAM, но он также требует и MIM (Microsoft Identity Manager, диспетчера идентификации Microsoft). Замена продукта простая, однако изменение процесса более сложно и сопряжено с трудностями. Именно это один из самых крупных вызовов с которым вы столкнётесь когда начнёте осваивать этот новый способ образа мыслей и работы.

Я начал свою карьеру в 2003 водной из самых крупных Североамериканских компаний хостинга. В то время я был системным администратором и одной из моих задач было выявление попыток взлома идентификации и предотвращение рабочих процессов, которые могли быть скомпрометированными. Для выполнения этого мне приходилось просматривать большое число журналов регистрации различных систем. Однако примерно в это время все попытки большинства атакующих со стороны индивидуалов или групп состояли в том чтобы помещать свои имена в вебсайтах чтобы доказывать что они могут вызывать разрушения. Среднее ежедневное число попыток взлома на сервер составляло от 20 до 50. Некоторые совместно работающие пользователи даже запускали свои сайты и рабочие нагрузки без какой бы то ни было защиты (даже когда были осведомлены относительно неё). Однако время шло, год за годом, общее число попыток впечатляюще росло, и мы начали говорить о сотнях и тысячах попыток в день. Приводимый ниже график взят из последнего Отчёта угроз безопасности Интернета Symantec (2018) и он подтверждает что общее число веб атак каждый месяц растёт в миллионах:

Наш предыдущий график доступен на странице 65 отчёта.

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

При рассмотрении самого прогресса угроз, начиная с 2012 года изменился ряд вещей. Вместо славы или финансовой выгоды атакующие начали иметь целью идентификацию. В самые ранние дни сведения о некой персоне хранились в различных форматах. К примеру, когда я приходил в свой медицинский центр 15 лет назад, прежде чем я увижу своего врача, соответствующему сотруднику медицинского персонала приходилось отыскивать сам файл с моим именем на нём. Они имели большое число стоек, заполненных файлами и документами, которые содержали записи о пациентах, историю обращений, отчёты об анализах и многое другое. Однако теперь вещи изменились: когда я прихожу в соответствующий центр, никто в администрации не должен беспокоиться о моём файле. Сам доктор может просмотреть все мои записи со своего компьютерного экрана всего лишь за несколько кликов. В наши дни данные преобразовались в некий цифровой формат; всё больше и больше сведений о людях преобразуется в цифровой вид. В таких системах обеспечения здоровья я превращаюсь в некую идентичность, причём моя идентификация присоединяется к данным, а также к определённым привилегиям. Рассмотрим вашу интернет банковскую систему; вы получили своё собственное имя пользователя и пароль для их набора при вашей регистрации в соответствующем портале. Это означает, что вы имеете собственную идентификацию в соответствующей банковской системе; после того как вы регистрируетесь, вы получаете доступ ко всем своим счетам, денежным переводам, выполнению платежей и прочему. Ваш банк предоставляет некие привилегии вашей идентификации. Имя собственные привилегии вы не способны заглянуть также и в свои счета соседнего банка. Однако менеджер вашего банка способен просматривать также и счета ваших соседних банков также. Это означает, что значения привилегий, подключённых управляющему идентификацией банка иные. Общий объём извлекаемых из конкретной системы данных зависит от идентификации и привилегий.

Дополнительно к этому, некоторые из подобных идентификаций интегрированы во множество систем. Отрасли применяют различные системы для различных действий; например, системы электронной почты, системы CMS или биллинговые системы. Все эти системы содержат данные. Чтобы делать операции более гладкими, эти системы могут быть интегрированы с одной инфраструктурой идентификации, например, Microsoft AD. Это позволит пользователям иметь единую практику подписи вместо применения различных идентификаций для всех и каждого из приложений. Это делает идентификацию всё более и более мощной в рамках любой системы. С точки зрения злоумышленника, задумайтесь, что будет дороже - сосредоточиться на одной системе или иметь целью личность, привязанную к данным и привилегиям в различных системах? Что из этого принесёт больший ущерб?

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

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

Прошло несколько лет с последних президентских выборов в США и теперь мы можем наблюдать как много новостей можно создавать при помощи всего лишь одного твита. Нет необходимости иметь особые привилегии для постов в твите; именно сама личность делает этот твит важным. С другой стороны, если такая учётная запись в Твите была взломана, и некто опубликовал фальшивый твит поддельного лица от имени той персоны, которому он принадлежит, какой ущерб это может причинить всему миру? Следует ли для этого взломать учётную запись Джека Дорси? Значение персональной идентификационной записи является более мощным нежели CEO Твиттера.

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

Наш предыдущий график доступен на странице 53 отчёта.

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

Наш предыдущий график доступен на странице 49 отчёта.

В декабре 2015 года было всего лишь 15 происшествий, но было раскрыто 195 миллионов идентификационных записей. Это отражает какой ущерб могут приносить такие виды атак.

Всякий раз, когда происходят атаки такого типа, наиболее распространённый ответ инженеров содержит: "Эти атаки были чересчур сложными!"; "Их было слишком сложно выявить!"; "Они были слишком изощрёнными!"; "Это была атака нулевого дня!" и тому подобное. Но так ли это на самом деле?

Отчёт Microsoft Security Intelligence Report Volume 21 (January through June 2016) содержит такой график, который поясняет сложность подобных уязвимостей. Он ясно показывает, что основную часть уязвимостей всё ещё сложны для выявления. Уязвимости с высокой сложностью по- прежнему составляют менее 5% от общего числа раскрытых уязвимостей. Это доказывает, что злоумышленники всё ещё сбивают низко висящие плоды:

Наш предыдущий график доступен на странице 46 отчёта.

Microsoft AD является лидером в предоставлении решений идентификации и управления доступом. Во всех этих постоянных новостях относительно брешей в идентификации Microsoft AD также возникает. Что интересно, так это то, что люди начинают задаваться вопросом почему Microsoft не может всё это исправить. Но если мы оценим данные проблемы, станет очевидным, что для решения таких проблем недостаточно предоставить некий насыщенный технологиями продукт. В каждой новой версии ОС сервера Microsoft выпускает и новую редакцию AD. В каждой новой редакции присутствуют свойства улучшения безопасности инфраструктуры идентификации. Тем не менее, когда я приступаю к работе над неким проектом AD, я обнаруживаю, что большинство инженеров даже не следуют рекомендациям по безопасности, которые были определены выпущенными 10 лет назад версиями AD!

Давайте рассмотрим автомобильные гонки: гоночные категории, как правило, основываются на объёме двигателя; к примеру, 3 литра, 5 литров и тому подобное. В большинстве случаев в гонках одни и те же модели одного и того же производителя совместно участвуют в гонках. Раз это один и тот же производитель и раз у них одна и та же мощность двигателя, как же один водитель выигрывает, а другой проигрывает? Что же, именно тюнинг автомобиля и навыки водителя определяют победителя. Если AD DS 2016 способен исправить все угрозы идентификации, это на самом деле неплохо, однако только предоставление продукта и технологии, похоже, пока не срабатывает. Вот почему требуется изменить сам наш подход к безопасности инфраструктуры идентификации. Мы не должны забывать о том, что мы боремся с противниками- людьми - тактика, методы и подходы, применяемые ими меняются ежедневно. Используемые нами продукты не имеют такой частоты обновлений, однако мы способны изменять их возможности выполнять атаку на свою инфраструктуру понимая её основы и применяя продукты, технологии и рабочие процессы для предотвращения этого.

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

Имеющаяся многоуровневая модель администрирования Microsoft основывается на трёх уровнях. Все подобные атаки на идентификацию начинаются с получения некого вида доступа к имеющейся инфраструктуре идентификации и последующем перемещении в сторону, пока они не получат ключи от всего царства, то есть учётные данные администратора Домена или Предприятия (Domain или Enterprise Admin). После этого они получают полное владение над всей инфраструктурой идентификации.

Как показывает предыдущая схема,самый первый этап в атаке на идентификацию состоит в получении какого- либо доступа к системе. Вначале они не имеют целью получить учётные данные Domain Admin или Enterprise Admin. Получение доступа к учётной записи обычного пользователя намного проще чем к учётной записи Domain Admin; всё что им требуется, это некая разновидность берегового плацдарма. Для этого, даже сейчас, основная масса распространённых технологий атак состоит в отправке фишинговых электронных писем. Как правило, кто- то всё- таки попадается на них и кликает по ним. Далее, когда они получают некий вид доступа к вашей инфраструктуре идентификации, следующий этап состоит в продвижении в сторону для получения больших полномочий. Кто из вас полностью удалил учётные записи локальных администраторов в своей инфраструктуре? Я уверен, что ответ будет почти никто. Пользователи часто просят об установке программного обеспечения и изменениях системного уровня в своих системах и в большинстве случаев инженеры назначают в конечном итоге права локального администратора. Когда скомпрометированная учётная запись является локальным администратором, становится не сложным перейти на следующий уровень.

Раз это не так, тогда злоумышленник заставит скомпрометированную систему вести себя неправильно. Итак, кто же придёт на помощь? Ну, естественно, ИТ супергерои из службы поддержки. В большинстве организаций инженеры службы технической поддержки являются Domain Admin (Администраторами Доменов). Если это не так, они, по крайней мере, локальные администраторы в системах. А потому, как только они получают вызов по поводу ненадлежащей работы компьютера, они применяют протокол RDP (Remote Desktop Protocol, удалённого рабочего места) или зарегистрируются в локально с применением привилегированной учётной записи. RDP всегда отправляет ваши полномочия открытым текстом. Когда злоумышленник запускает некий инструмент сбора паролей, достаточно просто перехватить такие полномочия. Вы можете удивиться, как скомпрометированная учётная запись обычного пользователя способны выполнять подобные программы. Что ж, бывает и так, что операционные системы Windows не мешают пользователю запускать в собственном контексте подобные программы. Они не позволяют пользователю на своём уровне изменять какие бы то ни было настройки на уровне системы, но они всё равно дают возможность пользователю запускать сценарии или исполняемые файлы уровня пользователя:

После того как злоумышленник получит доступ к некой идентификации в организации, следующим уровнем привилегий, которым он будет обладать, будет Уровень 1. Именно здесь обитают учётные записи Администратора, Администратора данных и администратора приложений SaaS. В типичной современной инфраструктуре у нас имеется слишком много администраторов. Прежде всего у нас имеются Администраторы Домена и Администраторы Предприятия. Различные выполняющиеся в нашей инфраструктуре приложения имеют своих собственных администраторов, например, Администраторов Exchange, Администраторов SQL и Администраторов SharePoint. Прочие приложения сторонних разработчиков, такие как CMS и порталы биллинга, могут иметь своих собственных администраторов. А потому на самом ли деле мы осведомлены обо всех активностях, происходящих от имени этих учётных записей? В основном инженеры беспокоятся лишь относительно защиты учётных записей Администратора Домена, однако в то же самое время забывают о прочих видах администраторов в своей инфраструктуре. Некоторые из таких ролей администраторов могут вызывать большие разрушения в бизнесе чем какой- то Администратор Домена. Такие приложения и службы рассредотачивают управление в вашей организации. Чтобы выполнить боковое перемещение по полномочиям, таким злоумышленникам требуется зарегистрироваться в некой машине или сервере, в которых регистрируются сами администраторы. LSASS (Local Security Authority Subsystem Service, Служба подсистемы локального управления безопасностью) хранит учётные данные в своей памяти для активных сеансов Windows. Это позволяет избежать хлопот пользователей по вводу учётных данных для каждой службы, к которой они получают доступ. Она также хранит маркеры (tickets) Kerberos. Это делает возможным для злоумышленников выполнять атаку передачи хэш- значения (pass- the- hash) и получить локально сохранённые учётные данные. Децентрализованное управление учётными данными упрощает такой процесс.

Другой проблемой для таких видов учётных записей является то, что после того как они становятся учётными записями администратора службы, они способны в конечном счёте становиться учётными записями Domain Admin или Enterprise Admin. Я наблюдал инженеров, создающих учётные записи службы и, когда они не способны выяснить какие в точности полномочия им требуются для конкретной программы, добавляют их в группу Domain Admin, в качестве самого простого способа исправления этой ситуации. Тем не менее, не только атаки на инфраструктуру способны раскрывать подобные учётные записи. Администраторы службы также подключены к своему приложению, а потому компрометация самого приложения также способна раскрывать идентификационные данные.

При подобном сценарии злоумышленнику будет просто получить все ключи в наивысшее царство:

Уровень 0 является тем, где работают Domain Admin и Enterprise Admin. Именно он является конечной целью некой атаки на инфраструктуры идентификации; после того как злоумышленник получают доступ к Уровню 0, они овладевают всей инфраструктурой идентификации. Последние отчёты показывают, что после первоначального взлома, получение привилегий Уровня 0 требует менее 48 часов. Согласно этим сообщениям, после того как злоумышленники получают доступ, для выявления такого взлома потребуется не менее 7-8 месяцев. Это связано с тем, что получая максимальные права, они всегда могут в случае необходимости создавать чёрные ходы, очищать журналы и прятаться навсегда. Используемые нами системы всегда относятся к Администраторам как к заслуживающим доверия людям. В современном мире это уже не так; как часто вы проверяете свои системные журналы чтобы выявить что же делают ваши Администраторы Домена? Даже если инженеры просматривают журналы прочих пользователей, они редко проверяют учётные записи Администраторов Домена. То же самое относится и к внутренним нарушениям безопасности: как я уже сказал, большая часть людей добропорядочна, но вы никогда не знаете этого наверняка. Многие громкие атаки на идентификацию уже доказали это.

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

Ответом на все эти проблемы является PAM. Как я уже упоминал в самом начале этой главы, он не является одним продуктом%; это некий рабочий процесс и какой- то новый вид работы. Основные шаги и составляющие этого процесса таковы:

AD DS 2016 теперь позволяет участие в группе на основе времени, что делает возможным весь этот процесс. Некий пользователь добавляется в какую- то группу со значением времени жизни (TTL, time-to-live) и, когда оно истекает, такой пользователь автоматически удаляется из этой группы. Например, давайте предположим что ваше приложение CRM имеет административные права, назначаемые группе безопасности CRMAdmin. Все пользователи из этой группы регистрируются в этой группе лишь один раз в месяц чтобы выполнить некое сопровождение. Однако все административные права для участников в этой группе остаются нетронутыми в остающиеся 29 дней, 24/ 7. Это предоставляет существенные возможности для злоумышленников в попытках получать доступ к привилегированным учётным записям. Итак, если имеется возможность предоставления прав доступа на более короткий промежуток времени, не будет ли это более полезным? После этого мы можем гарантировать что для основного числа дней в месяце наше приложение CRM не работает с риском быть скомпрометированным некой учётной записью в имеющейся группе CRMAdmin.

Какая логика зиждется за PAM?

PAM основан на концепции администрирования JIT (just-in-time, точно в срок). Ещё в 2014 Microsoft выпустил инструментарий PowerShell, который делает возможным JEA (Just Enough Administration, в точности достаточное администрирование). Давайте предположим что вы запускаете в своей инфраструктуре некий веб сервер; как часть общей операции, вам требуется раз в месяц собирать некоторые журналы для выработки отчёта. Вы уже настроили сценарий PowerShell для этой цели. Кто- то в вашей системе должен войти в систему и запустить его. Для выполнения этого вам требуются административные привилегии. Применяя JEA, имеется возможность настроить необходимые полномочия определённому пользователю для исполнения только этой конкретной задачи. Тем самым нет необходимости добавлять данного пользователя в имеющуюся группу Администраторов Домена. Этому пользователю не будет дозволено запускать никакие иные программами с назначенными им полномочиями, причём они не будут применяться к любому другому компьютеру. Администрирование JIT ограничено во времени. Это означает, что пользователи будут иметь необходимые полномочия только тогда, когда они им требуются; они не будут иметь привилегированные права доступа постоянно.

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

Давайте рассмотрим эти четыре основных этапа:

Давайте испробуем как это работает в действительности:

Rebeladmin Corp. применяет в своей деятельности некую CRM систему. Данное приложение имеет соответствующую роль администратора и назначенную ей группу безопасности Rebeladmin/CRMAdmins. Любой участник этой группы будет иметь полномочия администратора для данного приложения. В недавнем времени для Rebeladmin Corp. была введена PAM. Пребывая в должности инженера, я идентифицировал группу Rebeladmin/CRMAdmins в качестве некой привилегированной группы, которую я намерен защищать при помощи PAM. Самый первый шаг состоит в удалении всех участников из данной группы Rebeladmin/CRMAdmins. После этого я настраиваю ту же самую группу в своём бастионном лесу. Причём это не просто то же самое название группы, но ещё и эта группа имеет то же самое значение SID: 1984.

В качестве участника группы Rebeladmin/CRMAdmins используется пользователь Dennis и он ежемесячно запускал отчёты. В конце одного из месяцев он пытается запустить его и обнаруживает, что он не обладает требуемыми полномочиями. Следующий необходимый для него этап состоит в запросе полномочий через имеющийся портал MIM.

Согласно установленной политике, в качестве части такого запроса, наша система желает чтобы Dennis применял MFA. После того как Dennis удостоверит значение PIN, его запрос будет зарегистрирован в данном портале. В качестве администратора я получаю уведомление относительно такого запроса и я регистрируюсь в системе для просмотра данного запроса. Это легитимный запрос, а потому я подтверждаю его доступ в систему на 8 часов. Затем наша система автоматически добавляет соответствующую учётную запись Dennis в настроенную группу Bastion/CRMAdmins. Эта группа имеет то же самое значение SID, что и имеющаяся в промышленной эксплуатации группа. Следовательно, некий участник группы Bastion/CRMAdmins будет рассматриваться как какой- то администратор нашего приложения CRM. К тому же, участник этой группы содержит также установленное значение TTL. После истечения подтверждённых 8 часов учётная запись Dennis будет автоматически удалена из нашей группы Bastion/CRMAdmins. При данном процессе мы не добавляем никаких участников в свою промышленную группу безопасности, которй является Rebeladmin/CRMAdmins. А потому наш промышленный лес стоит нетронутым и защищённым.

Самое важное что нам следует здесь уяснить, так это то, что унаследованный подход к защите идентификации более не действует. Мы поднялись против врагов в человеческом обличии. Идентичность - это наш новый периметр в имеющейся инфраструктуре и для его защиты нам следует понимать как наши враги его атакуют и при этом оставаться на шаге впереди. PAM в AD DS 2016 это новый подход в верном направлении.

В своём предыдущем разделе я исследовал свойства PAM в новом AD DS 2016. Участие в группах на основе временного интервала является частью этой обширной темы. Они позволяют администраторам назначать временное членство в группах, срок действия которого истекает по некому значению TTL. Это значение будет добавляться в выдаваемую квитанцию (ticket). Это имеет название свойства ссылок со сроком действия (expiring links). Когда некий пользователь назначается участником некой временной группы, его время жизни Kerberos TGT (ticket-granting ticket, мандат на выдачу квитанций) будет эквивалентно самому низшему имеющемуся у него значению TTL. Например, давайте предположим что вы предоставили временное участие в группе для пользователя A с тем, чтобы он состоял в имеющейся группе Администраторов Домена. Это допустимо всего лишь на протяжении 60 минут. Однако когда пользователь зарегистрируется через 50 минут после своего первоначального назначения, причём он имеет только 10 минут оставшимися на членство в данной группе Администраторов Домена. Основываясь на этом, действующий контроллер домена выпустит некий TGT, который действует для пользователя A лишь 10 минут.

Это свойство не включено по умолчанию. Основная причина для этого состоит в том, что уровень функциональности такого леса должен быть Windows Server 2016. Кроме того, после того как это свойство будет включено, оно не может быть отключено.

Давайте изучим как это работает в реальном мире:

После того как истечёт обновлённый период TGT, этот пользователь больше не будет участником группы Администраторов Домена.

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

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

При самом процессе настройки Паспорта Microsoft, будет вырабатываться некая новая пара ключей общедоступного и частного (public-private) и сохранять значение частного ключа в TPM (Trusted Platform Module, Доверительном модуле платформы). {Прим. пер.: системы с TPM на момент перевода запрещены к ввозу в РФ.} Когда ваше устройство не имеет TPM, они всё ещё будут сохраняться в самом программном обеспечении. Значение частного ключа будет оставаться в этом устройстве на протяжении всего времени. Значение же общедоступного ключа может быть сохранено в AD (локально) или в Azure AD (в облачном решении). AD DS 2016 поддерживает конфигурацию Паспорта Microsoft.

При данном процессе аутентификации с применением Пароля Microsoft, Наш пользователь вначале должен выполнить аутентификацию в своём устройстве при помощи Microsoft Hello. Далее этому пользователю требуется проверить свою личность при помощи MFA, смарт карт или жестов. Эти сведения будут переданы в AD. Затем ваше устройство выработает некий уникальный ключ, аттестует этот ключ, изолирует имеющуюся часть общедоступного ключа и отправит его в AD для регистрации. После того как AD DS зарегистрирует данный общедоступный ключ, оно будет запрашивать у устройства регистрацию при помощи имеющегося частного ключа. Когда устройство успешно зарегистрируется с применением частного ключа, AD DS проверит его и выработает значение маркера (token) аутентификации. Такой маркер позволит самому пользователю и его устройству использовать соответствующие ресурсы.

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

AD FS делает возможным совместное использование идентификации между имеющими доверие партнёрами по бизнесу (федерализованными) с минимальными изменениями инфраструктуры идентификации. AD FS 2016 добавил многие новые свойства для защиты федерализованных сред от возникновения угроз инфраструктуре идентификации. В Главе 13, Службы Федерализации Active Directory я подробно разьясню AD FS. Прямо теперь я намерен суммировать блестящие новые имеющиеся свойства.

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

Microsoft Azure предоставляет Azure MFA в качестве некой службы для защиты рабочих процессов в облаке от не авторизованного доступа. Если локальный AD федерализован с Azure AD, она также может применяться для защиты локальных рабочих потоков. AD FS 2016 поддерживает интеграцию с Azure MFA. Если вам требуется установить AD FS 2012 R2 и интегрировать его с Azure MFA, вам понадобится некий локальный сервер MFA. Для AD FS 2016 не требуются никакие дополнительные компоненты, поскольку он устанавливается со встроенным адаптером Azure MFA. Когда Azure MFA настроен в качестве первичной аутентификации, тогда самому пользователю требуется предоставить некое имя пользователя и OTP (one-time password, одноразовый пароль) от Azure Authenticator для аутентификации.

AD FS 2016 также поддерживает доступ без пароля для подходящих устройств. Это сочетается с политиками Условного Доступа (Conditional Access), которые являются другой крупной функциональностью AD FS 2016. Политики Условного Доступа Azure могут применяться в устройствах, которые зарегистрированы в Azure AD или Intune (неком корпоративном комплекте мобильности). AD FS 2016 позволяет нам использовать те же самые условные политики для управления доступом локальных ресурсов. Если же используемые устройства не управляемые или не совместимые, мы можем принудительно использовать MFA для доступа с применением политик.

AD FS 2016 также поддерживает доступ с использованием Microsoft Hello и Паспорта Microsoft. Применяя такие методы аутентификации, пользователи способны иметь доступ к защищённым AD FS рабочим процессам из некой интра сети или экстра сети.

Некоторые организации используют для работы не Microsoft службы каталога. AD FS 2016 теперь поддерживает каталоги на основании LDAP v3. Это делает для нас возможной федерализованную идентификацию между средами с AD и без AD. Это также позволяет предприятиям осуществлять федерализацию своих личностей со службами Azure даже когда они применяют службы каталога сторонних производителей.

В нашей предыдущей версии AD FS, когда вам требовалось обновить ей до самой последней версии, вам требовалось построить отдельную ферму AD FS и затем экспортировать/ импортировать имеющуюся конфигурацию. Однако в AD FS 2016 это больше не требуется. Вы можете представить некий сервер AD FS 2016 в существующей ферме AD FS 2012 R2. Затем он будет работать на уровне AD FS 2012 R2. После того как самый последний сервер AD FS 2012 R2 будет удалён из этой фермы, уровень функциональности такой фермы может быть повышен до AD FS 2016.

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

Все остальные расширения работы с AD FS будут подробно пояснены в Главе 13, Службы Федерализации Active Directory.

Для инфраструктур AD важна точность времени с тем чтобы сопровождать аутентификацию Kerberos между пользователями и контроллерами домена. В настоящее время точность между двумя частями должна быть менее 5 минут. В некой среде AD участники домена синхронизируют время с контроллерами домена (то есть PDC, Primary Domain Controller, некого контроллера домена в самом корне леса, либо контроллера домена с хорошим сервером времени (good time server или флагом GTIMESERV) для поддержания точности времени по всему окружению.

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

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

В Windows Server 2016, Microsoft выполнил определённые улучшения в вопросах точности синхронизации времени по инфраструктурам. Он улучшил алгоритмы, которые будут смягчать само воздействие точности данных NTP, приводящее в результате к сетевым заторам и сетевым задержкам. Он также применяет некие улучшения API для точных временных ссылок. Применяя данные улучшения он способен предоставлять точность времени в 1 микросекунду.

Служба синхронизации времени Hyper-V 2016 также была улучшена для предоставления точного времени виртуальным средам. Это предоставит изначально точное время для имеющихся VM (virtual machine, ВМ - виртуальных машин) для запуска и последующих коррекций для образцов W32Time. Это делает для нас возможным иметь временную точность, значение которой составляет лежит между 10 и 15 микросекундами.

В Windows Server 2016 также были реализованы новые счётчики отслеживания производительности для наблюдения и устранения неисправностей при проблемах с точностью времени в инфраструктурах.

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

Rebeladmin Corp. имеет два офиса - один офис расположен в Торонто, Канада, а другой размещается в Лондоне, Великобритания. В обоих имеются запущенными настольные компьютеры, виртуальные серверы и физические серверы. Все эти устройства уже подключены к своему домену AD. Даже имея два местоположения, он всё ещё сопровождает одну инфраструктуру идентификации. Когда устройства расположены в определённом физическом местоположении с надлежащей связью, их будет проще контролировать с применением групповых политик AD, сценариев регистрации, полномочий и прочим. Для управления устройствами они также используют SCCM (System Center Configuration Manager, Диспетчер настроек Системного центра). Это означает, что в фиксированных границах безопасности нам известно где располагаются наши устройства и пользователи. Хотя в такой настройке и нет ничего предосудительного, в современном мире люди больше не ограничены столом и стулом в офисе.

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

Подключение к Azure AD может помочь в обходе этих вызовов; применяя его мы можем сделать следующее:

В некой локальной среде AD у нас имеются различные типы объектов, такие как учётные записи пользователей, группы и устройства. Применяя AD мы способны управлять значением состояния этих объектов. Это может относиться к доступу, безопасности или управлению. Аналогично, Azure AD способен также управлять объектами только в облаке или в некой гибридной среде. Используя подключение к Azure AD, мы можем сместить контроль над такими объектами устройств в Azure AD. Давайте забежим вперёд и рассмотрим подробнее эти два метода.

Более года назад я хотел записать свою маленькую дочь, Селену, на уроки плавания, проходящие в моём местном оздоровительном центре. Когда я обратился с запросом относительно этого в приёмную, мне сказали что нет свободных мест. Однако мы получили возможность зарегистрироваться в листе ожидания. Это было связано с заполнением небольшой формы с какими- то основными подробностями, такими как имя, контактные сведения и предпочтительные даты. Зарегистрировавшись в их системе я стал некой личностью. Та заполненная мной форма содержала сведения, которые могут быть использованы для моей уникальной идентификации относительно прочих в том же самом списке. Они лишь предоставляли информацию, достаточную для того, чтобы контактировать со мной при доступности мест. Аналогично, регистрируя некое устройство в Azure AD, мы можем осуществить некую его идентификацию. Однако это даст Azure AD лишь частичный контроль. После регистрации данного устройства, Azure AD может разрешать/ запрещать данное устройство, перехватывать события подписи, а также собирать декларируемые сведения. ы также можем внести это устройство в список Microsoft Intune; это предоставит нам дополнительный контроль над таким устройством для сопровождения позиций и требований совместимости имеющейся политики безопасности организации.

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

Некое устройство Windows 10 может непосредственно регистрироваться в Azure AD. Это не требует никаких локальных компонентов предприятия. Это идеально для сред,которые пытаются снизить отпечаток в своём локальном представительстве. Это также хорошо работает в гибридных средах. Даже когда управление устройством перемещено в Azure AD, это устройство всё ещё бесшовно имеет доступ к приложениям и ресурсам в локальной инфраструктуре.

Мы можем зарегистрировать своё устройство применив:

Присоединённые к Azure AD устройства имеют следующие преимущества:

Как я уже упоминал ранее, присоединение к Azure AD идеально для тех организаций,у которых нет локального AD, либо они пытаются уйти прочь от локального AD. Если у вас имеется системы, работающие под управлением ОС более ранней чем Windows 10, и если вы всё ещё желаете применять функциональность Azure AD с минимальными организационными изменениями, вам требуется применять метод гибридного присоединения к Azure AD.

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

Устройства всё ещё будут частью своего локального домена и не будет никаких изменений в Wibdows 10:

Гибридное присоединение к Azure AD поддерживает широкий диапазон операционных систем. Основываясь на различиях в самом процессе регистрации, мы можем собрать эти операционные системы в две группы.

Текущие устройства Windows

Ниже приводятся текущие устройства Windows:

Применяя GPO (Group Policy Object, Объекты групповой политики) или SCCM мы можем заставлять текущие устройства автоматически регистрироваться в Azure AD. Применяя такой метод мы способны также контролировать какие устройства необходимо регистрировать в Azure AD. Соответствующий этап конфигурирования для этого будет пояснён более подробно в Главе 17, Гибридная установка Azure Active Directory.

Устройства Windows нижнего уровня

Вот устройства Windows нижнего уровня:

Прежде чем регистрировать устройства нижнего уровня, нам следует установить некий агент (https://www.microsoft.com/en-us/download/details.aspx?id=53554). Он может быть помещён в компьютеры при помощи SCCM или GPO. Мы также обсудим это в дальнейшем в Главе 17, Гибридная установка Azure Active Directory.

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

Вы можете задаться вопросом, зачем я добавил эту тему относительно гибридного присоединения к Azure AD в эту главу. Я согласен, что это не является функциональностью AD 2016. Однако локальный AD сам по себе не способен предоставлять ответы на сложные требования идентификации и управления доступом, которые имеет бизнес сегодняшнего дня. С каждым днём Azure AD становится всё более зрелым; он на постоянной основе предъявляет новые свойства. А потому у нас нет выбора обсуждать хорошие стороны обеих технологий чтобы решать свои требования. AD 2016 полностью поддерживает работу бок о бок с Azure AD и делает нашу инфраструктуру идентификации прочной, безопасной и наполненной функциями.

В этой главе мы рассмотрели те новые свойства и расширения, которые пришли вместе с AD DS 2016. Одним из крупнейших улучшений Microsoft был новый подход к управлению привилегированным доступом (PAM). Это не просто некая новая функциональность, которая может быть включена через AD DS, а это часть пограничного решения. Он помогает защищать инфраструктуру идентификации от новейших противников, поскольку традиционные методы и технологии более не действенны перед столкновением с возникающими угрозами. Мы также рассмотрели новые виды расширенных методов аутентификации, которые допускает AD DS. Типичная комбинация имени пользователя/ пароля является самым слабым вариантов при современных вызовах инфраструктуре безопасности. AD FS 2016 также имеет дополнительные расширения безопасности для защиты личности в некой федерализованной среде. Мы также изучили те улучшения, которые выполнены для синхронизации времени с целью поддержки точности времени по всему домену AD. Когда мы рассматриваем гибридные среды, присоединение к Azure AD способствует организации в регистрации подключённых к домену Azure AD и позволяет им применять свойства от обеих технологий. В этой главе мы изучили что представляет из себя присоединение к Azure AD и как оно работает с локальными AD.

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