Preparar-se para vários workspaces e locatários no Microsoft Sentinel
Artigo
Para se preparar para sua implantação, você precisa determinar se uma arquitetura de vários workspaces é relevante para seu ambiente. Neste artigo, você aprenderá como o Microsoft Sentinel pode se estender entre vários workspaces e locatários para que você possa determinar se essa funcionalidade atende às necessidades da sua organização. Este artigo faz parte do guia de implantação do Microsoft Sentinel.
Ao integrar o Microsoft Sentinel, sua primeira etapa é selecionar seu workspace do Log Analytics. Embora você possa obter todo o benefício da experiência do Microsoft Sentinel com um único workspace, em alguns casos, convém estender seu workspace para consultar e analisar seus dados entre workspaces e locatários.
Esta tabela lista alguns desses cenários e, quando possível, sugere como você pode usar um único workspace para o cenário.
Requisito
Descrição
Maneiras de reduzir a contagem de workspace
Soberania e conformidade regulatória
Um workspace está vinculado a uma região específica. Para manter dados em diferentes regiões geográficas do Azure para atender aos requisitos regulatórios, divida os dados em workspaces separados.
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.
Propriedade de dados
Os limites da propriedade de dados, por exemplo, por subsidiárias ou empresas afiliadas, ficam mais bem delineados com workspaces separados.
Vários locatários do Azure
O Microsoft Sentinel dá suporte à coleta de dados dos recursos de SaaS do Azure e da Microsoft somente dentro do próprio limite do locatário do Microsoft Entra. Portanto, cada locatário do Microsoft Entra requer um workspace separado.
Controle de acesso a dados granulares
Uma organização pode precisar permitir que diferentes grupos, dentro ou fora dela, acessem alguns dos dados coletados pelo Microsoft Sentinel. Por exemplo:
O acesso dos proprietários de recursos aos dados pertencentes aos seus recursos
Acesso regional ou subsidiário de SOCs aos dados relevantes para suas partes da organização
Historicamente, vários workspaces eram a única maneira de definir diferentes períodos de retenção para diferentes tipos de dados. Isso não é mais necessário em muitos casos, graças à introdução das configurações de retenção de nível de tabela.
Ao colocar workspaces em assinaturas separadas, eles podem ser faturados para diferentes partes.
Relatório de uso e cobrança cruzada
Arquitetura herdada
O uso de vários workspaces pode ser proveniente de um design histórico que levava em consideração limitações ou melhores práticas que não são mais aplicáveis. Também pode ser uma opção de design arbitrária que pode ser modificada para acomodar melhor o Microsoft Sentinel.
Os exemplos incluem:
Usando um workspace padrão por assinatura ao implantar o Microsoft Defender para Nuvem
A necessidade de controle de acesso granular ou configurações de retenção, cujas soluções são relativamente novas.
Rearquitetar workspaces
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.
MSSP (Provedor de Serviços de Segurança Gerenciada)
No caso de um MSSP, muitos, senão todos os requisitos acima se aplicam. Assim, a melhor prática é usar vários workspaces entre locatários. Especificamente, recomendamos que você crie pelo menos um espaço de trabalho para cada locatário do Microsoft Entra para oferecer suporte a conectores de dados integrados de serviço a serviço que funcionam apenas em seu próprio locatário do Microsoft Entra.
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.
Use o Azure Lighthouse para ajudar a gerenciar várias instâncias do Microsoft Sentinel em diferentes locatários.
Arquitetura de vários workspace do Microsoft Sentinel
Conforme implícito pelos requisitos acima, há casos em que um único SOC precisa gerenciar e monitorar centralmente vários Workspaces do Log Analytics habilitados para o Microsoft Sentinel, potencialmente em locatários do Microsoft Entra.
Um serviço do Microsoft Sentinel MSSP.
Um SOC global que atende a várias subsidiárias, cada uma com o próprio SOC local.
Um SOC monitorando vários locatários do Microsoft Entra em uma organização.
Para atender esses casos, o Microsoft Sentinel oferece funcionalidades de vários workspaces que permitem o monitoramento, a configuração e o gerenciamento central, fornecendo apenas um painel de controle com tudo que é relacionado ao SOC. Este diagrama mostra uma arquitetura de exemplo para esses casos de uso.
Esse modelo tem vantagens significativas em relação a um modelo totalmente centralizado no qual todos os dados são copiados para um workspace:
Atribuição de função flexível para o SOCs global e local, ou para a MSSP de seus clientes.
Menos desafios relacionados à propriedades de dados, à privacidade de dados e à conformidade regulatória.
Latência mínima de rede e preços.
Facilidade de integração e remoção de novas subsidiárias e clientes.
Próximas etapas
Neste artigo, você aprendeu a configurar o Microsoft Sentinel para se estender entre vários workspaces e locatários.