Isolatie in de openbare Azure-cloud

Met Azure kunt u toepassingen en virtuele machines (VM's) uitvoeren op een gedeelde fysieke infrastructuur. Een van de belangrijkste economische redenen voor het uitvoeren van toepassingen in een cloudomgeving is de mogelijkheid om de kosten van gedeelde resources te verdelen over meerdere klanten. Deze praktijk van multitenancy verbetert de efficiëntie door resources te multiplexen bij verschillende klanten tegen lage kosten. Helaas introduceert het ook het risico dat fysieke servers en andere infrastructuurbronnen worden gedeeld om uw gevoelige toepassingen en VM's uit te voeren die mogelijk deel uitmaken van een willekeurige en mogelijk kwaadwillende gebruiker.

In dit artikel wordt beschreven hoe Azure isolatie biedt tegen zowel kwaadwillende als niet-kwaadwillende gebruikers en fungeert als een handleiding voor het ontwerpen van cloudoplossingen door verschillende isolatieopties aan architecten aan te bieden.

Isolatie op tenantniveau

Een van de belangrijkste voordelen van cloud-computing is het concept van een gedeelde, gemeenschappelijke infrastructuur voor meerdere klanten tegelijk, wat leidt tot schaalvoordelen. Dit concept wordt multitenancy genoemd. Microsoft werkt continu om ervoor te zorgen dat de architectuur met meerdere tenants van Microsoft Cloud Azure beveiliging, vertrouwelijkheid, privacy, integriteit en beschikbaarheidsstandaarden ondersteunt.

Met betrekking tot werklocaties in de cloud kan een tenant worden gedefinieerd als een client of organisatie die een bepaald exemplaar van de gebruikte cloudservice in eigendom heeft en beheert. Met het identiteitsplatform dat wordt geleverd door Microsoft Azure, is een tenant gewoon een toegewezen exemplaar van Azure Active Directory (Azure AD) dat uw organisatie ontvangt en eigenaar is wanneer deze zich registreert voor een Microsoft-cloudservice.

Elke Azure AD-directory is uniek en werkt afzonderlijk van andere Azure AD-directory’s. Net zoals een kantoorgebouw een beveiligd bedrijfsmiddel is van uw organisatie, is ook een Azure AD-directory ontworpen als een beveiligd bedrijfsmiddel dat alleen door uw organisatie kan worden gebruikt. De Azure AD-architectuur isoleert klant- en identiteitsgegevens, zodat deze niet door elkaar worden gehaald. Dit betekent dat gebruikers en beheerders van een Azure AD-directory niet per ongeluk of opzettelijk gegevens in een andere directory kunnen openen.

Azure Tenancy

Azure-tenancy (Azure-abonnement) verwijst naar een relatie 'klant/facturering' en een unieke tenant in Azure Active Directory. Isolatie op tenantniveau in Microsoft Azure wordt bereikt met behulp van Azure Active Directory en op rollen gebaseerd toegangsbeheer van Azure dat wordt aangeboden. Elk Azure-abonnement is gekoppeld aan één Azure Active Directory-directory (AD).

Gebruikers, groepen en toepassingen uit die directory kunnen resources in het Azure-abonnement beheren. U kunt deze toegangsrechten toewijzen met behulp van de Azure Portal, Azure-opdrachtregelprogramma's en Azure Management-API's. Een Azure AD-tenant is logisch geïsoleerd met behulp van beveiligingsgrenzen, zodat geen enkele klant toegang heeft tot co-tenants, kwaadwillig of per ongeluk. Azure AD wordt uitgevoerd op bare-metalservers die zijn geïsoleerd op een gescheiden netwerksegment, waarbij pakketfiltering op hostniveau en Windows Firewall ongewenste verbindingen en verkeer blokkeren.

Diagram met Azure-tenancy.

  • Voor toegang tot gegevens in Azure AD is gebruikersverificatie vereist via een beveiligingstokenservice (STS). Informatie over het bestaan, ingeschakelde status en rol van de gebruiker wordt gebruikt door het autorisatiesysteem om te bepalen of de aangevraagde toegang tot de doeltenant is geautoriseerd voor deze gebruiker in deze sessie.

  • Tenants zijn discrete containers en er is geen relatie tussen deze containers.

  • Geen toegang tussen tenants, tenzij tenantbeheerders deze verlenen via federatie of gebruikersaccounts inrichten van andere tenants.

  • Fysieke toegang tot servers die de Azure AD-service vormen en directe toegang tot de back-endsystemen van Azure AD, is beperkt.

  • Azure AD gebruikers geen toegang hebben tot fysieke assets of locaties en daarom is het niet mogelijk om de logische Controles van het Azure RBAC-beleid te omzeilen die hierna worden vermeld.

Voor diagnostische en onderhoudsbehoeften is een operationeel model dat gebruikmaakt van een Just-In-Time Privilege-uitbreidingssysteem vereist en gebruikt. Azure AD Privileged Identity Management (PIM) introduceert het concept van een in aanmerking komende beheerder. In aanmerking komende beheerders moeten gebruikers zijn die nu en dan bevoegde toegang nodig hebben, maar niet elke dag. De rol is inactief totdat gebruikers toegang nodig hebben. Op dat moment voeren ze een activeringsproces uit en zijn ze gedurende een vooraf bepaalde hoeveelheid tijd een actieve beheerder.

Azure AD Privileged Identity Management

Azure Active Directory host elke tenant in een eigen beveiligde container, met beleidsregels en machtigingen voor en binnen de container die uitsluitend eigendom is van en wordt beheerd door de tenant.

Het concept van tenantcontainers is diep ingeperkt in de adreslijstservice op alle lagen, van portals tot permanente opslag.

Zelfs wanneer metagegevens van meerdere Azure Active Directory-tenants worden opgeslagen op dezelfde fysieke schijf, is er geen relatie tussen de containers anders dan wat wordt gedefinieerd door de adreslijstservice, die op zijn beurt wordt bepaald door de tenantbeheerder.

Azure RBAC (op rollen gebaseerd toegangsbeheer van Azure)

Met op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) kunt u verschillende onderdelen delen die beschikbaar zijn in een Azure-abonnement door gedetailleerd toegangsbeheer voor Azure te bieden. Met Azure RBAC kunt u taken binnen uw organisatie scheiden en toegang verlenen op basis van wat gebruikers nodig hebben om hun taken uit te voeren. In plaats van iedereen onbeperkte machtigingen te geven in een Azure-abonnement of -resources, kunt u alleen bepaalde acties toestaan.

Azure RBAC heeft drie basisrollen die van toepassing zijn op alle resourcetypen:

  • De eigenaar heeft volledige toegang tot alle resources, inclusief het recht om toegang tot anderen te delegeren.

  • Inzender kan alle typen Azure-resources maken en beheren, maar kan geen toegang verlenen aan anderen.

  • Lezer kan bestaande Azure-resources weergeven.

Azure RBAC (op rollen gebaseerd toegangsbeheer van Azure)

De rest van de Azure-rollen in Azure staan beheer van specifieke Azure-resources toe. Met de rol Inzender voor virtuele machines kan een gebruiker bijvoorbeeld virtuele machines maken en beheren. Het geeft ze geen toegang tot de Azure-Virtual Network of het subnet waarmee de virtuele machine verbinding maakt.

Ingebouwde Azure-rollen vermelden de rollen die beschikbaar zijn in Azure. Hiermee geeft u de bewerkingen en het bereik op die elke ingebouwde rol aan gebruikers verleent. Als u uw eigen rollen wilt definiëren voor nog meer controle, raadpleegt u hoe u aangepaste rollen kunt bouwen in Azure RBAC.

Enkele andere mogelijkheden voor Azure Active Directory zijn:

  • Azure AD maakt eenmalige aanmelding (SSO) bij SaaS-toepassingen mogelijk, ongeacht waar ze worden gehost. Voor sommige toepassingen kan federatieve aanmelding worden gebruikt via Azure AD en voor andere toepassingen kan eenmalige aanmelding (SSO) met een wachtwoord worden gebruikt. Federatieve toepassingen kunnen ook ondersteuning bieden voor gebruikersinrichting en wachtwoordkluis.

  • De toegang tot gegevens in Azure Storage wordt geregeld via verificatie. Elk opslagaccount heeft een primaire sleutel (opslagaccountsleutel of SAK) en een secundaire geheime sleutel (de shared access signature of SAS).

  • Azure AD biedt Identity as a Service via federatie met behulp van Active Directory Federation Services, synchronisatie en replicatie met on-premises directory's.

  • Azure AD Multi-Factor Authentication vereist dat gebruikers aanmeldingen verifiëren met behulp van een mobiele app, telefoongesprek of sms-bericht. Het kan worden gebruikt met Azure AD om on-premises resources te beveiligen met de Multi-Factor Authentication-server, en ook met aangepaste toepassingen en mappen met behulp van de SDK.

  • Azure AD Domain Services kunt u virtuele Azure-machines toevoegen aan een Active Directory-domein zonder domeincontrollers te implementeren. U kunt zich aanmelden bij deze virtuele machines met uw Active Directory-referenties van uw bedrijf en virtuele machines die lid zijn van een domein beheren met behulp van groepsbeleid om beveiligingsbasislijnen af te dwingen op al uw virtuele Azure-machines.

  • Azure Active Directory B2C biedt een maximaal beschikbare service voor globaal identiteitsbeheer voor consumententoepassingen die worden geschaald naar honderden miljoenen identiteiten. De service kan worden geïntegreerd in zowel mobiele als webplatforms. Uw gebruikers kunnen zich aanmelden bij al uw toepassingen via aanpasbare ervaringen met behulp van hun bestaande sociale accounts of door referenties te maken.

Isolatie van Gegevensverwijdering van Microsoft-beheerders &

Microsoft neemt sterke maatregelen om uw gegevens te beschermen tegen ongepaste toegang of gebruik door onbevoegden. Deze operationele processen en controles worden ondersteund door de voorwaarden voor onlineservices, die contractuele toezeggingen bieden die de toegang tot uw gegevens regelen.

  • Microsoft-technici hebben geen standaardtoegang tot uw gegevens in de cloud. In plaats daarvan krijgen ze alleen toegang, onder toezicht van het beheer, alleen wanneer dat nodig is. Deze toegang wordt zorgvuldig beheerd en geregistreerd en ingetrokken wanneer deze niet meer nodig is.
  • Microsoft kan andere bedrijven inhuren om beperkte services namens hen te leveren. Onderaannemers hebben alleen toegang tot klantgegevens om de diensten te leveren waarvoor wij hen hebben ingehuurd om te leveren, en ze mogen deze niet gebruiken voor enig ander doel. Verder zijn ze contractueel gebonden aan het handhaven van de vertrouwelijkheid van de informatie van onze klanten.

Zakelijke services met gecontroleerde certificeringen zoals ISO/IEC 27001 worden regelmatig gecontroleerd door Microsoft en erkende auditbedrijven, die voorbeeldcontroles uitvoeren om die toegang te bevestigen, alleen voor legitieme zakelijke doeleinden. U hebt altijd toegang tot uw eigen klantgegevens op elk gewenst moment en om welke reden dan ook.

Als u gegevens verwijdert, worden de gegevens in Microsoft Azure verwijderd, inclusief kopieën in de cache of back-up. Voor services binnen het bereik vindt deze verwijdering binnen 90 dagen na het einde van de bewaarperiode plaats. (Services binnen het bereik worden gedefinieerd in de sectie Voorwaarden voor gegevensverwerking van onze Online Services-voorwaarden.)

Als een schijfstation dat wordt gebruikt voor opslag een hardwarefout ondervindt, wordt het veilig gewist of vernietigd voordat Microsoft het teruggeeft aan de fabrikant voor vervanging of reparatie. De gegevens op het station worden overschreven om ervoor te zorgen dat de gegevens op geen enkele manier kunnen worden hersteld.

Rekenisolatie

Microsoft Azure biedt verschillende cloudcomputingservices die een breed scala aan rekeninstantieservices & bevatten die automatisch omhoog en omlaag kunnen worden geschaald om te voldoen aan de behoeften van uw toepassing of onderneming. Deze rekeninstantie en -service bieden isolatie op meerdere niveaus om gegevens te beveiligen zonder de flexibiliteit in de configuratie die klanten nodig hebben, te beperken.

Geïsoleerde grootten van virtuele machines

Azure Compute biedt vm-grootten die zijn geïsoleerd voor een specifiek hardwaretype en toegewezen aan één klant. De geïsoleerde grootten leven en werken op specifieke hardwaregeneratie en worden afgeschaft wanneer de hardwaregeneratie buiten gebruik wordt gesteld.

Geïsoleerde grootten van virtuele machines zijn het meest geschikt voor workloads die een hoge mate van isolatie van workloads van andere klanten vereisen om redenen die onder andere voldoen aan nalevings- en regelgevingsvereisten. Het gebruik van een geïsoleerde grootte garandeert dat uw virtuele machine de enige is die wordt uitgevoerd op dat specifieke serverexemplaren.

Bovendien kunnen klanten, omdat de geïsoleerde vm's groot zijn, ervoor kiezen om de resources van deze VM's onder te verdelen met behulp van ondersteuning voor Azure voor geneste virtuele machines.

De huidige aanbiedingen voor geïsoleerde virtuele machines zijn onder andere:

  • 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

Notitie

Geïsoleerde VM-grootten hebben een beperkte levensduur van hardware. Zie hieronder voor meer informatie

Afschaffing van geïsoleerde VM-grootten

Geïsoleerde VM-grootten hebben een beperkte levensduur van hardware. Azure geeft 12 maanden vóór de officiële afschaffingsdatum herinneringen uit en biedt een bijgewerkt geïsoleerd aanbod voor uw overweging.

Grootte Buitengebruikstellingsdatum isolatie
Standard_DS15_v2 15 mei 2021
Standard_D15_v2 15 mei 2021
Standard_G5 15 februari 2022
Standard_GS5 15 februari 2022
Standard_E64i_v3 15 februari 2022
Standard_E64is_v3 15 februari 2022

Veelgestelde vragen

V: Wordt de grootte buiten gebruik gesteld of alleen de functie isolatie?

A: Momenteel wordt alleen de isolatiefunctie van de VM-grootten buiten gebruik gesteld. De afgeschafte geïsoleerde grootten blijven bestaan in niet-geïsoleerde toestand. Als isolatie niet nodig is, hoeft er geen actie te worden ondernomen en blijft de VM werken zoals verwacht.

V: Is er downtime wanneer mijn vm op een niet-geïsoleerde hardware terechtkomt?

A: Als er geen isolatie nodig is, is er geen actie nodig en is er geen downtime. In tegenstelling tot als isolatie vereist is, zal onze aankondiging de aanbevolen vervangingsgrootte bevatten. Als u de vervangingsgrootte selecteert, moeten onze klanten de grootte van hun VM's wijzigen.

V: Zijn er kosten delta's voor het verplaatsen naar een niet-geïsoleerde virtuele machine?

A: Nee

V: Wanneer worden de andere geïsoleerde grootten buiten gebruik gesteld?

A: We zullen 12 maanden voor de officiële afschaffing van de geïsoleerde grootte herinneringen verstrekken. Onze laatste aankondiging omvat het buiten gebruik maken van isolatiefuncties van Standard_G5, Standard_GS5, Standard_E64i_v3 en Standard_E64i_v3.

V: Ik ben een Azure Service Fabric-klant die vertrouwt op de Silver- of Gold-duurzaamheidslagen. Heeft deze wijziging invloed op mij?

A: Nee. De garanties die worden geboden door de duurzaamheidslagen van Service Fabric blijven werken, zelfs na deze wijziging. Als u om andere redenen fysieke hardware-isolatie nodig hebt, moet u mogelijk nog steeds een van de hierboven beschreven acties uitvoeren.

V: Wat zijn de mijlpalen voor D15_v2 of DS15_v2 isolatie buitengebruikstelling?

A:

Date Actie
15 mei 20201 Aankondiging van buitengebruikstelling van D/DS15_v2 isolatie
15 mei 2021 D/DS15_v2 isolatiegarantie verwijderd

1 Bestaande klant die deze grootten gebruikt, ontvangt een aankondigingsmail met gedetailleerde instructies voor de volgende stappen.

V: Wat zijn de mijlpalen voor de buitengebruikstelling van G5, Gs5, E64i_v3 en E64is_v3 isolatie?

A:

Date Actie
15 februari 20211 Aankondiging van buitengebruikstelling van G5/GS5/E64i_v3/E64is_v3 isolatie
28 februari 2022 G5/GS5/E64i_v3/E64is_v3 isolatiegarantie verwijderd

1 Bestaande klant die deze grootten gebruikt, ontvangt een aankondigingsmail met gedetailleerde instructies voor de volgende stappen.

Volgende stappen

Klanten kunnen er ook voor kiezen om de resources van deze geïsoleerde virtuele machines verder te onderverdelen met behulp van ondersteuning voor Azure voor geneste virtuele machines.

Toegewezen hosts

Naast de geïsoleerde hosts die in de vorige sectie worden beschreven, biedt Azure ook toegewezen hosts. Toegewezen hosts in Azure is een service die fysieke servers biedt die een of meer virtuele machines kunnen hosten en die zijn toegewezen aan één Azure-abonnement. Toegewezen hosts bieden hardware-isolatie op het niveau van de fysieke server. Er worden geen andere VM's op uw hosts geplaatst. Toegewezen hosts worden geïmplementeerd in dezelfde datacenters en delen dezelfde netwerk- en onderliggende opslaginfrastructuur als andere, niet-geïsoleerde hosts. Zie het gedetailleerde overzicht van toegewezen Azure-hosts voor meer informatie.

Hyper-V-hoofdbesturingssysteemisolatie & tussen gast-VM's van hoofd-VM's &

Het rekenplatform van Azure is gebaseerd op machinevirtualisatie, wat betekent dat alle klantcode wordt uitgevoerd in een virtuele Hyper-V-machine. Op elk Azure-knooppunt (of netwerkeindpunt) is er een Hypervisor die rechtstreeks via de hardware wordt uitgevoerd en een knooppunt verdeelt in een variabel aantal gast-Virtual Machines (VM's).

Hyper-V-hoofdbesturingssysteemisolatie & tussen gast-VM's van hoofd-VM's &

Elk knooppunt heeft ook één speciale hoofd-VM, waarop het host-besturingssysteem wordt uitgevoerd. Een kritieke grens is de isolatie van de hoofd-VM van de gast-VM's en de gast-VM's van elkaar, beheerd door de hypervisor en het hoofdbesturingssystemen. De koppeling van het hypervisor-/hoofdbesturingssysteem maakt gebruik van de decennia aan beveiligingservaring van het besturingssysteem van Microsoft en recentere kennis van Hyper-V van Microsoft om een sterke isolatie van gast-VM's te bieden.

Voor het Azure-platform wordt gebruikgemaakt van een gevirtualiseerde omgeving. Gebruikersexemplaren werken als zelfstandige virtuele machines die geen toegang hebben tot een fysieke hostserver.

De Azure-hypervisor fungeert als een micro-kernel en geeft alle aanvragen voor hardwaretoegang van virtuele gastmachines door aan de host voor verwerking met behulp van een interface met gedeeld geheugen met de naam VM Bus. Dit voorkomt dat gebruikers onbeperkt toegang krijgen tot het systeem om gegevens te lezen en te schrijven of programma’s uit te voeren en vermindert de risico’s die kleven aan het delen van systeemresources.

Geavanceerde beveiliging van VM-plaatsingsalgoritmen & tegen aanvallen aan het zijkanaal

Elke aanval op meerdere VM's omvat twee stappen: het plaatsen van een door een kwaadwillende VM op dezelfde host als een van de slachtoffer-VM's en vervolgens het overschrijden van de isolatiegrens om gevoelige slachtofferinformatie te stelen of de prestaties ervan te beïnvloeden voor greed of taxonomisch. Microsoft Azure biedt bescherming bij beide stappen met behulp van een geavanceerd algoritme voor vm-plaatsing en beveiliging tegen alle bekende side channel-aanvallen, waaronder luidruchtige vm's.

De Azure Fabric-controller

De Azure Fabric Controller is verantwoordelijk voor het toewijzen van infrastructuurresources aan tenantworkloads en beheert unidirectionele communicatie van de host naar virtuele machines. Het plaatsen van een algoritme van de Azure-infrastructuurcontroller is zeer geavanceerd en bijna onmogelijk om te voorspellen als fysiek hostniveau.

De Azure Fabric-controller

De Azure-hypervisor dwingt geheugen- en processcheiding af tussen virtuele machines en routeert netwerkverkeer veilig naar tenants van gastbesturingssystemen. Dit elimineert de mogelijkheid van en aanvallen op side channel op VM-niveau.

In Azure is de hoofd-VM speciaal: er wordt een beveiligd besturingssysteem uitgevoerd met de naam het hoofdbesturingssysteem dat als host fungeert voor een infrastructuuragent (FA). CA's worden op hun beurt gebruikt om gastagenten (GA) te beheren binnen gastbesturingssystemen op klant-VM's. CA's beheren ook opslagknooppunten.

De verzameling Azure-hypervisor, hoofdbesturingssysteem/FA en klant-VM's/CA's bestaat uit een rekenknooppunt. CA's worden beheerd door een infrastructuurcontroller (FC), die zich buiten reken- en opslagknooppunten bevindt (reken- en opslagclusters worden beheerd door afzonderlijke PC's). Als een klant het configuratiebestand van de toepassing bijwerken terwijl deze wordt uitgevoerd, communiceert de FC met de FA, die vervolgens contact op neemt met CA's, die de toepassing van de configuratiewijziging informeren. In het geval van een hardwarestoring vindt de FC automatisch beschikbare hardware en start de VIRTUELE machine daar opnieuw op.

Azure Fabric Controller

Communicatie van een fabriccontroller naar een agent is unidirectioneel. De agent implementeert een met SSL beveiligde service die alleen reageert op aanvragen van de controller. Het kan geen verbindingen met de controller of andere bevoegde interne knooppunten initiëren. De FC behandelt alle reacties alsof ze niet vertrouwd waren.

Infrastructuurcontroller

Isolatie breidt zich uit van de hoofd-VM van gast-VM's en de gast-VM's van elkaar. Rekenknooppunten worden ook geïsoleerd van opslagknooppunten voor betere beveiliging.

De hypervisor en het hostbesturingssysteem bieden netwerkpakketten: filters om ervoor te zorgen dat niet-vertrouwde virtuele machines geen vervalst verkeer kunnen genereren of verkeer kunnen ontvangen dat niet is geadresseerd, verkeer naar beveiligde infrastructuureindpunten sturen of ongepast broadcast-verkeer verzenden/ontvangen.

Aanvullende regels die zijn geconfigureerd door de Fabric Controller-agent om de VM te isoleren

Standaard wordt al het verkeer geblokkeerd wanneer een virtuele machine wordt gemaakt en configureert de infrastructuurcontrolleragent het pakketfilter om regels en uitzonderingen toe te voegen om geautoriseerd verkeer toe te staan.

Er zijn twee categorieën regels geprogrammeerd:

  • Machineconfiguratie- of infrastructuurregels: Standaard wordt alle communicatie geblokkeerd. Er zijn uitzonderingen om toe te staan dat een virtuele machine DHCP- en DNS-verkeer verzendt en ontvangt. Virtuele machines kunnen ook verkeer verzenden naar het openbare internet en verkeer verzenden naar andere virtuele machines binnen dezelfde Azure-Virtual Network en de activeringsserver van het besturingssysteem. De lijst met toegestane uitgaande bestemmingen van virtuele machines bevat geen Azure-routersubnetten, Azure-beheer en andere Microsoft-eigenschappen.
  • Configuratiebestand voor rollen: Hiermee definieert u de inkomende Access Control Lijsten (ACL's) op basis van het servicemodel van de tenant.

VLAN-isolatie

Er zijn drie VLAN's in elk cluster:

VLAN-isolatie

  • Het belangrijkste VLAN : verbindt niet-vertrouwde klantknooppunten
  • Het FC VLAN – bevat vertrouwde FCS's en ondersteunende systemen
  • Het VLAN van het apparaat: bevat vertrouwde netwerk- en andere infrastructuurapparaten

Communicatie is toegestaan van het FC VLAN naar het hoofd-VLAN, maar kan niet worden gestart van het hoofd-VLAN naar het FC VLAN. Communicatie wordt ook geblokkeerd van het hoofd-VLAN naar het VLAN van het apparaat. Dit zorgt ervoor dat zelfs als een knooppunt met klantcode wordt aangetast, er geen knooppunten kunnen worden aangevallen op de VLAN's van fc of apparaten.

Opslagisolatie

Logische isolatie tussen compute en opslag

Als onderdeel van het fundamentele ontwerp scheidt Microsoft Azure berekeningen op basis van VM's van opslag. Met deze scheiding kunnen berekeningen en opslag onafhankelijk worden geschaald, waardoor het eenvoudiger is om multitenancy en isolatie te bieden.

Daarom wordt Azure Storage uitgevoerd op afzonderlijke hardware zonder netwerkverbinding met Azure Compute, behalve logisch. Dit betekent dat wanneer een virtuele schijf wordt gemaakt, er geen schijfruimte wordt toegewezen voor de volledige capaciteit. In plaats daarvan wordt er een tabel gemaakt waarmee adressen op de virtuele schijf worden toegewezen aan gebieden op de fysieke schijf en die tabel in eerste instantie leeg is. De eerste keer dat een klant gegevens op de virtuele schijf schrijft, wordt ruimte op de fysieke schijf toegewezen en wordt er een aanwijzer naar deze in de tabel geplaatst.

Isolatie met opslagtoegangsbeheer

Access Control in Azure Storage heeft een eenvoudig toegangsbeheermodel. Elk Azure-abonnement kan een of meer opslagaccounts maken. Elk opslagaccount heeft één geheime sleutel die wordt gebruikt om de toegang tot alle gegevens in dat opslagaccount te beheren.

Isolatie met opslagtoegangsbeheer

Toegang tot Azure Storage-gegevens (inclusief tabellen) kan worden beheerd via een SAS-token (Shared Access Signature), dat scoped toegang verleent. De SAS wordt gemaakt via een querysjabloon (URL), ondertekend met de SAK (Opslagaccountsleutel). Deze ondertekende URL kan worden gegeven aan een ander proces (dat wil gezegd, gedelegeerd), waarmee vervolgens de details van de query kunnen worden ingevuld en de aanvraag van de opslagservice kan worden ingediend. Met een SAS kunt u tijdgebaseerde toegang verlenen tot clients zonder de geheime sleutel van het opslagaccount te onthullen.

De SAS betekent dat we een client beperkte machtigingen kunnen verlenen aan objecten in ons opslagaccount gedurende een bepaalde periode en met een opgegeven set machtigingen. We kunnen deze beperkte machtigingen verlenen zonder uw accounttoegangssleutels te hoeven delen.

Isolatie van opslag op IP-niveau

U kunt firewalls instellen en een IP-adresbereik definiëren voor uw vertrouwde clients. Met een IP-adresbereik kunnen alleen clients met een IP-adres binnen het gedefinieerde bereik verbinding maken met Azure Storage.

IP-opslaggegevens kunnen worden beveiligd tegen onbevoegde gebruikers via een netwerkmechanisme dat wordt gebruikt om een toegewezen of toegewezen tunnel van verkeer toe te wijzen aan IP-opslag.

Versleuteling

Azure biedt de volgende typen versleuteling om gegevens te beveiligen:

  • Versleuteling 'in transit'
  • Versleuteling 'at rest'

Versleuteling in transit

Versleuteling tijdens overdracht is een mechanisme voor het beveiligen van gegevens wanneer deze worden verzonden via netwerken. Met Azure Storage kunt u gegevens beveiligen met behulp van:

Versleuteling at rest

Voor veel organisaties is gegevensversleuteling in rust een verplichte stap in de richting van gegevensprivacy, naleving en gegevenssoevereine. Er zijn drie Azure-functies die versleuteling bieden van gegevens die 'at rest' zijn:

Zie Overzicht van versleutelingsopties voor beheerde schijven voor meer informatie.

Azure Disk Encryption

Met Azure Disk Encryption voor Linux-VM's en Azure Disk Encryption voor Windows-VM's kunt u de beveiligings- en nalevingsvereisten van de organisatie oplossen door uw VM-schijven (inclusief opstart- en gegevensschijven) te versleutelen met sleutels en beleidsregels die u beheert in Azure Key Vault.

De oplossing Schijfversleuteling voor Windows is gebaseerd op Microsoft BitLocker-stationsversleuteling en de Linux-oplossing is gebaseerd op dm-crypt.

De oplossing ondersteunt de volgende scenario's voor IaaS-VM's wanneer deze zijn ingeschakeld in Microsoft Azure:

  • Integratie met Azure Key Vault
  • Vm's in de Standard-laag: A, D, DS, G, GS, enzovoort, iaaS-VM's uit de serie
  • Versleuteling inschakelen op Virtuele Windows- en Linux IaaS-machines
  • Versleuteling uitschakelen op besturingssysteem- en gegevensstations voor Windows IaaS-VM's
  • Versleuteling uitschakelen op gegevensstations voor Linux IaaS-VM's
  • Versleuteling inschakelen op IaaS-VM's waarop windows-clientbesturingssystemen worden uitgevoerd
  • Versleuteling inschakelen voor volumes met koppelpaden
  • Versleuteling inschakelen op Linux-VM's die zijn geconfigureerd met schijfstriping (RAID) met behulp van mdadm
  • Versleuteling inschakelen op Linux-VM's met behulp van LVM (Logical Volume Manager) voor gegevensschijven
  • Versleuteling inschakelen op Windows-VM's die zijn geconfigureerd met behulp van opslagruimten
  • Alle openbare Azure-regio's worden ondersteund

De oplossing biedt geen ondersteuning voor de volgende scenario's, functies en technologie in de release:

  • IaaS-VM's in de Basic-laag
  • Versleuteling uitschakelen op een besturingssysteemstation voor Linux IaaS-VM's
  • IaaS-VM's die worden gemaakt met behulp van de klassieke VM-aanmaakmethode
  • Integratie met uw on-premises sleutelbeheerservice
  • Azure Files (gedeeld bestandssysteem), Network File System (NFS), dynamische volumes en Windows-VM's die zijn geconfigureerd met raid-systemen op basis van software

SQL Database isolatie

SQL Database is een relationele database-service in de Microsoft Cloud op basis van de toonaangevende Microsoft SQL Server-engine en is in staat bedrijfskritieke workloads af te handelen. SQL Database biedt voorspelbare gegevensisolatie op accountniveau, geografie/regio op basis van netwerken, allemaal met bijna nul beheer.

SQL Database toepassingsmodel

Microsoft SQL Database is een relationele databaseservice in de cloud die is gebaseerd op SQL Server technologieën. Het biedt een maximaal beschikbare, schaalbare databaseservice met meerdere tenants die wordt gehost door Microsoft in de cloud.

Vanuit het perspectief van een toepassing biedt SQL Database de volgende hiërarchie: Elk niveau heeft een-op-veel-in-veel-in-op-bevatten van niveaus hieronder.

SQL Database toepassingsmodel

Het account en abonnement zijn microsoft Azure-platformconcepten om facturering en beheer te koppelen.

Logische SQL-servers en -databases zijn SQL Database-specifieke concepten en worden beheerd met behulp van SQL Database, geleverde OData- en TSQL-interfaces of via de Azure Portal.

Servers in SQL Database zijn geen fysieke of VM-exemplaren, in plaats daarvan zijn ze verzamelingen van databases, beheer- en beveiligingsbeleidsregels, die worden opgeslagen in de zogenaamde 'logische hoofddatabase'.

SQL Database

Logische hoofddatabases zijn onder andere:

  • SQL-aanmeldingen die worden gebruikt om verbinding te maken met de server
  • Firewall-regels

Facturerings- en gebruiksgerelateerde informatie voor databases van dezelfde server is niet gegarandeerd op hetzelfde fysieke exemplaar in het cluster. In plaats daarvan moeten toepassingen de naam van de doeldatabase opgeven wanneer er verbinding wordt gemaakt.

Vanuit het perspectief van een klant wordt een server gemaakt in een geografisch grafische regio terwijl het daadwerkelijk maken van de server plaatsvindt in een van de clusters in de regio.

Isolatie via netwerktopologie

Wanneer een server wordt gemaakt en de DNS-naam is geregistreerd, verwijst de DNS-naam naar het zogenaamde 'Gateway VIP'-adres in het specifieke datacenter waar de server is geplaatst.

Achter het VIP (virtueel IP-adres) hebben we een verzameling staatloze gatewayservices. Over het algemeen worden gateways betrokken wanneer er coördinatie nodig is tussen meerdere gegevensbronnen (hoofddatabase, gebruikersdatabase, enzovoort). Gatewayservices implementeren het volgende:

  • TDS-verbindingsproxy. Dit omvat het vinden van gebruikersdatabases in het back-endcluster, het implementeren van de aanmeldingsreeks en het doorsturen van de TDS-pakketten naar de back-end en terug.
  • Databasebeheer. Dit omvat het implementeren van een verzameling werkstromen voor het uitvoeren van CREATE/ALTER/DROP-databasebewerkingen. De databasebewerkingen kunnen worden aangeroepen door TDS-pakketten of expliciete OData-API's te snuiven.
  • CREATE/ALTER/DROP login/user operations
  • Serverbeheerbewerkingen via OData-API

Isolatie via netwerktopologie

De laag achter de gateways wordt 'back-end' genoemd. Hier worden alle gegevens opgeslagen op een maximaal beschikbare manier. Elk stukje gegevens wordt gezegd dat ze deel uitmaken van een 'partitie' of 'failover-eenheid', elk van hen met ten minste drie replica's. Replica's worden opgeslagen en gerepliceerd door SQL Server engine en beheerd door een failoversysteem, ook wel 'fabric' genoemd.

Over het algemeen communiceert het back-endsysteem niet uitgaand naar andere systemen als voorzorgsmaatregel. Dit is gereserveerd voor de systemen in de front-endlaag (gateway). De machines in de gatewaylaag hebben beperkte bevoegdheden op de back-endcomputers om het kwetsbaarheid voor aanvallen als een diepgaande verdedigingsmechanisme te minimaliseren.

Isolatie per machinefunctie en toegang

SQL Database (bestaat uit services die worden uitgevoerd op verschillende computerfuncties. SQL Database is onderverdeeld in 'back-end'-clouddatabase- en 'front-end'-omgevingen (gateway/beheer), waarbij het algemene principe van verkeer alleen naar back-end gaat en niet naar buiten. De front-endomgeving kan communiceren met de buitenwereld van andere services en in het algemeen heeft slechts beperkte machtigingen in de back-end (voldoende om de toegangspunten aan te roepen die moeten worden aangeroepen).

Netwerkisolatie

Azure-implementatie heeft meerdere lagen netwerkisolatie. In het volgende diagram ziet u verschillende lagen netwerkisolatie die Azure biedt aan klanten. Deze lagen zijn zowel systeemeigen in het Azure-platform zelf als door de klant gedefinieerde functies. Binnenkomend vanaf internet biedt Azure DDoS isolatie tegen grootschalige aanvallen tegen Azure. De volgende isolatielaag is door de klant gedefinieerde openbare IP-adressen (eindpunten), die worden gebruikt om te bepalen welk verkeer via de cloudservice naar het virtuele netwerk kan worden doorgegeven. Systeemeigen isolatie van virtuele Azure-netwerken zorgt voor volledige isolatie van alle andere netwerken en dat verkeer alleen via door de gebruiker geconfigureerde paden en methoden stroomt. Deze paden en methoden zijn de volgende laag, waarbij NSG's, UDR en virtuele netwerkapparaten kunnen worden gebruikt om isolatiegrenzen te maken om de toepassingsimplementaties in het beveiligde netwerk te beveiligen.

Netwerkisolatie

Verkeersisolatie: Een virtueel netwerk is de grens voor verkeersisolatie op het Azure-platform. Virtuele machines (VM's) in één virtueel netwerk kunnen niet rechtstreeks communiceren met VM's in een ander virtueel netwerk, zelfs als beide virtuele netwerken door dezelfde klant worden gemaakt. Isolatie is een kritieke eigenschap die ervoor zorgt dat klant-VM's en communicatie privé blijven binnen een virtueel netwerk.

Subnet biedt een extra isolatielaag met in een virtueel netwerk op basis van IP-bereik. IP-adressen in het virtuele netwerk kunt u een virtueel netwerk verdelen in meerdere subnetten voor organisatie en beveiliging. Tussen VM's en PaaS-rolexemplaren die in (dezelfde of verschillende) subnetten in een VNET zijn geïmplementeerd, is communicatie mogelijk zonder extra configuratie. U kunt netwerkbeveiligingsgroep (NSG's) ook configureren om netwerkverkeer naar een VM-exemplaar toe te staan of te weigeren op basis van regels die zijn geconfigureerd in de toegangsbeheerlijst (ACL) van NSG. NSG's kunnen worden gekoppeld aan subnetten of afzonderlijke VM-exemplaren in dat subnet. Als een NSG is gekoppeld aan een subnet, zijn de ACL-regels van toepassing op alle VM-exemplaren in dat subnet.

Volgende stappen