Azure Key Vault certificates の2026年4月更新で最初に押さえるべき点は、大きなAPI変更や新機能追加ではなく、証明書管理の前提とデータ取り扱い表現を見直すべき更新だということです。特に2026年4月24日の差分では、公開信頼された証明書がCAや証明書透明性ログに送信される説明について、GDPR policies という表現が data-handling policies に改められました。グローバル運用では「Azure内で完結する証明書管理」と誤解せず、CA・CTログ・自社のデータ分類をあわせて確認することが重要です。(GitHub)
Microsoft Learn の公開ページでは最終更新日が2026年4月10日と表示されていますが、GitHubの履歴では2026年4月24日に about-certificates.md へコミットが入っています。この記事では、4月10日の本文整理と4月24日の文言修正をあわせて、IT管理者・プロダクトオーナーが実務で確認すべきポイントとして整理します。(Microsoft Learn)
Azureの最新動向: About Azure Key Vault certificatesで何が変わったか
2026年4月の更新は、Azure Key Vault certificates の基本仕様を大きく変えるものではありません。むしろ、既存の証明書運用を正しく理解し直すためのドキュメント更新と見るべきです。
特に4月24日の変更は、公開信頼された証明書が登録時に Azure 境界外の CA と certificate transparency、つまり CT ログへ送信される説明に関するものです。変更前はそれらのエンティティの GDPR policies に従うという表現でしたが、変更後は data-handling policies に従うという表現になりました。これは、GDPRだけに限定した説明ではなく、各CAやログ運営主体のデータ取り扱い方針を確認する必要がある、という読み方が自然です。(GitHub)
| 更新ポイント | 実務上の意味 | 取るべき対応 |
|---|---|---|
| 2026年4月24日にデータ取り扱い表現を修正 | 公開信頼証明書は Azure 境界外の CA・CTログに送られる前提で考える | CAのデータ処理条件、証明書に含めるSubject/SAN、社内説明資料を確認する |
| 2026年4月10日にドキュメント日付や表記を整理 | 破壊的変更というより、公式ドキュメントの監査・整理に近い | 「新機能追加」として扱わず、運用手順書の参照先更新として管理する |
| 古いブログ参照が現行ドキュメント参照へ差し替え | 旧ブログ記事ベースの手順が残っている可能性がある | 社内Wiki、Runbook、教育資料のリンクをMicrosoft Learn中心に更新する |
4月10日のコミットでは、about-certificates.md の日付更新やNote表記の整理が行われています。また別コミットでは、証明書発行者オブジェクト作成に関する古いブログリンクが、現行の「Integrating Key Vault with certificate authorities」への参照に差し替えられています。(GitHub)
Azure Key Vault certificatesとは何かを再確認する
Azure Key Vault certificates は、X.509証明書を作成・インポートし、安全に保存・管理するための機能です。Key Vaultでは、証明書所有者が証明書を作成または既存証明書をインポートでき、秘密鍵マテリアルを直接扱わずにX.509証明書の保管・管理を行えます。証明書ライフサイクルを管理するポリシー、期限切れや更新に関する連絡先、自動更新の仕組みも含まれます。(Microsoft Learn)
初心者がつまずきやすいのは、「Key Vault証明書は単なる証明書ファイルではない」という点です。Key Vault certificate を作成すると、同じ名前のアドレス指定可能なキーとシークレットも作成されます。キーはキー操作に使われ、シークレットは証明書の値をシークレットとして取得するために使われます。証明書オブジェクト自体には、公開X.509証明書のメタデータも含まれます。(Microsoft Learn)
| 構成要素 | 役割 | 運用での見方 |
|---|---|---|
| Key Vault certificate | 証明書メタデータ、ポリシー、ライフサイクル管理の中心 | 証明書の状態・期限・発行者・ポリシーを管理する |
| Addressable key | 証明書に紐づくキー操作を担う | 非エクスポート可能キーでは特に重要になる |
| Addressable secret | 証明書値をシークレットとして取得する経路 | PFX/PEM取得やアプリ連携時の権限設計に関わる |
2026年4月更新で特に見直すべきポイント
公開信頼証明書はAzure内だけで完結しない
今回の4月24日更新で最も実務に効くのは、公開信頼された証明書のデータ取り扱いです。公式ドキュメントでは、公開信頼証明書は登録時に Azure 境界外の CA と CTログへ送信され、それらのエンティティのデータ取り扱い方針の対象になると説明されています。(GitHub)
このため、プロダクトオーナーやセキュリティ担当者は、Azure Key Vaultを使っているかどうかだけでなく、証明書に含める情報そのものを確認する必要があります。たとえば、公開証明書のSubjectやSANに、不要な内部ホスト名、環境名、顧客を推測できる文字列を含めていないかを見直すべきです。
特にグローバル展開しているサービスでは、「GDPRに関係するか」だけで判断しないほうが安全です。CAやCTログのデータ取り扱い、契約上の説明、プライバシー影響評価、社内のデータ分類ルールをまとめて確認してください。
自動更新はすべてのCAで使えるわけではない
Azure Key Vault certificates は、選択された発行者、つまりKey VaultのパートナーであるX.509証明書プロバイダーやCAによる自動更新をサポートします。一方で、パートナー以外のプロバイダーや機関も利用できますが、自動更新はサポートされません。(Microsoft Learn)
公式ページでは、TLS/SSL証明書向けの提携証明書発行者プロバイダーとして DigiCert と GlobalSign が挙げられています。発行者オブジェクトはKey Vault内に作成され、同じKey Vault内の証明書でのみ利用できます。(Microsoft Learn)
| 証明書の作り方 | 自動更新の考え方 | 注意点 |
|---|---|---|
| Key Vault提携CAを使う | ポリシー設定により自動更新を検討できる | 発行者オブジェクト、要求者資格情報、連絡先設定を確認する |
| 非提携CAを使う | 自動更新は期待しない | CSR作成、CAへの申請、マージ、期限監視を手順化する |
| 既存証明書をインポートする | インポート後のポリシーと更新方式を確認する | 「Key Vaultに入れたから自動更新される」と考えない |
証明書更新の障害は、システム停止に直結しやすい領域です。特にWebアプリ、API Gateway、IoTデバイス、VPN、ネットワーク機器で使う証明書は、更新手順の属人化を避け、期限前に誰が何をするかを明確にしておきましょう。
エクスポート可能キーと非エクスポート可能キーを使い分ける
Key Vault証明書を作成すると、証明書はアドレス指定可能なシークレットからPFXまたはPEM形式で取得できます。ただし、秘密鍵を含めて取得できるかどうかは、証明書作成時のポリシーでキーがエクスポート可能に設定されているかに依存します。ポリシーで非エクスポート可能とされた場合、シークレットとして取得した値に秘密鍵は含まれません。(Microsoft Learn)
また、エクスポート可能なキーはRSAとECでのみ許可され、HSMキーは非エクスポート可能です。高い保護が必要な鍵を「あとでPFXとして取り出したい」という要件で設計すると、後から運用が詰まる可能性があります。(Microsoft Learn)
| 判断基準 | 推奨される考え方 |
|---|---|
| アプリや外部機器へPFX/PEMを配布する必要がある | エクスポート可能キーが必要かを事前に確認する |
| 秘密鍵の持ち出しを避けたい | 非エクスポート可能キーやHSM利用を検討する |
| 監査・金融・重要インフラ用途 | 「便利に取り出せる」より「取り出せない」設計を優先する |
| 証明書更新時に同じキーを再利用したい | ReuseKeyOnRenewal の扱いをポリシーで確認する |
よくある失敗は、証明書作成後に「PFXで取り出せない」と気づくケースです。これは不具合ではなく、非エクスポート可能キーとして作成されている可能性があります。証明書を作る前に、利用先サービスがKey Vault参照に対応しているのか、ファイル配布が必要なのかを決めておくことが重要です。
certificate policyは証明書運用の設計図になる
証明書ポリシーには、X.509証明書のSubjectやSANなどのプロパティ、キーの種類・長さ・エクスポート可否・ReuseKeyOnRenewal、シークレットのコンテンツタイプ、有効期間アクション、発行者に関するパラメーターなどが含まれます。有効期間アクションでは、期限までの日数またはライフタイムの割合をトリガーにし、emailContacts または autoRenew を実行できます。(Microsoft Learn)
証明書をゼロから作成する場合はポリシーの指定が必要です。秘密鍵を持つ証明書をKey Vaultにインポートした場合、Key VaultサービスはX.509証明書を読み取って既定のポリシーを作成します。ポリシーは、同じKey Vault証明書の全バージョンに対して1つのインスタンスとして扱われます。(Microsoft Learn)
運用では、certificate policy を「作成時の一時設定」ではなく「証明書更新を安全に回すための設計図」として扱うべきです。少なくとも次の項目は、証明書ごとに確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| Subject / SAN | 不要な内部名や顧客情報を含めていないか |
| Key type / key length | 利用先サービスとセキュリティ要件に合っているか |
| exportable | PFX/PEM取得が本当に必要か |
| lifetime actions | 通知だけか、自動更新まで行うか |
| issuer | 提携CAか、非提携CAか、手動運用が必要か |
| ReuseKeyOnRenewal | キー再利用がセキュリティ方針と合うか |
期限切れ証明書は「取得できる」ことと「使える」ことを分けて考える
Key Vault証明書には enabled 属性があり、既定値は true です。また、nbf と exp の期間外の操作は自動的に許可されません。公式ドキュメントでは、Key Vault証明書は期限切れ後も取得できる場合がある一方、TLS保護のように証明書期限を検証するシナリオでは動作しなくなる可能性があると説明されています。(Microsoft Learn)
つまり、監視の観点では「Key Vaultから取得できるか」だけを見ても不十分です。TLSエンドポイントで実際に有効な証明書が提示されているか、ロードバランサーやアプリケーションに新バージョンが反映されているかまで確認する必要があります。
証明書の連絡先は個人メールではなくチーム管理にする
証明書の連絡先は、証明書の有効期間イベントによってトリガーされる通知先です。連絡先情報はKey Vault内のすべての証明書で共有され、Key Vault内の任意の証明書イベントについて、指定されたすべての連絡先に通知が送信されます。(Microsoft Learn)
個人メールだけを設定すると、異動・退職・休暇で通知を見逃すリスクがあります。実務では、運用チームの共有メール、チケット起票用アドレス、オンコール連絡先などを組み合わせると安全です。通知を受けるだけでなく、更新作業の責任者、承認者、期限、ロールバック手順までRunbookに書いておきましょう。
アクセス制御は証明書・キー・シークレットを分けて考える
Key Vaultでは、証明書のアクセス制御ポリシーは、同じKey Vault内のキーやシークレットのアクセス制御ポリシーとは別です。アクセス制御はAzure RBACが推奨され、従来のKey Vaultアクセス ポリシーも利用できます。(Microsoft Learn)
公式ドキュメントでは、Key Vault Certificates Officer は証明書に対して権限管理以外の操作を実行でき、Key Vault Certificate User はシークレットやキー部分を含む証明書全体を読み取れると説明されています。一方、Key Vault Reader はメタデータを読めますが、機密値は読めません。(Microsoft Learn)
この違いは重要です。証明書を閲覧できればよい担当者に、秘密鍵相当の情報まで読めるロールを付与してはいけません。アプリケーション、運用担当者、監査担当者、開発者で必要な権限は異なります。
| 担当・主体 | 権限設計の考え方 |
|---|---|
| 本番アプリケーション | 必要な証明書取得だけに絞る。Managed Identityとの組み合わせを検討する |
| 証明書運用担当 | 作成・更新・インポート・連絡先管理に必要な範囲で付与する |
| 監査担当 | メタデータ閲覧中心。秘密値の読み取りは原則避ける |
| 開発者 | 開発環境と本番環境のKey Vaultを分離し、本番秘密情報へのアクセスを制限する |
IT管理者が今すぐ確認すべきチェックリスト
2026年4月更新を受けて、IT管理者は次の順番で確認すると効率的です。
| 確認項目 | 合格ライン |
|---|---|
| Key Vault内の証明書一覧 | 有効期限、用途、所有者、利用先が分かる |
| 発行者 | DigiCert / GlobalSignなど提携CAか、非提携CAかを把握している |
| 更新方式 | 自動更新、通知のみ、手動更新の区別が明確 |
| certificate policy | exportable、key type、lifetime actions、issuerが意図通り |
| 連絡先 | 個人メールだけでなくチームで受けられる |
| アクセス権 | RBACロールが最小権限になっている |
| 公開証明書のデータ取り扱い | CA・CTログへの送信前提を社内説明や契約確認に反映している |
特に、公開証明書と内部証明書を同じ感覚で扱わないことが大切です。公開信頼証明書では、CAやCTログへの送信が前提になります。内部向け証明書でも、発行元、秘密鍵の保護、更新手順、監査ログの確認を分けて設計してください。
プロダクトオーナーが見るべき観点
プロダクトオーナーにとって、Azure Key Vault certificates の更新ポイントは「証明書管理の細かい技術仕様」だけではありません。サービス継続性、顧客説明、コンプライアンス、リリース計画にも関わります。
たとえば、証明書期限切れは、アプリケーションコードにバグがなくてもサービス停止を引き起こします。自動更新を使っていても、非提携CAやインポート証明書では手動対応が必要になる場合があります。さらに、公開信頼証明書ではCAやCTログに情報が送られるため、証明書に含める名前やドメイン設計もプロダクト上の判断になります。
プロダクトオーナーは、次の3点だけでも確認しておくと、障害や説明不足を減らせます。
| 観点 | 確認すること |
|---|---|
| 可用性 | 証明書更新に失敗した場合、どの機能が止まるか |
| 情報開示 | 証明書のSubject/SANに外部へ出したくない情報が含まれていないか |
| 責任分界 | CA、Azure、運用チーム、開発チームの責任範囲が明確か |
失敗しやすいポイント
「Key Vaultに入れたから自動更新される」と思い込む
自動更新は、選択された発行者でサポートされる機能です。非提携CAやインポート証明書では、手動更新の流れを用意しなければなりません。更新方法、期限通知、作業担当、検証手順をRunbookに残してください。
「PFXやPEMはあとで取り出せる」と考える
秘密鍵を含むPFX/PEMを取得するには、作成時ポリシーでエクスポート可能にしておく必要があります。非エクスポート可能キーやHSMキーを選んだ場合、秘密鍵を取り出す運用はできません。セキュリティ上は望ましい設計ですが、配布前提のシステムでは事前確認が必須です。
「期限切れでも取得できるから大丈夫」と判断する
Key Vaultから取得できることと、TLS通信で有効に使えることは別です。期限切れ証明書は取得できても、TLS検証を行うシナリオでは動作しない可能性があります。証明書ストア、アプリ、ロードバランサー、CDN、API Managementなど、実際の利用先で反映状況を確認してください。
タグに機密情報を入れる
証明書のタグはキーやシークレットのタグと同様に、クライアント指定のキーと値のペアです。公式ドキュメントでは、呼び出し元が対象オブジェクト種別に対するlistまたはget権限を持つ場合、タグを読み取れると説明されています。(Microsoft Learn)
タグには、顧客名、案件名、内部システム名、秘密情報、個人情報を入れないほうが安全です。運用上必要な場合でも、社内コードや分類ラベルなど、公開されても問題が少ない値に置き換えましょう。
次に取るべき行動
今回の2026年4月更新は、緊急の実装修正を迫る内容というより、Azure Key Vault certificates の運用前提を見直すタイミングです。特に、公開信頼証明書のデータ取り扱い、自動更新の対象、エクスポート可否、証明書ポリシー、連絡先、RBAC権限を点検してください。
まずは本番Key Vaultにある証明書を一覧化し、期限・発行者・更新方式・利用先・所有者を整理しましょう。次に、公開証明書についてCAやCTログへの送信前提をプロダクト説明やセキュリティレビューに反映します。最後に、非提携CAやインポート証明書について、期限切れ前に確実に更新できるRunbookを整備してください。
Azure Key Vault certificates は、証明書を安全に保管するだけの機能ではありません。ポリシー、発行者、権限、通知、データ取り扱いまで含めて設計して初めて、実務で信頼できる証明書管理基盤になります。
コメント