Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure hjälper dig att köra applikationer och virtuella maskiner (VM) på delad fysisk infrastruktur. En av de främsta ekonomiska fördelarna med att köra applikationer i en molnmiljö är möjligheten att fördela kostnaden för delade resurser mellan flera hyresgäster. Denna multitenanspraxis förbättrar effektiviteten genom att multiplexa resurser mellan olika hyresgäster till låga kostnader. Det innebär dock också risken att dela fysiska servrar och andra infrastrukturresurser för att köra känsliga applikationer och virtuella maskiner som kan tillhöra en godtycklig och potentiellt illvillig användare.
Den här artikeln beskriver hur Azure ger isolering mot både illvilliga och icke-illvilliga användare. Den fungerar som en guide för att arkitektera molnlösningar genom att erbjuda flera isoleringsalternativ till arkitekter.
Isolering på klientnivå
En av de främsta fördelarna med molntjänster är konceptet med delad, gemensam infrastruktur över flera hyresgäster samtidigt, vilket leder till stordriftsfördelar. Det här konceptet kallas multitenancy. Microsoft arbetar kontinuerligt för att säkerställa att multitenant-arkitekturen i Microsoft Azure stödjer standarder för säkerhet, sekretess, integritet, integritet och tillgänglighet.
I den molnaktiverade arbetsplatsen är en "tenant" en organisation eller klient som äger och hanterar en specifik instans av tjänsten. I identitetsplattformen som tillhandahålls av Microsoft Azure är en hyresgäst en dedikerad instans av Microsoft Entra ID som din organisation får 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öretagsbyggnad är en Microsoft Entra-katalog en säker tillgång som endast din organisation kan använda. Microsoft Entra-arkitekturen isolerar kunddata och identitetsinformation från sammanblandning. Denna isolering innebär att användare och administratörer av en Microsoft Entra-katalog inte av misstag eller illvilligt kan komma åt data i en annan katalog.
Azure innehavare
Azure-hyresavtal (Azure-prenumeration) avser en kund- och faktureringsrelation samt en unik hyresgäst i Microsoft Entra ID. Microsoft Entra ID och dess Azure rollbaserade åtkomstkontroll erbjuder isolering på hyresgästnivå i Microsoft Azure. 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. Tilldela dessa åtkomsträttigheter genom att använda Azure-portalen, Azure-kommandoradsverktyg och Azure Management API:er. Säkerhetsgränser isolerar logiskt en Microsoft Entra-klientorganisation så att ingen kund kan få åtkomst till eller kompromettera delade klienter, vare sig avsiktligt eller av misstag. Microsoft Entra ID körs på servrar utan operativsystem som är isolerade i ett separat nätverkssegment, där paketfiltrering på värdnivå och Windows-brandväggen blockerar oönskade anslutningar och trafik.
Access till data i Microsoft Entra ID kräver användarautentisering via en säkerhetstokentjänst (STS). Auktorisationssystemet använder information om användarens existens, aktiverad status och roll för att avgöra om användaren har auktoriserad åtkomst till målhyresgästen i denna session.
Hyresgäster är åtskilda containrar och det finns inget samband mellan dessa containrar.
Ingen åtkomst finns mellan tenanter om inte en tenantadministratör beviljar det via federation eller genom att tillhandahålla användarkonton från andra tenanter.
Microsoft begränsar fysisk åtkomst till servrar som utgör Microsoft Entra-tjänsten och direkt tillgång till Microsoft Entra ID:s backend-system.
Microsoft Entra-användare har ingen tillgång till fysiska tillgångar eller platser, så de kan inte kringgå de logiska Azure RBAC-policykontrollerna som anges nedan.
För diagnostik- och underhållsbehov använder du en operativ modell som använder ett just-in-time-behörighetsupphöjningssystem. Microsoft Entra Privileged Identity Management (PIM) introducerar begreppet en berättigad administratör. Behöriga administratörer är användare som ibland behöver privilegierad åtkomst, men inte varje dag. Rollen är inaktiv tills användaren behöver åtkomst. Användaren genomför sedan en aktiveringsprocess och blir en aktiv administratör under en förutbestämd tid.
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 tenantcontainrar ä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-klienter lagras på samma fysiska disk finns det ingen annan relation mellan containrarna än vad katalogtjänsten definierar, vilket i sin tur styrs av klientadministratören.
Azure rollbaserad åtkomstkontroll (Azure RBAC)
Azure rollbaserad åtkomstkontroll (Azure RBAC) hjälper dig att dela flera komponenter som finns tillgängliga inom en Azure-prenumeration genom att erbjuda finjusterad åtkomsthantering för Azure. Azure RBAC kan du separera uppgifter inom din organisation och bevilja access 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 en Azure prenumeration eller resurser kan du bara tillåta vissa åtgärder.
Azure RBAC har tre grundläggande roller som gäller för alla resurstyper:
Owner har fullständig access till alla resurser, inklusive rätten att delegera access till andra.
Contributor kan skapa och hantera alla typer av Azure resurser men kan inte bevilja access till andra.
Reader kan visa befintliga Azure resurser.
Resten av Azure-rollerna i Azure tillåter hantering av specifika Azure-resurser. Rollen Virtuell maskindeltagare gör det till exempel möjligt för användaren att skapa och hantera virtuella maskiner. Det ger dem inte access till Azure Virtual Network eller undernätet som den virtuella datorn ansluter till.
Azure inbyggda roller listar de roller som är tillgängliga i Azure. De anger vilka å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 se hur du skapar Anpassade roller i Azure RBAC.
Några andra funktioner för Microsoft Entra ID är:
Microsoft Entra ID gör det möjligt för enkel inloggning 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ändarprovisionering och lösenordsvalv.
Microsoft Entra ID tillhandahåller identitet som en tjänst via federation med hjälp av Active Directory Federation Services (ADFS), 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. Använd det med Microsoft Entra ID för att hjälpa till att säkra lokala resurser genom att använda Multi-Factor Authentication Server, samt med anpassade applikationer och kataloger genom att använda SDK:n.
Microsoft Entra Domain Services hjälper dig att ansluta Azure-virtuella maskiner till en služba Active Directory-domän utan att distribuera domänkontroller. Du kan logga in på dessa virtual machines med företagets služba Active Directory autentiseringsuppgifter och administrera domänanslutna virtual machines med hjälp av Group Policy för att framtvinga säkerhetsbaslinjer på alla dina Azure virtual machines.
Microsoft Entra External ID är en mycket tillgänglig global identitetshanteringstjänst för konsumentinriktade applikationer som skalar till hundratals miljoner identiteter. Du kan integrera det över mobila och webbplattformar. 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ämpliga access eller användning av obehöriga personer. De Online Services villkoren erbjuder avtalsåtaganden som styr access till dina data och stöder dessa operativa processer och kontroller.
- Microsofts tekniker har inte standard access till dina data i molnet. I stället beviljas de access, 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 får endast access kunddata för att leverera de tjänster som Microsoft anlitade dem för, och de är förbjudna att använda dem i något annat syfte. Dessutom är de avtalsenligt bundna att upprätthålla konfidentialiteten för kundernas information.
Microsoft och ackrediterade revisionsföretag verifierar regelbundet affärstjänster med granskade certifieringar, till exempel ISO/IEC 27001. Dessa granskare utför stickprovsgranskningar för att intyga att access endast är för legitima affärsändamål. Du kan alltid komma åt dina egna kunddata när som helst och oavsett anledning.
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 slutet av kvarhållningsperioden. (Avsnittet Villkor för databearbetning i Online Services Terms definierar tjänster inom omfattningen.)
Om en diskenhet som används för lagring drabbas av ett maskinvarufel, raderas eller förstörs enheten säkert innan enheten returneras till tillverkaren för utbyte eller reparation. Microsoft skriver över datan på enheten för att säkerställa att ingen kan återställa datan 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 säkra data utan att offra den konfigurationsflexibilitet som organisationer kräver.
Storlekar på isolerade virtuella datorer
Azure Compute erbjuder storlekar på virtuella datorer som är isolerade till en viss maskinvarutyp och dedikerade till en enda kund. De isolerade storlekarna fungerar på specifika hårdvarugenerationer. Azure avskaffar dessa storlekar när hårdvarugenerationen pensioneras eller ny hårdvarugeneration blir tillgänglig.
Isolerade virtuella maskinstorlekar är bäst lämpade för arbetsbelastningar som kräver hög grad av isolering från andra hyresgästers arbetsbelastningar. Denna isolering krävs ibland för att uppfylla kraven på efterlevnad och reglering. Att använda en isolerad storlek garanterar att din virtuella maskin är den enda som körs på just den serverinstansen.
Eftersom isolerade VM:er är stora kan du välja att dela upp deras resurser genom att använda Azure support för nästlade virtuella maskiner.
De nuvarande isolerade virtuella maskinutbuden inkluderar:
Standard_E192is_v6Standard_E192ids_v6Standard_E104i_v5Standard_E104id_v5Standard_E104is_v5Standard_E104ids_v5Standard_E112ias_v5Standard_E112iads_v5Standard_E80is_v4Standard_E80ids_v4Standard_E96ias_v4Standard_E112ibs_v5Standard_E112ibds_v5Standard_EC96ias_v5Standard_EC96iads_v5Standard_HB120rs_v3Standard_HB176rs_v4Standard_HB368rs_v5Standard_HX176rsStandard_M832is_16_v3Standard_M832ids_16_v3Standard_M192is_v2Standard_M192ids_v2Standard_M192ims_v2Standard_M192idms_v2Standard_NC64as_T4_v3Standard_NC96ads_A100_v4Standard_NC80adis_H100_v5Standard_ND128isr_NDR_GB200_v6Standard_ND128isr_NDR_GB300_v6Standard_ND96isr_H100_v5Standard_ND96isr_H200_v5Standard_ND96isr_MI300X_v5Standard_NG32ads_V620_v1Standard_NG32adms_V620_v1Standard_NV72ads_A10_v5
Anteckning
Isolerade VM-storlekar har begränsad livslängd på grund av hårdvaruavvikelser.
Avveckling av isolerade VM-storlekar
Isolerade VM-storlekar har en hårdvarubegränsad livslängd. 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. Azure meddelade följande storlekar för pensionering.
| Storlek | Isoleringsdatum för tillbakadragning |
|---|---|
Standard_DS15_v2 |
15 maj 2020 |
Standard_D15_v2 |
15 maj 2020 |
Standard_G5 |
28 februari 2022 |
Standard_GS5 |
28 februari 2022 |
Standard_E64i_v3 |
28 februari 2022 |
Standard_E64is_v3 |
28 februari 2022 |
Standard_M192is_v2 |
31 mars 2027 |
Standard_M192ims_v2 |
31 mars 2027 |
Standard_M192ids_v2 |
31 mars 2027 |
Standard_M192idms_v2 |
31 mars 2027 |
För att ytterligare dela upp resurserna för dessa isolerade virtuella maskiner, se Azure support för nästlade virtuella maskiner.
Dedikerade värdar
Förutom de isolerade värdar som beskrivs i föregående avsnitt erbjuder Azure även dedikerade värdar. Azure Dedicated Host är en tjänst som tillhandahåller fysiska servrar som kan hosta en eller flera virtuella maskiner och är dedikerade till en enda Azure-prenumeration. Dedikerade värdar tillhandahåller maskinvaruisolering på fysisk servernivå. Inga andra virtuella datorer placeras på dina värdar. Du distribuerar dedikerade värdar i samma datacenter och de delar samma nätverk och underliggande storage infrastruktur som andra, icke-isolerade värdar. Mer information finns i den detaljerade översikten över Azure dedikerade värdar.
Hyper-V och rot-OS-isolering mellan rot-VM:er och gäst-VM:er
Azure beräkningsplattform baseras på datorvirtualisering. All kundkod körs på en Hyper-V virtuell dator. På varje Azure-node (eller nätverksslutpunkt) kör en hypervisor direkt över maskinvaran och delar in noden i ett variabelt antal gäst-VM:ar (virtuella maskiner).
Varje nod har också en särskild virtuell rotdator som kör värdoperativsystemet. Hypervisor- och rotoperativsystemet hanterar isoleringen av den virtuella rotdatorn från de virtuella gästdatorerna och isoleringen av de virtuella gästdatorerna från varandra. Denna kombination av hypervisor och rotoperativsystem använder Microsoft decennier av erfarenhet av operativsystemsäkerhet och mer nyare lärdomar från Microsoft:s Hyper-V för att ge stark isolering av gäst-VM:er.
Den Azure plattformen använder en virtualiserad miljö. Användarinstanser fungerar som fristående virtual machines som inte har access till en fysisk värdserver.
Det Azure hypervisor-programmet fungerar som en mikrokernel. Den skickar alla maskinvaruåtkomstbegäranden från gästvirtuella maskiner till värden, som bearbetas med hjälp av ett gränssnitt med delat minne som kallas VM Bus. Den här arkitekturen hindrar användare från att hämta rå åtkomst till läsa, skriva eller köra i systemet och minskar risken för obehörig delning av systemresurser.
Avancerad algoritm för VM-placering och skydd mot sidokanalsattacker
Varje angrepp mellan virtuella maskiner innebär två steg: att placera en VM som kontrolleras av angriparen på samma värd som en av offrets virtuella maskiner och sedan bryta isoleringsgränsen för att antingen stjäla känslig information från offret eller påverka dess prestanda genom resursstöld eller störning. Microsoft Azure ger skydd i båda stegen med hjälp av en avancerad VM-placeringsalgoritm och skydd mot alla kända sidokanalattacker, inklusive bullriga granne-VM:n.
Azure-vävstyrenheten
Azure Fabric Controller allokerar infrastrukturresurser till klientarbetsbelastningar och hanterar enkelriktad kommunikation från värden till virtual machines. VM-placeringsalgoritmen är mycket sofistikerad och nästan omöjlig att förutsäga på fysisk värdnivå.
I Azure kör root-VM:et ett härdat operativsystem som kallas root-OS, som värdar en fabric agent (FA). FAs hanterar gästagenter (GA) i gästoperativsystem på virtuella kunddatorer och hanterar även storage noder.
Samlingen med Azure hypervisor, rot-OS/FA och virtuella kunddatorer/GA:er består av en beräkningsnod. En tygkontrollant (FC) hanterar FAs. FC finns utanför beräknings- och lagringsnoderna. Separata FCs hanterar beräknings- och lagringskluster. Om en kund uppdaterar sitt programs konfigurationsfil medan den körs kommunicerar FC med FA. FA kontaktar GA:er, som underrättar applikationen om konfigurationsändringen. I händelse av ett maskinvarufel hittar FC automatiskt tillgänglig maskinvara och startar om den virtuella datorn där.
Kommunikationen från en fabrickontroller till en agent är enkelriktad. Agenten implementerar en SSL-skyddad tjänst som endast svarar på begäranden från kontrollanten. Agenten kan inte initiera anslutningar till kontrollern eller andra privilegierade interna noder. FC behandlar alla svar som om de inte var betrodda.
Isoleringen sträcker sig från den virtuella rotdatorn till virtuella gästdatorer och från en virtuell gästdator till en annan. Beräkningsnoder isoleras också från storage noder för ökat skydd.
Hypervisor-programmet och värdoperativsystemet tillhandahåller filter för nätverkspaket. Dessa filter hjälper till att säkerställa att ej betrodda virtual machines inte kan generera falsk trafik eller ta emot trafik som inte är adresserad till dem. De dirigerar trafik till skyddade infrastrukturslutpunkter och förhindrar att olämplig sändningstrafik skickas eller tas emot.
Andra regler konfigurerade av fabric controller agent för att isolera VM
Som standard blockerar Azure all trafik när du skapar en virtuell maskin. Sedan konfigurerar infrastrukturkontrollantagenten paketfiltret för att lägga till regler och undantag för att tillåta auktoriserad trafik.
Fabric Controller-agenten programmerar två kategorier av regler:
- Regler för maskinkonfiguration eller infrastruktur: Som standard blockerar Azure all kommunikation. Lägg till undantag så att en virtuell dator kan skicka och ta emot DHCP- och DNS-trafik. Virtuella datorer kan också skicka trafik till det "offentliga" internet och skicka trafik till andra virtuella datorer inom samma Azure Virtual Network och operativsystemaktiveringsservern. Listan över tillåtna utgående destinationer för virtuella maskiner inkluderar inte Azure-routersubnät, Azure-hantering och andra Microsoft-egenskaper.
- Role configuration file: Den här filen definierar inkommande Access Control listor (ACL: er) baserat på klientorganisationens tjänstmodell.
VLAN-isolering
Varje kluster innehåller tre virtuella lokala nätverk:
- Huvud-VLAN: Kopplar samman opålitliga kundnoder.
- FC VLAN: Innehåller betrodda FC:er och stödjande system.
- Enhetens VLAN: Innehåller betrodda nätverks- och andra infrastrukturenheter.
FC-VLAN:n kan kommunicera med huvud-VLAN:n, men huvud-VLAN:n kan inte initiera kommunikation med FC-VLAN:et. Huvud-VLAN:et kan inte heller kommunicera med enhetens VLAN. Denna VLAN-arkitektur säkerställer att även om en nod som kör kundkod blir komprometterad, kan den inte attackera noder på vare sig FC- eller enhetsVLAN:n.
Storage isolering
Logisk isolering mellan beräkning och lagring
Som en del av den grundläggande designen separerar Microsoft Azure VM-baserad beräkning från storage. Denna design gör det möjligt att skala beräkningsresurser och lagring oberoende av varandra, vilket gör det enklare att tillhandahålla flerklientstöd och isolering.
Därför körs Azure Storage på separat maskinvara utan nätverksanslutning till Azure Compute förutom logisk anslutning. Denna lagringsdesign innebär att när du skapar en virtuell disk så allokerar systemet inte diskutrymme för hela sin kapacitet. I stället skapar systemet en tabell som mappar adresser på den virtuella disken till områden på den fysiska disken. Den här tabellen är ursprungligen tom. Första gången du skriver data på den virtuella disken allokerar systemet utrymme på den fysiska disken och placerar en pekare till den i tabellen.
Isolering med hjälp av lagringsåtkomstkontroll
Access control i Azure Storage använder en enkel access control modell. Varje Azure prenumeration kan skapa ett eller flera storage konton. Varje storage konto har en enda hemlig nyckel som du använder för att styra access till alla data i det storage kontot.
Du kan styra åtkomst till Azure Storage-data (inklusive tabeller) genom en SAS (delad åtkomstsignatur)-token, vilket ger avgränsad åtkomst. Du skapar SAS via en frågemall (URL) och signerar den med SAK (Storage kontonyckel). Du kan ge den signerade URL:en till en annan process (delegerat). Den delegerade processen kan sedan fylla i information om frågan och göra begäran om storage-tjänsten. Med hjälp av en delad åtkomstsignatur (SAS) kan du bevilja tidsbaserad åtkomst till klienter utan att avslöja lagringskontots hemliga nyckel.
Med SAS kan du ge en klient begränsade behörigheter till objekt i ditt lagringskonto under en angiven tidsperiod och en viss uppsättning behörigheter. Du beviljar dessa begränsade behörigheter utan att behöva dela ditt konto access nycklar.
IP-nivå-lagringsisolering
Du kan upprätta brandväggar och definiera ett IP-adressintervall för dina betrodda klienter. Genom att använda ett IP-adressintervall kan endast klienter som har en IP-adress inom det definierade intervallet ansluta till Azure Storage.
Använd en nätverksmekanism som tilldelar en dedikerad tunnel av trafik till IP-lagring för att skydda IP-lagringsdata från obehöriga användare.
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 skyddar data när de överförs mellan nätverk. Med hjälp av Azure Storage kan du skydda data med hjälp av:
- Transport-nivåkryptering, till exempel HTTPS när du överför data till eller från Azure Storage.
- Wire-kryptering, till exempel SMB 3.0-kryptering för Azure filresurser.
- Client-side encryption, för att kryptera data innan de överförs till storage och dekryptera data när de har överförts från storage.
Kryptering i vila
För många organisationer är datakryptering i vila ett obligatoriskt steg mot dataintegritet, efterlevnad och datasuveränitet. Azure funktioner som tillhandahåller kryptering av vilande data är:
- Kryptering för lagringstjänsten krypterar automatiskt data när data skrivs till Azure Storage.
- Kryptering på klientsidan krypterar data innan den överförs till lagring.
- Kryptering på värd tillhandahåller kryptering från slutpunkt till slutpunkt för VM-data.
Kryptering hos värden
Viktigt!
Azure Disk Encryption är planerad att pensioneras den September 15, 2028. Fram till det datumet kan du fortsätta att använda Azure Disk Encryption utan avbrott. Den 15 september 2028 fortsätter ADE-aktiverade arbetsbelastningar att köras, men krypterade diskar kan inte låsas upp efter omstarter av virtuella datorer, vilket resulterar i avbrott i tjänsten.
Använd kryptering på värden för nya virtuella datorer eller överväg konfidentiella VM-storlekar med kryptering av OS-disk för arbetslaster för konfidentiell databehandling. Alla ADE-aktiverade virtuella datorer (inklusive säkerhetskopior) måste migreras till kryptering hos värden före pensionsdatumet för att undvika serviceavbrott. Mer information finns i Migrera från Azure Disk Encryption till kryptering på värd.
Kryptering på värd tillhandahåller kryptering från slutpunkt till slutpunkt för dina VM-data genom att kryptera data på värdnivå för virtuella datorer. Som standard använder den plattformshanterade nycklar, men du kan också använda kundhanterade nycklar som lagras i Azure Key Vault eller Azure Key Vault Managed HSM när du behöver större kontroll.
Kryptering på värd tillhandahåller kryptering på serversidan på VM-värdnivå med hjälp av AES 256-kryptering, som är FIPS 140-2-kompatibel. Den här krypteringen sker utan att förbruka processorresurser för virtuella datorer och tillhandahåller kryptering från slutpunkt till slutpunkt för:
- Tillfälliga diskar
- OS- och datadiskcacheminnen
- Dataflöden till Azure Storage
Viktiga fördelar med kryptering på värdmaskin:
- Ingen prestandapåverkan: Kryptering sker på värdnivå utan att använda VM-CPU-resurser.
- Brett VM-stöd: Stöds på de flesta VM-serier och storlekar.
- Kundhanterade nycklar: Valfri integration med Azure Key Vault eller Managed HSM för nyckelkontroll.
- Plattformshanterade nycklar som standard: Ingen extra konfiguration krävs för kryptering.
Mer information finns i Kryptering på värd och Översikt över krypteringsalternativ för hanterade diskar.
Isolering av SQL-databas
Azure SQL Database är en molnbaserad relationell databastjänst byggd på Microsoft SQL Server-motorn. Azure SQL Database är en mycket tillgänglig, skalbar, multitenant-databastjänst med förutsägbar dataisolering på konto-, geografi-, regions- och nätverksnivå. Tjänsten tillhandahåller denna databasisolering med nästan ingen administration.
SQL Database-programmodell
Ur ett applikationsperspektiv tillhandahåller SQL Database följande hierarki, där varje nivå har ett en-till-många-förhållande med nivåerna nedan.
Kontot och prenumerationen är Microsoft Azure plattformskoncept för att associera fakturering och hantering.
Logiska SQL-servrar och databaser är SQL-databasspecifika koncept. Du hanterar dem genom att använda OData- och T-SQL-gränssnitt som tillhandahålls av SQL Database, eller Azure-portalen.
Servrar i SQL Database är varken fysiska eller VM-instanser. Istället är de samlingar av databaser som delar hanterings- och säkerhetspolicys lagrade i en så kallad logisk huvuddatabas.
Logiska huvuddatabaser är:
- SQL-inloggningar som används för att ansluta till servern
- Brandväggsregler
Fakturering och användningsrelaterad information för databaser från samma server är inte garanterat att finnas på samma fysiska instans i klustret. Applikationer måste ange måldatabasens namn vid anslutning.
Ur ditt perspektiv skapar du en server i en geografisk region, men Azure skapar servern i ett av klustren i den regionen.
Isolering via nätverkstopologi
När du skapar en server och registrerar dess DNS-namn pekar DNS-namnet på Gateway VIP-adressen i det specifika datacenter där du placerar servern.
Bakom VIP-adressen (virtuell IP-adress) finns en samling tillståndslösa gatewaytjänster. I allmänhet engagerar sig gatewayer när samordning krävs mellan flera datakällor (huvuddatabas, användardatabas och så vidare). Gatewaytjänster implementerar följande funktioner:
- Proxy för TDS-anslutning. Den här funktionen omfattar att hitta användardatabasen i serverdelsklustret, implementera autentiseringssekvensen och sedan vidarebefordra TDS-paketen till serverdelen och tillbaka.
- Databashantering. Den här funktionen omfattar implementering av en samling arbetsflöden för att hantera databasåtgärderna CREATE, ALTER och DROP. Tjänsten kan anropa databasoperationer genom att antingen sniffa TDS-paket eller explicita OData-API:er.
- SKAPA, ÄNDRA och TA BORT autentiserings- och användaråtgärder
- Serverhanteringsåtgärder via OData API
Nivån bakom gatewayerna kallas serverdel. Backend-lagret lagrar all data på ett mycket tillgängligt sätt. Varje datadel tillhör en partition eller redundansenhet och varje partition har minst tre repliker. Den SQL Server motorn lagrar och replikerar repliker, och ett redundanssystem som ofta kallas fabric hanterar dem.
I allmänhet kommunicerar backend-systemet inte utgående till andra system som en säkerhetsåtgärd. Azure reserverar utgående kommunikation till systemen i front-end (gateway) nivån. Maskinerna i gateway-nivån har begränsade behörigheter på backend-maskinerna. Denna begränsning minimerar attackytan som en försvarsmekanism i djupet.
Isolering efter maskinfunktion och åtkomst
SQL Database består av tjänster som körs på olika maskinfunktioner. SQL Database delar in dessa tjänster i backend-molndatabaser och front-end gateway- och hanteringsmiljöer, med den allmänna principen att trafiken endast går in i back-end och inte ut. Front-end-miljön kan kommunicera med omvärlden av andra tjänster och har generellt bara begränsade behörigheter i back-end (tillräckligt för att kalla de ingångspunkter den behöver anropa).
Nätverksisolering
Azure-distributioner har flera lager av nätverksisolering. Följande diagram visar olika lager av nätverksisolering som Azure tillhandahåller. Dessa lager inkluderar inbyggda Azure-plattformsfunktioner och kunddefinierade funktioner. Inkommande från Internet ger Azure DDoS protection isolering mot storskaliga attacker mot Azure. Nästa lager av isolering är kunddefinierade offentliga IP-adresser (slutpunkter), som du använder för att avgöra vilken trafik som kan passera genom molntjänsten till virtual network. Inbyggd Azure virtuell nätverksisolering säkerställer fullständig isolering från alla andra nätverk. Trafiken flödar endast genom användarkonfigurerade vägar och metoder. Dessa vägar och metoder är nästa lager, där NSG:er, UDR och du kan använda virtuella nätverksapparater för att skapa isoleringsgränser för att skydda applikationsdistributionerna i det skyddade nätverket.
Traffic isolation: Ett virtuellt nätverk är trafikisoleringsgränsen på Azure-plattformen. Virtuella datorer i ett virtuellt nätverk kan inte kommunicera direkt med virtuella datorer i ett annat virtuellt nätverk, även om båda de virtuella nätverken skapas av samma kund. Isolering är en kritisk egenskap som säkerställer att kund-VM:ar och kommunikation förblir privata inom ett virtuellt nätverk.
Ett subnät ger ytterligare ett isoleringslager inom ett virtuellt nätverk baserat på IP-intervall. Du kan dela upp en virtual network i flera undernät för organisation och säkerhet. Virtuella datorer och PaaS-rollinstanser som distribueras till undernät (samma eller olika) inom en virtual network kan kommunicera med varandra utan någon extra konfiguration. Du kan också konfigurera nätverkssäkerhetsgrupper (NSG:er) för att tillåta eller neka nätverkstrafik till en virtuell datorinstans baserat på säkerhetsregler. Du kan associera NSG:er med antingen undernät eller enskilda nätverksgränssnitt som är kopplade till virtuella datorer. När du associerar en NSG med ett undernät gäller säkerhetsreglerna för alla vm-instanser i det undernätet.
Nästa steg
Läs mer om nätverkssäkerhetsgrupper. Nätverkssäkerhetsgrupper filtrerar nätverkstrafiken mellan Azure-resurser i ett virtuellt nätverk. Du kan begränsa trafik till undernät eller virtual machines baserat på källa, mål, port och protokoll med hjälp av säkerhetsregler.
Lär dig om virtuell maskinisolering i Azure. Azure Compute erbjuder storlekar på virtuella datorer som är isolerade till en viss maskinvarutyp och dedikerade till en enda kund.