Azure Key Vault-beveiliging

Azure Key Vault beveiligt cryptografische sleutels, certificaten (en de persoonlijke sleutels die zijn gekoppeld aan de certificaten) en geheimen (zoals verbindingsreeks s en wachtwoorden) in de cloud. Wanneer u gevoelige en bedrijfskritieke gegevens opslaat, moet u echter stappen ondernemen om de beveiliging van uw kluizen en de daarin opgeslagen gegevens te maximaliseren.

Dit artikel bevat een overzicht van beveiligingsfuncties en aanbevolen procedures voor Azure Key Vault.

Notitie

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

Netwerkbeveiliging

U kunt de blootstelling van uw kluizen verminderen door op te geven welke IP-adressen toegang tot deze kluizen hebben. Met de service-eindpunten van het virtuele netwerk voor Azure Key Vault kunt u de toegang tot een opgegeven virtueel netwerk beperken. Met de eindpunten kunt u ook de toegang tot een lijst met IPv4-adresbereiken (internetprotocol versie 4) beperken. Elke gebruiker die verbinding maakt met uw sleutelkluis van buiten deze bronnen, heeft geen toegang. Zie Service-eindpunten voor virtuele netwerken voor Azure Key Vault voor meer informatie

Nadat firewallregels van kracht zijn, kunnen gebruikers alleen gegevens lezen uit Key Vault wanneer hun aanvragen afkomstig zijn van toegestane virtuele netwerken of IPv4-adresbereiken. Dit is tevens van toepassing voor toegang tot Key Vault vanuit Azure Portal. Hoewel gebruikers kunnen bladeren naar een sleutelkluis van Azure Portal, kunnen ze mogelijk geen sleutels, geheimen of certificaten weergeven als hun clientcomputer niet in de lijst met toegestane clients staat. Zie Azure Key Vault-firewalls en virtuele netwerken configureren voor implementatiestappen

Met Azure Private Link hebt u via een privé-eindpunt in uw virtuele netwerk toegang tot Azure Key Vault en in Azure gehoste services van klanten of partners. Een privé-eindpunt in Azure is een netwerkinterface waarmee u privé en veilig verbinding maakt met een service die door Azure Private Link mogelijk wordt gemaakt. Het privé-eindpunt maakt gebruik van een privé-IP-adres van uw VNet, waardoor de service feitelijk in uw VNet wordt geplaatst. Al het verkeer naar de service kan worden gerouteerd via het privé-eindpunt, zodat er geen gateways, NAT-apparaten, ExpressRoute of VPN-verbindingen of openbare IP-adressen nodig zijn. Verkeer tussen uw virtuele netwerk en de services wordt via het backbonenetwerk van Microsoft geleid, waarmee de risico's van het openbare internet worden vermeden. U kunt verbinding maken met een exemplaar van een Azure-resource, zodat u het hoogste granulariteit krijgt in toegangsbeheer. Zie Key Vault integreren met Azure Private Link voor implementatiestappen

TLS en HTTPS

• De Key Vault-front-end (gegevenslaag) is een server met meerdere tenants. Dit betekent dat sleutelkluizen van verschillende klanten hetzelfde openbare IP-adres kunnen delen. Om isolatie te bereiken, wordt elke HTTP-aanvraag geverifieerd en onafhankelijk van andere aanvragen geautoriseerd.
• Met het HTTPS-protocol kan de client deelnemen aan TLS-onderhandeling. Clients kunnen de versie van TLS afdwingen, en wanneer een client dit doet, gebruikt de volledige verbinding de bijbehorende niveaubeveiliging. Key Vault ondersteunt tls 1.2- en 1.3-protocolversies.

Notitie

U kunt hier tls-versie bewaken die door clients wordt gebruikt door Key Vault-logboeken te bewaken met een kusto-voorbeeldquery.

Key Vault-verificatieopties

Wanneer u een sleutelkluis 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. In beide gevallen hebben toepassingen op drie manieren toegang tot Key Vault:

• Alleen toepassing: de toepassing vertegenwoordigt een service-principal of beheerde identiteit. Deze identiteit is het meest voorkomende scenario voor toepassingen die periodiek toegang nodig hebben tot certificaten, sleutels of geheimen uit de sleutelkluis. Voordat dit scenario werkt, moet de objectId toepassing worden opgegeven in het toegangsbeleid en mag de applicationId toepassing niet worden opgegeven of moet het zijnnull.
• Alleen gebruiker: de gebruiker heeft toegang tot de sleutelkluis vanuit elke toepassing die is geregistreerd in de tenant. Voorbeelden van dit type toegang zijn Azure PowerShell en Azure Portal. Voordat dit scenario werkt, moet de objectId gebruiker worden opgegeven in het toegangsbeleid en mag het applicationId niet worden opgegeven of moet het zijnnull.
• Application-plus-user (soms samengestelde identiteit genoemd): de gebruiker is vereist voor toegang tot de sleutelkluis vanuit een specifieke toepassing en de toepassing moet de stroom namens verificatie (OBO) gebruiken om de gebruiker te imiteren. Dit scenario werkt applicationId alleen als objectId deze moet worden opgegeven in het toegangsbeleid. De applicationId id identificeert de vereiste toepassing en de objectId gebruiker wordt geïdentificeerd. Deze optie is momenteel niet beschikbaar voor het gegevensvlak van Azure RBAC.

In alle typen toegang wordt de toepassing geverifieerd met Microsoft Entra-id. De toepassing gebruikt een ondersteunde verificatiemethode op basis van het toepassingstype. De toepassing verkrijgt een token voor een resource in het vlak om toegang te verlenen. De resource is een eindpunt in het beheer- of gegevensvlak, op basis van de Azure-omgeving. De toepassing gebruikt het token en verzendt een REST API-aanvraag naar Key Vault. Bekijk de volledige verificatiestroom voor meer informatie.

Het model van één mechanisme voor verificatie voor beide vlakken heeft verschillende voordelen:

• Organisaties kunnen de toegang centraal beheren tot alle sleutelkluizen in hun organisatie.
• Als een gebruiker vertrekt, verliest deze direct de toegang tot alle sleutelkluizen in de organisatie.
• Organisaties kunnen verificatie aanpassen met behulp van de opties in Microsoft Entra ID, zoals meervoudige verificatie inschakelen voor extra beveiliging.

Zie Basisbeginselen van Key Vault-verificatie voor meer informatie.

Overzicht van Access-model

Toegang tot een sleutelkluis wordt beheerd via twee interfaces: het beheervlak en het gegevensvlak. In het beheervlak beheert u Key Vault zelf. Bewerkingen in dit vlak omvatten het maken en verwijderen van sleutelkluizen, het ophalen van Key Vault-eigenschappen en het bijwerken van toegangsbeleid. In het gegevensvlak werkt u met de gegevens die zijn opgeslagen in een sleutelkluis. U kunt sleutels, geheimen en certificaten toevoegen, verwijderen en wijzigen.

Beide vliegtuigen gebruiken Microsoft Entra-id voor verificatie. Voor autorisatie maakt het beheervlak gebruik van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) en maakt het gegevensvlak gebruik van een Key Vault-toegangsbeleid en Azure RBAC voor bewerkingen in het gegevensvlak van Key Vault.

Voor toegang tot een sleutelkluis in beide lagen moeten alle bellers (gebruikers of toepassingen) over de juiste verificatie en autorisatie beschikken. Met verificatie wordt de identiteit van de beller vastgesteld. Autorisatie bepaalt welke bewerkingen de aanroeper kan uitvoeren. Verificatie met Key Vault werkt in combinatie met Microsoft Entra-id, die verantwoordelijk is voor het verifiëren van de identiteit van een bepaalde beveiligingsprincipaal.

Een beveiligingsprincipal is een object dat een gebruiker, groep, service of toepassing vertegenwoordigt die toegang tot Azure-resources aanvraagt. Azure wijst een unieke object-id toe aan elke beveiligingsprincipal.

• Een beveiligingsprincipaal voor gebruikers identificeert een persoon die een profiel in Microsoft Entra-id heeft.
• Een beveiligingsprincipaal voor groepen identificeert een set gebruikers die zijn gemaakt in Microsoft Entra-id. Elke rol of machtiging die wordt toegewezen aan de groep, geldt voor alle gebruikers in de groep.
• Een service-principal is een type beveiligingsprincipaal dat een toepassing of service identificeert, bijvoorbeeld een stukje code in plaats van een gebruiker of groep. De object-id van een service-principal wordt aangeduid als de client-id en fungeert als de bijbehorende gebruikersnaam. Het clientgeheim of certificaat van de service-principal fungeert als het wachtwoord. Veel Azure Services bieden ondersteuning voor het toewijzen van beheerde identiteiten met geautomatiseerd beheer van client-id's en certificaten. Beheerde identiteit is de veiligste en aanbevolen optie voor verificatie binnen Azure.

Zie Verifiëren bij Azure Key Vault voor meer informatie over verificatie bij Key Vault.

Voorwaardelijke toegang

Key Vault biedt ondersteuning voor beleid voor voorwaardelijke toegang van Microsoft Entra. Met behulp van beleid voor voorwaardelijke toegang kunt u de juiste toegangsbeheer toepassen op Key Vault wanneer dat nodig is om uw organisatie veilig te houden en op de manier van uw gebruiker te blijven wanneer dat niet nodig is.

Zie het overzicht van voorwaardelijke toegang voor meer informatie

Bevoegde toegang

Autorisatie bepaalt welke bewerkingen de beller kan uitvoeren. Autorisatie in Key Vault maakt gebruik van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) op het beheervlak en het toegangsbeleid van Azure RBAC of Azure Key Vault op het gegevensvlak.

Toegang tot kluizen vindt plaats via twee interfaces of vlakken. Deze vlakken zijn het beheervlak en het gegevensvlak.

• Het beheervlak is waar u Key Vault zelf beheert en het is de interface die wordt gebruikt om kluizen te maken en te verwijderen. U kunt ook eigenschappen van de key vault lezen en het toegangsbeleid beheren.
• Met het gegevensvlak kunt u werken met de gegevens die zijn opgeslagen in een sleutelkluis. U kunt sleutels, geheimen en certificaten toevoegen, verwijderen en wijzigen.

Toepassingen hebben toegang tot de vliegtuigen via eindpunten. De toegangsbeheer voor de twee vliegtuigen werken onafhankelijk. Als u een toepassing toegang wilt verlenen tot het gebruik van sleutels in een sleutelkluis, verleent u toegang tot het gegevensvlak met behulp van Azure RBAC of een Key Vault-toegangsbeleid. Als u een gebruiker leestoegang wilt verlenen tot Key Vault-eigenschappen en -tags, maar geen toegang tot gegevens (sleutels, geheimen of certificaten), verleent u toegang tot het beheervlak met Azure RBAC.

In de volgende tabel ziet u de eindpunten voor de beheer- en gegevensvlakken.

Toegangslaag	Eindpunten voor toegang	Operations	Mechanisme voor toegangsbeheer
Beheerlaag	Wereldwijd: management.azure.com:443 Microsoft Azure beheerd door 21Vianet: management.chinacloudapi.cn:443 Azure van de Amerikaanse overheid: management.usgovcloudapi.net:443 Azure Duitsland: management.microsoftazure.de:443	Sleutelkluizen maken, lezen, bijwerken en verwijderen Toegangsbeleid voor Key Vault instellen Key Vault-tags instellen	Azure RBAC
Gegevenslaag	Wereldwijd: <kluisnaam>.vault.azure.net:443 Microsoft Azure beheerd door 21Vianet: <kluisnaam>.vault.azure.cn:443 Azure van de Amerikaanse overheid: <kluisnaam>.vault.usgovcloudapi.net:443 Azure Duitsland: <kluisnaam>.vault.microsoftazure.de:443	Sleutels: versleutelen, ontsleutelen, wrapKey, unwrapKey, sign, verify, get, list, create, update, import, delete, recover, backup, restore, purge, rotate (preview), getrotationpolicy (preview), setrotationpolicy (preview), release (preview) Certificaten: managecontacts, getissuers, listissuers, setissuers, deleteissuers, manageissuers, get, list, create, import, update, delete, recover, backup, restore, purge Geheimen: ophalen, weergeven, instellen, verwijderen, herstellen, back-up, herstellen, opschonen	Key Vault-toegangsbeleid of Azure RBAC

Beheertoegang tot Key Vault beheren

Wanneer u een sleutelkluis in een resourcegroep maakt, beheert u de toegang met behulp van Microsoft Entra-id. U verleent gebruikers of groepen de mogelijkheid om de sleutelkluizen in een resourcegroep te beheren. U kunt toegang verlenen op een specifiek bereikniveau door de juiste Azure-rollen toe te wijzen. Als u toegang wilt verlenen aan een gebruiker voor het beheren van sleutelkluizen, wijst u een vooraf gedefinieerde key vault Contributor rol toe aan de gebruiker op een specifiek bereik. De volgende bereiken kunnen worden toegewezen aan een Azure-rol:

• Abonnement: Een Azure-rol die op abonnementsniveau is toegewezen, is van toepassing op alle resourcegroepen en resources binnen dat abonnement.
• Resourcegroep: Een Azure-rol die op het niveau van de resourcegroep is toegewezen, is van toepassing op alle resources in die resourcegroep.
• Specifieke resource: een Azure-rol die is toegewezen voor een specifieke resource, is van toepassing op die resource. In dit geval is de resource een specifieke sleutelkluis.

Er zijn verschillende vooraf gedefinieerde rollen. Als een vooraf gedefinieerde rol niet aan uw behoeften voldoet, kunt u uw eigen rol definiëren. Zie Azure RBAC: Ingebouwde rollen voor meer informatie.

Belangrijk

Wanneer u het machtigingsmodel voor toegangsbeleid gebruikt, kan een gebruiker met de Contributor, Key Vault Contributorof een andere rol die machtigingen voor het beheervlak van de sleutelkluis bevat Microsoft.KeyVault/vaults/write , zichzelf gegevensvlaktoegang verlenen door een Key Vault-toegangsbeleid in te stellen. Om onbevoegde toegang en beheer van uw sleutelkluizen, sleutels, geheimen en certificaten te voorkomen, is het essentieel om de roltoegang van inzenders tot sleutelkluizen onder het machtigingsmodel voor toegangsbeleid te beperken. Om dit risico te beperken, raden we u aan het RBAC-machtigingsmodel (Role-Based Access Control) te gebruiken, waardoor machtigingsbeheer wordt beperkt tot de rollen 'Eigenaar' en 'Beheerder voor gebruikerstoegang', waardoor een duidelijke scheiding tussen beveiligingsbewerkingen en administratieve taken mogelijk is. Zie de Key Vault RBAC-handleiding en wat is Azure RBAC? voor meer informatie.

Toegang tot Key Vault-gegevens beheren

U kunt de toegang tot Key Vault-sleutels, certificaten en geheimen beheren met behulp van toegangsbeleid voor Azure RBAC of Key Vault.

Zie voor meer informatie

• Azure RBAC voor bewerkingen van key vault-gegevensvlakken.
• Key Vault-toegangsbeleid

Logboekregistratie en controle

Logboekregistratie van Key Vault slaat informatie op over de activiteiten die in uw kluis worden uitgevoerd. Zie Key Vault-logboekregistratie voor meer informatie.

U kunt Key Vault integreren met Event Grid om een melding te ontvangen wanneer de status van een sleutel, certificaat of geheim dat is opgeslagen in de sleutelkluis is gewijzigd. Zie Key Vault bewaken met Azure Event Grid voor meer informatie

Het is ook belangrijk om de status van uw sleutelkluis te controleren om ervoor te zorgen dat uw service werkt zoals bedoeld. Zie Bewaking en waarschuwingen voor Azure Key Vault voor meer informatie.

Back-up en herstel

Met Beveiliging tegen voorlopig verwijderen en opschonen van Azure Key Vault kunt u verwijderde kluizen en kluisobjecten herstellen. Zie het overzicht van voorlopig verwijderen in Azure Key Vault voor meer informatie.

U moet ook regelmatig back-ups van uw kluis maken bij het bijwerken/verwijderen/maken van objecten in een kluis.

Volgende stappen

• Azure Key Vault-beveiligingsbasislijn
• Best practices voor Azure Key Vault
• Service-eindpunten voor virtuele netwerken voor Azure Key Vault
• Azure RBAC: ingebouwde rollen