Skydda dina parametrar

  • 4 minuter

Ibland måste du skicka känsliga värden till dina distributioner, till exempel lösenord och API-nycklar. Men du måste se till att dessa värden skyddas. I vissa situationer vill du inte att den person som skapar distributionen ska känna till de hemliga värdena. Andra gånger anger någon parametervärdet när de skapar distributionen, men du måste se till att de hemliga värdena inte loggas. I den här lektionen får du lära dig mer om hur du kan skydda dina parametrar.

Dricks

Det bästa sättet är att undvika att använda autentiseringsuppgifter helt och hållet. Hanterade identiteter för Azure-resurser kan göra det möjligt för komponenterna i din lösning att kommunicera säkert med varandra utan några autentiseringsuppgifter. Hanterade identiteter är inte tillgängliga för alla resurser, men det är en bra idé att använda dem där du kan. Där du inte kan kan du använda de metoder som beskrivs här.

Kommentar

Kommandona i den här enheten visas för att illustrera begrepp. Kör inte kommandona än. Du kommer att öva på det du lär dig här snart.

Definiera säkra parametrar

Dekoratören @secure kan tillämpas på sträng- och objektparametrar som kan innehålla hemliga värden. När du definierar en parameter som @securegör Azure inte parametervärdena tillgängliga i distributionsloggarna. Om du skapar distributionen interaktivt med hjälp av Azure CLI eller Azure PowerShell och du behöver ange värdena under distributionen visas inte texten på skärmen i terminalen.

Som en del av migreringen av HR-program måste du distribuera en logisk Azure SQL-server och databas. Du etablerar den logiska servern med en administratörsinloggning och ett lösenord. Eftersom de är känsliga måste du skydda dessa värden. Här är en exempeldeklaration för att skapa två strängparametrar för SQL-serverns administratörsinformation:

@secure()
param sqlServerAdministratorLogin string

@secure()
param sqlServerAdministratorPassword string

Observera att ingen av parametrarna har ett angivet standardvärde. Det är en bra idé att undvika att ange standardvärden för användarnamn, lösenord och andra hemligheter. Annars, om någon distribuerar mallen och inte inser att de bör åsidosätta värdet, försvagas deras säkerhet eftersom de får standardvärdet i stället för något som de själva har valt.

Dricks

Se till att du inte skapar utdata för känsliga data. Utdatavärden kan nås av alla som har åtkomst till distributionshistoriken. De är inte lämpliga för att hantera hemligheter.

Undvik att använda parameterfiler för hemligheter

Som du lärde dig i föregående lektion är parameterfiler ett bra sätt att ange en uppsättning parametervärden. Du skapar ofta parameterfiler för varje miljö som du distribuerar till. I allmänhet bör du undvika att använda parameterfiler för att ange hemliga värden. Parameterfiler sparas ofta i ett centraliserat versionskontrollsystem, till exempel Git. Många människor kan ha tillgång till det i framtiden. Spara inte känsliga data i versionskontrollsystem eftersom de inte är utformade för att lagra den här typen av information.

Integrera med Azure Key Vault

Azure Key Vault är en tjänst som är utformad för att lagra och ge åtkomst till hemligheter. Du kan integrera dina Bicep-mallar med Key Vault med hjälp av en parameterfil med en referens till en Key Vault-hemlighet.

Du kan använda den här funktionen genom att referera till nyckelvalvet och hemligheten i parameterfilen. Värdet exponeras aldrig eftersom du bara refererar till dess identifierare, som i sig inte är något hemligt. När du distribuerar mallen kontaktar Azure Resource Manager nyckelvalvet och hämtar data.

Dricks

Du kan referera till hemligheter i nyckelvalv som finns i en annan resursgrupp eller prenumeration än den du distribuerar till.

Diagram som visar en parameterfil som refererar till Azure Key Vault och skickar hemligheten till Bicep-mallen för att distribuera Azure-resurser.

Här är en parameterfil som använder Key Vault-referenser för att söka efter inloggningen och lösenordet för SQL-logisk serveradministratör som ska användas:

{
  "$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"
      }
    }
  }
}

Observera att i stället för att ange en för var och en value av parametrarna har den här filen ett reference objekt som innehåller information om nyckelvalvet och hemligheten.

Viktigt!

Nyckelvalvet måste konfigureras så att Resource Manager kan komma åt data i nyckelvalvet under malldistributioner. Dessutom måste användaren som distribuerar mallen ha behörighet att komma åt nyckelvalvet. Du får lära dig hur du utför dessa uppgifter i nästa lektion.

Använda Key Vault med moduler

Med moduler kan du skapa återanvändbara Bicep-filer som kapslar in en uppsättning resurser. Det är vanligt att använda moduler för att distribuera delar av din lösning. Moduler kan ha parametrar som accepterar hemliga värden, och du kan använda Biceps Key Vault-integrering för att tillhandahålla dessa värden på ett säkert sätt. Här är ett exempel på en Bicep-fil som distribuerar en modul och ger värdet för den ApiKey hemliga parametern genom att ta den direkt från 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')
  }
}

Observera att i den här Bicep-filen refereras Key Vault-resursen med hjälp av nyckelordet existing . Nyckelordet talar om för Bicep att Key Vault redan finns och att den här koden är en referens till valvet. Bicep distribuerar inte om det. Observera också att modulens kod använder getSecret() funktionen i värdet för modulens apiKey parameter. Det här är en speciell Bicep-funktion som bara kan användas med säkra modulparametrar. Internt översätter Bicep det här uttrycket till samma typ av Key Vault-referens som du lärde dig om tidigare.