Trabalhar com a solução do Microsoft Sentinel para aplicativos SAP em vários workspaces
Ao configurar seu espaço de trabalho do Log Analytics habilitado para o Microsoft Sentinel, você tem várias opções de arquitetura e fatores a considerar. Levando em consideração geografia, regulamentação, controle de acesso e outros fatores, você pode optar por ter vários espaços de trabalho em sua organização.
Este artigo discute como trabalhar com a solução do Microsoft Sentinel para aplicativos SAP em vários workspaces para diferentes cenários de implantação.
A solução do Microsoft Sentinel para aplicativos SAP dá suporte nativo a uma arquitetura entre workspaces para aceitar maior flexibilidade para:
- MSSPs (provedores de serviços de segurança gerenciada) ou um SOC (centro de operações de segurança) global ou federado.
- Requisitos de residência de dados.
- Design de hierarquia organização e TI.
- RBAC (controle de acesso baseado em função) insuficiente em um único workspace.
Importante
O trabalho com vários workspaces está atualmente em versão prévia. O recurso é fornecido sem um Contrato de Nível de Serviço. Para obter mais informações, consulte Termos de Uso Complementares de Versões Prévias do Microsoft Azure.
Você pode definir vários workspaces ao implantar o conteúdo de segurança do SAP.
Colaboração entre as equipes SOC e SAP em sua organização
Um caso de uso comum é quando a colaboração entre as equipes SOC e SAP em sua organização requer uma configuração de vários workspaces.
A equipe SAP da sua organização tem conhecimento técnico essencial para implementar com êxito e eficiência a solução do Microsoft Sentinel para aplicativos SAP. Portanto, é importante que a equipe SAP veja os dados relevantes e colabore com o SOC sobre os procedimentos de configuração e resposta a incidentes necessários.
Há dois cenários possíveis para a colaboração da equipe SOC e SAP, dependendo das necessidades da sua organização:
Cenário 1: dados SAP e dados SOC mantidos em workspaces separados. Ambas as equipes podem ver os dados SAP usando consultas entre workspaces.
Cenário 2: dados SAP mantidos somente no workspace do SOC. A equipe SAP pode consultar os dados usando consultas de contexto de recurso.
Cenário 1: dados SAP e dados SOC mantidos em workspaces separados
Nesse cenário, a equipe SAP e a equipe SOC têm espaços de trabalho separados do Log Analytics habilitados para o Microsoft Sentinel, onde os dados da equipe são mantidos.
Quando sua organização implanta a solução do Microsoft Sentinel para aplicativos SAP, cada equipe especifica seu workspace SAP.
Uma prática comum é fornecer a alguns ou a todos os membros da equipe SOC a função Leitor do Sentinel para o workspace SAP.
A criação de workspaces diferentes para os dados SAP e SOC têm estes benefícios:
O Microsoft Sentinel pode disparar alertas que incluem dados SOC e SAP e executar esses alertas no workspace SOC.
Observação
Para cenários SAP maiores, a execução de consultas feitas pelo SOC em dados do workspace SAP pode afetar o desempenho. Os dados SAP devem viajar para o workspace SOC quando estiverem sendo consultados. Para melhorar o desempenho e as otimizações de custo, considere ter os workspaces SOC e SAP no mesmo cluster dedicado.
A equipe SAP tem seu próprio espaço de trabalho Log Analytics habilitado para o Microsoft Sentinel que inclui todos os recursos, exceto detecções que incluem dados SOC e SAP.
Flexibilidade. A equipe SAP pode se concentrar no controle de ameaças internas em seu cenário, e o SOC pode se concentrar em ameaças externas.
Não há cobrança adicional por taxas de ingestão, porque os dados são ingeridos apenas uma vez no Microsoft Sentinel. No entanto, cada workspace tem seu próprio tipo de preço.
O SOC pode ver e investigar incidentes SAP. Se a equipe SAP enfrentar um evento que não pode explicar usando dados existentes, a equipe poderá atribuir o incidente ao SOC.
A tabela seguinte mapeia o acesso de dados e recursos para as equipes SAP e SOC nesse cenário.
| Função | Equipe do SOC | Equipe SAP |
|---|---|---|
| Acesso ao workspace do SOC | ✅ | ❌ |
| dados do workspace SAP, regras de análise, funções, watchlists e acesso a pastas de trabalho | ✅ | ✅1 |
| Colaboração e acesso a incidentes SAP | ✅ | ✅1 |
1 A equipe do SOC pode ver essas funções em ambos os workspaces. A equipe do SAP pode ver essas funções apenas no workspace do SAP.
Cenário 2: dados SAP mantidos somente no workspace do SOC
Nesse cenário, você deve manter todos os dados em um workspace e aplicar controles de acesso. Você pode fazer isso usando o Log Analytics no Azure Monitor para gerenciar o acesso aos dados por recurso. Você também pode associar recursos SAP a uma ID do recurso do Azure especificando o campo obrigatório azure_resource_id na seção de configuração do conector no coletor de dados que usou para ingerir dados do sistema SAP no Microsoft Sentinel.
Depois que o agente do coletor de dados for configurado com a ID do recurso correta, a equipe SAP poderá acessar os dados SAP específicos no workspace SOC usando uma consulta com escopo de recurso. A equipe SAP não pode ler nenhum dos outros tipos de dados não SAP.
Não há custos associados a essa abordagem, pois os dados são ingeridos apenas uma vez no Microsoft Sentinel. Quando você usa esse modo de acesso, a equipe SAP vê apenas dados brutos e não formatados. A equipe SAP não pode usar nenhum recurso do Microsoft Sentinel. Além de acessar os dados brutos por meio do Log Analytics, a equipe SAP pode acessar os mesmos dados por meio do Power BI.
Próxima etapa
Neste artigo, você aprendeu a trabalhar com a solução do Microsoft Sentinel para aplicativos SAP em vários workspaces para diferentes cenários de implantação. Em seguida, saiba como implantar a solução: