Distribuera en migreringsinfrastruktur

Den här artikeln visar hur det fiktiva företaget Contoso förbereder den lokala infrastrukturen för migrering, konfigurerar en Azure-infrastruktur inför migreringen och kör verksamheten i en hybridmiljö.

När du använder det här exemplet för att planera din egen infrastrukturmigrering bör du tänka på att den tillhandahållna exempelarkitekturen är specifik för Contoso. Granska organisationens affärsbehov, struktur och tekniska krav när du fattar viktiga infrastrukturbeslut om prenumerationsdesign eller nätverksarkitektur.

Huruvida du behöver alla delarna som beskrivs i den här artikeln beror på din strategi för migrering. Du kan till exempel behöva en mindre komplex nätverksstruktur om du bara skapar molnbaserade program i Azure.

Översikt

Innan Contoso kan migrera till Azure är det viktigt att förbereda en Azure-infrastruktur. I allmänhet behöver Contoso tänka på sex områden:

  • Steg 1: Azure-prenumerationer. Hur kommer IT-administratören att köpa Azure och interagera med Azure-plattformen och -tjänsterna?
  • Steg 2: Hybrididentitet. Hur kommer IT-administratören att hantera och kontrollera åtkomsten till lokala resurser och Azure-resurser efter migreringen? Hur utökar eller flyttar IT-personal identitetshantering till molnet?
  • Steg 3: Haveriberedskap och återhämtning. Hur säkerställer IT att dess program och infrastruktur är motståndskraftiga om avbrott och katastrofer inträffar?
  • Steg 4: Nätverk. Hur ska IT utforma en nätverksinfrastruktur och upprätta en anslutning mellan sitt lokala datacenter och Azure?
  • Steg 5: Säkerhet. Hur skyddar IT-hybriddistributionen?
  • Steg 6: Styrning. Hur kommer IT att hålla distributionen i linje med säkerhets- och styrningskraven?

Innan du börjar

Innan vi börjar granska infrastrukturen bör du läsa lite bakgrundsinformation om relevanta Azure-funktioner:

Lokal arkitektur

Här är ett diagram som visar den aktuella lokala Contoso-infrastrukturen.

Diagram över Contoso-arkitekturen.Bild 1: Lokal Contoso-arkitektur.

  • Contoso har ett huvuddatacenter i New York i östra USA.
  • Det finns ytterligare tre lokala avdelningar i USA.
  • Huvuddatacentret är anslutet till Internet med en fiberoptisk Metro Ethernet-anslutning (500 Mbit/s).
  • Varje gren är lokalt ansluten till Internet via företagsklassanslutningar, med IPsec VPN-tunnlar tillbaka till huvuddatacentret. Den här metoden gör att hela nätverket kan vara permanent anslutet och optimerar Internetanslutningen.
  • Huvuddatacentret är helt virtualiserat med VMware. Contoso har två ESXi 6.5-virtualiseringsvärdar som hanteras av vCenter Server 6.5.
  • Contoso använder Active Directory för identitetshantering och DNS-servrar (Domain Name System) i det interna nätverket.
  • Domänkontrollanterna i datacentret körs på virtuella VMware-datorer (VM). Domänkontrollanterna på de lokala avdelningarna körs på fysiska servrar.

Steg 1: Köp och prenumerera på Azure

Contoso måste bestämma hur man köper Azure, hur man hanterar prenumerationer och hur man licensierar tjänster och resurser.

Köpa Azure

Contoso registreras i en Enterprise-avtal. Det här avtalet innebär ett initialt ekonomiskt åtagande till Azure, vilket ger Contoso behörighet att få förmåner som flexibla faktureringsalternativ och optimerad prissättning.

Här är detaljerna:

  • Contoso uppskattade sina årliga kostnader för Azure. När Contoso undertecknade avtalet betalade det för det första året i sin helhet.
  • Contoso måste använda alla åtaganden innan året är slut eller förlora värdet för dessa dollar.
  • Om Contoso av någon anledning överskrider sitt åtagande och spenderar mer kommer Microsoft att fakturera för skillnaden.
  • Alla kostnader som uppstår utöver åtagandet kommer att ha samma pris som kostnaderna i Contosos avtal. Att överskrida åtagandet medför inga tilläggsavgifter.

Hantera prenumerationer

När contoso har betalat för Azure måste de bestämma hur de ska hantera Azure-prenumerationer. Eftersom Contoso har ett EA finns det ingen gräns för hur många Azure-prenumerationer det kan skapa. En Azure Enterprise-avtal-registrering definierar hur ett företag formar och använder Azure-tjänster och definierar en grundläggande styrningsstruktur.

Som ett första steg har Contoso definierat en struktur som kallas en företagsram för registreringen. Contoso använde vägledningen för Azure-företagsramverk för att förstå och utforma en autogenerering.

För tillfället har Contoso valt att använda en funktionell metod för att hantera prenumerationer:

  • Inom företaget används en enda IT-avdelning som styr Azure-budgeten. Detta är den enda gruppen med prenumerationer.
  • Contoso utökar den här modellen i framtiden, så att andra företagsgrupper kan ansluta som avdelningar i registreringshierarkin.
  • På IT-avdelningen har Contoso strukturerat två prenumerationer, Production och Development.
  • Om Contoso behöver fler prenumerationer i framtiden måste de också hantera åtkomst, principer och efterlevnad för dessa prenumerationer. Contoso gör det genom att introducera Azure-hanteringsgrupper som ytterligare ett lager ovanför prenumerationerna.

Diagram över företagshierarkin.Bild 2: Företagshierarki.

Granska licensieringen

När prenumerationerna har konfigurerats kan Contoso titta på Microsoft-licensiering. Licensieringsstrategin beror på de resurser som Contoso vill migrera till Azure och hur virtuella datorer och tjänster väljs och distribueras i Azure.

Azure Hybrid-förmån

För distribution av virtuella datorer i Azure innehåller standardbilder en licens som debiterar Contoso per minut för den programvara som används. Contoso har dock varit en långsiktig Microsoft-kund och har underhållit EAs och öppna licenser med Software Assurance.

Azure Hybrid-förmån är en kostnadseffektiv migreringsmetod. Det gör att Contoso kan spara på virtuella Azure-datorer och SQL Server arbetsbelastningar genom att konvertera eller återanvända Windows Server Datacenter- och Standard Edition-licenser som omfattas av Software Assurance. På så sätt kan Contoso betala en lägre basberäkningstakt för virtuella datorer och SQL Server. Mer information finns i Azure Hybrid-förmån.

License Mobility

Licensmobilitet via Software Assurance ger Microsofts volymlicensieringskunder som Contoso flexibiliteten att distribuera berättigade serverprogram med aktiv Software Assurance på Azure. Därmed behöver de inte köpa nya licenser. Utan tillkommande rörlighetsavgifter är det lätt att distribuera befintliga licenser i Azure. Mer information finns i License Mobility via Software Assurance på Azure.

Reserverade instanser för förutsägbara arbetsbelastningar

Förutsägbara arbetsbelastningar måste alltid vara tillgängliga med virtuella datorer som körs, till exempel verksamhetsspecifika program som ett SAP ERP-system. Oförutsägbara arbetsbelastningar är varierande, till exempel virtuella datorer som är på vid hög efterfrågan och av när efterfrågan är låg.

Diagram över Azure Reserved Virtual Machine Instances.Bild 3: Azure Reserved Virtual Machine Instances.

I utbyte mot att använda reserverade instanser för specifika VM-instanser som måste underhållas under lång tid kan Contoso få både rabatt och prioriterad kapacitet. Om du använder Azure Reserved Virtual Machine Instances tillsammans med Azure Hybrid-förmån kan contoso spara upp till 82 procent av den vanliga betala per användning-prissättningen (från och med april 2018).

Steg 2: Hantera hybrididentitet

Att ge och kontrollera användaråtkomst till Azure-resurser med identitets- och åtkomsthantering är ett viktigt steg för att samla en Azure-infrastruktur.

Contoso bestämmer sig för att utöka sin lokala Active Directory till molnet, i stället för att bygga ett nytt separat system i Azure. Eftersom Contoso inte använder Microsoft 365 ännu måste de etablera en Azure AD instans. Om Contoso använde Microsoft 365 skulle det redan ha en befintlig Azure AD klientorganisation och katalog, som den skulle kunna använda som sin primära Azure AD instans.

Läs mer om Microsoft 365-identitetsmodeller och Azure Active Directory. Du kan också lära dig hur du associerar eller lägger till en Azure-prenumeration till din Azure Active Directory-klientorganisation.

Skapa en Azure AD katalog

Contoso använder versionen Azure AD Free som ingår i en Azure-prenumeration. Contosos administratörer skapar en Azure AD katalog:

  1. I Azure Portal går de till Skapa en resursidentitet>>i Azure Active Directory.

  2. I Skapa katalog anger de ett namn för katalogen, ett första domännamn och den region där katalogen ska skapas.

    Skärmbild av val för att skapa en Azure AD katalog.

    Bild 4: Skapa en Azure AD katalog.

Anteckning

Katalogen som skapas har ett initialt domännamn i formatet domain-name.onmicrosoft.com. Namnet kan inte ändras eller tas bort. I stället måste administratörerna lägga till sitt registrerade domännamn i Azure AD.

Lägg till domännamn

För att kunna använda standarddomännamnet måste Contosos administratörer lägga till det som ett anpassat domännamn i Azure AD. Med det här alternativet kan de tilldela välbekanta användarnamn. En användare kan till exempel logga in med e-postadressen billg@contoso.com i stället för billg@contosomigration.onmicrosoft.com.

För att konfigurera ett anpassat domännamn lägger administratörerna till det i katalogen, lägger till en DNS-post och verifierar sedan namnet i Azure AD.

  1. I Anpassade domännamn>Lägg till anpassad domän lägger de till domänen.

  2. Om du vill använda en DNS-post i Azure måste de registrera den hos sin domänregistrator:

    • I listan med anpassade domännamn antecknar de DNS-informationen för namnet. Den använder en MX-post.
    • De behöver åtkomst till namnservern. De loggar in på domänen contoso.com och skapar en ny MX-post för DNS-posten som tillhandahålls av Azure AD, med hjälp av informationen som anges.
  3. När DNS-posterna har spridits väljer de Verifiera för att kontrollera det anpassade domännamnet i informationen för domänen.

    Skärmbild som visar val för Azure Active Directory D N S.

    Bild 5: Kontrollera domännamnet.

Konfigurera lokala och Azure-grupper och -användare

Nu när Azure AD-katalogen har upprättats måste Contosos administratörer lägga till anställda i lokal Active Directory grupper som ska synkroniseras till Azure AD. De bör använda lokala gruppnamn som motsvarar namnen på resursgrupperna i Azure. Detta gör det enklare att identifiera matchningar i synkroniseringsyfte.

Skapa resursgrupper i Azure

Resursgrupper i Azure samlar Azure-resurser. Med hjälp av ett resursgrupps-ID kan Azure utföra åtgärder på resurserna i gruppen.

En Azure-prenumeration kan ha flera resursgrupper. Det finns en resursgrupp i en enda prenumeration. Dessutom kan en enskild resursgrupp ha flera resurser. En resurs tillhör en enskild resursgrupp.

Contosos administratörer konfigurerar Azure-resursgrupper enligt följande tabell.

Resursgrupp Information
ContosoCobRG Den här gruppen innehåller alla resurser som rör affärskontinuitet. Den innehåller valv som Contoso använder för Azure Site Recovery-tjänsten och Azure Backup-tjänsten.

Den innehåller även resurser som används för migrering, inklusive Azure Migrate och Azure Database Migration Service.
ContosoDevRG Den här gruppen innehåller utvecklings-/testresurser.
ContosoFailoverRG Den här gruppen fungerar som en landningszon för redederiska resurser.
ContosoNetworkingRG Den här gruppen innehåller alla nätverksresurser.
ContosoRG Den här gruppen innehåller resurser som är relaterade till produktionsprogram och databaser.

De skapar resursgrupper på följande sätt:

  1. I Azure Portal >resursgrupper lägger de till en grupp.

  2. För varje grupp anger de ett namn, den prenumeration som gruppen tillhör och regionen.

  3. Resursgrupper visas i listan över resursgrupper.

    Skärmbild som visar en lista över resursgrupper

    Bild 6: Resursgrupper.

Skala resursgrupper

I framtiden kommer Contoso att lägga till andra resursgrupper efter behov. Den kan till exempel definiera en resursgrupp för varje program eller tjänst så att var och en kan hanteras och skyddas oberoende av varandra.

Skapa matchande säkerhetsgrupper lokalt

I den lokal Active Directory instansen konfigurerar Contosos administratörer säkerhetsgrupper med namn som matchar namnen på Azure-resursgrupperna.

Skärmbild som visar lokal Active Directory säkerhetsgrupper.Bild 7: Lokala Active Directory-säkerhetsgrupper.

Av praktiska skäl skapar de ytterligare en grupp som kommer att läggas till i alla andra grupper. Den här gruppen har rättigheter till alla resursgrupper i Azure. Ett begränsat antal globala administratörer läggs till i den här gruppen.

Synkronisera Active Directory

Contoso vill etablera en gemensam identitet för åtkomst till resurser lokalt och i molnet. Det gör du genom att integrera lokal Active Directory-instansen med Azure AD. Med den här modellen kan användare och organisationer dra nytta av en enda identitet för att få åtkomst till lokala program och molntjänster, till exempel Microsoft 365 eller tusentals andra webbplatser på Internet. Administratörer kan använda grupperna i Active Directory för att implementera rollbaserad åtkomstkontroll i Azure (Azure RBAC).

För att under lätta integreringen använder Contoso verktyget Azure AD Connect. När du installerar och konfigurerar verktyget på en domänkontrollant synkroniseras lokal Active Directory identiteter med Azure AD.

Hämta verktyget

  1. I Azure Portal går Contosos administratörer till Azure Active Directory>Azure AD Anslut och laddar ned den senaste versionen av verktyget till den server som de använder för synkronisering.

    Skärmbild som visar en länk för att ladda ned Azure A D Connect.

    Bild 8: Ladda ned Azure AD Connect.

  2. De startar AzureADConnect.msi installationen med hjälp av Expressinställningar. Det här är den vanligaste installationen och kan användas för en topologi med en skog med lösenordshashsynkronisering för autentisering.

    Skärmbild som visar guiden Azure AD Anslut.

    Bild 9: guiden Azure AD Anslut.

  3. I Anslut till Azure AD anger de autentiseringsuppgifterna för att ansluta till Azure AD (i formuläret admin@contoso.com eller admin@contoso.onmicrosoft.com).

    Skärmbild som visar sidan Anslut till Azure A D i Guiden Azure A D Connect.

    Bild 10: guiden Azure AD Anslut: Anslut till Azure AD.

  4. I Anslut till AD DS anger de autentiseringsuppgifter för den lokala katalogen (i formuläret CONTOSO\admin eller contoso.com\admin).

    Skärmbild som visar sidan Anslut till A D D S i Azure A D Connect-guiden.

    Bild 11: guiden Azure AD Anslut: Anslut till AD DS.

  5. När de är redo för konfigurering väljer de Starta synkroniseringsprocessen när konfigurationen är klar för att starta synkroniseringen omedelbart. Sedan är det dags att installera.

    . Tänk på följande:

    • Contoso har en direktanslutning till Azure. Om din lokal Active Directory instans finns bakom en proxy kan du läsa felsöka Azure AD anslutning.

    • Efter den första synkroniseringen visas lokala Active Directory-objekt i Azure AD-katalogen.

      Skärmbild som visar lokal Active Directory objekt som visas i Azure Active Directory.

      Bild 12: Lokala Active Directory-objekt som visas i Azure AD.

    • Contosos IT-team är representerat i varje grupp och baseras på dess roll.

      Skärmbild som visar gruppmedlemskap.

      Bild 13: Gruppmedlemskap.

Konfigurera Azure RBAC

Azure RBAC möjliggör detaljerad åtkomsthantering för Azure. Genom att använda Azure RBAC kan du endast bevilja den mängd åtkomst som användarna behöver för att utföra uppgifter. Du tilldelar lämplig Azure-roll till användare, grupper och program på omfångsnivå. Omfånget för en rolltilldelning kan vara en prenumeration, en resursgrupp eller en enskild resurs.

Contosos administratörer tilldelar sedan roller till de Active Directory-grupper som de synkroniserade lokalt.

  1. ControlCobRG I resursgruppen väljer de Åtkomstkontroll (IAM)>Lägg till rolltilldelning.

  2. I Lägg till rolltilldelningsrolldeltagare>> väljer ContosoCobRG de säkerhetsgruppen i listan. Gruppen visas sedan i listan med Valda medlemmar.

  3. De upprepar detta med samma behörigheter för de andra resursgrupperna (förutom ContosoAzureAdmins) genom att lägga till deltagarbehörigheter i säkerhetsgruppen som matchar resursgruppen.

  4. ContosoAzureAdmins För säkerhetsgruppen tilldelar de rollen Ägare.

    Skärmbild som visar lokala Azure Active Directory-grupper.

    Bild 14: Tilldela roller till säkerhetsgrupper.

Steg 3: Design för återhämtning

Konfigurera regioner

Azureresurser distribueras i regioner. Regioner är ordnade i geografiska områden. Krav på datahemvist, suveränitet, efterlevnad och återhämtning respekteras inom geografiska gränser.

En region består av en uppsättning datacenter. De är distribuerade inom en latensdefinierad perimeter och ansluts via ett dedikerat regionalt nätverk med låg latens.

Varje Azure-region är kopplad till en annan region av säkerhetsskäl. Läs om Azure-regioner och lär dig hur regioner paras ihop.

Contoso har valt att använda East US 2 (som finns i Virginia) som primär region och Central US (finns i Iowa) som sekundär region av följande skäl:

  • Contosos datacenter ligger i New York och Contoso tänkte på svarstiden till den närmaste datacentret.
  • East US 2 har alla tjänster och produkter som Contoso behöver. Det är inte alla Azure-regioner som har samma produkter och tjänster tillgängliga. Mer information finns i Azure-produkter efter region.
  • Central US är den länkade Azure-regionen för East US 2.

Eftersom Contoso funderar på att använda en hybridmiljö måste de tänka på hur de ska bygga in motståndskraft och en katastrofberedskapsplan i sin regionsdesign. Den enklaste strategin är en distribution i en region, som förlitar sig på Azure-plattformsfunktioner som feldomäner och regional parkoppling för motståndskraft. Det mest komplexa är en fullständig aktiv-aktiv-modell där molntjänster och databaser distribueras och betjänar användare från två regioner.

Contoso har valt något som ligger i mitten. Den distribuerar program och resurser i en primär region och behåller en fullständig kopia av infrastrukturen i den sekundära regionen. Med den strategin är kopian redo att fungera som en fullständig säkerhetskopia om ett fullständigt programhaveri eller ett regionalt fel inträffar.

Konfigurera tillgänglighet

Tillgänglighetsuppsättningar

Tillgänglighetsuppsättningar hjälper till att skydda program och data från ett lokalt maskinvaru- och nätverksstopp i ett datacenter. Tillgänglighetsuppsättningar distribuerar virtuella Azure-datorer över fysisk maskinvara i ett datacenter.

Feldomäner representerar underliggande maskinvara som delar en strömkälla och nätverksomkopplare inom datacentret. Virtuella datorer i en tillgänglighetsuppsättning distribueras över feldomäner för att minimera avbrott som orsakas av ett enskilt maskinvaru- eller nätverksfel.

En uppdateringsdomän representerar maskinvara som kan underhållas eller startas om samtidigt. Tillgänglighetsuppsättningar distribuerar också virtuella datorer över flera uppdateringsdomäner för att säkerställa att minst en instans alltid körs.

Contoso implementerar tillgänglighetsuppsättningar när arbetsbelastningar på virtuella datorer kräver hög tillgänglighet. Mer information finns i Hantera tillgängligheten för virtuella Windows-datorer i Azure.

Tillgänglighetszoner

Tillgänglighetszoner hjälper till att skydda program och data från fel som påverkar ett helt datacenter i en region.

Varje tillgänglighetszon representerar en unik fysisk plats i en Azure-region. Varje zon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk.

Det finns minst tre separata zoner i alla aktiverade regioner. Den fysiska avgränsningen av zonerna inom en region skyddar program och data mot datacenterfel.

Contoso använder Tillgänglighetszoner när program behöver större skalbarhet, tillgänglighet och motståndskraft. Mer information finns i Regioner och Tillgänglighetszoner i Azure.

Konfigurera säkerhetskopiering

Azure Backup

Du kan använda Azure Backup för att säkerhetskopiera och återställa virtuella Azure-diskar.

Azure Backup tillåter automatisk säkerhetskopiering av VM-diskavbildningar som lagras i Azure Storage. Säkerhetskopior är programkonsekventa för att säkerställa att säkerhetskopierade data är transaktionsmässigt konsekventa och att programmen startar efter återställningen.

Azure Backup stöder lokalt redundant lagring (LRS) för att replikera flera kopior av säkerhetskopierade data i ett datacenter om ett lokalt maskinvarufel inträffar. Om ett regionalt avbrott inträffar stöder Azure Backup även geo-redundant lagring (GRS), som replikerar säkerhetskopierade data till en sekundär länkad region.

Azure Backup krypterar data under överföring med hjälp av AES-256. Säkerhetskopierade vilande data krypteras via Azure Storage-kryptering.

Contoso använder Azure Backup med GRS på alla virtuella produktionsdatorer för att säkerställa att arbetsbelastningsdata säkerhetskopieras och snabbt kan återställas om ett avbrott inträffar. Mer information finns i En översikt över säkerhetskopiering av virtuella Azure-datorer.

Konfigurera haveriberedskap

Azure Site Recovery

Azure Site Recovery hjälper till att säkerställa affärskontinuitet genom att hålla affärsprogram och arbetsbelastningar igång under regionala avbrott.

Azure Site Recovery replikerar kontinuerligt virtuella Azure-datorer från en primär till en sekundär region, vilket säkerställer funktionella kopior på båda platserna. I händelse av ett avbrott i den primära regionen redundansväxlar programmet eller tjänsten till att använda de virtuella datorinstanser som replikeras i den sekundära regionen. Den här redundansväxlingen minimerar potentiella störningar. När åtgärderna återgår till det normala kan programmen eller tjänsterna växla tillbaka till virtuella datorer i den primära regionen.

Contoso implementerar Azure-Site Recovery för alla virtuella produktionsdatorer som används i verksamhetskritiska arbetsbelastningar, vilket säkerställer minimala störningar under ett avbrott i den primära regionen.

Steg 4: Utforma en nätverksinfrastruktur

Med den regionala designen på plats är Contoso redo att överväga en nätverksstrategi. Det måste tänka på hur det lokala datacentret och Azure ansluter och kommunicerar med varandra och hur nätverksinfrastrukturen ska utformas i Azure. Mer specifikt behöver Contoso:

  • Planera hybridnätverksanslutning. Fastställ hur det ska ansluta nätverk lokalt och i Azure.
  • Utforma en Azure-nätverksinfrastruktur. Bestämma sig för hur nätverk ska distribueras över regioner. Hur kommunicerar nätverk inom samma region och mellan regioner?
  • Utforma och konfigurera Azure-nätverk. Konfigurera Azure-nätverk och -undernät och bestäm vad som ska finnas i dem.

Planera hybridnätverksanslutning

Contoso övervägde flera arkitekturer för hybridnätverk mellan Azure och det lokala datacentret. Mer information finns i Välj en lösning för att ansluta ett lokalt nätverk till Azure.

Som en påminnelse består contosos lokala nätverksinfrastruktur för närvarande av datacentret i New York och lokala filialer på den östra halvan av USA. Alla platser har en business-class-anslutning till Internet. Var och en av grenarna ansluts sedan till datacentret via en IPsec VPN-tunnel via Internet.

Diagram över Contoso-nätverket.Bild 15: Contoso-nätverket.

Så här har Contoso valt att implementera hybridanslutningar:

  1. Konfigurera en ny VPN-anslutning från plats till plats mellan Contosos datacenter i New York och de två Azure-regionerna, East US 2 och Central US.
  2. Avdelningskontorstrafik som är bunden till virtuella nätverk i Azure dirigeras genom contosos huvuddatacenter.
  3. När Contoso skalar upp Azure-distributionen upprättas en Azure ExpressRoute-anslutning mellan datacentret och Azure-regionerna. När detta inträffar behåller Contoso VPN-plats-till-plats-anslutningen endast i redundanssyfte.

Endast VPN:

Skärmbild som visar Contoso VPN.Bild 16: Contoso VPN.

VPN och ExpressRoute:

Skärmbild som visar Contoso VPN och ExpressRoute.Bild 17: Contoso VPN och ExpressRoute.

Utforma en Azure-nätverksinfrastruktur

Contosos nätverkskonfiguration måste göra hybriddistributionen säker och skalbar. Contoso använder en långsiktig metod för detta och utformar virtuella nätverk så att de är motståndskraftiga och företagsklara. Mer information finns i Planera virtuella nätverk.

För att ansluta de två regionerna implementerar Contoso en nätverksmodell från hubb till hubb. I varje region använder Contoso en hubb- och ekermodell. Contoso använder Azures nätverkspeering för att ansluta nätverken och hubbarna.

Nätverkspeering

Peering för virtuella nätverk i Azure ansluter virtuella nätverk och hubbar. Global peering tillåter anslutningar mellan virtuella nätverk eller hubbar i olika regioner. Lokal peering ansluter virtuella nätverk i samma region.

Peering för virtuella nätverk ger flera fördelar:

  • Nätverkstrafiken mellan peer-kopplade virtuella nätverk är privat.
  • Trafiken mellan de virtuella nätverken finns i Microsoft-stamnätverket. Inget offentligt Internet, gatewayer eller kryptering krävs i kommunikationen mellan de virtuella nätverken.
  • Peering ger en standardanslutning med låg latens och hög bandbredd mellan resurser i olika virtuella nätverk.

Hub-to-hubb-modell mellan regioner

Contoso distribuerar en hubb i varje region. En hubb är ett virtuellt nätverk i Azure som fungerar som en central anslutningspunkt för ditt lokala nätverk. De virtuella hubbnätverken ansluter till varandra via global peering för virtuella nätverk, som ansluter virtuella nätverk mellan Azure-regioner. Hubben i varje region peerkopplas till dess partnerhubb i den andra regionen. Hubben är peer-kopplad till alla nätverk i regionen och kan ansluta till alla nätverksresurser.

Diagram över global peering.Bild 18: Global peering.

Hub-and-spoke-modell i en region

Inom varje region distribuerar Contoso virtuella nätverk för olika syften som ekernätverk från regionhubben. Virtuella nätverk i en region använder peering för att ansluta till sin hubb och till varandra.

Utforma hubbnätverket

Inom hub-and-spoke-modellen behövde Contoso tänka på hur trafik från det lokala datacentret och från Internet skulle dirigeras. Så här bestämde sig Contoso för att hantera routning för både hubbarna East US 2 och Central US :

  • Contoso utformar ett nätverk som tillåter trafik från Internet och från företagsnätverket med hjälp av ett VPN till Azure.
  • Nätverksarkitekturen har två gränser, en icke betrodd zon för klientdelen och en betrodd zon för serverdelen.
  • En brandvägg har ett nätverkskort i varje zon för att kontrollera åtkomsten till betrodda zoner.
  • Från Internet:
    • Internettrafiken påträffar en belastningsutjämnad offentlig IP-adress i perimeternätverket.
    • Den här trafiken dirigeras genom brandväggen och omfattas av brandväggsregler.
    • När nätverksåtkomstkontroller har implementerats vidarebefordras trafiken till en lämplig plats i den betrodda zonen.
    • Utgående trafik från det virtuella nätverket dirigeras till Internet via användardefinierade vägar. Trafiken tvingas genom brandväggen och kontrolleras i enlighet med Contosos principer.
  • Från Contosos datacenter:
    • Inkommande trafik via plats-till-plats-VPN eller ExpressRoute når den offentliga IP-adressen för Azure VPN-gatewayen.
    • Trafiken dirigeras genom brandväggen och brandväggsreglerna tillämpas.
    • När brandväggsregler har tillämpats vidarebefordras trafiken till en intern lastbalanserare (Standard SKU) i det betrodda interna zonundernätet.
    • Utgående trafik från det betrodda undernätet till det lokala datacentret via VPN dirigeras genom brandväggen. Regler tillämpas innan trafiken går över VPN-anslutningen från plats till plats.

Utforma och konfigurera Azure-nätverk

Med en nätverks- och routningstopologi på plats är Contoso redo att konfigurera Azure-nätverk och undernät:

  • Contoso implementerar ett privat nätverk av klass A i Azure (10.0.0.0/8). Detta fungerar på grund av lokalt. den har för närvarande ett privat adressutrymme klass B (172.160.0.0/16). Contoso kan vara säker på att det inte finns någon överlappning mellan adressintervall.
  • Contoso distribuerar virtuella nätverk i både de primära och sekundära regionerna.
  • Contoso använder en namngivningskonvention som innehåller prefixet VNET och regionförkortningen EUS2 eller CUS. Med den här standarden namnges VNET-HUB-EUS2 hubbnätverken East US 2 i regionen och VNET-HUB-CUS i Central US regionen.

Virtuella nätverk i East US 2

East US 2 är den primära region som Contoso använder för att distribuera resurser och tjänster. Så här utformar Contoso nätverk i den regionen:

  • Nav: Det virtuella hubbnätverket i East US 2 anses vara Contosos primära anslutning till det lokala datacentret.

  • Virtuella nätverk: De virtuella ekernätverken i East US 2 kan användas för att isolera arbetsbelastningar om det behövs. Förutom det virtuella hubbnätverket har Contoso två virtuella ekernätverk i East US 2:

    • VNET-DEV-EUS2. Det här virtuella nätverket ger utvecklings-/testteamet ett fullt fungerande nätverk för utvecklingsprojekt. Det kommer att fungera som att produktionstestområde. Det innebär att produktionsinfrastrukturen måste fungera här.

    • VNET-PROD-EUS2. Azure IaaS-produktionskomponenter kommer att finnas i det här nätverket.

    Varje virtuellt nätverk har ett eget unikt adressutrymme utan överlappning. Contoso har för avsikt att konfigurera routning utan att kräva NAT (Network Address Translation).

  • Undernät: Det kommer att finnas ett undernät i varje nätverk för varje programnivå. Varje undernät i produktionsnätverket har ett matchande undernät i det virtuella utvecklingsnätverket. Produktionsnätverket har ett undernät för domänkontrollanter.

I följande tabell sammanfattas virtuella nätverk i East US 2.

Virtuellt nätverk Intervall Peer
VNET-HUB-EUS2 10.240.0.0/20 VNET-HUB-CUS2, VNET-DEV-EUS2, VNET-PROD-EUS2
VNET-DEV-EUS2 10.245.16.0/20 VNET-HUB-EUS2
VNET-PROD-EUS2 10.245.32.0/20 VNET-HUB-EUS2, VNET-PROD-CUS

Diagram över hub-and-spoke-modellen i den primära regionen.Bild 19: En hubb- och ekermodell.

Undernät i East US 2 Hub nätverket (VNET-HUB-EUS2)

Undernät/zon CIDR Användbara IP-adresser
IB-UntrustZone 10.240.0.0/24 251
IB-TrustZone 10.240.1.0/24 251
OB-UntrustZone 10.240.2.0/24 251
OB-TrustZone 10.240.3.0/24 251
GatewaySubnet 10.240.10.0/24 251

Undernät i East US 2 utvecklingsnätverket (VNET-DEV-EUS2)

Utvecklingsteamet använder det virtuella utvecklingsnätverket som ett pilotområde för produktion. Det har tre undernät.

Undernät CIDR Adresser I undernät
DEV-FE-EUS2 10.245.16.0/22 1019 Klientdelar/virtuella datorer på webbnivå
DEV-APP-EUS2 10.245.20.0/22 1019 Virtuella datorer på programnivå
DEV-DB-EUS2 10.245.24.0/23 507 Virtuella databasdatorer

Undernät i East US 2 produktionsnätverket (VNET-PROD-EUS2)

Azure IaaS-komponenter finns i produktionsnätverket. Varje programnivå har ett eget undernät. Undernät matchar dem i utvecklingsnätverket, med tillägg av ett undernät för domänkontrollanter.

Undernät CIDR Adresser I undernät
PROD-FE-EUS2 10.245.32.0/22 1019 Klientdelar/virtuella datorer på webbnivå
PROD-APP-EUS2 10.245.36.0/22 1019 Virtuella datorer på programnivå
PROD-DB-EUS2 10.245.40.0/23 507 Virtuella databasdatorer
PROD-DC-EUS2 10.245.42.0/24 251 Virtuella datorer för domänkontrollant

Diagram över hubbnätverksarkitekturen.Bild 20: Hubbnätverksarkitektur.

Virtuella nätverk i Central US (sekundär region)

Central US är Contosos sekundära region. Så här kommer Contoso att utforma sina nätverk:

  • Nav: Det virtuella hubbnätverket i Central US anses vara den sekundära anslutningspunkten till det lokala datacentret. De virtuella ekernätverken i Central US kan användas för att isolera arbetsbelastningar vid behov, som hanteras separat från andra ekrar.

  • Virtuella nätverk: Contoso kommer att ha två virtuella nätverk i Central US:

    • VNET-PROD-CUS: Ett produktionsnätverk som kan betraktas som en sekundär hubb.
    • VNET-ASR-CUS: Ett virtuellt nätverk som fungerar som en plats där virtuella datorer skapas efter redundansväxling lokalt eller som en plats för virtuella Azure-datorer redundansväxla från den primära till den sekundära regionen. Det här nätverket liknar produktionsnätverken men utan några domänkontrollanter på det.

    Varje virtuellt nätverk i regionen har sitt eget adressutrymme utan överlappning. Contoso konfigurerar routning utan NAT.

  • Undernät: Undernäten kommer att utformas på ett liknande sätt som i East US 2.

I följande tabell sammanfattas virtuella nätverk i Central US.

Virtuellt nätverk Intervall Peer
VNET-HUB-CUS 10.250.0.0/20 VNET-HUB-EUS2, VNET-ASR-CUS, VNET-PROD-CUS
VNET-ASR-CUS 10.255.16.0/20 VNET-HUB-CUS, VNET-PROD-CUS
VNET-PROD-CUS 10.255.32.0/20 VNET-HUB-CUS, VNET-ASR-CUS, VNET-PROD-EUS2

Diagram över en nav-och-eker-modell i en länkad region.Bild 21: En hubb- och ekermodell i en länkad region.

Undernät i Central US hubbnätverket (VNET-HUB-CUS)

Undernät CIDR Användbara IP-adresser
IB-UntrustZone 10.250.0.0/24 251
IB-TrustZone 10.250.1.0/24 251
OB-UntrustZone 10.250.2.0/24 251
OB-TrustZone 10.250.3.0/24 251
GatewaySubnet 10.250.10.0/24 251

Undernät i Central US produktionsnätverket (VNET-PROD-CUS)

Parallellt med produktionsnätverket i den primära regionen (East US 2) finns det ett produktionsnätverk i den sekundära regionen (Central US).

Undernät CIDR Adresser I undernät
PROD-FE-CUS 10.255.32.0/22 1019 Klientdelar/virtuella datorer på webbnivå
PROD-APP-CUS 10.255.36.0/22 1019 Virtuella datorer på programnivå
PROD-DB-CUS 10.255.40.0/23 507 Virtuella databasdatorer
PROD-DC-CUS 10.255.42.0/24 251 Virtuella datorer för domänkontrollant

Undernät i redundans Central US -/återställningsnätverket (VNET-ASR-CUS)

Nätverket VNET-ASR-CUS används för redundans mellan regioner. Site Recovery kommer att användas för att replikera och redundansväxla virtuella Azure-datorer mellan regionerna. Det fungerar också som ett Contoso-datacenter till Azure-nätverket för skyddade arbetsbelastningar som finns kvar lokalt men redundansväxlar till Azure för haveriberedskap.

VNET-ASR-CUS är samma grundläggande undernät som det virtuella produktionsnätverket i East US 2 men utan behov av ett undernät för domänkontrollanten.

Undernät CIDR Adresser I undernät
ASR-FE-CUS 10.255.16.0/22 1019 Klientdelar/virtuella datorer på webbnivå
ASR-APP-CUS 10.255.20.0/22 1019 Virtuella datorer på programnivå
ASR-DB-CUS 10.255.24.0/23 507 Virtuella databasdatorer

Diagram över en hubbnätverksarkitektur.Bild 22: Hubbnätverksarkitektur.

Konfigurera peeranslutningar

Hubben i varje region peerkopplas till hubben i den andra regionen och till alla virtuella nätverk i hubbregionen. Med den här konfigurationen kan hubbar kommunicera och visa alla virtuella nätverk i en region. Observera att peering skapar en dubbelsidig anslutning. Den ena är från den initierande peern i det första virtuella nätverket och det andra är i det andra virtuella nätverket.

I en hybriddistribution måste trafik som passerar mellan peer-datorer vara synlig från VPN-anslutningen mellan det lokala datacentret och Azure. För att aktivera detta måste Contoso använda specifika inställningar för peer-kopplade anslutningar. För anslutningar från virtuella ekernätverk via hubben till det lokala datacentret måste Contoso tillåta att trafik vidarebefordras och korsa VPN-gatewayerna.

Domänkontrollant

För domänkontrollanterna i VNET-PROD-EUS2 nätverket vill Contoso att trafiken ska flöda både mellan EUS2 hubb-/produktionsnätverket och över VPN-anslutningen till den lokala miljön. För att göra detta måste Contosos administratörer tillåta följande:

  1. Konfigurationerna Tillåt vidarebefordrad trafik och Tillåt gatewaytrafik på peer-anslutningen. I vårt exempel är detta anslutningen från VNET-HUB-EUS2 till VNET-PROD-EUS2.

    Skärmbild som visar markerade kryssrutor för att tillåta vidarebefordrad trafik och tillåta gatewayöverföring.

    Bild 23: En peer-kopplad anslutning.

  2. Tillåt vidarebefordrad trafik och Använd fjärrgatewayer på andra sidan peering-anslutningen från VNET-PROD-EUS2 till VNET-HUB-EUS2.

    Skärmbild som visar de markerade kryssrutorna för att tillåta vidarebefordrad trafik och använda fjärrgatewayer.

    Bild 24: En peer-kopplad anslutning.

  3. Lokalt konfigurerar de en statisk väg som dirigerar den lokala trafiken att dirigera över VPN-tunneln till det virtuella nätverket. Konfigurationen slutförs på den gateway som tillhandahåller VPN-tunneln från Contoso till Azure. De använder routnings- och fjärråtkomsttjänsten (RRAS) för den statiska vägen.

    Skärmbild som visar val för den statiska vägen.

    Bild 25: En peer-kopplad anslutning.

Produktionsnätverk

Ett peernätverk med ekrar kan inte se andra peernätverk med ekrar i en annan region via en hubb. För att Contosos produktionsnätverk i båda regionerna ska kunna se varandra måste Contosos administratörer skapa en direkt peer-anslutning för VNET-PROD-EUS2 och VENT-PROD-CUS.

Diagram över hur du skapar en direkt peer-kopplad anslutning.Bild 26: Skapa en direkt peer-kopplad anslutning.

Konfigurera DNS

När du distribuerar resurser i virtuella nätverk har du ett par alternativ för domännamnsmatchning. Du kan använda namnmatchning som tillhandahålls av Azure eller tillhandahålla DNS-servrar för matchning. Vilken typ av namnmatchning du använder beror på hur dina resurser behöver kommunicera med varandra. Få mer information om Azure DNS-tjänsten.

Contosos administratörer har beslutat att tjänsten Azure DNS inte är lämplig för hybridmiljön. I stället använder de de lokala DNS-servrarna. Här är detaljerna:

  • Eftersom det här är ett hybridnätverk måste alla virtuella datorer lokalt och i Azure kunna matcha namn för att fungera korrekt. Det innebär att anpassade DNS-inställningar måste tillämpas på alla virtuella nätverk.

  • Contoso har för närvarande domänkontrollanter (DCs) distribuerade i Contosos datacenter och på avdelningskontoren. De primära DNS-servrarna är contosodc1 (172.16.0.10) och contosodc2 (172.16.0.1).

  • När de virtuella nätverken har distribuerats konfigureras de lokala domänkontrollanterna som DNS-servrar i nätverken.

  • Om en valfri anpassad DNS anges för det virtuella nätverket måste den virtuella IP-adressen 168.63.129.16 för de rekursiva matcharna i Azure läggas till i listan. För att göra detta konfigurerar Contoso DNS-serverinställningar i varje virtuellt nätverk. Till exempel skulle de anpassade DNS-inställningarna för VNET-HUB-EUS2 nätverket vara följande:

    Skärmbild som visar konfigurationen av anpassad DNS.

    Bild 27: En anpassad DNS.

Förutom de lokala domänkontrollanterna implementerar Contoso fyra domänkontrollanter som stöder Azure-nätverken (två för varje region):

Region DC Virtuellt nätverk Undernät IP-adress
East US 2 contosodc3 VNET-PROD-EUS2 PROD-DC-EUS2 10.245.42.4
East US 2 contosodc4 VNET-PROD-EUS2 PROD-DC-EUS2 10.245.42.5
Central US contosodc5 VNET-PROD-CUS PROD-DC-CUS 10.255.42.4
Central US contosodc6 VNET-PROD-CUS PROD-DC-CUS 10.255.42.4

När Contoso har distribuerat de lokala domänkontrollanterna måste de uppdatera DNS-inställningarna på nätverken för varje region för att inkludera de nya domänkontrollanterna i DNS-serverlistan.

Konfigurera domänkontrollanter i Azure

När Contosos administratörer har uppdaterat nätverksinställningarna är de redo att bygga ut domänkontrollanterna i Azure.

  1. I Azure Portal distribuerar de en ny virtuell Windows Server-dator till lämpligt virtuellt nätverk.

  2. De skapar tillgänglighetsuppsättningar på varje plats för den virtuella datorn. Tillgänglighetsuppsättningar säkerställer att Azure Fabric separerar de virtuella datorerna i olika infrastrukturer i Azure-regionen. Tillgänglighetsuppsättningar gör också att Contoso kan vara berättigad till serviceavtal på 99,95 procent (SLA) för virtuella datorer i Azure.

    Skärmbild som visar skapandet av en tillgänglighetsuppsättning.

    Bild 28: En tillgänglighetsuppsättning.

  3. När den virtuella datorn har distribuerats öppnas nätverksgränssnittet för den virtuella datorn. De anger den privata IP-adressen till statisk och anger en giltig adress.

    Skärmbild som visar den virtuella datorns nätverksgränssnittsanslutning.

    Bild 29: Ett virtuellt datornätverkskort.

  4. De kopplar en ny datadisk till den virtuella datorn. Den här disken innehåller Active Directory-databasen och sysvol-resursen.

    Disk storleken avgör antalet IOPS som stöds. Med tiden kan diskstorleken behöva öka i takt med att miljön växer.

    Anteckning

    Disken ska inte vara inställd på att läsa/skriva för värdcachelagring. Active Directory-databaser har inte stöd för detta.

    Skärmbild som visar en Active Directory-disk.

    Bild 30: En Active Directory-disk.

  5. När disken har lagts till ansluter de till den virtuella datorn via Fjärrskrivbordstjänster och öppnar Serverhanteraren.

  6. I Fil- och lagringstjänster kör de guiden Ny volym. De ser till att enheten tilldelas bokstaven F eller senare på den lokala virtuella datorn.

    Skärmbild som visar guiden Ny volym.

    Bild 31: Guiden Ny volym.

  7. I Serverhanteraren lägger de till rollen Active Directory Domain Services. Sedan konfigurerar de den virtuella datorn som en domänkontrollant.

    Skärmbild som visar hur du väljer en serverroll.

    Bild 32: Lägga till serverrollen.

  8. När den virtuella datorn har konfigurerats som en domänkontrollant och startats om öppnar de DNS-hanteraren och konfigurerar Azure DNS-matcharen som vidarebefordrare. Detta gör att domänkontrollanten kan vidarebefordra DNS-frågor som inte kan lösas i Azure DNS.

    Skärmbild som visar hur du konfigurerar DNS-matcharen som vidarebefordrare.

    Bild 33: Konfigurera Azure DNS-matcharen.

  9. De uppdaterar de anpassade DNS-inställningarna för varje virtuellt nätverk med lämplig domänkontrollant för den virtuella nätverksregionen. De inkluderar lokala domänkontrollanter i listan.

Konfigurera Active Directory

Active Directory är en viktig tjänst för ett nätverk och måste konfigureras korrekt. Contosos administratörer skapar Active Directory-platser för Contosos datacenter och för East US 2 regionerna och Central US .

  1. De skapar två nya platser (AZURE-EUS2 och AZURE-CUS) tillsammans med datacenterplatsen (contoso-datacenter).

  2. När webbplatserna har skapats skapar de undernät på platserna för att matcha de virtuella nätverken och datacentret.

    Skärmbild som visar skapandet av datacenterundernät.

    Bild 34: Datacenterundernät.

  3. De skapar två webbplatslänkar för att ansluta allt. Domänkontrollanterna bör sedan flyttas till deras plats.

    Skärmbild som visar hur du skapar datacenterlänkar.

    Bild 35: Datacenterlänkar.

  4. De bekräftar att Active Directory-replikeringstopologin är på plats.

    Skärmbild som visar datacentrets replikeringstopologi.

    Bild 36: Datacenterreplikering.

När allt är klart visas en lista över domänkontrollanter och platser i lokal Active Directory Administrationscenter.

Skärmbild som visar Active Directory Administrationscenter.Bild 37: Active Directory Administrationscenter.

Steg 5: Planera för styrning

Azure har en serie styrningskontroller för olika tjänster och delar av Azure-plattformen. Mer information finns i Styrningsalternativ för Azure.

När contoso konfigurerar identitets- och åtkomstkontroll har de redan börjat införa vissa aspekter av styrning och säkerhet. I stort sett måste den ta hänsyn till tre områden:

  • Princip: Azure Policy tillämpar och tillämpar regler och effekter på dina resurser, så att resurserna uppfyller företagets krav och serviceavtal.
  • Lås: Med Azure kan du låsa prenumerationer, resursgrupper och andra resurser så att de bara kan ändras av dem med behörigheter.
  • Taggar: Resurser kan kontrolleras, granskas och hanteras med taggar. Taggarna kopplar metadata till resurser som ger information om resurser eller ägare.

Konfigurera principer

Azure Policy-tjänsten utvärderar dina resurser genom att söka efter dem som inte är kompatibla med principdefinitioner. Du kan till exempel ha en princip som bara tillåter vissa typer av virtuella datorer eller kräver att resurser har en specifik tagg.

Principer innehåller en principdefinition. En principtilldelning anger i vilket omfång en princip ska tillämpas. Omfånget kan vara allt från en hanteringsgrupp till en resursgrupp. Lär dig hur du skapar och hanterar principer.

Contoso vill starta två principer. Den vill ha en princip för att säkerställa att resurser endast kan distribueras i East US 2 regionerna och Central US . Den vill också ha en princip för att begränsa vm-SKU:er till godkända SKU:er. Avsikten är att se till att dyra SKU:er för virtuella datorer inte används.

Begränsa resurser till regioner

Contoso använder den inbyggda principdefinitionen Tillåtna platser för att begränsa resursregioner.

  1. I Azure Portal väljer duAlla tjänster och söker efter Princip.

  2. Välj Tilldelningar>Tilldela princip.

  3. I principlistan väljer du Tillåtna platser.

  4. Ange Omfång till namnet på Azure-prenumerationen och välj de två regionerna i listan över tillåtna regioner.

    Skärmbild som visar tillåtna platser som definierats via principen.

    Bild 38: Tillåtna platser som definieras via principen.

  5. Som standard anges principen med Neka. Den här inställningen innebär att om någon startar en distribution i prenumerationen som inte finns i antingen East US 2 regionen eller Central US misslyckas distributionen. Så här händer det om någon i Contoso-prenumerationen försöker konfigurera en distribution i West US.

    Skärmbild som visar felet från en misslyckad princip.

    Bild 39: En misslyckad princip.

Tillåt specifika SKU:er för virtuella datorer

Contoso använder den inbyggda principdefinitionen Allow virtual machine SKUs för att begränsa vilka typer av virtuella datorer som kan skapas i prenumerationen.

Skärmbild som visar SKU-val.Bild 40: En princip-SKU.

Kontrollera efterlevnad av principer

Principerna träder i kraft omedelbart och Contoso kan kontrollera att de tillämpas på resurserna. Välj länken Efterlevnad i Azure Portal. Instrumentpanelen för efterlevnad visas. Du kan öka detaljnivån för mer information.

Skärmbild som visar instrumentpanelen för efterlevnad.Bild 41: Principefterlevnad.

Konfigurera lås

Contoso har länge använt ITIL-ramverket för att hantera sina system. En av de viktigaste aspekterna av ramverket är ändringskontroll och Contoso vill se till att ändrings kontrollen implementeras i Azure-distributionen.

Contoso låser resurser. Alla produktions- eller redundanskomponenter måste finnas i en resursgrupp som har ett skrivskyddat lås. Det innebär att behöriga användare måste ta bort låset för att kunna ändra eller ta bort produktionsobjekt. Icke-produktionsresursgrupper har CanNotDelete lås. Det innebär att behöriga användare kan läsa eller ändra en resurs men inte ta bort den.

Konfigurera taggning

För att kunna spåra resurser när de läggs till blir det allt viktigare för Contoso att associera resurser med en lämplig avdelning, kund och miljö. Förutom att tillhandahålla information om resurser och ägare gör taggar att Contoso kan aggregera och gruppera resurser och använda dessa data i återbetalningssyfte.

Contoso måste visualisera sina Azure-tillgångar på ett sätt som passar för verksamheten, till exempel efter roll eller avdelning. Observera att resurserna inte behöver ligga i samma resursgrupp för att ha samma tagg. Contoso skapar en taggtaxonomi så att alla använder samma taggar.

Taggnamn Värde
CostCenter 12345: Det måste vara ett giltigt kostnadsställe från SAP.
BusinessUnit Namnet på affärsenheten (från SAP). Matchar CostCenter.
ApplicationTeam Email alias för teamet som äger supporten för programmet.
CatalogName Namnet på programmet eller SharedServices, enligt tjänstkatalogen som resursen stöder.
ServiceManager E-postalias för ITIL Service Manager för resursen.
COBPriority Prioritet som har angetts av företaget för affärskontinuitet och haveriberedskap. Värden från 1 till 5.
ENV DEV, STGoch PROD är tillåtna värden som representerar utveckling, mellanlagring och produktion.

Ett exempel:

Skärmbild som visar Azure-taggar.Bild 42: Azure-taggar.

När du har skapat taggen går Contoso tillbaka och skapar nya principdefinitioner och tilldelningar för att framtvinga användningen av de taggar som krävs i organisationen.

Steg 6: Överväg säkerhet

Säkerhet är viktigt i molnet och Azure tillhandahåller en mängd olika säkerhetsverktyg och -funktioner. De hjälper dig att skapa säkra lösningar på den säkra Azure-plattformen. Mer information om Azure-säkerhet finns i Lita på ditt moln .

Det finns några aspekter för Contoso att tänka på:

  • Microsoft Defender för molnet ger enhetlig säkerhetshantering och Microsoft Defender for Identity över arbetsbelastningar i hybridmoln. Använd den för att tillämpa säkerhetsprinciper för dina arbetsbelastningar, begränsa din exponering för hot och identifiera och svara på attacker.
  • En nätverkssäkerhetsgrupp (NSG) filtrerar nätverkstrafik baserat på en lista med säkerhetsregler som tillåter eller nekar nätverkstrafik till resurser som är anslutna till virtuella nätverk i Azure.
  • Azure Disk Encryption är en funktion som hjälper dig att kryptera dina virtuella Windows- och Linux IaaS-diskar.

Arbeta med Microsoft Defender för molnet

Contoso letar efter en snabb överblick över säkerhetsstatusen för sitt nya hybridmoln, och mer specifikt dess Azure-arbetsbelastningar. Därför har Contoso beslutat att implementera Microsoft Defender för molnet från och med följande funktioner:

  • Centraliserad principhantering
  • Kontinuerlig utvärdering
  • Användbara rekommendationer

Centraliserad principhantering

Med centraliserad principhantering kan Contoso säkerställa efterlevnad med säkerhetskrav genom att hantera principer centralt för hela miljön. Den kan enkelt och snabbt implementera en princip som gäller för alla dess Azure-resurser.

Skärmbild som visar val för en säkerhetsprincip.Bild 43: En säkerhetsprincip.

Utvärdera säkerhet

Contoso kommer att dra nytta av den kontinuerliga säkerhetsutvärderingen som övervakar säkerheten för datorer, nätverk, lagring, data och program för att identifiera potentiella säkerhetsproblem.

Defender för molnet analyserar säkerhetstillståndet för Contosos beräknings-, infrastruktur- och dataresurser. Den analyserar också säkerhetstillståndet för Azure-appar och -tjänster. Med kontinuerlig utvärdering kan Contosos driftsteam identifiera potentiella säkerhetsproblem, till exempel system som saknar säkerhetsuppdateringar eller exponerade nätverksportar.

Contoso vill se till att alla virtuella datorer är skyddade. Defender för molnet hjälper dig med detta. Den verifierar den virtuella datorns hälsa och ger prioriterade och åtgärdsinriktade rekommendationer för att åtgärda säkerhetsproblem innan de utnyttjas.

Skärmbild som visar övervakning av virtuella datorer.Bild 44: Övervakning.

Arbeta med nätverkssäkerhetsgrupper

Contoso kan begränsa nätverkstrafiken till resurser i ett virtuellt nätverk med hjälp av nätverkssäkerhetsgrupper.

En nätverkssäkerhetsgrupp innehåller en lista över säkerhetsregler som tillåter eller nekar inkommande eller utgående nätverkstrafik baserat på käll- eller mål-IP-adress, port och protokoll. När regler tillämpas för ett undernät tillämpas de för alla resurser i undernätet. Förutom nätverksgränssnitt omfattar detta även instanser av Azure-tjänster som distribuerats i undernätet.

Med programsäkerhetsgrupper (ASG:er) kan du konfigurera nätverkssäkerhet som en naturlig förlängning av en programstruktur. Du kan sedan gruppera virtuella datorer och definiera nätverkssäkerhetsprinciper baserat på dessa grupper.

Contoso kan använda ASG:er för att återanvända säkerhetsprincipen i stor skala utan manuellt underhåll av explicita IP-adresser. Plattformen hanterar komplexiteten hos explicita IP-adresser och flera regeluppsättningar, så att organisationen kan fokusera på affärslogik. Contoso kan ange en ASG som källa och mål i en säkerhetsregel. När en säkerhetsprincip har definierats kan Contoso skapa virtuella datorer och tilldela de virtuella datorernas nätverkskort till en grupp.

Contoso implementerar en blandning av nätverkssäkerhetsgrupper och programsäkerhetsgrupper. Contoso oroar sig för hanteringen av nätverkssäkerhetsgrupper. Det är också oroat över överanvändningen av NSG:er och den extra komplexiteten för driftspersonalen. Det här är vad Contoso planerar att göra:

  • All trafik till och från alla undernät (nord/syd) omfattas av en NSG-regel, förutom gatewayundernäten i hubbnätverken.
  • Alla brandväggar eller domänkontrollanter skyddas av både undernäts-NSG:er och nätverkskorts-NSG:er.
  • Alla produktionsprogram kommer att ha tillämpade programsäkerhetsgrupper.

Contoso har skapat en modell för hur den här säkerhetskonfigurationen ska se ut för sina program.

Diagram över Contosos säkerhetsmodell.Bild 45: Säkerhetsmodell.

Nätverkssäkerhetsgrupperna som är associerade med programsäkerhetsgrupperna kommer att konfigureras med minst behörighet så att endast tillåtna paket kan flöda från en del av nätverket till målet.

Åtgärd Namn Källa Mål Port
Allow AllowInternetToFE VNET-HUB-EUS1/IB-TrustZone APP1-FE 80, 443
Allow AllowWebToApp APP1-FE APP1-APP 80, 443
Allow AllowAppToDB APP1-APP APP1-DB 1433
Deny DenyAllInbound Valfri Valfri Valfri

Kryptera data

Azure Disk Encryption integreras med Azure Key Vault för att styra och hantera diskkrypteringsnycklar och hemligheter för en prenumeration. Det säkerställer att alla data på virtuella datordiskar krypteras i vila i Azure Storage.

Contoso har avgjort att vissa virtuella datorer behöver kryptering. Contoso tillämpar kryptering på virtuella datorer med kundinformation, konfidentiella eller personliga data.

Slutsats

I den här artikeln konfigurerar Contoso en Azure-infrastruktur och -princip för Azure-prenumeration, hybrididentitet, haveriberedskap, nätverk, styrning och säkerhet.

Alla steg som tas här krävs inte för en molnmigrering. I det här fallet planerade Contoso en nätverksinfrastruktur som kan hantera alla typer av migreringar samtidigt som den är säker, elastisk och skalbar.

Nästa steg

När contoso har konfigurerat sin Azure-infrastruktur är det dags att börja migrera arbetsbelastningar till molnet. Se översikten över migreringsmönster och exempel för ett urval av scenarier som använder den här exempelinfrastrukturen som migreringsmål.