Automatize 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. Você implementa 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 configuração do Azure DevOps e do Microsoft Sentinel IaC.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

1. O scrum master e o gerenciamento de produtos usam o Azure DevOps para definir épicos, histórias de usuários e itens de lista de pendências de produtos como parte da lista de pendências do projeto.
   • O scrum master e o gerenciamento de produtos usam os Quadros do Azure para criar a lista de pendências, agendar o trabalho em sprints, revisar o quadro do projeto, criar a estrutura do repositório e definir regras de segurança, como fluxos de trabalho de aprovação e ramificações.
   • O repositório Git do Azure armazena os scripts e as permissões para gerenciar artefatos do Microsoft Sentinel na infraestrutura como código.
   • Os artefatos e o controle do código-fonte mantêm as extensões e os pacotes de atualização ou os componentes do fluxo de trabalho DevSecOps usados na solução, como o Kit de Ferramentas de Modelo do Azure Resource Manager e o PowerShell Pester.
2. Artefatos do Microsoft Sentinel:
   • Políticas. Os engenheiros do SIEM usam as 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 da Política do Azure.
   • Identidade gerida. O Microsoft Sentinel usa a identidade gerenciada para agir em nome da identidade de serviço gerenciado (MSI) enquanto interage com playbooks, aplicativos lógicos ou runbooks de automação e o cofre de chaves.
   • Automatização. As equipes SOC usam automação durante as investigações. As equipes SOC executam procedimentos de aquisição de dados forenses digitais com a Automação do Azure, como a cadeia de custódia da máquina virtual (VM) do Azure ou a Descoberta Eletrônica (Premium) para Microsoft Defender.
   • Análise. Os analistas 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 acionar playbooks se uma ameaça e um incidente forem identificados.
   • Cartilhas. 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.
   • Investigação de ameaças. Os caçadores de ameaças usam recursos proativos de caça a ameaças que podem ser acoplados aos notebooks Jupyter para casos de uso avançados, como processamento de dados, manipulação de dados, visualização de dados, aprendizado de máquina ou aprendizado profundo.
   • Pastas de trabalho. 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.
   • Informações sobre ameaças. Um conector de dados específico que funde plataformas de inteligência de ameaças alimenta o Microsoft Sentinel. Dois métodos de conectividade são suportados: TAXII e Graph API. Ambos os métodos servem como tiIndicators, ou indicadores de inteligência de ameaças, em APIs de segurança.
3. ID do Microsoft Entra. Os recursos de gerenciamento de identidade e acesso são fornecidos 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 o Microsoft Sentinel, aplicativos lógicos e runbooks de automação.
4. Azure Pipelines. Os engenheiros de DevOps usam pipelines para criar conexões de serviço para gerenciar as diferentes assinaturas do Azure, como ambientes de sandbox e produção com pipelines de integração contínua e entrega contínua (CI/CD). Recomendamos 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 SOC usam o cofre de chaves para armazenar com segurança os principais segredos e certificados do 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 de Pipeline do Azure.
6. Subscrição do Azure. As equipes 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 sandbox. Você pode dimensionar de acordo com suas necessidades com outros ambientes, como testes, 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 com seu repositório bifurcado.
3. Em seguida, o administrador cria uma solicitação pull (PR) para mesclar as alterações no repositório principal.
4. O pipeline de construção é executado no PR.

Componentes

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

Detalhes do cenário

Às vezes, as equipes do centro de operações de segurança (SOC) enfrentam desafios quando integram 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 se modernizar para a nuvem, os engenheiros devem aprender constantemente novas habilidades e técnicas para proteger e proteger ativos vitais de negócios. Os engenheiros devem criar soluções robustas e escaláveis que acompanhem as mudanças no cenário de segurança e 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. Esta metodologia de planeamento precoce é 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 suportados por esta solução incluem SOC local, SOC global, provedor de serviços de nuvem (CSP) e provedor de serviços de segurança gerenciados (MSSP).

Este artigo destina-se aos seguintes públicos:

• Especialistas em SOC, como analistas e caçadores de ameaças
• Engenheiros de gerenciamento de eventos e informações de segurança (SIEM)
• Arquitetos de cibersegurança
• Programadores

Potenciais casos de utilização

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

• Prototipagem rápida e prova de conceito. Esta solução é ideal para organizações de segurança e equipes SOC que desejam melhorar a cobertura de ameaças na nuvem ou modernizar sua infraestrutura SIEM com infraestrutura como código (IaC) e Microsoft Sentinel.
• Microsoft Sentinel como um serviço. Essa estrutura de desenvolvimento integra os princípios de gerenciamento do ciclo de vida do serviço. Esses princípios se adequam a equipes simples ou complexas, como MSSPs, que executam ações padronizadas e repetíveis em vários locatários de clientes enquanto combinam 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 agente de ameaça ou campanha em andamento pode usar essa solução.
• Criação de casos de uso de SOC para deteção de ameaças. Muitos grupos e plataformas de inteligência de ameaças confiam no conteúdo e na taxonomia MITRE Att&ck para analisar sua postura de segurança contra técnicas e procedimentos táticos avançados. A solução define uma abordagem estruturada para o desenvolvimento de práticas de engenharia de deteção de ameaças, incorporando a terminologia MITRE Att&ck no desenvolvimento de artefatos do Microsoft Sentinel.

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

Transfira um ficheiro do Visio desta 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 aspetos importantes de cenários de ataque.

Item de dados	Description	Artefatos do Microsoft Sentinel
Título	Nome descritivo para o cenário de ataque, com base nas características do vetor de ataque ou descrições da técnica.	Manifesto MITRE
Táticas MITRE ATT&CK	Táticas MITRE ATT&CK relacionadas ao cenário de ataque	Manifesto MITRE
Técnicas MITRE ATT&CK	Técnicas MITRE ATT&CK, incluindo a técnica ou ID da subtécnica, relacionadas com o cenário de ataque.	Manifesto MITRE
Fontes do conector de dados	Fonte de informação recolhida por um sensor ou sistema de registo que possa ser utilizada para recolher informações relevantes para identificar a ação que está a ser 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
Description	Informações sobre a técnica, o que é, para que é normalmente usada, como um adversário pode tirar proveito dela e variações sobre como ela pode ser usada. Inclui referências a artigos oficiais que descrevem informações técnicas relacionadas com a técnica, bem como referências de uso selvagem, conforme apropriado.
Detection	Processo analítico de alto nível, sensores, dados e estratégias de deteção úteis para identificar uma técnica que tenha sido usada por um adversário. Esta seção informa os responsáveis por detetar o comportamento adversário, como defensores de rede, para que possam tomar uma ação, como escrever um analítico ou implantar um sensor. Deve haver informações e referências suficientes para apontar para metodologias defensivas úteis. A deteção pode nem sempre ser possível para uma determinada técnica e deve ser documentada como tal.	Caça a ameaças do Google Analytics
Mitigaçã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 pela mitigação contra adversários, como defensores da rede ou formuladores de políticas, para permitir que eles tomem uma ação, como alterar uma política ou implantar uma ferramenta. A atenuação pode nem sempre ser possível para uma determinada técnica e deve ser documentada como tal.
Mitigaçã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 abrange etapas para alterar uma política ou implantar uma ferramenta. A atenuação pode nem sempre ser possível para uma determinada técnica e deve ser documentada como tal.	Playbooks, 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ê pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte 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 enquanto economiza tempo para casos de uso mais complexos, como engenharia de deteção de ameaças, inteligência de ameaças, SOC e casos de uso SOAR. As equipes de DevOps precisam saber onde podem usar o IaC com segurança no contexto do Microsoft Sentinel CI/CD. Esse processo introduz 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 lançamento do Microsoft Sentinel e do Azure DevOps.

Caso de utilização	Requisitos (privilégio mínimo)	Duração da atribuição de funções	Escopo da permissão	Administrador	Considerações de segurança
Ativar conectores do Microsoft Sentinel	Administrador de segurança** Proprietário* Contribuidor do Microsoft Sentinel Leitor	JIT (ativação única) De propósito (sempre que uma nova assinatura e conector são implantados)	Inquilino	SPN	Use o cofre de chaves para armazenar segredos e certificado do SPN (nome principal do serviço). Habilite a auditoria SPN. Periodicamente, revise 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 suportada) para contas privilegiadas. Use as funções personalizadas do Microsoft Entra para obter mais granularidade.
Implantar artefatos do Microsoft Sentinel, como pastas de trabalho, análises, regras, consultas de caça a ameaças, blocos de anotações e playbooks	Colaborador do Microsoft Sentinel Contribuidor de Aplicativos Lógicos	Permanente	Espaço de trabalho ou grupo de recursos do Microsoft Sentinel	SPN	Use a aprovação e as verificações do fluxo de trabalho do Azure DevOps (ADO) para proteger a implantação do pipeline com este SPN.
Atribuir uma política para configurar recursos de streaming de log ao Microsoft Sentinel	Contribuidor da Política de Recursos **	De propósito (sempre que uma nova assinatura e conector são implantados)	Todas as subscrições a monitorizar	SPN	Use o Microsoft Entra ID, CA e MFA, quando suportado, para contas privilegiadas.

* Apenas diz respeito às configurações de diagnóstico do Microsoft Entra.
** Conectores específicos precisam de permissões adicionais, como "administrador de segurança" ou "contribuidor de política de recursos" para permitir o streaming de dados para o espaço de trabalho Microsoft Sentinel, Microsoft Entra ID, Microsoft 365 ou Microsoft Defender e recursos de plataforma como serviço (PaaS), como o Azure Key Vault.

Modelo de acesso privilegiado

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

O acesso privilegiado deve ser a principal prioridade de segurança em todas as empresas. Qualquer comprometimento dessas identidades cria impactos altamente negativos. As identidades privilegiadas têm acesso a ativos críticos para os negócios, o que quase sempre causa grandes impactos quando 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 minar 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 de privilégio mínimo. A ilustração a seguir mostra como classificar as entidades de serviço, dependendo do tipo de acesso e 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 para esta conta com segurança no Cofre da Chave do Azure. Recomendamos vivamente que localize o cofre de chaves numa subscrição 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 permitem 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 esta entidade de serviço persistem, pelo que recomendamos vivamente que conceda apenas as permissões mínimas necessárias e mantenha a conta monitorizada e protegida.

Armazene o segredo ou certificado para esta conta com segurança no Cofre da Chave do Azure. Recomendamos vivamente que localize o cofre de chaves numa subscrição administrativa dedicada, se possível.

Entidades de serviço de nível 2

As entidades de serviço de nível 2 estão limitadas ao nível de subscrição. Essas entidades de serviço permitem que alguém execute tarefas administrativas sob uma assinatura, agindo 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, é altamente recomendável que você conceda apenas as permissões mínimas necessárias e mantenha a conta monitorada e protegida.

Armazene o segredo ou certificado para esta conta com segurança no Cofre da Chave do Azure. É altamente recomendável 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 estã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 este 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, é altamente recomendável que você conceda apenas as permissões mínimas necessárias e mantenha a conta monitorada e protegida.

Armazene o segredo ou certificado para esta conta com segurança no Cofre da Chave do Azure. É altamente recomendável 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 certificado com segurança no Cofre da Chave do Azure, onde os segredos de Nível 3 são armazenados.

Excelência operacional

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

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

O primeiro bloco é a definição do ambiente, que compõe os elementos essenciais da arquitetura. 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 Microsoft Sentinel, onde 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 dos artefatos do Microsoft Sentinel, que abrange codificação, implantação e uso ou destruição dos componentes. Por exemplo, este bloco contém as regras analíticas, playbooks, pastas de trabalho, caça a ameaças e assim por diante.

Considere estas dependências entre artefatos:

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

Crie, teste e implante infraestrutura

Ao gerenciar soluções Microsoft Sentinel e DevOps, é importante considerar os aspetos de conectividade e segurança da arquitetura corporativa.

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

• Agentes alojados na Microsoft. Essa opção é a maneira mais rápida de trabalhar com agentes de DevOps do Azure, porque é 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 para os intervalos de IP. Para baixar os intervalos de IP aos quais esses agentes concedem acesso, consulte Intervalos de IP do Azure e Tags de Serviço – Nuvem Pública.
• Agentes auto-hospedados. Essa opção oferece recursos dedicados e mais controle ao instalar software dependente para suas compilações e implantações. Os 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 corredores 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.

Corredores 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 corredores 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 Corredores suportados e recursos de hardware.

Corredores auto-hospedados

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

Considerações para a escolha de corredores

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

• Sua empresa precisa de recursos dedicados para executar processos em seus ambientes Microsoft Sentinel?
• Deseja isolar recursos para atividades de DevOps do ambiente de produção do restante dos ambientes?
• Você precisa testar certos 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 liberação

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 um pipeline de versão. Para obter mais informações sobre como usar um pipeline YAML no Azure DevOps, consulte Usar pipelines do Azure. Para obter mais informações sobre como usar um pipeline de versão no Azure DevOps, consulte Pipelines de versão. Para obter mais informações sobre como usar o GitHub com ações do GitHub, consulte Noções básicas sobre ações do GitHub.

Azure DevOps

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

• Use um pipeline YAML para acionar automaticamente aprovações de RP ou executar sob demanda.
• Gerencie conexões de serviço para diferentes ambientes usando grupos de DevOps do Azure.
• Em seus ambientes críticos, configure aprovações de implantação usando o recurso de conexão de serviço e os grupos de DevOps do Azure 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 RPs 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 Microsoft Sentinel, dependendo da arquitetura da sua empresa:

• 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 na configuração de suas definições de ambiente, física ou lógica. Ambos têm diferentes opções e vantagens:

• Definição física - Os elementos da arquitetura do Microsoft Sentinel são definidos com as seguintes opções para infraestrutura como código (IaC):
  • Modelos de bíceps
  • Modelos do Azure Resource Manager (modelos ARM)
  • Terraform
• Definição lógica - Atua como uma camada de abstração para montar diferentes equipes no grupo e definir seus ambientes. A definição é definida no pipeline de implantação e fluxos de trabalho como entrada para o ambiente de compilação 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ódigo

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

Definição física - Com base nas opções do IaC, pense em uma abordagem que use 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.

Restringir o acesso a este repositório à equipa que define a arquitetura a 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 precisa começar com a definição, consulte Adotar uma estratégia de ramificação do Git.

Para obter mais informações sobre modelos ARM, consulte Usando modelos vinculados e aninhados ao implantar recursos do Azure.

Para obter mais informações sobre como configurar ambientes Bicep, consulte Instalar ferramentas 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 RP que são feitas por diferentes equipes. Vários ambientes são definidos por diferentes equipes e aprovados pelos proprietários ou aprovadores da empresa.

O nível de privilégio para executar uma implantação de ambiente é Nível 2. Este nível garante que o grupo de recursos e os recursos são criados para o ambiente com a segurança e privacidade necessárias. Este nível também define as permissões de usuário em ações permitidas nos ambientes de produção, 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 o teste, podem implementar um pipeline do Azure DevOps ou ações do GitHub. Eles podem definir gatilhos agendados para destruir os ambientes, conforme necessário, usando eventos do Azure DevOps ou ações do GitHub.

Configuração automática dos conectores Microsoft Sentinel

Os conectores Microsoft Sentinel são uma parte essencial da solução que suporta a conexão com diferentes elementos no cenário da arquitetura corporativa, como Microsoft Entra ID, Microsoft 365, Microsoft Defender, soluções de plataforma de inteligência de 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 de DevOps deve ser suportada pelo 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 privilegiado	Privilégio mínimo do Azure	Requer aprovação do 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	Recomendado
Microsoft Defender XDR	Nível 0	administrador global ou administrador de segurança	Recomendado
Microsoft Defender para IOT	Nível 2	Contribuinte	Recomendado
Microsoft Defender para a Cloud	Nível 2	Leitor de Segurança	Opcional
Atividade do Azure	Nível 2	Leitor de Subscrição	Opcional
Plataformas de Inteligência de Ameaças	Nível 0	administrador global ou administrador de segurança	Recomendado
Eventos de Segurança	Level 4	Nenhuma	Opcional
Syslog	Level 4	Nenhuma	Opcional
DNS (pré-visualização)	Level 4	Nenhuma	Opcional
Firewall do Windows	Level 4	Nenhuma	Opcional
Eventos de segurança do Windows via AMA	Level 4	Nenhuma	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 prevenir e remediar ataques.

A implementação dos artefatos pode ser de responsabilidade de uma ou várias equipes. A construção automática e a implantação de artefatos geralmente são o requisito de processo mais comum e determinam a abordagem e as condições para seus agentes e corredores.

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, consulte Microsoft Sentinel REST API. 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 usa MITRE, considere classificar os diferentes artefatos e especificar as táticas e técnicas para cada um. Certifique-se de incluir um arquivo de metadados correspondente para cada tipo de artefato.

Por exemplo, se você estiver criando um novo manual usando um modelo ARM do Azure e o nome do arquivo for Playbook.arm.json, você adicionará 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 configuração para os diferentes tipos de artefatos que você usa.

Construa artefatos

O objetivo do seu processo de construção é garantir que você gere artefatos da mais alta qualidade. O diagrama a seguir mostra algumas das ações do processo de compilação que você pode tomar.

Transfira um ficheiro do Visio desta arquitetura.

• Você pode basear sua definição de artefato em um esquema descritivo no formato JSON ou YAML e, em seguida, validar o esquema para evitar erros de sintaxe.
  • Valide seus modelos ARM usando o kit de ferramentas de teste de modelo ARM.
  • Valide seus arquivos YAML e JSON para modelos personalizados usando o PowerShell.
• Valide as configurações da sua lista de observação e certifique-se de que os registros de roteamento entre domínios sem classe (CIDR) definidos sigam o esquema correto, por exemplo, 10.1.0.0/16.
• Use consultas de linguagem de consulta de palavra-chave (KQL), que você pode validar no nível da sintaxe, para regras analíticas, regras de caça e regras de transmissão ao vivo, que você pode validar no nível da sintaxe.
• Faça da validação local do KQL uma opção.
• Integre a ferramenta de validação em linha KQL no pipeline de DevOps.
• Se você estiver implementando uma lógica baseada no PowerShell para Automação do Azure, poderá incluir validação de sintaxe e 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 com os artefatos.

Exportar artefatos

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

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

Transfira um ficheiro do Visio desta arquitetura.

Implantar artefatos

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

• Reduza o tempo de colocação no mercado.
• Aumente o desempenho entre as várias equipes envolvidas na configuração e no gerenciamento de sua solução.
• Configure testes 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 diferentes artefatos como regras analíticas, manuais de remediação, listas de observação e assim por diante. Uma parte de cada caso de uso inclui a simulação de ataques em que toda a cadeia é avaliada desde a ingestão, deteção e remediação.

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

Transfira um ficheiro do Visio desta arquitetura.

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

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

Artefacto	Fluxos de trabalho de automação
Listas de observação	Revisão do código Validação do esquema Implementação Criar, atualizar, excluir listas de observação e itens
Fusão de regras de análise Microsoft Security Análise comportamental de ML Anomalia Agendado	Revisão do código Validação da sintaxe KQL Validação de esquemas Pester Implementação Criar, Ativar, Atualizar, Excluir, Exportar Suporte a modelos de alerta
Regras de automatização	Revisão do código Validação de esquemas Implementação Criar, ativar, atualizar, excluir, exportar
Conectores	Revisão do código Validação de esquemas Implementação Ações: ativar, excluir (desabilitar), atualizar
Regras da caça	Revisão do código Validação da sintaxe KQL Validação de esquemas Pester Implementação Ações: criar, habilitar, atualizar, excluir, exportar
Manuais de Procedimentos	Revisão do código TTK Implementação Ações: criar, habilitar, atualizar, excluir, exportar
Livros	Implementação Ações: criar, atualizar, excluir
Runbooks	Revisão do código Validação de sintaxe do PowerShell Pester Implementação Ações: criar, habilitar, atualizar, excluir, exportar

Dependendo da linguagem de automação escolhida, alguns recursos de automação podem não ser suportados. O diagrama a seguir mostra quais recursos de automação são suportados pela linguagem.

* Recursos em desenvolvimento que ainda não estão documentados
** Métodos de automação suportados pelo Microsoft Operational Insights ou APIs do Microsoft Insights Resource Provider

Azure Automation

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

Transfira um ficheiro do Visio desta arquitetura.

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

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

• Integração com soluções de terceiros, onde 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 da entidade de serviço Microsoft Entra
  • Autenticação de certificados
  • Credenciais personalizadas
  • Identidade gerida
• 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 para playbooks:
  • Soluções baseadas em PowerShell
  • Soluções baseadas em Python
• Implementação de soluções em cenários híbridos, onde as ações de correção podem afetar seus recursos locais e na nuvem.

Repositórios do Microsoft Sentinel

Equipes experientes de DevOps podem considerar o gerenciamento do Microsoft Sentinel na infraestrutura como código (IaC) com pipelines de CI/CD 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, portanto, as duas iniciativas a seguir podem ajudar:

• Documentando a arquitetura de referência
• Desenvolvimento de uma nova solução, anunciada no Ignite 2021, que se chama "Microsoft Sentinel Repositories"

Para apoiar a escolha da solução que se adapta às necessidades da sua equipa, a tabela seguinte compara os critérios funcionais e técnicos.

Caso de uso e recursos	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 da arquitetura do Azure DevOps, como agentes, pipelines, Git, painéis, um wiki, entidades de serviço, RBACs, auditoria e assim por diante.	Não recomendado	Recomendado
Temos equipes pequenas e conjuntos de habilidades baixas para gerenciar os pipelines de CI/CD.	Não recomendado	Recomendado
Queremos controlar e gerenciar todos os aspetos de segurança dos pipelines de CI/CD.	Suportado	Não suportado
Precisamos integrar portas e ramificações para supervisionar a integração, antes de permitir que os desenvolvedores acionem pipelines de implantação, como controle de código-fonte, revisão de código-fonte, reversão, aprovação de fluxo de trabalho e assim por diante.	Suportado	Parcialmente suportado
Temos uma estrutura personalizada de Git ou repositório.	Suportado	Suportado
Não usamos as linguagens Resource Manager ou Bicep IaC para criar artefatos.	Suportado	Não suportado
Queremos gerenciar centralmente a implantação de artefatos em vários espaços de trabalho do Microsoft Sentinel em um único locatário do Microsoft Entra.	Suportado	Suportado
Queremos integrar ou estender pipelines de CI/CD em vários locatários do Microsoft Entra.	Suportado	Suportado
Temos playbooks com parametrização diferente dependendo da assinatura, localização, ambiente e assim por diante.	Suportado	TBD, diretrizes a serem documentadas
Queremos integrar diferentes artefatos no mesmo repositório para compor casos de uso.	Suportado	Suportado
Queremos a capacidade de remover artefatos em massa.	Suportado	Não suportado

Disponibilidade, desempenho e escalabilidade

Ao escolher a arquitetura para os agentes de DevOps do Azure 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 Microsoft Sentinel.
• Os 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.
  • Os cenários de simulação de ataque são um caso especial em que podem ser necessários agentes dedicados. 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 Visão geral do Azure Lighthouse.

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

• Gerencie recursos do Microsoft Sentinel em locatários de clientes.
• Rastreie ataques e visualize alertas de segurança em vários locatários.
• Exiba incidentes em vários espaços de trabalho do Microsoft Sentinel espalhados entre locatários.

Métodos para integrar clientes

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

Integração manual usando um modelo ARM

Se não quiser publicar uma oferta no Azure Marketplace como fornecedor de serviços ou se não cumprir todos os requisitos, pode integrar os clientes manualmente utilizando modelos ARM. Essa é a opção mais provável em um cenário corporativo, onde 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 gerido	Modelos do ARM
Requer uma conta do Partner Center	Sim	No
Requer o nível de competência da plataforma de nuvem Silver ou Gold ou o status do Azure Expert Managed Services Provider (MSP)	Sim	No
Disponível para novos clientes através do Azure Marketplace	Sim	No
Pode limitar a oferta a clientes específicos	Sim (apenas com ofertas privadas, que não podem ser usadas com assinaturas estabelecidas por meio de um revendedor do programa CSP)	Sim
Requer aceitação do cliente no portal do Azure	Sim	No
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 ARM, consulte Criar e implantar modelos ARM.

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

Transfira um ficheiro do Visio desta arquitetura.

1. Uma oferta MSP é integrada através de um modelo 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 parceiro e chama um provedor de recursos de serviço gerenciado.
3. O provedor de recursos de serviço gerenciado usa o RBAC para controlar o acesso do MSP.
4. O MSP conclui ações SecOps em um recurso do cliente.
5. O processo de faturação trata as despesas como encargos do cliente. A cobrança dividida é possível se as entidades do cliente tiverem espaços de trabalho 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.

Identidade em 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 utilização	Prós
Identidade global para gerenciar ações de DevOps, entidade de serviço única	Este caso se aplica a processos de implantação global, que envolvem todos os locatários. O uso da identidade unificada facilita o acesso para os diferentes locatários, mas pode tornar complexo o processo de gerenciamento de ações de aprovação para locatários específicos. 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 que exigem aprovação. Neste caso, a recomendação para proteger e autorizar o uso dessa identidade é a mesma do caso global, mesmo quando o impacto é reduzido.

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

Caso de utilização	Prós
Repositório unificado com uma única versão de código para todos os locatários	Este caso facilita ter versões unificadas para o código no repositório. Nesse caso, uma versão unificada do código gerenciando uma versão específica para locatários pode exigir suporte sobre ramificações para cada caso.
Repositório unificado com pastas de código específicas por locatário	Este 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. Facilita a evolução entre inquilinos com equipas ou requisitos diferentes. A consolidação de alterações requer o estabelecimento de um processo entre repositórios, o que pode exigir esforço de manutenção.

Processos de compilação e implementação

Caso de utilização	Prós
Processo de compilação ú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 compilação por locatário	Uma versão diferente do código é implantada para 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.
Processo de implantação global locatário 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 custos

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

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

• O volume de dados que sua empresa alimenta mensalmente no espaço de trabalho do Microsoft Sentinel Log Analytics
• O nível de compromisso ou método de cobrança escolhido, como o 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 preços, consulte a calculadora de preços do Microsoft Sentinel. Para obter mais informações sobre as considerações e exemplos avançados de preços, consulte Planejar custos para o Microsoft Sentinel.

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

• Playbooks - tempos de execução para Aplicativos Lógicos do Azure e Azure Functions. Para obter mais informações, consulte Detalhes de preços.
• Exportar para armazenamento externo, como o Azure Data Explorer, Hubs de Eventos ou uma conta de Armazenamento do Azure.
• Um espaço de trabalho de aprendizado de máquina e a computação que um componente do Jupyter Notebook usa.

Implementar 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.

Crie e libere a estrutura do Microsoft Sentinel

Primeiro, configure os componentes necessários do NuGet em um repositório dedicado onde 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 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 Criar repositórios do GitHub. Nesse caso, você cria um novo pipeline e escolhe o GitHub como a fonte do 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.

Defina seu ambiente 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. Você especifica os diferentes elementos que compõem o ambiente em cada caso.

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

• Espaço de trabalho do Log Analytics - Este espaço de trabalho forma a base da solução. Informações relacionadas à segurança são armazenadas aqui e o espaço de trabalho é o mecanismo para Kusto Query Language (KQL).
• Solução Microsoft Sentinel sobre o espaço de trabalho do Log Analytics - Esta solução estende a funcionalidade do espaço de trabalho do Log Analytics para incluir recursos SIEM e SOAR.
• Cofre de chaves - O cofre de chaves mantém os segredos e chaves que são usados durante os processos de correção.
• Conta de automação - Esta conta é opcional e é usada para os processos de correção. O processo de correção que você usa é baseado nos runbooks do PowerShell e do Python. O processo inclui uma identidade gerenciada pelo sistema que funciona com diferentes recursos de acordo com as melhores práticas.
• Identidade gerenciada pelo usuário - Este recurso atua como uma camada de identidade unificada do Microsoft Sentinel que gerencia interações entre playbooks e runbooks do Microsoft Sentinel.
• Conexões de aplicativo lógico - São conexões para o Microsoft Sentinel, o cofre de chaves e automação que usam a identidade gerenciada pelo usuário.
• Conexões de aplicativos lógicos externos - São conexões para recursos externos envolvidos nos processos de correção e baseados nos playbooks.
• Hubs de Eventos do Azure - Este 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 - Este 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.

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, como 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 de seus casos de uso.

Implantar seu ambiente Microsoft Sentinel

Quando você tiver pelo menos um ambiente definido, poderá criar a conexão de serviço do Azure para integrar com o 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 a ramificação para a definição de ambiente no repositório. 

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

5. Digite 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 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:

• Implante componentes do NuGet.
• Conecte-se usando as ferramentas NuGet com o repositório de artefatos.
• Resolva o feed.
• Instale os módulos necessários.
• Obtenha 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 espaço de trabalho.
• 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 ao sistema.
• Defina a atribuição de função no cofre de chaves para a identidade gerenciada atribuída ao sistema.
• Crie as definições de Hubs de Eventos se elas não existirem e defina 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 ao sistema.
• Crie as definições de conta de armazenamento se elas não existirem e defina 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 ao sistema.
• Implante as ações do conector.
• Implante o runbook de integração na conta de automação.
• Implante as conexões de aplicativos lógicos se elas forem definidas como parte do ambiente.

Destrua um ambiente Microsoft Sentinel

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

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

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

Trabalhando com seu ambiente Microsoft Sentinel

Depois que seu 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 a ramificação 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 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 caça.

   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.

Crie seus artefatos no ambiente Microsoft Sentinel

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

1. Inicie o processo de compilação conforme definido neste arquivo.

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

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

   Diagrama de como escolher o ramo para construir os artefatos.] (./media/build-artifacts-pipeline.png)

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

O pipeline é composto pelas seguintes etapas:

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

Implante seus artefatos no ambiente 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 Implantar conteúdo personalizado do repositório.

Repositórios do Microsoft Sentinel

Se você usar repositórios do Microsoft Sentinel, poderá configurar um processo de liberaçã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 aspeto importante a considerar é a aprovação da versão, que você pode configurar seguindo estas abordagens:

• Aprovação de RP ao cometer os artefatos. Para obter mais informações, consulte Criar solicitações pull.
• Libere a aprovação do pipeline ao executar a implantação. Para obter mais informações, consulte 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 versão.

1. Configure seu processo de liberação conforme definido neste arquivo.

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

2. Escolha a ramificação 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 quiser usar as versões de pré-lançamento dos componentes da estrutura do PowerShell.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Kevin Kisoka - Brasil | Arquiteto Associado

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

Próximos passos

• Para saber mais sobre o Microsoft Sentinel com DevOps para arquitetura de locatário único, consulte Implantando e gerenciando o Microsoft Sentinel como código.
• Para saber mais sobre a arquitetura multilocatária do MSSP, 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 do Azure DevOps Security, 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 da conexão de serviço do Azure DevOps, consulte Conexões de serviço no Azure Pipelines.

Recursos relacionados

• Monitoramento de segurança híbrido usando o Microsoft Defender para nuvem e o Microsoft Sentinel
• Projetar um pipeline de CI/CD usando o Azure DevOps
• Funcionalidade avançada de modelo ARM