Active Directory прошла длинный путь развития. В 2000 году, когда служба каталогов только появилась, самая идея безопасности определялась простым, но в то время эффективным принципом AGLP (Accounts, Global groups, Local groups, Permissions). Учетные записи помещались в глобальные группы, глобальные группы — в локальные, а локальным группам назначались разрешения.

Однако с появлением соединений через Интернет Active Directory (AD) и средства безопасности, необходимые для ее защиты, перестали быть исключительно локальными, вышли за рамки организации и сформировали среду AD, существующую как локально, так и в «облаке».

Это означает, что вам придется скорректировать подходы и методы, используемые для защиты гибридного экземпляра AD, одновременно осознавая, что в подлунном мире нет ничего по-настоящему нового.

Зачем беспокоиться о безопасности гибридной AD

Если в последнее время вы не скрывались в глухих лесах, то вас не удивит, что внедрение Office 365 происходит стремительными темпами. Благодаря преимуществам в первую очередь таких продуктов, как Exchange Online, OneDrive для бизнеса и Skype для бизнеса, у Office 365 появляется в среднем 1 млн новых подписчиков в месяц. Какое отношение это имеет к безопасности гибридной AD? Самое прямое.

Все эти превосходные продукты работают на базе столь же впечатляющей службы каталогов — Azure AD. Служба Azure AD (AAD) используется всеми приложениями Office 365 для проверки подлинности пользователей и играет роль центральной нервной системы Office 365.

Однако каждому экземпляру Office 365 требуется отдельный клиент AAD, и это порождает необходимость управлять еще одной средой, за которую отвечает ИТ-подразделение. Поэтому свыше 75% клиентов с более чем 500 сотрудниками, использующими Office 365, синхронизируют локальную службу каталога AD с Azure AD, чтобы обеспечить единую процедуру проверки подлинности, и таким образом создают среду гибридной службы каталога AD.

С помощью соединения Azure AD Connect компании интегрируют два каталога, обеспечивая синхронизацию двух сред и удобную возможность авторизовываться в Office 365 с использованием локальных учетных данных. Поскольку это односторонняя синхронизация с AAD, важно помнить, что содержимое AAD определяет локальная среда AD.

В результате локальная служба каталога AD становится центром для управления доступом, создания компенсационных элементов управления безопасностью и определения способов предоставления доступа в AAD и связанных приложениях.

И все же возникает вопрос, почему нам следует беспокоиться об AAD. На сегодня существует свыше 500 млн локальных учетных записей AD, охватывающих 90% работающих с AD компаний во всем мире.

По данным отчета 2016 Verizon Data Breach Investigations Report, почти две трети подтвержденных краж информации совершены с использованием учетных данных. Из этого следует, что AD — основная цель злоумышленников.

Но показатели AAD дают еще более веский повод для беспокойства:

  • существует 750 млн учетных записей AAD;
  • 110 000 приложений ежемесячно используют AAD;
  • ежегодно совершается 10 млрд проверок подлинности.

«Облачная» инфраструктура Micro­soft в целом (в том числе Office 365, Xbox, MS Live и другие) подвергается более чем 10 млн кибератак. Вывод очевиден: любой доступ, полученный через локальную AD, может не только иметь последствия внутри AAD, но и затрагивать любые веб-приложения, использующие AAD. Поэтому локальная служба каталога AD должна быть наделена элементами управления безопасностью, соответствующими имеющимся в экземпляре AAD, чтобы обеспечить защиту всей гибридной AD. Сделать это нелегко. Для надежной защиты гибридной AD необходимо ответить на несколько вопросов:

  • Что они могут сделать? В идеале нужно иметь возможность определить, какие пользователи имеют разрешения для внешних приложений и данных или даже кто имеет право, например, управлять паролями в масштабах всей AD.
  • Что они делают? Во многих случаях нет достаточных сведений или полностью отсутствует след для аудита, чтобы точно определить, что изменилось в данном приложении и самой AD.
  • Оправдан ли привилегированный доступ? Когда ИТ-специалисты обращаются к данным, к которым они не должны иметь доступа, кто должен контролировать наблюдателей? Группы, используемые для локального доступа к ресурсам, также могут предоставлять доступ к «облачным» ресурсам.
  • Повлияют ли изменения на непрерывность бизнеса? Простое ошибочное изменение в локальной службе каталога AD распространится по всей AD и попадет в AAD, затрудняя восстановление (например, портится схема леса).

Чтобы устранить эти проблемы и помочь обеспечить безопасность гибридной AD, необходимо вернуться к исходной точке — вашей локальной службе каталога AD — и разместить элементы управления, которые повышают безопасность не только AD, но и AAD, данных, приложений и систем, работающих с AAD.

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

Что они могут сделать?

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

Кто такие «они»? Привилеги­ро­ванные ИТ-пользователи? Прило­жения или владельцы бизнеса? Пользователи начального уровня? На что обратить внимание, оценивая текущее состояние безопасности?

Если вы следите за отчетами Data Breach Investigation Reports, ежегодно выпускаемыми компанией Verizon, то знаете, что все случаи злоупотребления привилегиями (с участием как кибервзломщиков, овладевших ценными учетными данными, так и работников предприятия) распределяются между ролями внутри организации следующим образом (Verizon, Отчет Data Breach Investigations Report (2016)):

  • 14% — руководители и менеджеры высшего звена;
  • 14% — привилегированные пользователи (сотрудники ИТ-отделов и пользователи с повышенными правами);
  • 72% — обычные пользователи.

Из этих данных видно, что «они» могут быть кем угодно, поэтому следует в большей степени сосредоточиться на назначенных разрешениях, нежели на ролях. Итак, идет ли речь о разрешениях внутри AD (и следовательно, AAD)? Одним словом — нет.

Ваша гибридная AD служит фундаментом для доступа к приложениям, системам и данным как локально, так и в Azure (то есть к приложениям Office 365 и приложениям Azure). Например, пользователь начального уровня из финансового отдела может отвечать за сайт SharePoint Online подразделения, где хранятся конфиденциальные финансовые отчеты и данные. Если соответствующая учетная запись скомпрометирована, взломщик может потенциально получить доступ к информации, в разглашении которой организация определенно не заинтересована. Поэтому нужно знать, насколько это возможно, какие разрешения назначены пользователям AD и группам.

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

Трудность заключается в том, что никакие внешние разрешения, назначенные данному объекту AD, не хранятся в самом объекте. В сущности, вам нужно обратиться к приложению или системе и выяснить, как настроены параметры безопасности. Учитывая огромное количество систем, находящихся в вашем распоряжении, задача принимает угрожающие размеры. Как минимум, вы имеете дело с разрешениями собственно в AD, общих папках, файловых системах NTFS, базах данных SQL Server, Exchange и EOL, SharePoint и SPOL, базах данных и приложениях собственной разработки. Кроме того, есть еще Office 365 и другие приложения, интегрированные с Azure.

В идеальном мире эти нужды были бы документированы. Хотелось бы, чтобы к объектам в AD была добавлена вкладка «Назначенные разрешения» и любая система, которая выбирает данный объект, добавляла бы запись в список; таким образом, было бы центральное место, где можно увидеть наличие разрешений у объекта. Конечно, существуют способы сделать это вручную через встроенную функцию подготовки отчетов на консоли управления данного приложения (в случае приложений Microsoft для такой цели всегда есть PowerShell).

В некоторых случаях, в частности для AD или почтовых ящиков Exchange, это сравнительно простая задача, решаемая с помощью одной команды (например, Get-Acl для AD и Get-MailboxPermission для Exchange). Для других приложений и служб (как локальных, так и в Office 365/Azure) требуются более сложные сценарии, которые мы не рассматриваем в данной статье.

Помните, что команды PowerShell в основном нацелены на объекты приложений. Вопрос звучит следующим образом: «Кто имеет права на данный объект?» Итак, вам нужно сначала найти способ перечислить с помощью PowerShell все объекты (например, папки в файловой системе, почтовые ящики в Exchange и т. д.), а затем извлечь разрешения.

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

Существуют и другие элементы, которые могут быть интегрированы с AD: приложения, разработанные самостоятельно или полученные от других компаний, кроме Microsoft, а также приложения на основе SaaS вне Azure и т. д. Воспользуйтесь встроенными функциями подготовки отчетов, чтобы определить, какие назначения были сделаны. Независимо от того, каким способом вы решили выяснить, какие разрешения имеет каждый пользователь в вашей организации, возможно, проблема в том, что вы рассматриваете разрешения только в определенный момент времени. Из отчета о текущем состоянии вы не узнаете, что кто-то получил полные права на сайте SharePoint Online финансового отдела на три дня, а затем был удален. Вы видите разрешения такими, какие они сегодня, когда соответствующий сотрудник уже не имеет разрешений. Таким образом, вы упускаете из виду контекст и не можете обеспечить безопасность вашей гибридной AD.

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

Что они делают?

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

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

В целом ваш ответ заключается в аудите таких действий, как:

  • изменение разрешений в AD;
  • изменение членства в группах AD;
  • изменение разрешений и доступа на сервере файлов;
  • изменение разрешений и доступа к базе данных SQL Server;
  • изменение разрешений Exchange;
  • доступ к почтовому ящику в Exchange со стороны кого-то, кроме владельца;
  • изменение разрешений и доступа к SharePoint.

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

В результате будет сформирован большой объем данных. На что следует обратить внимание?

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

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

Так с чего же начать аудит? Компания Microsoft предоставляет широкий набор инструментов, в том числе новых, с которыми можно смело приступать к работе.

Аудит AD с использованием собственных инструментов

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

Централизованный аудит с подписками на события

Наш акцент в области обеспечения безопасности — на пользователях и их действиях, поэтому полезно иметь возможность сделать запрос типа «показать все действия, выполненные пользователем А вчера». Вряд ли что-то подобное будет возможно с помощью средства просмотра событий в обозримом будущем, но к цели можно приблизиться благодаря подпискам на события. Если вы не работали с ними раньше, то помните, что они позволяют настроить пересылку событий в центральный компьютер (предположительно на сервер). Объединяя данные в общем центре, вы на шаг приблизитесь к тому, чтобы собрать все действия из запроса пользователя А для просмотра в одном месте.

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

 

Создание подписки на события
Экран 1. Создание подписки на события

Обратите внимание, что этот подход не заменяет управления журналами событий или решений класса SIEM; в конечном итоге для хранения собранных данных журналов событий потребуется очень много места, а запросы в средстве просмотра событий замедлятся до предела. Этот прием подойдет для владельцев нескольких компьютеров, на которых размещаются журналы, чтобы они смогли увидеть все свои данные в одном месте.

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

Ускорение поиска с использованием фильтрации XML

Проблема со стандартным поиском и фильтрацией в средстве просмотра событий имеет два аспекта. Во-первых, для построения нужного запроса потребуется некоторое время; во-вторых, фильтрация на основе графического интерфейса не охватывает все данные, обнаруживаемые для события.

Самый продуктивный способ фильтрации данных журнала — заранее построить собственное пользовательское представление на основе XML. Вы можете начать с предоставления всех необходимых сведений на вкладке Filters, а затем перейти на вкладку XML для совершенствования XML-запроса.

Например, приведенный на экране 2 фильтр XML был создан для того, чтобы показать любые изменения, внесенные в группу администраторов домена.

 

Вкладка XML
Экран 2. Вкладка XML

Вы можете задействовать любой элемент метаданных события (которые можно просмотреть, открыв свойства данного события и выбрав вкладку XML) наряду с логическими операторами (инструкции AND и OR), чтобы создать сколь угодно сложный XML-фильтр. Хотите узнать, что делали вчера те или иные пользователи или поместить события из нескольких журналов в одно представление? Это и многое другое можно сделать с помощью фильтров XML.

Хотя фильтры XML приближают вас к возможности задать настоящие аудиторские вопросы, например «кто вчера обращался к почтовому ящику главного управляющего?», но работать с ними сложнее, чем со сторонними решениями. Кроме того, в конечном итоге вы видите сырые данные из журнала событий — анализ отсутствует, есть только информация.

Аудит через PowerShell

Было бы непростительной небрежностью с моей стороны не раскрыть эту тему хотя бы кратко. Команда get-eventlog служит мощным основанием для аудита.

Например:

$a = get-eventlog -logname
   Security|where {$_.eventID -eq 4728}
$a | format-list -property *

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

Аудит AzureAD

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

  • пользователи и группы;
  • B2B (бизнес-бизнес);
  • приложения;
  • административная единица;
  • роли;
  • каталог;
  • устройства;
  • политика.

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

Вы можете найти полный список встроенных отчетов аудита AAD на портале Azure по адресу: bit.ly/AADAuditEvents.

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

Аудит Office 365

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

В первую очередь необходимо включить ведение журнала аудита в центре безопасности и соответствия требованиям Security & Compliance Center на портале Office 365. Кроме того, следует отдельно включить ведение журнала для каждого почтового ящика, если вы хотите регистрировать такого рода действия. В результате вы получите доступ к разнообразной картине действий.

Активность администратора в:

  • Azure AD (связанная с Office 365);
  • SharePointOnline;
  • Exchange Online.

Активность пользователя в:

  • Exchange Online;
  • SharePointOnline;
  • OneDrive для бизнеса;
  • Sway;
  • Power BI;
  • Yammer.

Аудит в центре безопасности и соответствия требованиям

Компания Microsoft обеспечивает централизованный доступ ко всем этим данным с помощью функции Audit Log Search («Поиск по журналу аудита») портала Security & Compliance Portal в Office 365. Поиск по журналу аудита выглядит в значительной мере как упрощенное веб-средство просмотра событий, но с дополнительным преимуществом — более чем сотней заранее определенных действий (например, назначение разрешений почтовому ящику), ускоряющих процесс поиска нужных записей журнала.

Полный список всех действий, доступных для поиска по журналу аудита, можно найти по адресу: bit.ly/O365 AuditActivities.

Результаты можно фильтровать (как показано на экране 3) с помощью простых текстовых значений. В контексте Office 365 вы вплотную подходите к вопросам типа «Что пользователь А делал вчера?», поскольку можете указать в фильтре имя пользователя и вчерашнюю дату и получить ответ.

 

Фильтрация результатов
Экран 3. Фильтрация результатов

Результаты можно экспортировать в файл типа CSV: только первые 1000 результатов, представленные в консоли, или все результаты вместе с дополнительными сведениями для каждой записи журнала.

Аудит с использованием PowerShell

В Office 365 всю перечисленную информацию можно получить с помощью PowerShell. Этот процесс требует кропотливой настройки, ее описание требует отдельной статьи. Вам необходимо включить аудит, организовать сеанс PowerShell с Office 365 с помощью команды New-PSSession и воспользоваться командой Search-UnifiedAuditLog для получения нужных данных.

Можно ли на самом деле узнать, что они делают?

Цель — обеспечить просмотр операций доступа и изменений в AD и приложениях, работающих с AD. Перед вами большой выбор инструментов, но есть и препятствия. В самих данных существует очевидное разделение локальный/«облачный»; ни одна консоль не позволяет увидеть данные локальной службе каталога AD и данные AAD и Office 365 в одном месте. Другая проблема, не нуждающаяся в объяснении, — множество консолей.

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

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

Неприемлемый доступ?

Часто трудно дать ответ на этот вопрос. Если кто-то из ИТ-подразде­ления обращается к почтовому ящику главного управляющего в Exchange Online, допустимо ли это? Реагирует ли он на обращение в службу поддержки, чтобы помочь восстановить удаленное сообщение, или просто подглядывает? То же самое относится к сбросу пароля главного управляющего. Само по себе действие не обязательно полностью характеризует ситуацию.

Чтобы определить, вызван ли доступ рабочей необходимостью, надо предусмотреть некоторую политику, указывающую, что выходит за рамки нормального для каждого пользователя с повышенными привилегиями. Почти все действия, перечисленные в начале раздела «Что они делают?», присутствуют и здесь, но с большей конкретикой относительно того, какие учетные записи пользователей, почтовые ящики, папки NTFS, файлы и т. д. находятся вне досягаемости.

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

Проблема избыточных привилегий более распространена, чем можно подумать. Согласно исследованию института Ponemon под названием Corporate Data: A Protected Asset or a Ticking Time Bomb?, 71% пользователей имеют доступ к ресурсам, которых им видеть не полагается.

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

Средство просмотра событий позволяет передавать сообщения по электронной почте с использованием мастера создания простой задачи. В PowerShell для этого существует команда Send-MailMessage. А в центре безопасности и соответствия требованиям Office 365 предусмотрены оповещения о действиях, Activity Alerts. Речь идет о том, чтобы обеспечить безопасность AD и предоставляемый через нее доступ, поэтому обязательно нужны какие-нибудь оповещения, чтобы ИТ-специалисты не узнавали о неприемлемом доступе с опозданием на дни, недели или месяцы.

Получив оповещение о подозрительном изменении, важно выяснить основную причину. Например, если изменен пароль главного управляющего, вопрос не ограничивается тем, кто внес изменения; анализ необходимо расширить, если выяснилось, что лицо, изменившее пароль, обычно не имеет такого права. Затем вам нужно определить, кто предоставил этому лицу такое право и т. д.

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

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

Повлияют ли изменения на непрерывность бизнеса?

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

Типы изменений, требующие внимания с позиций непрерывности бизнеса как внутри, так и вне AD:

  • массовые и значимые изменения в разрешениях или группах AD;
  • изменения топографических параметров AD (например, сайты, подсети, DNS и т. д.);
  • признаки манипуляций с данными.

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

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

Переход к синхронизации локальной службы каталога AD с «облаком» увеличивает риск неприемлемого доступа к данным и приложениям без контроля ИТ-подразделения, а часто и вне досягаемости администраторов. Размещая элементы управления вокруг локальной службе каталога AD, вы создаете зону безопасности вокруг AD, AAD, Office 365 и своих веб-приложений. Четыре вопроса, рассмотренные в этой статье, позволяют решить, как лучше всего выяснить, что меняется в AD, какие приложения затронуты, как изменения повлияют на организацию и как подготовиться, чтобы правильно реагировать, когда изменения произойдут.

Как найти ответ быстро?

Если посмотреть на собственные инструменты, предоставленные Microsoft, становится очевидно, что компания придает большое значение безопасности AD, AAD и Office 365. Но все же это не основная сфера деятельности компании, и обычно такие инструменты приемлемы для использования от случая к случаю или если не требуется глубокого анализа. Но они не всегда подходят в ситуациях, когда нужно проанализировать подозрительные действия, которые могут влиять на работу пользователей и приложений в течение недель или месяцев.

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

Существует ряд решений, например от компании Quest, построенных с использованием методологии, которая позволяет усилить безопасность, взяв под контроль локальную AD и распространив меры защиты на «облако». В основе методологии лежат четыре опоры безопасности гибридной AD:

  • постоянный доступ;
  • определение и оповещение;
  • устранение и смягчение;
  • анализ и восстановление.

Постоянный доступ

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

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

Определение и оповещение

Непрерывное оценивание помогает отслеживать состояние безопасноcти, но организации по-прежнему нуждаются в возможности ускоренного ответа на неотложные угрозы. Возможность выполнять аудит в реальном времени, в сочетании с оповещениями, позволяет ИТ-специалистам своевременно реагировать на опасности.

Quest Change Auditor контролирует и обнаруживает изменения на уровне операционной системы и приложений в AD и важнейших корпоративных приложениях. Отличие от Enterprise Reporter состоит в том, что Change Auditor активно отслеживает приложения и системы в поисках изменений, тогда как Enterprise Reporter собирает данные о текущей конфигурации и сравнивает их с предыдущей версией. Change Auditor оповещает ИТ-специалистов об изменениях в реальном времени, нейтрализуя последствия неприемлемых конфигураций.

Quest InTrust — решение управления журналом событий (ELM), которое консолидирует данные журналов из множества источников, обнаруживая изменения в данных журналов и оповещая ИТ-специалистов о конкретных событиях. Достоинство InTrust заключается в возможности консолидировать не только данные AD и Office 365, но и журналы из других источников, которыми можно воспользоваться для получения контекста подозрительных событий.

Устранение и смягчение

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

Quest Change Auditor использует превентивные меры на основе политик, отслеживая события в AD, чтобы предотвратить попытки изменить важнейшие объекты службы. В результате формируется уровень слежения за безопасностью AD.

Quest GPOADmin предоставляет функции управления версиями и доступа с минимальными правами к объектам групповой политики. В случае нежелательных изменений можно быстро выполнить откат к предыдущей версии.

Quest InTrust обеспечивает действия на основе политики для отклика на события. Действия InTrust определяются заранее и могут решать многочисленные задачи как для смягчения угрозы, так и для оповещения ИТ-персонала. Например, если кто-то включает гостевую учетную запись, InTrust можно настроить на ее автоматическое отключение, блокирование пользователя, пытавшегося включить ее, и оповещение специалистов по безопасности.

Quest Active Roles создает среду AD с минимальными правами, где все изменения вносятся через портал (а не напрямую в AD), действуя в качестве посредника. Это позволяет ограничить видимость (привилегированные пользователи не видят объектов, которыми не могут управлять), ограничить административную функциональность (доступны только разрешенные действия) и использовать рабочие потоки для одобрения и отчетности наряду с процессами управления AD.

Анализ и восстановление

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

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

Решения Quest Recovery Manager обеспечивают глубокое резервное копирование и восстановление вплоть до уровня атрибутов для локальной и Azure AD, а также восстановление электронной почты, как локальное, так и в Office 365.

Quest IT Security Search дает специалистам, которые занимаются анализом подозрительной активности, представление данных из Change Auditor, Enterprise Reporter, Recovery Manager и InTrust. Таким образом достигается исчерпывающая видимость конфигурации среды и изменений в AD и наиболее важных приложениях. Корреляция данных с использованием интерактивного поискового механизма обеспечивает быстрый отклик на нарушения и криминалистический анализ.

Четыре опоры — одна цель

Ваше ИТ-подразделение ежедневно делает все возможное, чтобы обеспечить безопасность сетевой среды. По мере того как среда расширяется, охватывая «облако», вы теряете контроль, что ставит под угрозу всю среду.

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