Azure Key Vault を別のリージョンに再配置する
既存の Azure リソースを 1 つのリージョンから他のリージョンに移動する必要が生じる理由は多数存在します。 以下を行うことができます。
- 新しい Azure リージョンの利点を活用する。
- 特定のリージョンでしか利用できない機能やサービスをデプロイする。
- 内部ポリシーやガバナンスの要件を満たす。
- 会社の合併と買収に合わせた調整を行う
- 容量計画の要件を満たす。
Azure Key Vault では、別のリージョンへキー コンテナーを再配置することはできません。
再配置の代わりに、次の手順を実行する必要があります。
- 関連付けられている Azure サービスの再配置を使用して、新しいキー コンテナーを作成します。
- 必要なキー、シークレット、または証明書を再生成します。 場合によっては、既存のキー コンテナーから再配置されたキー コンテナーへのシークレットまたは証明書の転送が必要になることがあります。
前提条件
Azure サブスクリプションを使用してターゲット リージョンにキー コンテナーを作成できることを確認します。
Key Vault で使用されるすべての Azure サービスを含む依存関係マップを作成します。 再配置の対象となるサービスについては、適切な再配置戦略を選択する必要があります。
Key Vault の設計によっては、ターゲット リージョンに Virtual Network をデプロイして構成することが必要になることがあります。
ターゲット リージョンの Key Vault の再構成について文書化して計画します。
- アクセス ポリシーとネットワーク構成の設定。
- 論理的な削除と消去の保護。
- 自動ローテーションの設定。
ダウンタイム
起こり得るダウンタイムを理解するには、Azure 向けのクラウド導入フレームワークの再配置方法の選択に関する記事を参照してください。
サービス エンドポイントに関する考慮事項
Azure Key Vault の仮想ネットワーク サービス エンドポイントは、指定した仮想ネットワークへのアクセスを制限します。 エンドポイントは、IPv4 (インターネット プロトコル バージョン 4) アドレス範囲のリストへのアクセスを制限することもできます。 ユーザーがこのようなソース以外から Key Vault に接続しようとすると、アクセスを拒否されます。 Key Vault リソースのソース リージョンでサービス エンドポイントが構成されている場合は、ターゲット リージョンでも同じ手順を実行する必要があります。
ターゲット リージョンで Key Vault を正常に再作成するには、VNet とサブネットを事前に作成する必要があります。 これら 2 つのリソースの移動が Azure Resource Mover ツールで実行される場合、サービス エンドポイントは自動的に構成されません。 そのため、手動で構成する必要があります。これは、Azure portal、Azure CLI、または Azure PowerShell 経由で行うことができます。
プライベート エンドポイントに関する考慮事項
Azure Private Link を使用すると、仮想ネットワークから Azure のサービスとしてのプラットフォーム (PaaS)、お客様が所有するサービス、または Microsoft パートナーのサービスへのプライベート接続が可能になります。 Private Link がネットワーク アーキテクチャを簡素化し、パブリック インターネットへのデータの公開をなくすことで Azure のエンドポイント間の接続をセキュリティで保護します。
ターゲット リージョンで Key Vault を正常に再作成するには、実際に再作成が発生する前に VNet とサブネットを作成する必要があります。
Azure プライベート エンドポイントの DNS 統合に関する考慮事項
プライベート エンドポイントの IP アドレスを接続文字列の完全修飾ドメイン名 (FQDN) に解決するように、DNS 設定を正しく構成する必要があります。
既存の Microsoft Azure サービスには、パブリック エンドポイント用の DNS 構成が既に存在している場合があります。 プライベート エンドポイントを使用して接続するには、この構成をオーバーライドする必要があります。
プライベート エンドポイントに関連付けられているネットワーク インターフェイスには、DNS を構成するための情報が含まれています。 ネットワーク インターフェイスの情報には、プライベート リンク リソースの FQDN とプライベート IP アドレスが含まれています。
次のオプションを使用して、プライベート エンドポイントの DNS 設定を構成できます。
- ホスト ファイルを使用する (テストにのみ推奨)。 仮想マシン上のホスト ファイルを使用して、DNS をオーバーライドすることができます。
- プライベート DNS ゾーンを使用する。 プライベート DNS ゾーンを使用して、プライベート エンドポイントの DNS 解決をオーバーライドすることができます。 プライベート DNS ゾーンを自分の仮想ネットワークにリンクして、特定のドメインを解決することができます。
- DNS フォワーダーを使用する (オプション)。 DNS フォワーダーを使用して、プライベート リンク リソースの DNS 解決をオーバーライドすることができます。 仮想ネットワークでホストされている DNS サーバーでプライベート DNS ゾーンを使用する DNS 転送規則を作成します。
準備
Azure portal を使用してテンプレートをエクスポートするには:
Azure portal にサインインします。
[すべてのリソース] を選択してから、キー コンテナーを選択します。
>[Automation]>[テンプレートのエクスポート] を選択します。
[テンプレートのエクスポート] ブレードで [ダウンロード] を選択します。
ポータルからダウンロードした .zip ファイルを見つけて、選択したフォルダーにそのファイルを解凍します。
この zip ファイルには、テンプレートとテンプレートをデプロイするためのスクリプトから構成される .json ファイルが含まれています。
次の概念に注意してください。
- キー コンテナーの名前はグローバルに一意です。 コンテナー名を再利用することはできません。
- 新しいキー コンテナー内に、アクセス ポリシーとネットワーク構成設定を再構成する必要があります。
- 新しいキー コンテナー内に、論理的な削除と消去保護を再構成する必要があります。
- バックアップと復元の操作では、自動ローテーション設定は保持されません。 場合によっては、設定を再構成する必要があります。
テンプレートの変更
キー コンテナー名とリージョンを変更して、テンプレートを変更します。
Azure portal を使用してテンプレートをデプロイするには:
Azure Portal で、 [リソースの作成] を選択します。
[Marketplace を検索] で「template deployment」と入力し、Enter キーを押します。
[テンプレートのデプロイ] を選択します。
［作成］ を選択します
[Build your own template in the editor] (エディターで独自のテンプレートをビルド) を選択します。
[ファイルの読み込み] を選択し、手順に従って、前のセクションでダウンロードした template.json ファイルを読み込みます。
template.json ファイルで、キー コンテナー名の既定値を設定して、キー コンテナーに名前を付けます。 この例では、キー コンテナー名の既定値を
mytargetaccountに設定します。"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "vaults_name": { "defaultValue": "key-vault-name", "type": "String" } },template.json ファイル内の location プロパティを編集して、ターゲット リージョンを指定します。 この例では、ターゲット リージョンを
centralusに設定します。"resources": [ { "type": "Microsoft.KeyVault/vaults", "apiVersion": "2023-07-01", "name": "[parameters('vaults_name')]", "location": "centralus", ... }, ... ]リージョンの場所コードを取得するには、「Azure の場所」を参照してください。 リージョンのコードは、スペースを含まないリージョン名です (Central US = centralus)。
テンプレート内の typ プライベート エンドポイントのリソースを削除します。
{ "type": "Microsoft.KeyVault/vaults/privateEndpointConnections", ... }キー コンテナーでサービス エンドポイントを構成した場合は、networkAcl セクションの virtualNetworkRules でターゲット サブネットの規則を追加します。 ignoreMissingVnetServiceEndpoint フラグが False に設定されていることを確認します。これにより、サービス エンドポイントがターゲット リージョンで構成されない場合、IaC が Key Vault のデプロイに失敗します。
parameter.json
{ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "target_vnet_externalid": { "value": "virtualnetwork-externalid" }, "target_subnet_name": { "value": "subnet-name" } } }_template.json
"networkAcls": { "bypass": "AzureServices", "defaultAction": "Deny", "ipRules": [], "virtualNetworkRules": [ { "id": "[concat(parameters('target_vnet_externalid'), concat('/subnets/', parameters('target_subnet_name')]", "ignoreMissingVnetServiceEndpoint": false } ] }
Redeploy
テンプレートをデプロイして、ターゲット リージョンに新しいキー コンテナーを作成します。
template.json ファイルを保存します。
プロパティ値を入力または選択します。
サブスクリプション:Azure サブスクリプションを選択します。
[リソース グループ] : [新規作成] を選択して、リソース グループに名前を付けます。
[場所] :Azure の場所を選択します。
[上記の使用条件に同意する] を選択し、[購入を選択] を選択します。
新しいキー コンテナー内に、アクセス ポリシーとネットワーク構成設定 (プライベート エンドポイント) を再構成する必要があります。 新しいキー コンテナーと "自動ローテーション設定" で論理的な削除と消去の保護を再構成する必要があります。
ヒント
指定された XML が構文的に有効ではないことを示すエラーが発生した場合は、テンプレート内の JSON を Azure Resource Manager ドキュメントで説明されているスキーマと比較します。
データ移行による再デプロイ
重要
同じ地域内のリージョン間で Key Vault を移動する場合は、シークレット、キー、証明書のバックアップと復元を行うことをお勧めします。
- 再デプロイのアプローチに関するセクションで説明されている手順に従います。
- シークレットの場合:
- シークレット値をコピーしてソースのキー コンテナーに保存します。
- ターゲットのキー コンテナーでシークレットを再作成し、保存されたシークレットにその値を設定します。
- 証明書の場合:
- 証明書を PFX ファイルにエクスポートします。
- PFX ファイルをターゲットのキー コンテナーにインポートします。 秘密キーをエクスポートできない (
exportableが設定されていない) 場合は、新しい証明書を生成し、それをターゲットのキー コンテナーにインポートする必要があります。
- 関連付けられている Azure サービスの再配置により、キーが再生成されます。
- 関連付けられたサービスに対してキーが生成されたことを確認します。
確認
古いキー コンテナーを削除する前に、関連付けられた Azure サービスの再配置の前に必要なすべてのキー、シークレット、証明書が新しいコンテナーに含まれていることを確認します。