Azure Key Vault-beveiliging

3 minuten

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.

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.

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.

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 (Network Address Translation), 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.

Transport Layer Security (TLS) en Hypertext Transfer Protocol Secure (HTTPS)

De Key Vault-front-end (gegevensvlak) is een multitenant-server. 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.

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. Dit scenario werkt alleen als de object-id van de toepassing is opgegeven in het toegangsbeleid en de applicationId niet mag worden opgegeven of null moet zijn.
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. Dit scenario werkt alleen als de object-id van de gebruiker is opgegeven in het toegangsbeleid en de applicationId niet mag worden opgegeven of null moet zijn.
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. Voor dit scenario moeten zowel applicationId als objectId worden opgegeven in het toegangsbeleid. De applicationId identificeert de vereiste toepassing en de objectId identificeert de gebruiker. 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.

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, bijvoorbeeld om meervoudige verificatie in te schakelen voor extra beveiliging.

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, dat verantwoordelijk is voor het verifiëren van de identiteit van elke opgegeven beveiligingsprincipal.

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.

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.

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.

Toegangsvlak	Toegangseindpunten	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, back-up, restore, purge, rotate (preview), getrotationpolicy (preview), setrotationpolicy (preview), release (preview) Certificaten: contactpersonen beheren, getissuers, lijstuitgevers, verleners instellen, verleners verwijderen, verleners beheren, ophalen, vermelden, maken, importeren, bijwerken, verwijderen, herstellen, back-ups maken, herstellen, opschonen Geheimen: ophalen, weergeven, instellen, verwijderen, herstellen, een back-up maken, 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 rol Inzender aan de gebruiker toe voor 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.

Wanneer u het toegangsbeleidsmachtigingsmodel gebruikt en een gebruiker machtigingen heeft Contributor voor een beheervlak van een sleutelkluis, kan de gebruiker zichzelf toegang verlenen tot het gegevensvlak door een Key Vault-toegangsbeleid in te stellen. U moet nauwkeurig bepalen wie roltoegang heeft Contributor tot uw sleutelkluizen met het machtigingsmodel voor toegangsbeleid om ervoor te zorgen dat alleen geautoriseerde personen toegang hebben tot uw sleutelkluizen, sleutels, geheimen en certificaten. Het is raadzaam het nieuwe RBAC-machtigingsmodel (Role Based Access Control) te gebruiken om dit probleem te voorkomen. Met het RBAC-machtigingsmodel is het machtigingsbeheer beperkt tot de rollen 'Eigenaar' en 'Beheerder voor gebruikerstoegang', waardoor scheiding van taken tussen rollen voor beveiligingsbewerkingen en algemene beheerbewerkingen mogelijk is.

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.

Logboekregistratie en controle

Logboekregistratie van Key Vault slaat informatie op over de activiteiten die in uw kluis worden uitgevoerd.

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.

Het is ook belangrijk om de status van uw sleutelkluis te controleren om ervoor te zorgen dat uw service werkt zoals bedoeld.

Back-up en herstel

Met Beveiliging tegen voorlopig verwijderen en opschonen van Azure Key Vault kunt u verwijderde kluizen en kluisobjecten herstellen.

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