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

Статья
10/16/2024

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

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

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

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

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

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

Примечание.

Если данные не являются ресурсом Azure, например syslog, CEF или идентификатором Microsoft Entra ID или данными, собранными настраиваемым сборщиком, необходимо вручную настроить идентификатор ресурса, используемый для идентификации данных и включения доступа. Дополнительные сведения см. в статье явной настройки контекста ресурсов RBAC для ресурсов, отличных от Azure.

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

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

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

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

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

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

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

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

Эта отдельная подписка и RBAC в контексте ресурсов позволяют данным командам просматривать журналы, созданные любыми ресурсами, к которым у них есть доступ, даже если журналы хранятся в рабочей области, к которой у них нет прямого доступа. Команды по разработке приложений могут получить доступ к своим журналам в области Журналы на портале Azure, где можно отобразить журналы для определенного ресурса, или в Azure Monitor, где можно одновременно отобразить все журналы, к которым у них есть доступ.

Явно настройте RBAC контекста ресурсов для ресурсов, отличных от Azure

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

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

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

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

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

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

Совет

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

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

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

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

При сборе событий с помощью стандартного формата событий (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

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

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

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

Следующие шаги

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

Поделиться через