Azure Cosmos DBで個人情報や医療・金融関連データを扱うチームにとって、2026年4月の重要な更新は「Dynamic Data Masking（DDM）」が一般提供（GA）になったことです。結論から言うと、Azure Cosmos DB for NoSQLで、権限のないユーザーに対して機密フィールドをクエリ結果上で自動的にマスクできるようになり、本番環境での利用を前提に検討しやすくなりました。
特に、開発者・サポート担当・分析担当に本番データの読み取り権限を広く付与している組織では、アプリケーションコードを大きく変えずにデータ露出リスクを下げられる点が大きなメリットです。ただし、Dynamic Data Maskingは暗号化やアクセス制御の代替ではありません。アカウントキーの扱い、Microsoft Entra IDベースのRBAC、バックアップや分析基盤へのデータ連携まで含めて設計する必要があります。
Azure Cosmos DBの最新動向: Dynamic data masking for Azure Cosmos DB reaches general availabilityで何が変わったか
Microsoftは2026年4月、Azure Cosmos DB向けDynamic Data Maskingの一般提供を発表しました。Azure UpdatesではAzure Cosmos DBの「Dynamic data masking」がLaunched / General Availabilityとして掲載され、関連するAzure Cosmos DB Blogでも、Azure Cosmos DB for NoSQL向けDDMがGAになったことが案内されています。(Microsoft Azure)
今回の更新で重要なのは、DDMが「試験的に触ってみる機能」から「本番ワークロードで採用を検討できる機能」に移ったことです。Microsoftは、DDMによって機密データを閲覧する権限のないユーザーに対して値を自動的にマスクでき、アプリケーションコードやデータモデルの変更を必要としないと説明しています。(Microsoft for Developers)
| 観点 | 従来のよくある対応 | DDM GA後にできること | 実務上の意味 |
|---|---|---|---|
| 機密データのマスク | アプリ側で個別にマスク処理を実装 | Azure Cosmos DB側のポリシーでマスク | 実装漏れやサービス間のばらつきを減らしやすい |
| 本番データの読み取り | 開発者・分析者に広めの閲覧権限を付与しがち | 権限に応じてマスク済み結果を返す | 最小権限の運用に近づけやすい |
| データモデル | マスク用フィールドや派生データを別管理 | 保存データはそのまま、クエリ結果でマスク | データ構造を大きく変えずに導入しやすい |
| 監査・統制 | アプリごとの実装確認が必要 | コンテナー単位のマスキングポリシーで管理 | DBAやセキュリティ担当が統制しやすい |
data engineers、DBAs、analytics leadersにとっては、単なるセキュリティ機能の追加ではなく、「誰にどの粒度の本番データを見せるか」をデータベース層で再設計できる更新と捉えるべきです。
Dynamic Data Maskingとは何か
Dynamic Data Maskingは、Azure Cosmos DBのサーバー側で動作するポリシーベースのセキュリティ機能です。権限のないユーザーがクエリを実行した場合、機密フィールドはリアルタイムにマスクされて返されます。一方で、データベースに保存されている元データ自体は変更されません。(Microsoft Learn)
たとえば、顧客情報を保存しているコンテナーで、以下のような制御ができます。
| フィールド例 | 権限のあるユーザー | 権限のないユーザー |
|---|---|---|
/profile/contact/email | [email protected] | [email protected] |
/profile/name/first | Taro | XXXX |
/score | 95 | 0 |
/isActive | true | false |
この仕組みは、個人情報、保護対象の医療情報、社内の人事情報、取引先情報など、閲覧できる人を限定したいデータに向いています。重要なのは、DDMが「保存時にデータを変換する機能」ではなく、「クエリ結果を返す直前にマスクする機能」である点です。
対象はAzure Cosmos DB for NoSQL
Dynamic Data Maskingの対象は、Microsoft Learnの記載ではAzure Cosmos DB for NoSQLです。Azure Cosmos DBにはMongoDB、PostgreSQLなど複数の選択肢がありますが、今回のDDMを検討する際は、まず利用中のAPIがNoSQLかどうかを確認してください。(Microsoft Learn)
この確認をせずに「Azure Cosmos DB全体で使える」と判断すると、設計レビューや導入計画で手戻りが発生します。特にグローバル企業では、国や事業部ごとにCosmos DBのAPIや認証方式が異なることがあります。導入前に、対象アカウント、API、認証方式、利用中のSDK、接続元アプリケーションを棚卸ししておくべきです。
どのようにマスクされるのか
Azure Cosmos DBのDDMでは、フィールドの種類や用途に応じて複数のマスキング戦略を使えます。Microsoft Learnでは、Default、Custom String、Emailのような戦略が説明されています。(Microsoft Learn)
| マスキング戦略 | 使いどころ | 例 |
|---|---|---|
| Default | 氏名、住所、自由記述、数値、真偽値などを大まかに隠す | 文字列はXXXX、数値は0、真偽値はfalse |
| メールアドレスの形式を保ちながら大部分を隠す | [email protected] → [email protected] | |
| MaskSubstring | 文字列の一部だけを隠す | Washington → WasXXXXXonのように一部をマスク |
実務では、すべてのフィールドを一律に隠すよりも、「業務に必要な識別性を残すか」を基準に選ぶと失敗しにくくなります。
たとえば、カスタマーサポート担当が問い合わせ対応をする場合、メールアドレスの全体は不要でも、先頭文字やドメインの一部が見えると本人確認の補助になります。一方、給与額や医療情報のように部分的な表示でもリスクが高い項目は、Defaultで完全に近い形にマスクする方が安全です。
実装の基本手順
DDMは、単に機能をオンにするだけでは完成しません。権限設計とマスキングポリシーを組み合わせて初めて意味があります。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | 対象データを分類する | PII、PHI、社外秘、分析に必要な識別子を分ける |
| 2 | 認証方式を確認する | Microsoft Entra IDとデータプレーンRBACを前提に設計する |
| 3 | DDMを有効化する | Azure portalのFeaturesから有効化する |
| 4 | ロールを定義・割り当てる | unmask権限を持つユーザーを最小限にする |
| 5 | コンテナー単位でポリシーを設定する | 対象パス、除外パス、マスキング戦略を決める |
| 6 | 権限別にテストする | 権限あり・権限なしの両方で同じクエリ結果を比較する |
| 7 | RUと連携機能を確認する | マスク対象を含むクエリのRU、Change Feed、分析連携を確認する |
Microsoft Learnでは、DDMにはMicrosoft Entra IDのマネージドIDが必要で、アカウントキーはサポートされないと説明されています。また、データマスキングはAzure Cosmos DBのデータプレーンRBACを利用し、組み込みのData Contributorロールにはunmask権限が含まれる一方、Data Readerロールには既定でunmask権限が含まれないとされています。(Microsoft Learn)
つまり、DDM導入の実務ポイントは「マスクポリシーを作ること」だけではありません。誰がunmaskできるのか、どのアプリケーションがどの認証方式で接続しているのかを整理することが先です。
マスキングポリシーの考え方
マスキングポリシーでは、どのJSONパスをマスクするかを指定します。ネストされたフィールドや配列内のフィールドも対象にできますが、配列の特定インデックスだけを指定するようなパターンはサポートされないとされています。(Microsoft Learn)
以下は、設計イメージをつかむための例です。
"dataMaskingPolicy": {
"includedPaths": [
{
"path": "/profile/contact/email",
"strategy": "Email"
},
{
"path": "/profile/contact/phone"
},
{
"path": "/employment/history/[]/company",
"strategy": "MaskSubstring",
"startPosition": 2,
"length": 4
}
]
}この例では、メールアドレスにはEmail戦略を使い、電話番号は既定のマスク、職歴の会社名は一部だけをマスクしています。
本番導入では、最初から/ですべてをマスクして除外パスを大量に設定するより、まずは明確に機密と判断できるパスから始める方が安全です。ただし、組織のセキュリティ方針によっては「原則すべてマスクし、必要な項目だけ除外する」設計の方が適する場合もあります。Microsoft Learnでは、除外パスはすべてのパス/を含めた場合にのみサポートされると説明されています。(Microsoft Learn)
DDMが役立つ代表的なシーン
本番データを使った障害調査
開発者やSREが本番障害を調査する際、注文ID、ステータス、タイムスタンプ、エラー種別は必要でも、顧客の氏名、住所、メールアドレス、電話番号までは不要なことが多いです。
DDMを使えば、調査に必要な技術情報は見せつつ、個人情報はマスクできます。アプリケーション側に調査用ビューを作り込むより、データベース層で一貫した制御をかけやすくなります。
BI・分析チームへの読み取り権限付与
analytics leadersにとって難しいのは、分析担当者に十分なデータアクセスを与えながら、不要な個人情報の露出を避けることです。
DDMは、顧客セグメント、地域、利用状況、イベント履歴のような分析に必要な項目を活かしつつ、個人を直接特定できるフィールドを隠す設計に向いています。ただし、DDMは匿名化ではありません。クエリ条件や複数データの組み合わせによって推測できる情報が残る可能性があるため、統計処理や集計基盤では別途データ最小化の設計が必要です。
外部委託先・パートナーとの共同運用
サポート業務や運用監視を外部パートナーに委託している場合、本番データへのアクセス範囲が問題になりやすいです。
DDMを使うと、問い合わせ対応に必要な最小限のデータだけを見せ、個人情報や社内機密をマスクできます。契約や監査の観点でも、「どのフィールドを誰に見せないか」をポリシーとして説明しやすくなります。
DDMとRBAC、暗号化、アプリ側マスクの違い
DDMを正しく評価するには、既存のセキュリティ対策との違いを理解する必要があります。
| 対策 | 主な目的 | DDMとの違い |
|---|---|---|
| RBAC | 誰がどの操作をできるか制御する | DDMは読み取り結果の値をマスクする。RBACの代替ではない |
| 暗号化 | 保存時・通信時のデータ保護 | DDMは正当なクエリ結果に対する表示制御 |
| アプリ側マスク | 画面やAPIレスポンスで値を隠す | DDMはDB側で一貫して適用しやすい |
| データ匿名化 | 個人を再識別しにくくする | DDMは元データを保持し、権限者は非マスク値を見られる |
DDMは「見せる必要がない人に、見せない」ための実用的な機能です。一方で、「データそのものを安全な別データに変換する」「漏えいしても影響がない状態にする」機能ではありません。この違いを誤解すると、監査やコンプライアンス対応で過大評価してしまいます。
導入前に必ず確認したい制限と注意点
DDMは便利ですが、導入前に確認すべき制限があります。特に本番環境では、以下をチェックリストとして扱ってください。
| 注意点 | 内容 | 実務での対策 |
|---|---|---|
| NoSQL API限定 | DDMはAzure Cosmos DB for NoSQL向け | 対象アカウントのAPIを事前確認する |
| 有効化後にオフにできない | アカウントレベルで有効にすると無効化できない | 先に検証環境で有効化し、影響を確認する |
| アカウントキー設計に注意 | アカウントキー利用はDDM前提の権限制御と相性が悪い | Entra IDとRBAC中心に移行する |
| RUへの影響 | マスク対象を含むクエリでは追加処理によりRUがわずかに増える可能性がある | 代表クエリでRUを測定する |
| バックアップは元データ | バックアップや一部のデータ移動は非マスク値を扱う | バックアップ閲覧権限も厳格に管理する |
| 複雑なクエリによる推測 | 条件指定などから値を推測できる場合がある | DDMだけに頼らず直接アクセスを制限する |
| Change Feedなどへの影響 | unmask権限がないユーザーではChange Feedが利用できないとされる | パイプラインの実行主体に必要権限を確認する |
| Fabric mirroring / Analytical store | DDM有効アカウントでは既定でサポートされないとされる | 利用中ならMicrosoft Supportへの確認を計画に入れる |
Microsoft Learnでは、DDM有効化後はアカウントレベルで無効化できないこと、マスク対象を含むクエリではRU消費がわずかに増える可能性があること、バックアップやMaterialized viewsは元の非マスクデータで動作すること、複雑なクエリでは推測や露出の可能性があることが説明されています。(Microsoft Learn)
ここで特に重要なのは、「DDMを有効化したから本番DBを誰にでも読ませてよい」と考えないことです。DDMは露出を減らす機能であり、直接アクセスの制限、ログ管理、監査、データ分類、キー管理と組み合わせて使うべきです。
data engineersが見るべきポイント
data engineersは、DDMが既存のデータパイプラインに与える影響を確認する必要があります。
まず、ETLやELTの実行主体がunmask権限を持つべきかを決めます。たとえば、データウェアハウスへ匿名化済みデータだけを渡すパイプラインなら、実行主体にunmask権限を与えず、マスク済みデータを取得する設計も考えられます。一方、別のセキュアな処理基盤でトークナイズや匿名化を行う場合は、限定された実行主体にunmask権限が必要になるかもしれません。
次に、Change Feedや分析ストア、Fabric連携を使っているか確認します。DDMはクエリ時の表示制御なので、データ移動や分析基盤への連携では想定どおりにマスクされない、または制限が発生する可能性があります。既存パイプラインの実行ID、接続方法、出力先を一覧化してから導入判断を行いましょう。
DBAsが見るべきポイント
DBAsにとっての主な論点は、RBACと運用統制です。
DDMでは、unmask権限を持つロールが強い意味を持ちます。誰にunmask権限を与えるか、どのスコープで与えるか、定期的に棚卸しできるかを設計する必要があります。
また、Azure Cosmos DBアカウントキーを広く配布している環境では、DDMの効果を十分に得られません。アプリケーションや運用ツールがアカウントキーで接続している場合は、Microsoft Entra IDとデータプレーンRBACに寄せる移行計画を立てるべきです。
DBAが最初に行うべき作業は、次の3つです。
| 作業 | 目的 |
|---|---|
| 接続方式の棚卸し | アカウントキー、Entra ID、マネージドIDの利用状況を確認する |
| ロール設計 | Data Reader相当、unmask可能ロール、管理者ロールを分ける |
| マスキング対象のレビュー | ID、Partition Key、業務キーを不用意にマスクしないよう確認する |
特に、IDやPartition Keyをマスクすると、Azure portalのData Explorerでドキュメント表示に影響が出るとされています。運用調査で使うキー項目をどこまで見せるかは、セキュリティ担当とDBAが一緒に決めるべきです。(Microsoft Learn)
analytics leadersが見るべきポイント
analytics leadersは、DDMを「分析チームにデータを渡しやすくする機能」として見るだけでなく、「分析に必要なデータと不要な機密データを分離する仕組み」として捉えるべきです。
たとえば、顧客行動分析では、メールアドレスや氏名そのものは不要でも、地域、契約プラン、利用頻度、問い合わせ回数は必要です。DDMを使えば、直接識別子を隠しながら分析に必要なフィールドを残せます。
ただし、DDMは匿名化でも統計的秘匿でもありません。小さなセグメントや希少な属性の組み合わせでは、マスクされていない項目から個人を推測できる可能性があります。グローバルにデータを扱う組織では、各国・地域の規制や社内ポリシーに合わせて、データ最小化、集計粒度、保持期間、アクセスレビューを組み合わせる必要があります。
導入判断の基準
DDMは、すべてのAzure Cosmos DB環境で即時有効化すべき機能ではありません。以下の条件に当てはまる場合は、優先的に検討する価値があります。
| 状況 | 導入優先度 | 理由 |
|---|---|---|
| 本番データにPIIやPHIが含まれる | 高 | 誤閲覧や過剰アクセスのリスクを下げやすい |
| 開発者やサポート担当が本番DBを直接参照する | 高 | 権限別にマスク結果を返せる |
| アプリごとにマスク実装がばらついている | 高 | DB層で一元管理しやすい |
| すでにEntra ID / RBAC中心の接続に移行済み | 中〜高 | DDMを導入しやすい |
| アカウントキー接続が多い | 中 | 先に認証方式の見直しが必要 |
| Change FeedやFabric mirroringを多用している | 要検証 | 連携制限や権限設計の確認が必要 |
| テスト用の小規模環境のみ | 低〜中 | 本番データ露出リスクが小さいなら優先度は下がる |
判断のコツは、「マスクしたいデータがあるか」ではなく、「マスクされていない本番データを見ている人が、実際にはその値を業務上必要としていないか」を確認することです。不要な閲覧を減らせるなら、DDMの価値は高くなります。
失敗しやすいポイント
DDM導入でよくある失敗は、機能そのものではなく、運用設計の甘さから起きます。
マスク対象を広げすぎて業務が止まる
すべてのフィールドを一気にマスクすると、障害調査やサポート対応で必要な業務キーまで見えなくなることがあります。注文ID、テナントID、ステータス、タイムスタンプなど、業務に必要な非機密データは残す設計が必要です。
アプリケーションログを見落とす
DDMはAzure Cosmos DBから返されるクエリ結果に対するマスクです。unmask権限を持つアプリケーションが非マスク値を取得し、そのままログや外部サービスに送信していれば、別の場所で機密データが露出します。
アカウントキー接続を残したままにする
DDMを本気で使うなら、アカウントキーを人やツールに広く配る運用は見直すべきです。認証・認可をMicrosoft Entra IDとRBACに寄せ、unmask権限を明確に管理することが前提になります。
分析基盤への連携を確認しない
DDMはストレージ上のデータを変えるわけではありません。バックアップ、Materialized views、分析ストア、ミラーリング、データエクスポートなど、Cosmos DBの外に出るデータについては別途確認が必要です。
導入時の実務チェックリスト
本番環境でDDMを導入する前に、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 対象API | Azure Cosmos DB for NoSQLである |
| 対象データ | PII、PHI、社外秘、業務キーを分類済み |
| 接続方式 | アカウントキー依存を把握し、Entra ID / RBAC移行方針がある |
| ロール | unmask権限を持つユーザー・アプリを最小化している |
| ポリシー | マスク対象パスと除外パスをレビュー済み |
| 検証 | 権限あり・権限なしで同じクエリを比較済み |
| RU | 代表的なクエリでRU消費を測定済み |
| 運用 | 障害調査時に必要なフィールドが見える |
| 監査 | unmask権限の棚卸し手順がある |
| 連携 | Change Feed、バックアップ、分析ストア、Fabric連携への影響を確認済み |
DDMは、セキュリティ担当だけで決める機能ではありません。データエンジニア、DBA、アプリケーションチーム、分析責任者が同じテーブルで、どのデータを誰に見せるかを決める必要があります。
2026年4月更新への実務対応まとめ
2026年4月のAzure Cosmos DB更新では、Dynamic Data MaskingがGAとなり、Azure Cosmos DB for NoSQLで本番利用を前提に検討できる重要なセキュリティ機能になりました。アプリケーションコードやデータモデルを大きく変更せず、権限のないユーザーに対してクエリ結果上の機密フィールドをマスクできる点は、開発・運用・分析の現場にとって大きな前進です。
一方で、DDMは万能なデータ保護ではありません。保存データは変わらず、権限者は元データを見られます。複雑なクエリによる推測、バックアップや分析連携、アカウントキー接続、RUへの影響も考慮する必要があります。
次に取るべき行動は明確です。まず、自社のAzure Cosmos DB for NoSQLアカウントを棚卸しし、機密フィールド、接続方式、unmaskが必要なユーザー・アプリを洗い出してください。そのうえで、検証環境でDDMを有効化し、代表クエリ、RU、業務フロー、分析連携への影響を確認することが、2026年4月更新を安全に活かす最短ルートです。
コメント