Azure Key Vault の使用に関するガイドライン

完了

Azure Key Vault は、暗号化キー、証明書、サーバー側トークンなどのアプリケーション シークレットを格納するための一元化されたクラウド サービスです。 Key Vault はシークレットの管理に役立ちます。アプリケーションのシークレットが中央の 1 か所に保存され、アクセスがセキュリティで保護されます。また、アクセス許可が制御され、アクセスがログに記録されます。

Azure Key Vault で使用される 3 つの主要な概念があります。"コンテナー"、"キー"、"シークレット" です。

コンテナー

Azure Key Vault を使用して、コンテナーと呼ばれるセキュリティで保護された入れ物を複数作成します。 コンテナーでは、アプリケーション シークレットの保管を一元化することで、セキュリティ情報が誤って失われる可能性が低くなります。 組織には複数のキー コンテナーがあります。 各キー コンテナーは、組織内の 1 人または複数の担当者によって管理される、暗号化キーおよび暗号によって保護されたデータ ("シークレット" と呼びます) のコレクションです。 これらのキー コンテナーは、まとめて管理する必要がある組織のキーとシークレットの論理グループを表します。 それらはファイル システム内のフォルダーに似ています。 また、キー コンテナーでは、その中に格納されているすべての情報へのアクセスを制御し、記録します。

Azure PowerShell や Azure CLI などのコマンドライン ツールを使用するか、REST API または Azure portal を使用して、コンテナーの作成と管理を行うことができます。

たとえば、リソース グループに新しいコンテナーを作成する Azure CLI コマンド ラインの例を次に示します。

az keyvault create \
    --resource-group <resource-group> \
    --name <your-unique-vault-name>

Azure PowerShell を使用した同じコマンドを次に示します。

New-AzKeyVault -Name <your-unique-vault-name> -ResourceGroupName <resource-group>

キー

キーは、Azure Key Vault サービスにおいて中心となる要素です。 キー コンテナー内の特定のキーは、特定の用途向けの暗号アセットです。 例として、Microsoft Azure RMS の非対称マスター キー、SQL Server TDE (透過的なデータ暗号化)、CLE (列レベルの暗号化)、暗号化バックアップで使用される非対称キーなどがあります。

キーがキー コンテナーに作成または追加されると、Microsoft からも、ご自身のアプリからも、格納されたキーに直接アクセスすることはできなくなります。 アプリケーションでは、Key Vault サービスで暗号化メソッドを呼び出すことによって、キーを使用する必要があります。 Key Vault サービスにより、要求した操作が、セキュリティが強化された境界内で実行されます。 アプリケーションからキーに直接アクセスすることはできません。

キーは単一インスタンス (キーが 1 つだけ存在する) とすることも、バージョン管理することもできます。 バージョン管理する場合、キーは、プライマリ (アクティブ) キーと、キーがローリング (更新) されたときに作成されるゼロ、1 つ以上のセカンダリ (アーカイブ済み) キーのコレクションを持つオブジェクトです。 Key Vault では非対称キー (RSA 2048) がサポートされています。 これらのキーは、アプリケーションで暗号化またはデジタル署名に使用できます。

Key Vault のキーには、ハードウェアで保護されているものとソフトウェアで保護されているものという 2 種類があります。

ハードウェアで保護されたキー

Key Vault サービスではハードウェア セキュリティ モジュール (HSM) の使用がサポートされており、暗号化処理とキー生成のための、セキュリティが強化された改ざんされにくい環境が提供されます。 Azure には、FIPS 140-2 Level 2 に対して検証済みの専用 HSM があり、Key Vault でのキーの生成または格納に使用されます。 これらの、HSM でサポートされたキーは、常に HSM の境界にロックされます。 キーを使用して暗号化を解除または署名するように Key Vault サービスに対してクエリを実行すると、その操作は HSM 内で実行されます。

独自の HSM からキーをインポートし、HSM 境界を離れることなく Key Vault に転送できます。 このシナリオは、多くの場合、Bring Your Own Key または BYOK と呼ばれています。 独自の HSM で保護されたキーを生成し、それを Azure Key Vault に転送する方法の詳細については、このモジュールのまとめを参照してください。 また、HSM で保護されたアプリを移行する必要がある場合や、高度なセキュリティのコンプライアンス要件を維持する必要がある場合は、Microsoft Azure Dedicated HSM (ハードウェア セキュリティ モジュール) サービスを通してこれらの Azure HSM を直接使用することもできます。

ソフトウェアで保護されるキー

Key Vault では、ソフトウェアベースの RSA および ECC アルゴリズムを使用してキーを生成し、保護することもできます。 一般に、ソフトウェアで保護されたキーでは、FIPS 140-2 Level 2 の保証を除き、ほとんどの機能が HSM で保護されたキーとして提供されます。

  • キーは、この場合も、ご自分が管理するコンテナー内でアプリケーション (および Microsoft) から隔離されています
  • HSM で暗号化されたうえで "保存" されます
  • Key Vault ログを使用して使用状況を監視できます

ソフトウェアで保護されたキーについての主な相違点 (価格以外) は、Azure コンピューティング サービスを使用してソフトウェアで暗号化操作が実行されることです。 HSM で保護されたキーを使用すると、暗号化操作は HSM 内で実行されます。

ヒント

運用環境で使用する場合は、HSM で保護されたキーを使用し、ソフトウェアで保護されたキーは、テストやパイロットのシナリオでのみ使用することをお勧めします。 HSM でサポートされたキーには月単位の追加料金がかかります (その月にキーを使用した場合)。 まとめのページに、Azure Key Vault の価格の詳細へのリンクがあります。

ご自分でキーを作成するときに、キー生成の種類を決定します。 たとえば、Azure PowerShell コマンド Add-AzureKeyVaultKey には、Software または HSM のいずれかに設定できる Destination パラメーターがあります。

$key = Add-AzureKeyVaultKey -VaultName 'contoso' -Name 'MyFirstKey' -Destination 'HSM'

シークレット

シークレットは、Key Vault で作成される小さい (10K 未満の) データ BLOB であり、HSM で生成されたキーによって保護されています。 シークレットは、ほぼすべてのアプリケーションにある機密の設定 (ストレージ アカウントキー、PFX ファイル、SQL 接続文字列、データ暗号化キーなど) を保存するプロセスを簡略化するために存在します。

Key Vault の用途

これら 3 つの要素により、Azure Key Vault を使用すると、次の問題に対処するのに役立ちます。

  • シークレットの管理。 Azure Key Vault を使用すると、トークン、パスワード、証明書、API キー、その他のシークレットを (HSM で) 安全に格納し、それらへのアクセスを厳密に制御できます。
  • キー管理。 Azure Key Vault は、クラウドベースのキー管理ソリューションです。このソリューションにより、データの暗号化に使用する暗号化キーの作成と制御が容易になります。 App Service などの Azure サービスが Azure Key Vault と直接統合されているため、暗号化キーを知らなくてもシークレットの暗号化を解除できます。
  • 証明書管理。 Azure Key Vault は、Azure および内部の接続されているリソースで使用するためのパブリックおよびプライベートの SSL/TLS 証明書を簡単にプロビジョニング、管理、デプロイすることができるサービスでもあります。 また、証明機関と連携して TLS 証明書を要求および更新することもできます。これにより、証明書ライフサイクル管理のための堅牢なソリューションが提供されます。

重要

Key Vault は、サーバー アプリケーションの構成のシークレットを格納するよう設計されています。 アプリのユーザーに属するデータを格納するものではなく、アプリのクライアント側の部分で使用することはできません。 このことは、そのパフォーマンス特性、API、およびコスト モデルに反映されています。

ユーザー データは、Transparent Data Encryption を使用する Azure SQL データベース、Storage Service Encryption を使用するストレージ アカウントなど、別の場所に保存する必要があります。 Key Vault には、そうしたデータ ストアにアクセスするためにアプリケーションで使用されるシークレットを保持できます。

ベスト プラクティス

Azure Key Vault を使用するためのセキュリティのベスト プラクティスを次に示します。

ベスト プラクティス 解決策
特定のスコープでユーザー、グループ、およびアプリケーションにアクセス権を付与する。 RBAC の定義済みロールを使用します。 たとえば、キー コンテナーを管理するためのアクセス権をユーザーに付与するには、定義済みのロールであるキー コンテナーの共同作成者を特定のスコープでそのユーザーに割り当てます。 この場合のスコープは、サブスクリプション、リソース グループ、または特定のキー コンテナーになります。 定義済みのロールがニーズに合わない場合は、独自のロールを定義できます。
ユーザーが所有するアクセス権を制御する。 キー コンテナーへのアクセスは、2 つの独立したインターフェイス (管理プレーンとデータ プレーン) を使って制御します。 管理プレーンとデータ プレーンのアクセス制御は独立して動作します。 RBAC を使用して、ユーザーが所有するアクセス権を制御します。 たとえば、キー コンテナー内のキーを使用するための権限をアプリケーションに付与する場合は、キー コンテナー アクセス ポリシーを使って、データ プレーンのアクセス許可のみを付与する必要があります。 このアプリケーションには、管理プレーンへのアクセス権は必要ありません。 逆に、ユーザーがコンテナーのプロパティやタグを読み取ることができるが、キー、シークレット、証明書にはアクセスできないようにする場合、 RBAC を使用して、管理プレーンへの読み取りアクセス権を付与できます。 データ プレーンへのアクセス権は必要ありません。
キー コンテナーに証明書を格納する。 Azure Resource Manager では、Azure VM がデプロイされるときに、Azure Key Vault に格納されている証明書をその VM に安全にデプロイできます。 キー コンテナー用の適切なアクセス ポリシーを設定することで、誰が証明書にアクセスできるかを制御することもできます。 別のメリットは、すべての証明書を Azure Key Vault の 1 か所で管理できることです。
キー コンテナーまたはキー コンテナー オブジェクトが削除された場合に確実に回復することができる。 不注意によるか悪意によるかを問わず、キー コンテナーまたはキー コンテナー オブジェクトが削除される可能性があります。 Key Vault のソフト削除と消去保護機能を有効にしてください。保存データを暗号化するために使用されるキーに対しては必ず有効にしてください。 これらのキーの削除はデータ損失に相当するため、必要に応じて、削除されたコンテナーとコンテナー オブジェクトを回復できます。 Key Vault の回復操作を定期的に実行します。

注意

ユーザーがキー コンテナーの管理プレーンに対する共同作成者権限 (RBAC) を持っている場合は、キー コンテナー アクセス ポリシーを設定することで、データ プレーンへのアクセス権を自分自身に付与できます。 キー コンテナーに対する共同作成者アクセス権を持つユーザーを厳重に管理して、確実に承認されたユーザーのみがキー コンテナー、キー、シークレット、証明書にアクセスおよび管理することができるようにすることをお勧めします。