Gerenciar o acesso aos dados Microsoft Azure Sentinel por recurso

Normalmente, os usuários que têm acesso a um espaço de trabalho do Microsoft Azure 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 workspace do Microsoft Azure Sentinel, mas não devem ter acesso a todo o ambiente do Microsoft Azure 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 do Microsoft Azure Sentinel ou a recursos específicos do Microsoft Azure 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 Azure Sentinel por meio dos recursos que eles podem acessar em vez do workspace do Microsoft Azure Sentinel, 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 de syslog, CEF ou AAD, ou dados coletados por um coletor personalizado, você precisará configurar manualmente a ID de recurso usada para identificar os dados e habilitar o acesso. Para obter mais informações, consulte Configurar explicitamente o RBAC de contexto de recurso.

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.

Métodos alternativos para implementar o 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.

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.

Configurar explicitamente o RBAC de contexto de recurso

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.

Por exemplo, os dados em seu workspace do Microsoft Azure Sentinel que não são recursos do Azure incluem dados Syslog, CEF ou AAD, ou dados coletados por um coletor personalizado.

Para configurar explicitamente o RBAC de contexto de recurso:

1. Certifique-se de que você habilitou o RBAC de contexto de recurso no Azure monitor.

2. 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.

3. 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
   • IDs de recurso com a coleção Logstash
   • IDs de recurso com a coleção de API Log Analytics

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.

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.

Próximas etapas

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