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

１. 高リスク処理時のDPIA実施

１－１. データリスク分析の技術項目

(A) データカテゴリー・ボリュームの特定

• データ分類ラベル:

  • 例: “Public”, “Internal”, “Confidential”, “Highly Confidential (PII)”など

  • Azure Purview（Microsoft Purview）やカスタムメタデータを用いて、機密データの検出・分類を自動化。

  • パラメータ例:

    • Purview で “Sensitive Info Types” を定義 (個人情報・クレジットカード番号・マイナンバー 等)。

    • データセット単位でラベル “PII: True” や “Critical: True” を付与。

(B) データフロー図 / アーキテクチャ設計

• 例: Azure ML + Azure Storage + Azure SQL

  • データの流れ: インジェスト (Data Factory) → 保管 (Blob / Data Lake) → 前処理 (Databricks / Synapse) → ML 推論 (Azure Machine Learning) → 結果書き込み (SQL DB)

  • パラメータ例:

    • Data Factory: パイプライン名 pii-ingestion-pipeline

    • Storage アカウント: mystorageaccount (VNet 経由アクセス必須、public endpoint 無効)

    • ML ワークスペース: “mlworkspace-pii” (Key Vault と連携し、機密データを暗号化)

(C) 技術的リスク評価

• 暗号化の実装状況 (At Rest, In Transit)

  • Key Vault (BYOK/HSM) の使用有無、SQL Always Encrypted, TDE (Transparent Data Encryption) など

• アクセス制御

  • Azure AD RBAC, Conditional Access, Privileged Identity Management (PIM)

• 監査ログ

  • Azure Monitor / Sentinel の連携状況、Log 保管期限 など

• 疑似匿名化 (Pseudonymization)

  • 敏感な個人情報はハッシュ化やトークン化を実施

  • パラメータ例: 「Email列 → SHA256 + ソルト」「リレーション分割」など

2. データライフサイクル管理

２－１. 保持期間・自動削除ポリシー

(A) Azure Storage ライフサイクル管理

• Lifecycle Management ポリシーにより、一定期間経過後に “Hot → Cool → Archive” 層へ自動移行、または削除。

  • パラメータ例:

    json

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

  • 設定例: “logs/” プレフィックスのファイルを 30 日でCoolに、180 日でArchiveに移動し、365 日経過で削除。

(B) Azure Backup / Recovery Services Vault

• バックアップポリシー:

  • 例: “Daily Full Backup, 保持期間: 30 日” / “Weekly Full Backup, 保持期間: 1 年”など

  • パラメータ例:

    • バックアップ ポリシー名: daily-backup-policy

    • Retention Range: 30日 / 180日 / 365日

• Application Consistent Backup:

  • SQL DB や VM の整合性を保つには VSS (Windows) やファイルシステムフリーズ (Linux) 連携が必要。

  • 高度な機密データの場合、バックアップ先のストレージ暗号化 (BYOK) も検討。

(C) Azure SQL Database / Managed Instance の自動削除ポリシー

• Automatic Retention: TDE 有効化 + PITR (Point in Time Restore) の保持期間をシステム要件に合わせて設定。

  • パラメータ例: 7 days ~ 35 days (PITR)

  • 長期保存(LTR)が必要な場合、LTR ポリシーで “月次バックアップを X 年間保持” などを設定。

２－２. データ削除・アーカイブフロー

(A) GDPR の「忘れられる権利」対応

• Data Subject Request (DSR) 対応を技術的に実装：

  • 例: ユーザーID をキーとして、SQL や Blob に保存された個人情報を特定 → 論理削除／物理削除処理

  • バックアップ/キャッシュ: すぐには削除できない場合、“データを復元可能に保つ法定要件” vs. “データ主体の削除要請” のバランスを考慮し、法務と連携して設定。

  • パラメータ例:

    • “UserDeletionFunction” (Azure Functions)

      • トリガー: HTTP 要求 (認可後)

      • 操作内容: Cosmos DB / SQL DB / Blob などから該当キーのレコード削除 → Log Analytics へログ送信

      • 例外ケース: “RetentionPolicyActive=True” の場合は削除せずフラグのみ設定。法定期間満了後にバッチ削除。

(B) 疑似匿名化と再識別フロー

• 疑似匿名化: DB 上の “Name, Email” を別DBに分割し、ID (GUID) を紐付ける方式

• 再識別必要時: 厳格な権限コントロールの下、Key Vault 等でトークン・復号鍵を管理。

  • パラメータ例:

    • テーブルスキーマ: “personal_info_table” には “user_id, hashed_email, hashed_name” のみ格納

    • 復号キー: pii-reidentify-key を Key Vault Premium の “HSMバックエンド” に保管。

    • デフォルト権限: 誰も Sign/Verify/Unwrap ができない → 特権アカウントだけが Just-In-Time でキー操作権限を取得可 (Azure AD PIM)。

３. サポーティング技術とパラメータ例

３－１. Azure Policy & Purview (データガバナンス)

(A) Azure Policy

• 機密データ保護のポリシー:

  • “すべての Storage アカウントに TLS 1.2 を強制”

  • “Public Network Access = Disabled” で機微データ用ストレージをインターネットから遮断

• パラメータ例:

  json

  { "if": { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, "then": { "effect": "deny", "details": { "requirements": [ { "field": "Microsoft.Storage/storageAccounts/enableHttpsTrafficOnly", "equals": true } ] } } }

  • 適用範囲: Subscription / Resource Group

  • 違反リソースがあれば作成・更新を拒否 or 監視

(B) Microsoft Purview (旧 Azure Purview)

• データカタログ＆リネージュ:

  • 自動スキャンで DB / Storage / BIツール などにある PII 情報を検出し、可視化する。

• パラメータ例:

  • Purview アカウント: “purview-pii-management”

  • スキャンスケジュール: 週 1 回 / 月 1 回

  • センサ: “Azure SQL Connector”, “Azure Blob Connector”

  • 分類: “PersonalData”, “EmailAddress”, “TaxNumber” etc.

３－２. ログ・監査トレイル

(A) Azure Monitor / Azure Sentinel

• 取りこぼしなくログを集約: Activity Log / Diagnostic Log / SQL Audit Log / Key Vault Log

  • パラメータ例:

    • Log Analytics Workspace 名: “law-prod-pii-region1”

    • データ保持期間: 90 日 ホット + 1 年 アーカイブ

    • Sentinel Rule: 「異常な場所からの大量データダウンロードを検知 → アラート＆自動ブロック」

• DSR（削除要求）操作ログのトレース:

  • 誰がいつ「ユーザー削除関数」を実行したか、成功/失敗ログを残す。

  • 監査時に提出できるよう長期保管ポリシーを設定。

４. DPIA フローとの連携

1. 技術的リスク整理 → 法務部に提供

   • 新規システム導入 (ML, Big Data 分析) 時に、データフロー図・暗号化方式・RBAC 設計などを一覧化。

   • DPA（Data Processing Addendum）や SCC（Standard Contractual Clauses）の範囲と矛盾がないか確認し、法務部へ共有。

2. DPIA ドキュメント作成

   • 上記技術情報を踏まえ、目的・リスク・対策・残留リスクを法務部が文書化。

   • 監査機関やコンプライアンス委員会の承認を得る際、Key Vault 設定スクリーンショットやLifecycle Management ポリシーなどを証拠資料として提示。

3. 定期レビュー・改善

   • DPIA は一度きりで終わらず、システム更新やデータ取り扱い範囲が変わるたびに再評価。

   • Azure Policy / Purview レポートで変更点を検知 → 法務部と連携して DPIA 更新。

５. まとめ

５－１. 技術的ポイントのおさらい

1. 高リスク処理には: Azure 上でのデータフローを明確化し、

   • 暗号化 (At Rest/In Transit)

   • 疑似匿名化

   • RBAC / Key Vault を組み合わせて機微データを保護。

2. データライフサイクル:

   • Retention/Deletion ポリシー をストレージやバックアップ設定に落とし込み、法的要件（保管義務期間、忘れられる権利等）と整合。

   • Azure Policy、Lifecycle Management、バックアップ ポリシー、DSR 用バッチ処理／関数などを連携。

3. ログ管理と監査対応:

   • Log Analytics / Sentinel で一元的に監査証跡を収集・長期保管。

   • DSR 実行ログやエラーログも含め、どの担当者が何を操作したかを追跡できるようにする。

５－２. 運用フローとの統合

1. IT部門 → 法務部: 技術仕様、セキュリティ設定、リスク箇所をドキュメント化。

2. 法務部 → IT部門: DPIA の結果から導かれる制限事項（BYOK 必須、海外リージョン使用制限、Retention 期間など）をシステムに反映。

3. 継続的レビュー: システム更新や機能追加のたびに“DPIA 再評価 + 既存 Azure 設定の見直し”を実施。

これらを行うことで、GDPR のDPIA要件や国内外の個人情報保護規制に対応しながら、Azure 環境での機密データ処理を安全かつ効率的に運用可能となります。