Gerenciar o acesso aos dados Microsoft Azure Sentinel por recurso

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.

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.

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:

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.

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

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.

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:

Próximas etapas

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