Azure Key Vault でローカル ID を使用して Azure Local をデプロイする (プレビュー)

この記事では、Azure ローカルデプロイに Azure Key Vault でローカル ID を使用する方法について説明します。

重要

現在、この機能はプレビュー段階にあります。ベータ版、プレビュー版、またはその他の一般提供にまだリリースされていない Azure 機能に適用される法的条件については、 Microsoft Azure プレビューの追加使用条件を参照してください。

概要

Active Directory (AD) ベースのデプロイに加えて、Azure Local では、以前は AD レスデプロイと呼ばれる Azure Key Vault を使用したローカル ID によるデプロイがサポートされています。

ローカル管理者アカウントを使用するローカル ID では、デプロイプロセスによって、クラスターレベルの証明書ベースの認証との統合が構成されます。このセットアップにより、デプロイ中および進行中の操作中に安全な通信が保証されます。

この構成の一環として、Azure Cloud の Azure Key Vault がデプロイ中にプロビジョニングされ、BitLocker キーやその他の重要な構成データを含む Azure ローカルシークレットのセキュリティで保護されたバックアップとして機能します。

メリット

Azure Local で Key Vault でローカル ID を使用すると、特に AD に依存しない環境に対して、いくつかの利点があります。主な利点を次に示します。

最小限のエッジインフラストラクチャ。 AD を使用しない環境の場合、Key Vault を使用したローカル ID は、ユーザー ID とシークレットを安全かつ効率的に管理する方法を提供します。
シークレットストア。 Key Vault は、BitLocker キー、ノードパスワード、その他の機密情報などのシークレットを安全に管理および格納します。これにより、不正アクセスのリスクが軽減され、全体的なセキュリティ体制が強化されます。
簡素化された管理を維持します。 Key Vault と統合することで、組織はシークレットと資格情報の管理を効率化できます。これには、デプロイシークレットとローカル ID シークレットを 1 つのコンテナーに格納することが含まれるため、これらのシークレットの管理とアクセスが容易になります。
デプロイが簡略化されました。 Azure portal を使用したシステムのデプロイ中に、Key Vault と統合されたローカル ID プロバイダーを選択するオプションがあります。このオプションを選択すると、必要なすべてのシークレットが Key Vault 内に安全に格納されるため、デプロイプロセスが効率化されます。既存の AD システムや、継続的なメンテナンスが必要な AD を実行する他のシステムへの依存関係を減らすことで、デプロイの効率が向上します。さらに、このアプローチにより、運用テクノロジネットワークのファイアウォール構成が簡素化され、これらの環境の管理とセキュリティ保護が容易になります。

前提条件

前提条件を満たし、デプロイチェックリストを完了します。 AD 固有の前提条件をスキップします。
組み込みの管理者アカウントを使用する代わりに、すべてのノードで同じ資格情報を持つローカルユーザーアカウントを作成し、ローカル管理者グループに追加します。
クラスター内のすべてのノードで同じ資格情報を持つローカル管理者アカウントを作成します。この要件により、ノードの追加操作と修復操作が、すべてのノードで正常に認証および実行できるようになります。手順については、「ノードの追加」および「ノードの修復」を参照してください。
Azure ローカルソフトウェアをダウンロードします。 Azure ローカルデプロイのオペレーティングシステムのダウンロードに関するページを参照してください。
ノードには静的 IP アドレスが必要であり、DHCP はサポートされていません。 OS がインストールされたら、SConfig を使用して静的 IP アドレス、サブネット、ゲートウェイ、DNS を設定します。
適切に構成されたゾーンを持つ DNS サーバーを作成します。このセットアップは、ネットワークが正しく機能するために重要です。「Azure Local の DNS サーバーを構成する」を参照してください。

Azure Local の DNS サーバーを構成する

Azure Local の DNS を構成するには、次の手順に従います。

DNS サーバーを作成して構成します。

DNS サーバーがまだない場合は、設定します。これは、Windows Server DNS または別の DNS ソリューションを使用して行うことができます。
DNS ホスト A レコードを作成します。

Azure ローカルインスタンス内の各ノードに対して、DNS ホスト A レコードを作成します。このレコードは、ノードのホスト名をその IP アドレスにマップし、ネットワーク上の他のデバイスがノードを見つけて通信できるようにします。

さらに、システム自体の DNS ホスト A レコードを作成します。このレコードでは、システムに割り当てたネットワーク範囲の最初の IP アドレスを使用する必要があります。
DNS レコードを確認します。

特定のマシンの DNS レコードが正しく設定されていることを確認するには、次のコマンドを実行します。
```
nslookup "machine name"
```
DNS 転送を設定します。

必要に応じて、DNS クエリを Azure DNS または別の外部 DNS プロバイダーに転送するように DNS サーバーで DNS 転送を構成します。
ネットワーク設定を更新します。

構成した DNS サーバーを使用するように、Azure ローカルノードのネットワーク設定を更新します。これは、ネットワークアダプターの設定または PowerShell コマンドを使用して行うことができます。
DNS 構成を確認します。

DNS の構成をテストして、DNS クエリが正しく解決されていることを確認します。 nslookupやdigなどのツールを使用してDNS解決を確認できます。
次のコマンドを使用して、ローカルコンピューターとリモートコンピューターでオペレーティングシステムを再起動します。
```
Restart-Computer
```

Key Vault でローカル ID を使用してポータル経由で Azure Local をデプロイする

Azure portal を使用したデプロイ時に、Key Vault と統合されたローカル ID プロバイダーを選択するオプションがあります。これにより、認証に AD に依存するのではなく、Key Vault でローカル ID を使用してシークレットを安全に管理および格納できます。

一般的なデプロイ手順は、「 Azure portal を使用した Azure ローカルシステムのデプロイ」で説明されているものと同じです。ただし、Key Vault でローカル ID を使用する場合は、[ネットワーク] タブと [管理] タブで特定の手順を実行する必要があります。

[ネットワーク] タブ

有効な ゾーン名 (ドメイン) を指定して、クラスターの権限のあるプライベート DNS 名前空間を確立します。このドメインは、クラスターの可視性の要件に応じて、内部的 (内部専用のホストとワークロードの場合) または外部 (パブリックに使用可能なホストとワークロードの場合) で解決できる必要があります。
「Azure ローカルの DNS の構成」セクションで構成された DNS サーバーの詳細を指定します。

[管理] タブ

[Azure Key Vault を使用したローカル ID] オプションを選択します。
新しい Key Vault を作成するには、[ 新しいキーコンテナーの作成] を選択します。右側のコンテキストウィンドウに必要な詳細を入力し、[ 作成] を選択します。
[ キーコンテナー名] に、新しいキーコンテナー名を入力します。クラスターごとに 1 つの Key Vault を作成する必要があります。

デプロイ後の手順

システムをデプロイした後、デプロイが AD レスであることを確認し、シークレットが Key Vault にバックアップされていることを確認します。

Active Directory なしでシステムが展開されたことを確認する

システムをデプロイした後、デプロイが AD なし (AD レス) であることを確認します。

次のコマンドを実行して、ノードが AD ドメインに参加していないことを確認します。出力に WORKGROUPが表示された場合、ノードはドメインに参加していません。
```
Get-WmiObject Win32_ComputerSystem.Domain
```
出力例を次に示します。
```
[host]: PS C:\Users\LocalAdmin\Documents> (Get-WmiObject Win32_ComputerSystem).Domain 
WORKGROUP
```

クラスターが、AD なしで機能するワークグループクラスターであることを確認します。次のコマンドを実行し、 ADAware パラメーターの値を確認します。

Get-ClusterResource "Cluster Name" | Get-ClusterParameter ADAware 

Object       Name    Value Type 

------       ----    ----- ---- 

ClusterName  ADAware  2    UInt32 

For ADAware property, 0 = None, 1 = AD, 2 = Local Identity

シークレットが Key Vault にバックアップされていることを確認する

BitLocker キーと回復管理者パスワードは、Azure に安全にバックアップされ、最大限のセキュリティを確保するためにローテーションされます。

AD を使用できないシナリオでは、専用の回復管理者ユーザーを使用してシステムを復元できます。この目的で指定されたユーザー名は RecoveryAdmin。対応するパスワードを Azure Key Vault から安全に取得できるため、システム回復操作を効果的に実行するために必要な資格情報が確保されます。

これにより、すべての重要な情報が安全に保存され、必要に応じて簡単に取得できるため、インフラストラクチャのセキュリティと信頼性が強化されます。

Azure Local での Key Vault 拡張機能のアラート

Azure Local では、Key Vault 拡張機能を使用して、シークレットを安全に格納および管理します。信頼性とセキュリティを確保するために、システムは Key Vault 統合の正常性を継続的に監視します。問題が検出されると、アラートが自動的に生成され、Azure Monitor を通じて表示され、可視性と応答が得られます。

アラートは Azure Alerts ゲートウェイを介して送信され、Azure portal の [Monitor>Alerts] で表示できます。電子メール、SMS、または Webhook 経由で通知を受信するようにアクショングループを構成できます。詳細については、「Azure Monitor アラートとは」を参照してください。

次の表では、使用可能なアラート、その影響、および解決するための推奨されるアクションについて説明します。

Alerts	Description	インパクト	推奨されるアクション
キーボールトが存在しません(KeyVaultDoesNotExist)	指定された Key Vault が存在しません。	シークレットを安全にバックアップして格納するには、Key Vault が必要です。これを指定しないと、シークレットバックアップ操作は失敗します。	- Key Vault リソースが Azure サブスクリプションに存在することを確認します。 - Key Vault の名前とリソースグループがデプロイの構成と一致していることを確認します。 - Key Vault が削除された場合は、再作成して構成を更新します。
KeyVaultAccess	1 つ以上のクラスターノードが Key Vault にアクセスできませんでした。	ノードが Key Vault にアクセスできない場合、シークレットの取得またはバックアップを必要とする操作が失敗する可能性があります。	- クラスターノードと Key Vault エンドポイントの間のネットワーク接続を確認します。 - Key Vault のファイアウォールとアクセスポリシーによってクラスターノードの接続が許可されていることを確認します。 - クラスターで使用されるマネージド ID またはサービスプリンシパルに必要なアクセス許可 ( Get、 List、 Backup など) があることを確認します。さらに、ノードに関連付けられているマネージド ID (Arc for Server リソース) には、 Key Vault の Key Vault シークレットオフィサーロールを割り当てる必要があります。

Azure Local で Key Vault を更新する

新しい Key Vault を使用するようにバックアップ構成を更新するには、次の手順に従います。

Azure portal で新しい Key Vault を作成します。バックアップシークレットを格納するように構成します。
新しい Key Vault のアクセス制御を設定します。これには、ノード ID に必要なアクセス許可の付与が含まれます。 Key Vault に Key Vault シークレットオフィサー ロールが割り当てられていることを確認します。手順については、「 Azure ロールベースのアクセス制御を使用して Key Vault のキー、証明書、シークレットへのアクセスを提供する」を参照してください。
システム構成を更新します。 POST 要求を使用して、新しい Key Vault の詳細でクラスター構成を更新します。 POST API を実行するには、 Azure Stack HCI 管理者 ロールが割り当てられている必要があります。詳細については、「ロールベースのアクセス制御を使用して、Azure Arc で有効になっている Azure ローカル VM を管理する」を参照してください。
1. 次のコマンドを実行して、Azure サブスクリプションにサインインします。
```
Connect-AzAccount
```
2. 次のコマンドを実行して、サブスクリプションコンテキストを確認します。
```
Get-AzContext
```
3. 認証が完了したら、 Invoke-AzRestMethod コマンドレットを使用して POST 要求を送信します。これにより、新しい Key Vault の場所でクラスターが更新されます。
出力例を次に示します。
```
Invoke-AzRestMethod -Path "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.AzureStackHCI/clusters/<clusterName>/updateSecretsLocations" -Method POST -Payload
{ 
"properties": {
    "secretsType": "BackupSecrets",
    "secretsLocation": "https://hcikeyvaulttestingnew.vault.azure.net/"
              }
} # Response: 200 OK
```
構成を検証します。 Azure portal でシステムリソースを開き、 Resource JSON に更新された Key Vault の詳細が含まれていることを確認します。

Key Vault を更新できる リソース JSON のサンプルスクリーンショットを次に示します。
新しい Key Vault でシークレットを確認します。すべてのバックアップシークレットが新しい Key Vault に正しく格納されていることを確認します。
古い Key Vault をクリーンアップします。古い Key Vault とそのシークレットは自動的に削除されません。新しい Key Vault が正しく構成されていることを確認したら、必要に応じて古い Key Vault を削除できます。

削除された Key Vault を回復してバックアップを再開する

Key Vault を削除してから復旧すると、以前に Key Vault にアクセスしていたマネージド ID は、次の方法で影響を受けます。

マネージド ID アクセスの失効。削除プロセス中に、マネージド ID の Key Vault へのアクセス許可が取り消されます。これは、ID が Key Vault にアクセスするための承認を持たなくなった場合を意味します。
拡張機能操作の失敗。シークレットバックアップの管理を担当するバックアップキーコンテナー拡張機能は、アクセスのためにマネージド ID に依存します。アクセス許可が取り消されると、拡張機能はバックアップ操作を実行できません。
Azure portal の拡張機能の状態。 Azure portal では、拡張機能の状態が [失敗 ] と表示されます。これは、必要なアクセス許可が失われたために拡張機能がシークレットをバックアップできないことを示しています。

拡張機能の失敗の問題に対処して解決し、通常のバックアップ操作を復元するには、次の手順を実行します。

マネージド ID アクセスを再割り当てします。
1. Key Vault へのアクセスを必要とするマネージド ID を決定します。
2. Key Vault シークレットオフィサーロールをマネージド ID に再割り当てします。
拡張機能の機能を確認します。
1. 再割り当て後、Azure portal で拡張機能の状態を監視して、失敗から成功に変わるようにします。これは、拡張機能が必要なアクセス許可を回復し、正常に機能していることを示します。
2. バックアップ操作をテストして、シークレットが正しくバックアップされていること、およびバックアッププロセスが期待どおりに機能していることを確認します。

Azure Key Vault で構成された Azure ローカル環境でのツールの互換性

ID 管理のために Azure Key Vault を使用して構成された Azure ローカル環境でのツールのサポートは、エコシステムによって異なります。これらの構成で効果的に計画および運用するには、次のガイダンスを使用します。

サポートされているツール

PowerShell。 AD と Azure Key Vault ベースの ID 環境の両方で完全にサポートされています。 PowerShell は、ID 構成全体で Azure ローカルクラスターを管理および自動化するための主要なインターフェイスです。
Azure Monitor。 ホストと仮想マシンの正常性とパフォーマンスを監視するためにサポートされます。 Azure Monitor との統合により、システムの正常性、アラート、テレメトリを可視化できます。
Azure portal。 Azure ローカルクラスターの管理でサポートされます。

サポートされていないサポートツールまたは制限付きサポートツール

Windows Admin Center。 Azure Key Vault ベースの ID 環境ではサポートされていません。管理タスクには、PowerShell またはその他のサポートされているツールを使用する必要があります。
System Center Virtual Machine Manager (SCVMM)。 Azure Key Vault ベースの ID 環境では、サポートが制限されているか、サポートされていないことが予想されます。 SCVMM に依存する前に、特定のユースケースを検証します。

混在する互換性

Microsoft 管理コンソール (MMC)。 互換性は異なります。 Hyper-V Manager やフェールオーバークラスターマネージャーなどのツールは、すべてのシナリオで機能するとは限りません。運用環境で MMC を使用する前に、重要なワークフローをテストします。

FAQ

このセクションでは、Key Vault でのローカル ID の使用に関してよく寄せられる質問に対する回答を示します。

デプロイ中に Azure Key Vault Backup シークレット拡張機能がインストールされなかった場合の対応

デプロイ中に拡張機能がインストールされていない場合は、次の手順に従って、Arc 対応サーバーに拡張機能を手動でインストールできます。

Azure Key Vault がまだない場合は、新しい Azure Key Vault を作成します。手順については、「クイックスタート: Azure portal を使用してキーコンテナーを作成する」を参照してください。
Key Vault ページで、アクセス制御 (IAM)>ロールの割り当ての追加に移動します。
1. [ ロール ] タブで、[ Key Vault Secrets Officer] を選択します。
2. [ メンバー ] タブで、[ マネージド ID] を 選択し、Azure ローカルクラスターをメンバーとして追加します。
3. [確認と割り当て] を選択して、ロールの割り当てを完了します。
ロールの割り当てが [ ロールの割り当て ] タブに表示されることを確認します。
Azure ローカルクラスターに移動し、Arc マシン名をメモします。

次の PowerShell スクリプトを実行して、拡張機能を Arc マシンにインストールします。

# Login to Azure
Connect-AzAccount
$ResourceGroup = "<Resource Group>"
$ResourceLocation = "<Location>"
$KeyVaultUri = "<URL of Azure Key Vault>"
$ArcMachines = @("v-host1", "v-host2", "v-host3", "v-host4")
foreach ($MachineName in $ArcMachines) {
New-AzConnectedMachineExtension `
-Name AzureEdgeAKVBackupForWindows `
-ResourceGroupName $ResourceGroup `
-Location $ResourceLocation `
-MachineName $MachineName `
-Publisher Microsoft.Edge.Backup `
-ExtensionType AKVBackupForWindows `
-Setting @{KeyVaultUrl = $KeyVaultUri; UseClusterIdentity = $true}
}

Azure portal で拡張機能の状態を確認し、正常にインストールされたことを確認します。

次のステップ

デプロイ中にワークロードボリュームを作成しなかった場合は、各ボリュームのワークロードボリュームとストレージパスを作成します。詳細については、「 Azure Local および Windows Server クラスターでのボリュームの作成」および「 Azure Local のストレージパスの作成」を参照してください。
Azure ローカルデプロイの問題のサポートを受ける

この機能は、Azure Local 2411 以降でのみ使用できます。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-28