Projetar a arquitetura de workspace do Microsoft Sentinel
Este artigo fornece uma árvore de decisão para ajudar você a tomar decisões importantes sobre como projetar a arquitetura de workspace do Microsoft Sentinel. Para obter mais informações, consulte Exemplos de projetos de workspace do Microsoft Sentinel e Melhores práticas da arquitetura de workspace 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, verifique se você tem as seguintes informações:
| Pré-requisito | Descrição |
|---|---|
| Determinações regulamentares relacionadas à residência de dados do Azure | O Microsoft Sentinel pode ser executado em workspaces na maioria, mas não em todas as regiões com suporte no GA para Log Analytics. As regiões do Log Analytics com suporte recente podem levar algum tempo para se integrarem ao serviço Microsoft Sentinel. Os dados gerados pelo Microsoft Sentinel, como incidentes, indicadores e regras de análise, podem conter alguns dados do cliente provenientes dos workspaces do Log Analytics do cliente. Para obter mais informações, consulte Disponibilidade geográfica e residência de dados. |
| Fontes de dados | Descubra quais fontes de dados você precisa conectar, incluindo conectores integrados para soluções Microsoft e não Microsoft. Também é possível usar o CEF (Formato Comum de Evento), o Syslog ou a API REST para conectar suas fontes de dados ao Microsoft Sentinel. Se você tiver VMs do Azure em vários locais do Azure dos quais você precisa coletar os logs e o custo de saída de dados de salvamento for importante para você, será necessário calcular o custo de egresso de dados usando a calculadora de preços de largura de banda para cada local do Azure. |
| Funções do 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 (RBAC do Azure) ,para fornecer funções internas que podem ser atribuídas a usuários, grupos e serviços no Azure. Todas as funções integradas no Microsoft Sentinel concedem acesso a leitura de dados no 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 projeto do workspace. Para obter mais informações, consulte Funções personalizadas e avançadas do Azure RBAC. |
| Taxa de ingestão diária | A taxa de ingestão diária, geralmente em GB/dia, é um dos principais fatores em considerações de planejamento e gerenciamento de custos e projeto de workspace para o Microsoft Sentinel. Na maioria dos ambientes de nuvem e híbridos, os dispositivos de rede, como firewalls ou proxies e 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 custo do Microsoft Sentinel inclui tabelas úteis para estimar o volume das fontes de dados. Importante: essas estimativas são um ponto de partida, e as configurações de detalhamento de log e a carga de trabalho produzirão variações. É recomendável monitorar o sistema regularmente para rastrear todas as alterações. O monitoramento regular é recomendado com base no cenário. Para saber mais, confira Detalhes de preço dos Logs do Azure Monitor. |
Árvore de decisão
A imagem a seguir mostra um fluxograma completo da árvore de decisão para ajudá-lo a reconhecer como projetar melhor o workspace.
As seções a seguir fornecem uma versão em texto completo desta árvore de decisão, incluindo as seguintes notas referenciadas na imagem:
Nota Nº. 1 | Nota Nº. 2 | Nota Nº. 3 | Nota Nº. 4 | Nota Nº. 5 | Nota Nº. 6 | Nota Nº. 7 | Nota Nº. 8 | Nota Nº. 9 | Nota Nº. 10
Etapa 1: workspace novo ou existente?
Você tem um workspace existente que pode ser usado para o Microsoft Sentinel?
Se não, em qualquer caso você criará um novo workspace, continue diretamente na etapa 2.
Se tiver um workspace existente que poderá ser usado, considere a quantidade de dados que irá ingerir.
Etapa 2: manter os dados em diferentes geografias do Azure?
Se houver determinações regulamentares para manter os dados em diferentes geografias do Azure, use um workspace separado do Microsoft Sentinel para cada região do Azure que tenha requisitos de conformidade. Para obter mais informações, consulte Considerações sobre a região.
Se não for necessário manter os dados em diferentes geografias do Azure, continue na etapa 3.
Etapa 3: você tem vários locatários do Azure?
Se tiver apenas um único locatário, continue diretamente na etapa 4.
Se você tiver vários locatários do Azure, considere se está coletando logs específicos de um limite de locatário, como o Office 365 ou o Microsoft Defender XDR.
Se não houver logs específicos do locatário, continue diretamente na etapa 4.
Se você estiver coletando logs específicos do locatário, use um workspace separado do Microsoft Sentinel para cada locatário do Microsoft Entra. Continue na etapa 4 para outras considerações.
Árvore de decisão, nota nº. 1: os logs específicos para os limites do locatário, como do Office 365 e Microsoft Defender para nuvem, somente podem ser armazenados no workspace dentro do mesmo locatário.
Embora seja possível usar coletores personalizados para coletar logs específicos do locatário de um workspace em outro locatário, não recomendamos isso devido às seguintes desvantagens:
- Os dados coletados por conectores personalizados serão inseridos em tabelas personalizadas. Portanto, não será possível usar todas as regras e pastas de trabalho integradas.
- As tabelas personalizadas não são consideradas por alguns dos recursos integrados, como UEBA e regras de aprendizado de máquina.
- O custo e o esforço adicionais necessários para os conectores personalizados, como o uso de Azure Functions e Aplicativos Lógicos.
Se essas desvantagens não forem uma preocupação para sua organização, continue na etapa 4, em vez de usar workspaces separados do Microsoft Sentinel.
Etapa 4: divisão de faturamento/encargo retroativo?
Se for necessário dividir a cobrança ou o encargo retroativo, verifique se os relatórios de uso ou cobrança cruzada manual serão ideais para você.
Se não for necessário dividir a cobrança ou o encargo retroativo, continue na etapa 5.
Se for necessário dividir a cobrança ou o encargo retroativo, 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 uso ou a cobrança cruzada manual forem ideais para você, continue na etapa 5.
Se nenhum relatório de uso ou cobrança cruzada manual for ideal para você, use um workspace do Microsoft Sentinel separado para cada proprietário do custo.
Árvore de decisão, nota nº. 2: para obter mais informações, consulte Custos e cobrança do Microsoft Sentinel.
Etapa 5: coletando dados não SOC?
Se você não estiver coletando dados não SOC, como dados operacionais, vá diretamente para a etapa 6.
Se você estiver coletando dados não SOC, verifique se há alguma sobreposição em que a mesma fonte de dados é necessária para dados SOC e não SOC.
Se houver sobreposições entre dados SOC e não SOC, trate os dados sobrepostos apenas como dados SOC. Em seguida, verifique se a ingestão de ambos os dados SOC e não SOC individualmente é menos de 100 GB/dia, mas mais de 100 GB/dia quando combinados:
- Sim: prossiga com a etapa 6 para avaliação adicional.
- Não: não é recomendável usar o mesmo workspace por uma questão de economia. Prossiga com a etapa 6 para avaliação adicional.
Em ambos os casos, para obter mais informações, consulte a nota 10.
Se você não tiver dados sobrepostos, verifique se a ingestão de ambos os dados SOC e não SOC individualmente é menos de 100 GB/dia, mas mais de 100 GB/dia quando combinados:
Combinando seus dados SOC e não SOC
Árvore de decisão, nota nº 3: embora geralmente seja recomendável que os clientes mantenham um workspace separado para os dados não SOC, de modo que os dados não SOC não estejam sujeitos aos custos do Microsoft Sentinel, poderá haver situações em que a combinação de dados SOC e não SOC seja menos dispendiosa do que separá-los.
Por exemplo, considere uma organização que tem ingestão de logs de segurança a 50 GB/dia, logs de operações ingerindo a 50 GB/dia e um workspace na região Leste dos EUA.
A tabela a seguir compara opções de workspace com e sem workspaces separados.
Observação
Os custos e os termos listados na tabela a seguir são fictícios e usados apenas para fins ilustrativos. Para obter informações sobre custos mais atualizadas, consulte a calculadora de preços do Microsoft Sentinel.
| Arquitetura do workspace | Descrição |
|---|---|
| A equipe SOC tem seu próprio workspace, com o Microsoft Sentinel habilitado. A equipe de operações tem seu próprio workspace, sem o Microsoft Sentinel habilitado. |
Equipe do SOC: O custo do Microsoft Sentinel para 50 GB/dia é de $50 por mês. Os primeiros três meses de retenção são gratuitos. Equipe do Ops: − O custo do Log Analytics a 50 GB/ ia é de cerca de $50 por mês. − Os primeiros 31 dias de retenção são gratuitos. O custo total de ambos é igual a $10.000 por mês. |
| As equipes SOC e de operações compartilham o mesmo workspace com o Microsoft Sentinel habilitado. | Ao combinar ambos os logs, a ingestão será de 100 GB/dia, qualificando-se para elegibilidade para o nível de compromisso (50% para Sentinel e 15% para LA). O custo do Microsoft Sentinel para 100 GB/dia é igual a $ 9.000 por mês. |
Neste exemplo, você teria uma economia de custo de $1.000 por mês, combinando ambos os workspaces, e a equipe de operações também se beneficiará de 3 meses de retenção gratuita em vez de apenas 31 dias.
Este exemplo é relevante apenas quando os dados SOC e não SOC têm cada um tamanho de ingestão de >=50 GB/dia e <100 GB/dia.
Árvore de decisão, nota nº. 10: é recomendável usar um workspace separado para dados não SOC, de modo que os dados não SOC não estejam sujeitos a custos do Microsoft Sentinel.
No entanto, essa recomendação para workspaces separados para dados não SOC origina-se de uma perspectiva puramente baseada em custos e há outros fatores de projeto importantes a serem examinados ao determinar se usará um único ou vários workspaces. Para evitar o dobro dos custos de ingestão, considere coletar dados sobrepostos em um único workspace apenas com Azure RBAC em nível de tabela.
Etapa 6: várias regiões?
Se você estiver coletando logs de VMs do Azure em uma única região apenas, continue na etapa 7.
Se você estiver coletando logs de VMs do Azure em várias regiões, quanto você está preocupado com o custo de saída de dados?
Árvore de decisão, nota nº. 4: a saída de dados se refere ao custo de largura de banda para mover dados para fora dos datacenters do Azure. Para obter mais informações, consulte Considerações sobre a região.
Se reduzir a quantidade de esforço necessária para manter workspaces separados for uma prioridade, continue na etapa 7.
Se o custo de saída de dados for uma preocupação suficiente para fazer a manutenção de workspaces separados valer a pena, use um workspace separado do Microsoft Sentinel para cada região onde você precisa reduzir o custo de saída de dados.
Árvore de decisão, nota nº. 5: é recomendável ter o mínimo de workspaces possível. Use a calculadora de preços do Azure para estimar o custo e determinar quais regiões realmente são necessárias e combinar workspaces para regiões com baixos custos de saída. Os custos de Largura de Banda podem ser apenas uma pequena parte de sua conta do Azure quando comparados com os custos de ingestão separados do Microsoft Sentinel e do Log Analytics.
Por exemplo, o custo pode ser estimado da seguinte maneira:
- 1\.000 VMs, cada uma gerando 1 GB/dia;
- Enviando dados de uma região dos EUA para uma região da Europa;
- Usando uma taxa de compressão de 2:1 no agente
O cálculo desse custo estimado seria:
1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth costEsse custo de exemplo seria muito mais barato em comparação com os custos mensais de um workspace do Log Analytics e do Microsoft Sentinel separado.
Observação
Os custos listados são fictícios e usados apenas para fins ilustrativos. Para obter informações sobre custos mais atualizadas, consulte a calculadora de preços do Microsoft Sentinel.
Etapa 7: separar dados ou definir limites por propriedade?
Se não for necessário segregar dados ou definir quaisquer limites de propriedade, continue diretamente na etapa 8.
Se for necessário segregar dados ou definir limites baseados na propriedade, , cada proprietário de dados precisará usar o portal do Microsoft Sentinel?
Se cada proprietário de dados precisar ter acesso ao portal do Microsoft Sentinel, use um workspace do Microsoft Sentinel separado para cada proprietário.
Árvore de decisão, nota nº. 6: o acesso ao portal do Microsoft Sentinel requer que cada usuário tenha uma função de pelo menos um Leitor do Microsoft Sentinel com permissões do Leitor em todas as tabelas no workspace. Se um usuário não tiver acesso a todas as tabelas no workspace, 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 na etapa 8.
Para saber mais, veja Permissões no Microsoft Sentinel.
Etapa 8: controlar o acesso aos dados por fonte de dados/tabela?
Se não for necessário controlar o acesso aos dados por fonte ou tabela, use um único workspace do Microsoft Sentinel.
Se for controlar o acesso aos dados por fonte ou tabela, considere usar RBAC de contexto de recurso nas seguintes situações:
Se for necessário 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 precisa de permissões separadas
Em outros casos, quando você nãoprecisa controlar o acesso no nível de linha, forneça várias fontes de dados/tabelas personalizadas com permissões separadas, use um único workspace do Azure Sentinel, com o RBAC no nível da tabela para controle de acesso a dados.
Considerações sobre o contexto de recurso ou o RBAC no nível da tabela
Ao planejar usar o contexto de recurso ou o RBAC no nível da tabela, considere as seguintes informações:
Árvore de decisão, nota nº 7: para configurar o RBAC de contexto de recurso para recursos que não são do Azure, talvez você queira associar uma ID de recurso aos dados ao enviar para o Microsoft Sentinel, para que a permissão possa ser no escopo usando o RBAC de contexto de recurso. Para obter mais informações, consulte Configure explicitamente o RBAC de contexto de recurso e Modos de acesso por implantação.
Árvore de decisão, nota nº. 8: as permissões de recurso ou contexto de recurso permitem que os usuários exibam os logs apenas para os recursos aos quais têm acesso. O modo de acesso do workspace deve ser definido como Permissões de recursos do usuário ou workspace. 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.
Árvore de decisão, nota nº. 9: RBAC em nível de tabela permite que você defina um controle mais granular para dados em um workspace do Log Analytics, além de outras permissões. Este controle permite definir 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óximas etapas
Neste artigo, você examinou uma árvore de decisão para ajudar a tomar decisões importantes sobre como projetar a arquitetura de workspace do Microsoft Sentinel.