Preparar-se para vários workspaces e locatários no Microsoft Sentinel
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.
Se você decidiu configurar seu ambiente para estender em workspaces, consulte Estender o Microsoft Sentinel em workspaces e locatários e Gerenciar centralmente vários workspaces do Microsoft Sentinel com o gerenciador de workspaces.
A necessidade de usar vários workspaces 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. | |
| Propriedade dos 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 granular | Uma organização pode precisar permitir que diferentes grupos, dentro ou fora dela, acessem alguns dos dados coletados pelo Microsoft Sentinel. Por exemplo:
|
Usar o recurso RBAC do Azure ou RBAC do Azure de nível de tabela |
| Configurações de retenção granular | 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. | Usar as configurações de retenção de nível de tabela ou automatizar a exclusão de dados |
| Cobrança dividida | 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:
|
Rearquitetar workspaces |
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. O MSSP pode usar o Azure Lighthouse para estender as funcionalidades entre workspaces do Microsoft Sentinel para todos os locatários.
Arquitetura de vários workspace do Microsoft Sentinel
Conforme implícito nos requisitos acima, há casos em que um único SOC precisa gerenciar e monitorar centralmente vários workspaces do 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.
Nas seções a seguir, explicaremos como operar esse modelo e, particularmente, como:
Monitorar centralmente vários workspaces, potencialmente entre locatários, fornecendo ao SOC um único painel de controle.
Configurar e gerenciar centralmente vários workspaces, potencialmente entre locatários, usando a automação.
Próximas etapas
Neste artigo, você aprendeu a configurar o Microsoft Sentinel para se estender entre vários workspaces e locatários.