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

[アーティクル]
11/23/2024

適用対象: Azure Local バージョン 23H2

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

重要

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

概要

以前は AD レスデプロイと呼ばれ、Key Vault でローカル ID を使用する方法により、Azure Local では、AD に依存することなく、BitLocker キー、ノードパスワード、その他の機密情報などのシークレットを安全に管理および格納できます。 Key Vault と統合し、証明書ベースの認証を使用することで、セキュリティ体制を強化し、運用の継続性を確保できます。

メリット

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 を実行する他のシステムへの依存関係を減らすことで、デプロイの効率が向上します。さらに、このアプローチにより、運用テクノロジネットワークのファイアウォール構成が簡素化され、これらの環境の管理とセキュリティ保護が容易になります。

前提条件

開始する前に、次の点を確認してください。

制限付きパブリックプレビューに参加するにはAzure Key Vault Preview のサインアップフォームで Local Identity に署名します。プレビューへの参加中に個人データを収集、使用、保護する方法の詳細については、microsoft のプライバシーに関する声明参照してください。
前提条件と完全なデプロイチェックリストを満たす。 AD 固有の前提条件をスキップします。
組み込みの管理者アカウントを使用する代わりに、すべてのノードで同じ資格情報を持つローカルユーザーアカウントを作成し、ローカル管理者グループに追加します。
適切に構成されたゾーンを持つ DNS サーバーを作成します。このセットアップは、ネットワークが正しく機能するために重要です。 Azure Local の DNS サーバーの構成に関するページを参照してください。
Azure ローカルソフトウェアをダウンロードします。 Azure ローカルソフトウェアをダウンロードする方法の手順は、プレビューにサインアップしたユーザーに提供されます。

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や掘り下げなどのツールを使用して DNS 解決を確認できます。

各ノードにレジストリキーを設定します。

各ノードのゾーン名/FQDN を使用してレジストリキーを設定します。次のコマンドを実行します。

$zoneName = "replace.with.your.zone.name.here" 
$RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Parameters' 
Set-ItemProperty -Path $RegistryPath -Name 'Domain' -Value $zoneName

次のコマンドを使用して、ローカルコンピューターとリモートコンピューターでオペレーティングシステムを再起動します。
```
Restart-Computer
```

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

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

一般的なデプロイ手順は、「 Azure portal を使用して Azure Local バージョン 23H2 システムをデプロイするで説明されているものと同じです。ただし、Key Vault でローカル ID を使用する場合は、 Networking と Management タブで特定の手順を実行する必要があります。

[ネットワーク] タブ

構成 DNS for Azure Local セクションで構成されている DNS サーバーの詳細を指定します。

[管理] タブ

Azure Key Vault を使用したローカル ID オプションを選択します。
新しい Key Vault を作成するには、 新しい Key Vault を作成するを選択します。右側のコンテキストウィンドウに必要な詳細を入力し、 Create を選択します。
Key コンテナー名に、新しい 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 = DNS (AD'less) only.

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

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

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

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

Azure Local で Key Vault を更新する

新しい Key Vault を使用するようにバックアップ構成を更新するには、新しい Key Vault 情報を使用してシステムにパッチを適用する必要があります。

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

まず、Azure portal で新しい Key Vault を作成します。バックアップシークレットを格納するように構成されていることを確認します。
新しい Key Vault の適切なアクセス制御を設定します。これには、ノード ID に必要なアクセス許可の付与が含まれます。 Key Vault に Key Vaults Secret Officer ロールが割り当てられていることを確認します。手順については、「Azure のロールベースのアクセス制御を使用して Key Vault のキー、証明書、シークレットへのアクセス権を付与する」を参照してください。

システム構成を更新します。

POST 要求を使用して、新しい Key Vault の詳細でクラスター構成を更新します。これには、次の API エンドポイントへの要求の送信が含まれます。

API Spec:
API Version: 2024-07-01-preview
API Path: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.AzureStackHCI/clusters/{clusterName}/updateSecretsLocations
Payload:
{
"properties": {
    "secretsType": "BackupSecrets",
    "secretsLocation": "https://hcikeyvaulttestingnew.vault.azure.net/"
}
}

構成を検証します。 Azure portal でシステムリソースを開き、 Resource JSON に更新された Key Vault の詳細が含まれていることを確認します。

Key Vault を更新できる Resource 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 では、拡張機能の状態は Failed 必要なアクセス許可が失われたためにシークレットをバックアップできないことを示します。

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

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

次のステップ

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

次の方法で共有