Microsoft Azure documentation update: Add Azure Local support to SKR sample は、単なる説明文の追記ではなく、Secure Key Release（SKR）サンプルアプリを Azure Local でネイティブに動かすための実装・ビルド・権限設定の更新です。結論から言うと、Azure Local では VM 側の IMDS やサービスプリンシパルで Azure Key Vault に直接認証する流れではなく、Evidence SDK の release_akv_key を使い、Azure Local クラスターのマネージド ID 経由で Key Vault のキーリリースを行う構成に変わります。対象のPRは2026年5月20日にマージされています。(GitHub)
この更新で特に確認すべきなのは、cvm-securekey-release-app をAzure Local向けにビルドしているか、Key Vault側でクラスターIDに Release 権限を付与しているか、SKRポリシーがAzure Local用の要求に合っているかの3点です。既存のAzure Confidential VM向け手順をそのまま流用すると、ビルドは通ってもキーリリース時に403、構成証明エラー、またはEvidence SDK関連のリンクエラーで止まる可能性があります。
今回の更新は「Azure LocalでSKRサンプルを動かすための変更」
今回のPRでは、Secure Key Releaseサンプルアプリ cvm-securekey-release-app がAzure Local上で動作するように更新されました。PR説明では、新しい release_akv_key 関数を使い、Azure LocalクラスターのマネージドIDでAzure Key Vaultに対する認可を行うとされています。さらに、Evidence SDKの呼び出しが、従来のIMDSによるアクセストークン取得とKey Vaultへのキーリリース要求の両方を置き換える点も明記されています。(GitHub)
ここで重要なのは、「ドキュメント更新」という名前であっても、READMEだけの変更ではないことです。実際にはC++コード、CMake設定、Azure Local向けビルドスクリプトが変更されています。管理者だけでなく、サンプルをCI/CDや検証環境に組み込んでいる開発者も確認対象です。(GitHub)
| 観点 | 従来のAzure CVM向けサンプル | Azure Local向け更新後 |
|---|---|---|
| Key Vault認証 | IMDSまたはサービスプリンシパルでトークン取得 | Evidence SDKがホスト経由で処理 |
| 権限の主体 | VMに割り当てたマネージドIDやSP | Azure LocalクラスターのマネージドID |
| ビルド | 通常のCMakeビルド | -DAZURE_LOCAL=ON が必要 |
| 追加ライブラリ | Guest Attestation中心 | edge-cc-base-attestation-sdk もリンク |
| 確認ポイント | VM ID、SP資格情報、AKVアクセス | クラスターID、Release権限、Azure Local用SKRポリシー |
変更点の核心はKey Vault認証フローの切り替え
従来のSKRサンプルでは、構成証明トークンを取得した後、Key Vaultへリリース要求を送るためにIMDSまたはサービスプリンシパルからアクセストークンを取得していました。Azure Local向けビルドでは、この部分が AZURE_LOCAL 条件付きコンパイルで切り替わります。ソース上では、Azure Localの場合に release_akv_key を呼び出し、Evidence SDKがKey Vault認証とキーリリースを処理する実装になっています。(GitHub)
つまり、Azure Localでの失敗を調査するときに「IMDSからトークンが取れるか」「SPのシークレットが正しいか」だけを見ると、切り分けを誤ります。Azure Local向けにビルドされている場合、重要なのはホスト経由のEvidence SDK呼び出し、Azure LocalクラスターID、Key Vault側のRelease権限です。
管理者がまず確認すべき権限
Azure Key Vaultのキーリリース操作では、対象キーがエクスポート可能である必要があり、操作には keys/release 権限が必要です。Microsoft LearnのKey Vault REST APIでも、release操作には keys/release permission が必要と説明されています。(Microsoft Learn)
Azure RBACモデルを使っているKey Vaultであれば、Key Vault Crypto Service Release User がリリースキー用の組み込みロールです。このロールには Microsoft.KeyVault/vaults/keys/release/action が含まれています。(Microsoft Learn)
実務上は、次のように確認します。
| 確認項目 | 見るべきポイント | よくある失敗 |
|---|---|---|
| Key Vaultのアクセスモデル | Azure RBACか、アクセス ポリシーか | RBAC環境なのにアクセス ポリシーだけを見ている |
| 権限を付与するID | Azure LocalクラスターのマネージドID | Azure Local CVMのIDや古いSPに権限を付けている |
| 権限の種類 | 少なくともキーのRelease権限 | Get/Wrap/Unwrapだけを付けてReleaseを忘れる |
| スコープ | Key Vault全体か対象キー単位 | 別のKey Vaultや別バージョンのキーに付与している |
最小権限を意識するなら、検証段階では対象キー単位でRelease権限を付与し、動作確認後に運用スコープを決めるのが安全です。ただし、組織のKey Vault運用ルールでキー単位のロール割り当てを制限している場合は、セキュリティ管理者と事前に調整してください。
ビルド手順では AZURE_LOCAL フラグが必須
今回の更新では、CMakeに AZURE_LOCAL フラグが追加され、Azure Localモードの有効・無効を切り替えられるようになりました。Azure Localモードでは AZURE_LOCAL のコンパイル定義が追加され、edge-cc-base-attestation-sdk がリンクされます。(GitHub)
READMEにもAzure Local向けのビルド手順が追加されており、Azure LocalではAttestationパッケージをAzure Local対応でソースからビルドし、サンプルアプリは -DAZURE_LOCAL=ON を付けてビルドする流れになっています。(GitHub)
cd cvm-securekey-release-app/
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DAZURE_LOCAL=ON
makeAzure Local向けのトップレベルビルドスクリプト azurelocal/build-azure-local.sh でも、AzureAttestSKR のビルド時に -DAZURE_LOCAL=ON が指定されるよう変更されています。既存の自動化でこのスクリプトを使っている場合は、古いバイナリを再利用していないかも確認してください。(GitHub)
ビルドで詰まりやすいポイント
Azure Local対応で最も起きやすいのは、「ソースは更新したが、成果物は従来ビルドのまま」という状態です。この場合、コマンドの見た目は同じでも、内部ではAzure Local向けの release_akv_key 経路に入らず、IMDSやサービスプリンシパル経由の処理を試みる可能性があります。
確認するポイントは次のとおりです。
| 症状 | 原因の候補 | 対応 |
|---|---|---|
edge-cc-base-attestation-sdk のリンクエラー | Azure Local向けSDKや依存関係が不足 | AttestationパッケージをAzure Local対応でビルドし直す |
| IMDS関連のエラーが出る | Azure Local向けにビルドされていない | -DAZURE_LOCAL=ON でクリーンビルドする |
| Key Vaultで403 | クラスターIDにRelease権限がない | Key Vault RBACまたはアクセス ポリシーを見直す |
| SKRポリシー不一致 | Azure Local用の構成証明クレームを使っていない | Azure Local用サンプルポリシーに合わせて再確認する |
| 古い挙動が残る | 旧バイナリをデプロイしている | output や配布先の実行ファイルを入れ替える |
SKRポリシーはAzure Local用の要求に合わせる
Secure Key Releaseは、Microsoft Azure Attestation（MAA）によって生成された要求に基づいてキーをリリースする仕組みです。Microsoft Learnでは、SKRはKey Vault PremiumとKey Vault Managed HSMでサポートされ、SKRポリシーとMAA要求が密接に統合されていると説明されています。(Microsoft Learn)
今回のREADME更新では、Azure Local向けのSKRサンプルポリシーも示されています。Azure Localでは、たとえば x-ms-policy.edge-compliant-cvm が true であることや、SEV-SNP VMであること、デバッグ可能でないことを条件にする例が含まれています。(GitHub)
{
"version": "1.0.0",
"anyOf": [
{
"authority": "https://sharedweu.weu.attest.azure.net",
"allOf": [
{
"claim": "x-ms-isolation-tee.x-ms-sevsnpvm-is-debuggable",
"equals": "false"
},
{
"claim": "x-ms-isolation-tee.x-ms-attestation-type",
"equals": "sevsnpvm"
},
{
"claim": "x-ms-policy.edge-compliant-cvm",
"equals": "true"
}
]
}
]
}このポリシーはサンプルです。実運用では、アプリケーション、TEE構成、許可したい環境、利用するAttestation endpointに合わせて条件を調整します。ポリシーを緩くしすぎると、想定外の環境からキーをリリースできるリスクがあります。逆に厳しくしすぎると、OS更新やAzure Local更新後にクレームが変わり、正当なワークロードでもキーを取得できなくなることがあります。
Azure Local管理者への影響範囲
今回の更新は、Azureの全利用者に影響するサービス仕様変更ではありません。直接影響を受けるのは、Azure LocalでConfidential ComputingやSecure Key Releaseのサンプルを検証・展開する管理者、開発者、セキュリティ担当者です。
特に影響が大きいのは次のケースです。
| 対象者 | 影響 | 取るべき対応 |
|---|---|---|
| Azure Local管理者 | クラスターIDとKey Vault権限の確認が必要 | クラスターのマネージドIDにRelease権限を付ける |
| セキュリティ管理者 | Key Vaultのデータプレーン権限設計が変わる | RBACロールまたはアクセス ポリシーを見直す |
| 開発者 | Azure Local用ビルド経路を使う必要がある | AZURE_LOCAL フラグ付きでビルドする |
| CI/CD担当者 | 既存ビルドスクリプトとの差分確認が必要 | クリーンビルドと成果物更新を自動化する |
| 運用担当者 | 障害時の切り分け観点が変わる | IMDS/SPではなくEvidence SDK・クラスターID・Key Vault権限を見る |
Azure LocalはKey Vaultと連携したローカルID構成をサポートしており、Microsoft Learnでは、Key Vaultを使ってシークレットや構成データを安全に管理し、AD依存を減らせる利点が説明されています。今回のSKRサンプル更新も、このAzure Local側のID・Key Vault連携を前提にした流れと考えると理解しやすくなります。(Microsoft Learn)
移行時に確認する手順
既存の検証環境をAzure Local対応版に移す場合は、いきなり本番相当のキーで試さず、検証用Key Vaultと検証用キーで動作を確認してください。特にSKRは「認証」「構成証明」「Key Vaultポリシー」「キー属性」のどれか1つがずれても失敗します。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | リポジトリを最新化 | PR #89反映後のmainを取得しているか |
| 2 | Azure Local用Attestationパッケージを準備 | Azure Local対応でソースビルドしているか |
| 3 | サンプルをクリーンビルド | -DAZURE_LOCAL=ON が指定されているか |
| 4 | Key Vaultキーを準備 | エクスポート可能なキーで、SKRポリシーが付いているか |
| 5 | クラスターIDへ権限付与 | Release 権限が対象キーに効いているか |
| 6 | サンプル実行 | attestation URL、Key URL、nonceを正しく指定しているか |
| 7 | ログ確認 | エラーが構成証明、Key Vault権限、ネットワークのどれかを分類する |
検証用コマンドの考え方
READMEの例では、キーをラップする場合と、ラップ済みキーをアンラップする場合の実行例が示されています。実際の運用では、Key Vault URL、キー名、キーのバージョン、Attestation endpointを自社環境に合わせて置き換えます。(GitHub)
sudo ./AzureAttestSKR \
-a "https://<attestation-endpoint>" \
-k "https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>" \
-s "<secret-or-wrapped-key>" \
-w失敗時は、最初にKey Vaultの403だけを見るのではなく、次の順で切り分けると早く原因に近づけます。
| エラーの種類 | 最初に見る場所 | 判断基準 |
|---|---|---|
| 構成証明失敗 | Attestation endpoint、SKRポリシー | MAA要求がポリシー条件と一致しているか |
| Key Vault 403 | RBAC、アクセス ポリシー | クラスターIDにRelease権限があるか |
| ネットワーク失敗 | Azure Localホスト、Key Vault到達性 | ホスト側からKey Vaultへ到達できるか |
| 解析・復号失敗 | キー種別、暗号アルゴリズム、旧バイナリ | RSA_AES_KEY_WRAP_256 前提と実装が合うか |
| IMDS/SPエラー | ビルド成果物 | Azure Local向けビルドではない可能性がある |
RSA_AES_KEY_WRAP_256 への統一にも注意
今回のコードでは、キーリリース時の暗号化アルゴリズムとして RSA_AES_KEY_WRAP_256 が使われています。PRのコミット一覧にも、RSA_AES_KEY_WRAP_256 への切り替えに関する変更が含まれています。(GitHub)
これは単なる文字列変更ではありません。サンプル内の復号処理も、RSA-OAEP SHA-256を前提にした処理になっています。古いサンプルや独自改変したコードを混在させると、Key Vaultから値は返っているのに復号で失敗する、という分かりにくい状態になる可能性があります。
特に、次のような環境では注意してください。
| 環境 | リスク |
|---|---|
| 古いサンプルをフォークしている | アルゴリズムや復号処理だけ古いまま残る |
| ビルド済みバイナリを配布している | ソース更新後も実行ファイルが旧版のままになる |
| 複数チームがKey Vaultキーを共有している | ポリシーや権限変更の影響範囲が読みにくい |
| ログを詳細出力している | キーリリース関連の値を過剰に出力する可能性がある |
本番展開前のチェックリスト
Azure LocalでSKRサンプルを本番相当の検証に使う前に、次の項目を確認してください。
| チェック | 確認内容 |
|---|---|
| ソース | PR #89反映後のコードを使っている |
| ビルド | cmake .. -DCMAKE_BUILD_TYPE=Release -DAZURE_LOCAL=ON でビルドしている |
| 依存関係 | Azure Local対応のAttestationパッケージとEvidence SDKが利用できる |
| Key Vault | PremiumまたはManaged HSMなど、SKR対応構成を使っている |
| キー | エクスポート可能なキーとして作成し、SKRポリシーを付けている |
| 権限 | Azure LocalクラスターIDにRelease権限を付与している |
| ポリシー | Azure Local用のMAA要求に合う条件になっている |
| ネットワーク | Azure Local環境からKey Vaultへ到達できる |
| ログ | トークンやキー関連情報を不用意に出力しない |
| ロールバック | 旧手順との差分と戻し方を記録している |
ここで見落としやすいのは、Key Vaultの権限付与先です。Azure Local CVM上でサンプルを実行するため、ついVMやアプリ用サービスプリンシパルに権限を付けたくなります。しかし、この更新のポイントは、Azure LocalではSKRがクラスターIDを使って処理されることです。READMEでも、Azure Local CVMではマネージドIDはサポートされず、SKRはAzure LocalクラスターIDで処理されるため、そのIDにRelease権限を付与する必要があると説明されています。(GitHub)
まとめ：Azure Localでは「誰がKey VaultにReleaseするのか」を見直す
今回のMicrosoft Azure documentation update: Add Azure Local support to SKR sampleで最も重要なのは、SKRサンプルがAzure Local向けに実行経路を変えたことです。従来のようにVMのIMDSやサービスプリンシパルを中心に考えるのではなく、Evidence SDK、Azure LocalクラスターID、Key VaultのRelease権限をセットで確認する必要があります。
次に取るべき行動は明確です。まず対象環境で使っている cvm-securekey-release-app のソースとビルド成果物を確認し、Azure Local向けに -DAZURE_LOCAL=ON でクリーンビルドしてください。そのうえで、Key Vaultの対象キーにAzure LocalクラスターIDのRelease権限を付与し、Azure Local用のSKRポリシーで検証用キーリリースを実行します。ここまで確認できれば、Azure Local上でSKRを使う際の主要な詰まりどころを事前に潰せます。
コメント