Microsoft Purview BYOK / Azure Key Vault HSM を運用している組織は、まず自社のテナントルートキーが hsmPlatform 1 上にあるかを確認してください。該当する場合、Azure Key Vault のレガシー HSM Platform One は 2028年9月15日 に退役予定で、期限までに hsmPlatform 2 への移行が必要です。対応を後回しにすると、Microsoft Purview Information Protection の暗号化・復号操作が利用できなくなるリスクがあります。特に重要なのは、Azure Key Vault に取り込んだ BYOK キーは後からエクスポートできないため、元のオンプレミスHSMや鍵マテリアルの所在確認を今すぐ始める必要がある点です。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Purview BYOK / Azure Key Vault HSM の最新動向
Microsoft は、Microsoft Purview Information Protection で BYOK を利用している顧客向けに、Azure Key Vault HSM Platform One 退役に関するガイダンスを公開しました。2026年4月14日時点で確認すべきポイントは、次の3つです。
| 確認項目 | 実務上の意味 |
|---|---|
| 退役対象 | Azure Key Vault のレガシー HSM Platform One、つまり hsmPlatform 1 |
| 退役予定日 | 2028年9月15日 |
| Purview BYOK への影響 | hsmPlatform 1 上のテナントルートキーを利用している場合、hsmPlatform 2 への移行が必要 |
Microsoft によると、Azure Key Vault では2024年初頭に、FIPS 140-2 Level 3 認定HSMをベースにした新しいHSMプラットフォームが導入されました。一方、従来の HSM Platform One は退役対象になり、多くの Information Protection BYOK 利用者がこのレガシープラットフォームに依存している可能性があります。(TECHCOMMUNITY.MICROSOFT.COM)
ここで重要なのは、これは単なるAzure基盤の更新ではないという点です。Purview BYOK では、Azure Rights Management service のテナントルートキーが Azure Key Vault に保存され、そのルートキーにユーザーキー、コンピューターキー、ドキュメント暗号化キーなどが暗号学的に連鎖します。つまり、テナントルートキーのHSM基盤は、機密ファイルやメールの保護・復号に直結します。(Microsoft Learn)
影響を受けるのはどの環境か
影響を受けるのは、Microsoft Purview Information Protection で BYOK を構成し、そのテナントルートキーが Azure Key Vault の hsmPlatform 1 にある環境です。Microsoft 管理キーだけを使っている環境や、確認結果が hsmPlatform 2 以上の環境は、この退役対応としての移行は基本的に不要です。(Microsoft Learn)
まず、現在のキーが hsmPlatform 1 かどうかを確認します。Azure CLI では次のコマンドを使います。
az keyvault key show \
--vault-name <vault-name> \
--name <key-name> \
--query "attributes.hsmPlatform" \
-o tsvAzure PowerShell では次のように確認できます。
(Get-AzKeyVaultKey -VaultName "<vault-name>" -Name "<key-name>").Attributes.HsmPlatform結果が 1 なら移行対象です。2 以上であれば、すでに新しいHSMプラットフォーム上にあるため、このHSM退役を理由にした移行は不要です。(Microsoft Learn)
キー名やKey Vault名がすぐに分からない場合は、AIPService PowerShell モジュールで Purview / Azure Rights Management service 側に登録されているキー情報を確認します。
Connect-AipService
Get-AipServiceKeys | Select-Object KeyIdentifier, KeyVaultKeyUrlAIPService モジュールは Windows PowerShell 5.1 で動作し、PowerShell 7 などの新しいPowerShellとは互換性がない点に注意してください。運用端末や踏み台サーバーの標準環境が PowerShell 7 になっている組織では、確認作業の時点でつまずきやすいポイントです。(Microsoft Learn)
なぜ2028年の期限でも今すぐ調査すべきなのか
2028年9月15日という日付だけを見ると、まだ時間があるように見えます。しかし、Purview BYOK の移行は「新しいリソースを作って設定を変えるだけ」の作業ではありません。
最大の理由は、元の鍵マテリアルに再アクセスできるかが移行可否を左右するためです。Microsoft は、Azure Key Vault に一度取り込んだキーはエクスポートできないと説明しています。そのため、影響を受ける顧客は、元の鍵マテリアルを新しい hsmPlatform 2 の Key Vault に再インポートし、Purview 側の構成を更新する必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
特に次のような組織では、調査に時間がかかります。
| 状況 | 起こりやすい問題 |
|---|---|
| BYOK導入から数年経っている | 当時のHSM、アクセスカード、管理者、手順書が残っていない |
| M&Aや組織再編があった | 鍵管理の責任部署やサブスクリプション所有者が変わっている |
| グローバルテナントで利用している | 地域ごとにHSM、Key Vault、承認プロセスが分かれている |
| 監査要件が厳しい | 変更手順、証跡、復旧テスト、職務分掌の承認に時間がかかる |
| 旧担当者に依存していた | 鍵のバックアップ場所やHSMベンダー手順が属人化している |
2028年に近づいてから元のHSMや鍵マテリアルが見つからないと判明すると、単なる移行ではなく、再キー化、サポートケース、既存保護コンテンツのアクセス影響確認まで含むプロジェクトになります。Microsoft も、元のオンプレミス鍵マテリアルにアクセスできない顧客は、早急に計画を始めて Microsoft サポートと選択肢を確認するよう案内しています。(TECHCOMMUNITY.MICROSOFT.COM)
何もしない場合のリスク
hsmPlatform 1 のまま退役日を迎えた場合、Purview Information Protection の暗号化・復号操作が、キー移行完了まで利用できなくなる可能性があります。これは「新しいファイルを保護できない」だけでなく、「既存の保護済みファイルやメールを開けない」という業務停止リスクにつながります。(TECHCOMMUNITY.MICROSOFT.COM)
リスクは大きく3つに分けて考えると整理しやすくなります。
| リスク | 具体例 | 優先度 |
|---|---|---|
| 可用性リスク | 保護済みファイル、メール、ラベル適用済みコンテンツの復号に失敗する | 高 |
| コンプライアンスリスク | 鍵管理手順、監査証跡、データ保護要件を期限内に更新できない | 高 |
| 運用リスク | HSM担当、Purview担当、Azure担当、監査担当の調整が間に合わない | 中〜高 |
特に注意したいのは、旧キーを削除・失効すれば問題が解決するわけではない点です。Microsoft Learn では、再キー化後も旧キーで暗号化されたコンテンツを復号するには旧キーが必要であり、旧キーを削除または失効すると、そのキーで保護されたコンテンツがアクセス不能になると説明しています。(Microsoft Learn)
管理者が最初にやるべき棚卸し
最初の作業は、移行手順の実行ではなく「影響範囲の確定」です。いきなり新しいKey Vaultを作る前に、次の情報を1枚の管理表にまとめます。
| 棚卸し項目 | 確認する内容 |
|---|---|
| Purview / AIPService のキー情報 | KeyIdentifier、KeyVaultKeyUrl、現在アクティブなキー |
| Azure Key Vault | Vault名、リージョン、サブスクリプション、リソースグループ、SKU |
| HSMプラットフォーム | attributes.hsmPlatform が 1 か 2 以上か |
| 元の鍵マテリアル | オンプレミスHSM、バックアップ、管理カード、手順書の所在 |
| 管理者権限 | Azure、Key Vault、Purview、HSMベンダー、監査部門の担当者 |
| 保護対象 | SharePoint、Exchange、Officeクライアント、ラベル適用運用、外部共有の有無 |
| 監査・ログ | Azure Key Vaultログ、Azure Rights Management usage logging の取得状況 |
BYOK は、規制や社内統制のために鍵生成やライフサイクルを自社で管理したい場合に使われます。Microsoft Learn でも、BYOK はHSM保護キーなど、鍵管理に対する制御が必要な組織向けの選択肢として説明されています。つまり、技術チームだけで完結させず、コンプライアンス、リスク管理、内部監査の担当者も早めに巻き込むべきです。(Microsoft Learn)
標準的な移行パターン
hsmPlatform 1 から hsmPlatform 2 への移行は、元の鍵マテリアルを利用できるかどうかで大きく変わります。
元の鍵マテリアルにアクセスできる場合
もっとも望ましいのは、元のオンプレミスHSMまたはバックアップから同じ鍵マテリアルを新しい hsmPlatform 2 の Azure Key Vault にインポートできるケースです。この場合、Microsoft Learn の手順では、次の流れで移行します。(Microsoft Learn)
| ステップ | 作業内容 | 成果物 |
|---|---|---|
| 1 | 元のオンプレミスHSMまたはインポート可能なバックアップを確認する | 鍵マテリアルの所在確認 |
| 2 | hsmPlatform 2 の新しい Azure Key Vault を作成する | 新Key Vault |
| 3 | 元の鍵を新Key Vaultへインポートする | 新Key Vault上の同一公開鍵 |
| 4 | 新Key Vault、Rights Management service、オンプレミスHSMの公開鍵を照合する | 公開鍵一致の証跡 |
| 5 | Rights Management service が新Key Vaultを使えるようRBACを構成する | 必要権限の割り当て |
| 6 | Convert-AipServiceKeyToKeyVault でKey Vault URLを更新する | Purview側の参照先更新 |
移行前の検証では、新しいKey Vault、Rights Management service、オンプレミスHSMの公開鍵が完全に一致している必要があります。一致しない場合、Convert-AipServiceKeyToKeyVault は失敗します。これは安全装置として重要ですが、移行当日に初めて確認するとスケジュール遅延の原因になります。(Microsoft Learn)
参照先の更新は、概念的には次のようなコマンドで行います。
Connect-AipService
Convert-AipServiceKeyToKeyVault `
-KeyIdentifier <existing-key-id> `
-KeyVaultKeyUrl "https://<new-vault-name>.vault.azure.net/keys/<key-name>/<key-version>"ここで <key-version> を含めたKey Vault Key URLを指定する点も重要です。キーを更新・ローテーションした場合、Purview側の構成も新しいバージョンに合わせて更新する必要があります。(Microsoft Learn)
元の鍵マテリアルにアクセスできない場合
元のオンプレミスHSMや鍵マテリアルが見つからない場合、同じキーを新しい hsmPlatform 2 に再インポートすることはできません。この場合は新しいキーを作成し、Purview側で新しいキーをアクティブにする対応が必要になります。Microsoft Learn では、このケースでは Microsoft Purview サポートに問い合わせ、以前のキーで保護されたコンテンツの次の対応を相談するよう案内しています。(Microsoft Learn)
新しいキーをアクティブにする例は次のとおりです。
Connect-AipService
Use-AipServiceKeyVaultKey `
-KeyVaultKeyUrl "https://<vault-name>.vault.azure.net/keys/<key-name>/<key-version>"
Set-AipServiceKeyProperties `
-KeyIdentifier <new-key-id> `
-Active $trueただし、この対応は「完全な移行」とは別物です。旧キーで保護されたコンテンツは旧キーに依存するため、旧 hsmPlatform 1 キーを安易に削除してはいけません。Microsoft Learn でも、新しいキーを作成した後に既存の hsmPlatform 1 キーを削除すると、以前のキーで保護されたコンテンツがアクセス不能になると警告しています。(Microsoft Learn)
新しいKey Vaultを作るときの設計ポイント
新しい hsmPlatform 2 の Key Vault を作成する際は、単に「新しいVaultを作る」だけでは不十分です。後から設計を変えると再承認や再テストが必要になるため、次の点を先に決めておきます。
| 設計項目 | 推奨される考え方 |
|---|---|
| SKU | HSM保護キーを使う場合は Azure Key Vault Premium が必要 |
| 削除保護 | soft delete と purge protection を有効化する |
| Vaultの専用化 | Purview / Azure Rights Management tenant key 用に専用Vaultを使う |
| サブスクリプション | 可能であれば専用サブスクリプションを用意し、管理者を分離する |
| リージョン | コンプライアンス要件を優先しつつ、Azure Rights Management service との遅延も考慮する |
| 権限 | Rights Management service に必要な get、decrypt、sign 相当の権限だけを付与する |
| 監視 | Azure Key Vaultログと Azure Rights Management usage logging を突き合わせる |
Microsoft Learn は、専用Key Vaultの利用を推奨しています。理由は、ほかのサービスからの呼び出しによってKey Vaultのサービス制限に達すると、Azure Rights Management service の応答がスロットリングされる可能性があるためです。また、専用サブスクリプションは誤設定の防止や管理者分離にも役立ちます。(Microsoft Learn)
soft delete と purge protection も必須に近い設計項目です。Microsoft Learn では、Key Vaultとキーを作成したら直ちに両方を有効化するよう案内しており、十分なバックアップなしにキーを失うと、暗号化されたファイルやメールの完全なデータ損失につながると説明しています。(Microsoft Learn)
移行計画の現実的なタイムライン
公式の退役日は2028年9月15日ですが、実務では「2028年に作業開始」では遅すぎます。グローバル企業や規制産業では、次のような段階的な計画が現実的です。
| 時期の目安 | やること | 判断基準 |
|---|---|---|
| 直近 | hsmPlatform値、Key Vault、テナントキー、元鍵マテリアルを棚卸し | hsmPlatform 1 の有無を確定 |
| 2026年中 | 移行方式、責任者、HSMベンダー対応、サポート窓口を確定 | 元鍵マテリアルにアクセスできるか判断 |
| 2027年前半 | 非本番または検証用手順で公開鍵照合、RBAC、ログ確認を実施 | 手順書とロールバック判断を整備 |
| 2027年後半〜2028年前半 | 本番移行の変更申請、ユーザー影響テスト、監査証跡を準備 | 業務停止を伴わない移行日を決定 |
| 2028年9月15日より前 | 本番移行を完了し、ログと保護済みコンテンツのアクセスを確認 | 退役日までに未対応キーをゼロにする |
このタイムラインは公式期限ではなく、管理者向けの計画目安です。重要なのは、期限直前に「鍵が見つからない」「HSMベンダーの作業予約が取れない」「監査承認が下りない」といった非技術的な遅延を起こさないことです。
移行テストで確認すべきこと
本番移行前には、暗号化・復号が成功するかだけでなく、運用全体が成立するかを確認します。
| テスト項目 | 確認内容 |
|---|---|
| キー照合 | 新Key Vault、Rights Management service、オンプレミスHSMの公開鍵が一致する |
| 権限 | Rights Management service が新Key Vault上のキーで decrypt と sign を実行できる |
| 新規保護 | Officeファイルやメールにラベルを適用し、新しい保護操作が成功する |
| 既存コンテンツ | 移行前に保護されたファイルやメールを権限のあるユーザーが開ける |
| ログ | Azure Rights Management usage logging と Azure Key Vaultログでキー利用が追跡できる |
| 例外時対応 | 失敗時の停止判断、サポート連絡、変更取り消し手順が明確になっている |
Azure Rights Management usage logging では、KeyVaultDecryptRequest や KeyVaultSignRequest などの要求タイプから、テナントキーがどのように使われているかを確認できます。BYOK環境では、これを Azure Key Vaultログと突き合わせることで、Purviewのキー利用を独立して監視しやすくなります。(Microsoft Learn)
よくある失敗ポイント
Azure Key Vaultからキーをエクスポートできると思い込む
BYOKで取り込んだキーは、Azure Key Vaultや Azure Rights Management service からエクスポートできません。Azure Key Vaultのバックアップ機能はありますが、これは「外部で平文キーとして使えるエクスポート」とは違います。元の鍵マテリアルを自社側で保持していない場合、移行の選択肢が大きく制限されます。(Microsoft Learn)
Key Vaultを共有しすぎる
既存の共有Key Vaultに新しいBYOKキーを入れると、ほかのサービスの呼び出し、権限変更、管理者操作の影響を受けやすくなります。Purview BYOK のテナントルートキーは、通常のアプリケーションシークレットとは重要度が違います。専用Vault、専用サブスクリプション、限定された管理者で設計する方が安全です。(Microsoft Learn)
公開鍵照合を移行当日に初めて行う
Convert-AipServiceKeyToKeyVault は、既存のBYOKキーと新しいAzure Key Vault上のキーの公開鍵が完全に一致しない場合に失敗します。鍵名やVault名が正しく見えても、実際に別の鍵をインポートしていれば移行できません。公開鍵照合は、本番変更の前に必ず証跡として残しておくべきです。(Microsoft Learn)
旧キーを削除してしまう
再キー化や新しいキーの有効化を行っても、既存コンテンツが旧キーに依存している場合があります。旧キーを削除・失効すると、権限のあるユーザーでも過去の保護済みコンテンツを開けなくなる可能性があります。退役対応では「新しいキーを作る」ことと「旧キーを安全に保持する」ことを別の作業として扱う必要があります。(Microsoft Learn)
Compliance architects が決めるべきこと
コンプライアンスアーキテクトは、移行方式だけでなく、監査・統制・説明責任の観点を整理する必要があります。
| 決定事項 | 判断ポイント |
|---|---|
| 同一鍵マテリアルを再インポートするか | 元HSMまたはバックアップにアクセスできるか |
| 新キーへ再キー化するか | 旧鍵マテリアルが失われている場合の現実的な選択肢 |
| リージョンをどう選ぶか | データ主権、規制要件、Azure Rights Management service との遅延 |
| 鍵管理者を誰にするか | Purview管理者、Azure管理者、HSM管理者の職務分掌 |
| 証跡をどう残すか | 公開鍵照合、変更承認、ログ、サポートケース、復旧テスト |
| 旧キーをいつまで保持するか | 既存保護コンテンツの保存期間、法的保持、監査要件 |
グローバル組織では、国・地域ごとの規制やデータ主権要件も絡みます。単一の本社IT部門だけで判断せず、リージョン別の法務・コンプライアンス担当者に「鍵の場所」「管理者」「復号可能性」「退役期限」を明確に共有することが重要です。
Key-management admins が今すぐ実行するチェックリスト
Key-management admins は、まず次の順番で確認すると作業を進めやすくなります。
- Purview / AIPService に登録されている
KeyVaultKeyUrlを取得する - 対象キーの
attributes.hsmPlatformを確認する - hsmPlatform 1 のキーを一覧化する
- 元のオンプレミスHSM、管理カード、バックアップ、手順書の所在を確認する
- 新しい hsmPlatform 2 Key Vault のリージョン、SKU、サブスクリプションを設計する
- soft delete と purge protection を有効にする前提で設計する
- Rights Management service 用の権限付与方式を決める
- 公開鍵照合の手順と証跡フォーマットを作る
- Microsoft 365 Message Center の MC1234660 など、該当通知を確認する
- 鍵マテリアルが見つからない場合は、早期に Microsoft Purview サポートへ相談する
Microsoft は、2026年2月に Message Center 投稿 MC1234660 で、BYOKを利用中の影響対象顧客に Azure Key Vault HSM Platform One 退役と Information Protection テナントへの影響を通知したと説明しています。管理者は、Microsoft 365 管理センターの Message Center で自社テナント向け通知を確認しておくべきです。(TECHCOMMUNITY.MICROSOFT.COM)
まとめ：最初の一手は「hsmPlatform 1かどうか」の確認
Microsoft Purview BYOK / Azure Key Vault HSM の退役対応で最初にやるべきことは、移行作業ではなく、対象キーの特定です。attributes.hsmPlatform が 1 なら、2028年9月15日までに hsmPlatform 2 への移行計画を進める必要があります。2 以上なら、この退役対応としての緊急移行は不要です。
ただし、hsmPlatform 1 に該当した場合は、すぐに元の鍵マテリアルの所在確認へ進んでください。Azure Key VaultからBYOKキーを後でエクスポートすることはできません。移行の成否は、元のHSM、バックアップ、管理者、手順書が残っているかに左右されます。
次に取るべき行動は明確です。まず現在のPurview BYOKキーを棚卸しし、hsmPlatform値を確認します。該当キーがある場合は、元鍵マテリアルの確認、新しい hsmPlatform 2 Key Vault の設計、公開鍵照合、RBAC、テスト、監査証跡まで含めた移行計画を作成してください。2028年の期限は遠いように見えても、鍵管理の移行では「調査に最も時間がかかる」ことが珍しくありません。
コメント