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 motivaties voor het uitvoeren van toepassingen in een cloudomgeving is de mogelijkheid om de kosten van gedeelde resources over meerdere klanten te verdelen. 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 tot een willekeurige en mogelijk kwaadwillende gebruiker behoren.

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 talloze 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 ondersteuning voor Azure s beveiliging, vertrouwelijkheid, privacy, integriteit en beschikbaarheidsstandaarden.

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 Microsoft Entra-id dat uw organisatie ontvangt en eigenaar is wanneer deze zich registreert voor een Microsoft-cloudservice.

Elke Microsoft Entra-directory is uniek en gescheiden van andere Microsoft Entra-directory's. Net als een bedrijfskantoorgebouw is een veilige asset die specifiek is voor alleen uw organisatie, is een Microsoft Entra-adreslijst ook ontworpen als een veilige asset voor gebruik door alleen uw organisatie. De Microsoft Entra-architectuur isoleert klantgegevens en identiteitsgegevens van co-mingling. Dit betekent dat gebruikers en beheerders van een Microsoft Entra-directory niet per ongeluk of kwaadwillend toegang hebben tot gegevens in een andere map.

Azure Tenancy

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

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

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

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

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

• Fysieke toegang tot servers die de Microsoft Entra-service vormen en directe toegang tot de back-endsystemen van Microsoft Entra ID is beperkt.

• Microsoft Entra-gebruikers hebben geen toegang tot fysieke assets of locaties en daarom is het niet mogelijk om de logische Azure RBAC-beleidscontroles te omzeilen die hieronder worden vermeld.

Voor diagnostische gegevens en onderhoudsbehoeften is een operationeel model dat gebruikmaakt van een Just-In-Time privilege-uitbreidingssysteem vereist en gebruikt. Microsoft Entra 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.

Microsoft Entra ID 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 ingesleten in de adreslijstservice in alle lagen, van portals tot permanente opslag.

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

op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC)

Met op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) kunt u verschillende onderdelen delen die beschikbaar zijn binnen een Azure-abonnement door gedetailleerd toegangsbeheer voor Azure te bieden. Met Azure RBAC kunt u taken in 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:

• 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.

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 biedt ze geen toegang tot het virtuele Azure-netwerk 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 bouwt in Azure RBAC.

Enkele andere mogelijkheden voor Microsoft Entra ID zijn:

• Met Microsoft Entra ID kan eenmalige aanmelding worden ingeschakeld voor SaaS-toepassingen, ongeacht waar ze worden gehost. Sommige toepassingen zijn gefedereerd met Microsoft Entra-id en andere maken gebruik van eenmalige aanmelding met een wachtwoord. 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).

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

• Voor meervoudige verificatie van Microsoft Entra moeten gebruikers aanmeldingen verifiëren met behulp van een mobiele app, telefoongesprek of sms-bericht. Het kan worden gebruikt met Microsoft Entra ID om on-premises resources te beveiligen met de Multi-Factor Authentication-server, en ook met aangepaste toepassingen en mappen met behulp van de SDK.

• Met Microsoft Entra 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 consumenten kunnen zich aanmelden bij al uw toepassingen via aanpasbare ervaringen met behulp van hun bestaande sociale accounts of door referenties te maken.

Isolatie van Microsoft Beheer istrators en gegevensverwijdering

Microsoft neemt sterke maatregelen om uw gegevens te beschermen tegen ongepaste toegang of het 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 beheren.

• Microsoft-technici hebben geen standaardtoegang tot uw gegevens in de cloud. In plaats daarvan krijgen ze alleen toegang, onder beheertoezicht, 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 namens hen beperkte services te leveren. Onderaannemers hebben alleen toegang tot klantgegevens om de services te leveren waarvoor we 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 gegevens 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 kunt altijd en om welke reden dan ook altijd toegang krijgen tot uw eigen klantgegevens.

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

Als een schijfstation dat wordt gebruikt voor opslag een hardwarefout ondervindt, wordt het veilig gewist of vernietigd voordat Microsoft het naar de fabrikant retourneert 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.

Isolatie van rekenkracht

Microsoft Azure biedt verschillende cloudcomputingservices die een brede selectie rekeninstanties en -services bevatten die automatisch omhoog en omlaag kunnen worden geschaald om te voldoen aan de behoeften van uw toepassing of onderneming. Deze rekeninstanties en -services bieden isolatie op meerdere niveaus om gegevens te beveiligen zonder dat dit ten koste gaat van de flexibiliteit in de configuratie die klanten nodig hebben.

Geïsoleerde grootten van virtuele machines

Azure Compute biedt formaten virtuele machines die zijn geïsoleerd voor een specifiek hardwaretype en bedoeld voor een enkele klant. De geïsoleerde grootten leven en werken op specifieke hardwaregeneratie en worden afgeschaft wanneer de hardwaregeneratie buiten gebruik wordt gesteld of als er nieuwe hardwaregeneratie beschikbaar is.

Geïsoleerde grootten van virtuele machines zijn het meest geschikt voor workloads die een hoge mate van isolatie van workloads van andere klanten vereisen. Dit is soms vereist om te 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.

Daarnaast 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 vanwege hardwareafname.

Afschaffing van geïsoleerde VM-grootten

Geïsoleerde VM-grootten hebben een beperkte levensduur van de hardware. Azure geeft herinneringen van 12 maanden voor de officiële afschaffingsdatum van de grootten en biedt een bijgewerkte geïsoleerde aanbieding voor uw overweging. De volgende grootten hebben aangekondigd dat ze buiten gebruik worden gesteld.

Tekengrootte	Buitengebruikstellingsdatum van isolatie
Standard_DS15_v2	zaterdag 15 mei 2021
Standard_D15_v2	zaterdag 15 mei 2021
Standard_G5	dinsdag 15 februari 2022
Standard_GS5	dinsdag 15 februari 2022
Standard_E64i_v3	dinsdag 15 februari 2022
Standard_E64is_v3	dinsdag 15 februari 2022
Standard_M192is_v2	31 maart 2027
Standard_M192ims_v2	31 maart 2027
Standard_M192ids_v2	31 maart 2027
Standard_M192idms_v2	31 maart 2027

Veelgestelde vragen

V: Wordt de grootte buiten gebruik gesteld of wordt alleen de functie 'isolatie' ervan gebruikt?

A: Elke grootte die is gepubliceerd als geïsoleerd, maar geen 'i' in de naam heeft, wordt de isolatiefunctie van de VM-grootten buiten gebruik gesteld, tenzij anders gecommuniceerd. Grootten met 'i' in de naam worden afgeschaft.

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

A: Voor VM-grootten, waarbij alleen isolatie wordt afgeschaft, maar niet de grootte, is er geen actie nodig en is er geen downtime. In tegenstelling tot als isolatie vereist is, bevat de aankondiging de aanbevolen vervangingsgrootte. Als u de vervangingsgrootte selecteert, moeten klanten het formaat 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: Wij geven 12 maanden voor de officiële afschaffing van de geïsoleerde grootte herinneringen. Onze nieuwste 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 buiten gebruik stellen?

A:

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

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

V: Wat zijn de mijlpalen voor G5, Gs5, E64i_v3 en E64is_v3 isolatie buiten gebruik stellen?

A:

Datum	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

¹ 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 verdelen 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 je 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.

Isolatie van hyper-V en hoofdbesturingssysteem tussen hoofd-VM's en gast-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 over de hardware wordt uitgevoerd en een knooppunt opsplitst in een variabel aantal gast-VM's (Virtual Machines).

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 meer recent leren van De 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 algoritme voor plaatsing van vm's en beveiliging tegen side channel-aanvallen

Elke aanval tussen VM's bestaat uit twee stappen: het plaatsen van een door kwaadwillend bestuurde VIRTUELE machine 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 hebzucht of vm' s. 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 ruis-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 vm-plaatsingsalgoritmen van de Azure-infrastructuurcontroller zijn zeer geavanceerd en bijna onmogelijk om te voorspellen als fysiek hostniveau.

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 side channel-aanvallen op VM-niveau.

In Azure is de hoofd-VM speciaal: het voert een beveiligd besturingssysteem uit met de naam van het hoofdbesturingssysteem dat als host fungeert voor een infrastructuuragent (FA). CA's worden op hun beurt gebruikt voor het beheren van gastagents (GA) binnen gastbesturingssystemen op klant-VM's. VA'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 GA's, die de toepassing van de configuratiewijziging melden. In het geval van een hardwarefout vindt de FC automatisch beschikbare hardware en start de VIRTUELE machine daar opnieuw op.

Communicatie van een infrastructuurcontroller naar een agent is unidirectioneel. De agent implementeert een met SSL beveiligde service die alleen reageert op aanvragen van de controller. Er kunnen geen verbindingen worden gestart met de controller of andere bevoegde interne knooppunten. De FC behandelt alle reacties alsof ze niet vertrouwd waren.

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 netwerkpakket- 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 leiden 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:

• Computerconfiguratie- of infrastructuurregels: standaard wordt alle communicatie geblokkeerd. Er zijn uitzonderingen waarmee een virtuele machine DHCP- en DNS-verkeer kan verzenden en ontvangen. Virtuele machines kunnen ook verkeer verzenden naar het openbare internet en verkeer verzenden naar andere virtuele machines binnen hetzelfde Virtuele Azure-netwerk en de activeringsserver van het besturingssysteem. De lijst met toegestane uitgaande bestemmingen van de virtuele machines bevat geen Azure-routersubnetten, Azure-beheer en andere Microsoft-eigenschappen.
• Rolconfiguratiebestand: Hiermee definieert u de inkomende toegangsbeheerlijsten (ACL's) op basis van het servicemodel van de tenant.

VLAN-isolatie

Er zijn drie VLAN's in elk cluster:

• Het belangrijkste VLAN : verbindt niet-vertrouwde klantknooppunten
• Het FC VLAN – bevat vertrouwde FCS's en ondersteunende systemen
• Het VLAN van het apparaat: bevat een vertrouwd 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 waarop klantcode wordt uitgevoerd, geen knooppunten kan aanvallen op de VLAN's van het FC- of apparaat.

Opslagisolatie

Logische isolatie tussen compute en opslag

Als onderdeel van het fundamentele ontwerp scheidt Microsoft Azure de berekening op basis van VM's van opslag. Dankzij 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 netwerkconnectiviteit 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 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

Toegangsbeheer 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.

Toegang tot Azure Storage-gegevens (inclusief tabellen) kan worden beheerd via een SAS-token (Shared Access Signature), dat toegang verleent binnen het bereik. 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 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 aan clients zonder de geheime sleutel van het opslagaccount weer te geven.

De SAS betekent dat we een client beperkte machtigingen kunnen verlenen aan objecten in ons opslagaccount gedurende een opgegeven periode en met een opgegeven set machtigingen. We kunnen deze beperkte machtigingen verlenen zonder dat u toegangssleutels voor uw account hoeft te 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 via netwerken worden verzonden. Met Azure Storage kunt u gegevens beveiligen met behulp van:

• Versleuteling op transportniveau, zoals HTTPS wanneer u gegevens overdraagt naar of uit Azure Storage.
• Kabelversleuteling, zoals SMB 3.0-versleuteling voor Azure-bestandsshares.
• Versleuteling aan de clientzijde om de gegevens te versleutelen voordat ze worden overgebracht naar de opslag en om de gegevens te ontsleutelen nadat deze buiten de opslag zijn overgebracht.

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:

• Met Storage Service Encryption kunt u aanvragen dat de opslagservice automatisch gegevens versleutelt bij het schrijven naar Azure Storage.
• Versleuteling aan de clientzijde biedt ook de functie van versleuteling-at-rest .
• Azure Disk Encryption voor Linux-VM's en Azure Disk Encryption voor Windows-VM's.

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 voldoen aan de beveiligings- en nalevingsvereisten van de organisatie 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 reeks
• Versleuteling inschakelen op Windows- en Linux IaaS-VM's
• 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 het Windows-clientbesturingssysteem wordt uitgevoerd
• Versleuteling inschakelen op 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 methode voor het maken van vm's
• Integratie met uw on-premises sleutelbeheerservice
• Azure Files (gedeeld bestandssysteem), Network File System (NFS), dynamische volumes en Windows-VM's die zijn geconfigureerd met op software gebaseerde RAID-systemen

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 gebouwd 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 bevat een-op-veel-in-veel-in-een-op-een niveaus die eronder staan.

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, opgegeven OData- en TSQL-interfaces of via Azure Portal.

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

Logische hoofddatabases zijn onder andere:

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

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 klantperspectief wordt een server gemaakt in een geografisch grafische regio terwijl het maken van de server daadwerkelijk 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 VIP-adres van de gateway in het specifieke datacenter waar de server is geplaatst.

Achter het VIP (virtueel IP-adres) hebben we een verzameling stateless 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 de gebruikersdatabase 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

De laag achter de gateways wordt 'back-end' genoemd. Hier worden alle gegevens op een maximaal beschikbare manier opgeslagen. Elk stukje gegevens wordt gezegd dat ze behoren tot een 'partitie' of 'failover-eenheid', elk van hen met ten minste drie replica's. Replica's worden opgeslagen en gerepliceerd door de SQL Server-engine en beheerd door een failoversysteem dat vaak 'fabric' wordt 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 gatewaylaagmachines hebben beperkte bevoegdheden op de back-endcomputers om de kwetsbaarheid voor aanvallen te minimaliseren als een diepgaande verdedigingsmechanisme.

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-endomgevingen (gateway/beheer), met het algemene principe van verkeer dat alleen naar de back-end gaat en niet naar buiten gaat. De front-endomgeving kan communiceren met de buitenwereld van andere services en heeft in het algemeen 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 van 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.

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é blijft binnen een virtueel netwerk.

Subnet biedt een extra isolatielaag met in het virtuele 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 ook netwerkbeveiligingsgroep (NSG's) 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

• Meer informatie over netwerkisolatieopties voor machines in Virtuele Windows Azure-netwerken. Dit omvat het klassieke front-end- en back-endscenario waarbij machines in een bepaald back-endnetwerk of subnetwerk alleen toestaan dat bepaalde clients of andere computers verbinding maken met een bepaald eindpunt op basis van een acceptatielijst met IP-adressen.

• Meer informatie over isolatie van virtuele machines in Azure. Azure Compute biedt grootten van virtuele machines die zijn geïsoleerd voor een specifiek hardwaretype en toegewezen aan één klant.