Comparteix a través de

Confiabilidad en Microsoft Defender for Cloud: seguridad de DevOps

  • Article

En este artículo se describe la compatibilidad con la confiabilidad en las característicasde seguridad de Microsoft Defender for Cloud DevOps, que incluye la recuperación entre regiones y lacontinuidad empresarial. Para obtener información general más detallada sobre la confiabilidad de Azure, consulte Confiabilidad de Azure.

Este artículo es específico para recuperarse en el caso de una interrupción de la región. Si desea trasladar el conector de DevOps existente a una nueva región, consulte Preguntas comunes sobre Defender para DevOps

Recuperación ante desastres entre regiones y continuidad empresarial

La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.

En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.

La seguridad de Microsoft Defender for Cloud DevOps admite la recuperación ante desastres de una sola región. Por lo tanto, un proceso de recuperación ante desastres de varias regiones simplemente implementa el proceso de recuperación ante desastres de una sola región descrito en este documento.

Regiones admitidas

Para ver las regiones que admiten la seguridad de DevOps en Defender for Cloud, consulte Compatibilidad conla región de seguridad de DevOps.

Recuperación ante desastres de una sola región

El proceso de recuperación ante desastres de una sola región para las características de seguridad de DevOps se basa en el modelode responsabilidad compartida, por lo que incluye los procedimientos de cliente y Microsoft.

Responsabilidad del cliente

Cuando una región deja de funcionar, se pierden las configuraciones del conector de esa región. Las configuraciones perdidas incluyen tokens de cliente, configuraciones de detección automática y configuraciones de anotaciones de ADO.

Para solicitar la recuperación de un conector creado en una región inactiva:

  1. Cree un nuevo conector en una nueva región. Consulte la documentación de incorporación para Azure DevOps, GitHubo GitLab.

    Nota:

    Puede usar un conector existente en la nueva región, siempre y cuando esté autenticado para tener acceso al ámbito de los recursos de DevOps en el conector anterior.

  2. Abra una nueva solicitud de soporte técnico para liberar la propiedad de los recursos de DevOps desde el conector anterior.

    1. En Azure Portal, vaya a Ayuda y soporte técnico
    2. Rellene el formulario:
      1. Tipo de incidencia: Technical
      2. Tipo de servicio: Microsoft Defender for Cloud
      3. Resumen: "Interrupción de la región: recuperación del conector de DevOps"
      4. Tipo de problema: Defender CSPM plan
      5. Subtipo de problema: DevOps security

  3. Copie el identificador de recurso de los conectores de DevOps nuevos y antiguos. Esta información está disponible en Azure Resource Graph. Formato del identificador de recurso: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Security/securityConnectors/{connectorName}

    Puede ejecutar la consulta siguiente mediante el Explorador de Azure Resource Graph para buscar el identificador de 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. Una vez que los recursos de DevOps se han liberado del conector anterior y aparecen para el nuevo conector, vuelva a configurar las anotaciones de solicitud de incorporación de cambios según sea necesario.

  5. El nuevo conector se convertirá en principal. Cuando la región se recupera de la interrupción, puede eliminar de forma segura el conector anterior.

Responsabilidad de Microsoft

Cuando una región deja de funcionar y ha establecido el nuevo conector, Microsoft vuelve a crear todas las alertas, recomendaciones y entidades de Cloud Security Graph desde el conector anterior al nuevo conector.

Importante

Microsoft no vuelve a crear el historial de algunas funcionalidades, como datos de asignación de contenedores de ejecuciones anteriores, datos de alertas de más de una semana de antigüedad e infraestructura como datos del historial de asignación de código (IaC).

Prueba del proceso de recuperación ante desastres

Para probar el proceso de recuperación ante desastres, puede simular un conector perdido mediante la creación de un segundo conector y siguiendo los pasos de soporte técnico anteriores.

Pasos siguientes

Para más información sobre los elementos que se describen en este artículo, consulte:

Confiabilidad en Azure