Gerenciar o acesso aos dados do Microsoft Sentinel por recurso

O acesso a uma área de trabalho é gerido com Azure RBAC. Normalmente, os utilizadores que têm acesso a uma área de trabalho do Log Analytics ativada para Microsoft Sentinel também têm acesso a todos os dados da área de trabalho, incluindo conteúdo de segurança. Os administradores podem usar funções do Azure para configurar o acesso a recursos específicos no Microsoft Sentinel, dependendo dos requisitos de acesso da equipe.

No entanto, pode ter alguns utilizadores que precisam de aceder apenas a dados específicos na área de trabalho, mas não devem ter acesso a todo o ambiente Microsoft Sentinel. Por exemplo, poderá querer fornecer a uma equipa de operações não relacionadas com segurança (não SOC) acesso aos dados de eventos do Windows para os servidores que possuem.

Para usuários que precisam de acesso apenas a dados específicos no espaço de trabalho, recomendamos que você configure seu controle de acesso baseado em funções (RBAC) com base nos recursos permitidos a esses usuários, em vez de fornecer acesso ao espaço de trabalho ou a recursos específicos do Microsoft Sentinel. Esse método também é conhecido como a configuração de RBAC no contexto do recurso.

Quando os usuários têm acesso aos dados do Microsoft Sentinel por meio dos recursos que podem acessar, em vez do espaço de trabalho, eles podem visualizar 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 visualizar logs e pastas de trabalho apenas de um recurso específico.
Através do Monitor Azure. Utilize este método quando quiser criar consultas que abrangem vários recursos e/ou grupos de recursos. Ao acessar logs e pastas de trabalho no Azure Monitor, defina o escopo como um ou mais grupos de recursos ou recursos específicos.

Ative o RBAC de contexto de recursos no Azure Monitor. Para obter mais informações, veja Gerir o acesso a dados de registo e áreas de trabalho no Azure Monitor.

Observação

Se os seus dados não forem um recurso Azure, como o Syslog, o CEF ou Microsoft Entra ID dados ou dados recolhidos por um recoletor personalizado, terá de configurar manualmente o ID de recurso utilizado para identificar os dados e ativar o acesso. Para obter mais informações, veja Configurar explicitamente o RBAC de contexto de recursos para recursos não Azure.

Além disso, as funções e as pesquisas guardadas não são suportadas em contextos centrados em recursos. Portanto, funcionalidades do Microsoft Sentinel, como análise sintática e normalização, não têm suporte para RBAC no contexto do recurso no Microsoft Sentinel.

Cenários para RBAC com contexto de recursos

A tabela a seguir destaca os cenários em que o RBAC com contexto de recurso é mais útil. Tenha em atenção as diferenças nos requisitos de acesso entre equipas SOC e equipas não SOC.

Tipo de requisito	Equipe do SOC	Equipe que não pertence ao SOC
Permissões	Toda a área de trabalho	Apenas recursos específicos
Acesso a dados	Todos os dados na área de trabalho	Apenas os dados dos recursos aos quais a equipa está autorizada a aceder
Experiência	A experiência de Microsoft Sentinel completa, possivelmente limitada pelas permissões funcionais atribuídas ao utilizador	Somente consultas e Pastas de Trabalho de Log

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

Por exemplo, a imagem seguinte mostra uma versão simplificada de uma arquitetura de área de trabalho em que as equipas de segurança e operações precisam de acesso a diferentes conjuntos de dados e o RBAC de contexto de recursos é utilizado para fornecer as permissões necessárias.

No exemplo de diagrama de arquitetura RBAC entre recurso e contexto:

A área de trabalho do Log Analytics ativada para Microsoft Sentinel é colocada numa subscrição separada para isolar melhor as permissões da subscrição que as equipas de aplicações utilizam para alojar as respetivas cargas de trabalho.
As equipas de aplicações têm acesso aos respetivos grupos de recursos, onde podem gerir os respetivos recursos.

Colocar o espaço de trabalho em uma assinatura separada e usar RBAC no contexto de recursos permite que as equipes de aplicação visualizem logs gerados por quaisquer recursos aos quais tenham acesso, mesmo quando os logs estão armazenados em um workspace onde não têm acesso direto. As equipas de aplicações podem aceder aos respetivos registos através da área Registos do portal do Azure, para mostrar registos de um recurso específico, ou através do Monitor do Azure, para mostrar todos os registos a que podem aceder ao mesmo tempo.

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

Os recursos do Azure têm suporte nativo para RBAC com contexto de recurso, mas podem exigir ajustes adicionais ao trabalhar com recursos que não são do Azure. Por exemplo, dados no seu espaço de trabalho Log Analytics habilitado para o Microsoft Sentinel que não são recursos do Azure incluem dados do Syslog, CEF ou Microsoft Entra ID, ou dados coletados por um coletor personalizado.

Para configurar o RBAC em contexto de recurso para dados que não sejam do Azure, complete o procedimento a seguir.

Para configurar explicitamente o RBAC no contexto de recursos:

Certifique-se de que você tenha habilitado o RBAC no contexto do recurso no Azure Monitor.
Crie um grupo de recursos para cada equipa de utilizadores que precisa de aceder aos seus recursos sem todo o ambiente Microsoft Sentinel.

Atribua permissões de leitor de registos para cada um dos membros da equipa.
Atribua recursos aos grupos de equipa de recursos que criou e marque eventos com os IDs de recursos relevantes.

Quando Azure recursos enviam dados para Microsoft Sentinel, os registos são automaticamente etiquetados com o ID de recurso da origem de dados.

Dica

Recomendamos que agrupe os recursos para os quais está a conceder acesso num grupo de recursos específico criado para o efeito.

Se não conseguir, certifique-se de que sua equipe tenha permissões de leitura de logs diretamente nos recursos que você quer que ela acesse.

Para obter mais informações sobre os IDs de recursos, veja:

IDs de recurso com encaminhamento de log

Quando os eventos são recolhidos com o Common Event Format (CEF) ou o Syslog, o reencaminhamento de registos é utilizado para recolher 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 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 ter VMs separadas de encaminhamento de logs processando os eventos de cada equipe separadamente.

Por exemplo, separar suas VMs garante que os eventos de Syslog que pertencem à Equipe A sejam coletados usando a VM coletora A.

Dica

Ao utilizar uma VM no local ou outra VM na cloud, como o AWS, como o reencaminhador de registos, certifique-se de que tem um ID de recurso ao implementar 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 Syslog.

IDs de recurso com a coleção Logstash

Se estiver a recolher os seus dados com o plug-in de saída do Microsoft Sentinel Logstash, utilize o campo azure_resource_id para configurar o recoletor personalizado para incluir o ID de recurso na saída.

Se você está usando RBAC no contexto de recurso e quer que os eventos coletados pela API estejam disponíveis para usuários específicos, use o ID de recurso do grupo de recursos que você configurou em Configure explicitamente RBAC no contexto de recurso para recursos que não sejam do Azure.

Por exemplo, o seguinte arquivo de configuração Logstash mostra como ingerir eventos via entrada Beats e enviá-los para um workspace do Log Analytics usando o plugin de saída Microsoft Sentinel, com o azure_resource_id campo configurado para marcar eventos com um grupo de recursos específico para RBAC no contexto de recurso:

 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>   
     }
 }

Dica

Poderá querer adicionar várias output secções para diferenciar as etiquetas aplicadas a diferentes eventos.

IDs de recursos com a coleção da API do Log Analytics

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

Alternativas ao RBAC de contexto de recursos

Dependendo das permissões exigidas em sua organização, o uso do RBAC no contexto de recursos pode não satisfazer totalmente todos os requisitos de acesso a dados da sua organização. Por exemplo, considere se uma organização que utiliza a arquitetura de espaço de trabalho de assinatura separada descrita em Cenários para RBAC em contexto de recurso também deve conceder acesso aos logs do Office 365 a uma equipe interna de auditoria. Neste caso, podem utilizar o RBAC ao nível da tabela para conceder à equipa de auditoria acesso a toda a tabela OfficeActivity , sem conceder permissões a qualquer outra tabela.

A lista seguinte descreve cenários em que outras soluções para o acesso a dados podem corresponder melhor aos seus requisitos:

Cenário	Solução
Uma subsidiária tem uma equipa SOC que requer uma experiência de Microsoft Sentinel completa.	Neste caso, utilize uma arquitetura de várias áreas de trabalho para separar as permissões de dados. Para saber mais, confira: Expandir Microsoft Sentinel entre áreas de trabalho e inquilinos > Trabalhar com incidentes em muitas áreas de trabalho ao mesmo tempo
Quer fornecer acesso a um tipo específico de evento.	Por exemplo, forneça a um administrador do Windows acesso aos eventos de Segurança do Windows em todos os sistemas. Nestes casos, utilize o RBAC ao nível da 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 num evento	Por exemplo, poderá querer limitar o acesso a registos Office 365 com base na subsidiária de um utilizador. Neste caso, forneça acesso aos dados através da integração incorporada com dashboards e relatórios do Power BI.
Limitar o acesso por grupo de gestão	Coloque Microsoft Sentinel num grupo de gestão separado dedicado à segurança, garantindo que apenas as permissões mínimas são herdadas aos membros do grupo. Na sua equipa de segurança, atribua permissões a diferentes grupos de acordo com cada função de grupo. Uma vez que todas as equipas têm acesso a toda a área de trabalho, terão acesso à experiência de Microsoft Sentinel completa, restringida apenas pelas Microsoft Sentinel funções atribuídas. Para obter mais informações, veja Permissões no Microsoft Sentinel.

Para saber mais, confira:

Comentários

Esta página foi útil?

Last updated on 2026-08-14