Proteção da propriedade intelectual do MSSP no Microsoft Sentinel
Este artigo descreve os métodos que os MSSPs (provedores de serviços de segurança gerenciados) podem usar para proteger a propriedade intelectual que eles desenvolveram no Microsoft Sentinel, como regras de análise, consultas de busca, guias estratégicos e pastas de trabalho do Microsoft Sentinel.
O método escolhido depende de como cada um de seus clientes compra o Azure. Se você atua como um CSP (provedor de soluções de nuvem), ou o cliente tem uma conta Enterprise Agreement (EA)/Pagamento Conforme o Uso (PAYG). As seções a seguir descrevem cada um desses métodos separadamente.
Provedores de Soluções de Nuvem (CSP)
Se estiver revendendo o Azure como um provedor de soluções de nuvem (CSP), você está gerenciando a assinatura do Azure do cliente. Graças ao administrador em nome de (AOBO), os usuários no grupo de Agentes de Administração do seu locatário do MSSP são concedidos com 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 do MSSP, fora do grupo de Agentes de Administração, precisarem acessar o ambiente do cliente, recomendamos que usar o Azure Lighthouse. O Azure Lighthouse permite conceder aos usuários ou grupos acesso a um escopo específico, como um grupo de recursos ou uma assinatura, usando uma das funções internas.
Se for necessário fornecer aos usuários clientes acesso ao ambiente do Azure, é recomendável conceder a eles acesso no nível do grupo de recursos, em vez de à assinatura toda, para possibilitar mostrar/ocultar partes do ambiente, conforme necessário.
Por exemplo:
É possível conceder ao cliente acesso a vários grupos de recursos em que os aplicativos estão localizados, mas ainda manter o workspace do Microsoft Sentinel em um grupo de recursos separado, ao qual o cliente não tem acesso.
Use esse método para permitir que os clientes exibam as pastas de trabalho e guias estratégicos selecionados, recursos separados que podem residir no próprio grupo de recursos.
Mesmo com a concessão de acesso no nível do grupo de recursos, os clientes ainda têm acesso aos dados de log dos recursos que eles podem acessar, como logs de uma VM, mesmo sem acesso ao Microsoft Sentinel. Para saber mais, consulte Gerenciar o acesso aos dados do Microsoft Sentinel por recurso.
Dica
Se for necessário fornecer aos clientes acesso à assinatura toda, talvez deseje ver as diretrizes em Contratos Enterprise (EA)/Pagamento Conforme o Uso (PAYG).
Amostra de arquitetura do CSP do Microsoft Sentinel
A imagem a seguir descreve como as permissões descritas na seção anterior podem funcionar ao fornecer acesso aos clientes do CSP:
Nesta imagem:
Os usuários com acesso de Proprietário à assinatura do CSP são os usuários no grupo de Agentes de Administração, no locatário do Microsoft Entra MSSP.
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 os componentes do Microsoft Sentinel conforme necessário, como regras de análise e consultas de busca.
Para obter mais informações, consulte a documentação do Azure Lighthouse.
Contratos Enterprise (EA)/Pago conforme o uso (PAYG)
Se o cliente estiver comprando diretamente da Microsoft, ele já terá acesso completo ao ambiente do Azure e você não poderá ocultar nada que esteja na assinatura do Azure do cliente.
Em vez disso, proteja a propriedade intelectual que você desenvolveu no Microsoft Sentinel da seguinte maneira, dependendo do tipo de recurso que precisa proteger:
Regras de análise e consultas de busca
As regras de análise e as consultas de busca 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 de leitor do Microsoft Sentinel, ele poderá exibir a consulta. Nesse caso, é recomendável hospedar suas regras de análise e consultas de busca em seu próprio locatário do MSSP, em vez do locatário do cliente.
Para fazer isso, é necessário um espaço de trabalho em seu próprio locatário com o Microsoft Sentinel habilitado e também precisará ver o espaço de trabalho do cliente por meio do Azure Lighthouse.
Para criar uma regra de análise ou uma consulta de busca no locatário MSSP que faz referência a dados no locatário do cliente, é necessário usar a instrução workspace da seguinte maneira:
workspace('<customer-workspace>').SecurityEvent
| where EventID == ‘4625’
Ao adicionar uma instrução workspace às regras de análise, considere o seguinte:
Nenhum alerta no workspace do cliente. As regras criadas dessa maneira não criam alertas ou incidentes no espaço de trabalho do cliente. Os alertas e incidentes existirão somente no seu espaço de trabalho do MSSP.
Criar alertas separados para cada cliente. Ao usar esse método, também recomendamos usar regras de alerta separadas para cada cliente e detecção, pois a instrução do espaço de trabalho é diferente em cada caso.
É possível adicionar o nome do cliente ao nome da regra de alerta para identificar facilmente o cliente onde o alerta é disparado. Alertas separados podem resultar em um grande número de regras, que talvez deseje gerenciar usando scripts ou o Microsoft Sentinel como código.
Por exemplo:
Crie workspaces do MSSP separados para cada cliente. A criação de regras separadas para cada cliente e detecção pode fazer atingir o número máximo de regras de análise para seu workspace (512). Se tiver muitos clientes e espera atingir esse limite, talvez queira criar um workspace do MSSP separado para cada cliente.
Por exemplo:
Importante
A chave para usar esse método com êxito é usar a automação para gerenciar um grande conjunto de regras em seus workspaces.
Para obter mais informações, consulte Regras de análise entre workspaces
Pastas de trabalho
Se tiver desenvolvido uma pasta de trabalho do Microsoft Sentinel que não deseja que seu cliente copie, hospede a pasta de trabalho no locatário do seu MSSP. Verifique se tem acesso aos workspaces do cliente por meio do Azure Lighthouse e certifique-se de modificar a pasta de trabalho para usar os workspaces do cliente.
Por exemplo:
Para obter mais informações, consulte Pastas de trabalho entre workspaces.
Se desejar que o cliente seja capaz de exibir as visualizações do workspace e ainda manter o segredo do código, a recomendação é exportar o workspace para o Power BI.
Exportar o workspace para o Power BI:
- Torna as visualizações do workspace mais fáceis de compartilhar. É possível enviar ao cliente um link para o painel do Power BI, no qual é possível exibir os dados relatados, sem a necessidade de permissões de acesso do Azure.
- Habilita o agendamento. Configure o Power BI para enviar emails periodicamente que contenham um instantâneo do painel para o horário.
Para obter mais informações, consulte Importar dados de log do Azure Monitor para o Power BI.
Guias estratégicos
É possível proteger guias estratégicos da seguinte maneira, dependendo de onde as regras analíticas que disparam o guia estratégico foram criadas:
Regras de análise criadas no workspace do MSSP. Certifique-se de criar os guias estratégicos no locatário do MSSP e de obter todos os dados de incidente e alerta do workspace do MSSP. É possível anexar os guias estratégicos sempre que criar uma nova regra em seu workspace.
Por exemplo:
Regras de análise criadas no workspace do cliente. Use o Azure Lighthouse para anexar regras de análise do workspace do cliente a um guia estratégico hospedado no workspace do MSSP. Nesse caso, o guia estratégico obtém os dados do alerta e do incidente e qualquer outra informação do cliente, do workspace do cliente.
Por exemplo:
Em ambos os casos, se o guia estratégico precisar acessar o ambiente do Azure do cliente, use um usuário ou uma entidade de serviço que tenha esse acesso via Lighthouse.
No entanto, se o playbook 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 playbook.
Observação
Se forem usadas regras de automação junto com os guias estratégicos, deverão ser definidas permissões de regra de automação no grupo de recursos em que os guias estratégicos residem. Para obter mais informações, consulte Permissões para regras de automação para executar guias estratégicos.
Próximas etapas
Para obter mais informações, consulte: