Automatizar a integração do Sentinel com o Azure DevOps

Este artigo descreve como automatizar as operações de integração e implantação do Microsoft Sentinel com o Azure DevOps. Implemente o Azure DevOps usando os recursos do Microsoft Sentinel para ajudar a proteger sua implantação. Em seguida, você usa uma estrutura DevSecOps para gerenciar e implantar artefatos do Microsoft Sentinel em escala.

Arquitetura

O diagrama a seguir mostra uma instalação do Azure DevOps e do Microsoft Sentinel IaC.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados

1. O scrum master e o gerenciamento de produtos usam o Azure DevOps para definir epics, histórias de usuário e itens de backlog do produto como parte da lista de pendências do projeto.
   • O scrum master e o gerenciamento de produtos usam o Azure Boards para criar a lista de pendências, agendar o trabalho em sprints, examinar o quadro de projetos, criar a estrutura do repositório e definir regras de segurança, como fluxos de trabalho e branches de aprovação.
   • O repositório Git do Azure armazena os scripts e as permissões para gerenciar artefatos do Microsoft Sentinel na infraestrutura como código.
   • Artefatos e controle do código-fonte mantêm as extensões e atualizam pacotes ou componentes do fluxo de trabalho de DevSecOps que são usados na solução, como o Kit de Ferramentas de Modelo do Azure Resource Manager e o Pester do PowerShell.
2. Artefatos do Microsoft Sentinel:
   • Políticas. Os engenheiros do SIEM usam políticas do Azure na arquitetura de referência para definir e dimensionar as configurações de diagnóstico dos serviços do Azure. As políticas ajudam a automatizar a implantação dos conectores de dados do Microsoft Sentinel, como o Azure Key Vault. As políticas dependem da API OMSIntegration.
   • Conectores. O Microsoft Sentinel usa conectores lógicos, os Conectores de Dados do Azure, para ingerir dados de segurança, como em auditorias ou métricas, de fontes de dados com suporte, como Microsoft Entra ID, recursos do Azure, Microsoft Defender ou soluções de terceiros. A lista principal de conectores de dados é gerenciada pela API SecurityInsights. Outros dependem da API OMSIntegration e são gerenciados com as configurações de diagnóstico do Azure Policy.
   • Identidade Gerenciada. O Microsoft Sentinel usa a identidade gerenciada para agir em nome da MSI (identidade de serviço gerenciado) ao interagir com guias estratégicos, aplicativos lógicos ou runbooks de automação e o cofre de chaves.
   • Automação. As equipes do SOC usam a automação durante as investigações. As equipes do SOC executam procedimentos de aquisição de dados forenses digitais com a Automação do Azure, como a cadeia de custódia da VM (máquina virtual) do Azure ou a Descoberta Eletrônica (Premium) do Microsoft Defender.
   • Análise. Analistas de SOC ou caçadores de ameaças usam regras de análise internas ou personalizadas para analisar e correlacionar dados no Microsoft Sentinel ou para disparar guias estratégicos se uma ameaça e um incidente forem identificados.
   • Guias estratégicos. Os aplicativos lógicos executam as ações repetíveis do SecOps, como atribuir um incidente, atualizar um incidente ou executar ações de correção, como isolar ou conter uma VM, revogar um token ou redefinir uma senha de usuário.
   • Busca de ameaças. Os caçadores de ameaças usam recursos proativos de busca de ameaças que podem ser associados a notebooks Jupyter para casos de uso avançado, como processamento de dados, manipulação de dados, visualização de dados, aprendizado de máquina ou aprendizado profundo.
   • Workbooks. Os engenheiros do SIEM usam painéis de Pastas de Trabalho para visualizar tendências e estatísticas e exibir o status de uma instância do Microsoft Sentinel e seus subcomponentes.
   • Inteligência contra ameaças. Um conector de dados específico que funde plataformas de inteligência contra ameaças se alimenta do Microsoft Sentinel. Há suporte para dois métodos de conectividade: TAXII e API do Graph. Ambos os métodos servem como tiIndicators ou indicadores de inteligência contra ameaças em APIs de segurança.
3. Microsoft Entra ID. Os recursos de gerenciamento de identidade e acesso são entregues a componentes usados na arquitetura de referência, como identidades gerenciadas, entidades de serviço, RBACs (controles de acesso baseados em função) do Azure para Microsoft Sentinel, aplicativos lógicos e runbooks de automação.
4. Azure Pipelines. Os engenheiros do DevOps usam pipelines para criar conexões de serviço para gerenciar as diferentes assinaturas do Azure, como os ambientes de área restrita e de produção com pipelines de CI/CD (integração contínua e entrega contínua). É recomendável usar fluxos de trabalho de aprovação para evitar implantações inesperadas e entidades de serviço separadas se você direcionar várias assinaturas por ambiente do Azure.
5. Azure Key Vault. Os engenheiros do SOC usam o cofre de chaves para armazenar com segurança os segredos e certificados da entidade de serviço. Esse componente da arquitetura ajuda a impor o princípio DevSecOps de nenhum segredo no código quando usado por conexões de serviço do Azure Pipeline.
6. Assinatura do Azure. As equipes do SOC usam duas instâncias do Microsoft Sentinel nessa arquitetura de referência, separadas em duas assinaturas lógicas do Azure para simular ambientes de produção e área restrita. Você pode dimensionar para suas necessidades com outros ambientes, como teste, desenvolvimento, pré-produção e assim por diante.

Exemplo de fluxo de dados

1. Um administrador adiciona, atualiza ou exclui uma entrada em sua bifurcação do arquivo de configuração do Microsoft 365.
2. O administrador confirma e sincroniza as alterações em seu repositório bifurcado.
3. Em seguida, o administrador cria uma PR (pull request) para mesclar as alterações no repositório principal.
4. O pipeline de build é executado na PR.

Componentes

• O Microsoft Entra ID é um serviço baseado em nuvem para gerenciar seus controles de identidade e acesso.
• O Azure DevOps é um serviço de nuvem para colaborar no código, compilação implantação de aplicativos ou para planejar e acompanhar seu trabalho.
• O Azure Key Vault é serviço de nuvem para armazenar e acessar segredos de maneira segura. Um segredo é qualquer coisa a qual você queira controlar rigidamente o acesso, como chaves de API, senhas, certificados ou chaves criptográficas.
• O Azure Policy é um serviço no Azure para criar, atribuir e gerenciar definições de política em seu ambiente do Azure.
• O Microsoft Sentinel é uma solução escalonável, nativa de nuvem, SIEM e de orquestração de segurança, automação e resposta (SOAR).
• A Automação do Azure é um serviço para simplificar o gerenciamento de nuvem por meio da automação de processo. Use a Automação do Azure para automatizar tarefas longas, manuais, propensas a erros e repetidas com frequência. A automação ajuda a melhorar a confiabilidade, a eficiência e o tempo de valorização para sua empresa.

Detalhes do cenário

As equipes do SOC (Centro de Operações de Segurança) às vezes enfrentam desafios ao integrar o Microsoft Sentinel ao Azure DevOps. O processo envolve muitas etapas, e a configuração pode levar dias e envolver repetição. Você pode automatizar essa parte do desenvolvimento.

Para modernizar para a nuvem, os engenheiros devem aprender constantemente novas habilidades e técnicas para proteger e proteger ativos de negócios vitais. Os engenheiros devem criar soluções robustas e escalonáveis que acompanhem o cenário de segurança em mudança e com as necessidades dos negócios. Uma solução de segurança deve ser flexível, ágil e cuidadosamente planejada desde os estágios iniciais de desenvolvimento. Essa metodologia de planejamento antecipado é conhecida como shift-left.

Este artigo descreve como automatizar as operações de integração e implantação do Microsoft Sentinel com o Azure DevOps. Você pode expandir a solução para organizações complexas que têm várias entidades, assinaturas e vários modelos operacionais. Alguns dos modelos operacionais compatíveis com essa solução incluem SOC local, SOC global, CSP (provedor de serviços de nuvem) e MSSP (provedor de serviços de segurança gerenciada).

Este artigo é destinado aos seguintes públicos-alvo:

• Especialistas do SOC, como analistas e caçadores de ameaças
• Engenheiros de SIEM (gerenciamento de eventos e informações de segurança)
• Arquitetos de segurança cibernética
• Desenvolvedores

Possíveis casos de uso

A seguir estão os casos de uso típicos para esta arquitetura:

• Criação rápida e prova de conceito. Essa solução é ideal para organizações de segurança e equipes SOC que desejam melhorar a cobertura de ameaças à nuvem ou modernizar sua infraestrutura SIEM com IaC (infraestrutura como código) e Microsoft Sentinel.
• Microsoft Sentinel como serviço. Essa estrutura de desenvolvimento integra os princípios de gerenciamento do ciclo de vida do serviço. Esses princípios atendem a equipes simples ou complexas, como MSSPs que executam ações repetíveis e padronizadas em vários locatários do cliente, combinando o poder do Azure DevOps e do Azure Lighthouse. Por exemplo, uma equipe que precisa publicar casos de uso do Microsoft Sentinel para um novo ator de ameaça ou campanha contínua pode usar essa solução.
• Criando casos de uso do SOC para detecção de ameaças. Muitos grupos e plataformas de inteligência contra ameaças dependem do conteúdo e da taxonomia de MITRE att&ck para analisar sua postura de segurança em relação a procedimentos avançados de comercialização ou técnicas e táticas. A solução define uma abordagem estruturada para desenvolver práticas de engenharia de detecção de ameaças incorporando a terminologia de MITRE att&ck no desenvolvimento de artefatos do Microsoft Sentinel.

A ilustração a seguir mostra um cenário de nuvem de MITRE att&ck.

Baixe um Arquivo Visio dessa arquitetura.

Cenários de ataque de definição de ameaça com base no MITRE

Esta tabela mostra os termos, definições e detalhes de aspectos importantes dos cenários de ataque.

Item de dados	Descrição	Artefatos do Microsoft Sentinel
Título	Nome descritivo para o cenário de ataque, com base em características de vetor de ataque ou descrições técnicas.	Manifesto MITRE
Táticas MITRE ATT&CK	Táticas de MITRE ATT&CK relacionadas ao cenário de ataque	Manifesto MITRE
Técnicas de MITRE ATT&CK	Técnicas de MITRE ATT&CK, incluindo a ID da técnica ou sub-técnica, relacionadas ao cenário de ataque.	Manifesto MITRE
Fontes do conector de dados	Fonte de informações coletadas por um sensor ou sistema de log que pode ser usada para coletar informações relevantes para identificar a ação que está sendo executada, a sequência de ações ou os resultados dessas ações por um adversário.	Conector de dados do Microsoft Sentinel ou fonte de log personalizada
Descrição	Informações sobre a técnica, o que ela é, para que ela normalmente é usada, como um adversário pode tirar proveito dela e variações sobre como ela pode ser usada. Inclui referências a artigos autoritativos que descrevem informações técnicas relacionadas à técnica, bem como nas referências de uso selvagem, conforme apropriado.
Detecção	Processo analítico de alto nível, sensores, dados e estratégias de detecção úteis para identificar uma técnica usada por um adversário. Esta seção informa os responsáveis por detectar o comportamento do adversário, como defensores de rede, para que possam executar uma ação, como escrever uma análise ou implantar um sensor. Deve haver informações e referências suficientes para apontar para metodologias defensivas úteis. A detecção pode nem sempre ser possível para uma determinada técnica e deve ser documentada como tal.	Busca de ameaças de análise
Redução	Configurações, ferramentas ou processos que impedem que uma técnica funcione ou tenha o resultado desejado para um adversário. Esta seção informa os responsáveis por atenuar contra adversários, como defensores de rede ou formuladores de políticas, para permitir que eles tomem uma ação como alterar uma política ou implantar uma ferramenta. A mitigação pode nem sempre ser possível para uma determinada técnica e deve ser documentada como tal.
Redução	Configurações, ferramentas ou processos que impedem que uma técnica funcione ou tenha o resultado desejado para um adversário. Esta seção descreve como diminuir os efeitos de ataques adversários para defensores de rede ou formuladores de políticas. Ele aborda as etapas para alterar uma política ou implantar uma ferramenta. A mitigação pode nem sempre ser possível para uma determinada técnica e deve ser documentada como tal.	Guias estratégicos, runbooks de automação

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, um conjunto de princípios orientadores que você poderá usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Com a segurança, em termos gerais, a automação aumenta a eficiência das operações, economizando tempo para casos de uso mais complexos, como engenharia de detecção de ameaças, inteligência contra ameaças, SOC e casos de uso SOAR. As equipes de DevOps precisam saber onde podem usar IaC com segurança no contexto de CI/CD do Microsoft Sentinel. Esse processo apresenta o uso de identidades específicas que são usadas por contas não humanas no Microsoft Entra ID chamadas entidades de serviço e identidades gerenciadas.

A tabela a seguir resume as considerações de segurança para entidades de serviço e os principais casos de uso cobertos pelos pipelines de versão do Microsoft Sentinel e do Azure DevOps.

Caso de uso	Requisitos (privilégio mínimo)	Duração da atribuição de função	Escopo da permissão	Administrador	Considerações sobre segurança
Habilitar conectores do Microsoft Sentinel	Administrador de segurança** Proprietário* Colaborador do Microsoft Sentinel Leitor	JIT (ativação única) De propósito (sempre que uma nova assinatura e um conector são implantados)	Locatário	SPN	Use o cofre de chaves para armazenar os segredos e o certificado do SPN (nome da entidade de serviço). Habilite a auditoria do SPN. Periodicamente, examine a atribuição de permissão (Azure Privileged Identity Management para SPN) ou atividade suspeita para SPN. Use as autoridades de certificação do Microsoft Entra e a autenticação multifator (quando houver suporte) para contas com privilégios. Use funções personalizadas do Microsoft Entra para obter mais granularidade.
Implantar artefatos do Microsoft Sentinel, como pastas de trabalho, análise, regras, consultas de busca de ameaças, notebooks e guias estratégicos	Colaborador do Microsoft Sentinel Colaborador dos Aplicativos Lógicos	Permanente	Workspace ou Grupo de Recursos do Microsoft Sentinel	SPN	Use a aprovação do fluxo de trabalho do Azure DevOps (ADO) e as verificações para proteger a implantação de pipeline com esse SPN.
Atribuir uma política para configurar recursos de streaming de log ao Microsoft Sentinel	Colaborador da Política de Recurso **	De propósito (sempre que uma nova assinatura e um conector são implantados)	Todas as assinaturas a serem monitoradas	SPN	Use o Microsoft Entra ID, a AC e a MFA, quando houver suporte, para contas com privilégios.

* Diz respeito apenas às configurações de diagnóstico do Microsoft Entra.
** Conectores específicos precisam de permissões adicionais, como "administrador da segurança" ou "colaborador de política de recursos" para permitir dados de streaming para o workspace do Microsoft Sentinel, do Microsoft Entra ID, do Microsoft 365 ou do Microsoft Defender e os recursos de PaaS (Plataforma como serviço), como o Azure Key Vault.

Modelo de acesso privilegiado

Recomendamos adotar uma estratégia de modelo de acesso privilegiado para reduzir rapidamente os riscos para sua empresa de ataques de alto impacto e alta probabilidade ao acesso privilegiado. No caso de processos automáticos em um modelo de DevOps, baseie a identidade em identidades da entidade de serviço.

O acesso privilegiado deve ser a prioridade de segurança máxima em todas as empresas. Qualquer comprometimento dessas identidades cria impactos altamente negativos. Identidades privilegiadas têm acesso a ativos comercialmente críticos, o que quase sempre causa grandes impactos quando os invasores comprometem essas contas.

A segurança do acesso privilegiado é extremamente importante porque é fundamental para todas as outras garantias de segurança. Um invasor no controle de suas contas privilegiadas pode prejudicar todas as outras garantias de segurança.

Por esse motivo, recomendamos distribuir logicamente as entidades de serviço em diferentes níveis ou camadas seguindo um princípio mínimo de privilégio. A ilustração a seguir mostra como classificar as entidades de serviço, dependendo do tipo de acesso e de onde o acesso é necessário.

Entidades de serviço de nível 0

As entidades de serviço de nível 0 têm o nível mais alto de permissões. Essas entidades de serviço permitem que alguém execute tarefas de administração de grupo de gerenciamento raiz ou em todo o locatário como administrador global.

Por motivos de segurança e capacidade de gerenciamento, recomendamos que você tenha apenas uma entidade de serviço para esse nível. As permissões para essa entidade de serviço persistem, portanto, recomendamos que você conceda apenas as permissões mínimas necessárias e mantenha a conta monitorada e protegida.

Armazene o segredo ou certificado dessa conta com segurança no Azure Key Vault. Recomendamos que você localize o cofre de chaves em uma assinatura administrativa dedicada, se possível.

Entidades de serviço de nível 1

As entidades de serviço de nível 1 são permissões elevadas limitadas e com escopo para grupos de gerenciamento no nível da organização empresarial. Essas entidades de serviço dão direito para que alguém crie assinaturas no grupo de gerenciamento que está no escopo.

Por motivos de segurança e capacidade de gerenciamento, recomendamos que você tenha apenas uma entidade de serviço para esse nível. As permissões para essa entidade de serviço persistem, portanto, recomendamos que você conceda apenas as permissões mínimas necessárias e mantenha a conta monitorada e protegida.

Armazene o segredo ou certificado dessa conta com segurança no Azure Key Vault. Recomendamos que você localize o cofre de chaves em uma assinatura administrativa dedicada, se possível.

Entidades de serviço de nível 2

As entidades de serviço de nível 2 são limitadas ao nível da assinatura. Essas entidades de serviço permitem que alguém execute tarefas administrativas em uma assinatura, atuando como o proprietário da assinatura.

Por motivos de segurança e capacidade de gerenciamento, recomendamos que você tenha apenas uma entidade de serviço para esse nível. As permissões para essa entidade de serviço persistem, portanto, recomendamos que você conceda apenas as permissões mínimas necessárias e mantenha a conta monitorada e protegida.

Armazene o segredo ou certificado dessa conta com segurança no Azure Key Vault. Recomendamos que você localize o cofre de chaves em um grupo de recursos administrativos dedicado.

Entidades de serviço de nível 3

As entidades de serviço de nível 3 são limitadas ao Administrador de Carga de Trabalho. Em um cenário típico, cada carga de trabalho está contida dentro do mesmo grupo de recursos. Essa estrutura limita as permissões da entidade de serviço apenas a esse grupo de recursos.

Por motivos de segurança e capacidade de gerenciamento, recomendamos que você tenha apenas uma entidade de serviço por carga de trabalho. As permissões para essa entidade de serviço persistem, portanto, recomendamos que você conceda apenas as permissões mínimas necessárias e mantenha a conta monitorada e protegida.

Armazene o segredo ou certificado dessa conta com segurança no Azure Key Vault. Recomendamos que você localize o cofre de chaves em um grupo de recursos administrativos dedicado.

Entidades de serviço de nível 4

As entidades de serviço de nível 4 têm as permissões mais limitadas. Essas entidades de serviço permitem que alguém execute tarefas administrativas limitadas a um recurso.

Recomendamos o uso de identidades gerenciadas sempre que possível. No caso de identidades não gerenciadas, armazene o segredo ou o certificado com segurança no Azure Key Vault em que os segredos de Nível 3 são armazenados.

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.

As soluções do Microsoft Sentinel são compostas por três blocos, que garantem operações completas e bem-sucedidas.

O primeiro bloco é a definição de ambiente, que compõe os elementos de arquitetura essenciais. Sua principal preocupação com esse bloco é considerar o número de ambientes de produção e não produção a serem implantados e, em seguida, garantir que a configuração seja homogênea em todos os casos.

O segundo bloco é a implantação do conector do Microsoft Sentinel, em que você considera o tipo de conectores exigidos pela sua equipe e os requisitos de segurança para habilitá-los.

O terceiro bloco é o gerenciamento do ciclo de vida de artefatos do Microsoft Sentinel, que abrange codificação, implantação e uso ou destruição dos componentes. Por exemplo, esse bloco contém as regras analíticas, guias estratégicos, pastas de trabalho, busca de ameaças e assim por diante.

Considere essas dependências entre artefatos:

• Regras de automação definidas em uma regra de análise
• Pastas de trabalho ou análise que exigem uma nova fonte de dados ou conector
• Gerenciando as atualizações de componentes existentes
  • Como fazer a versão de seus artefatos
  • Como identificar, testar e implantar uma regra de análise atualizada ou totalmente nova

Criar, testar e implantar a infraestrutura

Ao gerenciar soluções do Microsoft Sentinel e DevOps, é importante considerar os aspectos de conectividade e segurança de sua arquitetura empresarial.

O Azure DevOps pode usar agentes hospedados pela Microsoft ou agentes auto-hospedados para atividades de build, teste e implantação. Dependendo dos requisitos da sua empresa, você pode usar os modelos hospedados pela Microsoft, auto-hospedados ou uma combinação de ambos os modelos.

• Agentes hospedados pela Microsoft. Essa opção é a maneira mais rápida de trabalhar com agentes do Azure DevOps, pois é uma infraestrutura compartilhada para toda a sua organização. Para obter mais informações sobre como usar agentes hospedados pela Microsoft em seu pipeline, consulte agentes hospedados pela Microsoft. Os agentes hospedados pela Microsoft podem trabalhar em ambientes de rede híbrida, concedendo acesso aos intervalos de IP. Para fazer o download dos intervalos de IP aos quais esses agentes concedem acesso, consulte Intervalos de IP do Azure e Marcas de Serviço - Nuvem Pública.
• Agentes auto-hospedados. Essa opção fornece recursos dedicados e mais controle ao instalar um software dependente para suas compilações e implantações. Agentes auto-hospedados podem trabalhar em VMs, conjuntos de dimensionamento e contêineres no Azure. Para obter mais informações sobre agentes auto-hospedados, consulte agentes do Azure Pipelines.

Corredores do GitHub

O GitHub pode usar corredores hospedados no GitHub ou executores auto-hospedados para atividades relacionadas à criação, teste e implantação. Dependendo das necessidades da sua empresa, você pode usar o GitHub hospedado, auto-hospedado ou uma combinação de ambos os modelos.

Executores hospedados no GitHub

Essa opção é a maneira mais rápida de trabalhar com fluxos de trabalho do GitHub, já que é uma infraestrutura compartilhada para toda uma organização. Para obter mais informações, consulte Sobre os executores hospedados no GitHub. Os agentes hospedados no GitHub trabalham em ambientes de rede híbrida, de acordo com determinados requisitos de rede. Para obter mais informações sobre os requisitos de rede, consulte Recursos de hardware e corredores com suporte.

Executores auto-hospedados

Essa opção fornece à sua empresa uma infraestrutura de recursos dedicada. Os executores auto-hospedados trabalham em VMs e contêineres no Azure e dão suporte ao dimensionamento automático.

Considerações sobre como escolher corredores

Ao escolher opções para os agentes e executores em sua solução do Microsoft Sentinel, considere as seguintes necessidades:

• Sua empresa precisa de recursos dedicados para executar processos em seus ambientes do Microsoft Sentinel?
• Deseja isolar recursos para atividades de DevOps do ambiente de produção do restante dos ambientes?
• Você precisa testar determinados casos que exigem acesso a recursos críticos ou recursos que estão disponíveis apenas em uma rede interna?

Orquestração e automação de processos de lançamento

Você pode configurar o processo de implantação com o Azure DevOps ou o GitHub. O Azure DevOps dá suporte ao uso de um pipeline YAML ou de um pipeline de lançamento. Para obter mais informações sobre como usar um pipeline YAML no Azure DevOps, consulte Usar o Azure Pipelines. Para obter mais informações sobre como usar um pipeline de lançamento no Azure DevOps, consulte pipelines de versão. Para obter mais informações sobre como usar o GitHub com o GitHub Actions, consulte Como entender o GitHub Actions.

Azure DevOps

Você pode fazer as seguintes atividades de implantação em uma implantação do Azure DevOps.

• Use um pipeline YAML para disparar automaticamente aprovações de PR ou executar sob demanda.
• Gerenciar conexões de serviço para ambientes diferentes usando grupos do Azure DevOps.
• Em seus ambientes críticos, configure aprovações de implantação usando o recurso de conexão de serviço e grupos do Azure DevOps para atribuir permissões de usuário específicas em sua equipe.

GitHub

Você pode fazer as seguintes atividades de implantação em uma implantação do GitHub.

• Use o GitHub para criar PRs ou atividades de implantação.
• Gerencie as credenciais da entidade de serviço usando os Segredos do GitHub.
• Integre a aprovação de implantação por meio do fluxo de trabalho associado ao GitHub.

Implantação automática com a infraestrutura do Microsoft Sentinel

Você pode implantar um ou mais ambientes do Microsoft Sentinel, dependendo da sua arquitetura empresarial:

• As organizações que precisam de várias instâncias em seu ambiente de produção podem configurar assinaturas diferentes no mesmo locatário para cada local geográfico.
• Uma instância centralizada no ambiente de produção fornece acesso a uma ou mais organizações no mesmo locatário.
• Grupos que precisam de vários ambientes, como produção, pré-produção, integração e assim por diante, podem criá-los e destruí-los conforme necessário.

Definições de ambiente físico versus lógico

Você tem duas opções para configurar suas definições de ambiente, físicas ou lógicas. Ambas têm opções e vantagens diferentes:

• Definição física - Os elementos da arquitetura do Microsoft Sentinel são definidos com as seguintes opções de IaC (infraestrutura como código):
  • Modelos do Bicep
  • Modelos do ARM (modelos do Azure Resource Manager)
  • Terraform
• Definição lógica - Atua como uma camada de abstração para configurar equipes diferentes no grupo e definir seus ambientes. A definição é feita no pipeline de implantação e fluxos de trabalho como entrada para o ambiente de build usando a camada de infraestrutura física.

Considere estes pontos ao definir seus ambientes lógicos:

• Convenções de nomenclatura
• Identificações de ambiente
• Conectores e configurações

Repositório de códigos

Considerando as abordagens de ambiente mostradas na seção anterior, considere a seguinte organização de repositório de código do GitHub.

Definição física - Com base nas opções de IaC, pense em uma abordagem que usa definições de módulo individuais vinculadas na definição de implantação principal.

O exemplo a seguir mostra como seu código pode ser organizado.

Restrinja o acesso a esse repositório à equipe que define a arquitetura no nível físico, garantindo uma definição homogênea na arquitetura empresarial.

Você pode adaptar a estratégia de ramificação e mesclagem à estratégia de implantação de cada organização. Se sua equipe precisar começar com a definição, consulte Adotar uma estratégia de ramificação do Git.

Para mais informações ou modelo do ARM, confira Usar modelos vinculados e aninhados ao implantar recursos do Azure.

Para obter mais informações sobre como configurar ambientes Bicep, consulte Instalar ferramentas do Bicep. Para obter mais informações sobre o GitHub, consulte fluxo do GitHub.

Definições lógicas definem os ambientes de uma empresa. O repositório Git reúne as diferentes definições para uma empresa.

O exemplo a seguir mostra como seu código pode ser organizado.

O repositório reflete as ações de PR feitas por equipes diferentes. Vários ambientes são definidos por equipes diferentes e aprovados pelos proprietários ou aprovadores da empresa.

O nível de privilégio para executar uma implantação de ambiente é o Nível 2. Esse nível garante que o grupo de recursos e os recursos sejam criados para o ambiente com a segurança e a privacidade necessárias. Esse nível também define as permissões do usuário em ações permitidas nos ambientes de produção e pré-produção.

As organizações que desejam ambientes sob demanda para teste e desenvolvimento e a capacidade de destruir os ambientes depois de concluir seus testes podem implementar um pipeline do Azure DevOps ou GitHub Actions. Eles podem definir gatilhos agendados para destruir os ambientes conforme necessário usando eventos do Azure DevOps ou GitHub Actions.

Configuração automática de conectores do Microsoft Sentinel

Os conectores do Microsoft Sentinel são uma parte essencial da solução que dá suporte à conexão com diferentes elementos no cenário da arquitetura empresarial, como Microsoft Entra ID, Microsoft 365, Microsoft Defender, soluções de plataforma de inteligência contra ameaças e assim por diante.

Ao definir um ambiente, você pode usar a configuração de conectores para configurar ambientes com configurações homogêneas.

A habilitação de conectores como parte do modelo DevOps deve ser compatível com o modelo de nível de entidade de serviço. Esse foco garante o nível certo de permissões, conforme mostrado na tabela a seguir.

Cenário do conector	Nível do modelo de acesso de privilégio	Privilégio mínimo do Azure	Requer aprovação de fluxo de trabalho
Microsoft Entra ID	Nível 0	administrador global ou administrador de segurança	Recomendado
Proteção do Microsoft Entra ID	Nível 0	administrador global ou administrador de segurança	Recomendado
Microsoft Defender para Identidade	Nível 0	administrador global ou administrador de segurança	Recomendado
Microsoft Office 365	Nível 0	administrador global ou administrador de segurança	Recomendado
Microsoft Cloud App Security	Nível 0	administrador global ou administrador de segurança	Recomendadas
Microsoft Defender XDR	Nível 0	administrador global ou administrador de segurança	Recomendado
Microsoft Defender para IOT	Nível 2	Colaborador	Recomendado
Microsoft Defender para Nuvem	Nível 2	Leitor de segurança	Opcional
Atividades do Azure	Nível 2	Leitor de assinatura	Opcional
Plataformas de Inteligência contra Ameaças	Nível 0	administrador global ou administrador de segurança	Recomendado
Eventos de segurança	Nível 4	Nenhum	Opcional
syslog	Nível 4	Nenhum	Opcional
DNS (Versão Prévia)	Nível 4	Nenhum	Opcional
Firewall do Windows	Nível 4	Nenhum	Opcional
Eventos de Segurança do Windows via AMA	Nível 4	Nenhum	Opcional

Implantação de artefatos do Microsoft Sentinel

Na implementação de artefatos do Microsoft Sentinel, o DevOps ganha maior relevância, pois cada empresa cria vários artefatos para evitar e corrigir ataques.

Implementar os artefatos pode ser responsabilidade de uma equipe ou de várias equipes. A implantação automática de artefatos e build é geralmente o requisito de processo mais comum e determina a abordagem e as condições para seus agentes e executores.

A implantação e o gerenciamento de artefatos do Microsoft Sentinel exigem o uso da API REST do Microsoft Sentinel. Para obter mais informações, confira API REST do Microsoft Azure Sentinel. O diagrama a seguir mostra um pipeline do Azure DevOps em uma pilha de API REST do Azure.

Você também pode implementar seu repositório usando o PowerShell.

Se sua equipe usar MITRE, considere classificar os diferentes artefatos e especificar as táticas e técnicas para cada um deles. Certifique-se de incluir um arquivo de metadados correspondente para cada tipo de artefato.

Por exemplo, se você estiver criando um novo guia estratégico usando um modelo do ARM do Azure e o nome do arquivo for Playbook.arm.json, adicione um arquivo JSON chamado Playbook.arm.mitre.json. Os metadados desse arquivo incluem os formatos CSV, JSON ou YAML que correspondem às táticas ou técnicas MITRE que você está usando.

Seguindo essa prática, sua equipe pode avaliar sua cobertura MITRE com base nos trabalhos que são feitos durante a instalação para os diferentes tipos de artefato que você usa.

Artefatos de compilação

O objetivo do processo de build é garantir que você gere os artefatos de maior qualidade. O diagrama a seguir mostra algumas das ações de processo de build que você pode executar.

Baixe um Arquivo Visio dessa arquitetura.

• Você pode basear sua definição de artefato em um esquema descritivo no formato JSON ou YAML e validar o esquema para evitar erros de sintaxe.
  • Valide seus modelos do ARM usando o kit de ferramentas de teste de modelo do ARM.
  • Valide seus arquivos YAML e JSON para modelos personalizados usando o PowerShell.
• Valide as configurações da watchlist e verifique se os registros CIDR (roteamento entre domínios) sem classe definidos seguem o esquema correto, por exemplo, 10.1.0.0/16.
• Use consultas KQL (linguagem de consulta de palavra-chave), que podem ser validadas no nível da sintaxe, para regras analíticas, regras de busca e regras de transmissão ao vivo, que podem ser validadas no nível da sintaxe.
• Torne a validação local do KQL uma opção.
• Integre a ferramenta de validação embutida do KQL no pipeline de DevOps.
• Se você estiver implementando uma lógica baseada no PowerShell para Automação do Azure, você poderá incluir a validação de sintaxe e o teste de unidade usando os seguintes elementos:
  • Pester
  • PSScriptAnalyzer
• Gere o relatório de metadados de manifesto MITRE com base nos arquivos de metadados incluídos nos artefatos.

Exportar artefatos

Normalmente, várias equipes trabalham em várias instâncias do Microsoft Sentinel para gerar artefatos necessários e validá-los. Com o objetivo de reutilização de artefatos existentes, sua empresa pode configurar processos automáticos para obter as definições de artefato de ambientes existentes. A automação também pode fornecer informações sobre quaisquer artefatos criados por diferentes equipes de desenvolvimento durante a instalação.

O diagrama a seguir mostra um exemplo de processo de extração de artefatos.

Baixe um Arquivo Visio dessa arquitetura.

Implantar artefatos

Os objetivos do processo de implantação são:

• Reduza o tempo para o mercado.
• Aumente o desempenho entre as várias equipes envolvidas na configuração e no gerenciamento da solução.
• Configure o teste de integração para avaliar a integridade do ambiente.

As equipes de desenvolvimento usam o processo para garantir que possam implantar, testar e validar casos de uso de artefatos que estão em desenvolvimento. As equipes de arquitetura e SOC validam a qualidade do pipeline em ambientes de QA e trabalham com os testes de integração para cenários de ataque. Nos casos de teste, uma equipe geralmente combina artefatos diferentes como regras analíticas, guias estratégicos de correção, watchlists e assim por diante. Uma parte de cada caso de uso inclui simular ataques em que toda a cadeia é avaliada por ingestão, detecção e correção.

O diagrama a seguir mostra a sequência de processo de implantação que garante que seus artefatos sejam implantados na ordem certa.

Baixe um Arquivo Visio dessa arquitetura.

Gerenciar artefatos Sentinelas como código oferece maneiras flexíveis de manter suas operações e automatizar a implantação em um pipeline de CI/CD DevOps.

As soluções da Microsoft fornecem fluxos de trabalho de automação para os artefatos a seguir.

Artifact	Fluxos de trabalho de automação
Watchlists	Revisão de código Validação de esquema Implantação Criar, atualizar, excluir watchlists e itens
Fusão de regras de análise Microsoft Security Análise comportamental de ML Anomalia Agendadas	Revisão de código Validação da sintaxe KQL Validação de esquema Pester Implantação Criar, Habilitar, Atualizar, Excluir, Exportar Suporte a modelos de alerta
Regras de automação	Revisão de código Validação de esquema Implantação Criar, habilitar, atualizar, excluir, exportar
Conectores	Revisão de código Validação de esquema Implantação Ações: habilitar, excluir (desabilitar), atualizar
Regras de busca	Revisão de código Validação da sintaxe KQL Validação de esquema Pester Implantação Ações: criar, habilitar, atualizar, excluir, exportar
Guias Estratégicos	Revisão de código TTK Implantação Ações: criar, habilitar, atualizar, excluir, exportar
Pastas de trabalho	Implantação Ações: criar, atualizar, excluir
Runbooks	Revisão de código Validação da sintaxe do PowerShell Pester Implantação Ações: criar, habilitar, atualizar, excluir, exportar

Dependendo da linguagem de automação escolhida, talvez não haja suporte para alguns recursos de automação. O diagrama a seguir mostra quais recursos de automação têm suporte no idioma.

* Recursos em desenvolvimento que ainda não estão documentados
** Métodos de automação compatíveis com os Insights Operacionais da Microsoft ou APIs do Provedor de Recursos do Microsoft Insights

Automação do Azure

O diagrama a seguir mostra os componentes da simplificação do acesso do Microsoft Sentinel com a identidade do serviço gerenciado.

Baixe um Arquivo Visio dessa arquitetura.

Se você precisar conceder acesso a outros recursos, use a identidade gerenciada, o que garante uma identidade exclusiva para todas as operações críticas.

Use a Automação do Azure para configurar guias estratégicos. Use scripts do PowerShell para as seguintes tarefas complexas e recursos de automação:

• Integração com soluções de terceiros, em que diferentes níveis de credenciais são necessários e com base no Microsoft Entra ID ou credenciais personalizadas:
  • Credenciais de usuário do Microsoft Entra
  • Credenciais de entidade de serviço do Microsoft Entra
  • Autenticação de certificado
  • Credenciais personalizadas
  • Identidade gerenciada
• Implementando uma solução que reutiliza scripts organizacionais ou soluções que exigem o uso de comandos do PowerShell para evitar a tradução complexa de guias estratégicos:
  • Soluções baseadas no PowerShell
  • Soluções baseadas em Python
• Implementando soluções em cenários híbridos, em que as ações de correção podem afetar a nuvem e os recursos locais.

Repositórios do Microsoft Sentinel

As equipes experientes do DevOps podem considerar o gerenciamento do Microsoft Sentinel em IaC (infraestrutura como código) com pipelines de CI/CD que são criados no Azure DevOps. Os grupos de produtos entendem os desafios que os clientes e parceiros enfrentam na criação da arquitetura de segurança do Azure DevOps, As duas iniciativas a seguir possam ajudar:

• A documentação da arquitetura de referência
• O desenvolvimento de uma nova solução, anunciada no Ignite 2021, que se chama "Repositórios do Microsoft Sentinel"

Para dar suporte à escolha da solução que atenda às necessidades da sua equipe, a tabela a seguir compara os critérios funcionais e técnicos.

Casos e recursos de uso	Abordagem personalizada do Azure DevOps e do GitHub	Repositórios do Microsoft Sentinel
Queremos começar rapidamente a implantar artefatos do Microsoft Sentinel sem gastar tempo definindo componentes de arquitetura do Azure DevOps, como agentes, pipelines, Git, dashboards, wiki, entidades de serviço, RBACs, auditoria e assim por diante.	Não recomendado	Recomendadas
Temos equipes pequenas e conjuntos de habilidades baixos para gerenciar os pipelines de CI/CD.	Não recomendado	Recomendadas
Queremos controlar e gerenciar todos os aspectos de segurança dos pipelines de CI/CD.	Com suporte	Sem suporte
Precisamos integrar portões e ramificações para supervisionar a integração, antes de permitir que os desenvolvedores disparem pipelines de implantação, como controle do código-fonte, revisão de codificação, reversão, aprovação de fluxo de trabalho e assim por diante.	Com suporte	Com suporte parcial
Temos uma estrutura de repositório ou Git personalizada.	Com suporte	Com suporte
Não usamos linguagens IaC do Resource Manager ou Bicep para criar artefatos.	Com suporte	Sem suporte
Queremos gerenciar centralmente a implantação de artefatos em vários workspaces do Microsoft Sentinel em um único locatário do Microsoft Entra.	Com suporte	Com suporte
Queremos integrar ou estender pipelines de CI/CD em vários locatários do Microsoft Entra.	Com suporte	Com suporte
Temos guias estratégicos com parametrização diferente dependendo da assinatura, localização, ambiente e assim por diante.	Com suporte	TBD, diretrizes a serem documentadas
Queremos integrar artefatos diferentes no mesmo repositório para compor casos de uso.	Com suporte	Com suporte
Queremos a capacidade de remover artefatos em massa.	Com suporte	Sem suporte

Disponibilidade, desempenho e escalabilidade

Ao escolher a arquitetura para os agentes do Azure DevOps em sua empresa para cenários do Microsoft Sentinel, considere as seguintes necessidades:

• O ambiente de produção pode exigir um pool de agentes dedicado para operações no ambiente do Microsoft Sentinel.
• Ambientes de não produção podem compartilhar o pool de agentes com um grande número de instâncias para lidar com as diferentes demandas das equipes, em particular, para práticas de CI/CD.
  • Cenários de simulação de ataque são um caso especial em que agentes dedicados podem ser necessários. Considere se um pool dedicado é necessário para suas necessidades de teste.
• As organizações que trabalham em cenários de rede híbrida podem considerar a integração dos agentes dentro da rede.

As organizações podem criar suas próprias imagens para agentes com base em contêineres. Para obter mais informações, consulte Executar um agente auto-hospedado no Docker.

Gerenciamento entre locatários do Microsoft Sentinel com o Azure DevOps

Como um SOC ou MSSP global, talvez seja necessário gerenciar vários locatários. O Azure Lighthouse dá suporte a operações dimensionadas em vários locatários do Microsoft Entra ao mesmo tempo, tornando suas tarefas de gerenciamento mais eficientes. Para obter mais informações, consulte a Visão geral do Azure Lighthouse.

O gerenciamento entre locatários é especialmente eficaz nos seguintes cenários:

• Gerenciar recursos do Microsoft Sentinel em locatários do cliente.
• Acompanhar ataques e ver alertas de segurança em vários locatários.
• Visualizar incidentes em vários espaços de trabalho do Microsoft Sentinel espalhados por locatários.

Métodos para integrar clientes

Você tem duas opções para integrar clientes, uma oferta de serviço gerenciado e um modelo do ARM.

Integração manual usando um modelo do ARM

Caso não queira publicar uma oferta no Azure Marketplace como um provedor de serviço ou não cumpra todos os requisitos, você pode integrar os clientes manualmente usando modelos do ARM. Essa é a opção mais provável em um cenário empresarial, em que a mesma empresa tem vários locatários.

A tabela a seguir compara os métodos de integração.

Consideração	Oferta de serviço gerenciado	Modelos do ARM
Requer uma conta do Partner Center	Sim	Não
Requer o nível de competência da plataforma de nuvem Silver ou Gold ou o status do MSP (Provedor de Serviços Gerenciados Especialistas) do Azure	Sim	Não
Disponível para novos clientes por meio do Azure Marketplace	Sim	Não
Pode limitar a oferta a clientes específicos	Sim (somente com ofertas privadas, que não podem ser usadas com assinaturas estabelecidas por meio de um revendedor do programa do CSP)	Sim
Requer a aceitação do cliente no portal do Azure	Sim	Não
Pode usar a automação para integrar várias assinaturas, grupos de recursos ou clientes	Não	Sim
Fornece acesso imediato a novas funções internas e recursos do Azure Lighthouse	Nem sempre (geralmente disponível após algum atraso)	Sim

Para obter mais informações sobre como publicar ofertas de serviço gerenciado, consulte Publicar uma oferta de serviço gerenciado no Azure Marketplace.

Para obter mais informações sobre como criar um modelo do ARM, consulte Criar e implantar modelos do ARM.

O diagrama a seguir mostra a integração de arquitetura de alto nível entre um locatário do MSSP e os locatários do provedor de recursos de um cliente com o Azure Lighthouse e o Microsoft Sentinel.

Baixe um Arquivo Visio dessa arquitetura.

1. Uma oferta do MSP é integrada por meio de um modelo do ARM ou de uma oferta de serviço do Azure Marketplace.
2. O gerenciamento de recursos delegados do Azure verifica se a solicitação é de um locatário de parceiro e chama um provedor de recursos de serviço gerenciado.
3. O provedor de recursos de serviço gerenciado usa RBAC para controlar o acesso do MSP.
4. O MSP conclui as ações de SecOps em um recurso do cliente.
5. O processo de cobrança trata as despesas como encargos do cliente. A cobrança dividida é possível se as entidades do cliente tiverem workspaces separados no mesmo locatário do Microsoft Entra.
6. A segurança e a soberania dos dados dependem do limite de locatário do cliente.

Identificar vários locatários

Para gerenciar o Microsoft Sentinel com o Azure DevOps, avalie as seguintes decisões de design para os componentes.

Caso de uso	Prós
Identidade global para gerenciar ações de DevOps, entidade de serviço única	Esse caso se aplica a processos de implantação globais, que envolvem todos os locatários. O uso de identidade unificada facilita o acesso aos diferentes locatários, mas pode tornar o processo de gerenciamento de ações de aprovação para locatários específicos complexo. O mecanismo de proteção e o modelo de autorização para esse tipo de identidade também são muito importantes, para evitar o uso não autorizado devido ao impacto global relacionado.
Identidade dedicada para gerenciar ações de DevOps, várias entidades de serviço	Esse caso se aplica quando os processos de implantação são dedicados para cada locatário ou ações de locatário exigem aprovação. Nesse caso, a recomendação para proteger e autorizar esse uso de identidade é a mesma do caso global, mesmo quando o impacto é reduzido.

Organização do repositório de código

Caso de uso	Prós
Repositório unificado com uma única versão do código para todos os locatários	Esse caso facilita ter versões unificadas para o código no repositório. Nesse caso, uma versão unificada do código que gerencia uma versão específica para locatários pode exigir suporte em branches para cada caso.
Repositório unificado com pastas de código específicas por locatário	Esse caso complementa o caso de repositório único. Aqui uma estrutura de pastas pode dividir artefatos dedicados por locatário.
Repositório dedicado por locatário	Essa abordagem fornece isolamento ao gerenciar artefatos de código. Isso facilita a evolução entre locatários com diferentes equipes ou requisitos. A consolidação de alterações requer o estabelecimento de um processo entre repositórios, o que pode exigir esforço para manter.

Processos de build e implantação

Caso de uso	Prós
Processo de build único para todos os locatários	Quando todos os locatários trabalham com a mesma versão dos artefatos, essa é a opção mais simples para implementar a geração e o pacote.
Processo de build por locatário	Uma versão diferente do código é implantada em cada locatário.
Processo de implantação global para todos os Locatários	Novas implantações e atualizações para implantações se aplicam a todos os locatários. As etapas dos processos de implantação e atualização são usadas para todos os locatários.
Locatário do processo de implantação global por locatário	Novas implantações e atualizações para implantações se aplicam a um ou mais locatários.
Processo de implantação dedicado por locatário	O processo de implantação é adaptado para cada locatário.

Otimização de custo

A otimização de custos consiste em reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

O custo da solução depende dos seguintes fatores:

• O volume de dados que sua empresa alimenta mensalmente no workspace do Log Analytics do Microsoft Sentinel
• A camada de compromisso ou o método de cobrança que você escolher, como pagamento conforme o uso (PAYG)
• A taxa de retenção das políticas de dados em uma tabela ou nível global

Para obter mais informações, consulte retenção de tipo de dados do Azure.

Para calcular os preços, consulte a calculadora de preços do Microsoft Sentinel. Para obter mais informações sobre as considerações e exemplos de preços avançados, consulte Planejar custos para o Microsoft Sentinel..

Você poderá incorrer em custos adicionais se estender sua solução com os seguintes componentes:

• Guias estratégicos - Runtimes para Aplicativos Lógicos do Azure e Azure Functions. Para obter mais informações, confira Detalhes de preços.
• Exportando para o armazenamento externo, como o Azure Data Explorer, os Hubs de Eventos ou uma conta de Armazenamento do Microsoft Azure.
• Um workspace de aprendizado de máquina e a computação que um componente do Jupyter Notebook usa.

Implantar este cenário

A seção a seguir descreve as etapas para implantar esse cenário na forma de um caso de uso de exemplo que abrange os vários processos de DevOps.

Compilar e lançar a estrutura do Microsoft Sentinel

Primeiro, configure os componentes do NuGet necessários em um repositório dedicado em que diferentes processos podem consumir as versões geradas.

Se você estiver trabalhando com o Azure DevOps, poderá criar um feed de componentes para hospedar os diferentes pacotes NuGet da estrutura do Microsoft Sentinel para o PowerShell. Para obter mais informações, consulte Introdução aos pacotes NuGet.

Se sua equipe escolher um registro do GitHub, você poderá conectá-lo como um repositório NuGet, pois ele é compatível com o protocolo de feed. Para obter mais informações, consulte Introdução aos pacotes do GitHub.

Quando você tem um repositório NuGet disponível, o pipeline contém uma conexão de serviço para o NuGet. Essas capturas de tela mostram a configuração da nova conexão de serviço chamada Microsoft Sentinel NuGet Framework Connection.

Depois de configurar o feed, você pode importar o pipeline para criar a estrutura do PowerShell diretamente do GitHub em uma bifurcação específica. Para obter mais informações, consulte Compilar repositórios do GitHub. Nesse caso, você cria um novo pipeline e escolhe o GitHub como a fonte de código.

Outra opção é importar o repositório Git como um repositório do Azure DevOps baseado no Git. Em ambos os casos, para importar o pipeline, especifique o seguinte caminho:

src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml

Agora você pode executar o pipeline pela primeira vez. Em seguida, a estrutura cria e libera para o feed do NuGet.

Definir seu ambiente do Microsoft Sentinel

Ao começar com o Microsoft Sentinel e usar esses exemplos, defina o ambiente em sua empresa, por exemplo, Ambiente como Código ou EaC. Especifique os diferentes elementos que compõem o ambiente em cada caso.

A arquitetura do Microsoft Sentinel inclui os seguintes elementos no Azure:

• Workspace do Log Analytics - Esse workspace forma a base da solução. As informações relacionadas à segurança são armazenadas aqui e o workspace é o mecanismo da KQL (Linguagem de Consulta Kusto).
• Solução do Microsoft Sentinel no workspace do Log Analytics - Essa solução estende a funcionalidade do workspace do Log Analytics para incluir recursos SIEM e SOAR.
• Key Vault - O cofre de chaves mantém os segredos e as chaves que são usadas durante os processos de correção.
• Conta de automação - Essa conta é opcional e é usada para os processos de correção. O processo de correção usado é baseado nos runbooks do PowerShell e do Python. O processo inclui uma identidade gerenciada pelo sistema que funciona com recursos diferentes de acordo com as práticas recomendadas.
• Identidade gerenciada pelo usuário - Esse recurso atua como uma camada de identidade unificada do Microsoft Sentinel que gerencia interações entre guias estratégicos e runbooks do Microsoft Sentinel.
• Conexões de Aplicativo Lógico - São conexões para o Microsoft Sentinel, o cofre de chaves e a automação que usam a identidade gerenciada pelo usuário.
• Conexões de Aplicativo Lógico Externo - São conexões para recursos externos envolvidos nos processos de correções e que se baseiam nos guias estratégicos.
• Hubs de Eventos do Azure - Esse recurso é opcional e lida com a integração entre o Microsoft Sentinel e outras soluções, como Splunk, Azure Databricks e aprendizado de máquina e Resilient.
• Conta de armazenamento - Esse recurso é opcional e manipula a integração entre o Microsoft Sentinel e outras soluções, como Splunk, Azure Databricks e aprendizado de máquina e Resilient.

Usando exemplos do repositório, você pode definir o ambiente com arquivos JSON para especificar os diferentes conceitos lógicos. As opções disponíveis para definir o ambiente podem ser literais ou automáticas.

Em uma definição literal, você especifica o nome e os elementos para cada recurso no ambiente, conforme mostrado neste exemplo.

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Literal",
            "ResourceGroupName": "<resource-group-name>"
         }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Literal",
            "LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
            "ManagedIdentityName": "<user-managed-identity-name>",
            "SentinelConnectionName": "<Sentinel-API-connection-name>",
            "KeyVaultName": "<Key-Vault-name>",
            "KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
        },
        "Automation":
        {
            "Type": "Literal",
            "AutomationAccountName": "<automation-account-name>",
            "AutomationAccountConnectionName": "<automation-account-API-connection-name>"
        },
        "Integration":
        {
            "Type": "Literal",
            "EventHubNamespaces": [
                "<Event-Hubs-namespace-1-name>",
                "<Event-Hubs-namespace-2-name>",
                "<Event-Hubs-namespace-3-name>",
                "<Event-Hubs-namespace-4-name>",
                "<Event-Hubs-namespace-5-name>",
                "<Event-Hubs-namespace-6-name>",
                "<Event-Hubs-namespace-7-name>",
                "<Event-Hubs-namespace-8-name>",
                "<Event-Hubs-namespace-9-name>",
                "<Event-Hubs-namespace-10-name>",
            ],
            "StorageAccountName": "<storage-account-name>"
        }
    }
}

Em uma definição automática, os nomes dos elementos são gerados automaticamente com base em convenções de nomenclatura, conforme mostrado neste exemplo.

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Automatic"
        }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Automatic"
        },
        "Automation":
        {
            "Type": "Automatic"
        },
        "Integration":
        {
            "Type": "Automatic",
            "MaxEventHubNamespaces": 5
        }
    }
}

Você pode encontrar exemplos no repositório GitHub no caminho de ambientes do Microsoft Sentinel e usar os exemplos como referência na preparação dos casos de uso.

Implantar seu ambiente do Microsoft Sentinel

Quando você tiver pelo menos um ambiente definido, poderá criar a conexão de serviço do Azure para integrar-se ao Azure DevOps. Depois de criar a conexão de serviço, defina a entidade de serviço vinculada para a função de proprietário ou um nível de permissões semelhante sobre a assinatura de destino.

1. Importe o pipeline para criar o novo ambiente conforme definido neste arquivo.

   src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.yml

2. Em seguida, insira o nome da conexão de serviço que representa o ambiente.

   

3. Escolha o branch para a definição de ambiente no repositório. 

4. Insira o nome da conexão de serviço do Azure DevOps para sua assinatura na caixa Conexão de Ambiente do Azure.

5. Insira o nome do ambiente que uma conexão de serviço pode usar para resolver vários ambientes na mesma assinatura.

6. Escolha a ação a ser aplicada aos conectores.

7. Selecione Usar Artefatos de Pré-Lançamento do PowerShell se você quiser usar as versões de pré-lançamento dos componentes da estrutura do PowerShell.

O pipeline inclui as seguintes etapas como parte do fluxo de implantação:

• Implantar componentes do NuGet.
• Conecte-se usando ferramentas Do NuGet com o repositório de artefatos.
• Resolva o feed.
• Instalar os módulos necessários.
• Obter a definição do ambiente.
• Valide quais recursos existem no destino.
• Adicione o Log Analytics e o Microsoft Sentinel se eles não estiverem no workspace.
• Se você já tiver o Log Analytics, adicione o Microsoft Sentinel sobre sua instância do Log Analytics.
• Crie uma identidade gerenciada para representar a interação entre o Microsoft Sentinel e os Aplicativos Lógicos.
• Crie o Azure Key Vault e defina a atribuição de função para gerenciar segredos e chaves para a identidade gerenciada.
• Se aplicável, crie uma conta de Automação do Azure e ative a identidade gerenciada atribuída pelo sistema.
• Defina a atribuição de função no cofre de chaves para a identidade gerenciada atribuída pelo sistema.
• Crie as definições dos Hubs de Eventos se elas não existirem e estabeleça se a definição inclui os elementos de integração.
• Defina a atribuição de função no cofre de chaves para a identidade gerenciada atribuída pelo sistema.
• Crie as definições da conta de armazenamento se elas não existirem e estabeleça se a definição inclui os elementos de integração.
• Defina a atribuição de função no cofre de chaves para a identidade gerenciada atribuída pelo sistema.
• Implante as ações do conector.
• Implante o runbook de integração na conta de Automação.
• Implante as conexões dos Aplicativos Lógicos se elas forem definidas como parte do ambiente.

Destruir um ambiente do Microsoft Sentinel

Quando o ambiente não for mais necessário, como no caso de um ambiente de desenvolvimento ou teste, você poderá destruí-lo conforme definido neste arquivo.

src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml

Como quando você implanta o pipeline de ambiente, especifica o nome da conexão de serviço que representa o ambiente.

Trabalhando com seu ambiente do Microsoft Sentinel

Depois que o ambiente estiver pronto, você poderá começar a criar os artefatos para configurar os diferentes casos de uso.

1. Exporte os artefatos do ambiente em que você está trabalhando, conforme definido neste arquivo.

   src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.yml

2. Escolha o branch para a definição de ambiente no repositório.

   

3. Insira o nome da conexão de serviço do Azure DevOps para o ambiente que está sendo exportado na caixa Conexão de Ambiente do Azure.

4. Selecione Usar Artefatos de Pré-Lançamento do PowerShell se você quiser usar as versões de pré-lançamento dos componentes da estrutura do PowerShell.

5. Escolha o formato para as regras analíticas e de busca.

   O arquivo de saída de artefatos está disponível nos resultados. Depois de ter os artefatos, você pode incluir o arquivo de saída no repositório Git.

Compilar seus artefatos no ambiente do Microsoft Sentinel

Coloque seus artefatos no caminho de casos de uso do MITRE do Microsoft Sentinel. Configure sua estrutura de pastas de acordo com os diferentes tipos de artefatos.

1. Inicie o processo de build conforme definido neste arquivo.

   src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yaml

2. Escolha o branch para a definição de ambiente no repositório.

   Diagrama de como escolher o branch para a criação dos artefatos.] (./media/build-artifacts-pipeline.png)

3. Selecione Usar Artefatos de Pré-Lançamento do PowerShell se você quiser usar as versões de pré-lançamento dos componentes da estrutura do PowerShell.

O pipeline é composto por estas etapas:

• Implantar componentes do NuGet.
• Conecte as ferramentas do NuGet ao repositório de artefatos.
• Resolva o feed.
• Instalar os módulos necessários.
• Obtenha a estrutura do kit de ferramentas de teste para validar os modelos do ARM.
• Valide os modelos do ARM.
• Valide o código dos Runbooks do PowerShell e faça a validação da sintaxe.
• Execute os testes de unidade do Pester, se aplicável.
• Valide a sintaxe KQL nas regras de busca e análise.

Implante seus artefatos no ambiente do Microsoft Sentinel

Ao implantar seus artefatos, você pode usar os repositórios do Microsoft Sentinel ou os exemplos de pipeline de implantação neste repositório. Para obter mais informações, consulte Como implantar conteúdo personalizado a partir de seu repositório.

Repositórios do Microsoft Sentinel

Se você usar repositórios do Microsoft Sentinel, poderá configurar um processo de versão para incluir os artefatos no repositório conectado a cada instância do Microsoft Sentinel. Depois que os artefatos são confirmados no repositório, algumas das etapas são feitas automaticamente como parte da criação do pipeline e da habilitação dos repositórios do Microsoft Sentinel.

Além disso, você pode personalizar os processos de implantação que os repositórios do Microsoft Sentinel fazem com base nas práticas descritas neste documento. Um aspecto importante a ser considerado é a aprovação da versão, que você pode configurar seguindo estas abordagens:

• Aprovação de PR ao confirmar os artefatos. Para obter mais informações, consulte Criar pull requests.
• Libere a aprovação do pipeline ao executar a implantação. Para obter mais informações, confira Definir aprovações e verificações.

Exemplos de pipeline de implantação do Microsoft Sentinel

Usando os exemplos de pipeline de implantação do Microsoft Sentinel, você pode configurar um processo de lançamento.

1. Configure o processo de versão conforme definido neste arquivo.

   src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.yml

2. Escolha o branch para a definição de ambiente no repositório.

   

3. Insira o nome da conexão de serviço do Azure DevOps para o ambiente que está sendo exportado na caixa Conexão de Ambiente do Azure.

4. Selecione Usar Artefatos de Pré-Lançamento do PowerShell se você quiser usar as versões de pré-lançamento dos componentes da estrutura do PowerShell.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• Kevin Kisoka | Arquiteto Associado

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

• Para saber mais sobre o Microsoft Sentinel com o DevOps para arquitetura de locatário único, consulte Implantando e gerenciando o Microsoft Sentinel como código.
• Para saber mais sobre como criar uma arquitetura MSSP que funcione em vários diretórios do Microsoft Entra, consulte Combinando o Azure Lighthouse com os recursos de DevOps do Microsoft Sentinel.
• Para obter informações sobre identidade gerenciada com o Microsoft Sentinel, consulte Novidades: identidade gerenciada para o conector de Aplicativos Lógicos do Microsoft Sentinel.
• Para saber como implantar conteúdo de um repositório do Microsoft Sentinel, consulte Implantar conteúdo personalizado do repositório.
• Para saber mais sobre as considerações sobre a Segurança do Azure DevOps, consulte Referência rápida de permissões padrão.
• Para saber como proteger um repositório do Azure DevOps, consulte Adicionar proteção a um recurso de repositório.
• Para obter informações sobre como gerenciar a segurança de conexão de serviço do Azure DevOps, consulte Conexões de serviço no Azure Pipelines.

Recursos relacionados

• Monitoramento de Segurança Híbrida usando o Microsoft Defender para Nuvem e o Microsoft Sentinel
• Criar um pipeline de CI/CD usando o Azure DevOps
• Funcionalidade avançada de modelo do ARM