Basisconcepten van Azure Key Vault
Azure Key Vault is een cloudservice voor het veilig opslaan en openen van geheimen. Een geheim is alles waartoe u de toegang strikt wilt beheren, zoals API-sleutels, wachtwoorden, certificaten of cryptografische sleutels. De Key Vault-service ondersteunt twee typen containers: kluizen en beheerde HSM-pools (Hardware Security Module). Kluizen ondersteunen het opslaan van door software en HSM ondersteunde sleutels, geheimen en certificaten. Beheerde HSM-pools ondersteunen alleen sleutels met HSM-ondersteuning. Zie het overzicht van de REST API van Azure Key Vault voor volledige details.
Hier volgen andere belangrijke termen:
Tenant: een tenant is de organisatie die een specifiek exemplaar van Microsoft-cloudservices in eigendom heeft en beheert. Het wordt meestal gebruikt om te verwijzen naar de set Azure- en Microsoft 365-services voor een organisatie.
Kluiseigenaar: een kluiseigenaar kan een sleutelkluis maken en heeft er volledige toegang toe en controle over. De eigenaar van de kluis kan ook controles instellen om vast te leggen wie toegang heeft tot geheimen en sleutels. Beheerders kunnen de levenscyclus van sleutels beheren. Ze kunnen een nieuwe versie van de sleutel instellen, een back-up maken en gerelateerde taken uitvoeren.
Kluisconsument: een kluisconsument kan acties uitvoeren op de elementen in de sleutelkluis wanneer de eigenaar van de kluis toegang verleent aan de consument. De beschikbare acties zijn afhankelijk van de verleende machtigingen.
Beheerde HSM-beheerders: gebruikers aan wie de beheerdersrol is toegewezen, hebben volledige controle over een beheerde HSM-pool. Ze kunnen meer roltoewijzingen maken om gecontroleerde toegang tot andere gebruikers te delegeren.
Beheerde HSM Crypto Officer/Gebruiker: ingebouwde rollen die meestal worden toegewezen aan gebruikers of service-principals die cryptografische bewerkingen uitvoeren met behulp van sleutels in beheerde HSM. Cryptogebruiker kan nieuwe sleutels maken, maar kan geen sleutels verwijderen.
Versleutelingsgebruiker voor beheerde HSM-cryptoservice: ingebouwde rol die meestal wordt toegewezen aan een beheerde service-id voor serviceaccounts (bijvoorbeeld opslagaccount) voor versleuteling van data-at-rest met door de klant beheerde sleutel.
Resource: een resource is een beheerbaar item dat beschikbaar is via Azure. Veelvoorkomende voorbeelden zijn virtuele machine, opslagaccount, web-app, database en virtueel netwerk. Er zijn nog veel meer.
Resourcegroep: een resourcegroep is een container met gerelateerde resources voor een Azure-oplossing. De resourcegroep kan alle resources voor de oplossing bevatten of enkel de resources die u als groep wilt beheren. U bepaalt hoe resources worden toegewezen aan resourcegroepen op basis van wat voor uw organisatie het meest zinvol is.
Beveiligingsprincipaal: Een Azure-beveiligingsprincipaal is een beveiligingsidentiteit die door de gebruiker gemaakte apps, services en automatiseringsprogramma's gebruikt voor toegang tot specifieke Azure-resources. U kunt het beschouwen als een 'gebruikersidentiteit' (gebruikersnaam en wachtwoord of certificaat) met een specifieke rol en nauw beheerde machtigingen. Een beveiligingsprincipaal hoeft alleen specifieke dingen te doen, in tegenstelling tot een algemene gebruikersidentiteit. Het verbetert de beveiliging als u het alleen het minimale machtigingsniveau verleent dat nodig is om de beheertaken uit te voeren. Een beveiligingsprincipaal die wordt gebruikt met een toepassing of service, wordt een service-principal genoemd.
Microsoft Entra-id: Microsoft Entra-id is de Active Directory-service voor een tenant. Elke adreslijst heeft een of meer domeinen. Aan een directory kunnen vele abonnementen zijn gekoppeld, maar slechts één tenant.
Azure-tenant-id: een tenant-id is een unieke manier om een Microsoft Entra-exemplaar binnen een Azure-abonnement te identificeren.
Beheerde identiteiten: Azure Key Vault biedt een manier om referenties en andere sleutels en geheimen veilig op te slaan, maar uw code moet worden geverifieerd bij Key Vault om ze op te halen. Het gebruik van een beheerde identiteit maakt het oplossen van dit probleem eenvoudiger door Azure-services een automatisch beheerde identiteit te geven in Microsoft Entra-id. U kunt deze identiteit gebruiken om te verifiëren bij Key Vault of een service die ondersteuning biedt voor Microsoft Entra-verificatie, zonder referenties in uw code te hebben. Zie de volgende afbeelding en het overzicht van beheerde identiteiten voor Azure-resources voor meer informatie.
Verificatie
Als u bewerkingen wilt uitvoeren met Key Vault, moet u zich eerst verifiëren. Er zijn drie manieren om te verifiëren bij Key Vault:
- Beheerde identiteiten voor Azure-resources: wanneer u een app implementeert op een virtuele machine in Azure, kunt u een identiteit toewijzen aan uw virtuele machine die toegang heeft tot Key Vault. U kunt ook identiteiten toewijzen aan andere Azure-resources. Het voordeel van deze aanpak is dat de app of service de rotatie van het eerste geheim niet beheert. Azure draait de identiteit automatisch. We raden deze aanpak aan als best practice.
- Service-principal en certificaat: u kunt een service-principal en een gekoppeld certificaat gebruiken dat toegang heeft tot Key Vault. We raden deze methode niet aan omdat de eigenaar van de toepassing of ontwikkelaar het certificaat moet roteren.
- Service-principal en geheim: Hoewel u een service-principal en een geheim kunt gebruiken om te verifiëren bij Key Vault, raden we dit niet aan. Het is moeilijk om het bootstrapgeheim dat wordt gebruikt voor verificatie bij Key Vault automatisch te roteren.
Versleuteling van gegevens in transit
Azure Key Vault dwingt TLS-protocol (Transport Layer Security) af om gegevens te beveiligen wanneer ze reizen tussen Azure Key Vault en clients. Clients onderhandelen over een TLS-verbinding met Azure Key Vault. TLS biedt sterke verificatie, privacy en integriteit van berichten (waardoor berichten worden gemanipuleerd, onderschept en vervalst), interoperabiliteit, flexibiliteit van algoritmen en gebruiksgemak en gebruiksgemak.
Perfect Forward Secrecy (PFS) beschermt verbindingen tussen clientsystemen van klanten en Microsoft-cloudservices met unieke sleutels. Verbindingen maken ook gebruik van op RSA gebaseerde 2048-bits versleutelingssleutellengten. Deze combinatie maakt het moeilijk voor iemand om gegevens te onderscheppen en te openen die onderweg zijn.
Rollen van Key Vault
Gebruik de volgende tabel om beter te begrijpen hoe Key Vault u kan helpen om aan de behoeften van ontwikkelaars en beveiligingsadministrators te voldoen.
| Role | Probleemformulering | Opgelost door Azure Key Vault |
|---|---|---|
| Ontwikkelaar voor een Azure-toepassing | "Ik wil een toepassing schrijven voor Azure die gebruikmaakt van sleutels voor ondertekening en versleuteling. Maar ik wil dat deze sleutels extern zijn vanuit mijn toepassing, zodat de oplossing geschikt is voor een toepassing die geografisch is gedistribueerd. Ik wil dat deze sleutels en geheimen worden beveiligd, zonder dat ik de code zelf hoef te schrijven. Ik wil ook dat deze sleutels en geheimen gemakkelijk kunnen worden gebruikt vanuit mijn toepassingen, met optimale prestaties." |
√ De sleutels worden opgeslagen in een kluis en wanneer dit nodig is, aangeroepen via een URI. √ De sleutels worden beveiligd door Azure. Hiervoor wordt gebruikgemaakt van algoritmen, sleutellengten en HSM's die voldoen aan de industriestandaard. √ Sleutels worden verwerkt in HSM's die zich in dezelfde Azure-datacenters bevinden als de toepassingen. Deze methode biedt betere betrouwbaarheid en minder latentie dan wanneer de sleutels zich op een afzonderlijke locatie bevinden, zoals on-premises. |
| SaaS-ontwikkelaar (Software as a Service) | "Ik wil niet de verantwoordelijkheid of potentiële aansprakelijkheid voor de tenantsleutels en geheimen van mijn klanten. Ik wil dat klanten hun sleutels bezitten en beheren, zodat ik me kan concentreren op wat ik het beste doe, wat de kernsoftwarefuncties biedt." |
√ Klanten kunnen hun eigen sleutels in Azure importeren en beheren. Wanneer een SaaS-toepassing cryptografische bewerkingen moet uitvoeren met behulp van de sleutels van klanten, voert Key Vault deze bewerkingen uit namens de toepassing. De toepassing ziet de sleutels van de klanten niet. |
| Chief Security Officer (CSO) | "Ik wil weten dat onze toepassingen voldoen aan FIPS 140 Level 3 HSM's voor veilig sleutelbeheer. Ik wil ervoor zorgen dat mijn organisatie de controle heeft over de levenscyclus van de sleutel en het sleutelgebruik kan bewaken. En hoewel we meerdere Azure-services en -resources gebruiken, wil ik de sleutels beheren vanaf één locatie in Azure. |
√ Kies kluizen of beheerde HSM's voor gevalideerde HSM's van FIPS 140. √ Kies beheerde HSM-pools voor met FIPS 140-2 niveau 3 gevalideerde HSM's. √ Key Vault is zodanig ontworpen dat Microsoft uw sleutels niet kan zien of extraheren. √ Sleutelgebruik wordt vrijwel in realtime vastgelegd. √ De kluis biedt één interface, ongeacht het aantal kluizen dat u in Azure hebt, welke regio's ze ondersteunen en door welke toepassingen ze worden gebruikt. |
Iedereen met een Azure-abonnement kan sleutelkluizen maken en gebruiken. Hoewel Key Vault voordelen biedt voor ontwikkelaars en beveiligingsbeheerders, kan deze worden geïmplementeerd en beheerd door de beheerder van een organisatie die andere Azure-services beheert. Deze beheerder kan zich bijvoorbeeld aanmelden met een Azure-abonnement, een kluis maken voor de organisatie waarin sleutels moeten worden opgeslagen en vervolgens verantwoordelijk zijn voor operationele taken zoals deze:
- Een sleutel of geheim maken of importeren.
- Een sleutel of geheim intrekken of verwijderen.
- Gebruikers of toepassingen machtigingen verlenen voor toegang tot de sleutelkluis, zodat ze de sleutels en geheimen in de kluis kunnen beheren of gebruiken.
- Sleutelgebruik configureren (bijvoorbeeld ondertekenen of versleutelen).
- Sleutelgebruik bewaken.
Deze beheerder geeft vervolgens ontwikkelaars-URI's om aan te roepen vanuit hun toepassingen. Deze beheerder geeft ook informatie over de logboekregistratie van belangrijke gebruiksgegevens aan de beveiligingsbeheerder.
Ontwikkelaars kunnen de sleutels ook rechtstreeks beheren door gebruik te maken van API's. Zie Ontwikkelaarshandleiding voor Key Vault voor meer informatie.
Volgende stappen
- Meer informatie over azure Key Vault-beveiligingsfuncties.
- Meer informatie over het beveiligen van uw beheerde HSM-pools
Azure Sleutelkluis is beschikbaar in de meeste regio's. Zie de pagina Prijzen van Key Vault voor meer informatie.