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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

Схема примера архитектуры для контекста ресурсов RBAC.

В примере диаграммы архитектуры RBAC в контексте ресурса:

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

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

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

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

Для настройки ресурсно-контекстного RBAC для не-Azure данных выполните следующую процедуру.

Чтобы явно настроить RBAC для контекста ресурсов:

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

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

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

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

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

    Совет

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

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

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

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

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

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

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

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

Совет

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

Идентификаторы ресурсов при сборе данных с помощью Logstash

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

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

Например, следующий конфигурационный файл Logstash показывает, как принимать события через ввод Beats и отправлять их в рабочее пространство Log Analytics с помощью плагина вывода Microsoft Sentinel, при azure_resource_id этом поле задаёт метки событий определённой группой ресурсов для контекста ресурса RBAC:

 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Совет

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

Идентификаторы ресурсов для коллекции API Log Analytics

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

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

Альтернативы RBAC с учётом контекста ресурса

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

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

Сценарий Решение
У дочерней компании есть команда SOC, которая требует полного Microsoft Sentinel опыта. В этом случае используйте архитектуру с несколькими рабочими областями для разделения разрешений на доступ к данным.

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

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

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

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

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

  • Last updated on