Affidabilità in Microsoft Defender per il cloud - Sicurezza di DevOps

  • Articolo

Questo articolo descrive il supporto dell'affidabilità nelle funzionalità di sicurezza di Microsoft Defender per il cloud DevOps, che include il ripristino tra aree e la continuità aziendale. Per una panoramica più dettagliata dell'affidabilità in Azure, vedere Affidabilità di Azure.

Questo articolo è specifico per il ripristino in caso di interruzione dell'area. Per spostare il connettore DevOps esistente in una nuova area, vedere Domande comuni su Defender per DevOps

Ripristino di emergenza tra aree e continuità aziendale

Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.

Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.

Microsoft Defender per il cloud la sicurezza devOps supporta il ripristino di emergenza a singola area. Di conseguenza, un processo di ripristino di emergenza in più aree implementa semplicemente il processo di ripristino di emergenza a singola area descritto in questo documento.

Aree geografiche supportate

Per le aree che supportano la sicurezza devOps in Defender per il cloud, vedere Supporto per le aree di sicurezza devOps.

Processo di ripristino di emergenza a singola area

Il processo di ripristino di emergenza in una singola area per le funzionalità di sicurezza DevOps si basa sul modello di responsabilità condivisa e include sia le procedure del cliente che di Microsoft.

Responsabilità del cliente

Quando un'area diventa inattiva, le configurazioni per il connettore di tale area andranno perse. Le configurazioni perse includono token del cliente, configurazioni di individuazione automatica e configurazioni di annotazioni ADO.

Per richiedere il ripristino di un connettore creato in un'area inattiva:

  1. Creare un nuovo connettore in una nuova area. Vedere la documentazione di onboarding per Azure DevOps, GitHub e/o GitLab.

    Nota

    È possibile usare un connettore esistente nella nuova area, purché sia autenticato per avere accesso all'ambito delle risorse DevOps nel connettore precedente.

  2. Aprire una nuova richiesta di supporto per rilasciare la proprietà delle risorse DevOps dal connettore precedente.

    1. In portale di Azure passare a Guida e supporto
    2. Compilare il modulo:
      1. Tipo di problema: Technical
      2. Tipo di servizio: Microsoft Defender for Cloud
      3. Riepilogo: "Interruzione dell'area - Ripristino di DevOps Connessione or"
      4. Tipo di problema: Defender CSPM plan
      5. Sottotipo del problema: DevOps security

  3. Copiare l'ID risorsa dei connettori DevOps nuovi e precedenti. Queste informazioni sono disponibili in Azure Resource Graph. Formato ID risorsa: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Security/securityConnectors/{connectorName}

    È possibile eseguire la query seguente usando Azure Resource Graph Explorer per trovare l'ID risorsa:

    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. Dopo che le risorse DevOps sono state rilasciate dal connettore precedente e visualizzate per il nuovo connettore, riconfigurare le annotazioni della richiesta pull in base alle esigenze.

  5. Il nuovo connettore verrà reso primario. Quando l'area viene ripristinata dall'interruzione, è possibile eliminare in modo sicuro il connettore precedente.

Responsabilità di Microsoft

Quando un'area si arresta e si è stabilito il nuovo connettore, Microsoft ricrea tutti gli avvisi, le raccomandazioni e le entità Cloud Security Graph dal connettore precedente al nuovo connettore.

Importante

Microsoft non ricrea la cronologia per alcune funzionalità, ad esempio i dati di mapping dei contenitori delle esecuzioni precedenti, i dati degli avvisi più di una settimana precedente e l'infrastruttura come dati della cronologia dei mapping del codice (IaC).

Testare il processo di ripristino di emergenza

Per testare il processo di ripristino di emergenza, è possibile simulare un connettore perso creando un secondo connettore e seguendo la procedura di supporto precedente.

Passaggi successivi

Per altre informazioni sugli elementi descritti in questo articolo, vedere:

Affidabilità in Azure