Delen via

Virtuele machines beveiligen die zijn geïmplementeerd in Azure Stack Hub

  • Artikel

Gebruik dit artikel als richtlijn bij het ontwikkelen van een strategie voor gegevensbescherming en herstel na noodgevallen voor door de gebruiker geïmplementeerde virtuele IaaS-machines (VM's) die zijn geïmplementeerd op Azure Stack Hub.

Als u zich wilt beschermen tegen gegevensverlies en uitgebreide downtime, implementeert u een plan voor back-upherstel of herstel na noodgevallen voor gebruikerstoepassingen en hun gegevens. Elke toepassing moet worden geëvalueerd als onderdeel van de uitgebreide strategie voor bedrijfscontinuïteit en herstel na noodgevallen (BC/DR) van uw organisatie.

Overwegingen voor het beveiligen van IaaS-VM's

Rollen en verantwoordelijkheden

Zorg er eerst voor dat er een duidelijk begrip is van de rollen en verantwoordelijkheden die worden toegewezen aan toepassingseigenaren en -operators in de context van beveiliging en herstel.

Gebruikers zijn verantwoordelijk voor het beveiligen van VM's. Operators zijn verantwoordelijk voor het online en in orde houden van Azure Stack Hub. Azure Stack Hub bevat een service die back-ups maakt van interne servicegegevens van infrastructuurservices en bevat geen gebruikersgegevens, waaronder door de gebruiker gemaakte VM's, opslagaccounts met gebruikers- of toepassingsgegevens of gebruikersdatabases.

Toepassingseigenaar/-architect Azure Stack Hub-operator
- De toepassingsarchitectuur afstemmen op de principes van cloudontwerp.
- Traditionele toepassingen naar behoefte moderniseren om ze voor te bereiden op de cloudomgeving.
- Definieer acceptabele RTO en RPO voor de toepassing.
- Identificeer toepassingsresources en gegevensopslagplaatsen die moeten worden beveiligd.
- Implementeer een methode voor gegevens- en toepassingsherstel die het beste aansluit bij de toepassingsarchitectuur en de vereisten van de klant.		 - Identificeer de doelstellingen voor bedrijfscontinuïteit en herstel na noodgevallen van de organisatie.
- Implementeer voldoende Azure Stack Hub-exemplaren om te voldoen aan de BC/DR-doelstellingen van de organisatie.
- Ontwerp en beheer de infrastructuur voor toepassings-/gegevensbeveiliging.
- Beheerde oplossingen of selfservicetoegang bieden tot beveiligingsservices.
- Werk samen met eigenaren/architecten van toepassingen om inzicht te hebben in het ontwerp van toepassingen en beveiligingsstrategieën aan te bevelen.
- Back-up van infrastructuur inschakelen voor serviceherstel en cloudherstel.

Combinaties van bron en doel

Gebruikers die zich moeten beschermen tegen een storing in een datacenter of site, kunnen een andere Azure Stack Hub of Azure gebruiken om hoge beschikbaarheid of snel herstel te bieden. Met de primaire en secundaire locatie kunnen gebruikers toepassingen implementeren in een actieve/actieve of actief/passieve configuratie in twee omgevingen. Voor minder kritieke workloads kunnen gebruikers capaciteit op de secundaire locatie gebruiken om toepassingen op aanvraag te herstellen vanuit een back-up.

Een of meer Azure Stack Hub-clouds kunnen worden geïmplementeerd in een datacenter. Als u een catastrofe wilt overleven, zorgt de implementatie van ten minste één Azure Stack Hub-cloud in een ander datacenter ervoor dat u een failover van workloads kunt uitvoeren en ongeplande downtime kunt minimaliseren. Als u slechts één Azure Stack Hub hebt, kunt u overwegen de openbare Azure-cloud te gebruiken als uw herstelcloud. De bepaling waar uw toepassing kan worden uitgevoerd, wordt bepaald door overheidsvoorschriften, bedrijfsbeleid en strenge latentievereisten. U hebt de flexibiliteit om de juiste herstellocatie per toepassing te bepalen. U kunt bijvoorbeeld toepassingen in het ene abonnement hebben die back-ups maken van gegevens naar een ander datacenter en in een ander abonnement, waarbij gegevens worden gerepliceerd naar de openbare Azure-cloud.

Doelstellingen voor toepassingsherstel

Toepassingseigenaren zijn primair verantwoordelijk voor het bepalen van de hoeveelheid downtime en gegevensverlies die de toepassing en de organisatie kunnen tolereren. Door acceptabele downtime en acceptabel gegevensverlies te kwantificeren, kunt u een herstelplan maken waarmee de impact van een noodgeval op uw organisatie wordt geminimaliseerd. Houd voor elke toepassing rekening met het volgende:

  • Beoogde hersteltijd (RTO)
    RTO is de maximaal acceptabele tijd dat een app na een incident niet beschikbaar kan zijn. Een RTO van 90 minuten betekent bijvoorbeeld dat u de app binnen 90 minuten na het begin van een noodgeval moet kunnen herstellen naar een actieve status. Als u een lage RTO hebt, kunt u een tweede implementatie continu op stand-by laten staan om u te beschermen tegen een regionale storing.
  • Recovery Point Objective (RPO)
    RPO is de maximale duur dat gegevensverlies acceptabel is tijdens een noodgeval. Als u bijvoorbeeld gegevens opslaat in één database, waarvan elk uur een back-up wordt gemaakt en die geen replicatie naar andere databases heeft, kunt u maximaal een uur aan gegevens kwijtraken.

Een andere metrische waarde is Gemiddelde tijd om te herstellen (MTTR). Dit is de gemiddelde tijd die nodig is om de toepassing na een fout te herstellen. MTTR is een empirische waarde voor een systeem. Als MTTR de RTO overschrijdt, veroorzaakt een storing in het systeem een onaanvaardbare bedrijfsonderbreking, omdat het niet mogelijk is om het systeem binnen de gedefinieerde RTO te herstellen.

Beveiligingsopties

Back-up terugzetten

Als u een back-up maakt van uw toepassingen en gegevenssets, kunt u snel herstellen van downtime als gevolg van beschadigde gegevens, onbedoelde verwijderingen of noodgevallen. Voor IaaS VM-toepassingen kunt u een in-guest agent gebruiken om toepassingsgegevens, configuratie van het besturingssysteem en gegevens die zijn opgeslagen op volumes te beveiligen.

Back-up maken met behulp van in-guest agent

Het maken van een back-up van een VM met behulp van een gastbesturingssysteemagent omvat meestal het vastleggen van de configuratie van het besturingssysteem, bestanden/mappen, schijven, binaire toepassingsbestanden of toepassingsgegevens.

Als u een toepassing wilt herstellen vanuit een agent, moet u de VM handmatig opnieuw maken, het besturingssysteem installeren en de gastagent installeren. Op dat moment kunnen gegevens worden hersteld in het gastbesturingssystemen of rechtstreeks naar de toepassing.

Back-up maken met behulp van schijfmomentopname voor gestopte VM's

Back-upproducten kunnen iaaS-VM-configuraties en schijven beveiligen die zijn gekoppeld aan een gestopte VM. Gebruik back-upproducten die zijn geïntegreerd met Azure Stack Hub-API's om VM-configuratie vast te leggen en schijfmomentopnamen te maken. Als geplande downtime voor de toepassing mogelijk is, controleert u of de VM de status Gestopt heeft voordat u de back-upwerkstroom start.

Back-up maken met behulp van schijfmomentopname voor het uitvoeren van VM's

Belangrijk

Het gebruik van schijfmomentopnamen vanuit de portal wordt momenteel niet ondersteund voor vm's met een actieve status. Het maken van een momentopname van een schijf die is gekoppeld aan een actieve VM, kan de prestaties verslechteren of de beschikbaarheid van het besturingssysteem of de toepassing in de VM beïnvloeden. U wordt aangeraden een oplossing van een back-upleverancier te gebruiken die is geïntegreerd met de mogelijkheid voor incrementele momentopnamen van Storage RP, of een in-guest agent om de toepassing te beveiligen als geplande downtime geen optie is.

VM's in een schaalset of beschikbaarheidsset

Vm's in een schaalset of beschikbaarheidsgroep die als tijdelijke resources worden beschouwd, mogen niet worden geback-upt op VM-niveau, met name als de toepassing staatloos is. Voor stateful toepassingen die zijn geïmplementeerd in een schaalset of beschikbaarheidsset, kunt u overwegen de toepassingsgegevens te beveiligen (bijvoorbeeld een database of volume in een opslaggroep).

Replicatie/handmatige failover

Voor toepassingen waarvoor minimaal gegevensverlies of minimale downtime is vereist, kan gegevensreplicatie worden ingeschakeld op gast- of toepassingsniveau om gegevens naar een andere locatie te repliceren. Sommige toepassingen, zoals Microsoft SQL Server, ondersteunen systeemeigen replicatie. Als de toepassing replicatie niet ondersteunt, kunt u software in het gastbesturingssystemen gebruiken om schijven te repliceren, of een partneroplossing die als een agent in het gastbesturingssystemen wordt geïnstalleerd.

Met deze benadering wordt de toepassing geïmplementeerd in de ene cloud en worden de gegevens on-premises naar de andere cloud of naar Azure gerepliceerd. Wanneer een failover wordt geactiveerd, moet de toepassing in het doel worden gestart en gekoppeld aan de gerepliceerde gegevens voordat deze serviceaanvragen kan starten.

Hoge beschikbaarheid/automatische failover

Voor stateless toepassingen die slechts enkele seconden of minuten downtime kunnen verdragen, kunt u een configuratie met hoge beschikbaarheid overwegen. Toepassingen met hoge beschikbaarheid zijn ontworpen om te worden geïmplementeerd op meerdere locaties in een actieve/actieve topologie waar alle exemplaren aanvragen kunnen verwerken. Voor lokale hardwarefouten implementeert de Azure Stack Hub-infrastructuur hoge beschikbaarheid in het fysieke netwerk met behulp van twee top-of-rack-switches. Voor fouten op rekenniveau gebruikt Azure Stack Hub meerdere knooppunten in een schaaleenheid en wordt automatisch een failover uitgevoerd voor een VM. Op VM-niveau kunt u schaalsets of VM's in beschikbaarheidsset gebruiken om ervoor te zorgen dat knooppuntfouten uw toepassing niet uitschakelen. Dezelfde toepassing moet worden geïmplementeerd op een secundaire locatie in dezelfde configuratie. Als u de toepassing actief/actief wilt maken, kan een load balancer of DNS worden gebruikt om aanvragen om te leiden naar alle beschikbare exemplaren.

Geen herstel

Sommige apps in uw omgeving hebben mogelijk geen bescherming nodig tegen ongeplande downtime of gegevensverlies. Vm's die worden gebruikt voor ontwikkeling en testen hoeven bijvoorbeeld doorgaans niet te worden hersteld. Het is uw beslissing om het zonder beveiliging voor een toepassing of gegevensset te doen.

Belangrijke overwegingen voor uw Azure Stack Hub-implementatie:

Aanbeveling Opmerkingen
Back-up maken van VM's/vm's herstellen naar een extern back-updoel dat al is geïmplementeerd in uw datacenter Aanbevolen Profiteer van bestaande back-upinfrastructuur en operationele vaardigheden. Zorg ervoor dat u de grootte van de back-upinfrastructuur zodanig wijzigt dat deze gereed is om de extra VM-exemplaren te beveiligen. Zorg ervoor dat de back-upinfrastructuur zich niet dicht bij de bron bevindt. U kunt VM's herstellen naar de bron-Azure Stack Hub, naar een secundair Azure Stack Hub-exemplaar of Naar Azure.
Back-up maken van VM's/vm's herstellen naar een extern back-updoel dat is toegewezen aan Azure Stack Hub Aanbevolen U kunt een nieuwe back-upinfrastructuur aanschaffen of een toegewezen back-upinfrastructuur inrichten voor Azure Stack Hub. Zorg ervoor dat de back-upinfrastructuur zich niet dicht bij de bron bevindt. U kunt VM's herstellen naar de bron-Azure Stack Hub, naar een secundair Azure Stack Hub-exemplaar of Naar Azure.
Back-up maken van VM's/rechtstreeks herstellen naar azure of een vertrouwde serviceprovider Aanbevolen Zolang u kunt voldoen aan uw vereisten voor gegevensprivacy en regelgeving, kunt u uw back-ups opslaan in azure of een vertrouwde serviceprovider. Idealiter voert de serviceprovider ook Azure Stack Hub uit, zodat u consistentie krijgt in de operationele ervaring wanneer u herstelt.
VM's repliceren/failover uitvoeren naar een afzonderlijk Azure Stack Hub-exemplaar Aanbevolen In het geval van failover moet u een tweede Azure Stack Hub-cloud volledig operationeel hebben, zodat u uitgebreide uitvaltijd van apps kunt voorkomen.
VM's rechtstreeks repliceren/failover uitvoeren naar Azure of een vertrouwde serviceprovider Aanbevolen Zolang u aan uw gegevensprivacy en wettelijke vereisten kunt voldoen, kunt u uw gegevens repliceren naar wereldwijde Azure of een vertrouwde serviceprovider. Idealiter voert de serviceprovider ook Azure Stack Hub uit, zodat u na een failover consistentie krijgt in de operationele ervaring.
Implementeer een back-updoel op dezelfde Azure Stack Hub die ook als host fungeert voor alle toepassingen die worden beveiligd door hetzelfde back-updoel. Zelfstandig doel: niet aanbevolen
Doel waarmee back-upgegevens extern worden gerepliceerd: aanbevolen		 Als u ervoor kiest om een back-upapparaat te implementeren in Azure Stack Hub (voor het optimaliseren van operationeel herstel), moet u ervoor zorgen dat alle gegevens continu worden gekopieerd naar een externe back-uplocatie.
Een fysiek back-upapparaat implementeren in hetzelfde rack waarop de Azure Stack Hub-oplossing is geïnstalleerd Niet ondersteund Op dit moment kunt u geen andere apparaten verbinden met de bovenkant van rackswitches die geen deel uitmaken van de oorspronkelijke oplossing.

Overwegingen voor een herstelde IaaS-VM

U moet enkele wijzigingen aanbrengen in uw VM nadat u de machine hebt hersteld vanuit een back-up. Deze omvatten:

  • MAC-adres
    De virtuele netwerkadapter krijgt een nieuw MAC-adres. Er is geen methode om het oorspronkelijke MAC-adres te behouden.
  • IP-adres
    Als uw VM intern een statisch IP-adres heeft ingesteld, kan het interne IP-adres op de virtuele netwerkadapter zo worden ingesteld dat deze overeenkomt met het origineel. Mogelijk moet u overwegen of het VNET een S2S-VPN heeft naar een externe omgeving waarin het IP-adres mogelijk in gebruik is.
  • Overbodige artefacten
    Als er een back-up van de VM is gemaakt op een ander platform, zoals VMware vSphere, moet u enkele extra stappen volgen om overbodige artefacten uit de bron op te schonen.

Volgende stappen

Dit artikel bevat algemene richtlijnen voor het beveiligen van gebruikers-VM's die zijn geïmplementeerd in Azure Stack Hub. Zie voor informatie over het gebruik van Azure-services om gebruikers-VM's te beveiligen: