Proteggere i parametri
A volte è necessario passare valori sensibili alle distribuzioni, ad esempio password e chiavi API. È però necessario assicurarsi che questi valori siano protetti. In alcune situazioni non è desiderabile che la persona che crea la distribuzione conosca i valori segreti. In altri casi, un utente immetterà il valore del parametro quando crea la distribuzione, ma occorre garantire che i valori segreti non vengano registrati. In questa unità verranno illustrati i modi in cui è possibile proteggere i parametri.
Suggerimento
L'approccio migliore consiste nell'evitare completamente l'uso delle credenziali. Le identità gestite per le risorse di Azure possono consentire ai componenti della soluzione di comunicare in modo sicuro senza bisogno di credenziali. Le identità gestite non sono disponibili per tutte le risorse, ma è consigliabile usarle ovunque sia possibile. Nei casi in cui non sono disponibili, è possibile usare gli approcci descritti qui.
Nota
I comandi riportati in questa unità vengono illustrati per spiegare i concetti. Non eseguire ancora i comandi. Presto sarà possibile provare quanto appreso.
Definire parametri protetti
È possibile applicare l'espressione Decorator @secure a parametri di stringa e oggetto che potrebbero contenere valori segreti. Quando si definisce un parametro come @secure, Azure non rende disponibili i valori del parametro nei log di distribuzione. Inoltre, se si crea la distribuzione in modo interattivo usando l'interfaccia della riga di comando di Azure o Azure PowerShell ed è necessario immettere i valori durante la distribuzione, il terminale non mostrerà il testo sullo schermo.
Come parte della migrazione dell'applicazione HR, è necessario distribuire un server logico e un database SQL di Azure. Si eseguirà il provisioning del server logico con un account di accesso e una password di amministratore. Poiché si tratta di valori sensibili, è necessario che siano protetti. Di seguito è riportata una dichiarazione di esempio per creare due parametri stringa per i dettagli dell'amministratore del server SQL:
@secure()
param sqlServerAdministratorLogin string
@secure()
param sqlServerAdministratorPassword string
Si noti che per nessuno dei due parametri è specificato un valore predefinito. È consigliabile evitare di specificare valori predefiniti per nomi utente, password e altri segreti. In caso contrario, se un utente distribuisce il modello e non si rende conto che deve sostituire il valore, comprometterà la sua stessa sicurezza, perché otterrà il valore predefinito anziché uno che ha scelto in prima persona.
Suggerimento
Assicurarsi di non creare output per i dati sensibili. I valori di output sono accessibili a chiunque abbia accesso alla cronologia di distribuzione. Non sono appropriati per la gestione dei segreti.
Evitare di usare file di parametri per i segreti
Come si è appreso nell'unità precedente, i file di parametri sono un ottimo strumento per specificare un set di valori di parametri. Spesso si creeranno file di parametri per ogni ambiente in cui si esegue la distribuzione. In generale, è consigliabile evitare di usare file di parametri per specificare i valori segreti. I file di parametri vengono spesso salvati in un sistema di controllo della versione centralizzato, ad esempio Git. Molte persone potrebbero avervi accesso in futuro. Non salvare dati sensibili nei sistemi di controllo della versione, perché non sono progettati per archiviare questo tipo di informazioni.
Integrazione con Azure Key Vault
Azure Key Vault è un servizio progettato per archiviare e fornire accesso ai segreti. È possibile integrare i modelli Bicep con Key Vault usando un file di parametri con un riferimento a un segreto di Key Vault.
Si può usare questa funzionalità facendo riferimento all'insieme di credenziali delle chiavi e al segreto nel file di parametri. Il valore non viene mai esposto perché si fa riferimento solo al suo identificatore, che di per sé non è un segreto. Al momento della distribuzione del modello, Azure Resource Manager contatterà l'insieme di credenziali delle chiavi per recuperare i dati.
Suggerimento
È possibile fare riferimento ai segreti negli insiemi di credenziali delle chiavi che si trovano in un gruppo di risorse o in una sottoscrizione diversa da quella in cui si sta eseguendo la distribuzione.
Di seguito è riportato un file di parametri che usa riferimenti a Key Vault per cercare l'account di accesso e la password dell'amministratore del server logico SQL da usare:
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"sqlServerAdministratorLogin": {
"reference": {
"keyVault": {
"id": "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/PlatformResources/providers/Microsoft.KeyVault/vaults/toysecrets"
},
"secretName": "sqlAdminLogin"
}
},
"sqlServerAdministratorPassword": {
"reference": {
"keyVault": {
"id": "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/PlatformResources/providers/Microsoft.KeyVault/vaults/toysecrets"
},
"secretName": "sqlAdminLoginPassword"
}
}
}
}
Si noti che, invece di specificare value per ognuno dei parametri, questo file ha un oggetto reference che contiene i dettagli dell'insieme di credenziali delle chiavi e del segreto.
Importante
L'insieme di credenziali delle chiavi deve essere configurato in modo da consentire a Resource Manager di accedere ai dati al suo interno durante le distribuzioni del modello. Inoltre, l'utente che distribuisce il modello deve disporre dell'autorizzazione per accedere all'insieme di credenziali delle chiavi. Queste attività verranno illustrate nell'unità successiva.
Usare Key Vault con moduli
I moduli consentono di creare file Bicep riutilizzabili che incapsulano un set di risorse. È comune usare i moduli per distribuire parti di una soluzione. I moduli possono contenere parametri che accettano valori segreti ed è possibile usare l'integrazione di Key Vault con Bicep per fornire questi valori in modo sicuro. Di seguito è riportato un file Bicep di esempio che distribuisce un modulo e fornisce il valore del parametro segreto ApiKey prendendolo direttamente da Key Vault:
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
name: keyVaultName
}
module applicationModule 'application.bicep' = {
name: 'application-module'
params: {
apiKey: keyVault.getSecret('ApiKey')
}
}
Notare che in questo file Bicep si fa riferimento alla risorsa Key Vault usando la parola chiave existing. La parola chiave indica a Bicep che l'istanza di Key Vault esiste già. Questo codice è un riferimento a tale insieme di credenziali. Bicep non lo ridistribuirà. Notare inoltre che il codice del modulo usa la funzione getSecret() nel valore per il parametro apiKey del modulo. Si tratta di una funzione Bicep speciale che può essere usata solo con i parametri di modulo protetti. Internamente, Bicep traduce questa espressione nello stesso tipo di riferimento a Key Vault illustrato in precedenza.