Isolatie in de Azure openbare cloud

Azure helpt je bij het draaien van applicaties en virtuele machines (VM's) op gedeelde fysieke infrastructuur. Een van de belangrijkste economische voordelen van het draaien van applicaties in een cloudomgeving is de mogelijkheid om de kosten van gedeelde resources te verdelen over meerdere tenants. Deze multitenancy-praktijk verbetert de efficiëntie door middelen tegen lage kosten tussen verschillende huurders te multiplexen. Het brengt echter ook het risico met zich mee dat fysieke servers en andere infrastructuurbronnen worden gedeeld om je gevoelige applicaties en VM's te draaien die mogelijk toebehoren aan een willekeurige en mogelijk kwaadaardige gebruiker.

Dit artikel beschrijft hoe Azure isolatie biedt tegen zowel kwaadwillende als niet-kwaadwillende gebruikers. Het dient als gids voor het ontwerpen van cloudoplossingen door verschillende isolatieopties aan architecten te bieden.

Isolatie op tenantniveau

Een van de belangrijkste voordelen van cloud computing is het concept van gedeelde, gemeenschappelijke infrastructuur over meerdere tenants tegelijk, wat leidt tot schaalvoordeel. Dit concept wordt multitenancy genoemd. Microsoft werkt continu om ervoor te zorgen dat de multitenant-architectuur van Microsoft Azure beveiligings-, vertrouwelijkheids-, privacy-, integriteits- en beschikbaarheidsstandaarden ondersteunt.

In de cloudomgeving is een tenant een client of organisatie die eigenaar is van en beheert een specifiek exemplaar van die cloudservice. In het identiteitsplatform van Microsoft Azure is een tenant een toegewijde instantie van Microsoft Entra ID die uw organisatie ontvangt en bezit wanneer zij zich aanmeldt voor een Microsoft clouddienst.

Elke Microsoft Entra-directory is uniek en gescheiden van andere Microsoft Entra-directory's. Net als een kantoorgebouw is een Microsoft Entra-directory een veilig hulpmiddel dat alleen door jouw organisatie gebruikt kan worden. De Microsoft Entra-architectuur isoleert klantgegevens en identiteitsgegevens om samenvoeging te voorkomen. Deze isolatie betekent dat gebruikers en beheerders van één Microsoft Entra-directory niet per ongeluk of kwaadwillig toegang kunnen krijgen tot gegevens in een andere directory.

Azure-abonnement

Azure-tenancy (Azure-abonnement) verwijst naar een klant- en factureringsrelatie en een unieke tenant in Microsoft Entra ID. Microsoft Entra ID en zijn Azure rolgebaseerde toegangscontrole bieden tenant-niveau isolatie in Microsoft Azure. Elk Azure-abonnement is gekoppeld aan één Microsoft Entra-map.

Gebruikers, groepen en toepassingen uit die directory kunnen resources beheren in het Azure-abonnement. Wijs deze toegangsrechten toe door gebruik te maken van het Azure-portaal, Azure-commandoregeltools en Azure Management API's. Beveiligingsgrenzen isoleren logisch een Microsoft Entra-tenant, zodat geen enkele klant toegang kan verkrijgen tot of co-tenants in gevaar kan brengen, hetzij kwaadwillend 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.

• Access naar gegevens in Microsoft Entra ID vereist gebruikersverificatie via een beveiligingstokenservice (STS). Het autorisatiesysteem gebruikt informatie over het bestaan, de actieve status en de rol van de gebruiker om te bepalen of deze gebruiker in deze sessie geautoriseerde toegang heeft tot de doeltenant.

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

• Er bestaat geen access tussen tenants, tenzij een tenantbeheerder deze verleent via federatie of door gebruikersaccounts van andere tenants in te richten.

• Microsoft beperkt fysieke toegang tot servers die deel uitmaken van de Microsoft Entra-dienst en directe toegang tot de back-end systemen van Microsoft Entra ID.

• Microsoft Entra-gebruikers hebben geen toegang tot fysieke assets of locaties, dus ze kunnen de logische Azure RBAC-beleidscontroles zoals hieronder vermeld niet omzeilen.

Voor diagnostiek en onderhoudsbehoeften gebruikt u een operationeel model dat gebruikmaakt van een just-in-time systeem voor het verhogen van bevoegdheden. Microsoft Entra Privileged Identity Management (PIM) introduceert het concept van een in aanmerking komende beheerder. In aanmerking komende beheerders zijn gebruikers die af en toe bevoorrechte toegang nodig hebben, maar niet elke dag. De rol is inactief totdat de gebruiker toegang nodig heeft. De gebruiker voltooit vervolgens een activatieproces en wordt een actieve beheerder voor een vooraf bepaalde tijd.

Microsoft Entra ID fungeert als host voor 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 op alle lagen, van portals tot permanente storage.

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

Azure op rollen gebaseerde toegangsbeheer (Azure RBAC)

Azure rolgebaseerde toegangscontrole (Azure RBAC) helpt je om verschillende componenten binnen een Azure-abonnement te delen door fijnmazig toegangsbeheer voor Azure te bieden. Azure RBAC stelt u in staat taken binnen uw organisatie te scheiden en access te 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:

• Owner heeft volledige access voor alle resources, inclusief het recht om access aan anderen te delegeren.

• Contributor kunnen alle typen Azure resources maken en beheren, maar kunnen access niet aan anderen verlenen.

• Reader kunt bestaande Azure resources bekijken.

De rest van de Azure rollen in Azure het beheer van specifieke Azure resources toestaan. Met de rol Inzender voor virtuele machines kan de gebruiker bijvoorbeeld virtual machines maken en beheren. Het geeft ze geen access aan de Azure Virtual Network of het subnet waarmee de virtuele machine verbinding maakt.

Azure ingebouwde rollen vermeld de rollen die beschikbaar zijn in Azure. Ze geven 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 Custom-rollen bouwt in Azure RBAC.

Enkele andere mogelijkheden voor Microsoft Entra ID zijn:

• Microsoft Entra ID maakt eenmalige aanmelding mogelijk voor SaaS-toepassingen, ongeacht waar ze worden gehost. Sommige toepassingen worden gefedereerd met Microsoft Entra ID en andere toepassingen gebruiken eenmalige aanmelding met een wachtwoord. Federatieve toepassingen kunnen ook ondersteuning bieden voor gebruikersinrichting en wachtwoordkluis.

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

• Voor meervoudige verificatie van Microsoft Entra moeten gebruikers aanmeldingen verifiëren met behulp van een mobiele app, telefoongesprek of sms-bericht. Gebruik het met Microsoft Entra ID om on-premises resources te beveiligen door gebruik te maken van de Multi-Factor Authentication Server, en ook met aangepaste applicaties en mappen via de SDK.

• Microsoft Entra Domeinservices helpt je Azure virtuele machines aan een Active Directory-domein te koppelen zonder domeincontrollers te hoeven uitzenden. U kunt zich aanmelden bij deze virtual machines met uw bedrijfsreferenties Active Directory en domein-gekoppelde virtual machines beheren met behulp van Group Policy om beveiligingsbasislijnen af te dwingen voor al uw Azure virtual machines.

• Microsoft Entra Externe id is een zeer beschikbaar wereldwijde identiteitsbeheerdienst voor consumentgerichte applicaties die schaalt naar honderden miljoenen identiteiten. Je kunt het integreren over mobiele en 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-beheerders en gegevensverwijdering

Microsoft neemt sterke maatregelen om uw gegevens te beschermen tegen ongepaste access of gebruik door onbevoegden. De Online Services Voorwaarden bieden contractuele toezeggingen die van toepassing zijn op toegang tot uw gegevens en deze operationele processen en controles ondersteunen.

• Microsoft-technici hebben geen standaard access voor uw gegevens in de cloud. In plaats daarvan krijgen ze toegang onder beheertoezicht, alleen wanneer dat nodig is. Die toegang wordt zorgvuldig gecontroleerd en vastgelegd en ingetrokken wanneer die niet meer nodig is.
• Microsoft kan andere bedrijven inhuren om namens hen beperkte services te leveren. Onderaannemers kunnen alleen klantgegevens access om de services te leveren waarvoor Microsoft hen heeft ingehuurd 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 klanten.

Microsoft en erkende auditbureaus controleren regelmatig bedrijfsservices met gecontroleerde certificeringen zoals ISO/IEC 27001. Deze auditors voeren voorbeeldcontroles uit om te bevestigen dat access alleen voor legitieme zakelijke doeleinden is. U kunt altijd en om welke reden dan ook toegang krijgen tot uw eigen klantgegevens.

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

Als een schijfstation dat wordt gebruikt voor opslag een hardwarefout ondervindt, wist of vernietigt Microsoft de schijf voordat de schijf naar de fabrikant wordt geretourneerd voor vervanging of reparatie. Microsoft overschrijft de gegevens op de schijf om ervoor te zorgen dat niemand de data op welke manier dan ook kan terughalen.

Computerisolatie

Microsoft Azure biedt verschillende cloudgebaseerde computingservices met een brede selectie rekeninstanties en -services die automatisch omhoog en omlaag kunnen worden geschaald om te voldoen aan de behoeften van uw toepassing of onderneming. Deze rekeninstanties en -diensten bieden isolatie op meerdere niveaus om data te beveiligen zonder concessies te doen aan de configuratieflexibiliteit die organisaties eisen.

Geïsoleerde afmetingen van virtuele machines

Azure Compute biedt grootten van virtuele machines die zijn geïsoleerd voor een specifiek hardwaretype en toegewezen aan één klant. De geïsoleerde groottes werken op specifieke hardwaregeneraties. Azure stelt deze grootten buiten gebruik wanneer de hardwaregeneratie met pensioen gaat of wanneer er een nieuwe hardwaregeneratie beschikbaar komt.

Geïsoleerde virtuele machinegroottes zijn het meest geschikt voor workloads die een hoge mate van isolatie van de workloads van andere tenants vereisen. Deze isolatie is soms nodig om te voldoen aan nalevings- en regelgevingsvereisten. Het gebruik van een geïsoleerde grootte garandeert dat je virtuele machine de enige is die op die specifieke serverinstantie draait.

Omdat geïsoleerde VM's groot zijn, kun je ervoor kiezen hun resources te onderverdelen door ondersteuning voor Azure te gebruiken voor geneste virtuele machines.

De huidige geïsoleerde virtuele machines omvatten:

• Standard_E192is_v6
• Standard_E192ids_v6
• Standard_E104i_v5
• Standard_E104id_v5
• Standard_E104is_v5
• Standard_E104ids_v5
• Standard_E112ias_v5
• Standard_E112iads_v5
• Standard_E80is_v4
• Standard_E80ids_v4
• Standard_E96ias_v4
• Standard_E112ibs_v5
• Standard_E112ibds_v5
• Standard_EC96ias_v5
• Standard_EC96iads_v5
• Standard_HB120rs_v3
• Standard_HB176rs_v4
• Standard_HB368rs_v5
• Standard_HX176rs
• Standard_M832is_16_v3
• Standard_M832ids_16_v3
• Standard_M192is_v2
• Standard_M192ids_v2
• Standard_M192ims_v2
• Standard_M192idms_v2
• Standard_NC64as_T4_v3
• Standard_NC96ads_A100_v4
• Standard_NC80adis_H100_v5
• Standard_ND128isr_NDR_GB200_v6
• Standard_ND128isr_NDR_GB300_v6
• Standard_ND96isr_H100_v5
• Standard_ND96isr_H200_v5
• Standard_ND96isr_MI300X_v5
• Standard_NG32ads_V620_v1
• Standard_NG32adms_V620_v1
• Standard_NV72ads_A10_v5

Uitfasering van geïsoleerde VM-grootten

Geïsoleerde VM-groottes hebben een hardware-beperkte levensduur. Azure stuurt herinneringen 12 maanden voor de officiële afschaffingsdatum van de formaten en biedt een bijgewerkt geïsoleerd aanbod voor uw beoordeling. Azure kondigde aan dat de volgende grootten worden uitgefaseerd.

Om de middelen van deze geïsoleerde virtuele machines verder te onderverdelen, zie ondersteuning voor Azure for nested virtual machines.

Toegewezen hosts

Naast de geïsoleerde hosts die in de vorige sectie worden beschreven, biedt Azure ook speciale hosts. Azure Dedicated Host is een dienst die fysieke servers levert die één of meer virtuele machines kunnen hosten en toegewijd zijn 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. U implementeert toegewezen hosts in dezelfde datacenters en ze delen hetzelfde netwerk en de onderliggende storage-infrastructuur als andere, niet-geïsoleerde hosts. Zie het gedetailleerde overzicht van Azure toegewezen hosts voor meer informatie.

Hyper-V en isolatie van hoofdbesturingssystemen tussen hoofd-VM's en gast-VM's

Azure rekenplatform is gebaseerd op machinevirtualisatie. Alle klantcode wordt uitgevoerd op een Hyper-V virtuele machine. Op elk Azure knooppunt (of netwerkeindpunt) wordt een hypervisor rechtstreeks over de hardware uitgevoerd en wordt het knooppunt verdeeld in een variabel aantal gast-virtual machines (VM's).

Elk knooppunt heeft ook een speciale hoofd-VM waarop het hostbesturingssysteem wordt uitgevoerd. De hypervisor en het hoofdbesturingssysteem beheren de isolatie van de hoofd-VM van de gast-VM's en de isolatie van de gast-VM's van elkaar. Deze combinatie van hypervisor en root besturingssysteem maakt gebruik van Microsoft's decennialange ervaring in besturingssysteembeveiliging en recentere kennis uit Microsoft's Hyper-V om sterke isolatie van gast-VM's te bieden.

Het Azure-platform maakt gebruik van een gevirtualiseerde omgeving. Gebruikersexemplaren werken als zelfstandige virtual machines die geen access hebben op een fysieke hostserver.

De Azure hypervisor fungeert als een microkernel. Hiermee worden alle hardware-access aanvragen van gast-virtual machines doorgegeven aan de host voor verwerking met behulp van een interface met gedeeld geheugen, VM Bus genoemd. Deze architectuur voorkomt dat gebruikers onbewerkte lees-, schrijf- of uitvoerrechten op het systeem krijgen en vermindert het risico van het delen van systeembronnen.

Het geavanceerde VM-plaatsingsalgoritme en bescherming tegen side-channelaanvallen

Elke cross-VM-aanval omvat twee stappen: het plaatsen van een door de tegenstander gecontroleerde VM op dezelfde host als een van de slachtoffer-VM's, en vervolgens het doorbreken van de isolatiegrens om ofwel gevoelige slachtofferinformatie te stelen of de prestaties te beïnvloeden door resourcediefstal of verstoring. Microsoft Azure biedt bescherming bij beide stappen door gebruik te maken van een geavanceerd algoritme voor vm-plaatsing en beveiliging tegen alle bekende side channel-aanvallen, inclusief lawaaierige vm's.

De Azure fabric-controller

De Azure Fabric Controller wijst infrastructuurresources toe aan tenantworkloads en beheert unidirectionele communicatie van de host naar virtual machines. Het VM-plaatsingsalgoritme is zeer geavanceerd en vrijwel onmogelijk te voorspellen op fysiek hostniveau.

In Azure voert de hoofd-VM een beveiligd besturingssysteem uit met de naam het hoofdbesturingssysteem dat als host fungeert voor een infrastructuuragent (FA). FAs beheren gastagents (GA) binnen gastbesturingssystemen op klant-vm's en beheren ook storagenodes.

De verzameling van Azure hypervisor, hoofdbesturingssysteem/FA en klant-VM's/GA's bestaat uit een rekenknooppunt. Een fabric controller (FC) beheert FA's. De FC bestaat buiten de reken- en storage-knooppunten. Afzonderlijke FC's beheren compute- en storageclusters. Als een klant het configuratiebestand van hun toepassing bijwerkt terwijl het actief is, communiceert de FC met de FA. De FA neemt contact op 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.

De 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. De agent kan geen verbindingen initiëren met de controller of andere bevoorrechte interne knooppunten. De FC behandelt alle reacties alsof ze niet vertrouwd waren.

Isolatie breidt zich uit van de hoofd-VM naar gast-VM's en van de ene gast-VM naar de andere. Rekenknooppunten worden ook geïsoleerd van storage knooppunten voor betere beveiliging.

De hypervisor en het host-besturingssysteem bieden netwerkpakketfilters. Deze filters helpen ervoor te zorgen dat niet-vertrouwde virtual machines geen vervalst verkeer kan genereren of geen verkeer kan ontvangen dat niet aan hen is geadresseerd. Ze leiden verkeer naar beveiligde infrastructuureindpunten en voorkomen dat ongepast broadcast-verkeer wordt verzonden of ontvangen.

Andere regels geconfigureerd door de fabric controller agent om VM te isoleren

Standaard blokkeert Azure al het verkeer wanneer je een virtuele machine aanmaakt. Vervolgens configureert de fabriccontrolleragent het pakketfilter om regels en uitzonderingen toe te voegen om geautoriseerd verkeer toe te staan.

De fabric controller-agent programmeert twee categorieën regels:

• Machineconfiguratie- of infrastructuurregels: Standaard blokkeert Azure alle communicatie. Uitzonderingen toevoegen om toe te staan dat een virtuele machine DHCP- en DNS-verkeer verzendt en ontvangt. Virtual machines kan ook verkeer verzenden naar het openbare internet en verkeer verzenden naar andere virtual machines binnen dezelfde Azure Virtual Network en de activeringsserver van het besturingssysteem. De lijst van toegestane uitgaande bestemmingen voor virtuele machines bevat geen Azure-routersubnetten, Azure-beheer en andere Microsoft-eigenschappen.
• Role-configuratiebestand: Dit bestand definieert de inkomende Access Control lijsten (ACL's) op basis van het servicemodel van de tenant.

VLAN-isolatie

Elk cluster bevat drie VLAN's:

• Het hoofd-VLAN: Verbindt onbetrouwbare klantnodes met elkaar.
• Het FC VLAN: Bevat vertrouwde FC's en ondersteunende systemen.
• Het apparaat-VLAN: Bevat vertrouwde netwerk- en andere infrastructuurapparaten.

Het FC VLAN kan communiceren met het hoofd-VLAN, maar het hoofd-VLAN kan geen communicatie initiëren met het FC VLAN. Het hoofd-VLAN kan ook niet communiceren met het apparaat-VLAN. Deze VLAN-architectuur zorgt ervoor dat zelfs als een node met klantcode wordt gecompromitteerd, deze geen nodes op de FC- of apparaat-VLANs kan aanvallen.

Opslagisolatie

Logische isolatie tussen rekenkracht en storage

Als onderdeel van het fundamentele ontwerp scheidt Microsoft Azure berekeningen op basis van VM's van storage. Dit ontwerp maakt het mogelijk om berekeningen en opslag onafhankelijk op te schalen, waardoor het eenvoudiger wordt om multitenancy en isolatie te bieden.

Daarom wordt Azure Storage uitgevoerd op afzonderlijke hardware zonder netwerkverbinding met Azure Compute, behalve logische connectiviteit. Dit opslagontwerp betekent dat wanneer je een virtuele schijf maakt, het systeem niet de volledige schijfruimte toewijst. In plaats daarvan maakt het systeem een tabel waarmee adressen op de virtuele schijf worden toegewezen aan gebieden op de fysieke schijf. Deze tabel is in eerste instantie leeg. De eerste keer dat u gegevens op de virtuele schijf schrijft, wijst het systeem ruimte toe op de fysieke schijf en plaatst u er een aanwijzer in de tabel.

Isolatie met behulp van storage access control

Access control in Azure Storage maakt gebruik van een eenvoudig access control model. Elk Azure-abonnement kan een of meer storage accounts maken. Elk storage-account heeft één geheime sleutel die u gebruikt om access te beheren voor alle gegevens in dat storage account.

U kunt toegang tot Azure Storage-gegevens (inclusief tabellen) beheren via een SAS-token (Shared Access Signature), waarmee beperkte toegang wordt verleend. U maakt de SAS via een querysjabloon (URL) en ondertekent deze met de SAK (Storage Accountsleutel). Je kunt de ondertekende URL aan een ander proces geven (gedemitteerd). Het gedelegeerde proces kan vervolgens de details van de query invullen en de aanvraag van de storage-service indienen. Met behulp van een SAS kunt u tijdgebaseerde access aan clients verlenen zonder de geheime sleutel van het storage-account weer te geven.

Met de SAS kun je een client beperkte rechten geven op objecten in je opslagaccount voor een bepaalde periode en een bepaalde set rechten. U verleent deze beperkte machtigingen zonder dat u uw account access sleutels hoeft te delen.

IP-niveau opslagisolatie

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

Gebruik een netwerkmechanisme dat een speciale tunnel van verkeer toewijst aan IP-opslag om IP-opslaggegevens te beschermen tegen ongeautoriseerde gebruikers.

Versleuteling

Azure biedt de volgende typen versleuteling om gegevens te beveiligen:

• Versleuteling onderweg
• Versleuteling van gegevens in rusttoestand

Versleuteling onderweg

Met versleuteling tijdens overdracht worden gegevens beschermd wanneer deze via netwerken worden verzonden. Met behulp van Azure Storage kunt u gegevens beveiligen met behulp van:

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

Versleuteling van gegevens in rusttoestand

Voor veel organisaties is data-encryptie in rust een verplichte stap richting gegevensprivacy, naleving en datasoevereiniteit. Azure functies die versleuteling van data-at-rest bieden, zijn onder andere:

• Storage service-encryptie versleutelt data automatisch wanneer deze naar Azure Storage wordt geschreven.
• Client-side encryptie versleutelt data voordat deze in opslag wordt overgezet.
• Versleuteling op host biedt end-to-end-versleuteling voor VM-gegevens.

Versleuteling op de host

Versleuteling op host biedt end-to-end-versleuteling voor uw VM-gegevens door gegevens op vm-hostniveau te versleutelen. Standaard worden door platform beheerde sleutels gebruikt, maar u kunt desgewenst door de klant beheerde sleutels gebruiken die zijn opgeslagen in Azure Key Vault of Azure Key Vault Beheerde HSM wanneer u meer controle nodig hebt.

Versleuteling op host biedt versleuteling aan de serverzijde op vm-hostniveau met behulp van AES 256-versleuteling, wat FIPS 140-2-compatibel is. Deze versleuteling vindt plaats zonder CPU-resources van de VM te verbruiken en biedt end-to-end-versleuteling voor:

• Tijdelijke schijven
• Caches voor het besturingssysteem en de gegevensschijf
• Gegevensstromen naar Azure Storage

Belangrijkste voordelen van versleuteling op host:

• Geen prestatie-impact: Versleuteling vindt plaats op hostniveau zonder gebruik te maken van VM-CPU-bronnen.
• Brede VM-ondersteuning: Ondersteund op de meeste VM-series en -groottes.
• Klantbeheerde sleutels: Optionele integratie met Azure Key Vault of Managed HSM voor sleutelbeheer.
• Standaard platformbeheerde sleutels: Geen extra configuratie nodig voor encryptie.

Zie Versleuteling op host en Overview van opties voor beheerde schijfversleuteling voor meer informatie.

SQL-database-isolatie

Azure SQL Database is een cloudgebaseerde relationele databaseservice gebouwd op de Microsoft SQL Server-engine. Azure SQL Database is een zeer beschikbaare, schaalbare, multitenant databasedienst met voorspelbare data-isolatie op account-, geografie-, regio- en netwerkniveau. De dienst biedt deze database-isolatie met vrijwel geen administratie.

SQL Database-toepassingsmodel

Vanuit het perspectief van een toepassing biedt SQL Database de volgende hiërarchie, waarbij elk niveau een-op-veel relaties heeft met de niveaus eronder.

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

Logische SQL-servers en databases zijn SQL-databasespecifieke concepten. Je beheert ze door gebruik te maken van OData en T-SQL-interfaces via SQL Database, of het Azure-portaal.

Servers in SQL Database zijn geen fysieke of VM-instanties. In plaats daarvan zijn het verzamelingen databases die beheer- en beveiligingsbeleid delen en worden opgeslagen in een zogenaamde logische hoofddatabase.

Logische hoofddatabases zijn onder andere:

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

Facturering en gebruiksgerelateerde informatie voor databases van dezelfde server is niet gegarandeerd op dezelfde fysieke instantie in de cluster. Applicaties moeten bij het verbinden de naam van de doeldatabases opgeven.

Vanuit jouw perspectief maak je een server in een geografisch gebied, maar Azure maakt de server in een van de clusters in die regio.

Isolatie via netwerktopologie

Wanneer je een server aanmaakt en de DNS-naam registreert, verwijst de DNS-naam naar het Gateway VIP-adres in het specifieke datacenter waar je de server plaatst.

Achter het VIP (virtueel IP-adres) bevindt zich een verzameling stateless-gatewaydiensten. In het algemeen worden gateways betrokken wanneer coördinatie nodig is tussen meerdere gegevensbronnen (hoofddatabase, gebruikersdatabase, enzovoort). Gatewayservices implementeren de volgende functies:

• TDS-verbindingsproxy. Deze functie omvat het vinden van de gebruikersdatabase in het back-endcluster, het implementeren van de verificatiereeks en het doorsturen van de TDS-pakketten naar de back-end en terug.
• Databasebeheer. Deze functie omvat het implementeren van een verzameling werkstromen voor het verwerken van databasebewerkingen CREATE, ALTER en DROP. De dienst kan databasebewerkingen aanroepen door TDS-pakketten of expliciete OData-API's te sniffen.
• CREATE-, ALTER- en DROP-verificatie en gebruikersbewerkingen
• Serverbeheerbewerkingen via OData-API

De laag achter de gateways wordt back-end genoemd. De back-end laag slaat alle data op een zeer toegankelijke manier op. Elk stukje gegevens behoort tot een partitie of failover-eenheid en elke partitie heeft ten minste drie replica's. De SQL Server-engine slaat replica's op en repliceert deze, en een failoversysteem wordt vaak aangeduid als fabric beheert deze.

Over het algemeen communiceert het back-endsysteem niet uitgaand naar andere systemen als voorzorgsmaatregel. Azure reserveert uitgaande communicatie aan de systemen in de front-end (gateway) tier. De gateway-tier machines hebben beperkte rechten op de back-end machines. Deze beperking minimaliseert het aanvalsoppervlak als een verdedigingsmechanisme in diepte.

Isolatie per machinefunctie en toegang

SQL Database bestaat uit diensten die op verschillende machinefuncties draaien. SQL Database verdeelt deze diensten in back-end clouddatabase- en front-end gateway- en beheeromgevingen, met het algemene principe dat verkeer alleen naar back-end gaat en niet naar buiten. De front-end omgeving kan communiceren met de buitenwereld van andere services en heeft over het algemeen slechts beperkte rechten in de back-end (genoeg om de toegangspunten aan te roepen die het moet aanroepen).

Netwerkisolatie

Azure-implementaties hebben meerdere lagen van netwerkisolatie. Het volgende diagram toont verschillende lagen van netwerkisolatie die Azure biedt. Deze lagen bevatten native Azure-platformfuncties en door de klant gedefinieerde functies. Binnenkomend van internet biedt Azure DDoS protection isolatie tegen grootschalige aanvallen tegen Azure. De volgende isolatielaag is door de klant gedefinieerde openbare IP-adressen (eindpunten), die u gebruikt om te bepalen welk verkeer via de cloudservice naar de virtual network kan worden doorgegeven. Native Azure virtuele netwerkisolatie zorgt voor volledige isolatie van alle andere netwerken. Verkeer stroomt alleen via door de gebruiker geconfigureerde paden en methoden. Deze paden en methoden vormen de volgende laag, waarbij NSG's, UDR en jij netwerkvirtuele appliances kunnen gebruiken om isolatiegrenzen te creëren om de applicatie-implementaties in het beschermde netwerk te beschermen.

Traffische isolatie: A virtual network is de grens voor verkeersisolatie op het Azure-platform. Virtuele machines (VMs) in een virtueel netwerk kunnen niet rechtstreeks communiceren met VMs in een ander virtueel netwerk, zelfs niet als beide virtuele netwerken door dezelfde klant zijn gemaakt. Isolatie is een cruciale eigenschap die ervoor zorgt dat klant-VM's en communicatie privé blijven binnen een virtueel netwerk.

Een subnet biedt een extra isolatielaag binnen een virtueel netwerk op basis van het IP-bereik. U kunt een virtual network verdelen in meerdere subnetten voor organisatie en beveiliging. VM's en PaaS-rolinstanties die zijn geïmplementeerd in subnetten (hetzelfde of verschillend) binnen een virtual network met elkaar kunnen communiceren zonder extra configuratie. U kunt ook netwerkbeveiligingsgroepen (NSG's) configureren om netwerkverkeer naar een VM-exemplaar toe te staan of te weigeren op basis van beveiligingsregels. U kunt NSG's koppelen aan subnetten of afzonderlijke netwerkinterfaces die zijn gekoppeld aan VM's. Wanneer u een NSG koppelt aan een subnet, zijn de beveiligingsregels van toepassing op alle VM-exemplaren in dat subnet.

Volgende stappen

• Meer informatie over network-beveiligingsgroepen. Netwerkbeveiligingsgroepen filteren netwerkverkeer tussen Azure resources in een virtual network. U kunt verkeer beperken tot subnetten of virtual machines op basis van bron, doel, poort en protocol met behulp van beveiligingsregels.

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