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

Улучшения AD DS можно обнаружить на уровнях функциональности его леса и домена. Обновление самой операционной системы или добавление контроллеров домена с запущенным Windows Server 2022 в некую имеющуюся инфраструктуру AD не служит автоматическому обновлению существующих уровней функциональности леса и домена. После того как списываются более старые Контроллеры домена, нам потребуется обновлять их вручную. Когда речь заходит об уровнях функциональности леса и домена, в Windows Server 2022 имеется большое отличие. Вплоть до выпуска Windows Server 2016 имелись новые уровни функциональности леса и домена. Однако начиная с Windows Server 2019 НЕТ никаких новых уровней функциональности леса или домена.

Самые последние уровни функциональности леса и домена, которые мы можем выбрать, всё ещё относятся к Windows Server 2016. Однако что это означает? Если улучшения связаны с функциональными уровнями леса и домена, означает ли это то, что в AD DS 2022 нет новых функций AD DS? Да, это так, в Windows Server 2022 нет новых никаких новых функциональных возможностей AD DS. В Windows Server 2019 в его схему было внесено незначительное изменение. А именно, в ней появился новый атрибут с названием msDS-preferredDataLocation, причём он может применяться для определения геолокации пользователя Microsoft 365. Кроме этого в AD 2019 также не было никаких изменений.

AD это самая широко применяемая служба каталога на существующем рынке. Она делает то что должна делать. Однако с годами изменились требования к управлению идентификацией. В качестве примера давайте возьмём подход с нулевым доверием. В самой первой главе я объяснял важность этой модели и то, как мы можем применять её для защиты идентификации. Микросегментация это практика, которая применяется в модели безопасности с нулевым доверием для создания небольших зон безопасности в большой сетевой среде. Для удовлетворения требований к управлению доступом в этих небольших зонах безопасности, мы можем вводить Контроллера домена AD с доступом только на чтение и поддерживать стандарты безопасности. Однако микросегментация должна выполняться на сетевом уровне. Кроме того, для предотвращения бокового смещения злоумышленников в рамках AD мы можем применять многоуровневую модель AD. Это не является функциональной возможностью AD; скорее, это способ управления привилегиями в некой настройке AD. Это можно осуществлять в любой версии AD. Доступ с наименьшими полномочиями также выступает ключевым требованием для обсуждаемой модели с нулевым доверием. Для обеспечения доступа с минимальными полномочиями мы можем применять основанное на времени членство в группах AD, делегирование учётной записи, Just-in-Time (JIT, точно по графику) и Just-Enough Administration (JEA, Минимально необходимого администрирования). За исключением участия в группах на основании времени (функциональная возможность AD DS 2016), все вышеперечисленные задачи могут выполняться при помощи более старых версий AD. Однако, чтобы управлять полным жизненным циклом идентификации и обладать законченным решением, нам всё ещё требуются такие инструменты/ службы как Microsoft Identity Manager (для PAM), Microsoft Defender for Identity (для отслеживания) и Microsoft Defender for Endpoint (для управления угрозами устройством конечного пользователя). Как мы видим, AD уже достаточно зрелый для удовлетворения части современных требований, но не всеми ими. Мы должны понимать, что наличие многофункционального продукта не решает все наши проблемы. Скорее, всё зависит от того, как мы его конфигурируем и как мы его применяем. Именно на этом мы и сосредоточимся в данной книге. Несмотря на то, что у нас для изучения в AD DS 2022 нет никаких новых функциональных возможностей, мы намерены изучить имеющиеся в настоящее время возможности AD и рассмотреть насколько они соответствуют требованиям управления доступом в наши дни. Давайте продолжим рассматривать некоторые функциональные возможности, которые появились в AD DS 2016 и которые также имеются и в AD DS 2022.

Windows Server 2003 больше не поддерживается Microsoft.

Уровни функциональности леса и домена Windows Server 2003 были признаны устаревшими в Windows Server 2022. То же самое произошло уже в Windows Server 2012R2. Однако у вас имеется возможность добавлять в некий домен AD DS 2003 Контроллеры домена Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008. Тем не менее, Контроллеры домена Windows Server 2022 требуют как минимум уровня функциональности Windows Server 2008. Если вы рассматриваете миграцию с AD DS 2003, вам для начала требуется выполнить обновление по крайней мере до уровня функциональности Windows Server 2008, а затем добавлять контроллеры домена Windows Server 2022.

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

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

В 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 Server 2008, DFSR применялся для репликации имеющихся папок SYSVOL.

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

Начиная с Windows Server 2008R2 FRS была признана устаревшей и когда вы развёртываете некий новый домен с минимальным уровнем функциональности леса и домена Windows Server 2008, по умолчанию для репликации SYSVOL будет применяться DFRS. Когда вы выполняете миграцию из среды домена Windows Server 2003, также требуется миграция FRS в DFSR. Контроллеры домена Windows Server 2022 могут добавляться лишь в среду AD, применяющую репликацию DFSR для SYSVOL. Все шаги миграции с FRS на DFSR были рассмотрены в одном из моих предыдущих блог постов, доступ к которому можно получить по следующей ссылке https://bit.ly/3q4Re7E.

В большинстве банков имеется служба депозитных ячеек. Сейф это безопасное место, в котором вы можете хранить очень ценные вещи. После того, как вы приняли решение защищать что- то, вы можете положить это в свой сейф (депозитную ячейку) в банке, располагающийся в надёжно защищаемом помещении. Когда вы зарегистрируетесь в банковской службе, этот банк снабдит вас карточкой ключа, PIN- кодом или ключом для открытия вашей депозитной ячейки. Если вам потребуется получить доступ к своей депозитной ячейке, сначала вам потребуется прийти в соответствующую службу чтобы доказать кто вы такой. После успешной проверки вам будет разрешён доступ к вашей депозитной ячейке. В этом помещении могут располагаться тысячи различных депозитных ячеек с большим числом ценных активов, но ваш ключ предоставит вам доступ лишь к той ячейке, которая принадлежит вам. Однако представьте себе, если бы существовал какой- то мастер- ключ, который был бы способен открывать все депозитные ячейки в этом помещении. Какой ключ более ценен для вора? Ваш ключ, или мастер ключ, который обладает "полномочиями" для открытия всех имеющихся депозитных ячеек? Очевидно, им бы был мастер ключ. Именно это очень похоже на то, как работает привилегированный доступ в среде AD. В некой среде AD у нас имеются различные учётные записи с различными уровнями доступа к системам и данным. Имеющийся уровень доступа и полномочия могут отличаться от одной учётной записи к другой на основании её роли или подразделения. Однако имеются определённые учётные записи с "привилегиями", которые могут применяться для выполнения того что пожелает их пользователь внутри этой среды AD без каких бы то ни было ограничений. Великолепными примерами этого выступают Domain Admin или Enterprise Admin. Если некто обладает доступом к одной из подобных учётных записей, он/ она обладают полным контролем над всей имеющейся средой AD. Именно получение доступа к некой учётной записи проще и легче для атакующего, однако после первоначального взлома они пытаются сместиться вбок и получить доступ к "привилегированным" учётным записям. Основная роль решения PAM (Privileged Access Management, Управления привилегированным доступом) состоит в предотвращении атакующим получения доступа к привилегированным учётным записям даже когда они совершили первоначальный взлом.

PAM занимает видное место в современной сфере угроз. Centrify провела опрос 1000 руководителей ИТ служб в Великобритании и США. Согласно их отчёту, "74% респондентов, чьи организации подверглись взлому, признают, что это связано с доступом к привилегированной учётной записи". Отраслевой отчёт о поведении злоумышленников в выпуске RSA Conference Edition за 2020 год, основанный на данных, собранных с более чем пяти миллионов рабочих потоков и устройств в облачных решениях клиентов, центров обработки данных и корпоративных сред, показал, что во всех отраслях на каждые 10 000 обнаружены 215 привилегированных атакующих. В нём также сообщается, что финансовые и страховые, медицинские, а также образовательные организации демонстрируют наибольшие аномалии поведения привилегированного доступа. Именно на эти три отрасли приходится 47% всех выявленных аномалий привилегированного доступа. Основываясь на своих данных, RSA также наблюдала 112 вариантов поведения при боковом смещении на каждые 10 000 хостов. Все эти сведения подтверждают резкое увеличение доступа злоумышленников к привилегированным учётным записям. Приведённые выше результаты подчёркивают важность PAM при борьбе с киберпреступниками.

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

Когда мы рассматриваем безопасность привилегированного доступа, нам необходимо сосредоточиться на двух моментах:

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

Прежде всего, PAM это не некая часть программного обеспечения, которое мы можем просто установить и покончить с этим. Это сочетание множества моментов. Прежде чем мы представим PAM в среде AD, нам требуется возвести некие основы, которые будут позднее рассмотрены в данном разделе. Что ещё более важно, PAM изменяет см способ работы с привилегированным доступом. Заменить некий продукт не сложно, однако изменить процесс сложнее и труднее.

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

Некоторые совместно работающие пользователи даже запускали свои сайты и рабочие нагрузки без какой бы то ни было защиты (даже когда были осведомлены относительно неё). Однако время шло, год за годом, общее число попыток впечатляюще росло, и мы начали говорить о сотнях и тысячах попыток в день. Согласно отчёту, выполненному в 2021 году Cybersecurity Ventures, происшествия с кибератаками происходят каждый 11 секунд. Это почти удваивающаяся скорость с 2019 (каждые 19 секунд) и в четыре раза больше чем было в 2016 (каждые 40 секунд). В Обзоре нарушений кибербезопасности 2020 года, проведённом Министерством цифровых технологий, культуры, СМИ и спорта Великобритании, говорится "за последние 12 месяцев почти половина предприятий (46%) и четверть благотворительных организаций (26%) сообщали о взломах или атаках":

Изменились не только значения чисел, но и мотивы атак. Как я уже говорил, в давние времена ребяческие сценарии стремились снискать себе славу. Позже, когда пользователи начали применять всё больше и больше Интернет служб, сам фокус атак сместился на финансовую выгоду. Эти виды атак по- прежнему популярны. Согласно Отчёту о расследовании утечек за 2020 год Verizon, 86% взломов имели финансовую мотивацию (из 3950 взломов). Ещё в 2018 году это было 76%.

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

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

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

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

Последние кибератаки

В июне 2019 года American Medical Collection Agency (AMCA) подверглась взлому данных, выставившему персональные и платёжные сведения 20 миллионов пациентов после того как злоумышленники взломали их портал платежей. Эти злоумышленники выставили такие персональные данные, как имена, даты рождения, адреса, номера телефонов, даты обслуживания, поставщиков услуг, сведения о балансе, а также подробности учётных данных кредитной карты/ банка. AMCA позднее заявила о банкротстве, поскольку этот взлом привёл как к финансовым, так и к юридическим проблемам.

В августе 2019 года, Capital One, один из крупнейших банковских институтов США, подвергся взлому данных, выставив персональные данные более чем 106 миллионов заявителей кредитных карт между 2005 и 2019 годами.

В январе 2020, Travelex, базирующаяся в Лондоне компания по обмену валют, испытала вымогательскую атаку со стороны группы Sodinokibi. Travelex вела переговоры с этой группой, но отказалась платить вымогательский выкуп в размере 6 миллионов долларов в обмен на ключи. Злоумышленники пригрозили опубликовать 5ГБ персональных данных клиентов, которые были украдены до шифрования.

В мае 2020 года была взломана бюджетная авиакомпания EasyJet, что оказало воздействие на 9 миллионов клиентов и выставило подробности о более чем 2 000 кредитных и дебетовых карт. EasyJet сообщила, что злоумышленники получили доступ и похитили подробности адресов электронной почты и путешествий клиентов.

В июне 2020 года подвергся вымогательской атаке Калифорнийский университет. Она оказала воздействие на исследовательские данные COVID-19 Медицинской школы университета и этот университет выплатил около 1 миллиона долларов для возврата доступа к этим сведениям.

В августе 2020 года вымогательская группа Maze опубликовала 50 ГБ данных, похищенных из международной сети LG. Они также опубликовали 25.8ГБ данных, относящихся к сети Xerox.

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

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

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

Согласно тенденциям уязвимостей безопасности NIST в отчёте за 2020 год, за последние 3 года наблюдается рост величины числа уязвимостей низкой сложности. В 2020 году 63% фигурировавших в отчётах уязвимостей обладали низкой сложностью. Низкая сложность означает, что такой уязвимостью может воспользоваться злоумышленник с невысоким уровнем технических навыков. Это доказывает, что злоумышленники всё ещё срывают низко висящие плоды:

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

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

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

Типичная атака на AD

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

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

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

Согласно Отчёту о расследовании утечки данных Verizon, 20% взломов основываются на фишинговых атаках. Согласно результатам Обзора нарушений кибербезопасности 2020, выполненного министерством цифровых технологий, культуры, СМИ и спорта Великобритании, 86% предприятий подвергаются фишинговым атакам. Как правило, кто- то натыкается на фишинговое письмо и нажимает на него. Затем, когда злоумышленник получает некий доступ к вашей инфраструктуре идентификации, следующим для него шагом будет смещение в сторону для обретения бо́льших полномочий. Кто из вас полностью удалил учётные записи локальных администраторов в своей инфраструктуре? Я уверен, что ответом будет - почти никто. Пользователи часто просят об установке программного обеспечения и изменениях системного уровня в своих системах и в большинстве случаев инженеры назначают в конечном итоге права локального администратора. Когда скомпрометированная учётная запись является локальным администратором, становится просто перейти на следующий уровень.

Когда скомпрометированная учётная запись утрачивает доступ локального администратора, тогда злоумышленник заставит скомпрометированную систему вести себя неправильно. Итак, кто же придёт на помощь? Ну, естественно, ИТ супергерои из службы поддержки. В большинстве организаций инженеры службы технической поддержки являются 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. Как я уже упоминал в самом начале этой главы, он не является единым продуктом; это некий рабочий процесс и какой- то новый вид работы. Основные шаги и составляющие этого процесса таковы: