パラメーターをセキュリティで保護する

  • 4 分

パスワードや API キーなど、機密性の高い値をデプロイに渡す必要がある場合があります。 ただし、これらの値が保護されていることを確認する必要があります。 状況によっては、デプロイを作成しているユーザーにシークレット値を知られたくない場合もあります。 また、デプロイを作成するときにパラメーター値を入力する場合もありますが、シークレット値がログに記録されていないことを確認する必要があります。 このユニットでは、パラメーターを保護する方法について説明します。

ヒント

最も良い方法は、資格情報を完全に使用しないようにすることです。 Azure リソースのマネージド ID を使用すると、ソリューションのコンポーネントが、資格情報を使用せず相互に安全に通信できるようになります。 マネージド ID はすべてのリソースで使用できるわけではありませんが、できる限り使用することをお勧めします。 それができない場合は、ここで説明する方法を使うことができます。

注意

このユニットのコマンドは、概念を説明するために示されています。 コマンドはまだ実行しないでください。 ここで学習した内容をすぐに練習します。

セキュリティで保護されたパラメーターの定義

@secure デコレーターは、シークレット値を含む可能性のある文字列およびオブジェクトのパラメーターに適用できます。 パラメーターを @secure として定義すると、Azure で、パラメーター値がデプロイ ログに利用されなくなります。 また、Azure CLI または Azure PowerShell を使用して対話形式でデプロイを作成し、デプロイ中に値を入力する必要がある場合、ターミナルの画面にはテキストが表示されません。

人事部アプリケーションの移行の一環として、Azure SQL の論理サーバーとデータベースをデプロイする必要があります。 管理者のログインとパスワードを使用して論理サーバーをプロビジョニングします。 これらは機密性が高いので、これらの値をセキュリティで保護する必要があります。 SQL サーバーの管理者詳細用に、2 つの文字列パラメーターを作成する宣言の例を次に示します。

@secure()
param sqlServerAdministratorLogin string

@secure()
param sqlServerAdministratorPassword string

どちらのパラメーターにも既定値が指定されていないことに注意してください。 ユーザー名、パスワード、その他のシークレットに既定値を指定しないようにすることをお勧めします。 そうしないと、ユーザーがテンプレートをデプロイし、その値をオーバーライドすべきだと気づかなかった場合、自分で選んだ値ではなく既定値が取得されることになり、セキュリティが低下します。

ヒント

機密データについては出力を作成しないでください。 出力値には、デプロイ履歴にアクセスできる人なら誰でもアクセスできます。 こういったものは、シークレットの処理には適していません。

シークレットにパラメーター ファイルを使用しないようにする

前のユニットで学習したとおり、パラメーター ファイルはパラメーター値のセットを指定するための最適な方法です。 多くの場合、デプロイする環境ごとにパラメーター ファイルを作成します。 一般的に、シークレット値を指定する際、パラメーター ファイルの使用は回避する必要があります。 パラメーター ファイルは Git のような一元化されたバージョン管理システムによく保存されます。 将来的には、多くの人がアクセスする可能性があります。 バージョン管理システムは、この種の情報を格納するように設計されていないため、機密データを格納しないでください。

Azure Key Vault との統合

Azure Key Vault は、シークレットを格納してアクセスできるように設計されたサービスです。 Key Vault のシークレットへの参照を含むパラメーター ファイルを使用して、Bicep テンプレートを Key Vault と統合できます。

パラメーター ファイルでキー コンテナーとシークレットを参照することで、この機能を使用できます。 識別子を参照するだけなので、値が公開されることはなく、それ自体はシークレットではありません。 テンプレートをデプロイすると、Azure Resource Manager からキー コンテナーに接続が行われ、データが取得されます。

ヒント

デプロイ先のとは別の、リソース グループまたはサブスクリプションにあるキー コンテナー内のシークレットを参照することができます。

Diagram that shows a parameter file reference Azure Key Vault and pass secret to Bicep template to deploy Azure resources.

Key Vault 参照により、使用する SQL 論理サーバー管理者のログインとパスワードを参照するパラメーター ファイルを次に示します。

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

各パラメーターに value を指定する代わりに、このファイルには reference オブジェクトがあり、キー コンテナーとシークレットの詳細が含まれていることに注意してください。

重要

テンプレートのデプロイ中に、Resource Manager からキー コンテナー内のデータにアクセスできるようにキー コンテナーを構成する必要があります。 また、テンプレートをデプロイするユーザーには、キー コンテナーにアクセスするためのアクセス許可が必要です。 次のユニットでは、これらのタスクを実行する方法について学習します。

モジュールでの Key Vault の使用

モジュールを使用すると、一連のリソースをカプセル化する再利用可能な Bicep ファイルを作成できます。 モジュールを使用してソリューションの一部をデプロイするのが一般的です。 モジュールにはシークレット値を受け取るパラメーターがあるかもしれませんが、Bicep の Key Vault 統合を使用して、これらの値を安全に指定できます。 モジュールをデプロイし、ApiKey シークレット パラメーターの値を Key Vault から直接取得して指定する Bicep ファイルの例を次に示します。

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

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

この Bicep ファイルの場合、existing キーワードを使用してキー コンテナー リソースを参照していることに注意してください。 このキーワードは Bicep に対して、キー コンテナーは既に存在しており、このコードはそのコンテナーへの参照であることを示しています。 これは Bicep によって再デプロイされません また、モジュールのコードでは、モジュールの apiKey パラメーターの値に getSecret() 関数を使用していることに注目してください。 これは、セキュリティで保護されたモジュール パラメーターでのみ使用できる特殊な Bicep 関数です。 この式は内部的に、Bicep によって、以前に学習したのと同じ種類の Key Vault 参照に変換されます。