DPIA と NIST の整合性

山崎行政書士事務所
9月12日
読了時間: 6分

— SP 800‑53 / 800‑37 / 800‑171 / CSF を軸に、Azure 実装へ落とす方法論 —

著者：山崎行政書士事務所クラウド法務・アーキテクチャ支援チーム

発行日：2025-09-12

要旨（Abstract）

DPIA（Data Protection Impact Assessment）は、法的根拠・必要性評価・リスク低減策・残留リスク受容を一体で回す運用プロセスである。NIST の SP 800‑53（統制カタログ）、SP 800‑37（RMF）、SP 800‑171（CUI 保護）、CSF（Cybersecurity Framework）は、DPIA の各工程に対して技術的統制と運用プロセスの標準化を提供する。Azure では、Microsoft Purview（可視化）／Azure Policy（強制）／Key Vault（鍵主権）／Defender for Cloud（評価）／Monitor & Sentinel（検知・証跡）／Storage Lifecycle & Backup（保持・削除）を束ね、「設計＝証跡」を満たす実装が可能である。本稿は、DPIA の工程 → NIST の条項 → Azure の機能を一対一に写像し、誤りやすいポイントの補正も含めて提示する。

1. DPIA（影響評価）の技術的実装：NIST との正準マッピング

1.1 リスク特定と評価（DPIA 冒頭工程）

NIST 対応：SP 800‑53 RA‑3（Risk Assessment）／RA‑5（Vulnerability Monitoring & Scanning）、SP 800‑37 RMF（Prepare→Categorize→Select）、CSF Identify（ID）群。
Azure 実装：
- Microsoft Purview：データカタログ・分類・系統の可視化（どの個人データがどこへ流れるか）。
- Defender for Cloud：構成評価・脆弱性・推奨事項の集約。
- Azure Policy：リージョン・公開設定・TLS・Private Link など強制（deny/audit/modify）。
- Evidence：Purview スキャン結果、Policy 準拠レポート、Defender の Secure Score と是正状況。

1.2 法的根拠に応じた最小化／分離

NIST 対応：SP 800‑53 SC‑7（Boundary Protection）／SC‑8（Transmission Confidentiality）／SC‑28（At‑Rest Protection）、AC ファミリ（最小権限）、DM‑2（Data Retention and Disposal：プライバシー）、CSF Protect（PR）群。
Azure 実装：Private Link／VNet 分離、AppGW(WAF)/FW、Storage/SQL 既定暗号＋CMK（Key Vault）、RBAC＋PIM（JIT 特権）で最小権限。
- 補足：暗号や境界制御は SC‑12（Cryptographic Key Management）（鍵管理）、SC‑13（Cryptographic Protection）（暗号使用）で裏付ける。

2. 暗号化・疑似匿名化：条項の正しい当てどころ

2.1 鍵主権と暗号の要件

NIST 対応：SP 800‑53 SC‑12/SC‑13/SC‑28/SC‑8、SP 800‑171 3.13.11（FIPS 準拠暗号の使用）、CSF PR.DS‑1（At‑Rest 保護）／PR.DS‑2（In‑Transit 保護）。
Azure 実装：
- Key Vault（BYOK/HSM）：鍵生成・保管・ローテ（≤12M）・Wrap/Unwrap/Sign の最小権限。
- SQL：TDE（保存暗号）＋**Always Encrypted（列）**でアプリ層平文を排除（必要列のみ）。
- Storage/Disks：既定暗号＋Customer‑Managed Key（CMK）、SAS/鍵の配布最小化。
- 通信：TLS 1.2/1.3、AppGW(WAF)、必要に応じ mTLS。
- FIPS：HSM/暗号モジュールは FIPS 140‑3 準拠のものを採用（信頼性の検収ライン）。

2.2 疑似匿名化・マスキング

NIST 対応：SP 800‑53 DM‑1/DM‑2（データ最小化・保持と廃棄：プライバシー）、SP 800‑122（PII 保護指針、疑似匿名化やトークン化の考え方）。
Azure 実装：
- Data Factory／Synapse／Databricksで取り込み前変換（HMAC/ペッパー・トークン化・列分割）。
- Purviewでラベル起点の変換ルール適用（取り込み経路で不可逆化）。
- Key Vaultで疑似匿名化キーを隔離（再識別は PIM の承認付き JIT のみ）。

注：CSF のPR.DS‑1/2が保存・転送暗号の本体であり、**PR.DS‑5（データ流出対策）**は暗号そのものではない。条項の当て先を取り違えないこと。

3. データライフサイクル：保持・削除・アーカイブの制度化

3.1 保持・廃棄の統制

NIST 対応：SP 800‑53 SI‑12（Information Management & Retention）＋DM‑2（Retention & Disposal：プライバシー）、CSF PR.DS‑2／PR.IP‑4（保持・廃棄の手順）。
Azure 実装：
- Storage Lifecycle：Hot→Cool→Archive→Delete の自動遷移。重要ログは Immutable（WORM）で改ざん耐性。
- SQL：PITR（短期）、LTR（長期）を業法・監査に沿って設定。
- Cosmos：TTL による自然消滅。Event Hubs は短期保持＋Capture→ADLS（WORM）で二段構え。
- Backup：Retention Policy を Evidence 化（なぜ何年保持かを規程と対照）。

3.2 媒体消去・復元不能化

NIST 対応：SP 800‑171 3.8.3（Media Sanitization）。
Azure 実装：クラウドの物理媒体は CSP 責務。利用者責務では論理削除＋鍵失効（Crypto‑shred）、TTL、Lifecycle Delete、退去時のエクスポート／削除証跡を Evidence Pack に残す。

注：「Purview の DLP がデータを削除する」という理解は誤り。Purview は発見・分類・系統が主で、削除はストレージ／DB 側のポリシーや関数処理で実行する。

4. データ主体の権利（開示・訂正・消去）とアクセス統制

4.1 権利行使の条項当て

NIST 対応（正準）：SP 800‑53 のプライバシー系統制（IP‑2：Individual Access／IP‑3：Redress／TR：Transparency／UL：Use Limitation 等）。
- ※IR‑4（Incident Handling）は侵害対応であり、**DSR（開示・消去等）**の条項ではない。
Azure 実装：
- Azure Functions＋Queue/Logic Appsで DSR（消去・訂正・開示）の自動フローを構築。
- Monitor/Log Analytics に DSR 実行ログ（誰が／いつ／何を）を保全、WORM へ長期退避。
- Entra ID / Conditional Access / PIMで本人向けポータルや管理者操作を最小権限＋条件付きに限定。
- 外部ユーザー主体なら Entra External ID / Entra ID B2C の権限モデルで本人の自己アクセスを実装。

5. RMF（SP 800‑37）で DPIA を運用に“固定化”する

Prepare：役割・規程・データ移転方針・委託先台帳を整備（CSF Govern と接続）。
Categorize：FIPS 199 に準拠した影響度区分（機密・完全・可用）。
Select：SP 800‑53 のベースラインからテーラリング（法規・業法・契約を反映）。
Implement/Assess/Authorize：設計→実装→53Aの試験手順で Evidence を取得し、稼働認可。
Monitor：Policy 準拠率／Defender 所見／Sentinel インシデント／Purview 変化を四半期レビュー→DPIA 更新。

6. 代表的な整合マップ（DPIA 工程 → NIST → Azure）

┌───────────────┬─────────────────────────────┬────────────────────────────────────────────┐
│ DPIA 工程        │ NIST（主条項）                  │ Azure（主機能）                                  │
├───────────────┼─────────────────────────────┼────────────────────────────────────────────┤
│ 目的/範囲/根拠     │ CSF Govern / SP800‑53 PL/PM    │ 規程・台帳・契約（SCC/DPA）を設計書にリンク              │
│ データ可視化       │ RA‑3 / CSF Identify            │ Purview（分類・系統・スキャン）                        │
│ リスク評価         │ RA‑3/RA‑5 / RMF Select         │ Defender for Cloud、Policy 準拠、脆弱性スキャン           │
│ 保護（暗号/分離）   │ SC‑12/13/28/8 / AC / PR.DS‑1/2 │ Key Vault(BYOK/HSM)、TDE/Always Encrypted、Private Link   │
│ 最小化/保持/廃棄    │ SI‑12 / DM‑2 / PR.IP‑4         │ Storage Lifecycle、WORM、SQL LTR、Backup Retention        │
│ 権利行使（DSR）     │ IP‑2/IP‑3/UL/TR                │ Functions/Logic Apps（自動化）、LA/Sentinel（証跡）       │
│ 監査・検知          │ AU / CSF Detect                │ Monitor/Diagnostics→LA、Sentinel（相関・SOAR）           │
│ DR/継続            │ CP / CSF Recover               │ ASR/Backup、演習記録（RTO/RPO 実測）                    │
└───────────────┴─────────────────────────────┴────────────────────────────────────────────┘

7. 実装の最小パッケージ（そのまま Evidence に入る粒度）

Policy セット：リージョン固定、publicNetworkAccess=Disabled、minimumTlsVersion≥1.2、PE/PL 必須、Key Vault RBAC。
鍵台帳：キー種／用途／所有者／ローテ周期／失効手順（Crypto‑shred も明記）。
Purview 台帳：データセット分類・敏感情報タイプ・スキャン周期・検知率。
保持・削除：Lifecycle JSON、SQL PITR/LTR、Backup Retention、Cosmos TTL。
DSR Runbook：本人確認→対象特定→削除／訂正→例外（Legal Hold/保全）→ログ出力。
監査ログ：採取範囲・保持・WORM 設定・KQL（大量 DL／DSR 実行検知）・エクスポート手順。
DR 記録：演習頻度・RTO/RPO 実測・改善点・是正済み記録。