Je DevOps-team implementeert Azure Virtual Desktop-hostpools en sessiehosts via Bicep. Domain-join-referenties en een SSL-certificaat voor reverse connect moeten tijdens de implementatie worden geleverd zonder geheimen in broncode of parameterbestanden te plaatsen. Auditors vereisen dat geheimen herstelbaar zijn als ze per ongeluk worden verwijderd. Welke twee acties moet je ondernemen? Elk correct antwoord vertegenwoordigt een deel van de oplossing.

De correcte antwoorden zijn "Sla de referenties en het certificaat op in Azure Key Vault met soft-delete en purge protection ingeschakeld" en "Wijs een user-assigned managed identity toe aan de implementatie en verleen deze get- en list-machtigingen voor de Key Vault; verwijs naar geheimen met behulp van de ARM/Bicep listSecret-functie." Azure Key Vault is de aanbevolen service voor het veilig opslaan van geheimen zoals referenties en certificaten. Soft-delete en purge protection zorgen ervoor dat geheimen herstelbaar zijn, zelfs na onbedoelde verwijdering, wat voldoet aan de auditvereisten. Een user-assigned managed identity biedt een veilige manier voor de Bicep-implementatie om toegang te krijgen tot de Key Vault zonder dat er geheimen in de code of parameterbestanden hoeven te worden opgeslagen. De listSecret-functie in Bicep/ARM maakt het mogelijk om de geheimen dynamisch op te halen tijdens de implementatie. De andere opties zijn onveilig of voldoen niet aan de vereisten: Geheimen in een Azure DevOps-variabelengroep opslaan en als plain-text doorgeven is onveilig. Het certificaat PFX base64 in het Bicep-bestand insluiten is onveilig en plaatst geheimen in broncode. Geheimen ophalen uit een Automation Account-referentieasset na de implementatie is niet geschikt voor het leveren van geheimen tijdens de implementatie zelf.