DPIA（データ保護影響評価）とライフサイクル（技術的側面）

— Azure 実装に落ちるパラメータ・証跡化・運用統合の実務論 —

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

要旨（Abstract）

DPIA は「文書を作る行為」ではなく、データ流と統制の設計・コントロールの強制・証跡の蓄積を通じて残留リスクを意思決定できる状態を生むプロセスである。Azure では、Microsoft Purview による分類・系統可視化、Key Vault＋CMK/BYOK による鍵主権、Private Link／WAF／RBAC／PIM による技術統制の強制、Azure Monitor／Sentinel による検知と証跡化、Storage Lifecycle／Backup／SQL LTR／Cosmos TTL 等による保持／削除の自動化を束ねることで、DPIA の計画—実装—証拠を同一の運用系で回せる。とりわけ ML（高リスク処理）では、**疑似匿名化・最小化・リーク対策（MI/属性推定耐性）**を設計段階で組み込むことが要諦となる。

1. 高リスク処理と DPIA：設計言語としての分解

1.1 リスク分解の軸（データ×流通×統制×証跡）

• データの性質：機微度（PII/PHI/CARD…）、量（件数/頻度/ビットレート）、保持期間。

• 流通：収集→保管→加工→学習/推論→可視化/外部提供→アーカイブ／削除。

• 統制：暗号化（At‑Rest/Transit/アプリ層）、鍵主権、ネットワーク分離、最小権限、疑似匿名化。

• 証跡：監査ログの網羅、改ざん耐性（WORM）、検索可能性（KQL）、Runbook/Playbook による再現性。

1.2 代表アーキテクチャ（概念）

[Data Sources] ─┬─> Data Factory (pii-ingestion) ──> ADLS Gen2(Private Link, PEA, CMK)
                 │
                 ├─> Event Hubs (ingest) ──> Databricks/Synapse (PII transform→tokenize)
                 │
                 └─> Purview (scan/classify/lineage)
                                               │
Azure ML Workspace (private, no-PIP) <── Key Vault (HSM/BYOK)
   ├─ Feature Store / Registry (PII最小化)
   └─ Online Inference (AppGW/WAF, mTLS, CA)
                                               │
SQL DB/MI (TDE/Always Encrypted) <── Results
                                               │
Log Analytics/Sentinel (DSR/削除実行/大量DL検知, WORM)

2. DPIA に載せる「技術パラメータ」：そのまま設計書に転記できる粒度

2.1 分類・ボリューム

• 分類ラベル：Public/Internal/Confidential/HighlyConfidential(PII) を最低限セット。

• Purview 設定（例）

  • Sensitive Info Types：EmailAddress, TaxNumber, CreditCard, NationalID（カスタム追加可）

  • アカウント：purview-pii-management／スキャン：週1回／接続：Azure SQL, ADLS, Power BI

  • メタタグ：PII=True, Critical=True, Residency=JP/EU

2.2 データフロー（命名規則・強制設定）

• Data Factory パイプライン：pii-ingestion-pipeline（プライベート連携）

• Storage アカウント：st-pii-prd（publicNetworkAccess=Disabled, minimumTlsVersion=TLS1_2, allowBlobPublicAccess=false, Private Endpoint）

• ML ワークスペース：mlws-pii-prd（VNet 統合、キーは Key Vault（HSM/BYOK）、Artifacts は PII 排除）

2.3 技術統制の必須セット

• 暗号化：At‑Rest＝既定暗号＋CMK（Key Vault）。アプリ層＝Always Encrypted（列）／HSM 鍵（BYOK）。

• 通信：TLS1.2/1.3、AppGW(WAF)＋必要に応じ mTLS。

• 鍵主権：Rotation=12M, KeyOps=Wrap/Unwrap/Signのみ, Access=RBAC最小, Audit=LA/Sentinel。

• アクセス：Entra ID の MFA＋条件付きアクセス、PIM による JIT 特権、RBAC はグループ割当。

• 疑似匿名化：HMAC-SHA256（Key Vault の per‑tenant 秘密鍵でペッパー）、トークン化／FPE、リレーション分割。

• ログ：Activity／Sign‑in／Diagnostic（KV/Storage/SQL/AppGW/Firewall）を LA に集約し、Blob WORM へロングターム退避。

• ノイズ付与（ML）：学習時に差分プライバシ（DP）やサンプリング、メンバーシップ推測耐性の評価を工程化。

3. データライフサイクル：保持・削除・アーカイブを自動化する

3.1 Storage ライフサイクル（例：ログ系）

{
  "rules": [{
    "name": "MoveToCoolAfter30Days",
    "enabled": true,
    "type": "Lifecycle",
    "definition": {
      "filters": { "prefixMatch": ["logs/"] },
      "actions": {
        "baseBlob": {
          "tierToCool":    { "daysAfterModificationGreaterThan": 30  },
          "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
          "delete":        { "daysAfterModificationGreaterThan": 365 }
        }
      }
    }
  }]
}

• Immutable（WORM）：監査・DSR 証跡は WORM＋リージョン内アーカイブへ。

• Legal Hold と DSR：保持義務が競合する場合は Legal Hold を優先し、解除後に削除バッチを再実行。

3.2 SQL Database / MI の保持

• PITR：7–35 日 で障害復旧窓を確保。

• LTR：月次バックアップを 3–7 年 など監査要件に沿って設定。

• Always Encrypted（Secure Enclave）：列単位で平文非保持（再識別は厳格承認＋PIM）。

3.3 Cosmos DB / Event Hubs / ADX 等

• Cosmos TTL：テーブル（コンテナ）に ttlSeconds を設定し、自然消滅型に。

• Event Hubs：保持は短期（数日〜2週間）＋Capture→ADLS（WORM）で再処理と証跡を二段構え。

• Kusto（ADX）：ホット短期＋長期アーカイブを定義、個人属性カラムは取り込み前変換でマスキング。

4. DSR（削除・開示）と再識別の統制

4.1 技術フロー（概念）

User Request → DSR Intake (Portal/API) → Queue
  → Function "UserDeletionFunction" (JITで起動)
     → Cosmos/SQL/Blob をキーで横断削除/匿名化
     → バックアップ/LTR はポリシー到来で消滅（フラグ記録）
     → すべての操作を LA に記録（WORMへ転送）

• 例外管理：RetentionPolicyActive=True のときは論理削除フラグのみ立てる。法定満了でバッチ削除。

• 再識別：Key Vault Premium（HSM）で復号鍵を隔離。デフォルトは誰も Unwrap できず、PIM の承認付きで一時付与。

4.2 ログと検知の最小 KQL

大量ダウンロード検知（例）

AzureDiagnostics
| where Category in ("StorageRead","StorageAuditLogs","AppGatewayAccessLog")
| summarize bytes=sum(tolong(RequestSize_s)), hits=count() by CallerIPAddress, bin(TimeGenerated, 1h)
| where bytes > 50GB or hits > 10000

DSR 実行監査（例）

AzureDiagnostics
| where OperationName has "UserDeletionFunction"
| project TimeGenerated, CorrelationId, ResultType, Caller, Resource, Message

5. 強制の仕組み：Policy / Private / DCR 変換 / IaC

5.1 Azure Policy（抜粋：TLS と公開禁止）

{
  "properties": {
    "displayName": "Enforce TLS1.2+ and no public access for Storage",
    "policyRule": {
      "if": { "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
      "then": {
        "effect": "deny",
        "details": {
          "conflictEffect": "audit",
          "conditions": [
            { "field": "Microsoft.Storage/storageAccounts/minimumTlsVersion", "notEquals": "TLS1_2" },
            { "field": "Microsoft.Storage/storageAccounts/publicNetworkAccess", "equals": "Enabled" },
            { "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": true }
          ]
        }
      }
    }
  }
}

5.2 Storage のセキュア既定（Bicep 概念）

resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'st-pii-prd'
  location: 'japaneast'
  sku: { name: 'Standard_GZRS' }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    publicNetworkAccess: 'Disabled'
    networkAcls: { defaultAction: 'Deny' }
    allowSharedKeyAccess: false
    encryption: { keySource: 'Microsoft.Keyvault' }
    immutableStorageWithVersioning: { enabled: true }
    deleteRetentionPolicy: { enabled: true, days: 7 }
  }
}

5.3 取り込み前に PII を落とす（DCR 変換の概念）

• 目的：ログ到達前に email, tax_id 等を除去／ハッシュ化。

• 指針：transformKql 相当の前処理で必ず不可逆化し、原本は WORM に保管。

6. ML（高リスク処理）の特記事項

• データ最小化：Feature Store には業務に不要な PII を残さない。識別子が必要な場合は安定トークン（HMAC）で代替。

• リーク防止：学習／検証／推論のデータ境界を明確に。テストセットへの PII 混入を Purview とスキーマ検証で検出。

• 攻撃耐性：メンバーシップ推測／モデル反転のリスク評価を定常化（スコアリングして Evidence Pack に格納）。

• 実験の追跡：MLflow/Model Registry のメタにデータバージョン／分類ラベルを反映。モデル配布は Private Link 経由。

7. DPIA 文書と Evidence Pack：技術—法務のハンドオフ標準

7.1 DPIA テンプレに載せる「技術項目」

1. データ目録（分類・件数・保持・所在・鍵所在）

2. データ流（入出力・中間処理・第三者提供・越境）

3. 統制（暗号・鍵主権・ネットワーク・ID/RBAC・疑似匿名化）

4. ログ（取得範囲・保持・改ざん耐性・検索性）

5. DSR（削除／開示の T‑T 流程・例外管理）

6. DR（RTO/RPO と演習の頻度・結果）

7. 残留リスク（受容／低減／移転の判断根拠）

7.2 Evidence Pack（監査提出パッケージ）

• 設計図（リージョン・PE・鍵・データ流）

• Policy/Template/Bicep（JSON一式）・割当台帳

• RBAC/PIM 台帳（JIT 履歴）

• DCR 変換と KQL ライブラリ

• WORM 設定・保持方針・実データ件数の証跡

• Sentinel ルール・Playbook・インシデント記録

• DR 手順・演習結果（RTO/RPO 実測）

• 法務書類（DPA/SCC）と設計書クロスリファレンス

8. 運用統合：レビューとガードレールで「回し続ける」

• 四半期レビュー：Purview レポート／Policy 違反／Sentinel 所見／DSR 統計をDPIA 更新へ反映。

• 変更管理：新規機能・新規データ源はDPIA トリガ。IaC で差分をレビューし、監査ログに残す。

• SLO/KPI：常設特権＝0、診断設定適用率＝100%、重大ログ WORM 保護＝100%、DR 演習＝四半期1回、DSR 処理 SLA＝規程以内。

• 越境移転：DR／バックアップ複製先・鍵位置・SCC 等を台帳に可視化し、Privacy Notice と整合させる。

9. 山崎行政書士事務所のご支援（PR）

法務（APPI/GDPR/SCC/DPA）× 技術（Purview/Key Vault/Policy/DCR/Sentinel/ASR）を同じ設計書と Evidence Packに束ね、監査にそのまま出せる品質で納品します。

• 要件整理→DPIA 設計→実装→証跡整備→監査同席まで伴走。

• ML／高リスク処理向けに疑似匿名化・DP・再識別統制のテンプレと試験書式を用意。

• 90 日ロードマップで Baseline を立ち上げ、Mission‑Critical（水準：HSM＋二重暗号化／mTLS／DR 演習）へ段階拡張。

• 金融・医療・製造の高規制案件で得た設計パターンと問答集を、貴社向けに最小改変で適用。

付録A：パラメータ・チェックシート（抜粋）

[分類]
  Purview: SensitiveInfoTypes=Email,TaxID,CreditCard,NationalID(+Custom)
  Tags: PII=True, Critical=True, Residency=JP/EU

[鍵]
  Key Vault: SKU=Premium(HSM), Rotation=12M, KeyOps=Wrap/Unwrap/Sign
  Access: RBAC最小、PIM必須、Diagnostic→LA/Sentinel

[Storage]
  publicNetworkAccess=Disabled, allowBlobPublicAccess=false, minimumTlsVersion=TLS1_2
  immutableStorageWithVersioning=enabled, deleteRetentionPolicy(days=7)
  Lifecycle: logs/ 30d→Cool, 180d→Archive, 365d→Delete

[SQL]
  TDE=On, AlwaysEncrypted(必要列), PITR=14d, LTR=月次×5年
  DSR: Key(UserID)で論理/物理削除、バックアップは法定満了後バッチ

[ネットワーク]
  Private Endpoint(ADLS/SQL/KV/ML), AppGW(WAF:Prevention), mTLS(必要時)
  UDRで外向きはFW、Egress審査

[ID/RBAC]
  MFA+条件付アクセス、PIM(JIT/承認/記録)、個人割当禁止、グループ割当

[ログ]
  Activity/Sign-in/Diagnostic 全収集→LA 90dホット＋1yアーカイブ
  重要ログは Blob WORM、KQLでDSR/大量DL検知

[ML]
  Feature最小化、PIIはHMACトークン化、Registryにデータ版数/分類
  モデルのMI/反転リスク評価を Evidence に保存

参照リンク集

DPIA / 規制・ガイダンス

https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-data-protection-impact-assessment-dpia-and-dpia_enhttps://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments/https://gdpr-info.eu/art-35-gdpr/

Azure データガバナンス / 分類

https://learn.microsoft.com/azure/purview/overviewhttps://learn.microsoft.com/azure/purview/sensitivity-labels

暗号化・鍵主権

https://learn.microsoft.com/azure/key-vault/general/https://learn.microsoft.com/azure/key-vault/keys/byok-specificationhttps://learn.microsoft.com/azure/azure-sql/database/always-encrypted-overviewhttps://learn.microsoft.com/azure/azure-sql/database/transparent-data-encryption-tde-overview

ネットワーク / WAF / Private Link

https://learn.microsoft.com/azure/private-link/private-link-overviewhttps://learn.microsoft.com/azure/application-gateway/overview

監査・ログ・SIEM

https://learn.microsoft.com/azure/azure-monitor/https://learn.microsoft.com/azure/sentinel/https://learn.microsoft.com/azure/storage/blobs/immutable-policy-configure-versioning

ライフサイクル・保持・削除

https://learn.microsoft.com/azure/storage/blobs/lifecycle-management-overviewhttps://learn.microsoft.com/azure/backup/backup-overviewhttps://learn.microsoft.com/azure/azure-sql/database/long-term-retention-overviewhttps://learn.microsoft.com/azure/cosmos-db/time-to-live

ML とプライバシ（概念整理）

https://learn.microsoft.com/azure/machine-learning/concept-responsible-ml