Fiabilidade do Microsoft Defender para a segurança da Cloud de DevOps

  • Artigo

Este artigo descreve o suporte à confiabilidade nos recursos de segurança do Microsoft Defender for Cloud DevOps, que inclui recuperação entre regiões e continuidade de negócios. Para obter uma visão geral mais detalhada da confiabilidade no Azure, consulte Confiabilidade do Azure.

Este artigo é específico para recuperação no caso de uma interrupção de região. Se você estiver procurando mover seu conector de DevOps existente para uma nova região, consulte Perguntas comuns sobre o Defender for DevOps

Recuperação de desastres entre regiões e continuidade de negócios

A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Quando se trata de DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.

A segurança do Microsoft Defender for Cloud DevOps oferece suporte à recuperação de desastres em uma única região. Como tal, um processo de recuperação de desastres de várias regiões simplesmente implementa o processo de recuperação de desastres de região única descrito neste documento.

Regiões suportadas

Para regiões que oferecem suporte à segurança de DevOps no Defender for Cloud, consulte Suporte a regiões de segurança de DevOps.

Processo de recuperação de desastres em uma única região

O processo de recuperação de desastres de região única para recursos de segurança de DevOps é baseado no modelo de Responsabilidade Compartilhada e, portanto, inclui procedimentos do cliente e da Microsoft.

Responsabilidades do cliente

Quando uma região fica inativa, suas configurações para o conector dessa região são perdidas. As configurações perdidas incluem tokens de cliente, configurações de descoberta automática e configurações de anotações ADO.

Para solicitar a recuperação de um conector criado em uma região baixa:

  1. Crie um novo conector em uma nova região. Consulte a documentação de integração do Azure DevOps, GitHub e/ou GitLab.

    Nota

    Você pode usar um conector existente na nova região, desde que ele seja autenticado para ter acesso ao escopo dos recursos de DevOps no conector antigo.

  2. Abra uma nova solicitação de suporte para liberar a propriedade dos recursos de DevOps do conector antigo.

    1. No portal do Azure, navegue até Ajuda + Suporte
    2. Preencha o formulário:
      1. Tipo de problema: Technical
      2. Tipo de serviço: Microsoft Defender for Cloud
      3. Resumo: "Interrupção de região - recuperação do DevOps Connector"
      4. Tipo de problema: Defender CSPM plan
      5. Subtipo de problema: DevOps security

  3. Copie a ID do recurso dos conectores DevOps novos e antigos. Essas informações estão disponíveis no Azure Resource Graph. Formato de ID do recurso: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Security/securityConnectors/{connectorName}

    Você pode executar a consulta abaixo usando o Azure Resource Graph Explorer para localizar a ID do Recurso:

    resources
 | extend connectorType = tostring(parse_json(properties["environmentName"]))
 | where type == "microsoft.security/securityconnectors"
 | where connectorType in ("AzureDevOps", "Github", "GitLab")
 | project connectorResourceId = id, region = location

  4. Depois que os recursos de DevOps tiverem sido liberados do conector antigo e aparecerem para o novo conector, reconfigure as anotações de solicitação pull conforme necessário.

  5. O novo conector será feito primário. Quando a região se recuperar da interrupção, você poderá excluir com segurança o conector antigo.

Responsabilidade da Microsoft

Quando uma região fica inativa e você estabelece o novo conector, a Microsoft recria todos os alertas, recomendações e entidades do Cloud Security Graph do conector antigo para o novo conector.

Importante

A Microsoft não recria o histórico de algumas funcionalidades, como dados de mapeamento de contêiner de execuções anteriores, dados de alertas com mais de uma semana e dados de histórico de mapeamento de infraestrutura como código (IaC).

Teste seu processo de recuperação de desastres

Para testar seu processo de recuperação de desastres, você pode simular um conector perdido criando um segundo conector e seguindo as etapas de suporte acima.

Próximos passos

Para saber mais sobre os itens discutidos neste artigo, consulte:

Fiabilidade no Azure