mcpField
B
building-purpose-limitation-enforcement

building-purpose-limitation-enforcement

github.com/mukul975安全32339 次安装32 周前更新
代码仓库

关于 building-purpose-limitation-enforcement

面向数据保护与工程团队的 GDPR 目的限制实施指南,说明如何按处理目的标记数据、控制访问并评估用途兼容性。结合 OPA 策略和 Article 6(4) 因素描述执行流程。

主要功能

  1. 01数据采集时绑定处理目的
  2. 02按目的实施访问控制
  3. 03记录目的授权访问审计轨迹
  4. 04按 Article 6(4) 评估用途兼容性
  5. 05使用 OPA 编写策略

适用场景

  1. 01限制服务访问不匹配目的的数据
  2. 02审核将数据用于新目的的请求
  3. 03追踪目的标签覆盖与评估状态

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill building-purpose-limitation-enforcement

安装后在 Claude Code 中输入/building-purpose-limitation-enforcement确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

详细介绍

构建目的限制执行机制

概述

GDPR 第 5(1)(b) 条要求,个人数据应“为特定、明确且合法的目的而收集,且不得以与这些目的不相容的方式进一步处理”。这就是目的限制原则,是数据保护的基本原则之一。

控制者必须在收集时或之前明确目的(直接收集适用第 13(1)(c) 条,间接收集适用第 14(1)(c) 条)。后续为不同目的进行的任何处理,都需要新的合法依据,或者必须通过第 6(4) 条规定的兼容性评估。

第 29 条工作组关于目的限制的第 03/2013 号意见(WP203)提供了兼容性评估的详细指南,并确定了第 6(4) 条所编纂的五项关键因素。

第 6(4) 条兼容性评估因素

当控制者希望为不同于收集个人数据时所声明的目的而处理个人数据时,第 6(4) 条要求评估兼容性,并考虑以下因素:

因素第 6(4) 条引用评估问题
目的之间的关联第 6(4)(a) 条原始目的与新目的之间是否存在关联?
收集背景第 6(4)(b) 条控制者与数据主体之间是什么关系?数据主体有何合理预期?
数据性质第 6(4)(c) 条数据是否包含特殊类别数据(第 9 条)或刑事定罪数据(第 10 条)?
后果第 6(4)(d) 条进一步处理可能对数据主体造成哪些后果?
保障措施第 6(4)(e) 条是否采取了适当的保障措施,包括加密或假名化?

以下情况无需进行兼容性评估:

  • 处理基于同意(第 6(1)(a) 条)——可针对新目的获取新的同意
  • 处理基于欧盟或成员国法律,且该法律构成必要且相称的措施(第 6(4) 条最后一段)
  • 根据第 89(1) 条,为公共利益归档、科学或历史研究,或统计目的进行处理

按目的标记的数据架构

设计原则
  1. 在数据录入时绑定目的 — 每条数据记录在进入系统时都会标记其收集目的
  2. 基于目的的访问控制 — 按目的定义访问策略,而非仅按数据字段定义
  3. 目的审计跟踪 — 每次访问都会记录其获准使用的目的
  4. 目的到期 — 目的实现后,相关数据将开始进入保留期限倒计时
架构图
┌────────────────────────────────────────────────────────────┐
│                   Data Collection Points                    │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ Web Form │  │ API Call │  │ IoT Feed │  │ Partner  │  │
│  │ P:ONBRD  │  │ P:ANALYT │  │ P:MAINT  │  │ P:MARKET │  │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘  │
│       └──────────────┼──────────────┼──────────────┘       │
└──────────────────────┼──────────────┼──────────────────────┘
                       │              │
┌──────────────────────▼──────────────▼──────────────────────┐
│              Purpose Tagging Gateway                        │
│  ┌─────────────────┐  ┌─────────────────────────────────┐  │
│  │ Purpose Registry │  │ Tag Injection Middleware        │  │
│  │ (canonical IDs)  │  │ (attaches purpose + timestamp)  │  │
│  └─────────────────┘  └─────────────────────────────────┘  │
└──────────────────────────────┬─────────────────────────────┘
                               │
┌──────────────────────────────▼─────────────────────────────┐
│              Purpose-Partitioned Data Store                  │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ ONBRD    │  │ ANALYT   │  │ MAINT    │  │ MARKET   │  │
│  │ Partition│  │ Partition│  │ Partition│  │ Partition│  │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
└──────────────────────────────┬─────────────────────────────┘
                               │
┌──────────────────────────────▼─────────────────────────────┐
│              Purpose Enforcement Layer                       │
│  ┌─────────────────┐  ┌────────────────┐  ┌────────────┐  │
│  │ Policy Engine   │  │ Compatibility  │  │ Audit      │  │
│  │ (OPA / Cedar)   │  │ Assessor       │  │ Logger     │  │
│  └─────────────────┘  └────────────────┘  └────────────┘  │
└────────────────────────────────────────────────────────────┘
目的注册表架构

每项处理目的都以规范的元数据进行登记:

{
  "purpose_id": "PRP-ONBRD-001",
  "purpose_name": "Customer Account Onboarding",
  "description": "Collection and processing of personal data necessary to create and activate a customer account, verify identity, and establish the contractual relationship.",
  "lawful_basis": "Article 6(1)(b)",
  "data_categories": ["email", "display_name", "country_code", "identity_verification_result"],
  "controller": "Prism Data Systems AG",
  "retention_period_days": 2555,
  "retention_trigger": "account_closure",
  "compatible_purposes": ["PRP-SUPRT-001", "PRP-SECUR-001"],
  "incompatible_purposes": ["PRP-MARKET-001", "PRP-RESRCH-001"],
  "special_categories": false,
  "created_date": "2025-06-01",
  "last_reviewed": "2026-01-15",
  "review_cadence_days": 180,
  "owner": "product_team",
  "dpo_approved": true
}

按目的进行访问控制

使用 Open Policy Agent(OPA)实现策略即代码

基于目的的访问控制通过 OPA 策略实现,这些策略会根据目的注册表评估访问请求:

# Prism Data Systems AG — Purpose-Based Access Policy

# Rule: Access is granted only if the requesting service's declared purpose
# matches a purpose tag on the requested data record.

allow {
    input.action == "read"
    input.resource.purpose_tags[_] == input.requester.declared_purpose
    purpose_is_active(input.requester.declared_purpose)
    role_authorized_for_purpose(input.requester.role, input.requester.declared_purpose)
}

# Rule: Cross-purpose access requires a completed compatibility assessment
allow {
    input.action == "read"
    not input.resource.purpose_tags[_] == input.requester.declared_purpose
    compatibility_assessment_approved(input.resource.purpose_tags, input.requester.declared_purpose)
    purpose_is_active(input.requester.declared_purpose)
}

# Rule: Write operations must include a valid purpose tag
allow {
    input.action == "write"
    valid_purpose(input.resource.purpose_tag)
    input.requester.declared_purpose == input.resource.purpose_tag
}
角色-目的授权矩阵
角色ONBRDANALYTSUPRTMARKETSECURBILLING
入职服务读取/写入—————
分析流水线—读取————
支持 Agent读取—读取/写入——读取
营销自动化———读取——
安全运营读取读取读取读取读取/写入读取
计费服务读取————读取/写入

目的兼容性评估工作流

  1. 提交请求 — 服务负责人提交请求,申请将根据目的 A 收集的数据用于新的目的 B,并说明业务理由。

  2. 因素分析 — 数据保护办公室评估第 6(4) 条的五项因素:

    • 目的之间的关联(评分 1-5:1 = 无关联,5 = 密切相关)
    • 背景和预期(评分 1-5:1 = 出乎意料,5 = 完全符合预期)
    • 数据性质(评分 1-5:1 = 特殊类别,5 = 非敏感)
    • 后果(评分 1-5:1 = 严重,5 = 影响极小)
    • 保障措施(评分 1-5:1 = 无保障措施,5 = 全面保障)
  3. 评分 — 计算总分(范围为 5-25):

    • 20-25:兼容。批准,并提供标准文档记录。
    • 15-19:可能兼容。批准,但需采取额外保障措施(假名化、访问限制)。
    • 10-14:可能不兼容。需升级至 DPO 处理,并考虑进行 DPIA。
    • 5-9:不兼容。拒绝。需有新的合法依据或单独同意。
  4. 记录决定 — 将评估结果记录在目的注册表中,包括评估人员身份、日期、评分明细、条件和复核日期。

  5. 更新策略 — 如果获批,则更新 OPA 策略,以允许在有记录的条件下跨目的访问。

Prism Data Systems AG 的实施

目的注册表

Prism Data Systems AG 在其目的注册表中维护 14 个已登记目的:

目的 ID名称合法依据数据类别
PRP-ONBRD-001客户注册Art. 6(1)(b)email, display_name, country_code
PRP-AUTH-001身份验证Art. 6(1)(b)email, password_hash, mfa_token
PRP-BILLING-001账单和发票Art. 6(1)(b)billing_address, payment_method, vat_id
PRP-SUPRT-001客户支持Art. 6(1)(b)email, display_name, support_ticket_history
PRP-ANALYT-001产品分析Art. 6(1)(f)pseudonymized_user_id, feature_events, session_duration
PRP-MARKET-001直接营销Art. 6(1)(a)email, display_name, marketing_preferences
PRP-SECUR-001安全监控Art. 6(1)(f)ip_address, user_agent, login_events
PRP-LEGAL-001法律合规Art. 6(1)(c)transaction_records, consent_records
执行指标

Prism Data Systems AG 跟踪以下目的限制执行指标:

指标目标衡量方式
目的标签覆盖率100% 的记录带有有效目的标签的数据记录所占比例
被拦截的跨目的访问尝试未经评估的请求中 > 95%策略引擎拒绝次数与跨目的请求总数之比
已完成的兼容性评估100% 在 5 个工作日内完成从提交请求到 DPO 作出决定的时间
目的注册表复核及时率100% 按周期完成复核在各自复核周期内完成复核的目的所占比例

主要法规参考

  • GDPR 第 5(1)(b) 条 — 目的限制原则
  • GDPR 第 6(4) 条 — 兼容性评估因素
  • GDPR 第 13(1)(c) 条 — 收集时告知目的
  • GDPR 第 14(1)(c) 条 — 间接收集时告知目的
  • GDPR 第 89(1) 条 — 档案保存、研究和统计的例外
  • GDPR 序言第 50 条 — 进一步处理的兼容性
  • 第 29 条工作组关于目的限制的第 03/2013 号意见(WP203)
  • EDPB 关于第 25 条「通过设计和默认实现数据保护」的第 4/2019 号指南

评论

支持 Markdown