Gerenciar o acesso aos dados Microsoft Azure Sentinel por recurso

Artigo
10/17/2024

Normalmente, os usuários que têm acesso a um workspace do Log Analytics habilitado para Microsoft Sentinel também têm acesso a todos os dados do workspace, incluindo o conteúdo de segurança. Os administradores podem usar as funções do Azure para configurar o acesso a recursos específicos no Microsoft Azure Sentinel, dependendo dos requisitos de acesso em sua equipe.

No entanto, você pode ter alguns usuários que precisam acessar apenas dados específicos no workspace, mas não devem ter acesso a todo o ambiente do Microsoft Sentinel. Por exemplo, você pode desejar fornecer uma equipe de operações sem segurança (não SOC) com acesso aos dados de eventos do Windows para os servidores que eles possuem.

Nesses casos, recomendamos que você configure seu RBAC (controle de acesso baseado em função) com base nos recursos que são permitidos para seus usuários, em vez de fornecer acesso ao workspace ou recursos específicos do Microsoft Sentinel. Esse método também é conhecido como configuração do RBAC de contexto de recurso.

Quando os usuários têm acesso aos dados do Microsoft Sentinel por meio dos recursos que eles podem acessar em vez do workspace, eles podem exibir logs e pastas de trabalho usando os seguintes métodos:

Por meio do próprio recurso, como uma máquina virtual do Azure. Use este método para exibir logs e pastas de trabalho somente para um recurso específico.
Via Azure Monitor. Use esse método quando desejar criar consultas que abranjam vários recursos e/ou grupos de recursos. Ao navegar para logs e pastas de trabalho no Azure Monitor, defina o escopo para um ou mais grupos de recursos ou recursos específicos.

Habilite o RBAC de contexto de recurso no Azure Monitor. Para mais informações, consulte Gerenciar o acesso a dados de log e workspaces no Azure Monitor.

Observação

Se seus dados não forem um recurso do Azure, como dados do Microsoft Entra ID, Syslog ou CEF, ou dados coletados por um coletor personalizador, você precisará configurar manualmente a ID do recurso usada para identificar os dados e habilitar o acesso. Para obter mais informações, consulte Configurar explicitamente o RBAC de contexto de recurso para recursos que não são do Azure.

Além disso, as funções e pesquisas salvas não têm suporte em contextos centrados em recursos. Portanto, os recursos do Microsoft Azure Sentinel, como análise e normalização, não têm suporte para o RBAC de contexto de recursos no Microsoft Azure Sentinel.

Cenários para RBAC de contexto de recurso

A tabela a seguir realça os cenários em que o RBAC de contexto de recurso é mais útil. Observe as diferenças nos requisitos de acesso entre as equipes do SOC e as equipes não SOC.

Tipo de Requisito	Equipe do SOC	Equipe não SOC
Permissões	Todo o workspace	Apenas recursos específicos
Acesso a dados	Todos os dados no workspace	Somente os dados de recursos que a equipe tem autorização para acessar
Experiência	A experiência completa do Microsoft Azure Sentinel, possivelmente limitada pelas permissões funcionais atribuídas ao usuário	Somente consultas e Pastas de Trabalho de Log

Se sua equipe tiver requisitos de acesso semelhantes à equipe não SOC descrita na tabela acima, o RBAC de contexto de recurso poderá ser uma boa solução para sua organização.

Por exemplo, a imagem a seguir mostra uma versão simplificada de uma arquitetura de workspace em que as equipes de segurança e operações precisam acessar diferentes conjuntos de dados e o RBAC de contexto de recurso é usado para fornecer as permissões necessárias.

Nesta imagem:

O workspace do Log Analytics habilitado para Microsoft Sentinel é colocado em uma assinatura separada para isolar melhor as permissões da assinatura que as equipes de aplicativos usam para hospedar suas cargas de trabalho.
As equipes de aplicativos recebem acesso aos respectivos grupos de recursos, onde poderão gerenciar os recursos.

Essa assinatura separada e o RBAC de contexto de recurso permitem que essas equipes exibam os logs gerados pelos recursos aos quais tenham acesso, mesmo se os logs estiverem armazenados em um workspace onde não tenham acesso direto. As equipes de aplicativos podem acessar os logs por meio da área Logs do portal do Azure, para mostrar os logs de um recurso específico, ou por meio do Azure Monitor, para mostrar todos os logs que podem acessar simultaneamente.

Configurar explicitamente o RBAC de contexto de recurso para recursos que não são do Azure

Os recursos do Azure têm suporte interno para RBAC de contexto de recurso, mas podem exigir ajustes adicionais ao trabalhar com recursos não Azure. Por exemplo, os dados em seu workspace do Log Analytics habilitado para Microsoft Sentinel que não são recursos do Azure incluem dados Syslog, CEF ou AAD, ou dados coletados por um coletor personalizado.

Use as etapas a seguir se desejar configurar o RBAC de contexto de recurso, mas seus dados não são um recurso do Azure.

Para configurar explicitamente o RBAC de contexto de recurso:

Certifique-se de que você habilitou o RBAC de contexto de recurso no Azure monitor.
Crie um grupo de recursos para cada equipe de usuários que precisa acessar seus recursos sem todo o ambiente do Microsoft Azure Sentinel.

Atribua permissões de leitor de log para cada membro da equipe.
Atribua recursos aos grupos da equipe de recursos que você criou e marque os eventos com as IDs de recurso relevantes.

Quando os recursos do Azure enviam dados para o Microsoft Azure Sentinel, os registros de log são automaticamente marcados com a ID de recurso da fonte de dados.

Dica

É recomendável agrupar os recursos para os quais você está concedendo acesso em um grupo de recursos específico criado para fins de uso.

Se você não puder, certifique-se de que sua equipe tenha permissões de leitor de log diretamente para os recursos que você deseja que eles acessem.

Para obter mais informações sobre as IDs de recurso, visite:

IDs de recurso com encaminhamento de log

Quando os eventos são coletados usando o Formato de Evento Comum (CEF) ou Syslog, o encaminhamento de log é usado para coletar eventos de vários sistemas de origem.

Por exemplo, quando um CEF ou uma VM de encaminhamento de Syslog escuta as fontes que enviam eventos de Syslog e as encaminha para o Microsoft Azure Sentinel, a ID de recurso da VM de encaminhamento de log é atribuída a todos os eventos que eles encaminham.

Se você tiver várias equipes, certifique-se de que você tenha VMs de encaminhamento de log separadas processando os eventos para cada equipe separada.

Por exemplo, separar suas VMs garante que os eventos de syslog que pertencem à equipe A sejam coletados usando a VM do coletor A.

Dica

Ao usar uma VM local ou outra VM de nuvem, como AWS, como encaminhador de log, verifique se ela tem uma ID de recurso implementando o Azure Arc.
Para dimensionar o ambiente de VM de encaminhamento de log, considere criar um conjunto de dimensionamento de VM para coletar os logs de CEF e Sylog.

IDs de recurso com a coleção Logstash

Se você estiver coletando seus dados usando o plug-in de saída Logstash do Microsoft Azure Sentinel, use o campo azure_resource_id para configurar seu coletor personalizado para incluir a ID do recurso na saída.

Se você estiver usando o RBAC de contexto de recurso e quiser que os eventos coletados pela API estejam disponíveis para usuários específicos, use a ID de recurso do grupo de recursos que você criou para os usuários.

Por exemplo, o código a seguir mostra um exemplo de arquivo de configuração 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>   
     }
 }

Dica

Talvez você queira adicionar várias seções output para diferenciar as marcas aplicadas a diferentes eventos.

IDs de recurso com a coleção de API Log Analytics

Ao coletar usando a API do coletor de dados log Analytics, você pode atribuir a eventos com uma ID de recurso usando o cabeçalho de solicitação HTTP x-ms-AzureResourceId.

Alternativas ao RBAC de contexto de recurso

Dependendo das permissões necessárias em sua organização, usar o RBAC de contexto de recurso pode não fornecer uma solução completa. Por exemplo, considere se a organização, cuja arquitetura está descrita na seção anterior, também deve conceder acesso aos logs do Office 365 para uma equipe de auditoria interna. Nesse, caso é possível usar o RBAC no nível da tabela para conceder à equipe de auditoria acesso a toda a tabela OfficeActivity, sem conceder permissões a outras tabelas.

A lista a seguir descreve os cenários em que outras soluções de acesso a dados podem atender melhor às suas necessidades:

Cenário	Solução
Uma subsidiária tem uma equipe SOC que requer uma experiência completa do Microsoft Azure Sentinel.	Nesse caso, use uma arquitetura de vários espaços de trabalho para separar as permissões de dados. Para obter mais informações, consulte: Estender o Microsoft Azure Sentinel em workspaces e locatários >Como trabalhar com incidentes em muitos workspaces ao mesmo tempo
Você deseja fornecer acesso a um tipo específico de evento.	Por exemplo, forneça um administrador do Windows com acesso aos eventos de segurança do Windows em todos os sistemas. Nesses casos, use o RBAC em nível de tabela para definir permissões para cada tabela.
Limitar o acesso a um nível mais granular, não baseado no recurso ou apenas a um subconjunto dos campos em um evento	Por exemplo, talvez você queira limitar o acesso aos logs do Office 365 com base na subsidiária de um usuário. Nesse caso, forneça acesso a dados usando a integração interna com Power BI dashboards e relatórios.
Limitar o acesso por grupo de gerenciamento	Coloque o Microsoft Sentinel em um grupo de gerenciamento separado dedicado à segurança, garantindo que apenas as permissões sejam herdadas para membros do grupo. Em sua equipe de segurança, atribua permissões a grupos diferentes de acordo com cada função de grupo. Como todas as equipes têm acesso a todo o workspace, elas terão acesso à experiência completa do Microsoft Sentinel, restrita apenas pelas funções do Microsoft Sentinel às quais foram atribuídas. Para saber mais, veja Permissões no Microsoft Sentinel.

Próximas etapas

Para saber mais, confira Permissões no Microsoft Azure Sentinel.

Compartilhar via