Melhores práticas da arquitetura de workspace do Microsoft Sentinel
Ao planejar a implantação do workspace do Microsoft Sentinel, você também deve projetar a arquitetura do workspace do Log Analytics. As decisões sobre a arquitetura do espaço de trabalho são normalmente orientadas por requisitos técnicos e de negócios. Este artigo analisa os principais fatores de decisão para ajudá-lo a determinar a arquitetura de espaço de trabalho certa para suas organizações, incluindo:
- Se você usará um único locatário ou vários locatários
- Todos os requisitos de conformidade que você tem para coleta e armazenamento de dados
- Como controlar o acesso aos dados do Microsoft Sentinel
- Implicações de custo para diferentes cenários
Para obter mais informações, consulte Projetar a arquitetura de workspace do Microsoft Sentinel, Exemplos de designs de workspace para cenários comuns e Atividades de pré-implantação e pré-requisitos para implantação do Microsoft Sentinel.
Confira nosso vídeo: Arquitetar o SecOps para obter êxito: práticas recomendadas para implantar o Microsoft Sentinel.
Este artigo faz parte do guia de implantação do Microsoft Sentinel.
Considerações sobre a locação
Embora menos espaços de trabalho sejam mais simples de gerenciar, você pode ter necessidades específicas para vários locatários e espaços de trabalho. Por exemplo, muitas organizações têm um ambiente de nuvem contendo vários locatários do Microsoft Entra, resultantes de fusões e aquisições ou devido a requisitos de separação de identidade.
Ao determinar quantos locatários e workspaces usar, considere que a maioria dos recursos do Microsoft Sentinel opera usando um único workspace ou instância do Microsoft Sentinel, e o Azure Sentinel ingere todos os logs alojados no workspace.
Os custos são uma das principais considerações ao determinar a arquitetura do Microsoft Sentinel. Para obter mais informações, consulte Custos e cobrança do Microsoft Sentinel.
Trabalhar com vários locatários
Se você tiver vários locatários, como um MSSP (provedor de serviços de segurança gerenciado), recomendamos que você crie pelo menos um espaço de trabalho para cada locatário do Microsoft Entra dar suporte a conectores de dados de serviço a serviço integrados que funcionam apenas em seu próprio locatário do Microsoft Entra.
Todos os conectores com base nas configurações de diagnóstico não podem ser conectados a um espaço de trabalho que não esteja localizado no mesmo locatário em que o recurso reside. Isso se aplica a conectores como Firewall do Azure, Armazenamento do Microsoft Azure, Azure Activity ou Microsoft Entra ID.
Use o Azure Lighthouse para ajudar a gerenciar várias instâncias do Microsoft Sentinel em diferentes locatários.
Observação
Os conectores de dados do parceiro normalmente são baseados em coleções de API ou agentes e, portanto, não são anexados a um locatário específico do Microsoft Entra.
Considerações de conformidade
Depois que os dados são coletados, armazenados e processados, a conformidade poderá se tornar um requisito de design importante, com um impacto significativo na arquitetura do Microsoft Sentinel. Ter a capacidade de validar e provar quem tem acesso a quais dados em todas as condições é um requisito de soberania de dados crítico em muitos países e regiões, e avaliar os riscos e obter insights nos fluxos de trabalho do Microsoft Sentinel é uma prioridade para muitos clientes.
No Microsoft Sentinel, os dados são armazenados e processados principalmente na mesma geografia ou região, com algumas exceções, como ao usar regras de detecção que aproveitam o aprendizado de máquina da Microsoft. Nesses casos, os dados podem ser copiados fora da geografia do espaço de trabalho para processamento.
Para saber mais, veja:
- Disponibilidade de geográfica e residência de dados
- Residência de dados no Azure
- Armazenamento e processamento de dados da UE na UE − blog de políticas da UE
Para começar a validar sua conformidade, avalie as fontes de dados e como e para onde os dados são enviados.
Observação
O agende do Log Analytics dá suporte a TLS 1.2 para garantir a segurança de dados em trânsito entre o agente e o serviço do Log Analytics, bem como o padrão FIPS 140.
Se você estiver enviando dados para uma geografia ou região diferente do workspace do Microsoft Sentinel, independentemente de o recurso de envio residir ou não no Azure, use um workspace na mesma geografia ou região.
Considerações sobre as regiões
Use instâncias separadas do Microsoft Sentinel para cada região. Embora o Microsoft Sentinel possa ser usado em várias regiões, você pode ter requisitos para separar dados por equipe, região ou site, ou regulamentos e controles que tornam os modelos de várias regiões impossíveis ou mais complexos do que o necessário. Usar instâncias e espaços de trabalho separados para cada região ajuda a evitar custos de largura de banda/saída para mover dados entre regiões.
Considere o seguinte ao trabalhar com várias regiões:
Os custos de saída geralmente se aplicam quando o agente do Azure Monitor ou Log Analytics é necessário para coletar logs, como em máquinas virtuais.
A saída da Internet também é cobrada, o que pode não afetar você, a menos que você exporte dados para fora do seu espaço de trabalho do Log Analytics. Por exemplo, você pode incorrer em despesas de saída da Internet se exportar os dados do Log Analytics para um servidor local.
Os custos de largura de banda variam dependendo da região de origem e destino e do método de coleta. Para obter mais informações, consulte:
Use modelos para as regras analíticas, consultas personalizadas, pastas de trabalho e outros recursos para tornar as implantações mais eficientes. Implante os modelos em vez de implantar manualmente cada recurso em cada região.
Os conectores baseados em configurações de diagnóstico não incorrem em custos de largura de banda. Para obter mais informações, confira Encargos de transferências de dados usando o Log Analytics.
Por exemplo, se você decidir coletar logs de máquinas virtuais no Leste dos EUA e enviá-los para um workspace do Microsoft Sentinel no Oeste dos EUA, serão cobrados os custos de entrada para a transferência de dados. Como o agente do Log Analytics compacta os dados em trânsito, o tamanho cobrado pela largura de banda pode ser menor do que o tamanho dos logs no Microsoft Sentinel.
Se você estiver coletando logs de Syslog e CEF de várias fontes ao redor do mundo, convém configurar um coletor de Syslog na mesma região que o workspace do Microsoft Sentinel para evitar custos de largura de banda, desde que a conformidade não seja uma preocupação.
Reconhecer se os custos de largura de banda justificam workspaces separados do Microsoft Sentinel dependem do volume de dados que você precisa transferir entre as regiões. Use a Calculadora de Preços do Azure para estimar os custos.
Para obter mais informações, consulte Residência de dados no Azure.
Considerações sobre o acesso
Você pode ter situações planejadas em que equipes diferentes precisarão acessar os mesmos dados. Por exemplo, a equipe do centro de operações de segurança deve ter acesso a todos os dados do Microsoft Sentinel, enquanto as equipes de operações e aplicativos precisarão acessar apenas partes específicas. Equipes de segurança independentes também podem precisar acessar os recursos do Microsoft Sentinel, mas com vários conjuntos de dados.
Combine RBAC de contexto de recurso e RBAC de nível de tabela para fornecer às suas equipes uma ampla gama de opções de acesso que devem dar suporte à maioria dos casos de uso.
Para saber mais, veja Permissões no Microsoft Sentinel.
RBAC de contexto de recurso
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 recurso é usado para fornecer as permissões necessárias.
Nesta imagem, o workspace do Microsoft Sentinel é colocado em uma assinatura separada para isolar melhor as permissões.
Observação
Outra opção, seria colocar o Microsoft Sentinel em um grupo de gerenciamento separado dedicado à segurança, o que garantiria que apenas as atribuições mínimas de permissão sejam herdadas. Dentro da equipe de segurança, vários grupos recebem permissões de acordo com as suas funções. Como essas equipes têm acesso a todo o workspace, elas terão acesso à experiência completa do Microsoft Sentinel, restrita apenas pelas funções do Azure Sentinel às quais foram atribuídas. Para saber mais, veja Permissões no Microsoft Sentinel.
Além da assinatura de segurança, uma assinatura separada é usada para que as equipes de aplicativos hospedem as 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.
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. Para obter mais informações, consulte Configurar explicitamente o RBAC de contexto de recurso.
RBAC no nível da tabela
O RBAC em nível de tabela permite definir os tipos de dados específicos (tabelas) para serem acessíveis apenas a um conjunto específico de usuários.
Por exemplo, considere se a organização, cuja arquitetura está descrita na imagem acima, 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 qualquer outra tabela.
Considerações sobre o acesso com vários espaços de trabalho
Se houver diferentes entidades, subsidiárias ou geografias na organização, cada uma com suas próprias equipes de segurança que precisam de acesso ao Microsoft Sentinel, use workspaces separados para cada entidade ou subsidiária. Implemente os espaços de trabalho separados em um único locatário do Microsoft Entra ou em vários locatários usando o Azure Lighthouse.
Sua equipe de centro de operações de segurança também poderá usar um workspace adicional do Microsoft Sentinel opcional para gerenciar artefatos centralizados, como regras de análise ou pastas de trabalho.
Para obter mais informações, consulte Simplificar o trabalho com vários espaços de trabalho.
Melhores práticas técnicas para criar o espaço de trabalho
Use a orientação de melhor prática a seguir ao criar o workspace do Log Analytics que você usará para o Microsoft Sentinel:
Ao nomear seu workspace, inclua o Microsoft Sentinel ou algum outro indicador no nome, para que seja facilmente identificado entre seus outros workspaces.
Use o mesmo workspace para o Microsoft Sentinel e o Microsoft Defender para Nuvem, para que todos os logs coletados pelo Microsoft Defender para Nuvem também possam ser ingeridos e usados pelo Microsoft Sentinel. O workspace padrão criado pelo Microsoft Defender para Nuvem não aparecerá como um workspace disponível para o Microsoft Sentinel.
Use um cluster de espaço de trabalho dedicado, se a ingestão de dados projetada for em torno ou mais de 1 TB por dia. Um cluster dedicado permite que você proteja os recursos dos seus dados do Microsoft Sentinel, o que permite melhor desempenho de consulta para grandes conjuntos de dados. Os clusters dedicados também oferecem a opção de mais criptografia e controle das chaves da sua organização.
Não aplique um bloqueio de recursos em um workspace do Log Analytics que você usará para o Microsoft Sentinel. Um bloqueio de recursos em um workspace pode fazer com que muitas operações do Microsoft Sentinel falhem.
Simplificar o trabalho com vários espaços de trabalho
Se for necessário trabalhar com vários workspaces, simplifique o gerenciamento e a investigação de incidentes, condensando e listando todos os incidentes de cada instância do Microsoft Sentinel em um único local.
Para referenciar dados mantidos em outros workspaces do Microsoft Sentinel, como em pastas de trabalho entre workspaces, use consultas entre workspaces.
O melhor momento para usar as consultas entre espaços de trabalho é quando informações valiosas são armazenadas em um espaço de trabalho, assinatura ou locatário diferente e podem agregar valor para sua ação atual. Por exemplo, o código a seguir mostra um exemplo de consulta entre espaços de trabalho:
union Update, workspace("contosoretail-it").Update, workspace("WORKSPACE ID").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification
Para obter mais informações, confira Estender o Microsoft Sentinel entre workspaces e locatários.
Próximas etapas
Neste artigo, você aprendeu sobre os principais fatores de decisão para ajudar a determinar a arquitetura correta do espaço de trabalho para sua organização.