Gerir o acesso ao Microsoft Sentinel dados 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 utilizar Azure funções para configurar o acesso a funcionalidades específicas no Microsoft Sentinel, consoante os requisitos de acesso da equipa.

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.

Nestes casos, recomendamos que configure o seu controlo de acesso baseado em funções (RBAC) com base nos recursos que são permitidos aos seus utilizadores, em vez de lhes fornecer acesso à área de trabalho ou a funcionalidades de Microsoft Sentinel específicas. Este método também é conhecido como configurar o RBAC de contexto de recurso.

Quando os utilizadores têm acesso a Microsoft Sentinel dados através dos recursos aos quais podem aceder em vez da área de trabalho, podem ver registos e livros através dos seguintes métodos:

Através do próprio recurso, como um Azure Máquina Virtual. Utilize este método para ver registos e livros apenas para 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 navegar para registos e livros no Azure Monitor, defina o âmbito para 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.

Nota

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. Por conseguinte, Microsoft Sentinel funcionalidades como a análise e a normalização não são suportadas para o RBAC de contexto de recursos no Microsoft Sentinel.

Cenários para RBAC de contexto de recursos

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

Tipo de requisito	Equipa SOC	Equipa não 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ências	A experiência de Microsoft Sentinel completa, possivelmente limitada pelas permissões funcionais atribuídas ao utilizador	Apenas consultas de registo e Livros

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.

Nesta imagem:

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.

Esta subscrição separada e o RBAC de contexto de recursos permitem que estas equipas vejam os registos gerados por quaisquer recursos aos quais tenham acesso, mesmo quando os registos são armazenados numa área de trabalho 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 recursos para recursos não Azure

Azure recursos têm suporte incorporado para RBAC de contexto de recursos, mas podem exigir otimização adicional ao trabalhar com recursos não Azure. Por exemplo, os dados na área de trabalho do Log Analytics ativados para Microsoft Sentinel que não são Azure recursos incluem dados do Syslog, CEF ou AAD ou dados recolhidos por um recoletor personalizado.

Utilize os seguintes passos se quiser configurar o RBAC de contexto de recursos, mas os dados não forem um recurso Azure.

Para configurar explicitamente o RBAC de contexto de recursos:

Certifique-se de que ativou o RBAC de contexto de recursos 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.

Sugestão

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 a sua equipa tem permissões de leitor de registos diretamente para os recursos aos quais pretende que acedam.

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

IDs de recursos com reencaminhamento de registos

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 uma VM de reencaminhamento CEF ou Syslog escuta as origens que enviam eventos do Syslog e os reencaminha para Microsoft Sentinel, o ID de recurso da VM de reencaminhamento de registos é atribuído a todos os eventos reencaminhados.

Se tiver várias equipas, certifique-se de que tem VMs de reencaminhamento de registos separadas a processar os eventos para cada equipa separada.

Por exemplo, separar as VMs garante que os eventos do Syslog que pertencem à Equipa A são recolhidos com a VM A do recoletor.

Sugestão

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 da VM de reencaminhamento de registos, considere criar um conjunto de dimensionamento de VMs para recolher os registos CEF e Syslog.

IDs de recursos 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 estiver a utilizar o RBAC de contexto de recursos e quiser que os eventos recolhidos pela API estejam disponíveis para utilizadores específicos, utilize o ID de recurso do grupo de recursos que criou para os seus utilizadores.

Por exemplo, o código seguinte mostra um ficheiro de configuração logstash de exemplo:

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

Sugestão

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 recolher com a API do recoletor de dados do Log Analytics, pode atribuir a eventos com um ID de recurso com o cabeçalho do pedido HTTP x-ms-AzureResourceId .

Alternativas ao RBAC de contexto de recursos

Consoante as permissões necessárias na sua organização, a utilização do RBAC de contexto de recursos pode não fornecer uma solução completa. Por exemplo, considere se a organização cuja arquitetura está descrita na secção anterior também tem de conceder acesso a Office 365 registos a uma equipa de auditoria interna. 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 mais informações, consulte: 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 a Segurança do Windows eventos 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 mais informações, consulte:

Comentários

Esta página foi útil?

Last updated on 2026-04-23