Про компанию

Компания Tenable является мировым лидером в области информационной безопасности, а

именно в направлении управления уязвимостями, управления рисками (Vulnerability Management) и
безопасностью индустриальной ИТ инфраструктуры (IoT, SCADA).
Платформа Tenable по контролю уязвимостей и управлению рисками признана абсолютным
лидером отрасли согласно отчету аналитического агентства Forrester в 2019 году, а также Frost Radar
2021. С продуктами Tenable организации получают всю глубину отчетности и аналитики,
необходимой для наглядного отслеживания трендов и представления киберрисков в бизнес-
терминах, что облегчает принятие стратегических решений. Еще одним преимуществом Tenable
является экспертная предиктивная приоритизация уязвимостей, которая позволяет фокусироваться
на исправлении уязвимостей, наиболее критичных для конкретной организации.
Также Tenable смогли создать первую в отрасли единую платформу для комплексной оценки
и управления рисками как в среде ИТ, так и в промышленных средах АСУТП (OT, SCADA). Отдельное
решение Tenable также направлено защиту Active Directory.
Компания Tenable имеет собственную команду по разработке новых технологий для
повышения эффективности выявления уязвимостей - Tenable Research. Это позволяет решениям
быть "на острие" защиты от новых видов атак и уязвимостей. Примером этого является кейс с
последней нашумевшей уязвимостью - Log4Shell. Компания Tenable первой выпустила патч для
борьбы с данной уязвимостью и подготовила готовый шаблон сканирования для нее, что позволило
Заказчикам предотвратить множество потенциальных инцидентов.

Почему нужно защищать Active Directory

Инфраструктура Active Directory является центром безопасности компании, или организации.

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

Стандартная атака начинается за пределами организации, затем развиваясь через сеть и

конечные точки, достигает критически важных данных и активов.

При работе с отслеживанием атак и инцидентов, как правило игнорируется вездесущий

надзиратель, который координирует все в ИТ-инфраструктуре - Active Directory. Что привлекает
слишком мало внимания специалистов по ИТ-безопасности и слишком много внимания со стороны
хакеров.

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

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

Active Directory была основным решением для управления идентификацией и доступом для
организаций в течение последних лет. Этот факт не изменился, и технология от Microsoft тоже не
сильно изменилась. Это IAM-решение хорошо известно как админам, так и злоумышленникам.
 Злоумышленники применяют изощренные подходы к атаке на AD как с внешней, так и с
внутренней стороны. История показала, что традиционные инструменты и подходы безопасности не
были очень эффективными из-за увеличения числа успешных атак. Единого решения для решения
проблем безопасности AD не существует, но с помощью правильных инструментов и подхода можно
усилить безопасность и снизить количество атак.

Active Directory исполняется 21 год, некоторые вещи остаются прежними, особенно объекты и
атрибуты, содержащиеся в инфраструктуре. Это значит, что очень мало усилий требуется для
активного его изучения. Если организации не будут использовать Active Directory согласно
передовым методикам, то злоумышленники постоянно будут находить лазейки и атаки будут
продолжать нарастать.

Решения по безопасности AD

За прошедшие годы Microsoft разработала несколько решений безопасности для локального

AD, часто они остаются неактуальны с течением времени - теряют поддержку или заменяются
другими решениями. Единственной технологией, которая остается на переднем крае безопасности
AD, является - групповая политика. Групповая политика действительно претерпела улучшения за
последние годы с включением множества настроек ADM/ADMX, осущетсвения индивидуального
видения расширенной политики аудита. При этом основная архитектура групповой политики
осталась прежней.
За последние годы были представлены сдедующие решения для обеспечения безопасности
AD:
• Расширенный аудит
• Мастер настройки безопасности (SCW)
• Диспетчер соответствия требованиям безопасности (SCM)
• Конфигурация желаемого состояния (DCM)
• Решение для пароля локального администратора (LAPS)
• Группа защищенных пользователей

Общая проблема каждого из этих решений заключается в невозможности по-настоящему

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

Новые потенциальные атаки

Статическая инфраструктура и нестабильные решения безопасности являются тригером для

хакеров для осуществления атак и их становится все больше. Злоумышленники в течение многих лет
хотели иметь возможность атаковать среду, не создавая никаких следов или событий. Такими и
являются новые виды атак. Общество специалистов по безопасности винит в этом саму Microsoft,
поскольку основа Active Directory с самого начала не была надежной (основные дыры и пробелы в
безопасности так и остаются без улучшений).
Современные атаки используют базовые концепции, на которых построены AD и Microsoft,
обходя фиксацию нарушений в журналах событий или отслеживание изменений, которые эти
решения для мониторинга AD могли видеть в течение многих лет.
 Злоумышленники используют боковое перемещение и повышение привилегий, чтобы
перейти к фазе контроля всего домена за несколько часов или дней. Некоторые из современных
атак/концепций, которым сегодня подвергается AD:

• DCSync
• DCShadow
• Password spray
• Pass-the-Hash
• Pass-the-Ticket
• Golden ticket
• Service Principal Name
• AdminCount and adminSDHolder

Медленные атаки

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

Атаки с использованием базовой технологии и конфигураций

Учтите, что Microsoft Active Directory была создана в 2000 году. Yahoo была техническим
вундеркиндом, а Билл Клинтон был президентом. Технологии, которые Microsoft внедрила для
обеспечения беспрепятственного обмена данными, до сих пор встроены в эту технологию. На
протяжении многих лет технологии использовались против окружающей среды, поскольку
информация, относящаяся к определенным привилегированным учетным записям, была легко
обнаружена. Некоторые из распространенных встроенных технологий, используемых в среде AD,
включают:
• Имена участников службы
• Admincount и adminSDHolder SIDHistory
• Идентификатор основной группы пользователей
Эти важные аспекты среды были разработаны для обеспечения безопасности и
согласованности, но теперь злоумышленники используют их для создания бэкдоров и получения
постоянного доступа, оставаясь незамеченными. Например, атака adminCount и adminSDHolder
довольно проста по замыслу, и ее почти невозможно остановить без постоянного внимания к
деталям. Короче говоря, злоумышленник изменит ACL, хранящийся в объекте adminSDHolder, чтобы
включить учетную запись, которую он
контроль, предоставляя учетной записи Изменить или Полный контроль. Когда фоновый
процесс запускается для размещения ACL на всех объектах, содержащих атрибут adminCount, равный
1, злоумышленнику предоставляется
 права доступа к привилегированным объектам.

Атаки, которые обходят ведение журналов

Были разработаны новые атаки, весьма изощренные и изобретательные. Эти атаки

действительно требуют привилегий в Active Directory, но с таким количеством других атак, которые
дают злоумышленнику привилегии, они используются только после того, как эти привилегии
предоставлены. Цель привилегированной атаки — добиться стойкости, чтобы никто не заметил. Две
атаки, подпадающие под эту категорию, включают:
• Синхронизация постоянного тока
• DCShadow
Общая цель DCSync состоит в том, чтобы получить данные учетной записи пароля, чтобы
офлайн-атаки могли быть сделаны хэшами паролей, полученными в результате атаки. Атака
DCShadow немного отличается тем, что она создает поддельный контроллер домена, который
используется для внедрения атак в поток репликации, бесследно изменяя объекты и атрибуты.
Обе атаки обходят логи. Это возможно, потому что они имитируют новый контроллер домена,
а журнал поддельного контроллера домена никогда не существует! Это идеальная атака для
организаций, которые полагаются на журнал событий безопасности, чтобы отслеживать активность.
Мониторинг AD, решения SIEM и даже большинство решений на основе агентов не смогут
распознать эти атаки.

Атаки, выдающие себя за других пользователей

Атаки, которые существуют уже некоторое время, но продолжают порождать новые

варианты, включают:
• Передача хеша
• Проходной билет
• Серебряные билеты
• Золотые билеты
Эти атаки каким-то образом используют украденные учетные данные, чтобы выдать себя за
пользователя. Конечно, украденные учетные данные принадлежат привилегированному
пользователю, поэтому в домене можно использовать максимально возможные привилегии. Pass-
the-Hash и Pass-the-Ticket используют необработанную хешированную информацию для
олицетворения пользователя, в то время как Silver и Golden Tickets берут на себя часть процесса
аутентификации Kerberos, который обеспечивает доступ к службам и всем учетным записям на
предприятии.

Упреждающее обнаружение различных атак

Учтите, что большинство сред AD были созданы много лет назад. Когда была установлена
Active Directory, сегодняшние проблемы безопасности даже не считались проблемой. Каждая
организация, использующая Active Directory, должна быть проинформирована о существующих
проблемах безопасности, которые могут привести к атаке на их инфраструктуру. К сожалению,
решения для мониторинга AD и SIEM не предоставляют эту услугу или функцию.
[Link] для AD делает все сразу. Когда вы устанавливаете [Link] для AD, система
предоставит список существующих проблем и неправильных конфигураций, которые необходимо
исправить немедленно. Каждой организации необходимо не только очистить свою текущую систему
безопасности для AD, но и необходим постоянный мониторинг, чтобы гарантировать отсутствие
неправильных конфигураций и атак. Очень многие организации думают, что если требуется только
усиление безопасности, настройки не будут
сдача. Это не относится ни к одной производственной среде Active Directory. Настройки
постоянно меняются из-за ошибок, установок, обновлений и атак. Поэтому, если инициируется
какая-либо неправильная конфигурация или атака, время для обнаружения и оповещения
организации имеет решающее значение. Некоторые атаки медленные, в то время как другие атаки
могут длиться всего несколько минут.
Чем быстрее будет выявлена атака, тем больше шансов, что ее удастся отразить. Мониторинг
AD и решения SIEM полагаются на журналы безопасности для получения сведений о текущих
действиях в Active Directory и вокруг нее. [Link] не ждет регистрации активности. Вместо,
[Link] использует необработанный поток репликации AD для получения информации
еще до того, как действие будет выполнено. Поскольку каждая секунда имеет значение, это может
создать или сломать отрицание атаки. (Конечно, [Link] может отправлять найденную
информацию в SIEM, поэтому SIEM являются жизненно важным компонентом общей безопасности
любой организации.)

Резюме по атакам

Поскольку Active Directory так хорошо известна и находится в застое, злоумышленники смогли
найти новые и инновационные лазейки в инфраструктуре. Эти бэкдоры умны, они позволяют
получать информацию практически без привилегий, что позволяет злоумышленникам находиться в
сети незамеченными. Есть некоторые атаки, требующие привилегий, но эти атаки могут обойти
журнал безопасности и, следовательно, мониторинг AD и решения SIEM. Для обнаружения всех атак,
используемых сегодня, лучше всего подходит упреждающий подход, такой как [Link].
[Link] предоставляет немедленную информацию о неправильных конфигурациях, а также
обнаружение любых новых неправильных конфигураций или атак в режиме реального времени. Все
без агентов и без привилегий.
По мере того, как мы углубляемся в недавние громкие нарушения, одна вещь становится
кристально ясной: способность злоумышленника воздействовать на инфраструктуру идентификации
(читай: Active Directory) играет центральную роль в кибербезопасности.
Как только злоумышленник закрепится в организации, он не сможет двигаться дальше без
доступа к учетной записи привилегированного пользователя. Они немедленно будут искать
привилегии высокого уровня, чтобы получить доступ к информации, которую они хотят в
организации. Обладая привилегиями, злоумышленник может создавать бездействующие учетные
записи, предоставляя им черный доступ, так что даже если они будут обнаружены, они смогут
вернуться в среду незамеченными. Злоумышленник может даже стереть свои криминалистические
следы, перемещаясь по сети организации.

Решение [Link]

[Link] направлено на поиск и устранение существующих проблем в безопасности Active

Directory, а также в реальном времени выявлять активные атаки без развертывания агентов или
использования привилегированных учетных записей. Решение может разворачиваться как в
облачной среде, так и локально в инфраструктуре, позволяет увидеть все происходящее с AD,
предсказать важные риски, реализовать активные действия, чтобы их снизить, блокируя при этом
траектории атаки, которыми злоумышленники могут воспользоваться.
Особенности разворачивания\интеграции решения:
 On-premises или в облаке
 Управление всеми компонентами и функционалом через единый Веб-интерфейс
 Установка как на сервера, входящие в домен Active Directory, так и на не входящие в домен.
 Не требует привилегированных аккаунтов или установки ПО на контроллеры доменов.
 Не требует установки агентов
 Система может интегрироваться с системами сторонних производителей (LDAP, SAML) для
обеспечения аутентификации и авторизации внутренних пользователей.
  Система поддерживает следующие протоколы для получения информации с контроллеров
домена: LDAP/LDAPS; SMB; CIFS, SMB2, DFSN, LSARPC, NbtSS, NetLogonR, SamR, SrvSvc, Kerberos,
FRS, DNS.

Возможности [Link] и задачи, которые может решать:

 Поиск, исправление, приоритизация слабых мест Active Directory до того, как произойдет
атака.

 Создание интерактивной графической визуализации инфраструктуры Active Directory.

 Обнаружение и реагирование на атаки Active Directory в режиме реального времени, таких

как: DCShadow, Brute Force, Password Spraying, DCSync и других.

 Предоставляет дополнительную информацию для SIEM, SOC или SOAR об атаках, для скорости
реагирования

 Блокирование траекторий атаки (типичного внутреннего пути по сети, который

злоумышленники могут успешно использовать для повышения привилегий)

 Выявление ошибок конфигурации Active Directory (предоставление готовых гайдов,

рекомендаций по их решению, исправлению)

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

 Выявление опасных доверительных отношений между доменами.

 Выявление любых изменений в AD.

 Визуализация каждой угрозы на основе таймлайна атаки.

 Корреляция между изменениями AD и вредоносными действиями.

 Детальный анализ атак на AD.

 Сопоставление с тактиками и техниками MITRE ATT&CK в описаниях обнаруженных

инцидентов.

 Система должна предоставлять подробное описание ошибок конфигурации и рекомендации по

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

 Система должна отображать консолидированные данные об атаках единым списком.

 Система должна сопоставлять техники и тактики MITRE ATT&CK в каждом инциденте.

 Система должна позволять отображать угрозы на основе детальной истории развития атак.

 Система должна проверять безопасность доменных служб Azure Active Directory, AWS Directory Service,
Google Managed Service в режиме реального времени.

 Система должна иметь возможность уведомлять о событиях через встроенные уведомления,

электронную почту и Syslog.
  Решение [Link] предупреждает и выдает аргументирующие рекомендации о применении
корректных сценариев использования и существующих путях потенциальных атак

 Наличие более 200 встроенных сценариев контроля поведения работы службы каталогов AD, при
постоянном обновлении индикаторов со стороны производителя Tenable;

 Использование непрерывного потока репликации данных из службы каталогов AD;

 Предупреждения об ошибках в конфигурации и путях проведения атак на основе постоянного

анализа конфигураций службы каталогов AD;

 Мгновенное «Обнаружение» и «Предотвращение» атак путем отслеживания в режиме реального

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

 Решение [Link] использует поток репликации для превентивного мониторинга, без журнала
службы каталогов AD вообще, это означает, что даже если произошло заражение от атаки, которая не
оставила никаких журналов (или если злоумышленник удалит эти журнальные события), решение все
равно сможем отобразить всю необходимую информацию для дальнейшего расследования, что в итоге
произошло и в какой хронологической последовательности, поскольку происходит сохранение всех
изменений, данных. Этот функционал позволит увидеть всю картину происшедшего и отображение
необходимых данных для дельнейшего расследования в случае взлома.

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

Практики использования [Link] для защиты Active Directory

• Проведение инвентаризации

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

• Оценка текущих настроек безопасности

Изначально Active Directory предлагает стандартные настройки безопасности. Эти настройки по

умолчанию могут соответствовать\не соответствовать потребностям\требованиям бизнеса, или
организации.

• Внедрение принципа минимальных привилегий

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

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

• Ограничение и контроль прав администраторов Active Directory

Распределение привилегий администратора и суперпользователей только тем сотрудникам

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

• Безопасность контроллера домена

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

• Использование многофакторной аутентификации

Если хакеры получат учетные пользовательские данные в Active Directory, процесс MFA не позволит
им повысить привилегии в системе.

• Помощь в осуществлении соответствии стандартов безопасности, мониторинга и аудита.

Внедрение решения, оценивающего изменения пользователей и поведение сети, поможет выявить

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

• Помощь в обучении ИТ-команды

Обучение и информирование своих сотрудников о подлинных угрозах и опасностях

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

• распознавать фишинговые атаки и атаки вредоносного ПО.

• Научите их понимать уровень риска с учетом поведения разных пользователей.

• Убедитесь, что ни один пользователь не имеет полного доступа к системе.

• Создайте и обеспечьте соблюдение стратегической политики паролей.

Лучшие практики
Существует несколько надежных источников, в которых подробно описаны передовые методы,
которым должны следовать организации, чтобы укрепить и защитить свою Active Directory. В
частности:

 Microsoft:
[Link]
practices-for-securing-active-directory

 NIST:
[Link]

 ANSSI:
[Link]

Кейсы в которых использование [Link] является маст-хев решением

 Урок усвоенный после взлома Solarwinds

 Безопасная миграция в Офис 365
 Безопасная миграция в Офис 365

Особенности использования Office 365

В состав решения Office 365 входит набор известных продуктов семейства Office в
специальной облачной реализации, дополнительные продукты: OneDrive — облачный хостинг
пользовательских файлов, Yammer — корпоративная социальная сеть. Для работы с облачными
продуктами используются интернет-браузер или классические версии клиентского ПО Microsoft
Outlook, Microsoft Lync, подключенные к серверам в облаке.
Заказчик через приобретение и активацию лицензий арендует у Microsoft
ограниченную область — облачный тенант.

Укрупненно есть два сценария работы с облачной средой:

 сценарий полного перевода пользователей в облако или подключения их в облачный тенант

(частичный перевод);
 гибридный сценарий — часть пользователей остается на собственных серверах предприятия,
часть пользователей работают в облачном тенанте. Гибридный сценарий также обеспечивает
плавную по времени миграцию пользователей организации с развитой собственной
инфраструктурой Microsoft Exchange, вплоть до полного перехода на облако.

Поскольку облачный тенант базируется на каталоге Active Directory с рядом ограничений,

вопросы ведения пользователей решаются либо непосредственным заведением аккаунтов в облаке,
либо через механизм синхронизации аккаунтов (объектов) из AD.
Вопросы авторизации пользователей решаются либо непосредственным заведением
паролей в облаке, либо через механизм связывания Active Directory через службы ADFS (Active
Directory Federation Services), что позволяет реализовать для пользователей заказчика Single Sing-On
доступ к ресурсам облака.
Microsoft, обновив версию облачного тенанта, декларировала поддержку сценария multi-
forest для Заказчиков с холдинговой структурой — группа компаний с разными ИТ-структурами, с
пользователями, расположенными в несвязанных Active Directory с независимыми Exchange-
организациями. Все независимые Exchange-организации могут присоединиться к одному общему
тенанту в облаке, сохраняя возможность гибридного сценария для каждой компании. Выгода
сценария multi-forest: в облаке работает единая адресная книга, доступны календари, статусы
присутствия, группы рассылки, общие порталы, общие собрания, документы для пользователей из
различных компаний.
Общие проблемы для любой модели использования облака Office365 Заказчиками с
собственной развитой инфраструктурой. Часть возможностей продуктов Office при переводе в
облаке либо теряются, либо работают с ограничениями, по сравнению с использованием тех же
продуктов в серверной инфраструктуре предприятия.
Группы безопасности Active Directory невозможно синхронизировать в облако, что означает,
например, пересмотр и перестройку структуры доступа к порталам, мигрирующим в SharePoint
Online, если в SharePoint (корпоративные порталы) на предприятии доступ базировался на AD-
группах.
При планировании перехода на облако вам нужно понимать, с какими техническими
ограничениями вы столкнетесь или какой функционал не будет доступен вашим пользователям, от
чего вы готовы отказаться, в каком случае готовы согласиться с дополнительными расходами и
перепроектировать набор решений, расположенных на инфраструктуре предприятия так, чтобы
безболезненно перевести часть сервисов на облака.
 Особенности гибридных моделей облачного сервиса
В гибридной модели развернутые на предприятии решения Exchange, Lync,SharePoint, а
также сервисы Active Directory, DNS, ADFS тесно работают с серверами, сервисами в облаке. Тесная
работа с облаком ИТ-решений на стороне заказчика требует от него развертывания последних
версий используемых продуктов. В дальнейшем заказчику обязательно придется своевременно
обновлять связанные решения в корпоративной инфраструктуре. Использование необновлённых
версий —это риски заказчика, невыполнение требования условий по поддержке решения, с
непредсказуемым результатом функционирования облачных сервисов для пользователей. В
некоторых случаях смена версий тенанта, связанная с этим смена версий серверных продуктов на
стороне заказчика требуют обязательного обновления клиентской части, миграции с
неподдерживаемых версий клиентов. Как следствие — это дополнительные усилия и затраты для
заказчика на планирование, подготовку, тестирование, реализацию обновления, миграции. Нужно
быть готовым к сбоям в процессе миграции, проявлению скрытых ошибок при миграции и в уже
установленных новых версиях продуктов. К чести вендора, проблемы достаточно быстро решаются,
но все же могут оказывать и оказывают влияние на непрерывность, стабильность работы
пользовательских сервисов и на воспринимаемое пользователями качество, которым часто
непонятна вся ИТ-суета со сменой версий продуктов. Тесное взаимодействие серверов с облаком
требует соответствующих сетевых настроек на всех элементах сетевой инфраструктуры, включая
брандмауэры, серверы балансировки, маршрутизаторы, DNS-серверы. Одна из связанных проблем
заключается в том, что облачные сервисы Microsoft периодически меняют пул используемых IP-
адресов, ассоциированных с прежними DNS-именами облачных сервисов. Заказчику необходимо
следить за анонсами смены IP-адресов, своевременно настраивать новые правила и отлавливать
ошибки/сбои в работе на момент переключения пула IP-адресов облачных сервисов, серверов. На
пользователей, подключаемых к облаку напрямую через Интернет, окажет влияние скорость
распространения изменений в DNS-серверах интернет-провайдеров в периоды, когда старые IP-
адреса облака уже не работают, а новые еще не обновились на DNS, к которому подключен
пользователь. В этом случае полезно будет заранее информировать пользователей в терминах
доступности тех или иных сервисов о возможных проблемах при любых запланированных Microsoft
изменениях в тенанте.

Особенности облачного сервиса для крупных организаций

Для борьбы с внутрикорпоративным спамом и возможной вирусной активностью Microsoft

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

Операции сопровождения (provisioning), управления атрибутами пользователей,

лицензиями в облаке практически никак не автоматизированы. Привязка лицензий к пользователю,
перевод лицензий на другой план, установка различных политик на отдельных пользователей — все
это делается вручную, индивидуально для каждого пользователя, что требует ресурсов на данную
работу. Дополнительный риск — человеческий фактор, возможность ошибки в многочисленных
повторяющихся ручных операциях. Помогает то, что в облаке с определенными ограничениями
поддерживаются PowerShell-скрипты, и при значительном количестве пользователей заказчику либо
придется самостоятельно автоматизировать provisioning-процессы, либо искать и приобретать
дополнительные продукты, которые уже умеют это делать.
 Проблемы, характерные для сценария multi-forest

Office 365 хорошо приспособлен для централизованной модели управления и плохо

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

В облачном тенанте используется «плоская» служба Active Directory, и нет возможности

разбить объекты облачного тенанта, например, пользователей, по различным коллекциям и
ограничить к ним доступ отдельным администраторам. Все пользователи доступны всем
администраторам. Заказчик либо вынужден переходить на централизованную модель управления
пользователями в облаке, либо искать и приобретать третьи продукты для управления, либо
эмулировать распределенное управление на договоренности администраторов различных
компаний не трогать «чужих» пользователей. У любых из обозначенных подходов есть свои минусы,
усугубляющие проблему совместного управления. Например, в подходе «не трогать „чужие“
объекты» остается пресловутый человеческий фактор задеть вручную или скриптом автоматизации
пользователей другой компании, лишить их возможности работы с облаком, и нет никакой
возможности откатить проведенные изменения назад, отменить изменения. Чтобы исправить, надо
будет сначала найти, что было сделано неправильно.
В облачном тенанте у вас единый пул лицензий на тенант, сразу на все компании, без
возможности привязки к отдельным компаниям. Сам пул лицензий собирается из пакетов лицензий,
активированных по контракту либо дополнительной закупкой, либо продлениями. И так по всем
контрактам всех компаний — участниц тенанта. У каждого пакета свое количество и состав лицензий
— планы (например: E1, E2, E3), сроки начала и окончания действия лицензий в пакете.
Отсюда проблема: нет возможности управлять пакетами лицензий, кроме как продлевать
пакет на следующий срок. Управление происходит на уровне пула целиком, оперируя понятиями
сколько всего есть лицензий различных планов, сколько занято (привязано к пользователю,
объектам облака), сколько свободно. Вы можете привязать к пользователю лицензию из общего
пула, взяв из числа свободных. При этом вам недоступна информация о сроке окончания лицензии
конкретного пользователя. При наступлении срока окончания какого-либо пакета лицензий —
сюрприз: случайный набор пользователей остается без лицензий, а значит, без доступа к сервису,
даже если в пуле есть свободные лицензии. Администратору необходимо найти пользователей без
лицензий и привязать к ним свободные лицензии из пула. По правилам использования ящик без
лицензии хранится в облаке семь дней и потом удаляется. Никакого backup, никакой возможности
восстановить. Когда в одном тенанте, за одним общим пулом лицензий стоит
несколько лицензионных контрактов разных компаний, в условиях отсутствия инструментов
привязки лицензий к компании есть высокая вероятность, что часть компаний группы будет
использовать лицензии сверх того, что они приобрели, за счет лицензий других компаний. Проблема
будет обостряться в периоды завершения лицензионных контрактов у одной из компаний группы,
если одни ответственные проигнорировали предупреждение вендора об окончании срока действия
лицензий, другие ответственные забыли или затянули обсуждение заключения нового контракта или
продление действующего.
На группу компаний потребуются дополнительные инструменты отчетности, учета и
управления лицензиями за пределами облака, с регулярной сверкой результатов в рамках общей
рабочей группы, а также система взаимного информирования и договоренностей по контрактам, по
оперативному реагированию и исправлению ситуации с лицензиями.

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

собственной развитой инфраструктурой

Если у компании есть собственная инфраструктура Active Directory и для удобства

авторизации пользователей в облаке требуется обеспечить им Single Sign-On, если есть собственная
почтовая система Exchange и нужно сохранить всю наработанную пользователями
корреспонденцию, архивы, группы рассылки, права доступа ассистентов к ящикам руководителей,
совместные ящики, используемые адреса, то подключение к облаку — это только проект миграции в
облако. Первое, с чем столкнется заказчик, — необходимость найти партнера с успешным опытом
миграции в облако клиентов сопоставимых размеров и условий (и это уже будет нетривиальная
задача), либо нанять профессионалов из Microsoft Consulting Services. Второе, миграция — это
крупный проект, который начинается с обследования готовности серверной и клиентской
инфраструктуры заказчика, сетей и требует приведения всех задействованных решений в состояние
готовности к работе с облаком. Фактически это набор проектов по миграции на требуемые
последние версии продуктов на серверах и клиентских устройствах, настройке сетевых решений.
Необходимо будет развернуть дополнительные сервисы, такие как AADSync — для синхронизации
объектов Active Directory заказчика в облако, ADFS — для авторизации облачных пользователей в
Active Directory заказчика.
Когда у вас холдинговая структура с отдельными ИТ-службами и пользователями в
различных компаниях в структуре, то все компании должны будут выполнить тот же набор
изменений, чтобы соответствовать требованиям для подключения к облаку.
Невыполнение требований какой-то одной компании приведет к простою по реализации
проекта для остальных. Проект также потребует организации тестовой среды с копией всех
существующих Active Directory, Exchange организаций, Lync, SharePoint, настройки ADFS,
инструментов синхронизации, сетевого дизайна, подключения к тестовому тенанту с обкаткой
настроек и всех аспектов миграции и всех типовых задач подготовки к миграции и собственно
миграции. зависимости от масштаба компании такой проект от стадии обсуждения до финальной
миграции займет от нескольких месяцев до пары лет работы. На этот проект накладывается
обстоятельство, что сама Microsoft активно дорабатывает как облачные продукты, так и все
требуемые вспомогательные решения. За последний год компанией была произведена замена
продуктов по синхронизации в облако и смена версий ADFS, смена версий тенанта. Любые
изменения ключевых компонентов решения требует предварительной проверки, тестирования и
планирования плавной замены.
Сама миграция затрагивает работу пользователей, бизнес-подразделений. Жизнь после
внедрения меняет внутренние ИТ-процессы и работу отдельных ИТ-подразделений, партнеров.
Такой проект требует разработки плана коммуникаций со всеми задействованными,
заинтересованными сторонами, быстрого реагирования и информирования по различным каналам
коммуникаций о проблемах, накопление и распространения знаний от внедряющих ИТ-решения до
поддержки и пользователей.
Выводы
При всех выгодах использования облаков не должно быть иллюзий о том, что к облаку просто
подключиться, облачные сервисы легко поддерживать и управление облаком не составит труда. С
одной стороны, вы получаете современные, удобные облачные продукты для пользователей, с
другой, инструменты, предлагаемые вендорами облаков для ИТ — незрелые, и вам приходится что-
то дополнительно предпринимать, делать, искать. В одних областях облака упрощают технические
решения, в других сложность взаимосвязей облачных решений с ИТ-решениями на предприятии
возрастает — вместе с требованиями по готовности систем и необходимыми компетенциям в ИТ.
Процесс подготовки и подключения к облаку для больших компаний можно сформулировать так:
непросто, недешево, на пути перехода в облако местами рискованно, требует высокой степени
зрелости и дисциплины вовлеченных ИТ-служб.

Урок усвоенный после взлома Solarwinds

 Вокруг взлома SolarWinds было много шума, и на то есть веские причины. Подробности
нападения и его масштабных последствий публикуются частями. Единственное, что на самом деле
не обсуждается, — это то, что вы можете сделать с вашими существующими приложениями,
службами и соответствующими компонентами Active Directory для защиты собственной
инфраструктуры и удостоверений.
Если бы существовала серебряная пуля для защиты приложений и сервисов, она была бы на вес
золота. Увы, нет ничего, а тем более 100, что можно сделать, чтобы защитить вашу среду на 100%.
Важно обучить своих администраторов и группы безопасности, чтобы они могли настраивать
учетные записи служб, AD, групповую политику, службы и приложения для смягчения неизбежных
угроз.
Какое место Active Directory занимает в атаке и взломе SolarWinds?
Исторически об атаках и взломах сообщалось на высоком уровне. Это означает, что предоставлено
мало подробностей о первоначальном нарушении, боковом перемещении, повышении привилегий
и более мелких подробностях о том, как вредоносный код выполнил указанное нарушение. Есть
несколько атак, таких как атака, предпринятая против Организации Объединенных Наций, которые
ясно указывают на то, что Active Directory была главной целью для быстрого перемещения по сети
после получения привилегий AD. Совсем недавно FireEye пресекла атаку SolarWinds SUNBURST.
Согласно FireEye, если бы в сети не было Active Directory, атака прекратилась бы.
«Бэкдор также определяет, присоединена ли система к домену Active Directory (AD), и, если да,
извлекает доменное имя. Выполнение прекращается, если система не присоединена к домену AD».
– FireEye, Inc, SUNBURST Дополнительные технические детали

Это доказывает, что злоумышленники не только полагаются на AD, но и если AD не будет на

картинке, они перейдут к совершенно другой организации. Это также показывает, что, хотя защита
приложений и служб имеет важное значение, злоумышленнику необходимо выйти за рамки
первоначального нарушения, чтобы достичь своих целей. Им необходимо использовать ядро
управления идентификацией для организации, которым почти всегда является Active Directory. Все
это восходит к наблюдению Сената о том, что агентства не понимают, какая среда у них есть, не
говоря уже о том, как должным образом защитить эту среду.
Ключевые детали атаки
Информация о том, как злоумышленники смогли скомпрометировать платформу SolarWinds Orion,
интригует, но есть много способов, которыми злоумышленник может проникнуть в окружающую
среду. В прошлом злоумышленники просто проникали через конечные точки, используя
фишинговые атаки и атаки с использованием социальной инженерии. Теперь они добавили
приложения, инструменты и сервисы в свой список точек входа, как подробно описано Infosecurity
Group.
Детали атаки SolarWinds показали, что злоумышленник смог обойти решения для федеративной
идентификации и использовать поддельные токены аутентификации, что позволило им легко
перемещаться в облачные среды Microsoft. Неудивительно, что эти шаги почти идентичны другим
шаблонам атаки после компрометации первого устройства в среде.
Хотя Microsoft заявила 4 февраля, что ее программное обеспечение и инструменты никоим образом
не использовались в атаке SolarWinds, анализ, проведенный известными поставщиками средств
защиты, свидетельствует об обратном:
FireEye Report
• MalwareBytes Report
• CrowdStrike Report

Обеспечение 100% защиты от первоначальной компрометации маловероятно. Каждое новое

нарушение доказывает это. Тем не менее, мы можем узнать из деталей взлома SolarWinds (и других
известных атак), что цель состоит в том, чтобы перейти в горизонтальное положение и получить
привилегии в Active Directory. Как только это будет достигнуто, движение к остальной части сети и
устройствам станет очень простым для выполнения и трудно обнаруживаемым.
Уроки выучены
Самый большой урок и самый простой: всегда будь готов ко всему! Злоумышленники движутся с
головокружительной скоростью, разрабатывая инновационные способы проникновения в наши
сети, перемещения в горизонтальном направлении и получения привилегий. Таким образом, нам
нужно соответствовать и превосходить их инновации, чтобы опередить их. Это требует, в контексте
безопасности, решений как для предотвращения, так и для обнаружения.

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

Конечные точки контроллеров домена должны быть настроены с минимальной привилегией
доступа с уровня ОС к сторонним службам. Если наименьшая привилегия равна уровню привилегии,
которая может вносить изменения в Active Directory, необходимо предпринять дополнительные
шаги для защиты этих учетных записей. Решений PAM и IAM недостаточно, хотя они являются
хорошим началом. Поскольку злоумышленники нацелены на угрозы, открытые для AD,
существующие угрозы в AD должны быть устранены как можно скорее.
Во-вторых, поскольку AD является основной целью бокового перемещения и повышения привилегий
в этой атаке, защита всех учетных записей AD имеет первостепенное значение.
Это означает, что необходимо защищать не только учетные записи и их настройки, но и
поддерживать безопасность. Должны быть включены круглосуточные решения для автоматического
анализа, которые могут обнаруживать сложные взаимосвязи между объектами/атрибутами AD и
элементами управления AD (ACL, конфигурациями, доверием и т. д.). Злоумышленники используют
инструменты подсчета, которые «сидят и ждут», пока не обнаружится угроза AD, после чего они
могут быстро отреагировать.
Обнаружение этих путей атаки в режиме реального времени даст организации фору для устранения
любых новых угроз, как только они будут обнаружены.

Наконец, должны быть готовы решения для обнаружения атак.

Почти все отчеты указывают на то, что методы распыления и подбора паролей использовались для
компрометации не только обычных учетных записей, но и привилегированных. Да, увеличение
сложности и длины пароля — хорошее начало, как и решения MFA. Однако до тех пор, пока
организации не смогут достичь этого уровня безопасности паролей, необходимо реализовать
обнаружение атак, связанных с паролями, в режиме реального времени, чтобы они могли
немедленно сообщить ИТ-персоналу и группе безопасности, чтобы остановить атаку.
Действия сейчас
Поскольку каждая организация сталкивается с беспрецедентным уровнем угроз, необходимо
немедленно принять меры для защиты данных, сети и организации в целом. Как минимум, как
можно скорее решите следующие задачи для приложений, служб и среды Active Directory:
Приложения и сервисы
• Настройте любые учетные записи службы с минимальными привилегиями (как в
приложении/службе, так и в AD).

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

• Исправление и обновление до последней версии продукта

• Настройте приложение/службу с наиболее безопасными параметрами.

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

• Устранение любых и всех существующих угроз, связанных с контроллерами домена и AD.

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

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

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