GDPR エンジニアリング スキル

エンジニア、アーキテクト、DevOps、技術リーダー向けの実践的 GDPR リファレンス。 CNIL 開発者ガイダンスおよび GDPR 第 5、25、32、33、35 条に基づいています。

黄金ルール： 少なく収集する。少なく保存する。少なく公開する。少なく保持する。

詳細については、references/ 内のリファレンスファイルを参照してください：

• references/data-rights.md — ユーザー権利エンドポイント、DSR ワークフロー、RoPA
• references/security.md — 暗号化、ハッシング、シークレット、匿名化
• references/operations.md — クラウド、CI/CD、インシデント対応、アーキテクチャパターン

---

1. GDPR の基本原則（第 5 条）

原則	エンジニアリング責務
適法性、公正性、透明性	RoPA 内のすべての処理活動について法的根拠を記録する
目的の制限	目的 A のために収集されたデータは、新しい法的根拠がない限り、目的 B に再利用されてはいけない
データ最小化	本日のビジネス上の必要性が文書化されたフィールドのみ収集する
正確性	更新エンドポイントを提供し、下流ストアに修正を伝播させる
保存制限	スキーマ設計時に TTL を定義する—その後は定義しない
完全性と機密性	保存中および転送中に暗号化し、アクセスを制限・監査する
アカウンタビリティ	コンプライアンスの証拠を維持し、RoPA を DPA 検査用に常に準備する

---

2. デザイン・バイ・デフォルト プライバシー

必須

• 個人データを保持するすべてのテーブルに作成時点で CreatedAt と RetentionExpiresAt を追加する。
• すべてのオプショナルデータ収集をデフォルトでオフにする。ユーザーがオプトインする。デフォルトオンの設定からのオプトアウトは決してない。
• 高リスク処理（生体認証、健康データ、大規模なプロファイリング、継続的な監視）を構築する前にDPIA を実施する。
• 新しい処理活動を導入する機能ごとにRoPA を更新する。
• データが流れる前に、すべてのサブ処理者とDPA に署名する。

禁止事項

• 文書化された法的根拠なしで新しいデータ収集機能をリリースする。
• 明示的な同意なしに、デフォルトでアナリティクス、トラッキング、またはテレメトリを有効にする。
• RoPA に記載されていないシステムに個人データを保存する。

---

3. データ最小化

必須

• すべての DTO/モデルフィールドを具体的なビジネス上の必要性にマッピングする。文書化されていないフィールドを削除する。
• 作成、読み取り、更新用に別の DTO を使用する—同じオブジェクトを再利用しない。
• 呼び出し元が見ることを許可されたものだけを返す—レスポンス投影を使用する。
• エッジで機密値をマスクする：カード番号に対して完全な値ではなく ****1234 を返す。
• デフォルトのリスト/検索投影から機密フィールド（DOB、国家 ID、健康）を除外する。

禁止事項

• 個人データを含む可能性のあるフルリクエスト/レスポンスボディをログに記録する。
• URL パスセグメントまたはクエリパラメータに個人データを含める（CDN ログ、ブラウザ履歴）。
• 明示的な法的根拠なしに dateOfBirth、国家 ID、または健康データを収集する。

---

4. 目的の制限

必須

• コードコメントと RoPA に、すべての処理活動の目的を記録する。
• データを二次的な目的に再利用する前に、新しい法的根拠を取得するか、互換性分析を実施する。

禁止事項

• サービス提供のために収集された個人データを、明示的な同意なしに広告ネットワークと共有する。
• サポートチケットの内容を、別の法的根拠とユーザー通知なしに ML モデルのトレーニングに使用する。

---

5. 保存制限と保持期間

必須

• 個人データを保持するすべてのテーブルは、定義された保持期間を持たなければならない。
• スケジュール設定されたジョブ（Hangfire、cron）を通じて保持期間を自動的に強制する—手動プロセスは決してない。
• 保持期間が終了したときにデータを匿名化または削除する—期限切れのデータを本番環境に無言で放置しない。

推奨デフォルト

データタイプ	最大保持期間
認証 / 監査ログ	12～24 ヶ月
セッション / リフレッシュトークン	30～90 日
メール / 通知ログ	6 ヶ月
非アクティブなユーザーアカウント	最後のログイン後 12 ヶ月 → 通知 → 削除
支払いレコード	税法で必要とされる通り（7～10 年）、最小化
アナリティクスイベント	13 ヶ月

推奨事項

• RetentionExpiresAt カラムを追加する—挿入時に計算する。
• ソフト削除（DeletedAt）を使用し、削除リクエストウィンドウ後（30 日）にハード削除をスケジュールする。

禁止事項

• 「後で役立つかもしれない」という理由で個人データを無期限に保持する。

---

6. API 設計ルール

必須

• URL パスまたはクエリパラメータに個人データを含めてはいけない。
  • GET /users/{userId}
• 個人データを返すまたは受け入れるすべてのエンドポイントを認証する。
• JWT から機能するユーザーの ID を抽出する—リクエストボディから抽出しない。
• すべてのリソースの所有権を検証する：if (resource.OwnerId != currentUserId) return 403。
• UUID または不透明な識別子を使用する—パブリックリソース ID として連続した整数は使用しない。

推奨事項

• 機密エンドポイント（ログイン、データエクスポート、パスワードリセット）にレート制限を適用する。
• Referrer-Policy: no-referrer と明示的な CORS 許可リストを設定する。

禁止事項

• スタックトレース、内部パス、またはデータベースエラーを API レスポンスで返す。
• 認証 API で Access-Control-Allow-Origin: * を使用する。

---

7. ロギングルール

必須

• アプリケーションログで IP を匿名化する—最後のオクテット（IPv4）または最後の 80 ビット（IPv6）をマスクする。
  • 192.168.1.xxx
• ログに含めてはいけないもの：パスワード、トークン、セッション ID、認証情報、カード番号、国家 ID、健康データ。
• PII が存在する可能性があるフルリクエスト/レスポンスボディをログに記録しない。
• ログ保持期間を強制する—定義された期間後に自動的に削除する。

推奨事項

• データではなくイベントをログに記録する："User {UserId} updated email" ではなく "Email changed from a@b.com to c@d.com" ではなく。
• 構造化ロギング（JSON）を使用し、userId を内部識別子として使用し、メールアドレスではない。
• 監査ログ（機密アクセス、管理者アクション）をアプリケーションログから分離する—異なる保持期間と ACL。

---

8. エラーハンドリング

必須

• ジェネリックエラーメッセージを返す—スタックトレース、内部パス、DB エラーを公開しない。
  • "Column 'email' violates unique constraint on table 'users'"
  • "A user with this email address already exists."
• すべてのエラーレスポンスにProblem Details（RFC 7807） を使用する。
• 相関 ID でサーバー側の完全なエラーをログに記録し、相関 ID だけをクライアントに返す。

禁止事項

• エラーレスポンスにファイルパス、クラス名、または行番号を含める。
• エラーメッセージに個人データを含める（例：「ユーザー john@example.com が見つかりません」）。

---

9. 暗号化（要約—詳細は references/security.md を参照）

スコープ	最小標準
標準的な個人データ	AES-256 ディスク/ボリューム暗号化
機密データ（健康、財務、生体認証）	AES-256 カラムレベル + KMS 経由のエンベロープ暗号化
転送中	TLS 1.2+（1.3 推奨）; HSTS 強制
キー	HSM バック KMS; DEK を年 1 回ローテーション

禁止事項 TLS 1.0/1.1、null 暗号スイート、またはハードコードされた暗号化キーを許可する。

---

10. パスワードハッシング

必須

• Argon2id（推奨）またはbcrypt（コスト ≥ 12）を使用する。MD5、SHA-1、SHA-256 は決して使用しない。
• パスワードごとに一意のソルトを使用する。ハッシュのみを保存する。

禁止事項

• どのような形式でもパスワードをログに記録する。URL でパスワードを送信する。リセットトークンをプレーンテキストで保存する。

---

11. シークレット管理

必須

• すべてのシークレットを KMS に保存する：Azure Key Vault、AWS Secrets Manager、GCP Secret Manager、または HashiCorp Vault。
• pre-commit フック（gitleaks、detect-secrets）を使用してシークレットコミットを防止する。
• 開発者のオフボーディング、年間スケジュール、または疑わしい漏洩時にシークレットをローテーションする。

.gitignore に含める必須項目： .env、.env.*、*.pem、*.key、*.pfx、*.p12、secrets/

禁止事項

• シークレットをソースコードにコミットする。シークレットをプレーンテキストの環境変数デフォルトとして保存する。

---

12. 匿名化と仮名化（要約—詳細は references/security.md を参照）

• 匿名化 = 不可逆 → GDPR スコープ外に該当。保持レコードに使用。
• 仮名化 = キーで可逆 → 依然として個人データ、リスク軽減。
• ユーザーを削除するときに、削除する代わりに保持する必要があるレコード（財務、監査）を匿名化する。
• 仮名化キーを KMS に保存する—仮名化されたデータと同じデータベースには保存しない。

禁止事項 リンケージ攻撃による再特定が可能な場合、データを「匿名化」と呼ぶ。

---

13. 偽データを使用したテスト

必須

• dev、ステージング、CI 環境で本番個人データを使用してはいけない。
• 本番 DB バックアップを非本番環境に復元する前に PII をスクラブしない。
• 合成データジェネレータを使用：Bogus（.NET）、Faker（JS/Python/Ruby）。
• すべてのテストメールアドレスに @example.com を使用する。

---

14. アンチパターン

アンチパターン	正しいアプローチ
URL の PII	パブリック識別子として不透明な UUID
フルリクエストボディのロギング	構造化イベントメタデータのみ
「永遠に保持」スキーマ	設計時に定義された TTL
dev/test の本番データ	合成データ + スクラビングパイプライン
チーム全体での共有認証情報	個別アカウント + RBAC
ハードコードされたシークレット	KMS + シークレットマネージャー
認証 API の Access-Control-Allow-Origin: *	明示的な CORS 許可リスト
プロフィールデータとのコンセント保存	専用同意ストア
GET クエリパラメータの PII	POST ボディまたは認証セッション
URL のパブリック連続整数 ID	UUID
準識別子を持つ「匿名化」データ	k-匿名性を適用、リンケージ耐性テスト
EEA 外のバックアップリージョン混在	バックアップジョブの明示的なリージョンロックダウン

---

15. PR レビューチェックリスト

データモデル

• すべての新しい PII カラムに文書化された目的と保持期間がある。
• 機密フィールド（健康、財務、国家 ID）はカラムレベル暗号化を使用している。
• パブリック対応識別子として連続した整数 PK がない。

API

• URL パスまたはクエリパラメータに PII がない。
• 個人データを返すすべてのエンドポイントが認証されている。
• 所有権チェックが存在する—ユーザーは別のユーザーのリソースにアクセスできない。
• レート制限が機密エンドポイントに適用されている。

ロギング

• パスワード、トークン、認証情報がログに記録されていない。
• IP が匿名化されている（最後のオクテットがマスクされている）。
• PII が存在する可能性のあるフルリクエスト/レスポンスボディがログに記録されていない。

インフラストラクチャ

• パブリックストレージバケットまたはパブリック IP データベースがない。
• 新しいクラウドリソースが DataClassification でタグ付けされている。
• 新しいストレージリソースで保存中の暗号化が有効になっている。
• データストレージ用の新しい地理的リージョンが EEA 準拠またはサポート標準契約句（SCC）でカバーされている。

シークレットと CI/CD

• ソースコードまたはコミットされたconfig ファイルにシークレットがない。
• 新しいシークレットが KMS と秘密インベントリドキュメントに追加されている。
• CI/CD シークレットがパイプラインログでマスクされている。

保持期間と削除

• 保持期間強制ジョブまたはポリシーが新しいデータストアまたはフィールドをカバーしている。
• 削除パイプラインが新しいデータストアをカバーするように更新されている。

ユーザー権利とガバナンス

• データエクスポートエンドポイントが新しい個人データフィールドを含んでいる。
• 新しい処理活動が導入された場合、RoPA が更新されている。
• 新しいサブ処理者が署名済み DPA を持ち、RoPA エントリがある。
• 変更が高リスク処理を含む場合、DPIA がトリガーされている。

---

黄金ルール： 少なく収集する。少なく保存する。少なく公開する。少なく保持する。

収集しない個人データの 1 バイトは、失う可能性のない、 侵害される可能性のない、責任を負わない可能性のある 1 バイトです。

---

CNIL 開発者 GDPR ガイダンス、GDPR 第 5、25、32、33、35 条、 ENISA、OWASP、NIST エンジニアリングベストプラクティスに基づいています。