Sichern Ihrer Parameter

Manchmal müssen Sie vertrauliche Werte an Ihre Bereitstellungen übergeben, z. B. Kennwörter und API-Schlüssel. Sie müssen aber sicherstellen, dass diese Werte geschützt sind. In einigen Situationen möchten Sie nicht, dass die Person, die die Bereitstellung erstellt, die Geheimniswerte kennt. In anderen Fällen gibt jemand den Parameterwert ein, wenn er die Bereitstellung erstellt, aber Sie müssen sicherstellen, dass die Geheimniswerte nicht protokolliert werden. In dieser Lerneinheit erfahren Sie mehr über die Möglichkeiten zum Schützen Ihrer Parameter.

Definieren sicherer Parameter

Der Decorator @secure kann auf Zeichenfolgen- und Objektparameter angewendet werden, die Geheimniswerte enthalten können. Wenn Sie einen Parameter als @secure definieren, stellt Azure die Parameterwerte nicht in den Bereitstellungsprotokollen zur Verfügung. Auch wenn Sie die Bereitstellung interaktiv mithilfe der Azure CLI oder Azure PowerShell erstellen und die Werte während der Bereitstellung eingeben müssen, zeigt das Terminal den Text nicht an Ihrem Bildschirm an.

Im Rahmen der Migration der Anwendung der Personalabteilung müssen Sie einen logischen Azure SQL-Server und eine Datenbank bereitstellen. Sie stellen den logischen Server mit einer Administratoranmeldung und einem Kennwort bereit. Da diese Werte vertraulich sind, müssen sie geschützt werden. Im Folgenden finden Sie eine Beispieldeklaration zum Erstellen von zwei Zeichenfolgenparametern für die Administratordetails des SQL-Servers:

@secure()
param sqlServerAdministratorLogin string

@secure()
param sqlServerAdministratorPassword string

Beachten Sie, dass für keinen Parameter ein Standardwert angegeben ist. Es ist eine bewährte Methode, die Angabe von Standardwerten für Benutzernamen, Kennwörter und andere Geheimnisse zu vermeiden. Andernfalls wird, wenn jemand Ihre Vorlage bereitstellt und nicht erkennt, dass er den Wert überschreiben sollte, seine Sicherheit geschwächt, da er den Standardwert anstelle eines selbst ausgewählten Werts erhält.

Verwenden Sie keine Parameterdateien für geheime Informationen

Wie Sie in der vorherigen Einheit gelernt haben, sind Parameterdateien eine hervorragende Möglichkeit, einen Satz von Parameterwerten anzugeben. Sie erstellen häufig Parameterdateien für jede Umgebung, in die Sie deployen. Im Allgemeinen sollten Sie die Verwendung von Parameterdateien vermeiden, um geheime Werte anzugeben. Parameterdateien werden häufig in einem zentralen Versionssteuerungssystem wie Git gespeichert. Viele Personen könnten in Zukunft möglicherweise Zugriff darauf haben. Speichern Sie vertrauliche Daten nicht in Versionskontrollsystemen, da diese nicht für die Speicherung dieser Art von Informationen konzipiert sind.

Integrieren mit Azure Key Vault

Azure Key Vault ist ein Dienst, der auf das Speichern und Bereitstellen des Zugriffs auf Geheimnisse ausgelegt ist. Sie können Ihre Bicep-Vorlagen mit Key Vault integrieren, indem Sie eine Parameterdatei mit einem Verweis auf ein Key Vault-Geheimnis verwenden.

Sie können dieses Feature verwenden, indem Sie auf das Schlüsselarchiv und das Geheimnis in der Parameterdatei verweisen. Der Wert wird nie verfügbar gemacht, da Sie nur auf seinen Bezeichner verweisen, der selbst kein Geheimnis ist. Wenn Sie die Vorlage bereitstellen, kontaktiert Azure Resource Manager den Schlüsseltresor und ruft die Daten ab.

Hier ist eine Parameterdatei, die Key Vault-Verweise verwendet, um die SQL-Anmeldeinformationen für logische Serveradministratoren und das zu verwendende Kennwort nachzuschlagen:

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

Beachten Sie, dass diese Datei nicht für jeden Parameter einen value angibt, sondern über ein reference-Objekt verfügt, das Details zum Schlüsseltresor und zum Geheimnis enthält.

Verwenden von Key Vault mit Modulen

Module ermöglichen es Ihnen, wiederverwendbare Bicep-Dateien zu erstellen, die eine Gruppe von Ressourcen kapseln. Es ist üblich, Module zum Bereitstellen von Teilen Ihrer Lösung zu verwenden. Module können über Parameter verfügen, die Geheimniswerte akzeptieren, und Sie können die Key Vault-Integration von Bicep verwenden, um diese Werte sicher bereitzustellen. Hier sehen Sie eine Bicep-Beispieldatei, die ein Modul bereitstellt und den Wert des Geheimnisparameters ApiKey angibt, indem dieser direkt aus Key Vault entnommen wird:

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName
}

module applicationModule 'application.bicep' = {
  name: 'application-module'
  params: {
    apiKey: keyVault.getSecret('ApiKey')
  }
}

Beachten Sie, dass in dieser Bicep-Datei mithilfe des Schlüsselworts existing auf die Key Vault-Ressource verwiesen wird. Das Schlüsselwort teilt Bicep mit, dass die Key Vault-Ressource bereits vorhanden ist und dass dieser Code nur ein Verweis auf diesen Tresor ist. Bicep stellt ihn nicht erneut bereit. Beachten Sie außerdem, dass der Code des Moduls die getSecret()-Funktion im Wert des apiKey-Parameters des Moduls verwendet. Dies ist eine spezielle Bicep-Funktion, die nur mit sicheren Modulparametern verwendet werden kann. Intern übersetzt Bicep diesen Ausdruck in dieselbe Art von Key Vault-Verweis, die Sie zuvor kennengelernt haben.