結論から言うと、Azure SQL / SQL Server の Dynamic Data Masking（DDM）は「機密データを表示時に隠す機能」であり、保存データそのものを守る暗号化機能ではありません。2026年4月20日にMicrosoftが公開した新しい解説では、DDMの有効な使いどころと限界が改めて整理されました。特に重要なのは、DDMを「情報漏えい対策の中心」に置くのではなく、最小権限、監査、Row-Level Security、Always Encrypted などと組み合わせて使うことです。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、セキュリティチーム、コンプライアンス責任者、プラットフォームアーキテクト向けに、Microsoftの最新ガイダンスを安全対策の文脈で読み解きます。読み終える頃には、自社のAzure SQL / SQL Server環境で何を優先して確認し、どのリスクから下げるべきかが分かります。
Microsoftの最新ガイダンスで押さえるべき結論
Microsoftの新しい説明で最も大事なのは、Dynamic Data Maskingを「万能なデータ保護」ではなく、クエリ結果に表示される値を制御するための補助的な機能として扱う点です。DDMでは、メールアドレスや電話番号などの列にマスクルールを定義し、権限のないユーザーに対して [email protected] のような形式で結果を返せます。一方で、データベース内に保存されている元データは変更されません。(TECHCOMMUNITY.MICROSOFT.COM)
これは、ヘルプデスク担当者、一次サポート、業務委託先、レポート閲覧者などに「必要以上の個人情報を見せない」場面では有効です。しかし、DDMは暗号化ではなく、行単位のアクセス制御でもなく、強い権限を持つユーザーからデータを隠す仕組みでもありません。Microsoftのドキュメントでも、DDMは監査、暗号化、Row-Level Securityなどの機能と併用することが推奨されています。(Microsoft Learn)
つまり、今回の更新を受けた実務上の判断は明確です。
DDMを導入している組織は、「マスクしているから安全」と考えるのではなく、「どの経路なら元データが見えるのか」を棚卸しする必要があります。
Dynamic Data Maskingでできること、できないこと
DDMの評価で失敗しやすいのは、「見えない」と「守られている」を同じ意味で扱ってしまうことです。以下の表で、DDMの役割と限界を整理します。
| 観点 | DDMでできること | DDMだけではできないこと | 実務での判断基準 |
|---|---|---|---|
| 画面・レポート表示 | クエリ結果の一部をマスクして表示する | 保存データそのものを暗号化する | 業務画面やBIレポートの過剰表示を減らす用途に向く |
| 権限のない閲覧者 | SELECT結果にマスク済みの値を返す | アドホッククエリによる推測を完全に防ぐ | 直接DB接続を許すユーザーには追加対策が必要 |
| 管理者・高権限ユーザー | 一般ユーザー向けの表示を制御する | db_owner、sysadmin、CONTROL相当の権限者から隠す | 管理者権限の棚卸しが最優先 |
| 行単位の制限 | 列の表示を変える | テナント別、部署別、顧客別に行をフィルターする | 行制御はRow-Level Securityで設計する |
| データ移動 | 条件によってはマスク済みデータとして出力される | すべてのバックアップ、エクスポート、ETL先を自動的に保護する | データ移動経路ごとに権限と出力内容を確認する |
| コンプライアンス | 過剰な閲覧を減らす統制の一部になる | DDM単体で法令・規格準拠を保証する | 証跡、権限管理、暗号化、運用ルールとセットで説明する |
Microsoftの説明でも、DDMはクエリ結果に適用されるため、条件指定やフィルターを使った推測、権限ユーザーによるマスク解除、メタデータ上のマスク情報の確認、データ移動時の扱いに注意が必要だとされています。(TECHCOMMUNITY.MICROSOFT.COM)
DDMを安全対策として見直すべき理由
Dynamic Data Maskingは便利な機能ですが、セキュリティ対策としては「見せ方の制御」に近い位置づけです。たとえば、サポート担当者が顧客一覧を見るときに、メールアドレス全体ではなく一部だけを表示する。営業レポートで電話番号や識別番号を隠す。こうした用途では、アプリケーション側の実装負担を減らしながら、偶発的な情報露出を減らせます。
一方で、次のようなケースではDDMだけに頼ると危険です。
- 開発者や運用担当者に本番DBへの直接接続を許可している
db_ownerやCONTROL権限を広く付与している- BI、ETL、データレイク、外部委託先へのエクスポート経路が多い
- DDMを「暗号化」や「アクセス制御」と同じ意味で説明している
- 監査ログを取得していない、または誰も確認していない
特にグローバル組織では、地域ごとの個人情報保護要件、外部委託、監査対応、データ主権の観点から、「誰が、どの国・地域から、どのデータを、どの形式で見られるか」を説明できる必要があります。DDMはその説明材料の一部にはなりますが、中心に置くべきなのは権限管理と証跡です。
影響評価で最初に確認すべき項目
DDMの見直しでは、いきなり機能を追加するよりも、現状のリスクを可視化することが重要です。セキュリティチームとDBA、アプリケーション担当者が同じ表を見て判断できるように、以下の観点で棚卸しします。
| 確認項目 | 見るべきポイント | 取るべきアクション |
|---|---|---|
| マスク対象列 | どのテーブル・列にDDMが設定されているか | sys.masked_columnsで一覧化し、機密区分と照合する |
| 高権限ユーザー | UNMASK、ALTER ANY MASK、CONTROL、db_ownerを誰が持つか | 不要な権限を削除し、承認制にする |
| 直接DB接続 | 業務ユーザーや開発者が自由にSQLを実行できるか | ビュー、ストアドプロシージャ、踏み台、承認フローに寄せる |
| データ移動 | エクスポート、バックアップ、ETL、BI、データ共有の経路 | 出力先ごとにマスク状態とアクセス権を確認する |
| 監査 | マスク変更、権限変更、機密列アクセスを追えているか | Azure SQL AuditingまたはSQL Server Auditを設計する |
| 説明責任 | DDMの限界を監査資料や設計書に書いているか | 「DDM単体では保護しない範囲」を明文化する |
Azure SQL Databaseの監査は、データベースイベントを追跡し、Azure Storage、Log Analytics、Event Hubsなどに監査ログを書き込めます。SQL Serverでも、サーバーレベル・データベースレベルの監査アクショングループや個別アクションを使って監査を設計できます。(Microsoft Learn)
まず実施すべきリスク低減策
DDM対象列を棚卸しする
最初に行うべきなのは、DDMが設定されている列の一覧化です。以下のクエリで、マスク対象のテーブル、列、マスク関数を確認できます。
SELECT
SCHEMA_NAME(t.schema_id) 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
WHERE c.is_masked = 1
ORDER BY
schema_name,
table_name,
column_name;この結果は、情報資産台帳やデータ分類表と照合します。たとえば、顧客ID、メールアドレス、電話番号、住所、生年月日、給与、認証情報に近い値などが未対応であれば、DDMの追加だけでなく、そもそも誰が参照できるべきかを見直します。
注意すべきなのは、DDMを追加すること自体をゴールにしないことです。機密度が高い列ほど、「マスク表示で十分か」「行制御が必要か」「暗号化すべきか」「そもそも本番データを非本番環境に渡してよいか」を分けて判断します。
UNMASKと管理者権限を最小化する
DDMの効果を大きく左右するのは、マスクを解除できるユーザーの範囲です。Microsoftのドキュメントでは、UNMASK権限を持つユーザーはマスクされていないデータを取得でき、CONTROL権限を持つ管理者や sysadmin、db_owner などのロールは、設計上マスクされていないデータを表示できると説明されています。(Microsoft Learn)
まず、次のようなクエリで明示的な権限付与を確認します。
SELECT
pr.name AS principal_name,
pr.type_desc AS principal_type,
pe.permission_name,
pe.state_desc,
pe.class_desc,
OBJECT_SCHEMA_NAME(pe.major_id) AS schema_name,
OBJECT_NAME(pe.major_id) AS object_name,
COL_NAME(pe.major_id, pe.minor_id) AS column_name
FROM sys.database_permissions AS pe
JOIN sys.database_principals AS pr
ON pe.grantee_principal_id = pr.principal_id
WHERE pe.permission_name IN ('UNMASK', 'ALTER ANY MASK', 'CONTROL')
ORDER BY
pr.name,
pe.permission_name;次に、ロール経由の権限も確認します。
SELECT
role_principal.name AS role_name,
member_principal.name AS member_name
FROM sys.database_role_members AS drm
JOIN sys.database_principals AS role_principal
ON drm.role_principal_id = role_principal.principal_id
JOIN sys.database_principals AS member_principal
ON drm.member_principal_id = member_principal.principal_id
WHERE role_principal.name IN ('db_owner', 'db_datareader', 'db_datawriter')
ORDER BY
role_name,
member_name;実務では、db_owner を「便利だから」という理由で付与しているケースが少なくありません。しかしDDMの観点では、db_ownerはマスクされたデータを見る側ではなく、マスクを管理・回避できる側です。恒久的な管理者権限は最小限にし、作業時だけ昇格する運用に寄せるべきです。
SQL Server 2022以降では、UNMASK権限をデータベース、スキーマ、テーブル、列といった粒度で付与・取り消しできます。全社共通で広く UNMASK を与えるのではなく、「請求担当は請求テーブルの一部列だけ」「監査担当は特定スキーマだけ」のように、業務上必要な範囲へ絞る設計が現実的です。(Microsoft Learn)
アドホッククエリによる推測を前提にする
DDMの大きな限界は、クエリ結果の表示を変えても、条件判定には元データが使われる点です。たとえば給与列が 0 と表示されていても、ユーザーが次のような条件を試せる場合、値の範囲を推測できる可能性があります。
SELECT EmployeeId, Salary
FROM Employees
WHERE Salary BETWEEN 9000000 AND 10000000;Microsoftのドキュメントでも、任意のアドホッククエリを実行できるユーザーは、推測や総当たりに近い手法で実際の値を推定できる可能性があると説明されています。DDMは偶発的な露出を抑えるには有効ですが、悪意ある推測から機密データを完全に守る目的では単独利用すべきではありません。(Microsoft Learn)
対策としては、次の順で検討します。
| 対策 | 具体例 | 効果 |
|---|---|---|
| 直接SQL実行を減らす | 業務ユーザーはアプリ、ビュー、ストアドプロシージャ経由にする | 推測クエリの自由度を下げる |
| 参照範囲を制限する | 部署、担当顧客、テナント単位でアクセス範囲を絞る | 大量推測の影響を小さくする |
| 監査を有効にする | 機密列への検索、権限変更、マスク変更を記録する | 不審な探索行動を検知しやすくする |
| クエリ権限を分ける | 開発、運用、分析、監査でロールを分離する | 「誰でも見られる」状態を防ぐ |
Row-Level Securityと組み合わせる
DDMは列の表示を変える機能であり、行そのものを隠す機能ではありません。たとえばマルチテナントSaaSで「顧客Aの担当者は顧客Aの行だけ見える」という要件がある場合、DDMではなくRow-Level Security（RLS）を検討します。
RLSは、グループメンバーシップや実行コンテキストに基づいて、テーブル内の行へのアクセスを制御する機能です。フィルター述語で読み取り対象の行を制限したり、ブロック述語で条件に合わない書き込みを防いだりできます。(Microsoft Learn)
DDMとRLSの役割分担は、次のように考えると分かりやすいです。
| 要件 | 主に使う機能 |
|---|---|
| メールアドレスの一部だけ見せたい | Dynamic Data Masking |
| 自部署の顧客行だけ見せたい | Row-Level Security |
| 管理者やDB運用者にも平文を見せたくない | Always Encrypted |
| 誰が何を実行したか記録したい | Auditing / SQL Server Audit |
| 本番データを検証環境に持ち出したい | 静的マスキング、匿名化、サブセット化を検討 |
列のマスクと行の制御を混同すると、設計レビューで抜け漏れが起きます。特にSaaS、金融、医療、人事、教育などのデータでは、「列を隠す」だけでなく「そもそも対象行にアクセスできるべきか」を必ず確認してください。
Always Encryptedが必要な列を切り分ける
保存データや高権限ユーザーからの保護を重視する場合、DDMではなくAlways Encryptedを検討します。Always Encryptedは、クレジットカード番号や国・地域の識別番号などの機密情報を保護するための機能で、暗号化キーをデータベースエンジンに公開しない設計を取ります。これにより、データを管理する立場のユーザーと、データを閲覧できるべきユーザーを分離しやすくなります。(Microsoft Learn)
ただし、Always Encryptedには制約があります。暗号化方式によって検索、並べ替え、結合、集計などに制限が出るため、既存アプリケーションの改修が必要になる場合があります。Microsoftのドキュメントでも、暗号化データに対する操作には制限があると説明されています。(Microsoft Learn)
判断基準は次の通りです。
| データの種類 | 推奨される考え方 |
|---|---|
| サポート画面で一部だけ隠したいメールアドレス | DDMで十分な場合がある |
| 業務上、一部担当者だけが見ればよい顧客情報 | DDM + RLS + 最小権限を検討 |
| 管理者にも平文を見せたくない識別番号 | Always Encryptedを検討 |
| 非本番環境にコピーする本番データ | DDMではなく静的マスキングや匿名化を検討 |
| 分析用に集計だけ使うデータ | 元データを渡さず、集計済みデータセットを作る |
DDMとAlways Encryptedは競合するというより、守る対象が違います。DDMは「表示時の露出を減らす」、Always Encryptedは「保存・処理の段階で平文アクセスを制限する」という役割で整理すると、設計判断がぶれにくくなります。
監査と検知をDDM運用の前提にする
DDMの運用で見逃してはいけないのは、マスク設定や権限設定が後から変わることです。最初は適切に設計していても、障害対応、リリース作業、分析依頼、外部委託の追加によって、UNMASK や db_owner が一時的に付与され、そのまま残ることがあります。
Azure SQLでLog Analyticsに監査ログを送っている場合、SQL監査ログのテーブルには、実行されたT-SQL文、データベース名、プリンシパル名、クライアントIP、アプリケーション名などの列があります。(Microsoft Learn)
たとえば、以下のような観点で定期確認用のクエリを用意します。
SQLSecurityAuditEvents
| where TimeGenerated > ago(30d)
| where Statement has_any ("UNMASK", "MASKED WITH", "DROP MASKED", "ALTER ANY MASK")
| project
TimeGenerated,
LogicalServerName,
DatabaseName,
ServerPrincipalName,
DatabasePrincipalName,
ClientIp,
ApplicationName,
Statement
| order by TimeGenerated descこのクエリはあくまで出発点です。実際には、自社の監査設定、ログの保存先、アクショングループ、命名規則に合わせて調整してください。重要なのは、DDMの設定変更と権限変更を「誰かが気づける状態」にすることです。
SQL Server環境では、DATABASE_PERMISSION_CHANGE_GROUP、DATABASE_OBJECT_CHANGE_GROUP、SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP、SELECT監査など、対象とするリスクに応じて監査アクションを設計します。SQL Server Auditでは、サーバーレベルとデータベースレベルのイベントを監査できますが、対象を広げすぎるとログ量が増えるため、機密テーブルや権限変更から優先するのが現実的です。(Microsoft Learn)
データ移動時のリスクを別枠で管理する
DDMは「そのデータベース内で、該当ユーザーにクエリ結果を返すとき」に効く機能です。そのため、エクスポート、バックアップ、ETL、データレイク連携、BIツール、外部共有などのデータ移動は、別のリスクとして管理する必要があります。Microsoftの新しいガイダンスでも、マスクは特定のデータベースインスタンスのスキーマレベルで定義されるため、バックアップやエクスポートされたデータセットに未マスク値が含まれる可能性がある点が挙げられています。(TECHCOMMUNITY.MICROSOFT.COM)
特に注意すべき経路は次の通りです。
| データ移動経路 | よくある落とし穴 | 対策 |
|---|---|---|
| BIツール | 接続ユーザーに強い権限があり、未マスク値を取得する | BI専用ロールを作り、必要な列だけビューで公開する |
| ETL / ELT | 本番DBからデータレイクへ平文でコピーする | コピー前に匿名化・トークン化・列除外を行う |
| CSVエクスポート | 一時的な調査で個人情報を含むCSVが残る | エクスポート承認、保存期限、共有禁止ルールを設ける |
| 非本番環境 | 本番データをそのまま開発・検証に使う | 静的マスキング済みデータセットを用意する |
| バックアップ | 復元先でアクセス制御が緩くなる | 復元先の権限、ネットワーク、監査も本番相当にする |
| 外部委託 | 委託先に広い参照権限を渡す | 契約、アクセス期限、列単位の最小権限をセットで管理する |
データ移動の管理では、「DDMが設定されているか」よりも「移動先で誰が平文にアクセスできるか」を基準にします。DDM対象列を含むデータセットは、移動先ごとにオーナー、保存期間、再共有可否、削除方法を決めておくと、監査対応がしやすくなります。
組織内でDDMを説明するときの注意点
DDMの説明資料や設計書では、次のような表現を避けるべきです。
| 避けたい表現 | 問題点 | 推奨表現 |
|---|---|---|
| DDMで個人情報を保護している | 暗号化やアクセス制御と誤解されやすい | DDMで非特権ユーザーへの表示露出を低減している |
| マスク済みなので漏えいしない | 推測、権限者、データ移動のリスクを無視している | DDMは多層防御の一部であり、監査と権限管理で補完している |
| 管理者にも見えない | db_ownerやsysadminには見える可能性がある | 高権限ユーザーは別途統制し、必要に応じてAlways Encryptedを検討する |
| DDMでコンプライアンス対応済み | コンプライアンスは単一機能では保証できない | DDM、監査、権限管理、暗号化、運用証跡を組み合わせて説明する |
コンプライアンス責任者にとって重要なのは、DDMの有無そのものではなく、リスクに対する統制が説明可能であることです。たとえば、「サポート担当者はメールアドレス全体を見られない」「本番DBに直接接続できるユーザーは承認済みの運用者のみ」「UNMASK付与はチケット承認が必要」「権限変更は監査ログで追跡している」といった形で、運用まで含めて説明できる状態を目指します。
優先順位付きチェックリスト
最後に、Azure SQL / SQL ServerでDDMを使う組織が、すぐに着手すべき項目を優先度順に整理します。
| 優先度 | 実施項目 | 完了の目安 |
|---|---|---|
| 高 | DDM対象列を sys.masked_columns で一覧化する | 対象DBごとにマスク列一覧がある |
| 高 | UNMASK、CONTROL、db_owner、sysadmin相当の権限者を棚卸しする | 業務上不要な高権限が削除されている |
| 高 | 本番DBへの直接接続ユーザーを確認する | アドホッククエリ可能なユーザーが把握されている |
| 高 | 権限変更とマスク変更の監査を有効にする | ログ保存先と確認担当が決まっている |
| 中 | RLSやビューで行・列の公開範囲を絞る | 業務ロールごとに見えるデータが定義されている |
| 中 | Always Encryptedが必要な列を選定する | 管理者にも見せない列が分類されている |
| 中 | BI、ETL、CSV、非本番環境へのデータ移動を確認する | 移動先ごとの平文アクセス可否が分かる |
| 低 | 設計書・監査資料の表現を修正する | DDMの限界と補完策が明記されている |
| 低 | 定期レビューの頻度を決める | 四半期またはリリース前後で見直す運用がある |
DDMの見直しは、複雑なセキュリティプロジェクトにしなくても始められます。まずは「どの列をマスクしているか」「誰がマスクを解除できるか」「誰が本番DBで自由にクエリを実行できるか」の3点を確認してください。ここを可視化するだけでも、過剰権限や説明資料の誤りを見つけやすくなります。
まとめ
Microsoftの最新ガイダンスは、Dynamic Data Maskingを否定するものではありません。むしろ、DDMを正しい場所で使えば、アプリケーション改修を抑えながら、機密情報の偶発的な露出を減らせます。
ただし、DDMは暗号化ではなく、行単位のアクセス制御でもなく、高権限ユーザーからデータを隠す仕組みでもありません。Azure SQL / SQL ServerでDDMを使っている組織は、次の順でリスクを下げるのが現実的です。
- DDM対象列を棚卸しする
UNMASKと高権限ロールを最小化する- アドホッククエリによる推測リスクを抑える
- 監査ログで権限変更・マスク変更を追跡する
- RLS、Always Encrypted、ビュー、静的マスキングを用途ごとに使い分ける
- エクスポートや非本番環境へのデータ移動を別枠で管理する
DDMは「最後の防壁」ではなく、「見せすぎを防ぐための一層」です。今回のMicrosoftの更新をきっかけに、機能の有効・無効だけで判断せず、権限、監査、データ移動、説明責任まで含めて見直すことが、実務上の最短ルートになります。
コメント