Управление доступом к данным Microsoft Sentinel по ресурсам

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

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

В таких случаях рекомендуется настроить управление доступом на основе ролей (RBAC), указав разрешенные для пользователей ресурсы, а не предоставлять им полный доступ к рабочей области Microsoft Sentinel или функциям Microsoft Sentinel. Этот метод также известен как RBAC в контексте ресурсов.

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

• Через сам ресурс, например виртуальную машину Azure. Этот метод используется для просмотра журналов и книг только для определенного ресурса.

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

Включите RBAC в контексте ресурсов в Azure Monitor. Дополнительные сведения см. в статье Управление доступом к данным журнала и рабочим областям в Azure Monitor.

Примечание

Если данные не являются ресурсом Azure, например данные Syslog, CEF или AAD, или данные, собранные пользовательским сборщиком, необходимо вручную настроить идентификатор ресурса, используемый для идентификации этих данных, и разрешить доступ. Дополнительные сведения см. в статье Явная настройка RBAC в контексте ресурсов.

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

Сценарии для RBAC в контексте ресурсов

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

Тип требования	Команда SOC	Группа, не относящаяся к SOC
Разрешения	Вся рабочая область	Только определенные ресурсы
Доступ к данным	Все данные в рабочей области	Только данные для ресурсов, доступ к которым разрешен группе
Взаимодействие	Полный интерфейс Microsoft Sentinel, возможно, ограниченный функциональными разрешениями, назначенными пользователю	Только запросы журнала и книги

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

Альтернативные методы реализации RBAC в контексте ресурсов

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

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

Сценарий	Решение
В филиале есть группа SOC, которой требуется полноценное использование Microsoft Sentinel.	В этом случае используйте архитектуру с несколькими рабочими областями для разделения разрешений на данные. Дополнительные сведения см. в разделе: - Расширение Microsoft Sentinel на рабочие области и арендаторы - Работа с инцидентами одновременно в нескольких рабочих областях
Необходимо предоставить доступ к определенному типу события.	Например, предоставить администратору Windows доступ к событиям безопасности Windows во всех системах. В таких случаях для определения разрешений для каждой таблицы следует использовать RBAC на уровне таблицы.
Ограничение доступа на более детализированном уровне, не основанном на ресурсе, или только для части полей в событии	Например, может потребоваться ограничить доступ к журналам Office 365 на основе подразделения, к которому принадлежит пользователь. В этом случае предоставьте доступ к данным с помощью встроенной интеграции с панелями мониторинга и отчетами Power BI.

Явная настройка RBAC в контексте ресурсов

Следующие действия полезны, если требуется настроить RBAC в контексте ресурсов, но ваши данные не являются ресурсом Azure.

Например, данные в рабочей области Microsoft Sentinel, которые не являются ресурсами Azure, включают в себя данные Syslog, CEF или AAD, или данные, собранные пользовательским сборщиком.

Чтобы явно настроить RBAC в контексте ресурсов, выполните следующие действия.

1. Убедитесь, что в Azure Monitor включено RBAC в контексте ресурсов.

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

   Назначьте разрешения читателя журнала для каждого члена команды.

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

   Когда ресурсы Azure отправляют данные в Microsoft Sentinel, записи журнала автоматически помечаются идентификатором ресурса источника данных.

   Совет

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

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

   Дополнительные сведения об идентификаторах ресурсов см. в разделах:

   • Идентификаторы ресурсов с перенаправлением журнала
   • Идентификаторы ресурсов со сбором Logstash
   • Идентификаторы ресурсов со сбором API Log Analytics

Идентификаторы ресурсов с перенаправлением журнала

При сборе событий с помощью стандартного формата событий (CEF) или Syslog перенаправление журнала используется для сбора событий из нескольких исходных систем.

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

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

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

Совет

• При использовании локальной виртуальной машины или другой облачной виртуальной машины, например AWS, в качестве средства перенаправления журнала убедитесь, что у нее есть идентификатор ресурса, внедрив службу Azure Arc.
• Для масштабирования среды виртуальной машины с перенаправлением журнала рассмотрите возможность создания масштабируемого набора виртуальных машин для получения журналов CEF и Syslog.

Идентификаторы ресурсов со сбором Logstash

Если вы собираете данные с помощью подключаемого модуля вывода Logstash для Microsoft Sentinel, используйте поле azure_resource_id, чтобы настроить в пользовательском сборщике добавление идентификатора ресурса в выходные данные.

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

Например, в следующем коде показан пример файла конфигурации Logstash:

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Совет

Может потребоваться добавить несколько разделов output для различения тегов, применяемых к различным событиям.

Идентификаторы ресурсов со сбором API Log Analytics

При сборе с помощью API сборщика данных Log Analytics можно назначить событиям идентификатор ресурса, используя заголовок запроса HTTP x-ms-AzureResourceId.

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

Дальнейшие действия

Дополнительные сведения см. в статье Разрешения в Microsoft Sentinel.