Gerenciar o acesso aos dados do Microsoft Sentinel por recurso

Artigo
10/16/2024

Normalmente, os usuários que têm acesso a um espaço de trabalho do Log Analytics habilitado para o Microsoft Sentinel também têm acesso a todos os dados do espaço 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 em sua equipe.

No entanto, você pode ter alguns usuários que precisam acessar apenas dados específicos em seu espaço de trabalho, mas não devem ter acesso a todo o ambiente do Microsoft Sentinel. Por exemplo, talvez você queira fornecer a uma equipe de operações não relacionadas à segurança (não SOC) acesso aos dados de eventos do Windows para os servidores de sua propriedade.

Nesses casos, recomendamos que você configure seu controle de acesso baseado em função (RBAC) com base nos recursos permitidos aos usuários, em vez de fornecer-lhes acesso ao espaço de trabalho ou a recursos específicos do Microsoft Sentinel. Esse método também é conhecido como configuração de RBAC de contexto de 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 exibir logs e pastas de trabalho usando os seguintes métodos:

Através do próprio recurso, como uma Máquina Virtual do Azure. Use esse método para exibir logs e pastas de trabalho somente para um recurso específico.
Através do Azure Monitor. Use esse método quando quiser criar consultas que abranjam vários recursos e/ou grupos de recursos. Ao navegar para logs e pastas de trabalho no Azure Monitor, defina seu escopo para um ou mais grupos de recursos ou recursos específicos.

Habilite o RBAC de contexto de recursos no Azure Monitor. Para obter mais informações, consulte Gerenciar o acesso a dados de log e espaços de trabalho no Azure Monitor.

Nota

Se seus dados não forem um recurso do Azure, como dados Syslog, CEF ou Microsoft Entra ID, ou dados coletados por um coletor personalizado, 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 recursos para recursos que não sejam do Azure.

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

Cenários para RBAC de contexto de recursos

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

Tipo de requisito	Equipa SOC	Equipa não-SOC
Permissões	Todo o espaço de trabalho	Apenas recursos específicos
Acesso aos dados	Todos os dados no espaço de trabalho	Somente dados para recursos que a equipe está autorizada a acessar
Experiência	A experiência completa do Microsoft Sentinel, possivelmente limitada pelas permissões funcionais atribuídas ao usuário	Somente consultas de log e pastas de trabalho

Se sua equipe tiver requisitos de acesso semelhantes aos da equipe não-SOC descritos na tabela acima, o RBAC de contexto de recursos pode ser uma boa solução para sua organização.

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

Nesta imagem:

O espaço de trabalho do Log Analytics habilitado para o 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 equipas de aplicações têm acesso aos respetivos grupos de recursos, onde podem gerir os seus recursos.

Esse RBAC separado de assinatura e contexto de recursos permite que essas equipes visualizem logs gerados por quaisquer recursos aos quais tenham acesso, mesmo quando os logs são armazenados em um espaço de trabalho onde não têm acesso direto. As equipes de aplicativos podem acessar seus logs por meio da área Logs do portal do Azure, para mostrar logs para um recurso específico, ou por meio do Azure Monitor, para mostrar todos os logs que podem acessar ao mesmo tempo.

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

Os recursos do Azure têm suporte interno para RBAC de contexto de recurso, mas podem exigir ajuste fino adicional ao trabalhar com recursos que não sejam do Azure. Por exemplo, os dados em seu espaço de trabalho do Log Analytics habilitado para o 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 quiser configurar o RBAC de contexto de recurso, mas seus dados não forem um recurso do Azure.

Para configurar explicitamente o RBAC de contexto de recurso:

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

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

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

Gorjeta

Recomendamos que você agrupe os recursos para os quais está concedendo acesso em um grupo de recursos específico criado para essa finalidade.

Se não for possível, 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 IDs de recursos, consulte:

IDs de recursos com encaminhamento de log

Quando os eventos são coletados usando o Common Event Format (CEF) ou o Syslog, o encaminhamento de logs é usado para coletar eventos de vários sistemas de origem.

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

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

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

Gorjeta

Ao usar uma VM local ou outra VM na nuvem, como a AWS, como seu encaminhador de log, verifique se ela tem uma ID de recurso implementando o Azure Arc.
Para dimensionar seu ambiente de VM de encaminhamento de log, considere a criação de um conjunto de escala de VM para coletar seus logs CEF e Sylog.

IDs de recursos com coleção Logstash

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

Se você estiver usando 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 criado para seus usuários.

Por exemplo, o código a seguir mostra um arquivo 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/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Gorjeta

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

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 a eventos com uma ID de recurso usando o cabeçalho de solicitação HTTP x-ms-AzureResourceId.

Alternativas ao RBAC de contexto de recursos

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

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

Scenario	Solução
Uma subsidiária tem uma equipe SOC que requer uma experiência completa do Microsoft Sentinel.	Nesse caso, use uma arquitetura de vários espaços de trabalho para separar suas permissões de dados. Para mais informações, consulte: Estenda o Microsoft Sentinel entre espaços de trabalho e locatários >Trabalhe com incidentes em vários espaços de trabalho ao mesmo tempo
Você deseja fornecer acesso a um tipo específico de evento.	Por exemplo, forneça a um administrador do Windows acesso a eventos de Segurança do Windows em todos os sistemas. Nesses casos, use RBAC no 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 a apenas 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 aos dados usando a integração interna com painéis e relatórios do Power BI.
Limitar o acesso por grupo de gerenciamento	Coloque o Microsoft Sentinel em um grupo de gerenciamento separado dedicado à segurança, garantindo que apenas permissões mínimas sejam herdadas para os membros do grupo. Dentro da sua equipa de segurança, atribua permissões a diferentes grupos de acordo com cada função de grupo. Como todas as equipes têm acesso a todo o espaço de trabalho, elas terão acesso à experiência completa do Microsoft Sentinel, restrita apenas pelas funções do Microsoft Sentinel que lhes foram atribuídas. Para obter mais informações, consulte Permissões no Microsoft Sentinel.

Próximos passos

Para obter mais informações, consulte Permissões no Microsoft Sentinel.

Partilhar via