Isolering i det offentliga Azure-molnet

Med Azure kan du köra program och virtuella datorer (VM) på delad fysisk infrastruktur. En av de främsta ekonomiska motiven för att köra program i en molnmiljö är möjligheten att fördela kostnaden för delade resurser mellan flera kunder. Den här metoden med flera innehavare förbättrar effektiviteten genom att multiplexera resurser mellan olika kunder till låga kostnader. Tyvärr medför det också risken att dela fysiska servrar och andra infrastrukturresurser för att köra känsliga program och virtuella datorer som kan tillhöra en godtycklig och potentiellt skadlig användare.

Den här artikeln beskriver hur Azure tillhandahåller isolering mot både skadliga och icke-skadliga användare och fungerar som en guide för att utforma molnlösningar genom att erbjuda olika isoleringsalternativ för arkitekter.

Isolering på klientnivå

En av de främsta fördelarna med molnbaserad databehandling är begreppet delad, gemensam infrastruktur för flera kunder samtidigt, vilket leder till stordriftsfördelar. Det här konceptet kallas för flera innehavare. Microsoft arbetar kontinuerligt för att säkerställa att arkitekturen för flera klientorganisationer i Microsoft Cloud Azure stöder säkerhet, konfidentialitet, sekretess, integritet och tillgänglighetsstandarder.

På en arbetsplats i molnet kan en klientorganisation definieras som en klient eller organisation som äger och hanterar en specifik instans av molntjänsten. Med identitetsplattformen som tillhandahålls av Microsoft Azure är en klientorganisation helt enkelt en dedikerad instans av Microsoft Entra-ID som din organisation tar emot och äger när den registrerar sig för en Microsoft-molntjänst.

Varje Microsoft Entra-katalog är distinkt och separat från andra Microsoft Entra-kataloger. Precis som en företagskontorsbyggnad är en säker tillgång som endast är specifik för din organisation, har en Microsoft Entra-katalog också utformats för att vara en säker tillgång för endast din organisation. Microsoft Entra-arkitekturen isolerar kunddata och identitetsinformation från co-mingling. Det innebär att användare och administratörer av en Microsoft Entra-katalog inte oavsiktligt eller skadligt kan komma åt data i en annan katalog.

Azure Tenancy

Azure-innehav (Azure-prenumeration) refererar till en "kund/fakturering"-relation och en unik klientorganisation i Microsoft Entra-ID. Isolering på klientnivå i Microsoft Azure uppnås med hjälp av Microsoft Entra-ID och rollbaserad åtkomstkontroll i Azure som erbjuds av den. Varje Azure-prenumeration är associerad med en Microsoft Entra-katalog.

Användare, grupper och program från den katalogen kan hantera resurser i Azure-prenumerationen. Du kan tilldela dessa åtkomsträttigheter med hjälp av Azure-portalen, Azure-kommandoradsverktyg och Azure Management-API:er. En Microsoft Entra-klientorganisation är logiskt isolerad med hjälp av säkerhetsgränser så att ingen kund kan komma åt eller kompromettera medklienter, antingen skadligt eller oavsiktligt. Microsoft Entra-ID körs på "bare metal"-servrar isolerade i ett separat nätverkssegment, där paketfiltrering på värdnivå och Windows-brandväggen blockerar oönskade anslutningar och trafik.

• Åtkomst till data i Microsoft Entra-ID kräver användarautentisering via en säkerhetstokentjänst (STS). Information om användarens existens, aktiverade tillstånd och roll används av auktoriseringssystemet för att avgöra om den begärda åtkomsten till målklientorganisationen är auktoriserad för den här användaren i den här sessionen.

• Klienter är diskreta containrar och det finns ingen relation mellan dessa.

• Ingen åtkomst mellan klientorganisationer om inte klientadministratören beviljar den via federation eller etablering av användarkonton från andra klienter.

• Fysisk åtkomst till servrar som utgör Microsoft Entra-tjänsten och direkt åtkomst till Microsoft Entra-ID:ts backend-system är begränsad.

• Microsoft Entra-användare har ingen åtkomst till fysiska tillgångar eller platser, och därför är det inte möjligt för dem att kringgå de logiska Azure RBAC-principkontroller som anges nedan.

För diagnostik- och underhållsbehov krävs och används en driftsmodell som använder ett just-in-time-behörighetshöjningssystem. Microsoft Entra Privileged Identity Management (PIM) introducerar begreppet berättigad administratör. Berättigade administratörer bör vara användare som behöver privilegierad åtkomst då och då, men inte varje dag. Rollen är inaktiv tills användaren behöver åtkomst. Därefter slutför användaren en aktiveringsprocess och blir aktiv administratör under en förinställd tidsperiod.

Microsoft Entra ID är värd för varje klientorganisation i sin egen skyddade container, med principer och behörigheter till och i containern som endast ägs och hanteras av klientorganisationen.

Begreppet klientcontainrar är djupt inrotat i katalogtjänsten i alla lager, från portaler hela vägen till beständig lagring.

Även om metadata från flera Microsoft Entra-klientorganisationer lagras på samma fysiska disk finns det ingen annan relation mellan containrarna än vad som definieras av katalogtjänsten, vilket i sin tur styrs av klientadministratören.

Rollbaserad åtkomstkontroll i Azure (Azure RBAC)

Rollbaserad åtkomstkontroll i Azure (Azure RBAC) hjälper dig att dela olika komponenter som är tillgängliga i en Azure-prenumeration genom att tillhandahålla detaljerad åtkomsthantering för Azure. Med Azure RBAC kan du separera uppgifter inom din organisation och bevilja åtkomst baserat på vad användarna behöver för att utföra sina jobb. I stället för att ge alla obegränsade behörigheter i Azure-prenumerationer eller resurser kan du bara tillåta vissa åtgärder.

Azure RBAC har tre grundläggande roller som gäller för alla resurstyper:

• Ägaren har fullständig åtkomst till alla resurser, inklusive rätten att delegera åtkomst till andra.

• Deltagare kan skapa och hantera alla typer av Azure-resurser men kan inte bevilja åtkomst till andra.

• Läsaren kan visa befintliga Azure-resurser.

Resten av Azure-rollerna i Azure tillåter hantering av specifika Azure-resurser. Till exempel tillåter rollen Virtuell datordeltagare att en användare skapar och hanterar virtuella datorer. Den ger dem inte åtkomst till Azure Virtual Network eller det undernät som den virtuella datorn ansluter till.

Inbyggda Roller i Azure visar en lista över de roller som är tillgängliga i Azure. Den anger de åtgärder och omfång som varje inbyggd roll beviljar användarna. Om du vill definiera dina egna roller för ännu mer kontroll kan du läsa om hur du skapar anpassade roller i Azure RBAC.

Några andra funktioner för Microsoft Entra-ID är:

• Med Microsoft Entra ID kan SSO till SaaS-program, oavsett var de finns. Vissa program är federerade med Microsoft Entra-ID och andra använder enkel inloggning med lösenord. Federerade program kan också stödja användaretablering och lösenordsvalv.

• Åtkomst till data i Azure Storage styrs via autentisering. Varje lagringskonto har en primärnyckel (lagringskontonyckel eller SAK) och en sekundär hemlig nyckel (signaturen för delad åtkomst eller SAS).

• Microsoft Entra ID tillhandahåller identitet som en tjänst via federation med hjälp av Active Directory usluge za ujedinjavanje, synkronisering och replikering med lokala kataloger.

• Microsoft Entra multifaktorautentisering kräver att användarna verifierar inloggningar med hjälp av en mobilapp, ett telefonsamtal eller ett sms. Det kan användas med Microsoft Entra-ID för att skydda lokala resurser med Multi-Factor Authentication Server, och även med anpassade program och kataloger med hjälp av SDK.

• Med Microsoft Entra Domain Services kan du ansluta virtuella Azure-datorer till en Active Directory-domän utan att distribuera domänkontrollanter. Du kan logga in på dessa virtuella datorer med företagets Active Directory-autentiseringsuppgifter och administrera domänanslutna virtuella datorer med hjälp av grupprincip för att framtvinga säkerhetsbaslinjer på alla dina virtuella Azure-datorer.

• Azure Active Directory B2C tillhandahåller en tjänst för global identitetshantering med hög tillgänglighet för konsumentinriktade program som skalar till hundratals miljoner identiteter. Den kan integreras över mobila plattformar och webbaserade plattformar. Dina konsumenter kan logga in på alla dina program via anpassningsbara upplevelser med hjälp av sina befintliga sociala konton eller genom att skapa autentiseringsuppgifter.

Isolering från Microsoft-administratörer och borttagning av data

Microsoft vidtar kraftfulla åtgärder för att skydda dina data från olämplig åtkomst eller användning av obehöriga personer. Dessa operativa processer och kontroller backas upp av onlinetjänstvillkoren, som erbjuder avtalsåtaganden som styr åtkomsten till dina data.

• Microsofts tekniker har inte standardåtkomst till dina data i molnet. I stället beviljas de åtkomst, under ledningstillsyn, endast när det behövs. Åtkomsten kontrolleras och loggas noggrant och återkallas när den inte längre behövs.
• Microsoft kan anlita andra företag för att tillhandahålla begränsade tjänster för dess räkning. Underleverantörer kan endast komma åt kunddata för att leverera de tjänster som vi har anlitat dem för att tillhandahålla, och de är förbjudna att använda dem för något annat ändamål. Dessutom är de avtalsmässigt bundna att upprätthålla konfidentialiteten för våra kunders information.

Företagstjänster med granskade certifieringar som ISO/IEC 27001 verifieras regelbundet av Microsoft och ackrediterade revisionsföretag, som utför stickprovsgranskningar för att bekräfta den åtkomsten, endast för legitima affärsändamål. Du kan alltid komma åt dina egna kunddata när som helst och av vilken anledning som helst.

Om du tar bort data tar Microsoft Azure bort data, inklusive cachelagrade kopior eller säkerhetskopior. För tjänster inom omfånget sker borttagningen inom 90 dagar efter kvarhållningsperiodens slut. (Tjänster inom omfång definieras i avsnittet Databehandlingsvillkor i vår Villkor för onlinetjänster.)

Om en diskenhet som används för lagring drabbas av ett maskinvarufel raderas eller förstörs den på ett säkert sätt innan Microsoft returnerar den till tillverkaren för ersättning eller reparation. Data på enheten skrivs över för att säkerställa att data inte kan återställas på något sätt.

Beräkningsisolering

Microsoft Azure tillhandahåller olika molnbaserade databehandlingstjänster som innehåller ett brett urval av beräkningsinstanser och tjänster som kan skalas upp och ned automatiskt för att uppfylla behoven i ditt program eller företag. Dessa beräkningsinstanser och tjänster erbjuder isolering på flera nivåer för att skydda data utan att offra flexibiliteten i konfigurationen som kunderna kräver.

Storlekar på isolerade virtuella datorer

Azure Compute ger VM-storlekar som isoleras till en specifik maskinvarutyp och dedikerad till en enda kund. De isolerade storlekarna är aktiva och fungerar på specifik maskinvarugenerering och kommer att bli inaktuella när maskinvarugenerationen dras tillbaka eller om den nya maskinvarugenerationen är tillgänglig.

Storlekar på isolerade virtuella datorer passar bäst för arbetsbelastningar som kräver en hög grad av isolering från andra kunders arbetsbelastningar. Detta krävs ibland för att uppfylla efterlevnads- och regelkrav. Att använda en isolerad storlek garanterar att den virtuella datorn är den enda som körs på den specifika serverinstansen.

Eftersom de virtuella datorerna med isolerad storlek är stora kan kunderna dessutom välja att dela upp resurserna för dessa virtuella datorer i andra hand med hjälp av Azure-stöd för kapslade virtuella datorer.

De aktuella erbjudandena för isolerade virtuella datorer är:

• Standard_E80ids_v4
• Standard_E80is_v4
• Standard_E104i_v5
• Standard_E104is_v5
• Standard_E104id_v5
• Standard_E104ids_v5
• Standard_M192is_v2
• Standard_M192ims_v2
• Standard_M192ids_v2
• Standard_M192idms_v2
• Standard_F72s_v2
• Standard_M128ms

Kommentar

Isolerade VM-storlekar har en begränsad livslängd på grund av maskinvaruutfasning.

Utfasning av isolerade VM-storlekar

Storlekarna för isolerade virtuella datorer har en livslängd som begränsas av maskinvaran. Azure utfärdar påminnelser 12 månader före det officiella utfasningsdatumet för storlekarna och tillhandahåller ett uppdaterat isolerat erbjudande för ditt övervägande. Följande storlekar har aviserats.

Storlek	Isoleringsdatum för tillbakadragning
Standard_DS15_v2	15 maj 2021
Standard_D15_v2	15 maj 2021
Standard_G5	15 februari 2022
Standard_GS5	15 februari 2022
Standard_E64i_v3	15 februari 2022
Standard_E64is_v3	15 februari 2022
Standard_M192is_v2	den 31 mars 2027
Standard_M192ims_v2	den 31 mars 2027
Standard_M192ids_v2	den 31 mars 2027
Standard_M192idms_v2	den 31 mars 2027

Vanliga frågor

F: Kommer storleken att dras tillbaka eller bara dess "isoleringsfunktion"?

S: Alla storlekar som publiceras som isolerade men inte har "i" i namnet, isoleringsfunktionen i VM-storlekarna dras tillbaka om inte annat kommuniceras. Storlekar med "i" i namnet kommer att vara inaktuella.

F: Finns det en stilleståndstid när min virtuella dator hamnar på en icke-isolated maskinvara?

S: För VM-storlekar, där endast isoleringen är inaktuell men inte storleken, behövs ingen åtgärd och det blir ingen stilleståndstid. Om isolering krävs innehåller meddelandet tvärtom den rekommenderade ersättningsstorleken. Om du väljer ersättningsstorleken måste kunderna ändra storlek på sina virtuella datorer.

F: Finns det något kostnadsdeltat för att flytta till en icke-isolated virtuell dator?

S: Nej

F: När kommer de andra isolerade storlekarna att gå i pension?

S: Vi ger påminnelser 12 månader före den officiella utfasningen av den isolerade storleken. Vårt senaste meddelande omfattar isoleringsfunktionens tillbakadragning av Standard_G5, Standard_GS5, Standard_E64i_v3 och Standard_E64i_v3.

F: Jag är en Azure Service Fabric-kund som förlitar sig på silver- eller guldhållbarhetsnivåer. Påverkar den här ändringen mig?

S: Nej. Garantierna från Service Fabrics hållbarhetsnivåer fortsätter att fungera även efter den här ändringen. Om du behöver fysisk maskinvaruisolering av andra skäl kan du fortfarande behöva utföra någon av de åtgärder som beskrivs ovan.

F: Vilka är milstolparna för D15_v2 eller DS15_v2 isoleringsavgång?

A:

Datum	Åtgärd
15 maj 20201	Meddelande om isolering av D/DS15_v2
15 maj 2021	D/DS15_v2 isoleringsgarantin har tagits bort

¹ Befintliga kunder som använder dessa storlekar får ett e-postmeddelande med detaljerade instruktioner om nästa steg.

F: Vilka är milstolparna för G5, Gs5, E64i_v3 och E64is_v3 isoleringsavgång?

A:

Datum	Åtgärd
15 feb 20211	Meddelande om G5/GS5/E64i_v3/E64is_v3 isolering
28 feb 2022	G5/GS5/E64i_v3/E64is_v3 isoleringsgaranti borttagen

¹ Befintliga kunder som använder dessa storlekar får ett e-postmeddelande med detaljerade instruktioner om nästa steg.

Nästa steg

Kunder kan också välja att ytterligare dela upp resurserna för dessa isolerade virtuella datorer genom att använda Azure-stöd för kapslade virtuella datorer.

Dedikerade värdar

Utöver de isolerade värdar som beskrivs i föregående avsnitt erbjuder Azure även dedikerade värdar. Dedikerade värdar i Azure är en tjänst som tillhandahåller fysiska servrar som kan vara värdar för en eller flera virtuella datorer och som är dedikerade till en enda Azure-prenumeration. Dedikerade värdar tillhandahåller maskinvaruisolering på fysisk servernivå. Inga andra virtuella datorer kommer att placeras på dina värdar. Dedikerade värdar distribueras i samma datacenter och delar samma nätverk och underliggande lagringsinfrastruktur som andra, icke-isolerade värdar. Mer information finns i den detaljerade översikten över dedikerade Azure-värdar.

Hyper-V och rotoperativsystemisolering mellan virtuella rotdatorer och virtuella gästdatorer

Azures beräkningsplattform baseras på datorvirtualisering, vilket innebär att all kundkod körs på en virtuell Hyper-V-dator. På varje Azure-nod (eller nätverksslutpunkt) finns det en Hypervisor som körs direkt över maskinvaran och delar upp en nod i ett variabelt antal virtuella gästdatorer (VM).

Varje nod har också en särskild virtuell rotdator som kör värdoperativsystemet. En kritisk gräns är isoleringen av den virtuella rotdatorn från de virtuella gästdatorerna och de virtuella gästdatorerna från varandra, som hanteras av hypervisor-programmet och rotoperativsystemet. Hypervisor-/rot-OS-parkopplingen utnyttjar Microsofts årtionden av säkerhetsupplevelse för operativsystem, och nyare inlärning från Microsofts Hyper-V, för att ge stark isolering av virtuella gästdatorer.

Azure-plattformen använder en virtualiserad miljö. Användarinstanser fungerar som fristående virtuella datorer som inte har åtkomst till en fysisk värdserver.

Azure-hypervisor-programmet fungerar som en mikrokärna och skickar alla begäranden om maskinvaruåtkomst från virtuella gästdatorer till värden för bearbetning med hjälp av ett gränssnitt för delat minne som kallas VM Bus. Detta förhindrar att användare erhåller rååtkomsten läs/skriv/kör till systemet och minskar risken med att dela systemresurser.

Avancerad vm-placeringsalgoritm och skydd mot sidokanalattacker

Alla attacker mellan virtuella datorer omfattar två steg: att placera en angripare kontrollerad virtuell dator på samma värd som en av de virtuella datorerna för offer och sedan bryta isoleringsgränsen för att antingen stjäla känslig information om offret eller påverka dess prestanda för girighet eller vandalism. Microsoft Azure ger skydd i båda stegen med hjälp av en avancerad algoritm för vm-placering och skydd mot alla kända sidokanalattacker, inklusive bullriga virtuella granndatorer.

Azure Fabric-kontrollanten

Azure Fabric Controller ansvarar för att allokera infrastrukturresurser till klientarbetsbelastningar och hanterar enkelriktad kommunikation från värden till virtuella datorer. Vm-placeringsalgoritmen för Azure Fabric-kontrollanten är mycket avancerad och nästan omöjlig att förutsäga som fysisk värdnivå.

Azure-hypervisor-programmet framtvingar minnes- och processseparation mellan virtuella datorer och dirigerar nätverkstrafik på ett säkert sätt till gästoperativsystemsklientorganisationer. Detta eliminerar risken för och sidokanalattacker på VM-nivå.

I Azure är den virtuella rotdatorn speciell: den kör ett härdat operativsystem som kallas rotoperativsystemet som är värd för en infrastrukturagent (FA). Certifikatutfärdare används i sin tur för att hantera gästagenter (GA) i gästoperativsystem på virtuella kunddatorer. Certifikatutfärdare hanterar också lagringsnoder.

Samlingen av Azure-hypervisor-, rot-OS/FA och virtuella kunddatorer/GA:er består av en beräkningsnod. Certifikatutfärdare hanteras av en infrastrukturkontrollant (FC), som finns utanför beräknings- och lagringsnoder (beräknings- och lagringskluster hanteras av separata domänkontrollanter). Om en kund uppdaterar programmets konfigurationsfil medan den körs kommunicerar FC med fa, som sedan kontaktar GA:er, som meddelar programmet om konfigurationsändringen. I händelse av ett maskinvarufel hittar FC automatiskt tillgänglig maskinvara och startar om den virtuella datorn där.

Kommunikation från en infrastrukturkontrollant till en agent är enkelriktad. Agenten implementerar en SSL-skyddad tjänst som endast svarar på begäranden från kontrollanten. Den kan inte initiera anslutningar till kontrollanten eller andra privilegierade interna noder. FC behandlar alla svar som om de inte var betrodda.

Isoleringen sträcker sig från den virtuella rotdatorn från virtuella gästdatorer och de virtuella gästdatorerna från varandra. Beräkningsnoder är också isolerade från lagringsnoder för ökat skydd.

Hypervisor-programmet och värdoperativsystemet tillhandahåller nätverkspaket – filter för att säkerställa att ej betrodda virtuella datorer inte kan generera falsk trafik eller ta emot trafik som inte är adresserad till dem, dirigera trafik till skyddade infrastrukturslutpunkter eller skicka/ta emot olämplig sändningstrafik.

Ytterligare regler som konfigurerats av infrastrukturkontrollantagenten för att isolera virtuella datorer

Som standard blockeras all trafik när en virtuell dator skapas och sedan konfigurerar infrastrukturkontrollantagenten paketfiltret för att lägga till regler och undantag för att tillåta auktoriserad trafik.

Det finns två typer av regler som är programmerade:

• Datorkonfiguration eller infrastrukturregler: Som standard blockeras all kommunikation. Det finns undantag för att tillåta att en virtuell dator skickar och tar emot DHCP- och DNS-trafik. Virtuella datorer kan också skicka trafik till det "offentliga" Internet och skicka trafik till andra virtuella datorer inom samma virtuella Azure-nätverk och os-aktiveringsservern. Listan över tillåtna utgående mål för virtuella datorer innehåller inte Azure-routerundernät, Azure-hantering och andra Microsoft-egenskaper.
• Rollkonfigurationsfil: Detta definierar de inkommande åtkomstkontrollistorna (ACL:er) baserat på klientorganisationens tjänstmodell.

VLAN-isolering

Det finns tre VLAN i varje kluster:

• Huvud-VLAN – kopplar samman ej betrodda kundnoder
• FC VLAN – innehåller betrodda domänkontrollanter och stödsystem
• Enhetens VLAN – innehåller betrodda nätverk och andra infrastrukturenheter

Kommunikation tillåts från FC VLAN till huvud-VLAN, men kan inte initieras från huvud-VLAN till FC VLAN. Kommunikationen blockeras också från huvud-VLAN till enhetens VLAN. Detta säkerställer att även om en nod som kör kundkod komprometteras kan den inte attackera noder på antingen FC- eller enhets-VLAN.

Lagringsisolering

Logisk isolering mellan beräkning och lagring

Som en del av den grundläggande designen separerar Microsoft Azure VM-baserad beräkning från lagring. Den här separationen gör att beräkningen och lagringen kan skalas separat, vilket gör det enklare att tillhandahålla flera innehavare och isolering.

Därför körs Azure Storage på separat maskinvara utan nätverksanslutning till Azure Compute förutom logiskt. Det innebär att diskutrymmet inte allokeras för hela kapaciteten när en virtuell disk skapas. I stället skapas en tabell som mappar adresser på den virtuella disken till områden på den fysiska disken och tabellen är ursprungligen tom. Första gången en kund skriver data på den virtuella disken allokeras utrymme på den fysiska disken och en pekare till den placeras i tabellen.

Isolering med åtkomstkontroll för lagring

Åtkomstkontroll i Azure Storage har en enkel åtkomstkontrollmodell. Varje Azure-prenumeration kan skapa ett eller flera lagringskonton. Varje lagringskonto har en enda hemlig nyckel som används för att styra åtkomsten till alla data i lagringskontot.

Åtkomst till Azure Storage-data (inklusive tabeller) kan styras via en SAS-token (signatur för delad åtkomst) som ger begränsad åtkomst. SAS skapas via en frågemall (URL), signerad med SAK (Lagringskontonyckel). Den signerade URL:en kan ges till en annan process (dvs. delegerad), som sedan kan fylla i information om frågan och göra begäran om lagringstjänsten. Med en SAS kan du bevilja tidsbaserad åtkomst till klienter utan att avslöja lagringskontots hemliga nyckel.

SAS innebär att vi kan bevilja en klient begränsad behörighet, till objekt i vårt lagringskonto under en angiven tidsperiod och med en angiven uppsättning behörigheter. Vi kan bevilja dessa begränsade behörigheter utan att behöva dela dina kontoåtkomstnycklar.

Lagringsisolering på IP-nivå

Du kan upprätta brandväggar och definiera ett IP-adressintervall för dina betrodda klienter. Med ett IP-adressintervall kan endast klienter som har en IP-adress inom det definierade intervallet ansluta till Azure Storage.

IP-lagringsdata kan skyddas från obehöriga användare via en nätverksmekanism som används för att allokera en dedikerad eller dedikerad tunnel av trafik till IP-lagring.

Kryptering

Azure erbjuder följande typer av kryptering för att skydda data:

• Kryptering vid överföring
• Kryptering i vila

Kryptering vid överföring

Kryptering under överföring är en mekanism för att skydda data när de överförs över nätverk. Med Azure Storage kan du skydda data med hjälp av:

• Kryptering på transportnivå, till exempel HTTPS när du överför data till eller från Azure Storage.
• Trådkryptering, till exempel SMB 3.0-kryptering för Azure-filresurser.
• Kryptering på klientsidan för att kryptera data innan de överförs till lagringen och dekryptera data när de har överförts från lagringen.

Kryptering i vila

För många organisationer är vilande datakryptering ett obligatoriskt steg mot datasekretess, efterlevnad och datasuveränitet. Det finns tre Azure-funktioner som tillhandahåller kryptering av data som är "i vila":

• Med kryptering av lagringstjänst kan du begära att lagringstjänsten automatiskt krypterar data när du skriver dem till Azure Storage.
• Kryptering på klientsidan innehåller också funktionen för kryptering i vila.
• Azure Disk Encryption för virtuella Linux-datorer och Azure Disk Encryption för virtuella Windows-datorer.

Mer information finns i Översikt över krypteringsalternativ för hanterade diskar.

Azure Disk Encryption

Azure Disk Encryption för virtuella Linux-datorer och Azure Disk Encryption för virtuella Windows-datorer hjälper dig att hantera organisationens säkerhet och efterlevnadskrav genom att kryptera dina virtuella datordiskar (inklusive start- och datadiskar) med nycklar och principer som du styr i Azure Key Vault.

Diskkrypteringslösningen för Windows baseras på Microsoft BitLocker-diskkryptering och Linux-lösningen baseras på dm-crypt.

Lösningen stöder följande scenarier för virtuella IaaS-datorer när de är aktiverade i Microsoft Azure:

• Integrering med Azure Key Vault
• Virtuella datorer på standardnivå: A, D, DS, G, GS och så vidare, seriens virtuella IaaS-datorer
• Aktivera kryptering på virtuella Windows- och Linux IaaS-datorer
• Inaktivera kryptering på operativsystem och dataenheter för virtuella Windows IaaS-datorer
• Inaktivera kryptering på dataenheter för virtuella Linux IaaS-datorer
• Aktivera kryptering på virtuella IaaS-datorer som kör Windows-klientoperativsystemet
• Aktivera kryptering på volymer med monteringssökvägar
• Aktivera kryptering på virtuella Linux-datorer som har konfigurerats med diskrensning (RAID) med hjälp av mdadm
• Aktivera kryptering på virtuella Linux-datorer med hjälp av LVM (Logical Volume Manager) för datadiskar
• Aktivera kryptering på virtuella Windows-datorer som konfigureras med hjälp av lagringsutrymmen
• Alla offentliga Azure-regioner stöds

Lösningen stöder inte följande scenarier, funktioner och teknik i versionen:

• Virtuella IaaS-datorer på basic-nivå
• Inaktivera kryptering på en OS-enhet för virtuella Linux IaaS-datorer
• Virtuella IaaS-datorer som skapas med hjälp av den klassiska metoden för att skapa virtuella datorer
• Integrering med din lokala nyckelhanteringstjänst
• Azure Files (delat filsystem), NFS (Network File System), dynamiska volymer och virtuella Windows-datorer som är konfigurerade med programvarubaserade RAID-system

SQL Database-isolering

SQL Database är en relationsdatabastjänst i Microsoft Cloud som är baserad på den marknadsledande Microsoft SQL Server-motorn och som kan hantera verksamhetskritiska arbetsbelastningar. SQL Database erbjuder förutsägbar dataisolering på kontonivå, geografi/region baserat på nätverk – allt med nästan noll administration.

SQL Database-programmodell

Microsoft SQL Database är en molnbaserad relationsdatabastjänst som bygger på SQL Server-tekniker. Det ger en högtillgänglig, skalbar databastjänst med flera klientorganisationer som hanteras av Microsoft i molnet.

Ur ett programperspektiv tillhandahåller SQL Database följande hierarki: Varje nivå har en-till-många-inneslutning av nivåerna nedan.

Kontot och prenumerationen är Microsoft Azure-plattformskoncept för att associera fakturering och hantering.

Logiska SQL-servrar och databaser är SQL Database-specifika begrepp och hanteras med hjälp av SQL Database, tillhandahållna OData- och TSQL-gränssnitt eller via Azure-portalen.

Servrar i SQL Database är inte fysiska instanser eller vm-instanser, i stället är de samlingar av databaser, delningshanterings- och säkerhetsprinciper som lagras i en så kallad "logisk huvuddatabas".

Logiska huvuddatabaser är:

• SQL-inloggningar som används för att ansluta till servern
• Brandväggsregler

Fakturerings- och användningsrelaterad information för databaser från samma server garanteras inte finnas på samma fysiska instans i klustret, i stället måste program ange måldatabasnamnet när de ansluter.

Ur ett kundperspektiv skapas en server i en geo-grafisk region medan den faktiska skapandet av servern sker i ett av klustren i regionen.

Isolering via nätverkstopologi

När en server skapas och dess DNS-namn registreras pekar DNS-namnet på den så kallade "Gateway VIP"-adressen i det specifika datacenter där servern placerades.

Bakom VIP-adressen (virtuell IP-adress) har vi en samling tillståndslösa gatewaytjänster. I allmänhet engagerar sig gatewayer när det behövs samordning mellan flera datakällor (huvuddatabas, användardatabas osv.). Gatewaytjänster implementerar följande:

• TDS-anslutningsproxy. Detta inkluderar att hitta användardatabasen i serverdelsklustret, implementera inloggningssekvensen och sedan vidarebefordra TDS-paketen till serverdelen och tillbaka.
• Databashantering. Detta omfattar implementering av en samling arbetsflöden för att utföra create/ALTER/DROP-databasåtgärder. Databasåtgärderna kan anropas genom att antingen sniffa TDS-paket eller explicita OData-API:er.
• CREATE/ALTER/DROP login/user operations
• Serverhanteringsåtgärder via OData API

Nivån bakom gatewayerna kallas "backend". Det är här alla data lagras på ett sätt med hög tillgänglighet. Varje del av data sägs tillhöra en "partition" eller "redundansenhet", var och en av dem har minst tre repliker. Repliker lagras och replikeras av SQL Server-motorn och hanteras av ett redundanssystem som ofta kallas "infrastrukturresurser".

I allmänhet kommunicerar backend-systemet inte utgående till andra system som en säkerhetsåtgärd. Detta är reserverat för systemen på klientdelsnivån (gateway). Gateway-nivådatorerna har begränsade privilegier på serverdelsdatorerna för att minimera attackytan som en mekanism för skydd på djupet.

Isolering efter datorfunktion och åtkomst

SQL Database består av tjänster som körs på olika datorfunktioner. SQL Database är indelat i "serverdelsmiljöer" och "klientdelsmiljöer" (gateway/hantering), där den allmänna principen för trafik endast går in i serverdelen och inte ut. Klientdelsmiljön kan kommunicera med andra tjänsters omvärld och har i allmänhet endast begränsade behörigheter i serverdelen (tillräckligt för att anropa de startpunkter som den behöver anropa).

Nätverksisolering

Azure-distributionen har flera lager av nätverksisolering. Följande diagram visar olika lager av nätverksisolering som Azure tillhandahåller kunderna. Dessa lager är både inbyggda i själva Azure-plattformen och kunddefinierade funktioner. Inbound from the Internet (Inkommande från Internet) ger Azure DDoS isolering mot storskaliga attacker mot Azure. Nästa lager av isolering är kunddefinierade offentliga IP-adresser (slutpunkter), som används för att avgöra vilken trafik som kan passera genom molntjänsten till det virtuella nätverket. Intern isolering av virtuella Azure-nätverk säkerställer fullständig isolering från alla andra nätverk och att trafiken endast flödar via användardefinierade sökvägar och metoder. Dessa sökvägar och metoder är nästa lager, där NSG:er, UDR och virtuella nätverksinstallationer kan användas för att skapa isoleringsgränser för att skydda programdistributionerna i det skyddade nätverket.

Trafikisolering: Ett virtuellt nätverk är gränsen för trafikisolering på Azure-plattformen. Virtuella datorer i ett virtuellt nätverk kan inte kommunicera direkt till virtuella datorer i ett annat virtuellt nätverk, även om båda de virtuella nätverken skapas av samma kund. Isolering är en viktig egenskap som säkerställer att kundens virtuella datorer och kommunikation förblir privat i ett virtuellt nätverk.

Undernätet erbjuder ytterligare ett lager av isolering med i det virtuella nätverket baserat på IP-intervall. IP-adresser i det virtuella nätverket kan du dela upp ett virtuellt nätverk i flera undernät för organisation och säkerhet. VM:ar och PaaS-rollinstanser som distribuerats till undernät (samma eller olika) inom ett VNet, kan kommunicera med varandra utan övrig konfiguration. Du kan också konfigurera nätverkssäkerhetsgrupp (NSG: er) för att tillåta eller neka nätverkstrafik till en virtuell datorinstans baserat på regler som konfigurerats i åtkomstkontrollistan (ACL) för NSG. NSG:er kan associeras med antingen undernät eller individuella VM-instanser inom det undernätet. När en NSG är associerad med ett undernät tillämpas ACL-reglerna på alla VM-instanser i det undernätet.

Nästa steg

• Lär dig mer om alternativ för nätverksisolering för datorer i virtuella Windows Azure-nätverk. Detta omfattar det klassiska klientdels- och serverdelsscenariot där datorer i ett visst serverdelsnätverk eller undernät endast kan tillåta att vissa klienter eller andra datorer ansluter till en viss slutpunkt baserat på en lista över TILLÅTNA IP-adresser.

• Lär dig mer om isolering av virtuella datorer i Azure. Azure Compute erbjuder storlekar på virtuella datorer som är isolerade till en viss maskinvarutyp och dedikerade till en enda kund.