Azure-richtlijnen voor beveiligde isolatie

Microsoft Azure is een platform voor openbare multitenant-cloudservices met hyperscale dat u toegang biedt tot een omgeving met uitgebreide functies met de nieuwste cloudinnovaties zoals kunstmatige intelligentie, machine learning, IoT-services, big data-analyses, intelligente edge en nog veel meer om u te helpen de efficiëntie te vergroten en inzicht te krijgen in uw activiteiten en prestaties.

Een multitenant-cloudplatform impliceert dat meerdere klanttoepassingen en -gegevens worden opgeslagen op dezelfde fysieke hardware. Azure maakt gebruik van logische isolatie om uw toepassingen en gegevens van andere klanten te scheiden. Deze aanpak biedt de schaal en economische voordelen van multitenant-cloudservices, terwijl andere klanten strikt voorkomen dat ze toegang hebben tot uw gegevens of toepassingen.

Azure richt zich op het waargenomen risico van het delen van resources door een betrouwbare basis te bieden voor het garanderen van multitenant, cryptografisch bepaalde, logisch geïsoleerde cloudservices met behulp van een gemeenschappelijke set principes:

1. Besturingselementen voor gebruikerstoegang met verificatie en identiteitsscheiding
2. Rekenisolatie voor verwerking
3. Netwerkisolatie, inclusief gegevensversleuteling tijdens overdracht
4. Opslagisolatie met gegevensversleuteling in rusttoestand
5. Beveiligingscontroleprocessen die zijn ingesloten in serviceontwerp om logisch geïsoleerde services correct te ontwikkelen

Multitenancy in de openbare cloud verbetert de efficiëntie door resources te multiplexen onder verschillende klanten tegen lage kosten; Deze benadering introduceert echter het waargenomen risico dat samenhangt met het delen van resources. Azure lost dit risico op door een betrouwbare basis te bieden voor geïsoleerde cloudservices met behulp van een benadering met meerdere lagen die wordt weergegeven in afbeelding 1.

Afbeelding 1. Azure-isolatiebenaderingen

Hieronder vindt u een korte samenvatting van isolatiemethoden.

• Besturingselementen voor gebruikerstoegang met verificatie en identiteitsscheiding : alle gegevens in Azure, ongeacht het type of de opslaglocatie, zijn gekoppeld aan een abonnement. Een cloudtenant kan worden weergegeven als een toegewezen exemplaar van Microsoft Entra-id dat uw organisatie ontvangt en eigenaar is wanneer u zich registreert voor een Microsoft-cloudservice. De identiteits- en toegangsstack helpt bij het afdwingen van isolatie tussen abonnementen, waaronder het beperken van de toegang tot resources binnen een abonnement alleen voor geautoriseerde gebruikers.

• Rekenisolatie : Azure biedt u zowel logische als fysieke rekenisolatie voor verwerking. Logische isolatie wordt geïmplementeerd via:

  • Hypervisorisolatie voor services die cryptografisch bepaalde isolatie bieden met behulp van afzonderlijke virtuele machines en azure Hypervisor-isolatie.
  • Drawbridge-isolatie binnen een virtuele machine (VM) voor services die cryptografisch bepaalde isolatie bieden voor workloads die op dezelfde virtuele machine worden uitgevoerd met behulp van isolatie die wordt geleverd door Drawbridge. Deze services bieden kleine verwerkingseenheden met behulp van klantcode.
  • Isolatie op basis van gebruikerscontext voor services die uitsluitend bestaan uit door Microsoft beheerde code en klantcode mag niet worden uitgevoerd.
    

  Naast robuuste logische rekenisolatie die standaard beschikbaar is voor alle Azure-tenants, kunt u, als u behoefte hebt aan fysieke rekenisolatie, Gebruikmaken van Azure Dedicated Host of geïsoleerde virtuele machines, die zijn geïmplementeerd op serverhardware die is toegewezen aan één klant.

• Netwerkisolatie : Azure Virtual Network (VNet) helpt ervoor te zorgen dat uw privénetwerkverkeer logisch wordt geïsoleerd van verkeer dat tot andere klanten behoort. Services kunnen communiceren met behulp van openbare IP-adressen of privé-IP-adressen (VNet). Communicatie tussen uw VM's blijft privé binnen een VNet. U kunt uw VNets verbinden via VNet-peering of VPN-gateways, afhankelijk van uw connectiviteitsopties, waaronder bandbreedte, latentie en versleutelingsvereisten. U kunt netwerkbeveiligingsgroepen (NSG's) gebruiken om netwerkisolatie te bereiken en uw Azure-resources te beschermen tegen internet en toegang te krijgen tot Azure-services met openbare eindpunten. U kunt servicetags voor virtueel netwerk gebruiken om netwerktoegangsbeheer te definiëren voor netwerkbeveiligingsgroepen of Azure Firewall. Een servicetag vertegenwoordigt een groep IP-adresvoorvoegsels van een bepaalde Azure-service. Microsoft beheert de adresvoorvoegsels die worden omvat door de servicetag en werkt de servicetag automatisch bij naarmate de adressen veranderen, waardoor de complexiteit van frequente updates voor netwerkbeveiligingsregels wordt verminderd. Bovendien kunt u Private Link gebruiken om toegang te krijgen tot Azure PaaS-services via een privé-eindpunt in uw VNet, zodat verkeer tussen uw VNet en de service via het wereldwijde backbone-netwerk van Microsoft wordt verplaatst, waardoor de service niet meer beschikbaar hoeft te worden gemaakt op het openbare internet. Ten slotte biedt Azure opties voor het versleutelen van gegevens tijdens overdracht, waaronder end-to-end-versleuteling van netwerkverkeer (Transport Layer Security) met TLS-beëindiging met behulp van Key Vault-certificaten, VPN-versleuteling met behulp van IPsec en Azure ExpressRoute-versleuteling met behulp van MACsec met cmk-ondersteuning (door de klant beheerde sleutels).

• Opslagisolatie – Om cryptografische zekerheid van logische gegevensisolatie te garanderen, maakt Azure Storage gebruik van gegevensversleuteling in rust met behulp van geavanceerde algoritmen en meerdere versleutelingsmethoden. Dit proces is afhankelijk van meerdere versleutelingssleutels en -services, zoals Azure Key Vault en Microsoft Entra ID, om veilige toegang tot sleutels en gecentraliseerd sleutelbeheer te garanderen. Azure Storage-serviceversleuteling zorgt ervoor dat gegevens automatisch worden versleuteld voordat ze naar Azure Storage worden bewaard en ontsleuteld voordat ze worden opgehaald. Alle gegevens die naar Azure Storage worden geschreven, worden versleuteld via FIPS 140 gevalideerde 256-bits AES-versleuteling en u kunt Key Vault gebruiken voor door de klant beheerde sleutels (CMK). Versleuteling van de Azure Storage-service versleutelt de pagina blobs die de schijven van virtuele Azure-machines opslaan. Bovendien kan Azure Disk Encryption eventueel worden gebruikt voor het versleutelen van Azure Windows- en Linux IaaS Virtual Machine-schijven om de opslagisolatie te vergroten en cryptografische zekerheid te garanderen van uw gegevens die zijn opgeslagen in Azure. Deze versleuteling omvat beheerde schijven.

• Processen en praktijken voor beveiligingsgarantie – Azure-isolatiegarantie wordt verder afgedwongen door het interne gebruik van de Security Development Lifecycle (SDL) en andere sterke beveiligingsgarantieprocessen om aanvalsvlakken te beschermen en bedreigingen te beperken. Microsoft heeft toonaangevende processen en hulpprogramma's ontwikkeld die een hoge mate van vertrouwen bieden in de azure-isolatiegarantie.

In overeenstemming met het model voor gedeelde verantwoordelijkheid in cloud-computing, terwijl u workloads migreert van uw on-premises datacenter naar de cloud, varieert de afbakening van de verantwoordelijkheid tussen u en de cloudserviceprovider, afhankelijk van het cloudservicemodel. Met het IaaS-model (Infrastructure as a Service) eindigt de verantwoordelijkheid van Microsoft bijvoorbeeld op de hypervisorlaag en bent u verantwoordelijk voor alle lagen boven de virtualisatielaag, inclusief het onderhouden van het basisbesturingssysteem in gast-VM's. U kunt Azure-isolatietechnologieën gebruiken om het gewenste isolatieniveau te bereiken voor uw toepassingen en gegevens die in de cloud zijn geïmplementeerd.

In dit artikel worden belangrijke overwegingen of acties die deel uitmaken van uw verantwoordelijkheid, uiteengezet in kaders. U kunt bijvoorbeeld Azure Key Vault gebruiken om uw geheimen op te slaan, inclusief versleutelingssleutels die onder uw beheer blijven.

Opmerking

Het gebruik van Azure Key Vault voor door de klant beheerde sleutels (CMK) is optioneel en vertegenwoordigt uw verantwoordelijkheid.

Extra resources:

• Aan de slag met Key Vault-certificaten

Dit artikel bevat technische richtlijnen voor het oplossen van veelvoorkomende beveiligings- en isolatieproblemen die relevant zijn voor cloudimplementatie. Het verkent ook ontwerpprincipes en -technologieën die beschikbaar zijn in Azure om u te helpen bij het bereiken van uw veilige isolatiedoelstellingen.

Aanbeveling

Raadpleeg de documentatie van Azure Security Benchmark voor aanbevelingen voor het verbeteren van de beveiliging van toepassingen en gegevens die zijn geïmplementeerd in Azure.

Isolatie op basis van identiteit

Microsoft Entra ID is een identiteitsopslagplaats en cloudservice die verificatie, autorisatie en toegangsbeheer biedt voor uw gebruikers, groepen en objecten. Microsoft Entra ID kan worden gebruikt als een zelfstandige cloudmap of als een geïntegreerde oplossing met bestaande on-premises Active Directory om belangrijke bedrijfsfuncties zoals adreslijstsynchronisatie en eenmalige aanmelding mogelijk te maken.

Elk Azure-abonnement is gekoppeld aan een Microsoft Entra-tenant. Met behulp van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) kunnen gebruikers, groepen en toepassingen uit die directory toegang krijgen tot resources in het Azure-abonnement. Een opslagaccount kan bijvoorbeeld in een resourcegroep worden geplaatst om de toegang tot dat specifieke opslagaccount te beheren met behulp van Microsoft Entra-id. Azure Storage definieert een set ingebouwde Azure-rollen die algemene machtigingen omvatten die worden gebruikt voor toegang tot blob- of wachtrijgegevens. Een aanvraag bij Azure Storage kan worden geautoriseerd met uw Microsoft Entra-account of de sleutel van het opslagaccount. Op deze manier kunnen alleen specifieke gebruikers toegang krijgen tot gegevens in Azure Storage.

Zero Trust-architectuur

Alle gegevens in Azure, ongeacht het type of de opslaglocatie, zijn gekoppeld aan een abonnement. Een cloudtenant kan worden weergegeven als een toegewezen exemplaar van Microsoft Entra-id dat uw organisatie ontvangt en eigenaar is wanneer u zich registreert voor een Microsoft-cloudservice. Verificatie voor Azure Portal wordt uitgevoerd via Microsoft Entra-id met behulp van een identiteit die is gemaakt in Microsoft Entra ID of federatief is met een on-premises Active Directory. De identiteits- en toegangsstack helpt bij het afdwingen van isolatie tussen abonnementen, waaronder het beperken van de toegang tot resources binnen een abonnement alleen voor geautoriseerde gebruikers. Deze toegangsbeperking is een overkoepelend doel van het Zero Trust-model, dat ervan uitgaat dat het netwerk is aangetast en een fundamentele verschuiving van het perimeterbeveiligingsmodel vereist. Bij het evalueren van toegangsaanvragen moeten alle aanvragende gebruikers, apparaten en toepassingen als niet-vertrouwd worden beschouwd totdat hun integriteit kan worden gevalideerd in overeenstemming met de ontwerpprincipes van Zero Trust. Microsoft Entra ID biedt de sterke, adaptieve, op standaarden gebaseerde identiteitsverificatie die is vereist in een Zero Trust-framework.

Opmerking

Extra bronnen:

• Zie het Zero Trust Guidance Center voor meer informatie over het implementeren van Zero Trust-architectuur in Azure.
• Zie NIST SP 800-207Zero Trust Architecture voor definities en algemene implementatiemodellen.

Microsoft Entra ID

De scheiding van de accounts die worden gebruikt voor het beheren van cloudtoepassingen is essentieel voor het bereiken van logische isolatie. Accountisolatie in Azure wordt bereikt met behulp van Microsoft Entra ID en de mogelijkheden ervan ter ondersteuning van gedetailleerd op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). Elk Azure-account is gekoppeld aan één Microsoft Entra-tenant. Gebruikers, groepen en toepassingen uit die directory kunnen resources beheren in Azure. U kunt de juiste toegangsrechten toewijzen met behulp van Azure Portal, Azure-opdrachtregelprogramma's en Azure Management-API's. Elke Microsoft Entra-tenant is uniek en gescheiden van andere Azure-AD's. Een Microsoft Entra-exemplaar is logisch geïsoleerd met behulp van beveiligingsgrenzen om te voorkomen dat klantgegevens en identiteitsgegevens binnenkomen, waardoor gebruikers en beheerders van een Microsoft Entra-id geen toegang hebben tot of inbreuk kunnen maken op gegevens in een ander Microsoft Entra-exemplaar, hetzij kwaadwillig of per ongeluk. Microsoft Entra ID wordt fysiek geïsoleerd uitgevoerd op toegewezen servers die logisch zijn geïsoleerd naar een toegewezen netwerksegment en waarbij pakketfiltering op hostniveau en Windows Firewall-services extra beveiliging bieden tegen niet-vertrouwd verkeer.

Microsoft Entra ID implementeert uitgebreide functies voor gegevensbescherming, waaronder tenantisolatie en toegangsbeheer, gegevensversleuteling tijdens overdracht, geheimenversleuteling en -beheer, versleuteling op schijfniveau, geavanceerde cryptografische algoritmen die worden gebruikt door verschillende Microsoft Entra-onderdelen, operationele overwegingen voor gegevens voor insider-toegang en meer. Gedetailleerde informatie is beschikbaar in een whitepaper Microsoft Entra Data Security Considerations.

Tenantisolatie in Microsoft Entra-id omvat twee primaire elementen:

• Voorkomen van datalekken en toegang over tenants, wat betekent dat gegevens die behoren tot tenant A op geen enkele manier kunnen worden verkregen door gebruikers van tenant B zonder expliciete autorisatie van tenant A.
• Isolatie van resourcetoegang tussen tenants, wat betekent dat bewerkingen die door Tenant A worden uitgevoerd, geen invloed hebben op de toegang tot resources voor Tenant B.

Zoals wordt weergegeven in afbeelding 2, vereist toegang via Microsoft Entra ID gebruikersverificatie via een StS (Security Token Service). Het autorisatiesysteem gebruikt informatie over de aanwezigheid en de ingeschakelde status van de gebruiker via de Directory Services API en Azure RBAC om te bepalen of toegang tot de gerichte Microsoft Entra-instantie is toegestaan tijdens de sessie. Afgezien van verificatie op basis van tokens die rechtstreeks aan de gebruiker is gekoppeld, biedt Microsoft Entra ID verdere ondersteuning voor logische isolatie in Azure via:

• Microsoft Entra-exemplaren zijn afzonderlijke containers en er is geen relatie tussen deze containers.
• Microsoft Entra-gegevens worden opgeslagen in partities en elke partitie heeft een vooraf bepaalde set replica's die worden beschouwd als de voorkeurs primaire replica's. Het gebruik van replica's biedt hoge beschikbaarheid van Microsoft Entra-services ter ondersteuning van identiteitsscheiding en logische isolatie.
• Access is niet toegestaan voor Microsoft Entra-exemplaren, tenzij de beheerder van het Microsoft Entra-exemplaar deze verleent via federatie of inrichting van gebruikersaccounts van andere Microsoft Entra-exemplaren.
• Fysieke toegang tot servers die bestaan uit de Microsoft Entra-service en directe toegang tot de back-endsystemen van Microsoft Entra ID is beperkt tot correct geautoriseerde Operationele Rollen van Microsoft met behulp van het Privileged Access Management System (JIT) van Just-In-Time (JIT).
• Microsoft Entra-gebruikers hebben geen toegang tot fysieke assets of locaties, waardoor het niet mogelijk is om de logische controles van Azure RBAC-beleid te omzeilen.

Afbeelding 2. Isolatie van logische tenants van Microsoft Entra

Kortom, de benadering van Azure voor isolatie van logische tenants maakt gebruik van identiteit, beheerd via Microsoft Entra-id, als de eerste logische controlegrens voor het bieden van toegang op tenantniveau tot resources en autorisatie via Azure RBAC.

Beheer van gegevensversleutelingssleutels

Azure biedt uitgebreide ondersteuning voor het beveiligen van uw gegevens met behulp van gegevensversleuteling, waaronder verschillende versleutelingsmodellen:

• Versleuteling aan de serverzijde die gebruikmaakt van door de service beheerde sleutels, door de klant beheerde sleutels in Azure of door de klant beheerde sleutels op door de klant beheerde hardware.
• Versleuteling aan de clientzijde waarmee u sleutels on-premises of op een andere veilige locatie kunt beheren en opslaan.

Gegevensversleuteling biedt isolatiegaranties die rechtstreeks zijn gekoppeld aan toegang tot versleutelingssleutels (cryptografische sleutels). Omdat Azure sterke coderingen gebruikt voor gegevensversleuteling, hebben alleen entiteiten met toegang tot cryptografische sleutels toegang tot gegevens. Als u cryptografische sleutels verwijdert of weer inroept, worden de bijbehorende gegevens niet toegankelijk. Meer informatie over gegevensversleuteling tijdens overdracht vindt u in de sectie Netwerkisolatie , terwijl gegevensversleuteling in rust wordt behandeld in de sectie Isolatie van opslag .

Met Azure kunt u dubbele versleuteling afdwingen voor zowel data-at-rest als data in transit. Met dit model zijn twee of meer versleutelingslagen ingeschakeld om te beschermen tegen inbreuk op elke versleutelingslaag.

Azure Key Vault

De juiste beveiliging en het juiste beheer van cryptografische sleutels is essentieel voor gegevensbeveiliging. Azure Key Vault is een cloudservice voor het veilig opslaan en beheren van geheimen. De Key Vault-service ondersteunt twee resourcetypen die worden beschreven in de rest van deze sectie:

• Vault ondersteunt met software beveiligde en hardwarebeveiligingsmodule (HSM)-beveiligde geheimen, sleutels en certificaten.
• Beheerde HSM ondersteunt alleen cryptografische sleutels die met HSM zijn beveiligd.

Als u extra beveiliging nodig hebt voor uw meest gevoelige klantgegevens die zijn opgeslagen in Azure-services, kunt u deze versleutelen met uw eigen versleutelingssleutels die u in Key Vault bepaalt.

De Key Vault-service biedt een abstractie van de onderliggende HSM's. Het biedt een REST API voor het inschakelen van servicegebruik vanuit cloudtoepassingen en -verificatie via Microsoft Entra ID , zodat u verificatie, herstel na noodgevallen, hoge beschikbaarheid en elasticiteit kunt centraliseren en aanpassen. Key Vault ondersteunt cryptografische sleutels van verschillende typen, grootten en curven, waaronder RSA- en Elliptic Curve-sleutels. Met beheerde HSM's is ondersteuning ook beschikbaar voor AES-symmetrische sleutels.

Met Key Vault kunt u versleutelingssleutels in HSM's importeren of genereren, zodat sleutels nooit de HSM-beveiligingsgrens verlaten ter ondersteuning van BYOK-scenario's (Bring Your Own Key), zoals wordt weergegeven in afbeelding 3.

Afbeelding 3. Azure Key Vault-ondersteuning voor Bring Your Own Key (BYOK)

Sleutels die worden gegenereerd binnen de Key Vault-HSM's kunnen niet worden geëxporteerd. Er kan geen duidelijke tekstversie van de sleutel buiten de HSM's zijn. Deze koppeling wordt afgedwongen door de onderliggende HSM. De BYOK-functionaliteit is beschikbaar met zowel de -sleutelkluizen als de -beheerde HSM's. Methoden voor het overdragen van met HSM beveiligde sleutels naar Key Vault variëren, afhankelijk van de onderliggende HSM, zoals wordt uitgelegd in de onlinedocumentatie.

Opmerking

Azure Key Vault is zodanig ontworpen, geïmplementeerd en beheerd dat Microsoft en de bijbehorende agents geen toegang hebben tot gegevens die zijn opgeslagen in de service, met inbegrip van cryptografische sleutels, gebruiken of extraheren. Zie Hoe beveiligt Azure Key Vault uw sleutels voor meer informatie?

Key Vault biedt een robuuste oplossing voor levenscyclusbeheer van versleutelingssleutels. Bij het maken wordt elke sleutelkluis of beheerde HSM automatisch gekoppeld aan de Microsoft Entra-tenant die eigenaar is van het abonnement. Iedereen die inhoud probeert te beheren of op te halen uit een sleutelkluis of beheerde HSM, moet correct worden geverifieerd en geautoriseerd:

• Met verificatie wordt de identiteit van de aanroeper (gebruiker of toepassing) vastgesteld.
• Autorisatie bepaalt welke bewerkingen de aanroeper kan uitvoeren, op basis van een combinatie van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) en sleutelkluistoegangsbeleid of beheerde lokale RBAC van HSM.

Microsoft Entra ID dwingt isolatie van tenants af en implementeert robuuste maatregelen om toegang door onbevoegde partijen te voorkomen, zoals eerder beschreven in de sectie Microsoft Entra-id . Toegang tot een sleutelkluis of beheerde HSM wordt beheerd via twee interfaces of vlakken( beheervlak en gegevensvlak) met beide vlakken die gebruikmaken van Microsoft Entra ID voor verificatie.

• Met het beheervlak kunt u de sleutelkluis of beheerde HSM zelf beheren, bijvoorbeeld sleutelkluizen of beheerde HSM's maken en verwijderen, sleutelkluis- of beheerde HSM-eigenschappen ophalen en toegangsbeleid bijwerken. Voor autorisatie gebruikt het beheervlak Azure RBAC in combinatie met zowel sleutelkluizen als beheerde HSM's.
• Met het gegevensvlak kunt u werken met de gegevens die zijn opgeslagen in uw sleutelkluizen en beheerde HSM's, waaronder het toevoegen, verwijderen en wijzigen van uw gegevens. Voor kluizen kunnen opgeslagen gegevens sleutels, geheimen en certificaten bevatten. Voor beheerde HSM's zijn opgeslagen gegevens beperkt tot alleen cryptografische sleutels. Voor autorisatie gebruikt het gegevensvlak Key Vault-toegangsbeleid en Azure RBAC voor bewerkingen van gegevensvlakken met sleutelkluizen of beheerde lokale HSM-RBAC met beheerde HSM's.

Wanneer u een sleutelkluis of beheerde HSM in een Azure-abonnement maakt, wordt deze automatisch gekoppeld aan de Microsoft Entra-tenant van het abonnement. Alle bellers in beide vliegtuigen moeten zich registreren in deze tenant en verifiëren voor toegang tot de sleutelkluis of beheerde HSM.

U beheert de toegangsmachtigingen en kunt gedetailleerde activiteitenlogboeken extraheren uit de Azure Key Vault-service. Azure Key Vault registreert de volgende informatie:

• Alle geverifieerde REST API-aanvragen, inclusief mislukte aanvragen
  • Bewerkingen op de sleutelkluis, zoals het maken, verwijderen, instellen van toegangsbeleid, enzovoort.
  • Bewerkingen voor sleutels en geheimen in de sleutelkluis, waaronder a) het maken, wijzigen of verwijderen van sleutels of geheimen, en b) ondertekening, verifiëren, versleutelen van sleutels, enzovoort.
• Niet-geverifieerde aanvragen, zoals aanvragen die geen Bearer-token hebben, ongeldig of verlopen zijn of een ongeldig token hebben.

Opmerking

Met Azure Key Vault kunt u controleren hoe en wanneer uw sleutelkluizen en beheerde HSM's worden geopend en door wie.

Extra resources:

• Bewaking en waarschuwingen configureren voor Azure Key Vault
• Logboekregistratie inschakelen voor Azure Key Vault
• Opslagaccount beveiligen voor Azure Key Vault-logboeken

U kunt ook de Azure Key Vault-oplossing in Azure Monitor gebruiken om Key Vault-logboeken te controleren. Als u deze oplossing wilt gebruiken, moet u logboekregistratie van Key Vault-diagnostische gegevens inschakelen en de diagnostische gegevens doorsturen naar een Log Analytics-werkruimte. Met deze oplossing is het niet nodig om logboeken naar Azure Blob Storage te schrijven.

Opmerking

Zie de Azure-beveiligingsbasislijn voor Key Vault voor een uitgebreide lijst met aanbevelingen voor Azure Key Vault-beveiliging.

Kluis

Kluizen bieden een multitenant, kosteneffectieve, eenvoudig te gebruiken, zonebestendige (waar beschikbaar) en zeer beschikbare oplossing voor sleutelbeheer die geschikt is voor de meest voorkomende cloudtoepassingsscenario's. Kluizen kunnen geheimen, sleutels en certificaten opslaan en beveiligen. Ze kunnen worden beveiligd met software (standard-laag) of met HSM-beveiliging (Premium-laag). Zie de pagina met prijzen van Azure Key Vault voor een vergelijking tussen de standard- en premium-lagen. Met software beveiligde geheimen, sleutels en certificaten worden beveiligd door Azure, met behulp van industriestandaard algoritmen en sleutellengten. Als u extra garanties nodig hebt, kunt u ervoor kiezen om uw geheimen, sleutels en certificaten te beveiligen in kluizen die worden beveiligd door multitenant HSM's. De bijbehorende HSM's worden gevalideerd volgens de FIPS 140-standaard en hebben een algemene beveiligingsniveau 2-classificatie, waaronder vereisten voor fysiek manipulatiebewijs en verificatie op basis van rollen.

Kluizen bieden ondersteuning voor door de klant beheerde sleutels (CMK), waar u uw eigen sleutels in HSM's kunt beheren en deze kunt gebruiken om data-at-rest te versleutelen voor veel Azure-services. Zoals eerder vermeld, kunt u versleutelingssleutels importeren of genereren in HSM's, zodat sleutels nooit de HSM-grens verlaten ter ondersteuning van BYOK-scenario's (Bring Your Own Key).

Key Vault kan aanvragen en vernieuwen van certificaten in kluizen verwerken, waaronder TLS-certificaten (Transport Layer Security), zodat u certificaten kunt registreren en automatisch kunt vernieuwen bij ondersteunde openbare certificeringsinstanties. Ondersteuning voor Key Vault-certificaten biedt het beheer van uw X.509-certificaten, die zijn gebouwd op sleutels en een functie voor automatische verlenging bieden. Certificaateigenaar kan een certificaat maken via Azure Key Vault of door een bestaand certificaat te importeren. Zowel zelfondertekende als door certificeringsinstantie gegenereerde certificaten worden ondersteund. Bovendien kan de eigenaar van het Key Vault-certificaat beveiligde opslag en beheer van X.509-certificaten implementeren zonder interactie met persoonlijke sleutels.

Wanneer u een sleutelkluis in een resourcegroep maakt, kunt u de toegang beheren met behulp van Microsoft Entra-id, waarmee u toegang kunt verlenen op een specifiek bereikniveau door de juiste Azure-rollen toe te wijzen. Als u bijvoorbeeld een gebruiker toegang wilt geven voor het beheren van sleutelkluizen, kunt u de vooraf gedefinieerde Key Vault Contributor-rol toewijzen aan de gebruiker op een specifiek bereik, inclusief een abonnement, een resourcegroep of een specifieke resource.

Belangrijk

U moet nauwkeurig bepalen wie de rol Inzender heeft tot uw sleutelkluizen. Als een gebruiker bijdragemachtigingen heeft voor het beheervlak van een Key Vault, kan de gebruiker toegang krijgen tot de data plane door een toegangsbeleid voor de sleutelkluis in te stellen.

Extra resources:

• Hoe toegang tot een sleutelkluis beveiligen.

Beheerde HSM

Beheerde HSM biedt een volledig beheerde, single-tenant, hoogbeschikbare, zone-resistente (waar beschikbaar) HSM als een dienst voor het opslaan en beheren van uw cryptografische sleutels. Het is het meest geschikt voor toepassingen en gebruiksscenario's die sleutels met hoge waarde verwerken. Het helpt u ook om te voldoen aan de strengste vereisten op het gebied van beveiliging, naleving en regelgeving. Beheerde HSM maakt gebruik van met FIPS 140 Level 3 gevalideerde HSM's om uw cryptografische sleutels te beveiligen. Elke beheerde HSM-pool is een geïsoleerd exemplaar van één tenant met een eigen beveiligingsdomein dat door u wordt beheerd en cryptografisch is geïsoleerd van exemplaren die tot andere klanten behoren. Cryptografische isolatie is afhankelijk van De Technologie van Intel Software Guard Extensions (SGX) die versleutelde code en gegevens biedt om uw controle over cryptografische sleutels te waarborgen.

Wanneer een beheerde HSM wordt gemaakt, biedt de aanvrager ook een lijst met beheerders van gegevensvlakken. Alleen deze beheerders hebben toegang tot het beheerde HSM-gegevensvlak om belangrijke bewerkingen uit te voeren en roltoewijzingen van gegevensvlakken (lokale RBAC van beheerde HSM) te beheren. Het machtigingsmodel voor zowel de beheer- als gegevensvlakken gebruikt dezelfde syntaxis, maar machtigingen worden afgedwongen op verschillende niveaus en roltoewijzingen maken gebruik van verschillende bereiken. Het beheervlak van Azure RBAC wordt afgedwongen door Azure Resource Manager, terwijl het datavlak-beheer van HSM lokaal RBAC wordt afgedwongen door de beheerde HSM zelf.

Belangrijk

In tegenstelling tot sleutelkluizen, verleent het verlenen van toegang tot een beheerde HSM uw gebruikers geen toegang tot het gegevensvlak om toegang te krijgen tot sleutels of roltoewijzingen van gegevensvlakken die worden beheerd met lokale HSM-RBAC. Deze isolatie wordt standaard geïmplementeerd om onbedoelde uitbreiding van bevoegdheden te voorkomen die van invloed zijn op de toegang tot sleutels die zijn opgeslagen in beheerde HSM's.

Zoals eerder vermeld, ondersteunt beheerde HSM het importeren van sleutels die zijn gegenereerd in uw on-premises HSM's, zodat de sleutels nooit de HSM-beveiligingsgrens verlaten, ook wel bekend als BYOK-scenario (Bring Your Own Key). Beheerde HSM biedt ondersteuning voor integratie met Azure-services zoals Azure Storage, Azure SQL Database, Azure Information Protection en andere services. Zie Gegevensversleutelingsmodellen voor een volledigere lijst met Azure-services die werken met beheerde HSM.

Met beheerde HSM kunt u de tot stand gebrachte Azure Key Vault-API en beheerinterfaces gebruiken. U kunt dezelfde toepassingsontwikkelings- en implementatiepatronen gebruiken voor al uw toepassingen, ongeacht de oplossing voor sleutelbeheer: multitenant-kluis of met één tenant beheerde HSM.

Computerisolatie

Het Microsoft Azure-rekenplatform is gebaseerd op machinevirtualisatie. Deze aanpak betekent dat uw code, ongeacht of deze is geïmplementeerd in een PaaS-werkrol of een virtuele IaaS-machine, wordt uitgevoerd op een virtuele machine die wordt gehost door een Windows Server-Hyper-V hypervisor. Op elke fysieke Azure-server, ook wel bekend als een knooppunt, is er een Hypervisor van het type 1 die rechtstreeks over de hardware wordt uitgevoerd en het knooppunt wordt verdeeld in een variabel aantal virtuele gastmachines (VM's), zoals wordt weergegeven in afbeelding 4. Elk knooppunt heeft één speciale host-VM, ook wel root-VM genoemd, waarop het host-besturingssysteem wordt uitgevoerd: een aangepaste en beperkte versie van de nieuwste Windows Server, die is verwijderd om het kwetsbaarheid voor aanvallen te verminderen en alleen die onderdelen op te nemen die nodig zijn om het knooppunt te beheren. Isolatie van de hoofd-VM van de gast-VM's en de gast-VM's van elkaar is een belangrijk concept in de Azure-beveiligingsarchitectuur die de basis vormt van Azure-rekenisolatie, zoals beschreven in de onlinedocumentatie van Microsoft.

afbeelding 4. Isolatie van Hypervisor, hoofd-VM en gast-VM's

Fysieke servers die vm's hosten, worden gegroepeerd in clusters en worden onafhankelijk beheerd door een uitgeschaald en redundant platformsoftwareonderdeel genaamd de Fabric Controller (FC). Elke FC beheert de levenscyclus van VM's die in het cluster worden uitgevoerd, inclusief het inrichten en bewaken van de status van de hardware onder controle. De FC is bijvoorbeeld verantwoordelijk voor het opnieuw maken van VM-exemplaren op goede servers wanneer wordt bepaald dat een server is mislukt. Het wijst ook infrastructuurbronnen toe aan tenantworkloads en beheert unidirectionele communicatie van de host naar virtuele machines. Door de rekeninfrastructuur te verdelen in clusters, worden fouten op FC-niveau geïsoleerd en voorkomt u dat bepaalde klassen fouten van invloed zijn op servers buiten het cluster waarin ze voorkomen.

De FC is de hersenen van het Azure-rekenplatform en de HostAgent is de proxy, waarbij servers worden geïntegreerd in het platform, zodat de FC de virtuele machines die door u en Azure-cloudservices worden gebruikt, kan implementeren, bewaken en beheren. Het koppelen van hypervisor-/hostbesturingssystemen maakt gebruik van tientallen jaren ervaring van Microsoft op het gebied van beveiliging van besturingssystemen, waaronder investeringen in beveiliging die zijn gericht op beveiliging in Microsoft Hyper-V om een sterke isolatie van gast-VM's te bieden. Isolatie van hypervisors wordt verderop in deze sectie besproken, waaronder garanties voor sterk gedefinieerde beveiligingsgrenzen die worden afgedwongen door de Hypervisor, diepgaande beveiligingsrisicobeperking en sterke beveiligingscontroleprocessen.

Netwerkisolatie beheren

Er zijn drie VLAN's (Virtual Local Area Networks) in elk rekenhardwarecluster, zoals wordt weergegeven in afbeelding 5:

• Hoofd-VLAN verbindt niet-vertrouwde klantknooppunten,
• Fabric Controller (FC) VLAN dat vertrouwde FCs en ondersteunende systemen bevat, en
• Apparaat-VLAN dat vertrouwde netwerk- en andere infrastructuurapparaten bevat.

Communicatie is toegestaan van het FC VLAN naar het hoofd-VLAN, maar kan niet worden gestart van het hoofd-VLAN naar het FC VLAN. De brug van het FC VLAN naar het hoofd-VLAN wordt gebruikt om de algehele complexiteit te verminderen en de betrouwbaarheid/tolerantie van het netwerk te verbeteren. De verbinding wordt op verschillende manieren beveiligd om ervoor te zorgen dat opdrachten worden vertrouwd en succesvol gerouteerd.

• Communicatie van een FC naar een Fabric Agent (FA) is unidirectioneel en vereist wederzijdse verificatie via certificaten. De FA implementeert een met TLS beveiligde service die alleen reageert op aanvragen van de FC. Er kunnen geen verbindingen worden gestart met de FC of andere bevoegde interne knooppunten.
• De FC behandelt reacties van de agentservice als onbetrouwbaar. Communicatie met de agent wordt verder beperkt tot een set geautoriseerde IP-adressen met behulp van firewallregels op elk fysiek knooppunt en routeringsregels op de randgateways.
• Beperking wordt gebruikt om ervoor te zorgen dat klant-VM's de netwerk- en beheeropdrachten niet kunnen verzadigen.

Communicatie wordt ook geblokkeerd van het hoofd-VLAN naar het VLAN van het apparaat. Op deze manier kan een knooppunt waarop klantcode wordt uitgevoerd, zelfs als het is gecompromitteerd, geen knooppunten op de FC- of apparaat-VLANs aanvallen.

Deze besturingselementen zorgen ervoor dat de toegang van de beheerconsole tot de Hypervisor altijd geldig en beschikbaar is.

afbeelding 5. VLAN-isolatie

De Hypervisor en het host-besturingssysteem bieden netwerkpakketfilters, die ervoor zorgen dat niet-vertrouwde VM's geen vervalst verkeer kunnen genereren of verkeer kunnen ontvangen dat niet is geadresseerd, verkeer naar beveiligde infrastructuureindpunten leiden of ongepast broadcast-verkeer verzenden/ontvangen. Standaard wordt verkeer geblokkeerd wanneer een virtuele machine wordt gemaakt en configureert de FC-agent vervolgens het pakketfilter om regels en uitzonderingen toe te voegen om geautoriseerd verkeer toe te staan. Meer gedetailleerde informatie over isolatie van netwerkverkeer en scheiding van tenantverkeer vindt u in de sectie Netwerkisolatie .

Beheerconsole en beheervlak

De Azure Management Console en het beheervlak volgen strikte beveiligingsarchitectuurprincipes van minimale bevoegdheden om tenantverwerking te beveiligen en te isoleren:

• Beheerconsole (MC): het MC in Azure Cloud bestaat uit de GUI van Azure Portal en de API-lagen van Azure Resource Manager. Ze gebruiken beide gebruikersreferenties om alle bewerkingen te verifiëren en te autoriseren.
• Beheervlak (MP): deze laag voert de werkelijke beheeracties uit en bestaat uit de Compute Resource Provider (CRP), Fabric Controller (FC), Fabric Agent (FA) en de onderliggende Hypervisor, die een eigen Hypervisor-agent heeft voor servicecommunicatie. Deze lagen maken allemaal gebruik van systeemcontexten die de minste machtigingen krijgen die nodig zijn om hun bewerkingen uit te voeren.

Azure FC wijst infrastructuurbronnen toe aan tenants en beheert unidirectionele communicatie van het host-besturingssysteem naar gast-VM's. Het algoritme voor vm-plaatsing van Azure FC is zeer geavanceerd en bijna onmogelijk te voorspellen. De FA bevindt zich in het host-besturingssysteem en beheert tenant-VM's. De verzameling azure Hypervisor, hostbesturingssysteem en FA en klant-VM's vormen een rekenknooppunt, zoals wordt weergegeven in afbeelding 4. FC's beheren FA's, hoewel er FC's bestaan buiten rekenknooppunten. Afzonderlijke FC's bestaan voor het beheren van reken- en opslagclusters. Als u het configuratiebestand van uw toepassing bijwerkt terwijl deze wordt uitgevoerd in de MC, communiceert het MC via CRP met de FC en communiceert de FC met de FA.

CRP is de front-endservice voor Azure Compute, met consistente reken-API's via Azure Resource Manager, waardoor u resources en extensies voor virtuele machines kunt maken en beheren via eenvoudige sjablonen.

Communicatie tussen verschillende onderdelen (bijvoorbeeld Azure Resource Manager van en naar CRP, CRP naar en van FC, FC naar en van Hypervisor-agent) werken allemaal op verschillende communicatiekanalen met verschillende identiteiten en verschillende machtigingensets. Dit ontwerp volgt algemene modellen met minimale bevoegdheden om ervoor te zorgen dat een inbreuk op één laag meer acties voorkomt. Afzonderlijke communicatiekanalen zorgen ervoor dat communicatie geen laag in de keten kan omzeilen. Afbeelding 6 laat zien hoe de MC en MP veilig communiceren in de Azure-cloud voor hypervisor-interactie die is geïnitieerd door de OAuth 2.0-verificatie van een gebruiker naar Microsoft Entra-id.

afbeelding 6. Interactie tussen beheerconsole en beheervlak voor beveiligde beheerstroom

Alle beheeropdrachten worden geverifieerd via een RSA-ondertekend certificaat of JSON Web Token (JWT). Verificatie- en opdrachtkanalen worden versleuteld via TLS 1.2 (Transport Layer Security), zoals beschreven in de sectie Gegevensversleuteling in transit . Servercertificaten worden gebruikt om TLS-connectiviteit te bieden aan de verificatieproviders waar een afzonderlijk autorisatiemechanisme wordt gebruikt, bijvoorbeeld Microsoft Entra ID of datacenter Security Token Service (dSTS). dSTS is een tokenprovider zoals Microsoft Entra-id die is geïsoleerd naar het Microsoft-datacenter en wordt gebruikt voor communicatie op serviceniveau.

Afbeelding 6 illustreert de beheerstroom die overeenkomt met een gebruikersopdracht om een virtuele machine te stoppen. De stappen in tabel 1 zijn op dezelfde manier van toepassing op andere beheeropdrachten en gebruiken dezelfde versleutelings- en verificatiestroom.

Tabel 1. Beheerproces met verschillende MC- en MP-onderdelen

Stap	Beschrijving	Authenticatie	Encryptie
1.	Gebruiker authenticeert via Microsoft Entra ID door inloggegevens in te voeren en krijgt een token uitgegeven.	Gebruikersreferenties	TLS 1.2
2.	Browser presenteert token aan Azure Portal om de gebruiker te verifiëren. Azure Portal controleert het token met behulp van tokenhandtekening en geldige ondertekeningssleutels.	JSON-webtoken (Microsoft Entra ID)	TLS 1.2
3.	Gebruiker dient verzoek 'VM stoppen' in via de Azure-portal. Azure Portal verzendt de aanvraag 'VM stoppen' naar Azure Resource Manager en presenteert het token van de gebruiker dat is opgegeven door Microsoft Entra-id. Azure Resource Manager controleert het token met behulp van tokenhandtekening en geldige ondertekeningssleutels en of de gebruiker gemachtigd is om de aangevraagde bewerking uit te voeren.	JSON-webtoken (Microsoft Entra ID)	TLS 1.2
4.	Azure Resource Manager vraagt een token aan bij dSTS-server op basis van het clientcertificaat dat Azure Resource Manager heeft, zodat dSTS een JSON-webtoken met de juiste identiteit en rollen kan verlenen.	Clientcertificaat	TLS 1.2
5.	Azure Resource Manager verzendt een aanvraag naar CRP. Aanroep wordt geverifieerd via OAuth met behulp van een JSON-webtoken dat de Azure Resource Manager-systeemidentiteit van dSTS vertegenwoordigt, zodat deze wordt overgestapt van gebruiker naar systeemcontext.	JSON-webtoken (dSTS)	TLS 1.2
6.	CRP valideert de aanvraag en bepaalt welke infrastructuurcontroller de aanvraag kan voltooien. CRP vraagt een certificaat van dSTS aan op basis van het clientcertificaat, zodat het verbinding kan maken met de specifieke infrastructuurcontroller (FC) die het doel van de opdracht is. De token verleent alleen machtigingen aan die specifieke FC als de CRP met die FC mag communiceren.	Clientcertificaat	TLS 1.2
7.	CRP verzendt vervolgens de aanvraag naar de juiste FC met het JSON-webtoken dat is gemaakt door dSTS.	JSON-webtoken (dSTS)	TLS 1.2
8.	FC valideert vervolgens of de opdracht is toegestaan en afkomstig is van een vertrouwde bron. Vervolgens wordt een beveiligde TLS-verbinding tot stand gebracht met de juiste Fabric Agent (FA) in het cluster waarmee de opdracht kan worden uitgevoerd met behulp van een certificaat dat uniek is voor de doel-FA en de FC. Zodra de beveiligde verbinding tot stand is gebracht, wordt de opdracht verzonden.	Wederzijds certificaat	TLS 1.2
9.	De FA valideert opnieuw dat de opdracht is toegestaan en afkomstig is van een vertrouwde bron. Zodra deze is gevalideerd, maakt de FA een beveiligde verbinding met behulp van wederzijdse certificaatverificatie en geeft de opdracht uit aan de Hypervisor-agent die alleen toegankelijk is voor de FA.	Wederzijds certificaat	TLS 1.2
10.	HypervisorAgent op de host voert een interne aanroep uit om de VIRTUELE machine te stoppen.	Systeemcontext	N.A.

Opdrachten die worden gegenereerd via alle stappen van het proces dat in deze sectie is geïdentificeerd en naar de FC en FA op elk knooppunt worden verzonden, worden naar een lokaal auditlogboek geschreven en gedistribueerd naar meerdere analysesystemen voor stroomverwerking om de systeemstatus te bewaken en beveiligingsgebeurtenissen en -patronen bij te houden. Bijhouden omvat gebeurtenissen die succesvol zijn verwerkt en gebeurtenissen die ongeldig zijn. Ongeldige aanvragen worden verwerkt door de inbraakdetectiesystemen om afwijkingen te detecteren.

Implementatieopties voor logische isolatie

Azure biedt isolatie van rekenverwerking via een benadering met meerdere lagen, waaronder:

• Hypervisorisolatie voor services die cryptografisch bepaalde isolatie bieden met behulp van afzonderlijke virtuele machines en azure Hypervisor-isolatie. Voorbeelden: App Service, Azure Container Instances, Azure Databricks, Azure Functions, Azure Kubernetes Service, Azure Machine Learning, Cloud Services, Data Factory, Service Fabric, Virtual Machines, Virtual Machine Scale Sets.
• Drawbridge-isolatie binnen een VIRTUELE machine voor services die cryptografisch bepaalde isolatie bieden voor workloads die op dezelfde virtuele machine worden uitgevoerd met behulp van isolatie die wordt geleverd door Drawbridge. Deze services bieden kleine verwerkingseenheden met behulp van klantcode. Om beveiligingsisolatie te bieden, voert Drawbridge een gebruikersproces uit in combinatie met een lichtgewicht versie van de Windows-kernel (bibliotheekbesturingssysteem) binnen een pico-proces. Een pico-proces is een beveiligd proces zonder directe toegang tot services of resources van het hostsysteem. Voorbeelden: Automation, Azure Database for MySQL, Azure Database for PostgreSQL, Azure SQL Database, Azure Stream Analytics.
• Isolatie op basis van gebruikerscontext voor services die uitsluitend bestaan uit door Microsoft beheerde code en klantcode mag niet worden uitgevoerd. Voorbeelden: API Management, Application Gateway, Microsoft Entra ID, Azure Backup, Azure Cache voor Redis, Azure DNS, Azure Information Protection, Azure IoT Hub, Azure Key Vault, Azure Portal, Azure Monitor (inclusief Log Analytics), Microsoft Defender for Cloud, Azure Site Recovery, Container Registry, Content Delivery Network, Event Grid, Event Hubs, Load Balancer, Service Bus, Storage, Virtual Network, VPN Gateway, Traffic Manager.

Deze opties voor logische isolatie worden in de rest van deze sectie besproken.

Hypervisor-isolatie

Isolatie van hypervisor in Azure is gebaseerd op Microsoft Hyper-V-technologie , waardoor isolatie op basis van Azure Hypervisor kan profiteren van decennia aan Microsoft-ervaring op het gebied van beveiliging van besturingssystemen en investeringen in Hyper-V technologie voor isolatie van virtuele machines. U kunt onafhankelijke beoordelingsrapporten van derden bekijken over Hyper-V beveiligingsfuncties, waaronder de rapporten van het National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS), zoals het rapport dat in februari 2021 is gepubliceerd en hierin wordt besproken.

Het doel van evaluatie (TOE) bestaat uit Microsoft Windows Server, Microsoft Windows 10 versie 1909 (update van november 2019) en Microsoft Windows Server 2019 (versie 1809) Hyper-V ("Windows"). TOE dwingt het volgende beveiligingsbeleid af, zoals beschreven in het rapport:

• Beveiligingscontrole : Windows heeft de mogelijkheid om controlegegevens te verzamelen, auditlogboeken te controleren, auditlogboeken te beveiligen tegen overloop en de toegang tot auditlogboeken te beperken. Controle-informatie die door het systeem wordt gegenereerd, bevat de datum en tijd van de gebeurtenis, de gebruikersidentiteit waardoor de gebeurtenis werd gegenereerd en andere gebeurtenisspecifieke gegevens. Geautoriseerde beheerders kunnen auditrecords controleren, zoeken en sorteren. Geautoriseerde beheerders kunnen het controlesysteem ook configureren om mogelijk controleerbare gebeurtenissen op te nemen of uit te sluiten die moeten worden gecontroleerd op basis van veel kenmerken. In de context van deze evaluatie hebben de beveiligingsprofielvereisten betrekking op het genereren van controlegebeurtenissen, een geautoriseerde beoordeling van opgeslagen auditrecords en het bieden van beveiligde opslag voor vermeldingen van auditgebeurtenissen.
• Cryptografische ondersteuning : Windows biedt gevalideerde cryptografische functies die ondersteuning bieden voor versleuteling/ontsleuteling, cryptografische handtekeningen, cryptografische hashing en het genereren van willekeurige getallen. Windows implementeert deze functies ter ondersteuning van IPsec-, TLS- en HTTPS-protocol-implementatie. Windows zorgt er ook voor dat de gast-VM's toegang hebben tot entropygegevens, zodat gevirtualiseerde besturingssystemen de implementatie van sterke cryptografie kunnen garanderen.
• Gebruikersgegevensbescherming : Windows maakt bepaalde computingservices beschikbaar voor gast-VM's, maar implementeert maatregelen om ervoor te zorgen dat toegang tot deze services op de juiste basis wordt verleend en dat deze interfaces niet leiden tot onbevoegde gegevenslekken tussen gast-VM's en Windows of tussen meerdere gast-VM's.
• Identificatie en verificatie : Windows biedt verschillende methoden voor gebruikersverificatie, waaronder X.509-certificaten die nodig zijn voor vertrouwde protocollen. Windows implementeert mechanismen voor wachtwoordsterkte en zorgt ervoor dat overmatige mislukte verificatiepogingen met behulp van methoden die onderhevig zijn aan brute force raden (wachtwoord, pincode) resulteert in vergrendelingsgedrag.
• Beveiligingsbeheer : Windows bevat verschillende functies voor het beheren van beveiligingsbeleid. Toegang tot beheerfuncties wordt afgedwongen via beheerdersrollen. Windows biedt ook de mogelijkheid om de scheiding van beheer- en operationele netwerken te ondersteunen en het delen van gegevens tussen gast-VM's te verbieden.
• Beveiliging van de TOE-beveiligingsfuncties (TSF): Windows implementeert verschillende zelfbeveiligingsmechanismen om ervoor te zorgen dat deze niet kan worden gebruikt als platform om onbevoegde toegang te krijgen tot gegevens die zijn opgeslagen op een gast-VM, dat de integriteit van zowel de TSF als de gast-VM's wordt onderhouden en dat gast-VM's alleen toegankelijk zijn via goed gedocumenteerde interfaces.
• TOE Access : in de context van deze evaluatie kan een geautoriseerde beheerder het systeem zo configureren dat er vóór het aanmeldingsdialoogvenster een aanmeldingsbanner wordt weergegeven.
• Vertrouwd pad/kanalen : Windows implementeert IPsec-, TLS- en HTTPS-vertrouwde kanalen en -paden voor extern beheer, overdracht van controlegegevens naar de operationele omgeving en scheiding van beheer- en operationele netwerken.

Meer informatie vindt u in het certificeringsrapport van derden.

De kritieke isolatie van hypervisor wordt geboden via:

• Sterk gedefinieerde beveiligingsgrenzen die worden afgedwongen door de Hypervisor
• Gelaagde verdedigingsstrategieën benutten mitigaties
• Sterke processen voor beveiligingscontrole

Deze technologieën worden beschreven in de rest van deze sectie. Ze stellen Azure Hypervisor in staat om sterke beveiligingsgaranties te bieden voor tenantscheiding in een multitenantcloud.

Sterk gedefinieerde beveiligingsgrenzen

Uw code wordt uitgevoerd op een hypervisor-VM en profiteert van door Hypervisor afgedwongen beveiligingsgrenzen, zoals wordt weergegeven in afbeelding 7. Azure Hypervisor is gebaseerd op Microsoft Hyper-V-technologie . Het verdeelt een Azure-knooppunt in een variabel aantal gast-VM's met afzonderlijke adresruimten waar ze een besturingssysteem (OS) kunnen laden en toepassingen die parallel werken met het hostbesturingssysteem dat wordt uitgevoerd in de hoofdpartitie van het knooppunt.

Afbeelding 7. Isolatie van rekenkracht met Azure Hypervisor (zie online woordenlijst met termen)

De Azure Hypervisor fungeert als een micro-kernel, waarbij alle aanvragen voor hardwaretoegang van gast-VM's worden doorgegeven met behulp van een VSC (Virtualization Service Client) naar het hostbesturingssysteem voor verwerking met behulp van een interface met gedeeld geheugen met de naam VMBus. Het hostbesturingssysteem proxyt de hardwareaanvragen met behulp van een VSP (Virtualization Service Provider) die voorkomt dat gebruikers onbewerkte lees-/schrijf-/uitvoertoegang tot het systeem verkrijgen en het risico van het delen van systeembronnen beperken. De bevoegde hoofdpartitie, ook wel host-besturingssysteem genoemd, heeft directe toegang tot de fysieke apparaten/randapparatuur op het systeem, bijvoorbeeld opslagcontrollers, GPU's, netwerkadapters, enzovoort. Met het host-besturingssysteem kunnen gastpartities het gebruik van deze fysieke apparaten delen door virtuele apparaten beschikbaar te maken voor elke gastpartitie. Een besturingssysteem dat wordt uitgevoerd in een gastpartitie heeft dus toegang tot gevirtualiseerde randapparatuur die worden geleverd door VSP's die worden uitgevoerd in de hoofdpartitie. Deze weergaven van virtuele apparaten kunnen een van de volgende drie vormen hebben:

• Geëmuleerde apparaten : het hostbesturingssysteem kan een virtueel apparaat beschikbaar maken met een interface die identiek is aan wat door een corresponderend fysiek apparaat wordt geleverd. In dit geval gebruikt een besturingssysteem in een gastpartitie dezelfde apparaatstuurprogramma's als bij het uitvoeren op een fysiek systeem. Het host-besturingssysteem zou het gedrag van een fysiek apparaat naar de gastpartitie emuleren.
• Para-gevirtualiseerde apparaten : het hostbesturingssysteem kan virtuele apparaten beschikbaar maken met een virtualisatiespecifieke interface met behulp van de interface voor gedeeld geheugen van VMBus tussen het hostbesturingssysteem en de gast. In dit model maakt de gastpartitie gebruik van apparaatstuurprogramma's die speciaal zijn ontworpen om een gevirtualiseerde interface te implementeren. Deze para-gevirtualiseerde apparaten worden soms 'synthetische' apparaten genoemd.
• Hardwareversnelde apparaten – het Host-besturingssysteem kan fysieke hardware-perifere apparaten rechtstreeks aan de gastpartitie blootstellen. Dit model biedt hoge I/O-prestaties in een gastpartitie, omdat de gastpartitie rechtstreeks toegang heeft tot hardwareapparaatbronnen zonder het host-besturingssysteem te doorlopen. Versneld netwerken van Azure is een voorbeeld van een apparaat dat is versneld met hardware. Isolatie in dit model wordt bereikt met behulp van in-output geheugenbeheereenheden (I/O MMU's) om adresruimte te bieden en isolatie te onderbreken voor elke partitie.

Met virtualisatie-extensies in de host-CPU kan de Azure Hypervisor isolatie tussen partities afdwingen. De volgende fundamentele CPU-mogelijkheden bieden de hardwarebouwstenen voor isolatie van Hypervisor:

• Adresomzetting op het tweede niveau : de Hypervisor bepaalt welke geheugenbronnen een partitie mag openen met behulp van paginatabellen op het tweede niveau die worden geleverd door de GEHEUGENbeheereenheid (MMU) van de CPU. De MMU van de CPU maakt gebruik van adresomzetting op het tweede niveau onder Hypervisor-beheer om beveiliging af te dwingen voor geheugentoegang die wordt uitgevoerd door:
  • CPU bij uitvoering onder de context van een partitie.
  • I/O-apparaten die rechtstreeks worden geopend door gastpartities.
• CPU-context : de Hypervisor maakt gebruik van virtualisatieextensies in de CPU om bevoegdheden en CPU-context te beperken die kunnen worden geopend terwijl een gastpartitie wordt uitgevoerd. De Hypervisor gebruikt deze faciliteiten ook om de status op te slaan en te herstellen bij het delen van CPU's tussen meerdere partities om isolatie van de CPU-status tussen de partities te garanderen.

De Azure Hypervisor maakt uitgebreid gebruik van deze processorfaciliteiten om isolatie tussen partities te bieden. De opkomst van speculatieve side channel-aanvallen heeft potentiële zwakke plekken in sommige van deze processorisolatiemogelijkheden geïdentificeerd. In een architectuur met meerdere tenants bestaat elke aanval tussen meerdere VM's uit twee stappen: het plaatsen van een door adversary beheerde VM op dezelfde host als een van de slachtoffer-VM's en vervolgens het overschrijden van de logische isolatiegrens om een side-channel-aanval uit te voeren. Azure biedt bescherming tegen beide bedreigingsvectoren met behulp van een geavanceerd VM-plaatsingsalgoritmen die geheugen- en processcheiding afdwingen voor logische isolatie en veilige routering van netwerkverkeer met cryptografische zekerheid bij de Hypervisor. Zoals beschreven in de sectie Exploitatie van beveiligingsproblemen in virtualisatietechnologieën verderop in het artikel, is de Azure Hypervisor ontworpen om robuuste isolatie rechtstreeks binnen de hypervisor te bieden die helpt bij het beperken van veel geavanceerde side channel-aanvallen.

De door Azure Hypervisor gedefinieerde beveiligingsgrenzen bieden de isolatieprimitief op basisniveau voor sterke segmentatie van code, gegevens en resources tussen potentieel vijandige multitenants op gedeelde hardware. Deze isolatie primitiefen worden gebruikt voor het maken van isolatiescenario's met meerdere tenants, waaronder:

• Isolatie van netwerkverkeer tussen potentieel vijandige gasten : Virtual Network (VNet) biedt isolatie van netwerkverkeer tussen tenants als onderdeel van het fundamentele ontwerp, zoals verderop wordt beschreven in de sectie Scheiding van tenantnetwerkverkeer . VNet vormt een isolatiegrens waarbij de VIRTUELE machines binnen een VNet alleen met elkaar kunnen communiceren. Verkeer dat is bestemd voor een virtuele machine vanuit het VNet of externe afzenders zonder het juiste beleid dat is geconfigureerd, wordt verwijderd door de host en wordt niet bezorgd bij de VIRTUELE machine.
• Isolatie voor versleutelingssleutels en cryptografisch materiaal : u kunt de isolatiemogelijkheden verder uitbreiden met behulp van hardwarebeveiligingsmanagers of gespecialiseerde sleutelopslag, bijvoorbeeld het opslaan van versleutelingssleutels in met FIPS 140 gevalideerde HSM's (Hardware Security Modules) via Azure Key Vault.
• Planning van systeemresources : Azure-ontwerp omvat gegarandeerde beschikbaarheid en segmentatie van reken-, geheugen-, opslag- en directe en geparavirtualiseerde apparaattoegang.

De Azure Hypervisor voldoet aan de beveiligingsdoelstellingen die worden weergegeven in tabel 2.

Tabel 2. Azure Hypervisor-beveiligingsdoelstellingen

Doelstelling	Bron
Isolatie	Het azure Hypervisor-beveiligingsbeleid vereist geen informatieoverdracht tussen VM's. Dit beleid vereist mogelijkheden in Virtual Machine Manager (VMM) en hardware voor de isolatie van geheugen, apparaten, netwerken en beheerde resources, zoals persistente gegevens.
VMM-integriteit	Integriteit is een kernbeveiligingsdoelstelling voor virtualisatiesystemen. Om systeemintegriteit te bereiken, wordt de integriteit van elk Hypervisor-onderdeel tot stand gebracht en onderhouden. Dit doel betreft alleen de integriteit van de Hypervisor zelf, niet de integriteit van het fysieke platform of de software die binnen VM's wordt uitgevoerd.
Platformintegriteit	De integriteit van de Hypervisor is afhankelijk van de integriteit van de hardware en software waarvan deze afhankelijk is. Hoewel de Hypervisor geen directe controle heeft over de integriteit van het platform, is Azure afhankelijk van hardware- en firmwaremechanismen zoals de Cerberus-beveiligingsmicrocontroller om de onderliggende platformintegriteit te beschermen, waardoor de VMM en gasten niet kunnen worden uitgevoerd als de platformintegriteit wordt aangetast.
Beheertoegang	Beheerfuncties worden alleen uitgevoerd door geautoriseerde beheerders, verbonden via beveiligde verbindingen met een principe van minimale bevoegdheden dat wordt afgedwongen door een fijnmazig mechanisme voor toegangsbeheer voor rollen.
Audit	Azure biedt controlemogelijkheden voor het vastleggen en beveiligen van systeemgegevens, zodat deze later kunnen worden geïnspecteerd.

Beveiligingsproblemen met diepgaande aanvallen

Om het risico van een beveiligingsrisico verder te beperken, heeft Microsoft geïnvesteerd in talloze diepgaande beveiligingsbeperkingen in Azure-systemen, -software, -hardware en -firmware om sterke echte isolatiegaranties te bieden aan Azure-klanten. Zoals eerder vermeld, is Isolatie van Azure Hypervisor gebaseerd op Microsoft Hyper-V-technologie , waardoor Azure Hypervisor kan profiteren van decennia aan Microsoft-ervaring op het gebied van beveiliging van besturingssystemen en investeringen in Hyper-V technologie voor isolatie van virtuele machines.

Hieronder vindt u enkele belangrijke ontwerpprincipes die door Microsoft worden gebruikt om Hyper-V te beveiligen:

• Voorkomen dat problemen op ontwerpniveau van invloed zijn op het product
  • Elke wijziging in Hyper-V is onderhevig aan ontwerpbeoordeling.
• Veelvoorkomende beveiligingsklassen elimineren met veiliger coderen
  • Sommige onderdelen, zoals de VMSwitch, gebruiken een formeel bewezen protocolparser.
  • Veel onderdelen gebruiken gsl::span in plaats van onbewerkte aanwijzers, waardoor de mogelijkheid van bufferoverloop en/of buitengrensgeheugentoegang wordt geëlimineerd. Zie de GSL-documentatie (Guidelines Support Library) voor meer informatie.
  • Veel onderdelen maken gebruik van slimme aanwijzers om het risico op gebruik-na-vrije bugs te elimineren.
  • De meeste kernelmoduscode in Hyper-V gebruikt een hoop-allocator die geheugen op nul zet tijdens de toewijzing om niet-geïnitialiseerde geheugenfouten te elimineren.
• Veelvoorkomende beveiligingsklassen met compilerbeperking elimineren
  • Alle Hyper-V code wordt gecompileerd met InitAll, waardoor niet-geïnitialiseerde stackvariabelen worden geëlimineerd. Deze benadering is geïmplementeerd omdat veel historische beveiligingsproblemen in Hyper-V zijn veroorzaakt door niet-geïnitialiseerde stackvariabelen.
  • Alle Hyper-V code wordt gecompileerd met stack canaries om het risico op beveiligingsproblemen met stackoverloop aanzienlijk te verminderen.
• Problemen ontdekken die in het product terechtkomen
  • Alle Windows-code bevat een set statische analyseregels die erop worden uitgevoerd.
  • De Hyper-V-code is code beoordeeld en gefuzzt. Zie de sectie Beveiligingscontroleprocessen en -procedures verderop in dit artikel voor meer informatie over fuzzing.
• Misbruik van resterende beveiligingsproblemen moeilijker maken
  • Het VM-werkproces heeft de volgende mitigaties toegepast:
    • Willekeurige Code Guard : dynamisch gegenereerde code kan niet worden geladen in het VM-werkproces.
    • Code Integrity Guard : alleen door Microsoft ondertekende code kan worden geladen in het VM-werkproces.
    • Control Flow Guard (CFG) – Biedt grofmazige controlestroombeveiliging voor indirecte aanroepen en sprongen.
    • NoChildProcess – Het werkproces kan geen subprocessen maken (nuttig voor het omzeilen van CFG).
    • NoLowImages/NoRemoteImages: het werkproces kan DLL's niet laden via het netwerk of DLL's die door een sandbox-proces naar de schijf zijn geschreven.
    • NoWin32k: het werkproces kan niet communiceren met Win32k, waardoor sandbox-escapes moeilijker worden.
    • Heap randomisatie : Windows wordt geleverd met een van de veiligste heap-implementaties van elk besturingssysteem.
    • Randomisatie van adresruimte-indeling (ASLR): hiermee wordt de indeling van heaps, stacks, binaire bestanden en andere gegevensstructuren in de adresruimte gerandomaliseerd om exploitatie minder betrouwbaar te maken.
    • Preventie van gegevensuitvoering (DEP/NX): alleen pagina's met geheugen die zijn bedoeld om code te bevatten, zijn uitvoerbaar.
  • De kernel heeft de volgende mitigaties toegepast:
    • Heap randomisatie : Windows wordt geleverd met een van de veiligste heap-implementaties van elk besturingssysteem.
    • Randomisatie van adresruimte-indeling (ASLR): hiermee wordt de indeling van heaps, stacks, binaire bestanden en andere gegevensstructuren in de adresruimte gerandomaliseerd om exploitatie minder betrouwbaar te maken.
    • Preventie van gegevensuitvoering (DEP/NX): alleen pagina's met geheugen die zijn bedoeld om code te bevatten, zijn uitvoerbaar.

Microsoft-investeringen in Hyper-V-beveiliging komen Azure Hypervisor direct ten goede. Het doel van diepgaande verdedigingsbeperkende oplossingen is om wapenexploitatie van een beveiligingsprobleem zo duur mogelijk te maken voor een aanvaller, hun impact te beperken en het venster voor detectie te maximaliseren. Alle aanvallen worden geëvalueerd op effectiviteit door een grondige beveiligingsbeoordeling van het Azure Hypervisor-aanvalsoppervlak met behulp van methoden die kwaadwillende personen kunnen gebruiken. In tabel 3 worden enkele van de oplossingen beschreven die zijn bedoeld om de isolatiegrenzen van de Hypervisor en de integriteit van de hardwarehost te beschermen.

Tabel 3. Diepgaande verdediging van Azure Hypervisor

Mitigatie	Beveiligingsimpact	Details van risicobeperking
Integriteit van controlestroom	Verhoogt de kosten voor het uitvoeren van controlestroomintegriteitsaanvallen (bijvoorbeeld retourgeoriënteerde programmeeraanvallen)	Control Flow Guard (CFG) zorgt ervoor dat indirecte controlestroomoverdrachten worden geïnstrueerd tijdens het compileren en worden afgedwongen door de kernel (gebruikersmodus) of beveiligde kernel (kernelmodus), ter mitigatie van kwetsbaarheden in stack-retouren.
Integriteit van code in de gebruikersmodus	Beschermt tegen schadelijke en ongewenste binaire uitvoering in de gebruikersmodus	Randomisatie van adresruimte-indeling (ASLR) geforceerd op alle binaire bestanden in de hostpartitie, alle code die is gecompileerd met SDL-beveiligingscontroles (bijvoorbeeld strict_gs), willekeurige beperkingen voor het genereren van code op hostprocessen verhinderen het injecteren van door runtime gegenereerde code.
Code-integriteit van gebruikers- en kernelmodus afgedwongen door hypervisor	Er is geen code geladen in codepagina's die zijn gemarkeerd voor uitvoering totdat de echtheid van de code is geverifieerd	Beveiliging op basis van virtualisatie (VBS) maakt gebruik van geheugenisolatie om een veilige wereld te maken om beleid af te dwingen en gevoelige code en geheimen op te slaan. Met Hypervisor-afgedwongen Code Integrity (HVCI) wordt de beveiligde omgeving gebruikt om te voorkomen dat niet-ondertekende code wordt geïnjecteerd in de normale wereld van de kernel.
Hardware root-of-trust met platform beveiligd opstarten	Zorgt ervoor dat de host alleen de exacte firmware en besturingssysteeminstallatiekopie opstart die is vereist	Met beveiligd opstarten van Windows wordt gevalideerd dat de Azure Hypervisor-infrastructuur alleen kan worden opgestart in een bekende goede configuratie, afgestemd op Azure-firmware, hardware en kernelproductieversies.
Verminderde kwetsbaarheid voor aanvallen VMM	Beschermt tegen escalatie van bevoegdheden in VMM-gebruikersfuncties	De Azure Hypervisor Virtual Machine Manager (VMM) bevat zowel onderdelen van de gebruikers- als kernelmodus. Onderdelen van de gebruikersmodus worden geïsoleerd om uitsplitsing in kernelmodusfuncties te voorkomen, naast talloze gelaagde oplossingen.

Bovendien heeft Azure een beveiligingsstrategie voor lekken aangenomen die via Red Teaming is geïmplementeerd. Deze aanpak is afhankelijk van een speciaal team van beveiligingsonderzoekers en technici die doorlopende tests van Azure-systemen en -bewerkingen uitvoeren met behulp van dezelfde tactieken, technieken en procedures als echte aanvallers tegen een live productie-infrastructuur, zonder dat de kennis van de Azure-infrastructuur en platformengineering of operationele teams wordt gebruikt. Met deze aanpak worden de mogelijkheden voor beveiligingsdetectie en -respons getest en worden beveiligingsproblemen in de productie in Azure Hypervisor en andere systemen geïdentificeerd, waaronder configuratiefouten, ongeldige veronderstellingen of andere beveiligingsproblemen op een gecontroleerde manier. Microsoft investeert sterk in deze innovatieve beveiligingsmaatregelen voor continue risicobeperking van Azure.

Sterke processen voor beveiligingscontrole

Het aanvalsoppervlak in Hyper-V is goed begrepen. Het is het onderwerp van doorlopend onderzoek en grondige beveiligingsbeoordelingen. Microsoft is transparant geweest over de Hyper-V kwetsbaarheid voor aanvallen en onderliggende beveiligingsarchitectuur, zoals wordt gedemonstreerd tijdens een openbare presentatie op een Black Hat-conferentie in 2018. Microsoft staat achter de robuustheid en kwaliteit van Hyper-V-isolatie met een bug bounty-programma van $ 250.000 voor kritieke Remote Code Execution (RCE), openbaarmaking van informatie en Denial of Service (DOS)-kwetsbaarheden die zijn gerapporteerd in Hyper-V. Door gebruik te maken van dezelfde Hyper-V-technologie in het Windows Server- en Azure-cloudplatform, zorgt het openbaar beschikbare documentatie- en bug bounty-programma ervoor dat beveiligingsverbeteringen worden opgebouwd voor alle gebruikers van Microsoft-producten en -services. Tabel 4 bevat een overzicht van de belangrijkste aanvalsoppervlakpunten uit de Black Hat-presentatie.

Tabel 4. details aanvalsoppervlak voor Hyper-V

Aanvalsoppervlak	Bevoegdheden toegekend bij inbreuk	Onderdelen op hoog niveau
Hyper-V	Hypervisor: volledig systeemcompromis met de mogelijkheid om andere gasten te compromitteren	- Hypercalls - Snijpuntafhandeling
Kernel-moduscomponenten van de hostpartitie	Systeem in kernelmodus: volledig systeemcompromitteren met de mogelijkheid om andere gasten te compromitteren	- VID (Virtual Infrastructure Driver) intercept handling - Kernel-mode client library - Virtual Machine Bus (VMBus) kanaalberichten - Storage Virtualization Service Provider (VSP) - Network VSP - Virtual Hard Disk (VHD) parser - Azure Networking Virtual Filtering Platform (VFP) en Virtual Network (VNet)
Onderdelen van de hostpartitie in de gebruikersmodus	Werkproces in de gebruikersmodus: beperkt compromis met de mogelijkheid om host aan te vallen en bevoegdheden te verhogen	- Virtuele apparaten (VDEVs)

Om deze kwetsbaarheid voor aanvallen te beschermen, heeft Microsoft toonaangevende processen en hulpprogramma's ontwikkeld die een hoge mate van vertrouwen bieden in de azure-isolatiegarantie. Zoals beschreven in de sectie Beveiligingscontroleprocessen en -procedures verderop in dit artikel, bevat de aanpak ingebouwde fuzzing, penetratietests, levenscyclus van beveiligingsontwikkeling, verplichte beveiligingstraining, beveiligingsbeoordelingen, detectie van beveiligingsinbraak op basis van gast - bedreigingsindicatoren van de host en geautomatiseerde buildwaarschuwingen voor wijzigingen in het kwetsbaarheidsgebied voor aanvallen. Dit volwassen multidimensionale controleproces helpt de isolatiegaranties van de Azure Hypervisor te verbeteren door het risico op beveiligingsproblemen te beperken.

Opmerking

Azure heeft een toonaangevende aanpak aangenomen voor hypervisor-gebaseerde tenantscheiding, die is versterkt en verbeterd dankzij twee decennia van Microsoft-investeringen in Hyper-V-technologie voor de isolatie van virtuele machines. Het resultaat van deze aanpak is een robuuste Hypervisor waarmee tenantscheiding via 1) sterk gedefinieerde beveiligingsgrenzen, 2) diepgaande beveiligingsbeperking en 3) sterke beveiligingsgarantieprocessen wordt gewaarborgd.

Drawbridge-isolatie

Voor services die kleine verwerkingseenheden bieden met behulp van klantcode, worden aanvragen van meerdere tenants uitgevoerd binnen één VIRTUELE machine en geïsoleerd met behulp van Microsoft Drawbridge-technologie . Om beveiligingsisolatie te bieden, voert Drawbridge een gebruikersproces uit in combinatie met een lichtgewicht versie van de Windows-kernel (Bibliotheekbesturingssysteem) binnen een pico-proces. Een pico-proces is een lichtgewicht, veilige isolatiecontainer met minimaal kernel-API-oppervlak en geen directe toegang tot services of resources van het hostsysteem. De enige externe aanroepen die het pico-proces kan maken, zijn aan de Drawbridge Security Monitor via de Drawbridge Application Binary Interface (ABI), zoals weergegeven in afbeelding 8.

afbeelding 8. Procesisolatie met Drawbridge

De beveiligingsmonitor is onderverdeeld in een systeemapparaatstuurprogramma en een gebruikersmodusonderdeel. De ABI is de interface tussen het bibliotheek-besturingssysteem en de host. De volledige interface bestaat uit een gesloten set van minder dan 50 staatloze functie-aanroepen:

• Down-aanroepen van het pico-proces naar het hostbesturingssysteem ondersteunen abstracties zoals threads, virtueel geheugen en I/O-streams.
• Oproepen naar het pico-proces voeren initialisatie uit, retourneren uitzonderingsinformatie en draaien binnen een nieuwe thread.

De semantiek van de interface is opgelost en ondersteunt de algemene abstracties die toepassingen van elk besturingssysteem vereisen. Met dit ontwerp kunnen het bibliotheek-besturingssysteem en de host afzonderlijk worden ontwikkeld.

De ABI wordt binnen twee onderdelen geïmplementeerd:

• De Pal (Platform Adaptation Layer) wordt uitgevoerd als onderdeel van het pico-proces.
• De host-implementatie wordt uitgevoerd als onderdeel van de host.

Pico-processen worden gegroepeerd in isolatie-eenheden, sandboxes genoemd. De sandbox definieert de toepassingen, het bestandssysteem en externe resources die beschikbaar zijn voor de pico-processen. Wanneer een proces binnen een pico-proces een nieuw subproces aanmaakt, wordt het uitgevoerd met een eigen Library OS in een afzonderlijk pico-proces binnen dezelfde sandbox. Elke sandbox communiceert met de beveiligingsmonitor en kan niet communiceren met andere sandboxes, behalve via toegestane I/O-kanalen (sockets, benoemde pijpen, enzovoort), die expliciet moeten worden toegestaan door de configuratie, afhankelijk van de servicebehoeften. Het resultaat is dat code die wordt uitgevoerd in een pico-proces alleen toegang heeft tot zijn eigen resources en niet rechtstreeks het Host-systeem of een geplaatste sandbox kan aanvallen. Het is alleen mogelijk om objecten in een eigen sandbox te beïnvloeden.

Wanneer het pico-proces systeembronnen nodig heeft, moet het de Drawbridge-host aanroepen om deze aan te vragen. Het normale pad voor een virtueel gebruikersproces zou zijn om het bibliotheekbesturingssysteem aan te roepen om resources aan te vragen en het bibliotheekbesturingssysteem zou vervolgens een oproep doen naar de ABI. Tenzij het beleid voor resourcetoewijzing is ingesteld in het stuurprogramma zelf, verwerkt de beveiligingsmonitor de ABI-aanvraag door het beleid te controleren om te zien of de aanvraag is toegestaan en vervolgens de aanvraag te onderhouden. Dit mechanisme wordt gebruikt voor alle systeemprimitief en zorgt er daarom voor dat de code die in het pico-proces wordt uitgevoerd, de resources van de hostcomputer niet kan misbruiken.

Naast geïsoleerd worden binnen sandboxes, worden pico-processen ook aanzienlijk van elkaar geïsoleerd. Elk pico-proces bevindt zich in een eigen adresruimte voor virtueel geheugen en voert een eigen kopie van het bibliotheekbesturingssysteem uit met een eigen kernel in de gebruikersmodus. Telkens wanneer een gebruikersproces wordt gestart in een Drawbridge-sandbox, wordt een nieuw exemplaar van het bibliotheekbesturingssystemen opgestart. Hoewel deze taak tijdrovender is in vergelijking met het starten van een niet-geïsoleerd proces in Windows, is het aanzienlijk sneller dan het opstarten van een VIRTUELE machine tijdens het uitvoeren van logische isolatie.

Een normaal Windows-proces kan meer dan 1200 functies aanroepen die leiden tot toegang tot de Windows-kernel; de gehele interface voor een pico-proces bestaat echter uit minder dan 50 aanroepen naar de Host. De meeste toepassingsaanvragen voor besturingssysteemservices worden verwerkt door het bibliotheekbesturingssysteem binnen de adresruimte van het pico-proces. Door een aanzienlijk kleinere interface voor de kernel te bieden, creëert Drawbridge een veiligere en geïsoleerde besturingssysteemomgeving waarin toepassingen veel minder kwetsbaar zijn voor wijzigingen in het hostsysteem en incompatibiliteit die wordt geïntroduceerd door nieuwe besturingssysteemreleases. Belangrijker is dat een Drawbridge pico-proces een sterk geïsoleerde container is waarin niet-vertrouwde code van zelfs de meest schadelijke bronnen kan worden uitgevoerd zonder dat het hostsysteem in gevaar kan komen. De Host gaat ervan uit dat er geen code die wordt uitgevoerd binnen het pico-proces kan worden vertrouwd. De host valideert alle aanvragen van het pico-proces met beveiligingscontroles.

Net als een virtuele machine is het pico-proces veel gemakkelijker te beveiligen dan een traditionele besturingssysteeminterface, omdat het aanzienlijk kleiner, stateloos is en vast gedefinieerde en eenvoudig te beschrijven semantiek heeft. Een ander extra voordeel van de kleine ABI / stuurprogramma syscall-interface is de mogelijkheid om de stuurprogrammacode met weinig moeite te controleren/ te fuzzen. Syscall fuzzers kunnen bijvoorbeeld de ABI in een relatief korte tijd met hoge dekkingsnummers fuzzen.

Isolatie op basis van gebruikerscontext

In gevallen waarin een Azure-service bestaat uit door Microsoft beheerde code en klantcode niet mag worden uitgevoerd, wordt de isolatie geleverd door een gebruikerscontext. Deze services accepteren alleen invoer van gebruikersconfiguraties en gegevens voor verwerking. Willekeurige code is niet toegestaan. Voor deze services wordt een gebruikerscontext verstrekt om de gegevens vast te stellen die toegankelijk zijn en welke bewerkingen op basis van azure-toegangsbeheer (Azure RBAC) zijn toegestaan. Deze context wordt tot stand gebracht door Microsoft Entra-id, zoals eerder beschreven in de sectie Isolatie op basis van identiteit . Zodra de gebruiker is geïdentificeerd en geautoriseerd, maakt de Azure-service een toepassingsgebruikerscontext die is gekoppeld aan de aanvraag wanneer deze wordt uitgevoerd, zodat de gebruikersbewerkingen worden gescheiden en correct worden geïsoleerd.

Fysieke isolatie

Naast robuuste logische rekenisolatie die standaard beschikbaar is voor alle Azure-tenants, kunt u, als u behoefte hebt aan fysieke rekenisolatie, gebruikmaken van Azure Dedicated Host of Geïsoleerde virtuele machines, die beide zijn toegewezen aan één klant.

Opmerking

Fysieke tenantisolatie verhoogt de implementatiekosten en is mogelijk niet vereist in de meeste scenario's, gezien de sterke logische isolatiegaranties van Azure.

Azure Dedicated Host (Azure Toegewijde Host)

Azure Dedicated Host fysieke servers biedt die een of meer Virtuele Azure-machines kunnen hosten en toegewezen zijn aan één Azure-abonnement. U kunt toegewezen hosts inrichten in een regio, beschikbaarheidszone en foutdomein. Vervolgens kunt u Windows, Linux en SQL Server rechtstreeks op Azure-VM's in ingerichte hosts plaatsen met behulp van de configuratie die het beste aan uw behoeften voldoet. Toegewezen host biedt hardware-isolatie op het niveau van de fysieke server, zodat u uw Azure-VM's kunt plaatsen op een geïsoleerde en toegewezen fysieke server waarop alleen de workloads van uw organisatie worden uitgevoerd om te voldoen aan de nalevingsvereisten van het bedrijf.

Opmerking

U kunt een toegewezen host implementeren met behulp van Azure Portal, Azure PowerShell en Azure CLI.

U kunt virtuele Windows- en Linux-machines implementeren op toegewezen hosts door het server- en CPU-type, het aantal kernen en extra functies te selecteren. Dedicated Host maakt controle over platformonderhoudsgebeurtenissen mogelijk door u in te schakelen voor een onderhoudsvenster om potentiële gevolgen voor uw ingerichte services te verminderen. De meeste onderhoudsevenementen hebben weinig tot geen invloed op uw VM's; Als u zich echter in een sterk gereglementeerde branche of met een gevoelige workload bevindt, wilt u mogelijk controle hebben over mogelijke onderhoudsimpacten.

Microsoft biedt gedetailleerde richtlijnen voor het inrichten van virtuele Windows - en Linux-machines met behulp van Azure Portal, Azure PowerShell en Azure CLI. Tabel 5 bevat een overzicht van de beschikbare beveiligingsrichtlijnen voor uw virtuele machines die zijn ingericht in Azure.

Tabel 5. Beveiligingsrichtlijnen voor virtuele Azure-machines

VM	Beveiligingsrichtlijnen
Windows	Beveiligingsbeleid Azure Disk Encryption Ingebouwde beveiligingsmaatregelen Aanbevelingen voor beveiliging
Linux	Beveiligingsbeleid Azure Disk Encryption Ingebouwde beveiligingsmaatregelen Aanbevelingen voor beveiliging

Geïsoleerde virtuele machines

Azure Compute biedt grootten van virtuele machines die zijn geïsoleerd voor een specifiek hardwaretype en toegewezen aan één klant. Met deze VM-exemplaren kunnen uw workloads worden geïmplementeerd op toegewezen fysieke servers. Het gebruik van geïsoleerde VM's garandeert in wezen dat uw VIRTUELE machine de enige is die wordt uitgevoerd op dat specifieke serverknooppunt. U kunt er ook voor kiezen om de resources op deze geïsoleerde VM's verder te verdelen met behulp van Azure-ondersteuning voor geneste virtuele machines.

Netwerkisolatie

De logische isolatie van tenantinfrastructuur in een openbare multitenantcloud is essentieel voor het onderhouden van beveiliging. Het overkoepelende principe voor een gevirtualiseerde oplossing is om alleen verbindingen en communicatie toe te staan die nodig zijn om die gevirtualiseerde oplossing te laten werken, waarbij alle andere poorten en verbindingen standaard worden geblokkeerd. Azure Virtual Network (VNet) helpt ervoor te zorgen dat uw privénetwerkverkeer logisch wordt geïsoleerd van verkeer dat tot andere klanten behoort. Virtuele machines (VM's) in één VNet kunnen niet rechtstreeks communiceren met VM's in een ander VNet, zelfs niet als beide VNets door dezelfde klant worden gemaakt. Netwerkisolatie zorgt ervoor dat de communicatie tussen uw VM's privé blijft binnen een VNet. U kunt uw VNets verbinden via VNet-peering of VPN-gateways, afhankelijk van uw connectiviteitsopties, waaronder bandbreedte, latentie en versleutelingsvereisten.

In deze sectie wordt beschreven hoe Azure isolatie van netwerkverkeer tussen tenants biedt en die isolatie afdwingt met cryptografische zekerheid.

Scheiding van tenantnetwerkverkeer

Virtuele netwerken (VNets) bieden isolatie van netwerkverkeer tussen tenants als onderdeel van hun fundamentele ontwerp. Uw Azure-abonnement kan meerdere logisch geïsoleerde privénetwerken bevatten en firewalls, taakverdeling en netwerkadresomzetting bevatten. Elk VNet is standaard geïsoleerd van andere VNets. Meerdere implementaties binnen uw abonnement kunnen op hetzelfde VNet worden geplaatst en vervolgens met elkaar communiceren via privé-IP-adressen.

Netwerktoegang tot VM's wordt beperkt door pakketfiltering aan de netwerkrand, bij load balancers en op host-besturingssysteemniveau. Bovendien kunt u uw hostfirewalls configureren om de connectiviteit verder te beperken, waarbij u voor elke luisterende poort opgeeft of verbindingen worden geaccepteerd via internet of alleen vanuit rolinstanties binnen dezelfde cloudservice of VNet.

Azure biedt netwerkisolatie voor elke implementatie en dwingt de volgende regels af:

• Verkeer tussen VM's gaat altijd via vertrouwde pakketfilters.
  • Protocollen zoals Address Resolution Protocol (ARP), Dynamic Host Configuration Protocol (DHCP) en ander OSI Layer-2-verkeer van een VIRTUELE machine worden beheerd met snelheidsbeperking en bescherming tegen adresvervalsing.
  • VM's kunnen geen verkeer vastleggen op het netwerk dat niet voor hen is bedoeld.
• Uw VM's kunnen geen verkeer verzenden naar privé-interfaces en infrastructuurservices van Azure of naar VM's die behoren tot andere klanten. Uw VM's kunnen alleen communiceren met andere VM's die eigendom zijn van of worden beheerd door u en met service-eindpunten van de Azure-infrastructuur die bedoeld zijn voor openbare communicatie.
• Wanneer u een VIRTUELE machine op een VNet plaatst, krijgt die VM een eigen adresruimte die onzichtbaar is en dus niet bereikbaar is vanaf VM's buiten een implementatie of VNet (tenzij deze is geconfigureerd om zichtbaar te zijn via openbare IP-adressen). Uw omgeving is alleen geopend via de poorten die u opgeeft voor openbare toegang; als de VM is gedefinieerd om een openbaar IP-adres te hebben, zijn alle poorten geopend voor openbare toegang.

Pakketstroom- en netwerkpadbeveiliging

Het hyperscale-netwerk van Azure is ontworpen om het volgende te bieden:

• Uniforme hoge capaciteit tussen servers.
• Prestatie-isolatie tussen services, inclusief klanten.
• Ethernet Layer-2 semantiek.

Azure maakt gebruik van verschillende netwerk implementaties om deze doelen te bereiken:

• Platte adressering zodat service-exemplaren overal in het netwerk kunnen worden geplaatst.
• Taakverdeling om verkeer gelijkmatig over netwerkpaden te verdelen.
• Op eindsystemen gebaseerde adresresolutie om te kunnen schalen naar grote servergroepen, zonder extra complexiteit toe te voegen aan het netwerkcontrolevlak.

Deze implementaties geven elke service de illusie dat alle servers die eraan zijn toegewezen, en alleen die servers, zijn verbonden door één niet-uitferende Ethernet-switch ( een Virtual Layer 2 (VL2) - en deze illusie te behouden, zelfs als de grootte van elke service varieert van één server tot honderdduizenden. Deze VL2-implementatie zorgt voor isolatie van de verkeersprestaties, waardoor het onmogelijk is dat het verkeer van een dienst wordt beïnvloed door het verkeer van een andere dienst, evenals het zou zijn als elke dienst verbonden was met een afzonderlijke fysieke switch.

In deze sectie wordt uitgelegd hoe pakketten door het Azure-netwerk stromen en hoe het topologie-, routeringsontwerp en directorysysteem worden gecombineerd om de onderliggende netwerkinfrastructuur te virtualiseren, waardoor de illusie ontstaat dat servers zijn verbonden met een grote, niet-interfererende laag-2-switch in het datacenter.

Het Azure-netwerk maakt gebruik van twee verschillende IP-adresfamilies:

• Klantadres (CA) is het door de klant gedefinieerde/gekozen VNet-IP-adres, ook wel virtual IP (VIP) genoemd. De netwerkinfrastructuur werkt met behulp van CA's, die extern routeerbaar zijn. Alle switches en interfaces zijn CA's toegekend, en switches draaien een op IP gebaseerd (Layer-3) link-state routeringsprotocol dat uitsluitend deze CA's verspreidt. Met dit ontwerp kunnen switches de volledige topologie op switchniveau verkrijgen en pakketten doorsturen die zijn ingekapseld met CA's langs kortste paden.
• Provideradres (PA) is het door Azure toegewezen interne infrastructuuradres dat niet zichtbaar is voor gebruikers en ook wel Dynamic IP (DIP) wordt genoemd. Geen verkeer gaat rechtstreeks van internet naar een server; al het verkeer van internet moet via een Software Load Balancer (SLB) gaan en worden ingekapseld om de interne Azure-adresruimte te beveiligen door alleen pakketten te routeren naar geldige interne IP-adressen en poorten van Azure. Network Address Translation (NAT) scheidt intern netwerkverkeer van extern verkeer. Intern verkeer maakt gebruik van RFC 1918-adresruimte of privéadresruimte , de provideradressen (PA's) die niet extern routeerbaar zijn. De vertaling wordt uitgevoerd bij de SLB's. Klantadressen (CA's) die extern routeerbaar zijn, worden omgezet in interne provideradressen (CA's) die alleen routeerbaar zijn in Azure. Deze adressen blijven ongewijzigd, ongeacht hoe de locaties van hun servers veranderen vanwege migratie van virtuele machines of het opnieuw inrichten.

Elke PA is gekoppeld aan een CA, de id van de ToR-switch (Top of Rack) waarmee de server is verbonden. VL2 maakt gebruik van een schaalbaar, betrouwbaar directoriesysteem voor het opslaan en onderhouden van de toewijzing van PA's aan CA's. Deze toewijzing wordt gemaakt wanneer servers worden ingericht voor een service en toegewezen PA-adressen. Een agent die wordt uitgevoerd in de netwerkstack op elke server, de VL2-agent genoemd, roept de resolutiedienst van het adreslijstsysteem aan om de werkelijke locatie van de bestemming te leren en stuurt het oorspronkelijke pakket door via een tunnel naar daar.

Azure wijst IP-adressen van servers toe die alleen fungeren als namen, zonder topologische betekenis. Het VL2-adresseringsschema van Azure scheidt deze servernamen (PAs) van hun locaties (CA's). De crux van het aanbieden van laag-2-semantiek is dat servers geloven dat ze één groot IP-subnet delen, dat wil zeggen de volledige PA-ruimte, met andere servers in dezelfde service, door het elimineren van de Address Resolution Protocol (ARP) en DHCP (Dynamic Host Configuration Protocol) schaalproblemen die grote Ethernet-implementaties plagen.

Afbeelding 9 toont een voorbeeldpakketstroom waarbij afzender S pakketten naar bestemming D verzendt via een willekeurig gekozen tussenliggende switch met behulp van IP-in-IP inkapseling. PA's zijn van 20/8 en CA's van 10/8. H(ft) geeft een hash aan van de 5-tuple, die bestaat uit bron-IP, bronpoort, doel-IP, doelpoort en protocoltype. De ToR vertaalt de PA naar de CA, en verzendt naar de tussenliggende switch, die het naar de doel-CA ToR-switch stuurt en vervolgens vertaalt naar de doel-PA.

afbeelding 9. Voorbeeldpakketstroom

Een server kan geen pakketten verzenden naar een PA als de adreslijstservice weigert deze te voorzien van een CA waarmee de pakketten kunnen worden gerouteerd, wat betekent dat de adreslijstservice beleidsregels voor toegangsbeheer afdwingt. Aangezien het adreslijstsysteem weet welke server de aanvraag indient bij het verwerken van een zoekactie, kan het fijnmazige isolatiebeleid afdwingen. Het kan bijvoorbeeld een beleid afdwingen dat alleen servers die deel uitmaken van dezelfde service met elkaar kunnen communiceren.

Verkeersstroompatronen

Om verkeer te routeren tussen servers, die PA-adressen gebruiken, op een onderliggend netwerk dat routes kent voor CA-adressen, legt de VL2-agent op elke server pakketten van de host vast en worden ze ingekapseld met het CA-adres van de ToR-switch van de bestemming. Zodra het pakket bij de CA aankomt (dat wil zeggen, de bestemmings-ToR-switch), wordt het pakket door de bestemmings-ToR-switch gedecapsuleerd en geleverd aan de bestemmings-PA die in de binnenste header zit. Het pakket wordt eerst geleverd aan een van de tussenliggende switches, ingekapseld door de switch, geleverd aan de CA van de ToR, opnieuw ingekapseld en ten slotte verzonden naar de bestemming. Deze benadering wordt weergegeven in afbeelding 10 met behulp van twee mogelijke verkeerspatronen: 1) extern verkeer (oranje lijn) dat via Azure ExpressRoute of internet naar een VNet loopt en 2) intern verkeer (blauwe lijn) tussen twee VNets. Beide verkeersstromen volgen een vergelijkbaar patroon om netwerkverkeer te isoleren en te beveiligen.

Afbeelding 10. Scheiding van tenantnetwerkverkeer met behulp van VNets

Extern verkeer (oranje lijn): Voor extern verkeer biedt Azure meerdere beveiligingslagen om isolatie af te dwingen, afhankelijk van verkeerspatronen. Wanneer u een openbaar IP-adres op uw VNet-gateway plaatst, wordt verkeer vanaf het openbare internet of uw on-premises netwerk dat is bestemd voor dat IP-adres doorgestuurd naar een Internet Edge-router. Als u persoonlijke peering tot stand brengt via een ExpressRoute-verbinding, is deze ook verbonden met een Azure-VNet via VNet Gateway. Met deze configuratie wordt de verbinding van het fysieke circuit uitgelijnd en wordt de privé-IP-adresruimte van de on-premises locatie adresseerbaar. Azure gebruikt vervolgens Border Gateway Protocol (BGP) om routeringsgegevens te delen met het on-premises netwerk om end-to-end-connectiviteit tot stand te brengen. Wanneer de communicatie begint met een resource in het VNet, loopt het netwerkverkeer normaal door totdat het een Microsoft ExpressRoute Edge-router (MSEE) bereikt. In beide gevallen bieden VNets de middelen voor azure-VM's om te fungeren als onderdeel van uw on-premises netwerk. Er wordt een cryptografisch beveiligde IPsec-/IKE-tunnel tot stand gebracht tussen Azure en uw interne netwerk (bijvoorbeeld via Azure VPN Gateway of Persoonlijke Peering van Azure ExpressRoute), waardoor de VIRTUELE machine veilig verbinding kan maken met uw on-premises resources alsof deze zich rechtstreeks in dat netwerk bevond.

Bij de Internet Edge-router of de MSEE-router wordt het pakket ingekapseld met behulp van Generic Routing Encapsulation (GRE). Deze inkapseling maakt gebruik van een unieke id die specifiek is voor de VNet-bestemming en het doeladres, dat wordt gebruikt om het verkeer naar het geïdentificeerde VNet op de juiste manier te routeren. Bij het bereiken van de VNet-gateway, een speciaal VNet dat alleen wordt gebruikt om verkeer van buiten een Azure-VNet te accepteren, wordt de inkapseling geverifieerd door de Azure-netwerkinfrastructuur om ervoor te zorgen dat: a) het eindpunt dat het pakket ontvangt een overeenkomst is met de unieke VNet-id die wordt gebruikt om de gegevens te routeren, en b) het aangevraagde doeladres bestaat in dit VNet. Na verificatie wordt het pakket gerouteerd als intern verkeer van de VNet-gateway naar het uiteindelijke aangevraagde doeladres in het VNet. Deze aanpak zorgt ervoor dat verkeer van externe netwerken alleen naar Azure VNet gaat waarvoor het is bestemd, waardoor isolatie wordt afgedwongen.

Intern verkeer (blauwe lijn): intern verkeer maakt ook gebruik van GRE-inkapseling/tunneling. Wanneer twee resources in een Azure-VNet communicatie tussen elkaar proberen tot stand te brengen, neemt de Azure-netwerkinfrastructuur contact op met de Azure VNet-routeringsdirectoryservice die deel uitmaakt van de Azure-netwerkinfrastructuur. De adreslijstservices gebruiken het klantadres (CA) en het aangevraagde doeladres om het provideradres (PA) te bepalen. Deze informatie, waaronder de VNet-id, CA en PA, wordt vervolgens gebruikt om het verkeer in te kapselen met GRE. Het Azure-netwerk gebruikt deze informatie om de ingekapselde gegevens correct te routeren naar de juiste Azure-host met behulp van de PA. De inkapseling wordt gecontroleerd door de Azure-netwerkinfrastructuur om het volgende te bevestigen:

1. De PA is een overeenkomstig element.
2. De CA bevindt zich bij deze PA en
3. De VNet-identificatie komt overeen.

Zodra alle drie zijn geverifieerd, wordt de inkapseling verwijderd en als normaal verkeer naar de CA doorgestuurd, bijvoorbeeld naar een VM-eindpunt. Deze benadering biedt VNet-isolatiecontrole op basis van de juiste verkeersroutering tussen cloudservices.

Azure VNets implementeren verschillende mechanismen om verkeer tussen tenants te beveiligen. Deze mechanismen zijn afgestemd op bestaande industriestandaarden en beveiligingsprocedures en voorkomen bekende aanvalsvectoren, waaronder:

• Ip-adresvervalsing voorkomen : wanneer ingekapseld verkeer wordt verzonden door een VNet, controleert de service de informatie aan het ontvangende einde van de verzending. Het verkeer wordt aan het begin van de verzending afzonderlijk opgezoekd en ingekapseld en opnieuw geverifieerd op het ontvangende eindpunt om ervoor te zorgen dat de overdracht correct is uitgevoerd. Deze verificatie wordt uitgevoerd met een interne VNet-functie met de naam SpoofGuard, waarmee wordt gecontroleerd of de bron en bestemming geldig zijn en mogen communiceren, waardoor ongelijkheden in verwachte inkapselingspatronen worden voorkomen die anders spoofing mogelijk maken. De GRE-inkapselingsprocessen verhinderen spoofing omdat GRE-inkapseling en versleuteling die niet door de Azure-netwerkinfrastructuur worden uitgevoerd, worden beschouwd als verkeer dat wordt verwijderd.
• Netwerksegmentatie bieden voor klanten met overlappende netwerkruimten : de implementatie van Azure VNet is afhankelijk van vastgestelde tunnelingstandaarden zoals de GRE, waardoor het gebruik van klantspecifieke unieke id's (VNet-id's) in de cloud mogelijk is. De VNet-id's worden gebruikt als scopings-id's. Deze aanpak zorgt ervoor dat u altijd binnen uw unieke adresruimte werkt, waarbij de adresruimten tussen tenants en de Azure-netwerkinfrastructuur overlappen. Alles wat niet is ingekapseld met een geldige VNet-id, wordt geblokkeerd in de Azure-netwerkinfrastructuur. In het eerder beschreven voorbeeld wordt ingekapseld verkeer dat niet door de Azure-netwerkinfrastructuur wordt uitgevoerd, verwijderd.
• Voorkomen van verkeer tussen VNets – Het voorkomen van verkeer tussen VNets gebeurt via dezelfde mechanismen die adresoverlap aanpakken en spoofing voorkomen. Verkeer tussen VNets is onmogelijk gemaakt door het gebruik van unieke VNet-id's die per tenant zijn vastgesteld, in combinatie met verificatie van al het verkeer bij de bron en bestemming. Gebruikers hebben geen toegang tot de onderliggende transmissiemechanismen die afhankelijk zijn van deze id's om de inkapseling uit te voeren. Daarom zou elke poging om deze mechanismen te inkapselen en simuleren ertoe leiden dat verkeer verloren gaat.

Naast deze sleutelbeveiligingen wordt al het onverwachte verkeer dat afkomstig is van internet standaard verwijderd. Elk pakket dat het Azure-netwerk binnenkomt, zal eerst een Edge-router tegenkomen. Edge-routers staan opzettelijk al het binnenkomende verkeer toe in het Azure-netwerk, met uitzondering van vervalst verkeer. Deze basisverkeersfiltering beschermt het Azure-netwerk tegen bekend slecht schadelijk verkeer. Azure implementeert ook DDoS-beveiliging op de netwerklaag, verzamelt logboeken om verkeer te beperken of te blokkeren op basis van realtime en historische gegevensanalyse en beperkt aanvallen op aanvraag.

Bovendien blokkeert de Azure-netwerkinfrastructuur verkeer van IP-adressen die afkomstig zijn uit de Azure-netwerkinfrastructuurruimte die zijn vervalst. De Azure-netwerkinfrastructuur maakt gebruik van GRE en Virtual Extensible LAN (VXLAN) om te controleren of al het toegestane verkeer door Azure wordt beheerd en al het niet-Azure GRE-verkeer wordt geblokkeerd. Door GRE-tunnels en VXLAN te gebruiken om verkeer te segmenteren met behulp van unieke sleutels van klanten, voldoet Azure aan RFC 3809 en RFC 4110. Wanneer u Azure VPN Gateway gebruikt in combinatie met ExpressRoute, voldoet Azure aan RFC 4111 en RFC 4364. Met een uitgebreide benadering voor isolatie die extern en intern netwerkverkeer omvat, bieden Azure-VNets u de zekerheid dat Azure verkeer tussen VNets met succes routeert, de juiste netwerksegmentatie toestaat voor tenants met overlappende adresruimten en ip-adresvervalsing voorkomt.

U kunt ook Azure-services gebruiken om uw resources verder te isoleren en te beveiligen. Met behulp van netwerkbeveiligingsgroepen (NSG's), een functie van Azure Virtual Network, kunt u verkeer filteren op bron- en doel-IP-adres, poort en protocol via meerdere inkomende en uitgaande beveiligingsregels, die in wezen fungeren als een gedistribueerde virtuele firewall en op IP gebaseerde netwerktoegangsbeheerlijst (ACL). U kunt een NSG toepassen op elke NIC in een virtuele machine, een NSG toepassen op het subnet waarmee een NIC of een andere Azure-resource is verbonden, en rechtstreeks op virtuele-machineschaalsets, zodat u de infrastructuur nauwkeuriger kunt beheren.

Op de infrastructuurlaag implementeert Azure een Hypervisor-firewall om alle tenants binnen virtuele machines bovenop de Hypervisor te beveiligen van ongeautoriseerde toegang. Deze Hypervisor-firewall wordt gedistribueerd als onderdeel van de NSG-regels die zijn geïmplementeerd op de host, geïmplementeerd in de Hypervisor en geconfigureerd door de Fabric Controller-agent, zoals wordt weergegeven in afbeelding 4. De hostbesturingssysteemexemplaren gebruiken de ingebouwde Windows Firewall om fijnmazige ACL's te implementeren met een grotere granulariteit dan router-ACL's. Ze worden onderhouden door dezelfde software die tenants inricht, zodat ze nooit verouderd zijn. De fijnmazige ACL's worden toegepast met behulp van het MCF (Machine Configuration File) op Windows Firewall.

Boven aan de besturingssysteemstack bevindt zich het gastbesturingssysteem dat u als besturingssysteem gebruikt. Deze laag staat standaard geen binnenkomende communicatie met de cloudservice of het virtuele netwerk toe, waardoor deze in feite deel uitmaakt van een particulier netwerk. Voor PaaS-web- en werkrollen is externe toegang niet standaard toegestaan. U kunt RDP-toegang (Remote Desktop Protocol) inschakelen als een expliciete optie. Voor IaaS-VM's die zijn gemaakt met behulp van Azure Portal, worden RDP- en externe PowerShell-poorten standaard geopend; poortnummers worden echter willekeurig toegewezen. Voor IaaS-VM's die zijn gemaakt via PowerShell, moeten RDP- en externe PowerShell-poorten expliciet worden geopend. Als de beheerder ervoor kiest om de RDP- en externe PowerShell-poorten open te houden voor internet, moet het account dat RDP- en PowerShell-verbindingen mag maken, worden beveiligd met een sterk wachtwoord. Zelfs als poorten open zijn, kunt u ACL's definiëren op de openbare IP-adressen voor extra beveiliging, indien gewenst.

Service-tags

U kunt servicetags van virtual network gebruiken om netwerkisolatie te bereiken en uw Azure-resources te beveiligen tegen internet terwijl u toegang krijgt tot Azure-services met openbare eindpunten. Met servicetags kunt u besturingselementen voor netwerktoegang definiëren voor netwerkbeveiligingsgroepen of Azure Firewall. Een servicetag vertegenwoordigt een groep IP-adresvoorvoegsels van een bepaalde Azure-service. Microsoft beheert de adresvoorvoegsels die worden omvat door de servicetag en werkt de servicetag automatisch bij naarmate de adressen veranderen, waardoor de complexiteit van frequente updates voor netwerkbeveiligingsregels wordt verminderd.

Opmerking

U kunt regels voor binnenkomende/uitgaande netwerkbeveiligingsgroepen maken om verkeer van/naar internet te weigeren en verkeer naar/van Azure toe te staan. Servicetags zijn beschikbaar voor veel Azure-services voor gebruik in regels voor netwerkbeveiligingsgroepen.

Extra resources:

• Beschikbare servicetags voor specifieke Azure-services

Azure Private Link

U kunt Private Link gebruiken om toegang te krijgen tot Azure PaaS-services en door Azure gehoste klant-/partnerservices via een privé-eindpunt in uw VNet, zodat verkeer tussen uw VNet en de service via het wereldwijde backbone-netwerk van Microsoft wordt uitgevoerd. Deze aanpak elimineert de noodzaak om de service beschikbaar te maken voor het openbare internet. U kunt ook uw eigen private link-service maken in uw eigen VNet en deze aan uw klanten leveren.

Azure-privé-eindpunt is een netwerkinterface die u privé en veilig verbindt met een service die wordt mogelijk gemaakt door Private Link. Privé-eindpunt maakt gebruik van een privé-IP-adres van uw VNet, waardoor de service effectief in uw VNet wordt geplaatst.

Vanuit het oogpunt van netwerkisolatie zijn de belangrijkste voordelen van Private Link:

• U kunt uw VNet verbinden met services in Azure zonder een openbaar IP-adres bij de bron of bestemming. Private Link verwerkt de connectiviteit tussen de service en de consumenten via het wereldwijde backbone-netwerk van Microsoft.
• U hebt toegang tot services die worden uitgevoerd in Azure vanaf on-premises via privépeering van Azure ExpressRoute, VPN-tunnels en gekoppelde virtuele netwerken met behulp van privé-eindpunten. Private Link elimineert de noodzaak om Microsoft-peering in te stellen of via internet te gaan om de service te bereiken.
• U kunt privé verbinding maken met services die worden uitgevoerd in andere Azure-regio's.

Opmerking

U kunt Azure Portal gebruiken om privé-eindpuntverbindingen op Azure PaaS-resources te beheren. Voor Private Link-services in eigendom van de klant/partner zijn Azure Power Shell en Azure CLI de voorkeursmethoden voor het beheren van privé-eindpuntverbindingen.

Extra resources:

• Privé-eindpuntverbindingen beheren in Azure PaaS-resources
• Privé-eindpuntverbindingen beheren op een Private Link-service die eigendom is van een klant of partner

Gegevensversleuteling tijdens overdracht

Azure biedt veel opties voor het versleutelen van gegevens tijdens overdracht . Gegevensversleuteling in transit isoleert uw netwerkverkeer tegen ander verkeer en beschermt gegevens tegen onderschepping. Gegevens die onderweg zijn, zijn van toepassing op scenario's waarbij gegevens worden verzonden tussen:

• Uw eindgebruikers en Azure-service
• Uw on-premises datacenter en Azure-regio
• Microsoft-datacenters als onderdeel van de verwachte Azure-servicebewerking

De verbinding van de eindgebruiker met de Azure-service

Transport Layer Security (TLS): Azure maakt gebruik van het TLS-protocol om gegevens te beveiligen wanneer deze onderweg zijn tussen uw eindgebruikers en Azure-services. De meeste eindgebruikers maken via internet verbinding met Azure en de nauwkeurige routering van netwerkverkeer is afhankelijk van de vele netwerkproviders die bijdragen aan de internetinfrastructuur. Zoals aangegeven in de Microsoft Products and Services Data Protection Addendum (DPA) heeft Microsoft geen controle over de regio's waaruit u of uw eindgebruikers toegang hebben tot of verplaatsen van klantgegevens.

Belangrijk

U kunt de beveiliging verbeteren door versleuteling in te schakelen tijdens de overdracht. U kunt Application Gateway bijvoorbeeld gebruiken om end-to-end-versleuteling van netwerkverkeer te configureren en te vertrouwen op Key Vault-integratie voor TLS-beëindiging.

Tussen Azure-services wordt verkeer van en naar de service beveiligd door TLS 1.2 met RSA-2048 voor sleuteluitwisseling en AES-256 voor gegevensversleuteling. De bijbehorende cryptomodules zijn FIPS 140 gevalideerd als onderdeel van het Microsoft Windows FIPS-validatieprogramma.

TLS biedt sterke verificatie, berichtprivacy en integriteit. Perfect Forward Secrecy (PFS) beschermt verbindingen tussen uw clientsystemen en Microsoft-cloudservices door een unieke sessiesleutel te genereren voor elke sessie die u start. PFS beschermt eerdere sessies tegen mogelijke toekomstige sleutelcompromitties. Deze combinatie maakt het moeilijker om gegevens tijdens het transport te onderscheppen en te openen.

In-transit-versleuteling voor VM's: externe sessies naar Windows- en Linux-VM's die zijn geïmplementeerd in Azure, kunnen worden uitgevoerd via protocollen die ervoor zorgen dat gegevensversleuteling wordt verzonden. Het Remote Desktop Protocol (RDP) dat vanaf uw clientcomputer naar Windows- en Linux-VM's is geïnitieerd, maakt bijvoorbeeld TLS-beveiliging mogelijk voor gegevens die onderweg zijn. U kunt ook Secure Shell (SSH) gebruiken om verbinding te maken met linux-VM's die worden uitgevoerd in Azure. SSH is een versleuteld verbindingsprotocol dat standaard beschikbaar is voor extern beheer van Linux-VM's die worden gehost in Azure.

Belangrijk

Bekijk de aanbevolen procedures voor netwerkbeveiliging, waaronder richtlijnen voor het uitschakelen van RDP-/SSH-toegang tot virtuele machines vanaf internet om beveiligingsaanvallen te beperken om toegang te krijgen tot Virtuele Azure-machines. Toegang tot VM's voor extern beheer kan vervolgens worden uitgevoerd via punt-naar-site-VPN, site-naar-site-VPN of Azure ExpressRoute.

Azure Storage-transacties : bij interactie met Azure Storage via Azure Portal vinden alle transacties plaats via HTTPS. Bovendien kunt u uw opslagaccounts zo configureren dat alleen aanvragen van beveiligde verbindingen worden geaccepteerd door de eigenschap 'beveiligde overdracht vereist' in te stellen voor het opslagaccount. De optie Veilige overdracht is standaard ingeschakeld bij het maken van een opslagaccount in Azure Portal.

Azure Files biedt volledig beheerde bestandsshares in de cloud die toegankelijk zijn via het SMB-protocol (Server Message Block) van de industrie standaard. Standaard is versleuteling ingeschakeld voor alle Azure-opslagaccounts. Bij het koppelen van een share via SMB of het openen ervan via Azure Portal (of Azure PowerShell, Azure CLI en Azure SDK's), staat Azure Files alleen de verbinding toe als deze is gemaakt met SMB 3.0+ met versleuteling of via HTTPS.

Datacenterverbinding met Azure-regio

VPN-versleuteling : virtueel netwerk (VNet) biedt een middel waarmee virtuele Azure-machines (VM's) kunnen fungeren als onderdeel van uw interne (on-premises) netwerk. Met VNet kiest u de adresbereiken van niet-wereldwijd routeerbare IP-adressen die moeten worden toegewezen aan de VM's, zodat ze niet botsen met adressen die u elders gebruikt. U hebt opties om veilig verbinding te maken met een VNet vanaf uw on-premises infrastructuur of externe locaties.

• Site-naar-site (IPsec/IKE VPN-tunnel): er wordt een cryptografisch beveiligde tunnel tot stand gebracht tussen Azure en uw interne netwerk, zodat een Virtuele Azure-machine verbinding kan maken met uw back-endbronnen alsof deze zich rechtstreeks in dat netwerk bevond. Voor dit type verbinding is een VPN-apparaat vereist dat zich on-premises bevindt met een extern gericht openbaar IP-adres dat eraan is toegewezen. U kunt Azure VPN Gateway gebruiken om versleuteld verkeer tussen uw VNet en uw on-premises infrastructuur via het openbare internet te verzenden, bijvoorbeeld een site-naar-site-VPN is afhankelijk van IPsec voor transportversleuteling. VPN Gateway ondersteunt veel versleutelingsalgoritmen die door FIPS 140 worden gevalideerd. Bovendien kunt u VPN Gateway configureren voor het gebruik van aangepast IPsec-/IKE-beleid met specifieke cryptografische algoritmen en belangrijke sterke punten in plaats van te vertrouwen op het standaardBeleid van Azure. IPsec versleutelt gegevens op IP-niveau (netwerklaag 3).
• Punt-naar-site (VPN via SSTP, OpenVPN en IPsec): er wordt een beveiligde verbinding tot stand gebracht vanaf uw afzonderlijke clientcomputer naar uw VNet met behulp van SSTP (Secure Socket Tunneling Protocol), OpenVPN of IPsec. Als onderdeel van de punt-naar-site-VPN-configuratie moet u een certificaat en een VPN-clientconfiguratiepakket installeren, waarmee de clientcomputer verbinding kan maken met een virtuele machine in het VNet. Punt-naar-site-VPN-verbindingen vereisen geen VPN-apparaat of een openbaar IP-adres.

Naast het beheren van het type algoritme dat wordt ondersteund voor VPN-verbindingen, biedt Azure u de mogelijkheid om af te dwingen dat al het verkeer dat een VNet verlaat, alleen kan worden gerouteerd via een VNet-gateway (bijvoorbeeld Azure VPN Gateway). Met deze afdwinging kunt u ervoor zorgen dat verkeer mogelijk geen VNet verlaat zonder versleuteld te zijn. Een VPN Gateway kan worden gebruikt voor VNet-naar-VNet-verbindingen en biedt ook een beveiligde tunnel met IPsec/IKE. Azure VPN maakt gebruik van PSK-verificatie (Pre-Shared Key), waarbij Microsoft de PSK genereert wanneer de VPN-tunnel wordt gemaakt. U kunt de automatisch gegenereerde PSK wijzigen in uw eigen PSK.

Azure ExpressRoute-versleuteling : Met Azure ExpressRoute kunt u privéverbindingen maken tussen Microsoft-datacenters en uw on-premises infrastructuur of co-locatiefaciliteit. ExpressRoute-verbindingen gaan niet via het openbare internet en bieden lagere latentie en hogere betrouwbaarheid dan met IPsec beveiligde VPN-verbindingen. ExpressRoute-locaties zijn de toegangspunten voor de wereldwijde netwerk-backbone van Microsoft en ze komen mogelijk wel of niet overeen met de locatie van Azure-regio's. Zodra het netwerkverkeer de Microsoft-backbone binnenkomt, is het gegarandeerd dat deze privénetwerkinfrastructuur wordt doorlopen in plaats van via het openbare internet. U kunt ExpressRoute gebruiken met verschillende opties voor gegevensversleuteling, waaronder MACsec waarmee u MACsec-versleutelingssleutels kunt opslaan in Azure Key Vault. MACsec versleutelt gegevens op MAC-niveau (Media Access Control), dat wil gezegd, gegevenskoppelingslaag (netwerklaag 2). Zowel AES-128- als AES-256-blokcoderingen worden ondersteund voor versleuteling. U kunt MACsec gebruiken om de fysieke koppelingen tussen uw netwerkapparaten en Microsoft-netwerkapparaten te versleutelen wanneer u via ExpressRoute Direct verbinding maakt met Microsoft. ExpressRoute Direct maakt directe glasvezelverbindingen mogelijk van uw rand naar de Edge-routers van Microsoft Enterprise op de peeringlocaties.

U kunt IPsec inschakelen naast MACsec op uw ExpressRoute Direct-poorten, zoals wordt weergegeven in afbeelding 11. Met VPN Gateway kunt u een IPsec-tunnel instellen via Microsoft-peering van uw ExpressRoute-circuit tussen uw on-premises netwerk en uw Azure VNet. MACsec beveiligt de fysieke verbinding tussen uw on-premises netwerk en Microsoft. IPsec beveiligt de end-to-end-verbinding tussen uw on-premises netwerk en uw VNets in Azure. MACsec en IPsec kunnen onafhankelijk worden ingeschakeld.

zijn afbeelding 11. VPN- en ExpressRoute-versleuteling voor gegevens die onderweg zijn

Verkeer over de wereldwijde netwerk-backbone van Microsoft

Azure-services zoals Storage en SQL Database kunnen worden geconfigureerd voor geo-replicatie om duurzaamheid en hoge beschikbaarheid te garanderen, met name voor scenario's voor herstel na noodgevallen. Azure is afhankelijk van gekoppelde regio's voor het leveren van geografisch redundante opslag (GRS) en gekoppelde regio's worden ook aanbevolen bij het configureren van actieve geo-replicatie voor Azure SQL Database. Gekoppelde regio's bevinden zich binnen dezelfde geografie; Netwerkverkeer is echter niet gegarandeerd hetzelfde pad van de ene Azure-regio naar de andere te volgen. Om de betrouwbaarheid te bieden die nodig is voor de Azure-cloud, heeft Microsoft veel fysieke netwerkpaden met automatische routering rond storingen voor optimale betrouwbaarheid.

Bovendien wordt al het Verkeer van Azure binnen een regio of tussen regio's versleuteld door Microsoft met behulp van MACsec, dat afhankelijk is van AES-128-blokcodering voor versleuteling. Dit verkeer blijft volledig binnen de wereldwijde netwerk-backbone van Microsoft en voert nooit het openbare internet in. De backbone is een van de grootste ter wereld met meer dan 250.000 km aan verlichte glasvezel- en onderzeese kabelsystemen.

Belangrijk

Bekijk de best practices van Azure voor de beveiliging van gegevens die worden verzonden om ervoor te zorgen dat alle gegevens in transit worden versleuteld. Voor belangrijke Azure PaaS-opslagservices (bijvoorbeeld Azure SQL Database, Azure SQL Managed Instance en Azure Synapse Analytics), wordt gegevensversleuteling in transit standaard afgedwongen.

Virtuele netwerkapparaten van derden

Azure biedt u veel functies waarmee u uw beveiligings- en isolatiedoelen kunt bereiken, waaronder Microsoft Defender for Cloud, Azure Monitor, Azure Firewall, VPN Gateway, netwerkbeveiligingsgroepen, Application Gateway, Azure DDoS Protection, Network Watcher, Microsoft Sentinel en Azure Policy. Naast de ingebouwde mogelijkheden die Azure biedt, kunt u virtuele netwerkapparaten van derden gebruiken om tegemoet te komen aan uw specifieke vereisten voor netwerkisolatie en tegelijkertijd bestaande interne vaardigheden toe te passen. Azure ondersteunt veel apparaten, waaronder aanbiedingen van F5, Palo Alto Networks, Cisco, Check Point, Barracuda, Citrix, Fortinet en vele andere. Netwerkapparaten ondersteunen netwerkfunctionaliteit en -services in de vorm van VM's in uw virtuele netwerken en implementaties.

Het cumulatieve effect van netwerkisolatiebeperkingen is dat elke cloudservice fungeert alsof deze zich in een geïsoleerd netwerk bevindt waar VM's binnen de cloudservice met elkaar kunnen communiceren, waarbij ze elkaar kunnen identificeren door hun bron-IP-adressen, met het vertrouwen dat geen andere partijen hun peer-VM's kunnen imiteren. Ze kunnen ook worden geconfigureerd om binnenkomende verbindingen van internet via specifieke poorten en protocollen te accepteren en ervoor te zorgen dat al het netwerkverkeer dat uw virtuele netwerken verlaat, altijd is versleuteld.

Aanbeveling

Raadpleeg de gepubliceerde Documentatie voor Azure-netwerken voor hulp bij het gebruik van systeemeigen beveiligingsfuncties om uw gegevens te beschermen.

Extra resources:

• Overzicht van Azure-netwerkbeveiliging
• Azure-netwerkbeveiliging

Opslagisolatie

Microsoft Azure scheidt uw op VM's gebaseerde rekenresources van opslag als onderdeel van het fundamentele ontwerp. Dankzij de 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.

Elk Azure-abonnement kan een of meer opslagaccounts hebben. Azure Storage ondersteunt verschillende verificatieopties, waaronder:

• Gedeelde symmetrische sleutels : bij het maken van een opslagaccount genereert Azure twee 512-bits opslagaccountsleutels die de toegang tot het opslagaccount beheren. U kunt deze sleutels op elk gewenst moment daarna roteren en opnieuw genereren zonder coördinatie met uw toepassingen.
• Verificatie op basis van Microsoft Entra ID : toegang tot Azure Storage kan worden beheerd door Microsoft Entra ID, waarmee tenantisolatie wordt afgedwongen en robuuste maatregelen worden geïmplementeerd om toegang door onbevoegde partijen, waaronder Microsoft-insiders, te voorkomen. Meer informatie over isolatie van Microsoft Entra-tenants vindt u in een technisch document over Microsoft Entra Data Security Considerations.
• Shared Access Signatures (SAS): handtekeningen voor gedeelde toegang of 'vooraf ondertekende URL's' kunnen worden gemaakt op basis van de gedeelde symmetrische sleutels. Deze URL's kunnen aanzienlijk beperkt zijn om de beschikbare kwetsbaarheid voor aanvallen te verminderen, maar tegelijkertijd kunnen toepassingen opslagtoegang verlenen aan een andere gebruiker, service of apparaat.
• SAS voor gebruikersdelegatie : gedelegeerde verificatie is vergelijkbaar met SAS, maar is gebaseerd op Microsoft Entra-tokens in plaats van de gedeelde symmetrische sleutels. Met deze benadering kan een service die wordt geverifieerd met Microsoft Entra ID een vooraf ondertekende URL maken met een beperkt bereik en tijdelijke toegang verlenen tot een andere gebruiker, service of apparaat.
• Anonieme openbare leestoegang : u kunt toestaan dat een klein deel van uw opslag openbaar toegankelijk is zonder verificatie of autorisatie. Deze mogelijkheid kan worden uitgeschakeld op abonnementsniveau als u een strengere controle wenst.

Azure Storage biedt opslag voor een groot aantal workloads, waaronder:

• Virtuele Azure-machines (schijfopslag)
• Big Data Analytics (HDFS voor HDInsight, Azure Data Lake Storage)
• Toepassingsstatus, gebruikersgegevens opslaan (Blob, Queue, Table Storage)
• Langetermijngegevensopslag (Azure Archive Storage)
• Netwerkschijven in de cloud (bestandsopslag)
• Webpagina's op internet leveren (statische websites)

Hoewel Azure Storage veel verschillende extern gerichte scenario's voor klantopslag ondersteunt, wordt intern de fysieke opslag voor de bovenstaande services beheerd door een gemeenschappelijke set API's. Om duurzaamheid en beschikbaarheid te bieden, is Azure Storage afhankelijk van gegevensreplicatie en gegevenspartitionering tussen opslagresources die worden gedeeld tussen tenants. Om de cryptografische zekerheid van logische gegevensisolatie te garanderen, vertrouwt Azure Storage op gegevensversleuteling in rust, met behulp van geavanceerde algoritmen en meerdere versleutelingen, zoals beschreven in deze sectie.

Gegevensreplicatie

Uw gegevens in een Azure Storage-account worden altijd gerepliceerd om duurzaamheid en hoge beschikbaarheid te garanderen. Azure Storage kopieert uw gegevens om deze te beschermen tegen tijdelijke hardwarefouten, netwerk- of stroomstoringen en zelfs enorme natuurrampen. Doorgaans kunt u ervoor kiezen om uw gegevens binnen hetzelfde datacenter, in verschillende beschikbaarheidszones binnen dezelfde regio of in geografisch gescheiden regio's te repliceren. Wanneer u een opslagaccount maakt, kunt u een van de volgende redundantieopties selecteren:

• Lokaal redundante opslag (LRS) repliceert drie kopieën (of het equivalent met wiscode, zoals later wordt beschreven) van uw gegevens in één datacenter. Een schrijfaanvraag naar een LRS-opslagaccount retourneert pas nadat de gegevens naar alle drie de replica's zijn geschreven. Elke replica bevindt zich in afzonderlijke fout- en upgradedomeinen binnen een schaaleenheid (set opslagrekken binnen een datacenter).
• Zone-redundante opslag (ZRS) repliceert uw gegevens synchroon over drie opslagclusters in één regio. Elk opslagcluster is fysiek gescheiden van de andere en bevindt zich in een eigen beschikbaarheidszone (AZ). Een schrijfaanvraag bij een ZRS-opslagaccount retourneert alleen nadat de gegevens naar alle replica’s zijn geschreven in drie clusters.
• Met geografisch redundante opslag (GRS) worden uw gegevens gerepliceerd naar een secundaire (gekoppelde) regio die honderden kilometers verwijderd is van de primaire regio. GRS-opslagaccounts zijn duurzaam, zelfs tijdens een volledige regionale storing of een noodgeval waarbij de primaire regio niet kan worden hersteld. Voor een opslagaccount met GRS of RA-GRS ingeschakeld, worden alle gegevens eerst gerepliceerd met LRS. Een update wordt eerst doorgevoerd op de primaire locatie en gerepliceerd met behulp van LRS. De update wordt vervolgens asynchroon gerepliceerd naar de secundaire regio met behulp van GRS. Wanneer gegevens naar de secundaire locatie worden geschreven, worden deze ook gerepliceerd binnen die locatie met behulp van LRS.
• Geografisch redundante opslag met leestoegang (RA-GRS) is gebaseerd op GRS. Het biedt alleen-lezentoegang tot de gegevens op de secundaire locatie, naast geo-replicatie tussen twee regio's. Met RA-GRS kunt u lezen uit de secundaire regio, ongeacht of Microsoft een failover van de primaire naar de secundaire regio initieert.
• Geografisch zone-redundante opslag (GZRS) combineert de hoge beschikbaarheid van ZRS met bescherming tegen regionale storingen zoals geleverd door GRS. Gegevens in een GZRS-opslagaccount worden gerepliceerd over drie AZ's in de primaire regio en ook gerepliceerd naar een secundaire geografische regio voor bescherming tegen regionale rampen. Elke Azure-regio wordt gekoppeld aan een andere regio binnen dezelfde geografie, samen met een regionaal paar.
• Geografisch zone-redundante opslag met leestoegang (RA-GZRS) is gebaseerd op GZRS. U kunt desgewenst leestoegang tot gegevens inschakelen in de secundaire regio met RA-GZRS als uw toepassingen gegevens moeten kunnen lezen na een noodgeval in de primaire regio.

Azure Storage-architectuur op hoog niveau

Azure Storage-productiesystemen bestaan uit opslagstempels en de locatieservice (LS), zoals weergegeven in afbeelding 12. Een opslagstempel is een cluster van rekken met opslagknooppunten, waarbij elk rek is gebouwd als een afzonderlijk foutdomein met redundant netwerken en stroom. De LS beheert alle opslagstempels en de accountnaamruimte voor alle stempels. Het wijst accounts toe aan opslagstempels en beheert deze over de opslagstempels voor taakverdeling en herstel na noodgevallen. De LS zelf wordt verdeeld over twee geografische locaties voor eigen noodherstel (Calder, et al., 2011).

Afbeelding 12. Azure Storage-architectuur op hoog niveau (bron: Calder, et al., 2011)

Er zijn drie lagen binnen een opslagstempel: front-end, partitie en stream. Deze lagen worden beschreven in de rest van deze sectie.

Front-endlaag

De front-endlaag (FE) bestaat uit een set staatloze servers die de binnenkomende aanvragen overnemen, de aanvragen verifiëren en autoriseren en deze vervolgens doorsturen naar een partitieserver in de partitielaag. De FE-laag weet naar welke partitieserver elke aanvraag moet worden doorgestuurd, omdat elke front-endserver een partitietoewijzing in de cache opgeslagen. De partitiekaart houdt bij welke partities toegankelijk zijn voor de service en welke partitie-server de toegang tot elke partitie in het systeem beheert. De FE-servers streamen ook grote objecten rechtstreeks vanuit de stroomlaag.

Het overdragen van grote hoeveelheden gegevens via internet is inherent onbetrouwbaar. Met behulp van de Azure-blok-blobs-service kunt u grote bestanden efficiënt uploaden en opslaan door grote bestanden op te delen in kleinere gegevensblokken. Op deze manier kunnen blok-blobs gegevens partitioneren in afzonderlijke blokken voor de betrouwbaarheid van grote uploads, zoals wordt weergegeven in afbeelding 13. Elk blok kan maximaal 100 MB groot zijn met maximaal 50.000 blokken in de blok-blob. Als een blok niet correct kan worden verzonden, hoeft alleen dat specifieke blok opnieuw te worden verzonden in plaats van het hele bestand opnieuw te moeten verzenden. Bovendien kunnen met een blok-blob meerdere blokken parallel worden verzonden om de uploadtijd te verkorten.

afbeelding 13. Blok-blobpartitionering van gegevens in afzonderlijke blokken

U kunt blokken in elke volgorde uploaden en de volgorde ervan bepalen in de laatste stap van de toezegging voor de bloklijst. U kunt ook een nieuw blok uploaden om een bestaand niet-verzonden blok van dezelfde blok-id te vervangen.

Partitielaag

De partitielaag is verantwoordelijk voor:

• Gegevensabstracties op een hoger niveau beheren (Blob, Tabel, Wachtrij),
• Een schaalbare objectnaamruimte bieden,
• Het bieden van transactievolgorde en sterke consistentie voor objecten,
• Objectgegevens opslaan boven op de stroomlaag en
• Objectgegevens opslaan in de cache om de I/O van de schijf te verminderen.

Deze laag biedt ook asynchrone geo-replicatie van gegevens en is gericht op het repliceren van gegevens over stempels. Interstempelreplicatie wordt op de achtergrond uitgevoerd om een kopie van de gegevens op twee locaties te bewaren voor herstel na noodgevallen.

Zodra een blob is opgenomen door de FE-laag, is de partitielaag verantwoordelijk voor het bijhouden en opslaan van waar gegevens in de stroomlaag worden geplaatst. Elke opslagtenant kan ongeveer 200 - 300 afzonderlijke knooppunten van de partitielaag hebben en elk knooppunt is verantwoordelijk voor het bijhouden en leveren van een partitie van de gegevens die zijn opgeslagen in die Opslagtenant. Met de high throughput block blob (HTBB)-functie kunnen gegevens binnen één blob worden gesplitst, waardoor de werkbelasting voor grote blobs kan worden verdeeld over meerdere servers in de partitielaag (afbeelding 14). Het verdelen van de belasting tussen meerdere partitielaagservers verbetert de beschikbaarheid, doorvoer en duurzaamheid aanzienlijk.

afbeelding 14. Blok-blobs met hoge doorvoer spreiden verkeer en gegevens over meerdere partitieservers en streams

Stroomlaag

De streamlaag slaat de bits op schijf op en is verantwoordelijk voor het distribueren en repliceren van de gegevens op veel servers om gegevens duurzaam te houden binnen een opslagstempel. Het fungeert als een gedistribueerde bestandssysteemlaag binnen een stempel. Het verwerkt bestanden, die streams worden genoemd, dat geordende lijsten zijn van gegevensblokken genaamd extents, die vergelijkbaar zijn met extents op fysieke harde schijven. Grote blobobjecten kunnen in meerdere gebieden worden opgeslagen, mogelijk op knooppunten van meerdere fysieke gebieden (EN's). De gegevens worden opgeslagen in de stroomlaag, maar zijn toegankelijk vanuit de partitielaag. Partitieservers en streamservers zijn in elk opslagknooppunt binnen een cluster geplaatst.

De stroomlaag biedt synchrone replicatie (intra-stempel) op verschillende knooppunten in verschillende foutdomeinen om gegevens duurzaam te houden binnen de stempel. Het is verantwoordelijk voor het maken van de drie lokale gerepliceerde kopieën van elke extent. De stream layer manager zorgt ervoor dat alle drie kopieën worden verdeeld over verschillende fysieke racks en knooppunten op verschillende fout- en upgradedomeinen, zodat kopieën bestand zijn tegen afzonderlijke schijf-/knooppunt-/rackfouten en geplande downtime vanwege upgrades.

Erasure Coding : Azure Storage maakt gebruik van een techniek met de naam Erasure Coding, waarmee gegevens kunnen worden herbouwd, zelfs als sommige gegevens ontbreken vanwege schijffouten. Deze benadering is vergelijkbaar met het concept van RAID-striping voor afzonderlijke schijven waarbij gegevens worden verspreid over meerdere schijven, zodat als een schijf verloren gaat, de ontbrekende gegevens kunnen worden gereconstrueerd met behulp van de pariteits bits van de gegevens op de andere schijven. Erasure Coding splitst een omvang in gelijke gegevens en pariteitsfragmenten die zijn opgeslagen op afzonderlijke EN's, zoals wordt weergegeven in afbeelding 15.

Figuur 15. Erasure Coding verdeelt extentiegegevens verder over EN-servers om te beschermen tegen falen

Alle gegevensblokken die zijn opgeslagen in stream-extent-knooppunten hebben een 64-bits cyclische redundantiecontrole (CRC) en een header die wordt beveiligd met een hash-handtekening om de gegevensintegriteit van het knooppunt (EN) te bieden. De CRC en handtekening worden gecontroleerd voordat elke keer dat naar de schijf wordt geschreven, van de schijf wordt gelezen, en een netwerkbericht wordt ontvangen. Daarnaast lezen scrubberprocessen alle data met regelmatige tussenpozen, waarbij ze de CRC controleren en zoeken naar bit rot. Als er een defecte extent wordt gevonden, wordt er een nieuwe kopie van die extent gemaakt om de beschadigde extent te vervangen.

Uw gegevens in Azure Storage zijn afhankelijk van gegevensversleuteling in rust om cryptografische zekerheid te bieden voor logische gegevensisolatie. U kunt kiezen tussen door Microsoft beheerde versleutelingssleutels (ook wel door het platform beheerde versleutelingssleutels genoemd) of door de klant beheerde versleutelingssleutels (CMK). De verwerking van gegevensversleuteling en -ontsleuteling is transparant voor klanten, zoals besproken in de volgende sectie.

Versleuteling van gegevens in rust

Azure biedt uitgebreide opties voor data-at-rest om u te helpen uw gegevens te beschermen en te voldoen aan uw nalevingsbehoeften wanneer u zowel door Microsoft beheerde versleutelingssleutels als door de klant beheerde versleutelingssleutels gebruikt. Zie gegevensversleutelingsmodellen voor meer informatie. Dit proces is afhankelijk van meerdere versleutelingssleutels en -services, zoals Azure Key Vault en Microsoft Entra ID, om veilige toegang tot sleutels en gecentraliseerd sleutelbeheer te garanderen.

Opmerking

Als u extra beveiligings- en isolatiegaranties nodig hebt voor uw meest gevoelige gegevens die zijn opgeslagen in Azure-services, kunt u deze versleutelen met behulp van uw eigen versleutelingssleutels die u beheert in Azure Key Vault.

Over het algemeen wordt het beheren van sleuteltoegang en het garanderen van efficiënte bulkversleuteling en ontsleuteling van gegevens bereikt via de volgende typen versleutelingssleutels (zoals weergegeven in afbeelding 16), hoewel andere versleutelingssleutels kunnen worden gebruikt zoals beschreven in de sectie Opslagserviceversleuteling.

• Data Encryption Key (DEK) is een symmetrische AES-256-sleutel die wordt gebruikt voor bulkversleuteling en ontsleuteling van een partitie of een blok gegevens. De cryptografische modules zijn FIPS 140 gevalideerd als onderdeel van het Windows FIPS-validatieprogramma. Toegang tot DEKs is nodig door de resourceprovider of het toepassingsexemplaar die verantwoordelijk zijn voor het versleutelen en ontsleutelen van een specifiek gegevensblok. Eén resource kan veel partities en veel DEK's bevatten. Wanneer een DEK wordt vervangen door een nieuwe sleutel, moeten alleen de gegevens in het bijbehorende blok opnieuw worden versleuteld met de nieuwe sleutel. De DEK wordt altijd versleuteld opgeslagen met de sleutelversleutelingssleutel (KEK).
• Sleutelversleutelingssleutel (KEK) is een asymmetrische RSA-sleutel die optioneel door u wordt geleverd. Deze sleutelversleutelingssleutel wordt gebruikt om de Data Encryption Key (DEK) te versleutelen met behulp van Azure Key Vault of Beheerde HSM. Zoals eerder vermeld in de sectie Gegevensversleutelingssleutelbeheer , kan Azure Key Vault gebruikmaken van FIPS 140 gevalideerde HSM's (Hardware Security Modules) om versleutelingssleutels te beveiligen; Beheerde HSM maakt altijd gebruik van FIPS 140 gevalideerde hardwarebeveiligingsmodules. Deze sleutels kunnen niet worden geëxporteerd en er kan geen duidelijke tekstversie van de KEK buiten de HSM's zijn. De binding wordt afgedwongen door de onderliggende HSM. KEK wordt nooit rechtstreeks blootgesteld aan de resourceprovider of andere services. Toegang tot KEK wordt beheerd door machtigingen in Azure Key Vault en toegang tot Azure Key Vault moet worden geverifieerd via Microsoft Entra-id. Deze rechten kunnen worden ingetrokken om de toegang tot deze sleutel te blokkeren en, als gevolg daarvan, de gegevens die met deze sleutel zijn versleuteld als de basis van de sleutelketen.

afbeelding 16. Gegevensversleutelingssleutels worden versleuteld met behulp van uw sleutel die is opgeslagen in Azure Key Vault

Daarom omvat de versleutelingssleutelhiërarchie zowel DEK als KEK. DEK wordt versleuteld met KEK en afzonderlijk opgeslagen voor efficiënte toegang door resourceproviders in bulkversleutelings- en ontsleutelingsbewerkingen. Alleen een entiteit met toegang tot de KEK kan de DEK echter ontsleutelen. De entiteit die toegang heeft tot de KEK kan afwijken van de entiteit waarvoor de DEK is vereist. Aangezien de KEK nodig is om de DEK te ontsleutelen, is de KEK in feite het enige punt waarmee de DEK kan worden verwijderd door de KEK te verwijderen.

Gedetailleerde informatie over verschillende gegevensversleutelingsmodellen en specifieke informatie over sleutelbeheer voor veel Azure-platformservices is beschikbaar in onlinedocumentatie. Bovendien bieden sommige Azure-services andere versleutelingsmodellen, waaronder versleuteling aan de clientzijde, om hun gegevens verder te versleutelen met behulp van gedetailleerdere besturingselementen. De rest van deze sectie omvat de implementatie van versleuteling voor belangrijke Azure-opslagscenario's, zoals Storage-serviceversleuteling en schijfversleuteling voor Virtuele IaaS-machines.

Aanbeveling

Raadpleeg de gepubliceerde documentatie voor Azure-gegevensversleuteling voor hulp bij het beveiligen van uw gegevens.

Extra resources:

• Overzicht van versleuteling bij opslag
• Gegevensversleutelingsmodellen
• Best practices voor gegevensversleuteling

Opslagserviceversleuteling

Azure Storage-serviceversleuteling voor data-at-rest zorgt ervoor dat gegevens automatisch worden versleuteld voordat ze naar Azure Storage worden bewaard en ontsleuteld voordat ze worden opgehaald. Alle gegevens die naar Azure Storage worden geschreven, worden versleuteld via FIPS 140 gevalideerde 256-bits AES-versleuteling en de verwerking van versleuteling, ontsleuteling en sleutelbeheer in Storage-serviceversleuteling is transparant voor klanten. Microsoft beheert standaard de versleutelingssleutels en is verantwoordelijk voor sleutelrotatie, gebruik en toegang. Sleutels worden veilig opgeslagen in een Microsoft-sleutelopslag. Deze optie biedt u het meeste gemak omdat alle Azure Storage-services worden ondersteund.

U kunt er echter ook voor kiezen om versleuteling met uw eigen sleutels te beheren door het volgende op te geven:

• door de klant beheerde sleutel voor het beheren van Azure Storage-versleuteling waarbij de sleutel wordt opgeslagen in Azure Key Vault. Deze optie biedt veel flexibiliteit voor het maken, draaien, uitschakelen en intrekken van toegang tot door de klant beheerde sleutels. U moet Azure Key Vault gebruiken om door de klant beheerde sleutels op te slaan. Zowel sleutelkluizen als beheerde HSM's worden ondersteund, zoals eerder beschreven in de sectie Azure Key Vault .
• Door de klant geleverde sleutel voor het versleutelen en ontsleutelen van Blob-opslag, waarbij de sleutel alleen kan worden opgeslagen in Azure Key Vault of in een ander sleutelarchief op uw locatie om te voldoen aan wettelijke nalevingsvereisten. Met door de klant geleverde sleutels kunt u een versleutelingssleutel doorgeven aan de Storage-service met behulp van Blob-API's als onderdeel van lees- of schrijfbewerkingen.

Opmerking

U kunt door de klant beheerde sleutels (CMK) configureren met Azure Key Vault met behulp van Azure Portal, Azure PowerShell of Azure CLI. U kunt .NET gebruiken om een door de klant verstrekte sleutel op te geven voor een aanvraag voor Blob Storage.

Opslagserviceversleuteling is standaard ingeschakeld voor alle nieuwe en bestaande opslagaccounts en kan niet worden uitgeschakeld. Zoals wordt weergegeven in afbeelding 17, gebruikt het versleutelingsproces de volgende sleutels om cryptografische zekerheid van gegevensisolatie in rust te garanderen:

• Data Encryption Key (DEK) is een symmetrische AES-256-sleutel die wordt gebruikt voor bulkversleuteling en die uniek is per opslagaccount in Azure Storage. Deze wordt gegenereerd door de Azure Storage-service als onderdeel van het maken van het opslagaccount en wordt gebruikt om een unieke sleutel af te leiden voor elk gegevensblok. De opslagservice versleutelt de DEK altijd met behulp van de stempelsleutel of een sleutelversleutelingssleutel als de klant door de klant beheerde sleutelversleuteling heeft geconfigureerd.
• KEK (Key Encryption Key) is een asymmetrische RSA-sleutel (2048 of hoger) die wordt beheerd door de klant en wordt gebruikt voor het versleutelen van de Data Encryption Key Key (DEK) met behulp van Azure Key Vault of Managed HSM. Deze wordt nooit rechtstreeks blootgesteld aan de Azure Storage-service of andere services.
• Stamp Key (SK) is een symmetrische AES-256-sleutel die wordt beheerd door Azure Storage. Deze sleutel wordt gebruikt om de DEK te beveiligen wanneer u geen door de klant beheerde sleutel gebruikt.

Deze sleutels beschermen alle gegevens die naar Azure Storage worden geschreven en bieden cryptografische zekerheid voor logische gegevensisolatie in Azure Storage. Zoals eerder vermeld, is Versleuteling van Azure Storage-service standaard ingeschakeld en kan deze niet worden uitgeschakeld.

afbeelding 17. Versleutelingsstroom voor Storage-serviceversleuteling

Opslagaccounts worden versleuteld, ongeacht hun prestatielaag (Standard of Premium) of implementatiemodel (Azure Resource Manager of klassiek). Alle opties voor Azure Storage-redundantie ondersteunen versleuteling en alle kopieën van een opslagaccount worden versleuteld. Alle Azure Storage-resources worden versleuteld, waaronder blobs, schijven, bestanden, wachtrijen en tabellen. Alle objectmetagegevens worden ook versleuteld.

Omdat gegevensversleuteling wordt uitgevoerd door de Storage-service, kunt u met CMK versleuteling aan de serverzijde alle typen besturingssystemen en installatiekopieën voor uw VM's gebruiken. Voor uw Virtuele Windows- en Linux IaaS-machines biedt Azure ook Azure Disk Encryption waarmee u beheerde schijven kunt versleutelen met CMK in de gast-VM of EncryptionAtHost waarmee schijfgegevens rechtstreeks op de host worden versleuteld, zoals beschreven in de volgende secties. Azure Storage-serviceversleuteling biedt ook dubbele versleuteling van schijfgegevens-at-rest.

Azure Disk Encryption

Versleuteling van de Azure Storage-service versleutelt de pagina blobs die de schijven van virtuele Azure-machines opslaan. Bovendien kunt u eventueel Azure Disk Encryption gebruiken voor het versleutelen van Azure Windows - en Linux IaaS Virtual Machine-schijven om de opslagisolatie te vergroten en cryptografische zekerheid te garanderen van uw gegevens die zijn opgeslagen in Azure. Deze versleuteling omvat beheerde schijven, zoals verderop in deze sectie wordt beschreven. Azure-schijfversleuteling maakt gebruik van de industriestandaard BitLocker-functie van Windows en de DM-Crypt-functie van Linux om volumeversleuteling op basis van het besturingssysteem te bieden die is geïntegreerd met Azure Key Vault.

Schijfversleuteling via BitLocker en DM-Crypt is een gegevensbeveiligingsfunctie die wordt geïntegreerd met het besturingssysteem en de bedreigingen van gegevensdiefstal of blootstelling bij verloren, gestolen of ongepast buiten gebruik gestelde computers aanpakt. BitLocker en DM-Crypt bieden de meeste beveiliging bij gebruik met tpm-versie 1.2 (Trusted Platform Module) of hoger. De TPM is een microcontroller die is ontworpen om hardware te beveiligen via geïntegreerde cryptografische sleutels. Deze is meestal vooraf geïnstalleerd op nieuwere computers. BitLocker en DM-Crypt kunnen deze technologie gebruiken om de sleutels te beveiligen die worden gebruikt om schijfvolumes te versleutelen en integriteit te bieden voor het opstartproces van de computer.

Voor beheerde schijven kunt u met Azure Disk Encryption de besturingssysteem- en gegevensschijven versleutelen die worden gebruikt door een virtuele IaaS-machine; Gegevens kunnen echter niet worden versleuteld zonder eerst het besturingssysteemvolume te versleutelen. De oplossing is afhankelijk van Azure Key Vault om u te helpen bij het beheren van de schijfversleutelingssleutels in sleutelkluizen. U kunt uw eigen versleutelingssleutels opgeven, die worden beveiligd in Azure Key Vault ter ondersteuning van BYOK-scenario's (Bring Your Own Key), zoals eerder beschreven in de sectie Gegevensversleutelingssleutelbeheer .

Azure Disk-versleuteling biedt geen ondersteuning voor beheerde HSM of een on-premises sleutelbeheerservice. Alleen sleutelkluizen die worden beheerd door de Azure Key Vault-service kunnen worden gebruikt om door de klant beheerde versleutelingssleutels voor Azure Disk-versleuteling te beveiligen. Zie Versleuteling op host voor andere opties met beheerde HSM.

Opmerking

Gedetailleerde instructies zijn beschikbaar voor het maken en configureren van een sleutelkluis voor Azure Disk-versleuteling met zowel Windows - als Linux-VM's .

Azure Disk-versleuteling is afhankelijk van twee versleutelingssleutels voor implementatie, zoals eerder is beschreven:

• Data Encryption Key (DEK) is een symmetrische AES-256-sleutel die wordt gebruikt voor het versleutelen van besturingssysteem- en gegevensvolumes via BitLocker of DM-Crypt. DEK zelf wordt versleuteld en opgeslagen op een interne locatie dicht bij de gegevens.
• Sleutelversleutelingssleutel (KEK) is een asymmetrische RSA-2048-sleutel die wordt gebruikt om de gegevensversleutelingssleutels te versleutelen. KEK wordt bewaard in Azure Key Vault onder uw beheer, inclusief het verlenen van toegangsmachtigingen via Microsoft Entra-id.

De DEK, versleuteld met de KEK, wordt afzonderlijk opgeslagen en alleen een entiteit met toegang tot de KEK kan de DEK ontsleutelen. Toegang tot de KEK wordt bewaakt door Azure Key Vault, waar u ervoor kunt kiezen om uw sleutels op te slaan in fips 140 gevalideerde hardwarebeveiligingsmodules.

Voor Windows-VM's selecteert Azure Disk Encryption de versleutelingsmethode in BitLocker op basis van de versie van Windows, bijvoorbeeld XTS-AES 256-bits voor Windows Server 2012 of hoger. Deze cryptomodules zijn FIPS 140 gevalideerd als onderdeel van het Microsoft Windows FIPS-validatieprogramma. Voor Linux-VM's gebruikt Azure Disk Encryption de standaard ontsleuteling van aes-xts-plain64 met een 256-bits volumehoofdsleutel die FIPS 140 is gevalideerd als onderdeel van DM-Crypt validatie die is verkregen door leveranciers van Linux IaaS VM-installatiekopieën in Microsoft Azure Marketplace.

Versleuteling aan de serverzijde voor beheerde schijven

Beheerde Azure-schijven zijn opslagvolumes op blokniveau die worden beheerd door Azure en worden gebruikt met virtuele Azure-machines met Windows en Linux. Ze vereenvoudigen schijfbeheer voor Azure IaaS-VM's door opslagaccountbeheer transparant voor u te verwerken. Door Azure beheerde schijven versleutelen uw gegevens standaard met behulp van 256-bits AES-versleuteling die is gevalideerd met FIPS 140. Voor versleutelingssleutelbeheer hebt u de volgende opties:

• Door platform beheerde sleutels is de standaardkeuze die transparante gegevensversleuteling in rust biedt voor beheerde schijven, waarbij sleutels worden beheerd door Microsoft.
• Met door de klant beheerde sleutels kunt u controle hebben over uw eigen sleutels die kunnen worden geïmporteerd of gegenereerd in Azure Key Vault of beheerde HSM. Deze benadering is afhankelijk van twee sets sleutels, zoals eerder beschreven: DEK en KEK. DEK versleutelt de gegevens met behulp van op AES-256 gebaseerde versleuteling en wordt op zijn beurt versleuteld door een RSA KEK die is opgeslagen in Azure Key Vault of beheerde HSM.

Door de klant beheerde sleutels (CMK) bieden u volledige controle over uw versleutelingssleutels. U kunt toegang verlenen tot beheerde schijven in uw Azure Key Vault, zodat uw sleutels kunnen worden gebruikt voor het versleutelen en ontsleutelen van de DEK. U kunt uw sleutels ook uitschakelen of de toegang tot beheerde schijven op elk gewenst moment intrekken. Ten slotte hebt u volledige controle over het sleutelgebruik met Azure Key Vault-bewaking om ervoor te zorgen dat alleen beheerde schijven of andere geautoriseerde resources toegang hebben tot uw versleutelingssleutels.

Versleuteling op host

Versleuteling op de host werkt samen met serverside-encryptie om ervoor te zorgen dat gegevens die zijn opgeslagen op de VM-host in rust zijn versleuteld en versleuteld naar de Storage-service worden verzonden. De server die als host fungeert voor uw VIRTUELE machine, versleutelt uw gegevens zonder prestatieimpact of vereiste voor code die wordt uitgevoerd op uw gast-VM en die versleutelde gegevens stromen naar Azure Storage met behulp van de sleutels die zijn geconfigureerd voor versleuteling aan de serverzijde. Zie Versleuteling op host - End-to-end-versleuteling voor uw VM-gegevens voor meer informatie. Versleuteling op host met CMK kan sleutels gebruiken die zijn opgeslagen in beheerde HSM of Key Vault, net zoals versleuteling aan de serverzijde voor beheerde schijven.

U hebt altijd de controle over uw klantgegevens in Azure. U kunt uw klantgegevens die in Azure zijn opgeslagen, openen, extraheren en verwijderen. Wanneer u uw Azure-abonnement beëindigt, voert Microsoft de benodigde stappen uit om ervoor te zorgen dat u de eigenaar blijft van uw klantgegevens. Een veelvoorkomend probleem bij het verwijderen van gegevens of het beëindigen van abonnementen is of een andere klant of Azure-beheerder toegang heeft tot uw verwijderde gegevens. In de volgende secties wordt uitgelegd hoe het verwijderen, bewaren en vernietigen van gegevens in Azure werkt.

Gegevens verwijderen

Opslag wordt spaarzaam toegewezen, wat betekent dat wanneer een virtuele schijf wordt gemaakt, schijfruimte niet 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 u gegevens op de virtuele schijf schrijft, wordt ruimte op de fysieke schijf toegewezen en wordt er een aanwijzer naar deze in de tabel geplaatst. Zie Azure-gegevensbeveiliging: gegevens opschonen en lekken voor meer informatie.

Wanneer u een blob of tabelentiteit verwijdert, wordt deze onmiddellijk verwijderd uit de index die wordt gebruikt om de gegevens op de primaire locatie te vinden en te openen. Vervolgens wordt de verwijdering asynchroon uitgevoerd op de geo-gerepliceerde kopie van de gegevens als u geografisch redundante opslag hebt ingericht. Op de primaire locatie kunt u direct proberen toegang te krijgen tot de blob of entiteit en kunt u deze niet vinden in uw index, omdat Azure een sterke consistentie biedt voor het verwijderen. U kunt dus rechtstreeks controleren of de gegevens zijn verwijderd.

In Azure Storage zijn alle schrijfbewerkingen sequentieel. Deze methode minimaliseert het aantal schijf 'zoekopdrachten', maar vereist dat de aanwijzers naar objecten worden bijgewerkt telkens wanneer ze worden geschreven. Nieuwe versies van aanwijzers worden ook opeenvolgend geschreven. Een neveneffect van dit ontwerp is dat het niet mogelijk is om ervoor te zorgen dat een geheim op de schijf wordt verwijderd door het te overschrijven met andere gegevens. De oorspronkelijke gegevens blijven op de schijf staan en de nieuwe waarde wordt opeenvolgend geschreven. Aanwijzers worden bijgewerkt, zodat de verwijderde waarde niet meer kan worden gevonden. Zodra de schijf vol is, moet het systeem echter nieuwe logboeken schrijven naar schijfruimte die is vrijgemaakt door het verwijderen van oude gegevens. In plaats van logboekbestanden rechtstreeks vanuit schijfsectoren toe te wijzen, worden logboekbestanden gemaakt in een bestandssysteem met NTFS. Een achtergrondthread die op Azure Storage-knooppunten wordt uitgevoerd, maakt ruimte vrij door het oudste logboekbestand te doorlopen, blokken te kopiëren waarnaar nog steeds wordt verwezen van dat oudste logboekbestand naar het huidige logboekbestand en alle aanwijzers bij te werken zoals het gaat. Vervolgens wordt het oudste logboekbestand verwijderd. Daarom zijn er twee categorieën vrije schijfruimte op de schijf: (1) ruimte die NTFS kent is gratis, waar nieuwe logboekbestanden uit deze groep worden toegewezen; en (2) ruimte binnen die logboekbestanden die Azure Storage kent, is gratis omdat er geen huidige aanwijzers zijn.

De sectoren op de fysieke schijf die aan de verwijderde gegevens zijn gekoppeld, worden onmiddellijk beschikbaar voor hergebruik en worden overschreven wanneer het bijbehorende opslagblok opnieuw wordt gebruikt voor het opslaan van andere gegevens. De tijd die nodig is om data te overschrijven varieert, afhankelijk van de schijfbenutting en de activiteiten. Dit proces is consistent met de werking van een door logboek gestructureerd bestandssysteem waarbij alle schrijfbewerkingen sequentieel naar de schijf worden geschreven. Dit proces is niet deterministisch en er is geen garantie wanneer bepaalde gegevens worden verwijderd uit fysieke opslag. Het moment waarop exact verwijderde gegevens worden overschreven of waarop de bijbehorende fysieke opslag aan een andere klant wordt toegewezen, is niet relevant voor de garantie van sleutelisolatie dat er na verwijdering geen gegevens kunnen worden hersteld:

• Een klant kan verwijderde gegevens van een andere klant niet lezen.
• Als iemand probeert een regio te lezen op een virtuele schijf waarnaar ze nog niet zijn geschreven, is er geen fysieke ruimte toegewezen voor die regio en worden daarom alleen nullen geretourneerd.

Klanten krijgen geen directe toegang tot de onderliggende fysieke opslag. Omdat klantsoftware alleen virtuele schijven adresseert, is er geen manier voor een andere klant om een aanvraag uit te drukken om te lezen van of te schrijven naar een fysiek adres dat aan u is toegewezen of een fysiek adres dat gratis is.

Conceptueel gezien is deze logica van toepassing, ongeacht de software die lees- en schrijfbewerkingen bijhoudt. Voor Azure SQL Database is het de SQL Database-software die deze afdwinging uitvoert. Voor Azure Storage is dit de Azure Storage-software. Voor niet-duurzame schijven van een virtuele machine is dit de VHD-verwerkingscode van het host-besturingssysteem. De toewijzing van virtueel naar fysiek adres vindt plaats buiten de vm van de klant.

Ten slotte is de versleutelingssleutelhiërarchie , zoals beschreven in de sectie data-at-rest en weergegeven in afbeelding 16, afhankelijk van de KEK (Key Encryption Key Key), die in Azure Key Vault kan worden bewaard onder uw controle (dat wil gezegd, door de klant beheerde sleutel – CMK) en wordt gebruikt voor het versleutelen van de Data Encryption Key (DEK), waarmee gegevens in rust worden versleuteld met behulp van AES-256 symmetrische versleuteling. Gegevens in Azure Storage worden standaard versleuteld en u kunt ervoor kiezen om versleutelingssleutels onder uw eigen beheer te hebben. Op deze manier kunt u ook de toegang tot uw gegevens die zijn opgeslagen in Azure voorkomen. Aangezien de KEK vereist is om de DEK te ontsleutelen, fungeert de KEK bovendien als het centrale punt: wanneer de KEK wordt verwijderd, kan ook de DEK worden gewist.

Gegevensretentie

Tijdens de looptijd van uw Azure-abonnement hebt u altijd de mogelijkheid om uw gegevens die zijn opgeslagen in Azure te openen, te extraheren en te verwijderen.

Als uw abonnement verloopt of wordt beëindigd, behoudt Microsoft uw klantgegevens gedurende een bewaarperiode van 90 dagen, zodat u uw gegevens kunt extraheren of uw abonnementen kunt verlengen. Na deze bewaarperiode verwijdert Microsoft al uw klantgegevens binnen een andere 90 dagen, dat wil zeggen dat uw klantgegevens 180 dagen na verloop of beëindiging definitief worden verwijderd. Gezien de procedure voor het bewaren van gegevens, kunt u bepalen hoe lang uw gegevens worden opgeslagen door timing wanneer u de service beëindigt met Microsoft. Het is raadzaam dat u uw service pas beëindigt nadat u alle gegevens hebt geëxtraheerd, zodat de initiële bewaarperiode van 90 dagen kan fungeren als een veiligheidsbuffer als u zich later realiseert dat u iets hebt gemist.

Als u per ongeluk een volledig opslagaccount hebt verwijderd, neemt u contact op met de ondersteuning van Azure voor hulp bij herstel. U kunt ondersteuningsaanvragen maken en beheren in Azure Portal. Een opslagaccount dat in een abonnement is verwijderd, wordt twee weken bewaard om herstel na onbedoelde verwijdering mogelijk te maken, waarna het permanent wordt verwijderd. Wanneer een opslagobject (bijvoorbeeld blob, bestand, wachtrij, tabel) zelf wordt verwijderd, is de verwijderbewerking onmiddellijk en niet ongedaan te maken. Tenzij u een back-up hebt gemaakt, kunnen verwijderde opslagobjecten niet worden hersteld. Voor Blob Storage kunt u extra beveiliging implementeren tegen onbedoelde of onjuiste wijzigingen of verwijderingen door voorlopig verwijderen in te schakelen. Wanneer voorlopig verwijderen is ingeschakeld voor een opslagaccount, kunnen blobs, blobversies en momentopnamen in dat opslagaccount worden hersteld nadat ze zijn verwijderd, binnen een retentieperiode die u hebt opgegeven. Als u wilt voorkomen dat gegevens worden bewaard nadat het opslagaccount of het abonnement is verwijderd, kunt u opslagobjecten afzonderlijk verwijderen voordat u het opslagaccount of abonnement verwijdert.

Voor het onbedoeld verwijderen in verband met Azure SQL Database, moet u de back-ups controleren die de service automatisch maakt en gebruik maken van point-in-time herstel. Volledige databaseback-up wordt bijvoorbeeld wekelijks uitgevoerd en differentiële databaseback-ups worden elk uur uitgevoerd. Daarnaast kunnen afzonderlijke services (zoals Azure DevOps) hun eigen beleid hebben voor onbedoeld verwijderen van gegevens.

Gegevensvernietiging

Als een schijfstation dat wordt gebruikt voor opslag een hardwarefout ondervindt, wordt het veilig gewist of vernietigd voordat het uit bedrijf wordt genomen. De gegevens op de schijf worden gewist om ervoor te zorgen dat de gegevens op geen enkele manier kunnen worden hersteld. Wanneer dergelijke apparaten buiten gebruik worden gesteld, volgt Microsoft het NIST SP 800-88 R1 verwijderingsproces met gegevensclassificatie afgestemd op FIPS 199 Moderate. Magnetische, elektronische of optische media worden opgeschoond of vernietigd overeenkomstig de eisen die zijn vastgesteld in NIST SP 800-88 R1, waarbij de voorwaarden als volgt worden gedefinieerd:

• Opschonen : "een opschoningsproces voor media dat de vertrouwelijkheid van informatie beschermt tegen een laboratoriumaanval", waarbij "resources en kennis nodig zijn om niet-standaardsystemen te gebruiken voor het uitvoeren van pogingen tot gegevensherstel op media buiten hun normale bedrijfsomgeving" met behulp van "signaalverwerkingsapparatuur en speciaal opgeleid personeel." Opmerking: Voor harde schijven (waaronder ATA, SCSI, SATA, SAS, enzovoort) is een opdracht voor veilig wissen op firmwareniveau (single-pass) acceptabel, of een overschrijven en verificatie op softwareniveau (nullen, willekeurig) van de volledige fysieke media, inclusief herstelgebieden, indien van toepassing. Voor SSD's (Solid State Disks) is een secure-erase-opdracht op firmwareniveau nodig.
• Vernietig – "een verscheidenheid aan methoden, waaronder desintegratie, verbranding, verpulvering, shredding en smelten" waarna de media "niet opnieuw kunnen worden gebruikt zoals oorspronkelijk bedoeld."

Opschonings- en vernietigingsbewerkingen moeten worden uitgevoerd met behulp van hulpprogramma's en processen die zijn goedgekeurd door Microsoft Security. Records moeten worden bewaard van de verwijdering en vernietiging van activa. Apparaten die de Purge niet kunnen voltooien, moeten worden ontmagnetiseerd (alleen voor magnetische media) of vernietigd.

Naast technische implementatiedetails waarmee Azure-reken-, netwerk- en opslagisolatie mogelijk is, heeft Microsoft veel geïnvesteerd in beveiligingscontroleprocessen en -procedures om logisch geïsoleerde services en systemen te ontwikkelen, zoals beschreven in de volgende sectie.

Processen en procedures voor beveiligingscontrole

Azure-isolatiegaranties worden verder afgedwongen door het interne gebruik van de SDL (Security Development Lifecycle) en andere sterke beveiligingscontroleprocessen om kwetsbaarheid voor aanvallen te beschermen en bedreigingen te beperken. Microsoft heeft toonaangevende processen en hulpprogramma's ontwikkeld die een hoge mate van vertrouwen bieden in de azure-isolatiegarantie.

• Security Development Lifecycle (SDL): Microsoft SDL introduceert beveiligings- en privacyoverwegingen in alle fasen van het ontwikkelingsproces, helpt ontwikkelaars bij het bouwen van zeer veilige software, voldoen aan vereisten voor beveiligingsnaleving en verlagen de ontwikkelingskosten. De richtlijnen, best practices, hulpprogramma's en processen in de Microsoft SDL zijn intern gebruikt om alle Azure-services te bouwen en veiligere producten en services te maken. Dit proces wordt ook openbaar gedocumenteerd om de kennis van Microsoft te delen met de bredere branche en branchefeedback op te nemen om een sterker beveiligingsontwikkelingsproces te creëren.
• Hulpprogramma's en processen : alle Azure-code is onderworpen aan een uitgebreide set statische en dynamische analysehulpprogramma's die potentiële beveiligingsproblemen, ineffectieve beveiligingspatronen, geheugenbeschadiging, problemen met gebruikersbevoegdheden en andere kritieke beveiligingsproblemen identificeren.
  • Speciaal ontworpen fuzzing : een testtechniek die wordt gebruikt om beveiligingsproblemen in softwareproducten en -services te vinden. Het bestaat uit het herhaaldelijk invoeren van gewijzigde of fuzzed gegevens aan software-invoer om vastlopen, uitzonderingen en crashes te activeren; dit zijn foutvoorwaarden die door een aanvaller kunnen worden gebruikt om toepassingen en diensten te verstoren of over te nemen. Microsoft SDL raadt aan alle aanvalsoppervlakken van een softwareproduct te fuzzen , met name die oppervlakken die een gegevensparser blootstellen aan niet-vertrouwde gegevens.
  • Live-site penetratietests : Microsoft voert doorlopende live-sitepenetratietests uit om de controles en processen voor cloudbeveiliging te verbeteren, als onderdeel van het Red Teaming-programma dat verderop in deze sectie wordt beschreven. Penetratietests zijn een beveiligingsanalyse van een softwaresysteem dat wordt uitgevoerd door ervaren beveiligingsprofessionals die de acties van een hacker simuleren. Het doel van een penetratietest is om potentiële beveiligingsproblemen op te sporen als gevolg van coderingsfouten, systeemconfiguratiefouten of andere zwakke plekken in de operationele implementatie. De tests worden uitgevoerd op basis van azure-infrastructuur en -platforms en de eigen tenants, toepassingen en gegevens van Microsoft. Uw tenants, toepassingen en gegevens die worden gehost in Azure, zijn nooit gericht; U kunt echter uw eigen penetratietests uitvoeren van uw toepassingen die zijn geïmplementeerd in Azure.
  • Bedreigingsmodellering : een kernelement van de Microsoft SDL. Het is een technische techniek die wordt gebruikt om bedreigingen, aanvallen, beveiligingsproblemen en tegenmaatregelen te identificeren die van invloed kunnen zijn op toepassingen en services. Threat modeling maakt deel uit van de levenscyclus van azure-routineontwikkeling.
  • Geautomatiseerde buildwaarschuwingen voor wijzigingen in kwetsbaarheid voor aanvallen : Attack Surface Analyzer is een door Microsoft ontwikkeld opensource-beveiligingshulpprogramma dat de kwetsbaarheid voor aanvallen van een doelsysteem analyseert en rapporteert over mogelijke beveiligingsproblemen die zijn geïntroduceerd tijdens de installatie van software of onjuiste configuratie van het systeem. De kernfunctie van Attack Surface Analyzer is de mogelijkheid om de beveiligingsconfiguratie van een besturingssysteem te 'diffen' voor en nadat een softwareonderdeel is geïnstalleerd. Deze functie is belangrijk omdat voor de meeste installatieprocessen verhoogde bevoegdheden zijn vereist en zodra deze zijn verleend, kunnen ze leiden tot onbedoelde wijzigingen in de systeemconfiguratie.
• Verplichte beveiligingstraining : het Microsoft Azure-beveiligingstrainings- en bewustzijnsprogramma vereist dat alle medewerkers die verantwoordelijk zijn voor Azure-ontwikkeling en -activiteiten essentiële training en eventuele extra training op basis van afzonderlijke taakvereisten uitvoeren. Deze procedures bieden een standaardbenadering, hulpprogramma's en technieken die worden gebruikt om het bewustzijnsprogramma te implementeren en te ondersteunen. Microsoft heeft een beveiligingsbewustzijnsprogramma met de naam STRIKE geïmplementeerd dat maandelijkse e-mailcommunicatie biedt aan alle technische medewerkers van Azure over beveiligingsbewustzijn en waarmee werknemers zich kunnen registreren voor persoonlijke of online training voor beveiligingsbewustzijn. STRIKE biedt een reeks beveiligingstrainingen gedurende het hele jaar plus STRIKE Central, een gecentraliseerde onlineresource voor beveiligingsbewustzijn, training, documentatie en betrokkenheid van de community.
• Bug Bounty Program – Microsoft gelooft sterk dat nauwe samenwerking met academische en brancheonderzoekers een hoger beveiligingsniveau voor u en uw gegevens aanstuurt. Beveiligingsonderzoekers spelen een integrale rol in het Azure-ecosysteem door beveiligingsproblemen te detecteren die zijn gemist in het softwareontwikkelingsproces. Het Microsoft Bug Bounty-programma is ontworpen om onderzoek in relevante technologieën (bijvoorbeeld versleuteling, adresvervalsing, hypervisorisolatie, uitbreiding van bevoegdheden, enzovoort) aan te vullen en aan te moedigen om de infrastructuur en uw gegevens van Azure beter te beveiligen. Zo compenseert Microsoft voor elk kritiek beveiligingsprobleem dat in de Azure Hypervisor wordt geïdentificeerd, beveiligingsonderzoekers tot $ 250.000, een aanzienlijk bedrag om deelname en openbaarmaking van beveiligingsproblemen te stimuleren. Het bounty-bereik voor rapporten over beveiligingsproblemen in Azure-services is maximaal $ 60.000.
• Red Team-activiteiten : Microsoft maakt gebruik van Red Teaming, een vorm van live sitepenetratietests tegen door Microsoft beheerde infrastructuur, services en toepassingen. Microsoft simuleert beveiligingsincidenten uit de echte wereld, bewaakt continu de beveiliging en oefent met het reageren op beveiligingsincidenten om de beveiliging van Azure te testen en te verbeteren. Red Teaming is gebaseerd op de Assume Breach-beveiligingsstrategie en wordt uitgevoerd door twee kerngroepen: Red Team (aanvallers) en Blue Team (verdedigers). De aanpak is ontworpen om Azure-systemen en -bewerkingen te testen met behulp van dezelfde tactiek, technieken en procedures als echte aanvallers tegen een live productie-infrastructuur, zonder de voorkennis van de infrastructuur- en platform engineering- of operations-teams. Met deze aanpak worden beveiligingsdetectie- en responsmogelijkheden getest en kunnen beveiligingsproblemen in productie, configuratiefouten, ongeldige veronderstellingen of andere beveiligingsproblemen op een gecontroleerde manier worden geïdentificeerd. Elke inbraak van het Rode Team wordt gevolgd door volledige informatie-uitwisseling tussen het Rode Team en het Blauwe Team om hiaten te identificeren, bevindingen aan te pakken en de reactietijd op inbreuken aanzienlijk te verbeteren.

Als u gewend bent aan een traditionele on-premises datacenterimplementatie, voert u doorgaans een risicoanalyse uit om uw blootstelling aan bedreigingen te meten en maatregelen te formuleren bij het migreren naar de cloud. In veel van deze gevallen zijn beveiligingsoverwegingen voor traditionele on-premises implementatie vaak goed te begrijpen, terwijl de bijbehorende cloudopties meestal nieuw zijn. De volgende sectie is bedoeld om u te helpen met deze vergelijking.

Overwegingen voor logische isolatie

Een multitenant-cloudplatform impliceert dat meerdere klanttoepassingen en -gegevens worden opgeslagen op dezelfde fysieke hardware. Azure maakt gebruik van logische isolatie om uw toepassingen en gegevens van andere klanten te scheiden. Deze aanpak biedt de schaal en economische voordelen van multitenant-cloudservices, terwijl het strikt helpt om controles af te dwingen die zijn ontworpen om te voorkomen dat andere klanten toegang krijgen tot uw gegevens of toepassingen. Als u migreert van een traditionele on-premises fysiek geïsoleerde infrastructuur naar de cloud, vindt u in deze sectie informatie die voor u van belang kan zijn.

Overwegingen voor fysieke versus logische beveiliging

Tabel 6 biedt een overzicht van belangrijke beveiligingsoverwegingen voor fysiek geïsoleerde on-premises implementaties (bare metal) versus logisch geïsoleerde cloudimplementaties (Azure). Het is handig om deze overwegingen te bekijken voordat u risico's onderzoekt die specifiek zijn voor gedeelde cloudomgevingen.

Tabel 6. Belangrijke beveiligingsoverwegingen voor fysieke versus logische isolatie

Beveiligingsoverweging	Op locatie	Azuur
Firewalls, netwerken	- Fysieke netwerk afdwinging (switches, enzovoort) - Fysieke firewall op basis van host kan worden gemanipuleerd door gecompromitteerde toepassing - twee afdwingingslagen	- Fysieke netwerkhandhaving (switches, enzovoort) - Hyper-V de handhaving van de virtuele netwerkswitch van de host kan niet worden veranderd vanuit de VM - de hostgebaseerde VM-firewall kan worden gemanipuleerd door een gecompromitteerde toepassing - drie lagen van handhaving
Aanvalsoppervlak	- Grote hardware-aanvalsoppervlak blootgesteld aan complexe workloads, maakt firmware gebaseerde geavanceerde persistente bedreiging (APT) mogelijk	- Hardware die niet rechtstreeks aan VM wordt blootgesteld, geen potentieel voor APT om in firmware van VM te blijven bestaan - kleine softwaregebaseerde Hyper-V kwetsbaarheid voor aanvallen met een laag historisch aantal fouten dat beschikbaar is voor de VM
Side channel-aanvallen	- Side channel-aanvallen kunnen een factor zijn, hoewel verminderde versus gedeelde hardware	- Bij side channel-aanvallen wordt verondersteld dat controle wordt uitgeoefend over de plaatsing van VM's tussen toepassingen; dit kan in grote cloudservices niet praktisch zijn.
patchen	- Gevarieerd effectief patchbeleid toegepast op hostsystemen - Zeer gevarieerd/kwetsbaar bijwerken voor hardware en firmware	- Uniform patching-beleid toegepast op host en VM's
Beveiligingsanalyse	- Beveiligingsanalyse afhankelijk van op host gebaseerde beveiligingsoplossingen, waarbij wordt ervan uitgegaan dat er geen inbreuk is gemaakt op host-/beveiligingssoftware	- Externe VM (op basis van hypervisor) forensische/momentopnamemogelijkheden maakt het mogelijk om een evaluatie van mogelijk gecompromitteerde workloads mogelijk te maken
Beveiligingsbeleid	- Verificatie van beveiligingsbeleid (patchscans, scannen van beveiligingsproblemen, enzovoort) onderhevig aan manipulatie door aangetaste host - Inconsistent beveiligingsbeleid toegepast op klantentiteiten	- Externe VM-verificatie van beveiligingsbeleid - Mogelijk om uniform beveiligingsbeleid af te dwingen voor entiteiten van klanten
Logboekregistratie en bewaking	- Gevarieerde oplossingen voor logboekregistratie en beveiligingsanalyse	- Algemene oplossingen voor logboekregistratie van Azure-platformen en beveiligingsanalyses - De meeste bestaande on-premises/ gevarieerde oplossingen voor logboekregistratie en beveiligingsanalyse werken ook
Kwaadwillende insider	- Permanente bedreiging veroorzaakt door systeembeheerders met verhoogde toegangsrechten meestal voor de duur van de werkgelegenheid	- Sterk verminderde bedreiging omdat beheerders geen standaardtoegangsrechten hebben

Hieronder vindt u belangrijke risico's die uniek zijn voor gedeelde cloudomgevingen die mogelijk moeten worden aangepakt wanneer gevoelige gegevens en workloads worden meegenomen.

Misbruik van beveiligingsproblemen in virtualisatietechnologieën

Vergeleken met traditionele on-premises gehoste systemen biedt Azure een sterk verminderd kwetsbaarheid voor aanvallen door gebruik te maken van een vergrendelde Windows Server-kern voor het hostbesturingssysteem gelaagd via de Hypervisor. Bovendien hebben gast-PaaS-VM's standaard geen gebruikersaccounts om binnenkomende externe verbindingen te accepteren en is het standaardaccount voor Windows-beheerders uitgeschakeld. Uw software in PaaS-VM's wordt standaard beperkt tot uitvoering onder een account met beperkte bevoegdheden, waardoor uw service wordt beschermd tegen aanvallen door hun eigen eindgebruikers. U kunt deze machtigingen wijzigen en u kunt er ook voor kiezen om uw VM's zo te configureren dat externe beheerderstoegang is toegestaan.

PaaS-VM's bieden geavanceerdere bescherming tegen permanente malware-infecties dan traditionele fysieke serveroplossingen, die, indien aangetast door een aanvaller, moeilijk te reinigen zijn, zelfs nadat het beveiligingsprobleem is gecorrigeerd. De aanvaller heeft mogelijk wijzigingen in het systeem achtergelaten die opnieuw toegang toestaan en het is een uitdaging om al deze wijzigingen te vinden. In het extreme geval moet het systeem helemaal opnieuw worden geïnstalleerd met alle software die opnieuw is geïnstalleerd, wat soms leidt tot verlies van toepassingsgegevens. Met PaaS-VM's is het opnieuw voltooien van bewerkingen een routineonderdeel en kan het helpen bij het opschonen van inbraaks die niet eens zijn gedetecteerd. Deze aanpak maakt het moeilijker om een compromis te behouden.

Side channel-aanvallen

Microsoft is aan het begin geweest van het beperken van speculatieve aanvallen aan de zijkant van het uitvoeringskanaal die gebruikmaken van hardwareproblemen in moderne processors die gebruikmaken van hyperthreading. In veel opzichten zijn deze problemen vergelijkbaar met de Spectre (variant 2) zijaanval, die in 2018 werd bekendgemaakt. In 2022 werden er meerdere nieuwe speculatieve problemen aan de zijkant van het uitvoeringskanaal bekendgemaakt door zowel Intel als AMD. Om deze beveiligingsproblemen op te lossen, heeft Microsoft Hyper-V HyperSight ontwikkeld en geoptimaliseerd, een uitgebreide en krachtige architectuur voor het beperken van beveiligingsproblemen aan de zijkant. HyperClear is afhankelijk van drie hoofdonderdelen om een sterke isolatie tussen VM's te garanderen.

• Core scheduler om het delen van de privébuffers van een CPU-kern en andere resources te voorkomen.
• Isolatie van adresruimte van virtuele processor om speculatieve toegang tot het geheugen van een andere virtuele machine of de privéstatus van een andere virtuele CPU-kern te voorkomen.
• Gevoelige gegevens wissen om te voorkomen dat privégegevens ergens in het hypervisorgeheugen worden achtergelaten, behalve binnen de privéadresruimte van een virtuele processor, zodat deze gegevens in de toekomst niet speculatief kunnen worden geopend.

Deze beveiligingen zijn geïmplementeerd in Azure en zijn beschikbaar in ondersteunde versies van Windows Server 2016 en hoger.

Opmerking

De Hyper-V HyperSight-architectuur is bewezen als een gemakkelijk uitbreidbaar ontwerp waarmee u sterke isolatiegrenzen kunt bieden tegen verschillende speculatieve aanvallen aan de zijkant van het uitvoeringskanaal, met een verwaarloosbare invloed op de prestaties.

Wanneer VM's van verschillende klanten op dezelfde fysieke server worden uitgevoerd, is het de taak van de Hypervisor om ervoor te zorgen dat ze niets kunnen leren over wat de vm's van de andere klant doen. Azure helpt onbevoegde directe communicatie per ontwerp te blokkeren; Er zijn echter subtiele effecten waarbij de ene klant het werk dat door een andere klant wordt uitgevoerd, kan karakteriseren. De belangrijkste van deze effecten zijn tijdseffecten wanneer verschillende VM's concurreren voor dezelfde resources. Door het aantal bewerkingen op CPU's zorgvuldig te vergelijken met verstreken tijd, kan een VIRTUELE machine iets leren over wat andere VM's op dezelfde server doen. Deze exploits hebben veel aandacht gekregen in de academische pers, waar onderzoekers op zoek zijn naar meer specifieke details over de gebeurtenissen in een peer-VM.

Van bijzonder belang zijn pogingen om de cryptografische sleutels van een peer-VM te leren door de timing van bepaalde geheugentoegang te meten en uit te stellen welke cachelijnen de VM van het slachtoffer leest en bijwerkt. Onder gecontroleerde omstandigheden met VM's met hyperthreading zijn geslaagde aanvallen aangetoond tegen commercieel beschikbare implementaties van cryptografische algoritmen. Naast de eerder genoemde Hyper-V HyperSight-risicobeperkingsarchitectuur die door Azure wordt gebruikt, zijn er verschillende extra oplossingen in Azure die het risico op een dergelijke aanval verminderen:

• De standaard cryptografische Azure-bibliotheken zijn ontworpen om dergelijke aanvallen te weerstaan door geen cachetoegangspatronen te hebben, afhankelijk van de cryptografische sleutels die worden gebruikt.
• Azure maakt gebruik van een geavanceerd algoritme voor de plaatsing van VM-hosts dat zeer complex is en bijna onmogelijk te voorspellen, waardoor de kans wordt verkleind dat een door een tegenstander beheerde VM op dezelfde host als de doel-VM wordt geplaatst.
• Alle Azure-servers hebben ten minste acht fysieke kernen en sommige hebben nog veel meer. Het verhogen van het aantal kernen dat de belasting deelt die door verschillende VM's wordt geplaatst, voegt ruis toe aan een al zwak signaal.
• U kunt VM's inrichten op hardware die is toegewezen aan één klant met behulp van Azure Dedicated Host of Geïsoleerde VM's, zoals beschreven in de sectie Fysieke isolatie . Fysieke tenantisolatie verhoogt echter de implementatiekosten en is mogelijk niet vereist in de meeste scenario's, gezien de sterke garanties voor logische isolatie die door Azure worden geboden.

Over het algemeen draagt PaaS – of elke workload die automatisch VM's creëert – bij aan de veranderingen in VM-plaatsing, wat leidt tot willekeurige toewijzing van VM's. Door willekeurige plaatsing van uw VM's is het veel moeilijker voor aanvallers om op dezelfde host te komen. Bovendien wordt hosttoegang beveiligd met sterk gereduceerde kwetsbaarheid voor aanvallen waardoor deze soorten aanvallen moeilijk te onderhouden zijn.

Samenvatting

Een multitenant-cloudplatform impliceert dat meerdere klanttoepassingen en -gegevens worden opgeslagen op dezelfde fysieke hardware. Azure maakt gebruik van logische isolatie om uw toepassingen en gegevens van andere klanten te scheiden. Deze aanpak biedt de schaal en economische voordelen van multitenant-cloudservices, terwijl andere klanten strikt voorkomen dat ze toegang hebben tot uw gegevens of toepassingen.

Azure richt zich op het waargenomen risico van het delen van resources door een betrouwbare basis te bieden voor het garanderen van multitenant, cryptografisch bepaalde, logisch geïsoleerde cloudservices met behulp van een gemeenschappelijke set principes:

• Besturingselementen voor gebruikerstoegang met verificatie en identiteitsscheiding die gebruikmaakt van Microsoft Entra ID en op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC).
• Rekenisolatie voor verwerking, inclusief logische en fysieke rekenisolatie.
• Netwerkisolatie, inclusief scheiding van netwerkverkeer en gegevensversleuteling tijdens overdracht.
• Opslagisolatie met versleuteling van gegevens die in rust zijn, gebruikmakend van geavanceerde algoritmen, meerdere versleutelingen en sleutels, en mogelijkheden voor door de klant beheerde sleutels (CMK) onder uw controle in Azure Key Vault.
• Beveiligingscontroleprocessen die zijn ingesloten in het serviceontwerp om logisch geïsoleerde services te ontwikkelen, waaronder SDL (Security Development Lifecycle) en andere sterke beveiligingscontroleprocessen om kwetsbaarheid voor aanvallen te beschermen en risico's te beperken.

In overeenstemming met het model voor gedeelde verantwoordelijkheid in cloud-computing biedt dit artikel richtlijnen voor activiteiten die deel uitmaken van uw verantwoordelijkheid. Het verkent ook ontwerpprincipes en -technologieën die beschikbaar zijn in Azure om u te helpen bij het bereiken van uw veilige isolatiedoelstellingen.

Volgende stappen

Meer informatie over:

• Documentatie over basisprincipes van beveiliging voor Azure
• Beveiliging van Azure-infrastructuur
• azure-platformintegriteit en -beveiliging
• Overzicht van Azure Government
• Beveiliging van Azure Government
• Azure Government-compliance
• Nalevingsaanbiedingen voor Azure en andere Microsoft-services