Share via

Confiabilidade na Segurança de DevOps do Microsoft Defender para Nuvem

  • Artigo

Este artigo descreve o suporte à confiabilidade em recursos de segurança de DevOps do Microsoft Defender para Nuvem, que inclui recuperação entre regiões e continuidade dos negócios. Para obter uma visão geral mais detalhada da confiabilidade no Azure, confira 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 para DevOps

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

A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.

Quando o assunto é 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 de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.

A segurança de DevOps do Microsoft Defender para Nuvem dá suporte à recuperação de desastre de região única. Dessa forma, um processo de recuperação de desastre de várias regiões simplesmente implementa o processo de recuperação de desastre de região única descrito neste documento.

Regiões com suporte

Para regiões que dão suporte à segurança do DevOps no Defender para Nuvem, consulte suporte à região de segurança do DevOps.

Processo de recuperação de desastre em região única

O processo de recuperação de desastre de região única para recursos de segurança do DevOps baseia-se no modelo de responsabilidade compartilhada e, portanto, inclui procedimentos do cliente e da Microsoft.

Responsabilidade do cliente

Quando uma região fica inoperante, 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 de ADO.

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

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

    Observação

    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 da região – recuperação do Conector de DevOps"
      4. Tipo de problema: Defender CSPM plan
      5. Subtipo do problema: DevOps security

  3. Copie a ID do recurso dos conectores de DevOps novos e antigos. Essas informações estão disponíveis no Azure Resource Graph. Formato da 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 de pull conforme necessário.

  5. O novo conector será transformado em primário. Quando a região se recupera da interrupção, você pode excluir com segurança o conector antigo.

Responsabilidade da Microsoft

Quando uma região cai e você estabeleceu o novo conector, a Microsoft recria todos os alertas, recomendações e entidades do grafo de segurança da nuvem do conector antigo para o novo conector.

Importante

A Microsoft não recria o histórico para 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 IaC (infraestrutura como código).

Testar o seu processo de recuperação de desastre

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

Próximas etapas

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

Confiabilidade no Azure