Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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.
In de aanbevelingen voor beveiliging in dit artikel worden zero Trust-principes geïmplementeerd: 'Expliciet verifiëren', 'Minimale toegang tot bevoegdheden gebruiken' en 'Inbreuk aannemen'. Zie het Zero Trust Guidance Center voor uitgebreide richtlijnen voor Zero Trust.
Dit artikel bevat aanbevelingen voor beveiliging om uw Azure Key Vault-implementatie te beveiligen.
Servicespecifieke beveiliging
Azure Key Vault heeft unieke beveiligingsoverwegingen met betrekking tot kluisarchitectuur en het juiste gebruik van de service voor het opslaan van cryptografische materialen.
Gebruik één Key Vault per toepassing, regio en omgeving: maak afzonderlijke Key Vaults voor ontwikkeling, preproductie en productieomgevingen om de impact van schendingen te verminderen.
Sleutelkluizen definiëren beveiligingsgrenzen voor opgeslagen geheimen. Als u geheimen in dezelfde kluis groepeert, neemt de impactgebied van een beveiligingsgebeurtenis toe, omdat aanvallen mogelijk toegang hebben tot geheimen in verschillende belangen. Als u de toegang over verschillende belangen wilt beperken, overweeg dan tot welke geheimen een specifieke toepassing toegang moet hebben en verdeel vervolgens uw sleutelkluizen op basis van deze criteria. Het scheiden van sleutelkluizen per applicatie is de meest voorkomende scheidingslijn. Beveiligingsgrenzen kunnen echter gedetailleerder zijn voor grote toepassingen, bijvoorbeeld per groep gerelateerde services.
Gebruik één Key Vault per tenant in multitenant-oplossingen: Voor saaS-oplossingen met meerdere tenants gebruikt u een afzonderlijke Key Vault voor elke tenant om gegevensisolatie te onderhouden. Deze benadering biedt een veilige isolatie van klantgegevens en workloads. Zie Multitenancy en Azure Key Vault voor meer informatie.
Gebruik Key Vault niet als een gegevensarchief voor de configuratie van de klant of service: Services moeten Azure Storage gebruiken met versleuteling-at-rest of Azure App Configuration. Deze opties zijn beter presterend voor configuratiescenario's.
Sla certificaten (eigendom van klant of service) niet op als geheimen: Sla certificaten in eigendom van de service op als Key Vault certificaten en configureer ze voor automatisch roteren. Zie Azure Key Vault voor meer informatie: Certificaten en informatie over automatischerotatie in Azure Key Vault.
Sla geen klantinhoud op in Key Vault: Key Vault is geen gegevensarchief en is niet gebouwd om te schalen als een. Gebruik in plaats daarvan Azure Cosmos DB of Azure Storage. Klanten die BYOK (Bring Your Own Key) voor versleuteling in rust willen, kunnen de wrappingsleutel opslaan in Azure Key Vault en gebruiken om gegevens in Azure Storage te versleutelen.
Netwerkbeveiliging
Het verminderen van de netwerkblootstelling is essentieel voor het beveiligen van Azure Key Vault tegen onbevoegde toegang. Netwerkbeperkingen configureren op basis van de vereisten en use-case van uw organisatie. Zie Netwerkbeveiliging configureren voor Azure Key Vault voor gedetailleerde informatie en stapsgewijze configuratie-instructies.
Deze netwerkbeveiligingsfuncties worden weergegeven van de meest beperkte tot minst beperkte mogelijkheden. Kies de configuratie die het beste past bij de use-case van uw organisatie.
Schakel alleen openbare netwerktoegang uit en gebruik privé-eindpunten: Implementeer Azure Private Link om een privétoegangspunt tot stand te brengen vanuit een virtueel netwerk naar Azure Key Vault en voorkom blootstelling aan het openbare internet. Als u openbare toegang uitschakelt, worden verbindingen met het gegevensvlak geblokkeerd; De openbare DNS-records van de kluis kunnen standaard worden omgezet (zie openbare DNS-zichtbaarheid van een persoonlijke sleutelkluis). Zie Key Vault integreren met Azure Private Link voor implementatiestappen.
- Voor sommige klantscenario's is vertrouwde Microsoft-services vereist om de firewall te omzeilen. In dergelijke gevallen moet de kluis mogelijk worden geconfigureerd om vertrouwde Microsoft-services toe te staan. Zie Vertrouwde services voor de huidige lijst met services die de firewall omzeilen wanneer deze optie is ingeschakeld. De bypass blijft van toepassing wanneer openbare toegang is uitgeschakeld. Zie Netwerkbeveiliging configureren voor stapsgewijze instructies: Key Vault firewall ingeschakeld (alleen vertrouwde services).
Key Vault-firewall inschakelen: beperk de toegang tot openbare statische IP-adressen of uw virtuele netwerken. Zie Netwerkbeveiliging configureren voor meer informatie: Firewallinstellingen.
- Voor sommige klantscenario's is vertrouwde Microsoft-services vereist om de firewall te omzeilen. In dergelijke gevallen moet de kluis mogelijk worden geconfigureerd om vertrouwde Microsoft-services toe te staan. Alleen services in de tabel Vertrouwde services worden door deze optie toegelaten; Microsoft-services die niet in de lijst staan (bijvoorbeeld Azure DevOps) nog steeds een firewall-IP-regel, een regel voor een virtueel netwerk of een privé-eindpunt nodig hebben.
Netwerkbeveiligingsperimeter gebruiken: definieer een logische netwerkisolatiegrens voor PaaS-resources (bijvoorbeeld Azure Key Vault, Azure Storage en SQL Database) die buiten de perimeter van het virtuele netwerk en/of openbare statische IP-adressen van uw organisatie worden geïmplementeerd. Zie Netwerkbeveiliging configureren voor meer informatie: Netwerkbeveiligingsperimeter.
-
publicNetworkAccess: SecuredByPerimeteroverschrijft 'Vertrouwde Microsoft-services toestaan om de firewall te omzeilen', wat betekent dat sommige scenario's waarvoor een vertrouwensrelatie is vereist, niet werken.
-
TLS-versiebeheer afdwingen op clients: Azure Key Vault ondersteunt TLS 1.2 en 1.3. Omdat de Key Vault front-end een multitenant-service is waarbij kluizen van verschillende klanten hetzelfde openbare IP-adres kunnen delen, wordt elke HTTPS-aanvraag geverifieerd en onafhankelijk geautoriseerd. Clients nemen deel aan TLS-onderhandeling, dus maak uw clients vast aan TLS 1.2 of 1.3 om ervoor te zorgen dat elke verbinding gebruikmaakt van het bijbehorende beveiligingsniveau. Zie Key Vault-logboekregistratie voor meer informatie en voorbeeldquery's in Kusto voor het bewaken van door clients gebruikte TLS-versies.
Identiteits- en toegangsbeheer
Azure Key Vault maakt gebruik van Microsoft Entra-id voor verificatie. Toegang wordt beheerd via twee interfaces: het besturingsvlak (voor het beheren van Key Vault zelf) en het gegevensvlak (voor het werken met sleutels, geheimen en certificaten). Zie Azure RBAC voor bewerkingen in het gegevensvlak van Key Vault voor meer informatie over het toegangsmodel en de eindpunten.
Beheerde identiteiten inschakelen: gebruik door Azure beheerde identiteiten voor alle app- en serviceverbindingen met Azure Key Vault om vastgelegde referenties te elimineren. Beheerde identiteiten helpen verificatie te beveiligen en de noodzaak van expliciete referenties te verwijderen. Zie Azure Key Vault-verificatie voor verificatiemethoden en -scenario's.
Op rollen gebaseerd toegangsbeheer gebruiken: Op rollen gebaseerd toegangsbeheer (RBAC) van Azure gebruiken om de toegang tot Azure Key Vault te beheren. Zie Azure RBAC voor bewerkingen in key vault-gegevensvlakken voor meer informatie.
- Gebruik geen verouderd toegangsbeleid: verouderde toegangsbeleidsregels hebben bekende beveiligingsproblemen en ontbreken ondersteuning voor Privileged Identity Management (PIM). Gebruik ze niet voor kritieke gegevens en workloads. Azure RBAC beperkt mogelijke risico's voor onbevoegde toegang tot Key Vault. Zie Azure op rollen gebaseerd toegangsbeheer (Azure RBAC) versus toegangsbeleid (verouderd) voor meer informatie.
Met het RBAC-autorisatiemodel zijn roltoewijzingen op kluisniveau mogelijk voor permanente toegang en in aanmerking komende JIT-toewijzingen voor bewerkingen met verhoogde bevoegdheden. Objectbereiktoewijzingen ondersteunen alleen leesbewerkingen; Voor beheerbewerkingen zoals netwerktoegangsbeheer, bewaking en objectbeheer zijn machtigingen op kluisniveau vereist. Gebruik één Key Vault per toepassing voor veilige isolatie tussen toepassingsteams.
Just-In-Time-rollen (JIT) toewijzen: Gebruik Azure Privileged Identity Management (PIM) om in aanmerking komende JIT Azure RBAC-rollen toe te wijzen voor beheerders en operators van Key Vault. Zie het overzicht van Privileged Identity Management (PIM) voor meer informatie.
- Goedkeuringen vereisen voor activering van bevoorrechte rollen: voeg een extra beveiligingslaag toe om onbevoegde toegang te voorkomen door ervoor te zorgen dat ten minste één fiatteur is vereist om JIT-rollen te activeren. Zie Microsoft Entra-rolinstellingen configureren in Privileged Identity Management voor meer informatie.
- Meervoudige verificatie afdwingen voor rolactivering: MFA vereisen om JIT-rollen te activeren voor operators en beheerders. Zie Microsoft Entra multifactor authentication voor meer informatie.
Beleid voor voorwaardelijke toegang van Microsoft Entra inschakelen: Key Vault ondersteunt beleid voor voorwaardelijke toegang van Microsoft Entra om toegangsbeheer toe te passen op basis van voorwaarden zoals gebruikerslocatie of apparaat. Zie het overzicht van voorwaardelijke toegang voor meer informatie.
Pas het principe van minimale bevoegdheden toe: beperk het aantal gebruikers met beheerdersrollen en zorg ervoor dat gebruikers alleen de minimale machtigingen krijgen die vereist zijn voor hun rol. Zie Beveiliging verbeteren met het principe van minimale bevoegdheden voor meer informatie.
Gegevensbeveiliging
Voor het beveiligen van gegevens die zijn opgeslagen in Azure Key Vault is het mogelijk om voorlopig verwijderen, opschonen en geautomatiseerde rotatie van cryptografische materialen in te schakelen.
Voorlopig verwijderen inschakelen: zorg ervoor dat voorlopig verwijderen is ingeschakeld, zodat u verwijderde Key Vault objecten binnen een bewaarperiode van 7 tot 90 dagen kunt herstellen. Voor meer informatie raadpleegt u de Azure Key Vault soft-delete-overzicht.
Purgebescherming inschakelen: Schakel purgebescherming in om te beschermen tegen onbedoelde of kwaadwillende verwijdering van Key Vault-objecten, zelfs nadat soft-delete is ingeschakeld. Zie Overzicht van voorlopig verwijderen in Azure Key Vault: beveiliging tegen opschonen voor meer informatie.
Automatischerotatie implementeren voor cryptografische assets: configureer automatische rotatie van sleutels, geheimen en certificaten om het risico op inbreuk te minimaliseren en naleving van beveiligingsbeleid te garanderen. Regelmatige rotatie van cryptografische materialen is een kritieke beveiligingspraktijk. Zie Autorotatie in Azure Key Vault begrijpen,Sleutel automatisch roteren configureren, Automatisch roteren van certificaten configureren, Geheimrotatieautomatiseren voor resources met één set verificatiereferenties en Geheimrotatie automatiserenvoor resources met twee sets verificatiereferenties.
Logboekregistratie en bewaking
Uitgebreide logboekregistratie en bewaking maken detectie van verdachte activiteiten en naleving van controlevereisten mogelijk.
Auditlogboekregistratie inschakelen: Key Vault-logboekregistratie slaat informatie op over bewerkingen die in de kluis worden uitgevoerd. Zie Key Vault logboekregistratie voor meer informatie.
Microsoft Defender voor Key Vault inschakelen: Schakel Microsoft Defender voor Key Vault in om verdachte activiteiten te controleren en te waarschuwen. Zie Inleiding tot Microsoft Defender voor Key Vault voor meer informatie.
Schakel logboekwaarschuwingen in voor beveiligingsgebeurtenissen: stel waarschuwingen in die moeten worden gewaarschuwd wanneer kritieke gebeurtenissen worden geregistreerd, zoals toegangsfouten of geheime verwijderingen. Zie Bewaking en waarschuwingen voor Azure Key Vault voor meer informatie.
Bewaken en waarschuwen: Integreer Key Vault met Event Grid om meldingen te ontvangen over wijzigingen in sleutels, certificaten of geheimen. Zie Bewaking Key Vault met Azure Event Grid voor meer informatie.
Naleving en bestuur
Regelmatige nalevingscontroles en governancebeleidsregels zorgen ervoor dat uw Key Vault-implementatie voldoet aan beveiligingsstandaarden en organisatievereisten.
- Gebruik Azure Policy om configuratie af te dwingen: Azure Policy configureren om beveiligde configuraties voor Azure Key Vault te controleren en af te dwingen en waarschuwingen in te stellen voor afwijkingen van beleid. Zie Azure Policy controles voor naleving van regelgeving voor Azure Key Vault voor meer informatie.
Back-up en herstel
Regelmatige back-ups zorgen voor bedrijfscontinuïteit en beschermen tegen gegevensverlies tegen onbedoelde of schadelijke verwijdering.
Systeemeigen back-up inschakelen voor Azure Key Vault: configureer en gebruik de systeemeigen back-upfunctie van Azure Key Vault om back-ups te maken van geheimen, sleutels en certificaten, zodat herstel mogelijk is. Zie Azure Key Vault back-up voor meer informatie.
Zorg ervoor dat back-ups worden gemaakt voor geheimen die niet opnieuw kunnen worden gemaakt: maak een back-up van Key Vault-objecten (zoals versleutelingssleutels) die niet opnieuw kunnen worden gemaakt vanuit andere bronnen. Zie Azure Key Vault back-up voor meer informatie.
Test back-up- en herstelprocedures: Als u de effectiviteit van back-upprocessen wilt controleren, test u regelmatig het herstel van Key Vault-geheimen, -sleutels en -certificaten. Zie Azure Key Vault back-up voor meer informatie.
Begrijp backup-onafhankelijkheid: een sleutel die is hersteld naar een andere kluis vanuit een back-up, is volledig onafhankelijk van de originelen. Het uitschakelen, verwijderen of opschonen van de oorspronkelijke sleutel heeft geen invloed op herstelde kopieën. Als u de sleutel uitschakelt of verwijdert, worden ook alle afhankelijke gegevensservices offline gehaald (SQL TDE-databases worden bijvoorbeeld ontoegankelijk en opslagaccounts met door de klant beheerde sleutels geven fouten terug). Als een sleutel verdacht wordt van een compromis, wisselt u naar een nieuwe sleutel en migreert u afhankelijke diensten voordat u de oude deactiveert. Zie De beveiligingsoverwegingen voor back-ups en het antwoord op sleutelinbreuken voor meer informatie.
Verwante beveiligingsartikelen
Voor aanbevolen beveiligingsprocedures die specifiek zijn voor sleutels, geheimen en certificaten, raadpleegt u:
- Beveilig uw Azure Key Vault sleutels: belangrijke beveiligingsprocedures, waaronder rotatie, HSM-beveiliging en BYOK.
- Beveilig uw Azure Key Vault-geheimen: specifieke best practices voor de beveiliging van geheimen, waaronder rotatie, caching en bewaking.
- Beveilig uw Azure Key Vault certificaten: best practices voor certificaatspecifieke beveiliging, waaronder levenscyclusbeheer, verlenging en CA-integratie.