2026年6月3日に公開・更新された Azure の告知で注目すべき点は、Azure Database for PostgreSQL – Flexible Server が、別の Microsoft Entra テナントにある Azure Key Vault／Managed HSM のカスタマー マネージド キー（CMK）を使えるようになったことです。つまり、SaaS 事業者やグループ会社のように「データベースを運用するテナント」と「暗号化キーを管理するテナント」を分けたいケースで、より現実的な鍵管理設計が取れるようになります。なお、名称に Azure SQL が含まれて検索されることがありますが、今回の対象は Azure SQL Database や Azure SQL Managed Instance ではなく、Azure Database for PostgreSQL – Flexible Server です。Microsoft の Azure Updates では In preview は非本番での利用・検証向けとして扱われます。 (マイクロソフト Azure)
今回の変更点：クロステナントCMKで「DB運用」と「鍵管理」を分離できる
Azure Database for PostgreSQL – Flexible Server では、保存データは常に暗号化されます。対象には、システムデータベース、ユーザーデータベース、サーバーログ、WAL、バックアップなどが含まれます。既定ではサービス マネージド キー（SMK）が使われますが、より厳格な鍵管理が必要な場合は、Azure Key Vault または Azure Key Vault Managed HSM に保存したカスタマー マネージド キー（CMK）を利用できます。 (Microsoft Learn)
今回の Public Preview で追加されたのは、PostgreSQL Flexible Server と Key Vault／Managed HSM が異なる Microsoft Entra テナントに存在する構成です。Microsoft Learn では、このクロステナントCMKを、サービス提供者側のテナントに PostgreSQL リソースがあり、顧客側のテナントに暗号化キーがあるシナリオとして説明しています。 (Microsoft Learn)
| 観点 | 従来のCMK構成 | クロステナントCMKのPublic Preview |
|---|---|---|
| PostgreSQLサーバー | サービス提供者または利用者のテナント内 | サービス提供者側の Microsoft Entra テナント |
| 暗号化キー | 原則として同じテナントの Key Vault／Managed HSM | 顧客側など別テナントの Key Vault／Managed HSM |
| 主な用途 | 自社内のセキュリティ統制、鍵ローテーション管理 | SaaS、ISV、グループ会社、顧客管理キー要件への対応 |
| 運用上の注意 | Key Vault、ID、権限、ローテーションの管理が必要 | それに加えて、テナント間のアプリ登録・権限委任・責任分界が必要 |
| 本番利用 | 通常のCMKは要件に応じて利用可能 | Public Preview のため、本番適用は慎重に判断 |
この変更の本質は、暗号化そのものが新しくなったというより、暗号化キーの所有・管理をデータベース運用者から分離しやすくなった点にあります。
たとえば、SaaS 事業者が Azure Database for PostgreSQL – Flexible Server を自社テナントで運用し、顧客が自社テナントの Key Vault で暗号化キーを管理する構成が考えられます。顧客はキーのライフサイクルを自分たちのセキュリティポリシーに合わせて管理でき、サービス提供者は PostgreSQL 基盤の運用に集中できます。
Azure SQLの更新ではなく、Azure Database for PostgreSQLの更新として確認する
今回のトピックは「Azure SQL」という文脈で見つける人もいますが、実際の対象サービスは Azure Database for PostgreSQL – Flexible Server です。
Azure SQL Database、Azure SQL Managed Instance、SQL Server on Azure VM のCMK設定が直接変更されたわけではありません。Azure SQLを運用している管理者が確認すべきなのは、「自社のAzureデータベース全体の暗号化キー管理方針に影響するか」という観点です。
特に、次のような組織では Azure SQL 担当者も情報を押さえておく価値があります。
- Azure SQL と Azure Database for PostgreSQL を併用している
- クラウドDBの暗号化キー管理をセキュリティ部門が一元管理している
- 顧客別テナント、事業会社別テナント、国・地域別テナントを使い分けている
- SaaS基盤で「顧客が鍵を持つ」モデルを検討している
逆に、Azure SQL Database だけを使っていて PostgreSQL Flexible Server を使っていない場合、今回のプレビューによって既存環境の設定変更が必要になるわけではありません。
影響を受ける可能性が高い対象者
今回の Public Preview は、すべての Azure 利用者に大きな影響がある変更ではありません。影響が大きいのは、テナント分離と鍵管理を厳密に設計している組織です。
| 対象者 | 確認すべき理由 |
|---|---|
| SaaS／ISV事業者 | サービス提供者テナントでDBを運用し、顧客テナントのキーで暗号化する設計が検討しやすくなる |
| セキュリティ管理者 | Key Vault、Managed HSM、Microsoft Entra ID、RBAC、監査ログの設計が必要 |
| Azure管理者 | サーバー作成時の暗号化方式、リージョン、ID、権限設定を誤ると後から変更しにくい |
| PostgreSQL運用担当者 | キー失効や権限削除がDB接続不可につながるため、監視と復旧手順が重要 |
| 開発者／SRE | IaC、デプロイ手順、障害時の切り分け、切り戻し設計に影響する |
| 情報システム部門 | 顧客管理キー要件や委託先管理の説明材料として使える可能性がある |
一方で、既定のサービス マネージド キーを使っているだけの小規模な検証環境や、単一テナント内で完結している環境では、急いで対応する必要はありません。
クロステナントCMKの構成イメージ
クロステナントCMKでは、大きく分けて「サービス提供者側テナント」と「顧客側テナント」の2つを意識します。Microsoft Learn の説明では、サービス提供者側でマルチテナントアプリケーションを作成し、ユーザー割り当てマネージド ID をフェデレーション資格情報として構成します。顧客側では、そのマルチテナントアプリケーションをインストールし、Key Vault または Managed HSM とキーを用意して、必要なキー権限を付与します。 (Microsoft Learn)
| 役割 | 主な作業 |
|---|---|
| サービス提供者側テナント | マルチテナントアプリの作成、ユーザー割り当てマネージド ID の構成、PostgreSQL Flexible Server の作成 |
| 顧客側テナント | Key Vault／Managed HSM の用意、暗号化キーの作成または利用、マルチテナントアプリへのキー権限付与 |
| PostgreSQL Flexible Server | 作成時に CMK、ユーザー割り当てマネージド ID、キー識別子、マルチテナントアプリのクライアントIDを関連付ける |
実務では、サービス提供者と顧客の間で「誰がどの操作を行うのか」を事前に決めておく必要があります。特に、キーの削除、無効化、期限切れ、権限変更はデータベース可用性に直結します。
管理者が最初に確認すべき設定項目
クロステナントCMKを試す前に、まず次の項目を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 対象サービス | Azure Database for PostgreSQL – Flexible Server であること。Azure SQL Database ではない |
| 利用目的 | 顧客管理キー、SaaS、テナント分離、鍵管理分離などの明確な要件があるか |
| 利用環境 | Public Preview のため、本番ではなく検証・非本番から始める |
| リージョン | プレビュー対応リージョンに対象環境を作れるか |
| サーバー作成タイミング | CMK方式はサーバー作成時に選ぶ必要があるため、既存サーバーへの単純な後付けを前提にしない |
| Key Vault／Managed HSM | キー、削除保護、監査、ネットワーク制御、権限設計が整っているか |
| Microsoft Entra ID | マルチテナントアプリ、ユーザー割り当てマネージド ID、フェデレーション資格情報を管理できるか |
| 運用体制 | キーローテーション、障害時復旧、顧客との責任分界を文書化できるか |
特に重要なのは、CMKは暗号化を強化する便利機能ではなく、鍵を失うとデータベースの可用性に影響する運用責任を引き受ける機能だという点です。
対応リージョンとプレビュー制限
Microsoft Learn によると、クロステナントCMKのプレビューは、現時点で East US 2、West US 2、US Central、Australia Southeast、Australia East、North Europe のリージョンに限定されています。また、Azure PowerShell と Azure CLI ではまだサポートされておらず、geo-redundant backups を有効にしたサーバー作成や long-term retention backup operations も現在はサポート対象外とされています。 (Microsoft Learn)
| 制限 | 実務上の影響 |
|---|---|
| 対応リージョンが限定される | Japan East／Japan West 前提の本番構成にはそのまま適用できない可能性がある |
| Azure PowerShell／Azure CLI 未対応 | 自動化は Azure Portal、ARM テンプレート、REST API などの対応状況を確認して設計する |
| geo-redundant backups と LTR に制限 | DR、長期保管、監査要件がある環境では本番採用の前に代替策が必要 |
| Public Preview | SLA、サポート条件、仕様変更の可能性を前提に検証する |
日本国内リージョンでの利用を前提にしている場合は、まず「現時点で検証できるリージョン」と「将来本番配置したいリージョン」を分けて考える必要があります。プレビュー検証は対応リージョンで行い、本番設計はGAやリージョン拡大の情報を待つ、という進め方が現実的です。
既存サーバーへの影響と移行時の考え方
既存の Azure Database for PostgreSQL – Flexible Server に対して、サービス マネージド キーからカスタマー マネージド キーへ同じサーバー上で切り替えることはできません。Microsoft Learn では、データ暗号化で SMK と CMK のどちらを使うかはサーバー作成時に決定し、作成後に切り替えられないと説明されています。既存サーバーで方式を変えたい場合は、バックアップを新しいサーバーへ復元する方法が選択肢になります。 (Microsoft Learn)
移行を検討する場合は、次の流れで進めると失敗しにくくなります。
| ステップ | 作業内容 | 注意点 |
|---|---|---|
| 現状確認 | 既存サーバーが SMK か CMK か、リージョン、バックアップ、レプリカ構成を確認 | 暗号化方式の後付け変更を前提にしない |
| 要件整理 | 顧客管理キー、テナント分離、監査、DR、長期保管の要件を整理 | プレビュー制限と矛盾しないか確認 |
| 検証環境作成 | 対応リージョンで新しい PostgreSQL Flexible Server を作成 | 本番データではなく検証データから始める |
| クロステナント設定 | マルチテナントアプリ、ID、Key Vault権限、キー識別子を設定 | 顧客側テナントの作業手順も文書化 |
| 復元・接続確認 | アプリケーション接続、性能、バックアップ、監視を確認 | キー権限を意図的に外す障害テストも行う |
| 切り替え計画 | DNS、接続文字列、メンテナンス時間、ロールバックを設計 | プレビュー機能を本番投入する場合はリスク承認が必要 |
ここで避けたいのは、「CMKを有効にすればセキュリティが上がる」とだけ考えて、復旧手順を作らずに進めることです。CMKでは、キー管理の自由度が上がる一方で、キーにアクセスできないとDBが利用できなくなるリスクも増えます。
Key Vaultとキー設定で確認すべきポイント
CMKを使う場合、Key Vault または Managed HSM の設計が重要です。Microsoft Learn では、Key Vault の soft-delete、purge protection、権限付与、キーの種類、キー状態などが要件として挙げられています。キーは非対称の RSA または RSA-HSM が対象で、2,048、3,072、4,096 ビットがサポートされ、より高いセキュリティには 4,096 ビットが推奨されています。 (Microsoft Learn)
| 設定項目 | 推奨・確認ポイント |
|---|---|
| soft-delete | 誤削除からの復旧に備えて有効化する |
| purge protection | 削除後すぐに完全消去されないようにする |
| 削除済みコンテナー保持期間 | 90日保持が推奨されている |
| キーの種類 | RSA または RSA-HSM を使用する |
| キーサイズ | 2,048／3,072／4,096 ビット。高セキュリティ要件では 4,096 ビットを検討 |
| キー状態 | Enabled であること |
| 有効開始日時 | 設定する場合は過去日時になっていること |
| 有効期限 | 設定する場合は期限切れにならない運用を用意する |
| 監査ログ | Key Vault のアクセスログを Azure Monitor Logs やSIEMに連携する |
| リソースロック | 誤削除防止のため Key Vault にロックを設定する |
セキュリティ部門が Key Vault を管理し、DBA が PostgreSQL を管理する組織では、操作権限を明確に分けることが重要です。たとえば、DBAにはDB操作権限を付与しても、キーの削除や無効化までは許可しない設計が望ましいケースがあります。
権限設定で失敗しやすいポイント
CMK構成で最も多いトラブルは、キーそのものではなく、IDと権限の不足です。通常のCMKでは、Azure Database for PostgreSQL Flexible Server のユーザー割り当てマネージド ID に対して、Key Vault の RBAC 権限モデルなら Key Vault Crypto Service Encryption User ロール、従来のアクセスポリシーなら get、list、wrapKey、unwrapKey などの権限が必要です。 (Microsoft Learn)
クロステナントCMKでは、これに加えてマルチテナントアプリとフェデレーション資格情報が関係します。サービス提供者側だけで設定が完結しないため、顧客側テナントの管理者がアプリのインストールやKey Vault権限付与を行える状態にしておく必要があります。
よくある失敗は次の通りです。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 顧客側テナントでアプリが承認されていない | PostgreSQLサーバー作成時にキーへアクセスできない | 事前に承認手順と必要権限を顧客側に共有する |
| Key Vault権限が不足している | キーの取得・ラップ・アンラップに失敗する | RBACまたはアクセスポリシーを最小権限で正しく付与する |
| キー識別子を誤る | サーバー作成やローテーションが失敗する | Key Identifier をコピーし、バージョンあり／なしを運用方針に合わせる |
| Key Vaultのネットワーク制限が厳しすぎる | PostgreSQLからキーに到達できない | 信頼された Microsoft サービスの許可など、公式推奨に沿って確認する |
| 管理者がキーを無効化・削除する | DBが Inaccessible になる | 削除保護、監査、変更承認フローを設定する |
特にSaaSで顧客管理キーを扱う場合は、顧客がキーを無効化したときの扱いを契約・運用手順に含めるべきです。「キーを止める＝データアクセスを止める」という意味になるため、サポート窓口や障害対応フローにも影響します。
デプロイ時に確認したいARM／REST APIの要点
Microsoft Learn の例では、クロステナントCMKを ARM テンプレートや REST API で構成する場合、primaryKeyUri、primaryUserAssignedIdentity、primaryFederatedIdentityClientId などの指定が必要です。また、REST API の例では api-version=2025-03-15-privatepreview またはそれ以降を使う旨が示されています。 (Microsoft Learn)
実務でIaC化する場合は、次の観点をレビューしてください。
| パラメーター | 意味 | 確認ポイント |
|---|---|---|
primaryKeyUri | 顧客側Key Vault／Managed HSMにあるキーのURI | バージョン付きURIか、バージョンなしURIかを運用方針に合わせる |
primaryUserAssignedIdentity | PostgreSQL Flexible Serverに割り当てるユーザー割り当てマネージド ID | サービス提供者側テナントで正しく作成・関連付けされているか |
primaryFederatedIdentityClientId | マルチテナント Microsoft Entra アプリのクライアントID | 省略するとクロステナントCMKとして扱われない可能性がある |
dataEncryption.type | Azure Key Vault を使った暗号化指定 | SMK／CMKの切り替え不可を理解して作成する |
注意したいのは、キーURIだけを更新する場合でも、データ暗号化関連のプロパティをまとめて指定する必要がある点です。Microsoft Learn では、primaryFederatedIdentityClientId をリクエスト本文に含めないと、クロステナントCMK構成ではなく非クロステナントCMK構成として扱われると説明されています。 (Microsoft Learn)
キーローテーション時の注意点
CMK運用では、キーの作成よりもローテーションのほうが重要です。Azure Database for PostgreSQL Flexible Server では、バージョンなしキーURIを使うことで、Key Vault側で新しいキー バージョンが利用可能になった際に、PostgreSQL側が新しいバージョンを自動的に取り込む構成が可能です。 (Microsoft Learn)
ただし、運用では次の点を守る必要があります。
| 運用項目 | 注意点 |
|---|---|
| 自動キー バージョン更新 | バージョンなしキーURIを使う設計にすると、手作業の更新漏れを減らせる |
| 手動ローテーション | バージョン付きURIを使っている場合、PostgreSQL側の参照更新が必要 |
| 旧キーの扱い | ローテーション後すぐに無効化しない |
| 監視 | ローテーション後にサーバー状態、Activity log、アプリ接続を確認する |
| 作業手順 | 顧客側テナントとサービス提供者側テナントの両方で手順を合わせる |
Microsoft Learn では、キーを新しいバージョンにローテーションする場合、再暗号化が成功するまで古いキーを利用可能な状態に保つ必要があり、少なくとも2時間待ってから古いキー バージョンへのアクセスを無効化することが推奨されています。 (Microsoft Learn)
障害時に起きること：キーにアクセスできないとDBは利用不可になる
CMK構成では、Azure Database for PostgreSQL Flexible Server が継続的にキーへアクセスできる必要があります。キーが無効化、削除、期限切れ、到達不能になった場合、サーバーは Inaccessible 状態になり、接続を拒否し始める可能性があります。Microsoft Learn では、キーが無効化・削除・期限切れ・到達不能になった場合、通常60分以内に Inaccessible になり、キーが再び利用可能になった後も Ready に戻るまで最大60分かかる場合があると説明されています。 (Microsoft Learn)
| 原因 | 影響 | 復旧の考え方 |
|---|---|---|
| キーの期限切れ | DBがキーを使えず接続不可になる | キーの有効期限を延長し、状態回復を待つ |
| キーの削除 | DBが暗号化キーにアクセスできない | Key Vaultのsoft-deleteから復旧する |
| Key Vaultの削除 | DB全体がキーにアクセスできない | Key Vaultを復旧し、再検証を待つ |
| マネージド ID の削除 | キー取得に使うIDが失われる | IDを復旧または新規作成し、サーバー側設定を更新する |
| RBACロール削除 | wrapKey／unwrapKeyなどが実行できない | 必要なロールまたはアクセスポリシーを再付与する |
| Key Vaultファイアウォール変更 | PostgreSQLからKey Vaultに到達できない | ネットワーク制御と信頼されたサービス設定を見直す |
本番相当の検証では、正常系だけでなく「キー権限を外したら何が起きるか」「復旧にどれくらいかかるか」まで確認しておくべきです。これは障害訓練としても重要です。
開発者・SREが確認すべきアプリケーション側の影響
クロステナントCMKは主にインフラ・セキュリティ寄りの機能ですが、アプリケーション側にも影響します。
まず、接続文字列やSQLクエリの書き方が直接変わるわけではありません。アプリケーションは通常どおり PostgreSQL に接続します。ただし、キーアクセス障害が起きた場合は、アプリケーションから見ると「DB接続不可」「タイムアウト」「認証以前の接続失敗」のように見える可能性があります。
開発者・SREは、次の点を確認してください。
- DB接続失敗時のリトライが過剰になっていないか
- キーアクセス障害と通常のネットワーク障害を監視上で区別できるか
- アプリケーションログに接続先サーバー名、タイムスタンプ、エラーコードが残るか
- デプロイ時に新サーバーへの切り替え手順を自動化できるか
- ロールバック時に旧サーバーへ戻せるDNS・接続文字列設計になっているか
- 顧客側のキー操作が原因の停止を、SLAやサポート範囲でどう扱うか
SaaSでは、顧客が自分のキーを管理するほど、障害原因がサービス提供者側だけに閉じなくなります。SREの運用設計では、顧客側テナントの設定変更もインシデント要因として扱う必要があります。
導入判断の基準
クロステナントCMKは、要件に合えば非常に有用ですが、すべての環境に必要な機能ではありません。導入判断は、次の基準で行うとよいでしょう。
| 判断 | 向いているケース |
|---|---|
| すぐ検証すべき | SaaSで顧客管理キー要件がある、ISVとして顧客テナントのキー利用を求められている |
| 情報収集に留める | 将来的にテナント分離を検討しているが、現在は単一テナントCMKで足りている |
| 今は不要 | PostgreSQL Flexible Serverを使っていない、SMKで十分、キー管理の追加負荷を避けたい |
| 本番適用は慎重に判断 | 国内リージョン、geo-redundant backups、LTR、CLI自動化が必須の環境 |
セキュリティ要件が強いほど魅力的に見えますが、プレビュー段階では制限もあります。特にDRや長期保管が必須のシステムでは、クロステナントCMKだけを前提に設計せず、現行のバックアップ・レプリケーション要件と突き合わせてください。
実務での確認チェックリスト
最後に、管理者・開発者が実際に動くためのチェックリストを整理します。
| 項目 | 確認 |
|---|---|
| サービス確認 | 対象が Azure Database for PostgreSQL – Flexible Server である |
| 影響確認 | Azure SQL Database への直接変更ではないことを関係者に共有した |
| 利用目的 | 顧客管理キー、SaaS、テナント分離などの要件が明確である |
| リージョン | Public Preview 対応リージョンで検証環境を作成できる |
| サーバー作成 | CMKはサーバー作成時に選ぶ必要があることを理解した |
| Key Vault | soft-delete、purge protection、監査、リソースロックを確認した |
| キー | RSA／RSA-HSM、キーサイズ、Enabled状態、有効期限を確認した |
| Entra ID | マルチテナントアプリ、フェデレーション資格情報、ユーザー割り当てマネージド ID を設計した |
| 権限 | Key Vault権限を最小権限で付与した |
| 自動化 | ARM／REST API のパラメーターをレビューした |
| 監視 | Resource health、Activity log、Key Vaultログのアラートを用意した |
| 障害訓練 | キー失効・権限削除・Key Vault到達不可の復旧手順を検証した |
| 移行 | 既存サーバーのインプレース切り替えを前提にしていない |
| 本番判断 | Public Preview の制限とリスクを承認プロセスに載せた |
今回の Public Preview は、Azure Database for PostgreSQL – Flexible Server をSaaSや複数テナント構成で使う組織にとって、鍵管理の選択肢を広げる重要なアップデートです。まずは既存環境の暗号化方式、PostgreSQL Flexible Server の利用有無、Key Vault 管理体制を棚卸しし、対応リージョンの非本番環境で小さく検証するところから始めるのが安全です。
コメント