Protegendo a propriedade intelectual do MSSP no Microsoft Sentinel
Este artigo descreve os métodos que os provedores de serviços de segurança gerenciados (MSSPs) podem usar para proteger a propriedade intelectual que desenvolveram no Microsoft Sentinel, como regras de análise do Microsoft Sentinel, consultas de caça, playbooks e pastas de trabalho.
O método escolhido depende de como cada um dos seus clientes compra o Azure; se você atua como um Provedor de Soluções na Nuvem (CSP) ou se o cliente tem uma conta Enterprise Agreement (EA)/Pay-as-you-go (PAYG). As seções a seguir descrevem cada um desses métodos separadamente.
Provedores de soluções na nuvem (CSP)
Se estiver a revender o Azure como um Fornecedor de Soluções na Nuvem (CSP), está a gerir a subscrição do Azure do cliente. Graças ao Admin-On-Behalf-Of (AOBO), os usuários no grupo Admin Agents do seu locatário MSSP recebem acesso de Proprietário à assinatura do Azure do cliente, e o cliente não tem acesso por padrão.
Se outros usuários do locatário MSSP, fora do grupo Agentes de Administração, precisarem acessar o ambiente do cliente, recomendamos que você use o Azure Lighthouse. O Azure Lighthouse permite que você conceda aos usuários ou grupos acesso a um escopo específico, como um grupo de recursos ou assinatura, usando uma das funções internas.
Se você precisar fornecer aos usuários clientes acesso ao ambiente do Azure, recomendamos que você conceda a eles acesso no nível do grupo de recursos, em vez da assinatura inteira, para que você possa mostrar/ocultar partes do ambiente conforme necessário.
Por exemplo:
Você pode conceder ao cliente acesso a vários grupos de recursos onde seus aplicativos estão localizados, mas ainda manter o espaço de trabalho do Microsoft Sentinel em um grupo de recursos separado, onde o cliente não tem acesso.
Use esse método para permitir que os clientes visualizem pastas de trabalho e playbooks selecionados, que são recursos separados que podem residir em seu próprio grupo de recursos.
Mesmo com a concessão de acesso no nível do grupo de recursos, os clientes têm acesso aos dados de log para os recursos que podem acessar, como logs de uma VM, mesmo sem acesso ao Microsoft Sentinel. Para obter mais informações, consulte Gerenciar o acesso aos dados do Microsoft Sentinel por recurso.
Gorjeta
Se precisar de fornecer aos seus clientes acesso a toda a subscrição, poderá consultar as orientações em Enterprise Agreements (EA) / Pay-as-you-go (PAYG).
Exemplo de arquitetura CSP do Microsoft Sentinel
A imagem a seguir descreve como as permissões descritas na seção anterior podem funcionar ao fornecer acesso a clientes CSP:
Nesta imagem:
Os usuários aos quais foi concedido acesso de Proprietário à assinatura do CSP são os usuários do grupo Agentes de Administração, no locatário do MSSP Microsoft Entra.
Outros grupos do MSSP obtêm acesso ao ambiente do cliente por meio do Azure Lighthouse.
O acesso do cliente aos recursos do Azure é gerenciado pelo RBAC do Azure no nível do grupo de recursos.
Isso permite que os MSSPs ocultem componentes do Microsoft Sentinel conforme necessário, como regras do Google Analytics e consultas de caça.
Para obter mais informações, consulte também a documentação do Azure Lighthouse.
Acordos Enterprise (EA) / Pay-as-you-go (PAYG)
Se o cliente estiver comprando diretamente da Microsoft, ele já tem acesso total ao ambiente do Azure e você não pode ocultar nada que esteja na assinatura do Azure do cliente.
Em vez disso, proteja sua propriedade intelectual desenvolvida no Microsoft Sentinel da seguinte maneira, dependendo do tipo de recurso que você precisa proteger:
Regras de análise e consultas de caça
As regras de análise e as consultas de caça estão contidas no Microsoft Sentinel e, portanto, não podem ser separadas do espaço de trabalho do Microsoft Sentinel.
Mesmo que um usuário tenha apenas permissões do Microsoft Sentinel Reader, ele poderá exibir a consulta. Nesse caso, recomendamos hospedar suas regras do Google Analytics e procurar consultas em seu próprio locatário MSSP, em vez do locatário do cliente.
Para fazer isso, você precisa de um espaço de trabalho em seu próprio locatário com o Microsoft Sentinel habilitado e também precisa ver o espaço de trabalho do cliente por meio do Azure Lighthouse.
Para criar uma regra analítica ou consulta de caça no locatário MSSP que faz referência a dados no locatário do cliente, você deve usar a workspace instrução da seguinte maneira:
workspace('<customer-workspace>').SecurityEvent
| where EventID == ‘4625’
Ao adicionar uma workspace instrução às suas regras de análise, considere o seguinte:
Nenhum alerta no espaço de trabalho do cliente. As regras criadas dessa maneira não criam alertas ou incidentes no espaço de trabalho do cliente. Os alertas e incidentes existem apenas no espaço de trabalho MSSP.
Crie alertas separados para cada cliente. Ao usar esse método, também recomendamos que você use regras de alerta separadas para cada cliente e deteção, pois a instrução do espaço de trabalho é diferente em cada caso.
Você pode adicionar o nome do cliente ao nome da regra de alerta para identificar facilmente o cliente onde o alerta é acionado. Alertas separados podem resultar em um grande número de regras, que você pode querer gerenciar usando scripts ou o Microsoft Sentinel como código.
Por exemplo:
Crie espaços de trabalho MSSP separados para cada cliente. Criar regras separadas para cada cliente e deteção pode fazer com que você atinja o número máximo de regras de análise para seu espaço de trabalho (512). Se você tiver muitos clientes e espera atingir esse limite, convém criar um espaço de trabalho MSSP separado para cada cliente.
Por exemplo:
Importante
A chave para usar esse método com sucesso é usar a automação para gerenciar um grande conjunto de regras em seus espaços de trabalho.
Para obter mais informações, consulte Regras de análise entre espaços de trabalho
Livros
Se você desenvolveu uma pasta de trabalho do Microsoft Sentinel que não deseja que o cliente copie, hospede a pasta de trabalho em seu locatário MSSP. Certifique-se de que tem acesso aos espaços de trabalho do cliente através do Azure Lighthouse e, em seguida, certifique-se de que modifica o livro para utilizar esses espaços de trabalho do cliente.
Por exemplo:
Para obter mais informações, consulte Pastas de trabalho entre espaços de trabalho.
Se você quiser que o cliente possa exibir as visualizações da pasta de trabalho, mantendo o código secreto, recomendamos que você exporte a pasta de trabalho para o Power BI.
Exportando sua pasta de trabalho para o Power BI:
- Torna as visualizações da pasta de trabalho mais fáceis de compartilhar. Você pode enviar ao cliente um link para o painel do Power BI, onde ele pode exibir os dados relatados, sem exigir permissões de acesso do Azure.
- Permite o agendamento. Configure o Power BI para enviar emails periodicamente que contenham um instantâneo do painel para esse período.
Para obter mais informações, consulte Importar dados de log do Azure Monitor para o Power BI.
Manuais de Procedimentos
Você pode proteger seus playbooks da seguinte forma, dependendo de onde as regras analíticas que acionam o playbook foram criadas:
Regras de análise criadas no espaço de trabalho MSSP. Certifique-se de criar seus playbooks no locatário do MSSP e de obter todos os dados de incidentes e alertas do espaço de trabalho do MSSP. Você pode anexar os playbooks sempre que criar uma nova regra em seu espaço de trabalho.
Por exemplo:
Regras de análise criadas no espaço de trabalho do cliente. Use o Azure Lighthouse para anexar regras de análise do espaço de trabalho do cliente a um playbook hospedado em seu espaço de trabalho MSSP. Nesse caso, o manual obtém os dados de alerta e incidente, e quaisquer outras informações do cliente, do espaço de trabalho do cliente.
Por exemplo:
Em ambos os casos, se o manual precisar acessar o ambiente do Azure do cliente, use um usuário ou entidade de serviço que tenha esse acesso via Lighthouse.
No entanto, se o manual precisar acessar recursos que não sejam do Azure no locatário do cliente, como o Microsoft Entra ID, o Office 365 ou o Microsoft Defender XDR, crie uma entidade de serviço com permissões apropriadas no locatário do cliente e adicione essa identidade no manual.
Nota
Se você usar regras de automação junto com seus playbooks, deverá definir as permissões da regra de automação no grupo de recursos em que os playbooks vivem. Para obter mais informações, consulte Permissões para regras de automação para executar playbooks.
Próximos passos
Para obter mais informações, consulte: