Azure SQL / SQL Server の Dynamic Data Masking（DDM）は、機密データを「保存時に守る機能」ではなく、権限のないユーザーに対してクエリ結果の表示を抑制するためのプレゼンテーション制御として扱うべきです。つまり、DDMは最小権限の実装を補助する機能であり、Always Encrypted、Row-Level Security、監査、権限設計、暗号化を置き換えるものではありません。
2026年4月20日、MicrosoftはDynamic Data Maskingについて「何であり、何ではないか」を改めて整理した公式ガイダンスを公開しました。要点は明確です。DDMは、メールアドレスや電話番号などを結果セット上でマスクし、偶発的な露出を減らすには有効です。一方で、元データは変更されず、暗号化もされず、行単位のアクセス制御にもなりません。データベースセキュリティチーム、コンプライアンス設計者、Azure SQL管理者は、DDMを「表示制御の一部」として設計に組み込み、他の保護策と組み合わせる必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
Dynamic Data Maskingは「見せ方」を制御する機能
Dynamic Data Maskingは、指定した列にマスクルールを設定し、権限のないユーザーがSQLクエリを実行したときに、結果セット上の値を伏せ字や部分表示に変換する機能です。たとえば、メールアドレス列にマスクを設定すると、通常ユーザーには [email protected] のような値が返され、元のメールアドレスそのものは表示されません。Microsoft Learnでも、DDMは非特権ユーザーへの機密データ露出を制限し、アプリケーション層の設計や実装を簡素化する機能として説明されています。(Microsoft Learn)
重要なのは、データベース内の実データは変更されないという点です。DDMは列の値を保存前に加工するわけでも、暗号化するわけでもありません。あくまで、クエリ結果が返されるタイミングで表示を変える仕組みです。
たとえば、次のような列に向いています。
| 対象列 | DDMの使い方 | 期待できる効果 |
|---|---|---|
| メールアドレス | email() で一部だけ表示 | サポート担当者が顧客識別に使いつつ、完全なアドレス露出を避ける |
| 電話番号 | partial() で下数桁のみ表示 | 本人確認の補助に使いながら、全番号の露出を減らす |
| 生年月日 | default() や日時用マスクを利用 | 年齢確認や分析用途で過剰な個人情報表示を避ける |
| 会員番号・割引コード | random() や default() を利用 | 業務上不要な数値情報を画面やレポートで隠す |
DDMの価値は、保存データそのものを守ることではなく、日常的な参照画面、レポート、運用確認、問い合わせ対応で「見せすぎ」を防ぐことにあります。
2026年4月20日のMicrosoftガイダンスが示したポイント
Microsoftが2026年4月20日に公開したAzure SQL Blogの記事では、DDMの目的、適切なユースケース、制限事項が改めて整理されています。特に強調されているのは、DDMはアプリケーションやレポートで機密値の表示を標準化し、偶発的・カジュアルな露出を抑えるために有効だが、単独のデータ保護策ではないという点です。(TECHCOMMUNITY.MICROSOFT.COM)
この更新は、DDMを「暗号化の代わり」と誤解する設計を避けるうえで重要です。検索需要としても、DDMとAlways Encryptedの違い、DDMと最小権限、SQL ServerやAzure SQLのコンプライアンス設計を比較したいニーズは根強くあります。実務では、DDMを導入するかどうかよりも、どのリスクにDDMを使い、どのリスクには別の制御を使うかを明確にすることが欠かせません。
Microsoftの説明に沿えば、DDMは次のような性質を持ちます。
| 観点 | DDMでできること | DDMでできないこと |
|---|---|---|
| 表示制御 | 非特権ユーザーへの結果表示をマスクする | 元データを暗号化する |
| アプリケーション実装 | 画面やレポートごとのマスク実装を減らす | すべてのアクセス経路を安全にする |
| 権限制御 | UNMASK 権限の有無で表示を変える | SELECT や管理者権限そのものを制限する |
| コンプライアンス | データ最小表示の補助になる | 監査、暗号化、アクセスレビューを代替する |
| 攻撃対策 | 偶発的な露出を減らす | 推測クエリや高権限ユーザーから守り切る |
DDMを暗号化の代替にしてはいけない理由
DDMとAlways Encryptedは、目的がまったく異なります。DDMはクエリ結果の表示を変える機能です。一方、Always Encryptedは、クレジットカード番号や識別番号などの機密情報をクライアント側で暗号化し、暗号化キーをDatabase Engineに公開しない設計です。Microsoftは、Always Encryptedを、データ所有者とデータベース管理者などの高権限運用者を分離するための機能として説明しています。(Microsoft Learn)
DDMでは、データベース内部の値は平文のまま扱われます。そのため、暗号化が必要な要件に対してDDMだけを使うと、設計上のギャップが残ります。たとえば、次のような要件ではDDM単独では不十分です。
- データベース管理者にも特定列の平文を見せたくない
- バックアップやストレージ上のデータ保護が必要
- 規制や社内基準で暗号化が明示的に求められている
- クラウド運用者、DBA、委託先管理者との職務分掌を厳格にしたい
- 漏えい時に平文データの露出リスクを下げたい
このような場合は、Always Encrypted、Transparent Data Encryption（TDE）、TLS、Azure Key Vault、監査などを組み合わせて設計します。Azure SQLのセキュリティ概要でも、ネットワーク、認証、認可、監査、暗号化、データ分類などを含む多層防御の考え方が示されています。(Microsoft Learn)
DDMとAlways Encryptedの使い分け
| 比較項目 | Dynamic Data Masking | Always Encrypted |
|---|---|---|
| 主目的 | 結果セットでの表示抑制 | 列データの暗号化 |
| 元データ | 変更されない | 暗号化される |
| DBAからの保護 | 高権限ユーザーは見える可能性がある | キーにアクセスできない管理者からの保護を意図 |
| アプリ改修 | 比較的少ない場合が多い | ドライバー、キー管理、クエリ制約への対応が必要 |
| 向いている用途 | サポート画面、レポート、非特権ユーザー向け表示 | クレジットカード番号、国民識別番号、高機密個人情報 |
| 注意点 | 推測や権限過多に弱い | 検索、並べ替え、結合などに制約が出る場合がある |
DDMは「見せない」ための機能、Always Encryptedは「読めない状態で保存・処理範囲を制限する」ための機能です。両者を競合機能としてではなく、リスクに応じて併用する部品として考えると設計しやすくなります。
DDMをRow-Level Securityの代替にしてはいけない理由
DDMは列の値をマスクしますが、行そのものを隠す機能ではありません。営業担当者Aには自分の担当顧客だけ、テナントAにはテナントAのデータだけを見せたい、という要件にはRow-Level Security（RLS）を使うべきです。
Microsoft Learnでは、Row-Level Securityはユーザーのグループメンバーシップや実行コンテキストに基づいて、テーブル内の行へのアクセスを制御する機能として説明されています。RLSには、読み取り可能な行を絞るフィルター述語と、条件に違反する書き込みをブロックするブロック述語があります。(Microsoft Learn)
たとえば、マルチテナントSaaSで次のような設計をしたとします。
SELECT CustomerName, Email, TenantId
FROM dbo.Customers;DDMを使えば、Email を [email protected] のようにマスクできます。しかし、TenantId が異なる他社データの行まで返ってくるなら、根本的なアクセス制御としては不十分です。ここで必要なのは、DDMではなくRLSによる行フィルタリングです。
| 要件 | 適した機能 |
|---|---|
| 顧客メールアドレスを一部だけ表示したい | DDM |
| 担当部署の顧客行だけ参照させたい | Row-Level Security |
| テナントごとにデータ行を分離したい | Row-Level Security |
| DBAにも特定列の平文を見せたくない | Always Encrypted |
| 保存データやバックアップを暗号化したい | TDE、Always Encrypted、キー管理 |
| アクセス履歴を残して調査したい | Auditing、Defender for SQL、ログ監視 |
列の表示制御と行のアクセス制御は別物です。DDMを入れても、閲覧可能な行の範囲が広すぎる設計は解決しません。
DDMは最小権限の補助として設計する
DDMを安全に使うには、最小権限の原則とセットで考える必要があります。Microsoft Learnでは、マスクされた列に対しても、テーブルへの SELECT 権限があるユーザーはデータを参照できます。ただし、UNMASK 権限がなければマスクされた値が表示されます。管理者ユーザーや sysadmin、db_owner などの高権限ロールは、設計上、マスクされていないデータを見られる場合があります。(Microsoft Learn)
実務での設計ポイントは、次の3つです。
UNMASKを業務上必要なロールだけに付与する
DDM導入時によくある失敗は、「問い合わせ対応チーム」「開発者」「運用担当者」などに広く UNMASK を付けてしまうことです。これではDDMの意味が薄れます。
たとえば、次のように分けます。
| ロール | 参照範囲 | UNMASKの考え方 |
|---|---|---|
| 一次サポート | 顧客検索、問い合わせ履歴 | 原則付与しない。メールや電話は部分表示 |
| 二次サポート | 本人確認、障害調査 | 必要な列だけ限定的に付与 |
| コンプライアンス担当 | 監査・調査 | 承認プロセスとログを前提に付与 |
| DBA | 管理作業 | 業務データ閲覧の必要性を別途評価 |
| 開発者 | 非本番検証 | 本番データでは原則付与しない |
SQL Server 2022以降では、UNMASK 権限をデータベース、スキーマ、テーブル、列といった粒度で付与・取り消しできるようになっています。対応環境では、全体に広く付与するのではなく、列単位・業務単位で絞る設計が有効です。(Microsoft Learn)
db_ownerや管理者権限を日常業務に使わせない
DDMは高権限ユーザーに対する強い防御策ではありません。db_owner や sysadmin などの権限を持つユーザーは、マスクされていない値を見られたり、マスク設定を変更・削除できたりする可能性があります。Microsoftの2026年4月20日のガイダンスでも、特権ユーザー管理と監査の重要性が明示されています。(TECHCOMMUNITY.MICROSOFT.COM)
そのため、運用設計では次のルールを徹底します。
- 日常的な参照用アカウントに管理者権限を付けない
- DBA作業用とデータ閲覧用のIDを分ける
- 一時的な昇格は申請・承認・期限付きにする
ALTER ANY MASK、CONTROL、UNMASKの付与状況を定期レビューする- マスク設定の変更を監査対象にする
DDMを導入しても、権限設計が粗いままでは「マスクしているはずなのに多くの人が平文を見られる」状態になります。
アドホッククエリ権限を慎重に扱う
DDMは結果表示をマスクしますが、データベース内部では実データを使って比較や条件判定が行われます。そのため、十分なクエリ権限を持つユーザーが条件を細かく変えながら検索すると、値を推測できる場合があります。Microsoft Learnでも、DDMはアプリケーションで使う定義済みクエリにおける露出制限に向いているが、アドホッククエリを実行できるユーザーが推測や総当たりで実値に近づくリスクがあると説明されています。(Microsoft Learn)
たとえば、給与列をマスクしていても、次のような条件検索を繰り返せるなら、実値の範囲を狭められる可能性があります。
SELECT EmployeeId, Salary
FROM dbo.Employees
WHERE Salary BETWEEN 9000000 AND 9100000;この問題を避けるには、DDMだけでなく、次の制御が必要です。
- アドホッククエリを実行できるユーザーを限定する
- 定型レポートやストアドプロシージャ経由の参照に寄せる
- 監査ログで不自然な条件検索を検知する
- 高機密列はAlways Encryptedやアクセス制御で保護する
- 分析用途には匿名化・集計済みデータセットを用意する
DDMの実装例：まずは「見せる必要がない列」から始める
DDMは、複雑なセキュリティ戦略を一気に完成させる機能ではありません。実務では、まず「多くのユーザーに完全表示する必要がない列」を選び、表示最小化のコントロールとして導入するのが現実的です。
たとえば、顧客テーブルのメールアドレスと電話番号をマスクする場合は、次のように設定できます。
ALTER TABLE dbo.Customers
ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');
ALTER TABLE dbo.Customers
ALTER COLUMN PhoneNumber ADD MASKED WITH (FUNCTION = 'partial(3, "XXXX", 2)');マスクされた列を確認するには、sys.masked_columns を使います。Microsoft Learnでも、マスクが設定された列とマスク関数を確認する方法として sys.masked_columns が紹介されています。(Microsoft Learn)
SELECT
s.name AS schema_name,
t.name AS table_name,
c.name AS column_name,
c.masking_function
FROM sys.masked_columns AS c
JOIN sys.tables AS t
ON c.object_id = t.object_id
JOIN sys.schemas AS s
ON t.schema_id = s.schema_id
WHERE c.is_masked = 1;権限設計は、マスク設定と同じくらい重要です。たとえば、通常のサポートロールには SELECT のみを与え、マスク解除が必要な監査ロールにだけ UNMASK を付与します。
GRANT SELECT ON dbo.Customers TO support_readonly;
-- 対応環境では、必要な列に限定してUNMASKを付与する
GRANT UNMASK ON dbo.Customers(Email) TO compliance_reviewer;ここで大切なのは、DDLを投入して終わりにしないことです。必ず、実際の業務ロールでログインし、画面、レポート、SQLクライアント、エクスポート処理でどのように見えるかを検証します。
DDM導入前に確認すべきチェックリスト
DDMは設定自体が比較的簡単なため、設計を飛ばして導入されがちです。しかし、コンプライアンスや監査で問われるのは「マスクを設定したか」ではなく、「なぜその制御で十分だと判断したか」です。
| 確認項目 | 判断基準 | よくある失敗 |
|---|---|---|
| 対象データの分類 | 個人情報、決済情報、医療情報、社内機密などを分類済みか | 機密度が高い列にもDDMだけを使う |
| 利用者ロール | 誰が何のために見るかを定義したか | 全員に同じ参照権限を付ける |
UNMASK付与 | 必要最小限のロール・列に限定したか | サポート部門全体に広く付与する |
| 管理者権限 | db_ownerやsysadminが過剰でないか | 日常運用アカウントが高権限 |
| アドホッククエリ | 推測検索のリスクを評価したか | SQL実行権限を広く許可する |
| エクスポート | CSV、BI、ETL、バックアップの扱いを確認したか | 別経路で平文が流出する |
| 監査 | 参照、権限変更、マスク変更を追えるか | 設定変更の証跡がない |
| 代替・併用策 | Always Encrypted、RLS、TDE、監査と役割分担したか | DDMを万能な保護策として扱う |
DDMの成否は、マスク関数の選び方よりも、ロール設計、アクセス経路の把握、監査運用で決まります。
コンプライアンス設計では「DDMを使っている」だけでは足りない
DDMは、個人情報や機密情報の表示を最小化するうえで有効な補助策です。しかし、コンプライアンス対応では、DDMだけを根拠に「データ保護済み」と説明するのは危険です。
Azure SQLのセキュリティ概要では、データ分類が監査、異常アクセスのアラート、アクセス制御、セキュリティ強化、プライバシー標準や規制対応の土台になると説明されています。また、Azure SQLでは監査、脅威検出、暗号化、アクセス管理など複数のセキュリティ機能を組み合わせる考え方が示されています。(Microsoft Learn)
監査や審査に備えるなら、次のような説明ができる状態を目指します。
| 監査で問われやすい観点 | 用意すべき説明 |
|---|---|
| なぜDDMを使ったのか | 非特権ユーザーへの表示最小化が目的であること |
| なぜ暗号化ではないのか | 当該列のリスク評価と、暗号化が必要な列との切り分け |
| 平文を見られる人は誰か | UNMASK、管理者権限、業務承認フロー |
| 行レベルの分離はどうしているか | RLS、アプリ側認可、テナント分離設計 |
| エクスポート時の扱いはどうか | BI、ETL、CSV、バックアップ、ログへの出力制御 |
| 変更履歴は追えるか | 監査ログ、権限変更履歴、マスク設定変更履歴 |
| 定期レビューはあるか | アクセス権、ロール、対象列、例外承認の棚卸し |
特にグローバル企業では、地域ごとのプライバシー要件、委託先運用、クラウド運用者との職務分掌、データ越境、監査証跡の保持期間などが絡みます。DDMはその一部を支える機能であり、全体設計の中心に置くべきものではありません。
DDMが有効なユースケース
DDMが役立つのは、「完全な秘匿」ではなく「必要以上に見せない」場面です。
サポート担当者向けの顧客検索画面
問い合わせ対応では、顧客を識別するためにメールアドレスや電話番号の一部が必要になることがあります。しかし、全桁・全文字を常時表示する必要はありません。DDMを使えば、一次サポートには部分表示、二次対応や本人確認が必要な担当者には承認付きで平文表示、という設計にしやすくなります。
開発・検証環境での偶発的露出低減
本番に近いデータを使って検証する場合、開発者に完全な個人情報を見せる必要がないケースがあります。ただし、DDMはデータ自体を匿名化するわけではありません。非本番環境で本番データを扱う場合は、静的マスキング、匿名化、データサブセット化、権限制御も併用するべきです。
BIレポートや運用レポートの表示制御
売上分析や問い合わせ分析では、顧客名や連絡先の完全表示が不要なことがあります。DDMを使うと、同じテーブルを参照しながら、非特権ユーザーにはマスク済みの値を返せます。ただし、BIツール側のキャッシュ、エクスポート、共有リンク、データセット権限もあわせて確認する必要があります。
委託先・外部運用者への限定的な参照
外部ベンダーに障害調査や運用確認を依頼する場合、全データの平文表示は避けたいものです。DDMは、問い合わせIDやステータスは見せつつ、個人情報列をマスクする設計に向いています。ただし、委託先に高権限DBロールを与えるとDDMの効果が弱まるため、権限分離と監査ログが前提になります。
DDMを使うべきではない、または単独では不十分なケース
DDMは便利ですが、次のようなケースでは単独利用を避けるべきです。
| ケース | DDMだけでは不十分な理由 | 検討すべき対策 |
|---|---|---|
| DBAにも平文を見せたくない | 高権限ユーザーはマスクを回避・変更できる可能性がある | Always Encrypted、職務分掌、キー管理 |
| テナントごとに行を分離したい | DDMは行をフィルタリングしない | Row-Level Security、アプリ認可 |
| 規制で暗号化が必要 | DDMは暗号化ではない | TDE、Always Encrypted、TLS、Key Vault |
| アドホックSQLを広く許可している | 推測クエリで実値に近づく可能性がある | 権限制限、監査、定型クエリ化 |
| CSVやETLで外部連携する | 権限や経路によって平文が移動する可能性がある | エクスポート制御、DLP、静的マスキング |
| データ侵害時の影響を下げたい | 保存データはマスクされていない | 暗号化、監査、アクセス制御、検知 |
「DDMを設定したから安全」ではなく、「DDMでどの露出を減らし、残るリスクを何で抑えるか」を明文化することが重要です。
Azure SQL / SQL ServerでDDMを設計する実務フロー
DDM導入は、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| データ分類 | 機密列、個人情報、業務上の表示要否を整理 | 機密データ台帳 |
| ロール定義 | 誰がどの列をどの粒度で見るかを定義 | ロール・権限マトリクス |
| 機能選定 | DDM、RLS、Always Encrypted、TDE、監査を役割分担 | セキュリティ設計書 |
| マスク設計 | 列ごとに email()、partial()、default() などを選ぶ | マスク対象一覧 |
| 権限設定 | SELECT、UNMASK、管理者権限を最小化 | 権限付与スクリプト |
| 検証 | 業務ロールごとに表示、検索、エクスポートを確認 | テスト結果 |
| 監査 | 参照、権限変更、マスク変更を記録 | 監査ログ設計 |
| 定期レビュー | 例外権限、不要ロール、対象列を棚卸し | レビュー記録 |
特に、データ分類とロール定義を飛ばさないことが大切です。対象列が曖昧なままDDMを設定すると、「重要な列がマスクされていない」「不要な列をマスクして業務が止まる」「UNMASK が広すぎる」といった問題が起きます。
設計判断の目安：DDMは「最後の防壁」ではなく「表示最小化の標準化」
DDMの位置づけを一言で表すなら、最小権限を実務画面やレポートに落とし込むための表示制御です。
次のように判断すると、DDMを過大評価せずに使えます。
- ユーザーに行の存在を見せてもよいが、列の完全な値は不要 → DDMが有効
- ユーザーにその行自体を見せてはいけない → RLSや認可設計が必要
- 管理者や運用者にも平文を見せたくない → Always Encryptedを検討
- 保存データやバックアップを守りたい → TDEやキー管理が必要
- 不正アクセスや濫用を検知したい → 監査と脅威検出が必要
- コンプライアンス証跡が必要 → データ分類、権限レビュー、ログ保全が必要
DDMは軽量で導入しやすい一方、守れる範囲は限定的です。だからこそ、適切な場所で使えば効果的です。
まとめ：DDMは暗号化でも行制御でもなく、最小権限を補強する表示制御
Dynamic Data Maskingは、Azure SQL / SQL Serverで機密データの露出を抑える便利な機能です。ただし、その役割はクエリ結果の表示制御です。保存データを暗号化する機能でも、行単位でアクセスを制限する機能でも、コンプライアンス対応を単独で完結させる機能でもありません。
2026年4月20日のMicrosoftガイダンスが示す通り、DDMはアプリケーションやレポートで機密値の表示を標準化し、偶発的な露出を減らすために使うのが適切です。実務では、DDMをAlways Encrypted、Row-Level Security、TDE、監査、データ分類、権限レビューと組み合わせ、最小権限の一部として設計しましょう。
次に取るべき行動はシンプルです。まず、自社のAzure SQL / SQL Serverで「誰が、どの列を、なぜ平文で見る必要があるのか」を棚卸ししてください。そのうえで、表示だけを抑えればよい列にはDDMを、行を分離すべきデータにはRLSを、平文アクセス自体を避けたい列にはAlways Encryptedを検討します。この切り分けができれば、DDMは過不足のない実用的なセキュリティコントロールになります。
コメント