Share via

Betrouwbaarheid in Microsoft Defender voor Cloud - DevOps Beveiliging

  • Artikel

In dit artikel wordt de betrouwbaarheidsondersteuning in Microsoft Defender voor Cloud DevOps-beveiligingsfuncties beschreven, waaronder herstel in meerdere regio's en bedrijfscontinuïteit. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheid in Azure.

Dit artikel is specifiek voor herstel in het geval van een storing in de regio. Als u uw bestaande DevOps-connector naar een nieuwe regio wilt verplaatsen, raadpleegt u veelgestelde vragen over Defender voor DevOps

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

Microsoft Defender voor Cloud DevOps-beveiliging biedt ondersteuning voor herstel na noodgevallen in één regio. Als zodanig implementeert een herstelproces voor meerdere regio's eenvoudigweg het herstelproces voor één regio dat in dit document wordt beschreven.

Ondersteunde regio’s

Zie de ondersteuning voor DevOps-beveiligingsregio's voor regio's die DevOps-beveiliging ondersteunen in Defender voor Cloud.

Herstelproces voor één regio

Het herstelproces voor één regio voor DevOps-beveiligingsfuncties is gebaseerd op het model voor gedeelde verantwoordelijkheid, en omvat dus zowel klant- als Microsoft-procedures.

Verantwoordelijkheid van klant

Wanneer een regio uitvalt, gaan uw configuraties voor de connector van die regio verloren. Verloren configuraties omvatten klanttokens, configuraties voor automatische detectie en ADO-aantekeningen.

Herstel aanvragen van een connector die is gemaakt in een omlaag geplaatste regio:

  1. Maak een nieuwe connector in een nieuwe regio. Raadpleeg de onboardingdocumentatie voor Azure DevOps, GitHub en/of GitLab.

    Notitie

    U kunt een bestaande connector in de nieuwe regio gebruiken, zolang deze is geverifieerd voor toegang tot het bereik van DevOps-resources in de oude connector.

  2. Open een nieuwe ondersteuningsaanvraag om het eigendom van de DevOps-resources van de oude connector vrij te geven.

    1. Navigeer in Azure Portal naar Help en ondersteuning
    2. Vul het formulier in:
      1. Type probleem: Technical
      2. Servicetype: Microsoft Defender for Cloud
      3. Samenvatting: 'Regiostoring - DevOps Verbinding maken or-herstel'
      4. Probleemtype: Defender CSPM plan
      5. Subtype probleem: DevOps security

  3. Kopieer de resource-id van de nieuwe en oude DevOps-connectors. Deze informatie is beschikbaar in Azure Resource Graph. Resource-id-indeling: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Security/securityConnectors/{connectorName}

    U kunt de onderstaande query uitvoeren met behulp van Azure Resource Graph Explorer om de resource-id te vinden:

    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. Zodra de DevOps-resources zijn vrijgegeven uit de oude connector en voor de nieuwe connector worden weergegeven, configureert u indien nodig de aantekeningen voor de pull-aanvraag opnieuw.

  5. De nieuwe connector wordt primair gemaakt. Wanneer de regio uit de storing wordt hersteld, kunt u de oude connector veilig verwijderen.

Verantwoordelijkheid van Microsoft

Wanneer een regio uitvalt en u de nieuwe connector hebt ingesteld, maakt Microsoft alle waarschuwingen, aanbevelingen en Cloud Security Graph-entiteiten van de oude connector opnieuw in de nieuwe connector.

Belangrijk

Microsoft maakt geen geschiedenis opnieuw voor sommige functies, zoals containertoewijzingsgegevens uit eerdere uitvoeringen, waarschuwt gegevens meer dan één week oud en infrastructuur als codegeschiedenisgegevens (IaC).

Uw proces voor herstel na noodgevallen testen

Als u het herstelproces voor noodgevallen wilt testen, kunt u een verloren connector simuleren door een tweede connector te maken en de bovenstaande ondersteuningsstappen te volgen.

Volgende stappen

Zie voor meer informatie over de items die in dit artikel worden besproken:

Betrouwbaarheid in Azure