Criar a arquitetura da área de trabalho do Microsoft Sentinel
Este artigo fornece uma árvore de decisão para ajudá-lo a tomar decisões importantes sobre como projetar sua arquitetura de espaço de trabalho do Microsoft Sentinel. Para obter mais informações, consulte Designs de espaço de trabalho de exemplo do Microsoft Sentinel e Práticas recomendadas de arquitetura de espaço de trabalho do Microsoft Sentinel. Este artigo faz parte do guia de implantação do Microsoft Sentinel.
Pré-requisitos
Antes de trabalhar na árvore de decisão, certifique-se de que tem as seguintes informações:
| Pré-requisito | Description |
|---|---|
| Requisitos regulamentares relacionados com a residência de dados do Azure | O Microsoft Sentinel pode ser executado em espaços de trabalho na maioria, mas não em todas as regiões suportadas no GA for Log Analytics. As regiões do Log Analytics recentemente suportadas podem levar algum tempo para integrar o serviço Microsoft Sentinel. Os dados gerados pelo Microsoft Sentinel, como incidentes, marcadores e regras de análise, podem conter alguns dados do cliente provenientes dos espaços de trabalho do Log Analytics do cliente. Para obter mais informações, consulte Disponibilidade geográfica e residência de dados. |
| Origens de dados | Descubra quais fontes de dados você precisa conectar, incluindo conectores internos para soluções Microsoft e não-Microsoft. Você também pode usar o Common Event Format (CEF), Syslog ou REST-API para conectar suas fontes de dados ao Microsoft Sentinel. Se você tiver VMs do Azure em vários locais do Azure dos quais precisa coletar os logs e a economia no custo de saída de dados for importante para você, você precisará calcular o custo de saída de dados usando a calculadora de preços de largura de banda para cada local do Azure. |
| Funções de usuário e níveis/permissões de acesso a dados | O Microsoft Sentinel usa o controle de acesso baseado em função do Azure (Azure RBAC) para fornecer funções internas que podem ser atribuídas a usuários, grupos e serviços no Azure. Todas as funções internas do Microsoft Sentinel concedem acesso de leitura aos dados em seu espaço de trabalho do Microsoft Sentinel. Portanto, você precisa descobrir se há necessidade de controlar o acesso aos dados por fonte de dados ou nível de linha, pois isso afetará a decisão de design do espaço de trabalho. Para obter mais informações, consulte Funções personalizadas e RBAC do Azure avançado. |
| Taxa de ingestão diária | A taxa de ingestão diária, geralmente em GB/dia, é um dos principais fatores no gerenciamento de custos e considerações de planejamento e design de espaço de trabalho para o Microsoft Sentinel. Na maioria dos ambientes híbridos e em nuvem, os dispositivos de rede, como firewalls ou proxies, e os servidores Windows e Linux produzem os dados mais ingeridos. Para obter os resultados mais precisos, a Microsoft recomenda um inventário exaustivo de fontes de dados. Como alternativa, a calculadora de custos do Microsoft Sentinel inclui tabelas úteis para estimar as pegadas das fontes de dados. Importante: Essas estimativas são um ponto de partida, e as configurações de verbosidade do log e a carga de trabalho produzirão variâncias. Recomendamos que monitorize o seu sistema regularmente para controlar quaisquer alterações. Recomenda-se um monitoramento regular com base no seu cenário. Para obter mais informações, consulte Detalhes de preços dos Logs do Azure Monitor. |
Árvore de decisões
A imagem a seguir mostra um fluxograma completo da árvore de decisão para ajudá-lo a entender a melhor forma de projetar seu espaço de trabalho.
As seções a seguir fornecem uma versão em texto completo dessa árvore de decisão, incluindo as seguintes notas referenciadas na imagem:
Nota #1 | Nota #2 | Nota #3 | Nota #4 | Nota #5 | Nota #6 | Nota #7 | Nota #8 | Nota #9 | Nota #10
Etapa 1: Espaço de trabalho novo ou existente?
Você tem um espaço de trabalho existente que pode ser usado para o Microsoft Sentinel?
Caso contrário, e você criará um novo espaço de trabalho em qualquer caso, continue diretamente com a etapa 2.
Se você tiver um espaço de trabalho existente que possa usar, considere a quantidade de dados que você estará ingerindo.
Etapa 2: Mantendo dados em diferentes geografias do Azure?
Se você tiver requisitos regulatórios para manter dados em diferentes geografias do Azure, use um espaço de trabalho separado do Microsoft Sentinel para cada região do Azure que tenha requisitos de conformidade. Para obter mais informações, consulte Considerações sobre região.
Se não precisar de manter dados em diferentes geografias do Azure, continue com o passo 3.
Etapa 3: Você tem vários locatários do Azure?
Se você tiver apenas um único locatário, continue diretamente com a etapa 4.
Se você tiver vários locatários do Azure, considere se está coletando logs específicos para um limite de locatário, como o Office 365 ou o Microsoft Defender XDR.
Se você não tiver nenhum log específico do locatário, continue diretamente com a etapa 4.
Se você estiver coletando logs específicos do locatário, use um espaço de trabalho separado do Microsoft Sentinel para cada locatário do Microsoft Entra. Continue com a etapa 4 para outras considerações.
Nota #1 da árvore de decisão: Os logs específicos dos limites do locatário, como do Office 365 e do Microsoft Defender for Cloud, só podem ser armazenados no espaço de trabalho dentro do mesmo locatário.
Embora seja possível usar coletores personalizados para coletar logs específicos do locatário de um espaço de trabalho em outro locatário, não recomendamos isso devido às seguintes desvantagens:
- Os dados coletados por conectores personalizados serão ingeridos em tabelas personalizadas. Portanto, você não poderá usar todas as regras e pastas de trabalho internas.
- As tabelas personalizadas não são consideradas por alguns dos recursos internos, como UEBA e regras de aprendizado de máquina.
- Custo e esforço adicionais necessários para os conectores personalizados, como usar o Azure Functions e os Aplicativos Lógicos.
Se essas desvantagens não forem uma preocupação para sua organização, continue com a etapa 4 em vez de usar espaços de trabalho separados do Microsoft Sentinel.
Passo 4: Dividir a faturação / estorno?
Se você precisar dividir seu faturamento ou estorno, considere se o relatório de uso ou a cobrança cruzada manual funciona para você.
Se não for necessário dividir a cobrança ou o estorno, continue com a etapa 5.
Se você precisar dividir o faturamento ou o estorno, considere usar a cobrança cruzada manual. Para obter custos precisos por entidade, você pode usar uma versão modificada da pasta de trabalho Custo do Microsoft Sentinel que divide o custo por entidade.
Se o relatório de utilização ou o carregamento cruzado manual funcionarem para si, continue com o passo 5.
Se nenhum relatório de uso ou cobrança cruzada manual funcionarem para você, use um espaço de trabalho separado do Microsoft Sentinel para cada proprietário de custo.
Nota #2 da árvore decisória: Para obter mais informações, consulte Custos e faturamento do Microsoft Sentinel.
Passo 5: Recolha de dados não SOC?
Se você não estiver coletando nenhum dado não-SOC, como dados operacionais, você pode pular diretamente para a etapa 6.
Se você estiver coletando dados não SOC, considere se há sobreposições, onde a mesma fonte de dados é necessária para dados SOC e não SOC.
Se você tiver sobreposições entre dados SOC e não SOC, trate os dados sobrepostos como dados SOC apenas. Em seguida, considere se a ingestão de dados SOC e não-SOC individualmente é inferior a 100 GB / dia, mas mais de 100 GB / dia quando combinados:
- Sim: Prossiga com o passo 6 para uma avaliação mais aprofundada.
- Não: não recomendamos o uso do mesmo espaço de trabalho por uma questão de eficiência de custos. Prossiga com o passo 6 para uma avaliação mais aprofundada.
Em ambos os casos, para mais informações, ver nota 10.
Se você não tiver dados sobrepostos, considere se a ingestão de dados SOC e não SOC individualmente é inferior a 100 GB / dia, mas mais de 100 GB / dia quando combinados:
Combinando seus dados SOC e não-SOC
Nota #3 da árvore de decisão: Embora geralmente recomendemos que os clientes mantenham um espaço de trabalho separado para seus dados não SOC para que os dados não SOC não estejam sujeitos aos custos do Microsoft Sentinel, pode haver situações em que combinar dados SOC e não SOC seja menos dispendioso do que separá-los.
Por exemplo, considere uma organização que tenha logs de segurança ingerindo a 50 GB/dia, logs de operações ingerindo a 50 GB/dia e um espaço de trabalho na região Leste dos EUA.
A tabela a seguir compara as opções de espaço de trabalho com e sem espaços de trabalho separados.
Nota
Os custos e termos listados na tabela a seguir são falsos e usados apenas para fins ilustrativos. Para obter informações atualizadas sobre custos, consulte a calculadora de preços do Microsoft Sentinel.
| Arquitetura do espaço de trabalho | Description |
|---|---|
| A equipe SOC tem seu próprio espaço de trabalho, com o Microsoft Sentinel habilitado. A equipe de operações tem seu próprio espaço de trabalho, sem o Microsoft Sentinel habilitado. |
Equipa SOC: O custo do Microsoft Sentinel para 50 GB/dia é de US$ 6.500 por mês. Os primeiros três meses de retenção são gratuitos. Equipa de operações: - O custo do Log Analytics em 50 GB/dia é de cerca de US $ 3.500 por mês. - Os primeiros 31 dias de retenção são gratuitos. O custo total para ambos é igual a US $ 10.000 por mês. |
| As equipes SOC e Ops compartilham o mesmo espaço de trabalho com o Microsoft Sentinel habilitado. | Ao combinar ambos os logs, a ingestão será de 100 GB/dia, qualificando-se para a elegibilidade para o Nível de Compromisso (50% para Sentinel e 15% para LA). Custo do Microsoft Sentinel para 100 GB / dia equivale a US $ 9.000 por mês. |
Neste exemplo, você teria uma economia de custos de US$ 1.000 por mês combinando ambos os espaços de trabalho, e a equipe de operações também desfrutará de 3 meses de retenção gratuita em vez de apenas 31 dias.
Este exemplo é relevante somente quando os dados SOC e não-SOC têm um tamanho de ingestão de >=50 GB/dia e <100 GB/dia.
Nota #10 da árvore de decisão: Recomendamos o uso de um espaço de trabalho separado para dados não SOC para que os dados não SOC não estejam sujeitos aos custos do Microsoft Sentinel.
No entanto, essa recomendação para espaços de trabalho separados para dados não SOC vem de uma perspetiva puramente baseada em custos, e há outros fatores de design importantes a serem examinados ao determinar se um ou vários espaços de trabalho devem ser usados. Para evitar custos de ingestão dupla, considere coletar dados sobrepostos em um único espaço de trabalho somente com o RBAC do Azure no nível da tabela.
Passo 6: Várias regiões?
Se você estiver coletando logs de VMs do Azure em uma única região, continue diretamente com a etapa 7.
Se você estiver coletando logs de VMs do Azure em várias regiões, quão preocupado você está com o custo de saída de dados?
Nota #4 da árvore de decisão: A saída de dados refere-se ao custo da largura de banda para mover dados para fora dos datacenters do Azure. Para obter mais informações, consulte Considerações sobre região.
Se reduzir a quantidade de esforço necessário para manter espaços de trabalho separados for uma prioridade, continue com a etapa 7.
Se o custo de saída de dados for uma preocupação suficiente para fazer valer a pena manter espaços de trabalho separados, use um espaço de trabalho separado do Microsoft Sentinel para cada região onde você precisa reduzir o custo de saída de dados.
Nota #5 da árvore de decisão: Recomendamos que você tenha o menor número possível de espaços de trabalho. Use a calculadora de preços do Azure para estimar o custo e determinar quais regiões você realmente precisa e combinar espaços de trabalho para regiões com baixos custos de saída. Os custos de largura de banda podem ser apenas uma pequena parte da sua fatura do Azure quando comparados com os custos de ingestão separados do Microsoft Sentinel e do Log Analytics.
Por exemplo, o seu custo pode ser estimado da seguinte forma:
- 1.000 VMs, cada uma gerando 1 GB/dia;
- Envio de dados de uma região dos EUA para uma região da UE;
- Usando uma taxa de compressão de 2:1 no agente
O cálculo para este custo estimado seria:
1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth costEsse custo de amostra seria muito menos dispendioso quando comparado com os custos mensais de um espaço de trabalho separado do Microsoft Sentinel e do Log Analytics.
Nota
Os custos listados são falsos e são usados apenas para fins ilustrativos. Para obter informações atualizadas sobre custos, consulte a calculadora de preços do Microsoft Sentinel.
Etapa 7: Segregar dados ou definir limites por propriedade?
Se você não precisar segregar dados ou definir limites de propriedade, continue diretamente com a etapa 8.
Se você precisar segregar dados ou definir limites com base na propriedade, cada proprietário de dados precisará usar o portal Microsoft Sentinel?
Se cada proprietário de dados precisar ter acesso ao portal do Microsoft Sentinel, use um espaço de trabalho separado do Microsoft Sentinel para cada proprietário.
Nota #6 da árvore de decisão: O acesso ao portal do Microsoft Sentinel requer que cada usuário tenha uma função de pelo menos um Microsoft Sentinel Reader, com permissões de Leitor em todas as tabelas no espaço de trabalho. Se um usuário não tiver acesso a todas as tabelas no espaço de trabalho, ele precisará usar o Log Analytics para acessar os logs nas consultas de pesquisa.
Se o acesso aos logs por meio do Log Analytics for suficiente para qualquer proprietário sem acesso ao portal do Microsoft Sentinel, continue com a etapa 8.
Para obter mais informações, consulte Permissões no Microsoft Sentinel.
Etapa 8: Controlando o acesso aos dados por fonte de dados / tabela?
Se você não precisar controlar o acesso aos dados por fonte ou tabela, use um único espaço de trabalho do Microsoft Sentinel.
Se você precisar controlar o acesso aos dados por origem ou tabela, considere o uso do RBAC de contexto de recursos nas seguintes situações:
Se você precisar controlar o acesso no nível da linha, como fornecer vários proprietários em cada fonte de dados ou tabela
Se você tiver várias fontes/tabelas de dados personalizadas, em que cada uma delas precisará de permissões separadas
Em outros casos, quando você não precisar controlar o acesso no nível da linha, forneça várias fontes/tabelas de dados personalizadas com permissões separadas, use um único espaço de trabalho do Microsoft Sentinel, com RBAC no nível de tabela para controle de acesso a dados.
Considerações para RBAC de contexto de recurso ou de nível de tabela
Ao planejar o uso do RBAC de contexto de recursos ou de nível de tabela, considere as seguintes informações:
Observação #7 da árvore de decisão: Para configurar o RBAC de contexto de recurso para recursos que não sejam do Azure, convém associar uma ID de Recurso aos dados ao enviar para o Microsoft Sentinel, para que a permissão possa ter escopo usando RBAC de contexto de recurso. Para obter mais informações, consulte Configurar explicitamente os modos RBAC e Access de contexto de recurso por implantação.
Nota #8 da árvore de decisão: Permissões de recursos ou contexto de recursos permite que os usuários visualizem logs apenas para recursos aos quais eles têm acesso. O modo de acesso ao espaço de trabalho deve ser definido como Permissões de recurso ou espaço de trabalho do usuário. Somente as tabelas relevantes para os recursos em que o usuário tem permissões serão incluídas nos resultados da pesquisa da página Logs no Microsoft Sentinel.
Nota #9 da árvore de decisão: O RBAC no nível da tabela permite definir um controle mais granular para os dados em um espaço de trabalho do Log Analytics, além das outras permissões. Esse controle permite que você defina tipos de dados específicos que são acessíveis apenas a um conjunto específico de usuários. Para obter mais informações, consulte RBAC de nível de tabela no Microsoft Sentinel.
Próximos passos
Neste artigo, você revisou uma árvore de decisão para ajudá-lo a tomar decisões importantes sobre como projetar sua arquitetura de espaço de trabalho do Microsoft Sentinel.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários