Защита интеллектуальной собственности MSSP в Microsoft Sentinel

В этой статье описываются методы, которые поставщики управляемых услуг безопасности (MSSP) могут использовать для защиты объектов интеллектуальной собственности, созданных ими в Microsoft Sentinel, таких как правила аналитики Microsoft Sentinel, запросы для поиска угроз, сценарии и книги.

Выбранный метод зависит от того, как каждый из ваших клиентов покупает Azure; выступаете ли вы в качестве поставщика облачных решений (CSP) или у клиента есть учетная запись Соглашение Enterprise (EA) или pay-as-go (PAYG). В разделах Поставщики облачных решений (CSP) и Соглашения Enterprise (EA) и pay-as-go (PAYG) описываются каждый из этих методов отдельно.

Защита интеллектуальной собственности MSSP в средах поставщика облачных решений (CSP)

Если вы перепродаете Azure в качестве поставщика облачных решений (CSP), вы управляете подпиской клиента на Azure. Благодаря Admin-On-Behalf-Of (AOBO), которая позволяет агентам администрирования партнера управлять подпиской клиента, пользователям группы Admin Agents (роли в Partner Center, участники которой администрируют подписки клиентов) из вашего клиента MSSP предоставляется роль "Владелец" для подписки Azure клиента, при этом у клиента по умолчанию нет доступа.

Если другим пользователям из клиента MSSP, не входящим в группу Admin Agents, требуется доступ к среде клиента, мы рекомендуем использовать Azure Lighthouse. Azure Lighthouse позволяет предоставлять пользователям или группам доступ к определённой области, например, к группе ресурсов или подписке, используя одну из встроенных ролей.

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

Например, вы можете:

• Вы можете предоставить клиенту доступ к нескольким группам ресурсов, в которых находятся его приложения, но по-прежнему сохранить рабочую область Microsoft Sentinel в отдельной группе ресурсов, где у клиента нет доступа.

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

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

Пример архитектуры Microsoft Sentinel CSP

На следующем рисунке описывается, как разрешения CSP, описанные в разделе " Поставщики облачных решений" (CSP), могут работать при предоставлении доступа к клиентам CSP:

На этом рисунке:

• Пользователи, которым предоставлен доступ Owner к подписке CSP, входят в группу Admin Agents в клиенте Microsoft Entra MSSP.

• Другие группы из MSSP получают доступ к клиентской среде через Azure Lighthouse.

• Доступ клиентов к Azure ресурсам управляется Azure RBAC на уровне группы ресурсов.

  Управление клиентским доступом на уровне группы ресурсов позволяет поставщикам управляемых услуг безопасности (MSSP) при необходимости скрывать компоненты Microsoft Sentinel, такие как правила аналитики и запросы поиска угроз.

Дополнительные сведения также см. в документации по Azure Lighthouse.

Защита интеллектуальной собственности MSSP в соглашениях Enterprise и средах с оплатой по мере использования

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

Вместо этого защитите интеллектуальную собственность, разработанную в Microsoft Sentinel следующим образом, в зависимости от типа ресурса, который необходимо защитить:

Правила аналитики и запросы охоты

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

Даже если у пользователя есть только разрешения уровня «Читатель» в Microsoft Sentinel, он может просмотреть запрос. Поскольку разрешения Reader по-прежнему дают доступ к запросам, мы рекомендуем размещать правила аналитики и запросы для поиска угроз в собственном арендаторе MSSP, а не в арендаторе клиента.

Для этого вам потребуется рабочая область в вашем собственном клиенте с включенной службой Microsoft Sentinel, а также доступ к рабочей области клиента через Azure Lighthouse.

Чтобы создать правило аналитики или запрос для поиска угроз в тенанте MSSP, которые ссылаются на данные в тенанте клиента, необходимо использовать оператор workspace следующим образом:

workspace('<customer-workspace-explicit-identifier>').SecurityEvent
| where EventID == ‘4625’

При добавлении инструкции workspace в правила аналитики учитывайте следующее:

• Используйте явный идентификатор workspace клиента: используйте идентификатор customer workplace в кросс-workspace запросе для лучшей производительности. Дополнительные сведения см. в разделе Форматы идентификаторов для запросов между рабочими областями.

• Нет оповещений в рабочем пространстве клиента: правила, созданные таким образом, не создают оповещений или инцидентов в рабочем пространстве клиента. Оповещения и инциденты существуют только в рабочей области MSSP.

• Создавайте отдельные оповещения для каждого клиента: При создании правил аналитики между рабочими пространствами мы также рекомендуем использовать отдельные правила оповещений для каждого клиента и обнаружения, поскольку оператор Workspace отличается в каждом случае.

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

  Например, вы можете:

  

• Создайте отдельные MSSP-рабочие пространства для каждого клиента: создание отдельных правил для каждого клиента и обнаружения может привести к максимальному числу аналитических правил для вашего рабочего пространства (512). Если у вас много клиентов и вы планируете достичь этого ограничения, вы можете создать отдельную рабочую область MSSP для каждого клиента.

  Например, вы можете:

  

Рабочие книги

Если вы разработали книгу Microsoft Sentinel и не хотите, чтобы клиент мог её скопировать, сначала убедитесь, что у вас есть доступ к рабочим областям клиента через Azure Lighthouse. Затем разместите рабочую книгу в арендаторе MSSP и настройте ее для использования этих рабочих областей клиентов.

Например, вы можете:

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

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

Экспорт книги в Power BI:

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

Дополнительные сведения см. в статье Импорт данных журнала Azure Monitor в Power BI.

Сценарии

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

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

  Например, вы можете:

  

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

  Например, вы можете:

  

В обоих случаях, если сценарию требуется доступ к среде Azure клиента, используйте пользователя или субъекта-службу, у которых есть такой доступ через Lighthouse.

Однако, если сценарию требуется доступ к ресурсам вне Azure в арендаторе заказчика, таким как Microsoft Entra ID, Office 365 или Microsoft Defender XDR, создайте субъект-службу с соответствующими разрешениями в арендаторе заказчика, а затем добавьте эту идентичность в сценарий.

Связанные материалы

• Техническое руководство по Microsoft Sentinel для MSSP
• Управление несколькими клиентами в Microsoft Sentinel в качестве MSSP
• Расширьте Microsoft Sentinel на несколько рабочих областей и тенантов
• Визуализация и мониторинг данных
• Руководство. Настройка автоматизированных ответов на угрозы в Microsoft Sentinel