automated-ropa-generation

RoPA 自动生成

概述

通过访谈和问卷手动创建 RoPA 耗时长、主观性强，而且容易遗漏利益相关方忘记或不了解的处理活动。RoPA 自动生成利用现有的 IT 系统清单、云服务目录、API 网关日志和数据库架构来发现处理活动，并预填第 30 条第 1 款字段。此方法可将创建 RoPA 的工作量减少 60-80%，同时提高覆盖率，因为它能捕获手动访谈经常遗漏的处理活动（影子 IT、自动化数据管道、第三方集成）。

用于自动填充 RoPA 的数据源

来源 1：Active Directory / Azure AD

可揭示的信息：

• 组织架构（部门、团队），用于映射处理负责人
• 群组成员身份，揭示谁可以访问哪些系统（接收方类别）
• 应用注册和服务主体（处理系统清单）
• 条件访问策略（安全措施文档）

已填充的第 30 条字段：

字段	从 AD 提取的数据
第 30 条第 1 款(a)项 — 控制者身份	组织名称、部门层级、DPO 群组成员身份
第 30 条第 1 款(d)项 — 接收方	安全群组成员身份揭示内部访问模式
第 30 条第 1 款(g)项 — 安全措施	条件访问策略、MFA 强制状态

Helix Biotech Solutions 的发现方法：

Azure AD Tenant: helix-biotech.onmicrosoft.com
├── Enterprise Applications (87 registered)
│   ├── SAP SuccessFactors → HR processing activities
│   ├── Veeva Vault CDMS → Clinical trial data management
│   ├── Salesforce → Customer relationship management
│   ├── Google Analytics → Website analytics
│   ├── ADP Workforce Now → Payroll processing
│   └── ... (82 more applications)
├── Security Groups (134 groups)
│   ├── SG-HR-Payroll (4 members) → Access to payroll data
│   ├── SG-Clinical-Data (12 members) → Access to clinical trial data
│   ├── SG-Finance-AP (6 members) → Access to accounts payable
│   └── ... (131 more groups)
└── Conditional Access Policies (23 policies)
    ├── Require MFA for all users
    ├── Block legacy authentication
    ├── Require compliant device for clinical systems
    └── ... (20 more policies)

来源 2：云服务目录

可揭示的信息：

• 正在使用的所有云服务（IaaS、PaaS、SaaS）
• 数据驻留情况（数据存储在哪些区域/国家）
• 服务提供商身份（处理者和次级处理者）
• 数据分类标签（如已实施）

Helix Biotech Solutions 的 AWS 示例：

AWS 服务	区域	个人数据标识	映射的处理活动
RDS（PostgreSQL）	eu-central-1	标记：data-classification=confidential	员工人力资源数据库
S3 存储桶：helix-clinical-data	eu-central-1	标记：data-classification=restricted, contains-special-category=true	临床试验文档存储
S3 存储桶：helix-marketing	eu-central-1	标记：data-classification=internal	营销分析数据
Lambda：payroll-processor	eu-central-1	由 ADP 集成调用	薪资数据转换
CloudFront Distribution	Global（边缘节点）	日志包含 IP 地址	网站内容分发
SES（Simple Email Service）	eu-west-1	向电子邮件地址发送邮件	客户和员工电子邮件通信

Azure 示例：

Azure 服务	区域	数据分类	映射的处理活动
Azure SQL	West Europe	机密	财务和会计数据库
Azure Blob Storage	West Europe	受限	临床试验成像数据
Azure AD	Global	内部	身份和访问管理
Azure Monitor	West Europe	内部	系统监控（可能会捕获用户活动）

来源 3：API 网关日志

揭示的信息：

• 哪些 API 会处理个人数据（根据对请求/响应的检查）
• 系统间的数据流模式（上游和下游）
• 第三方 API 集成（外部接收方）
• 数据处理量和频率（有助于评估该处理是否属于第 30(5) 条所述的“偶尔”处理）

Helix Biotech Solutions 的 API 网关分析：

API 端点	方法	个人数据字段	上游系统	下游系统	每日请求量
/api/v2/employees	GET/POST	employee_id, name, email, department	SAP SuccessFactors	Internal HR portal	340 次请求
/api/v2/patients/{id}/records	GET	patient_id, diagnosis, treatment	Veeva Vault CDMS	Clinical reporting dashboard	1,200 次请求
/api/v2/orders	POST	customer_name, email, billing_address	Salesforce	SAP ERP	890 次请求
/api/v1/analytics/events	POST	ip_address, user_agent, page_url	Website (JS tracker)	Google Analytics	45,000 次请求
/api/v2/vendor/payments	POST	vendor_name, bank_account, tax_id	SAP ERP	Banking API (Deutsche Bank)	120 次请求

来源 4：数据库架构

揭示的信息：

• 存储的数据类别详情（列名和类型）
• 揭示数据流的数据表关系
• 通过列名模式匹配识别个人数据
• 数据量和增长模式

架构分析方法：

1. 连接云目录中识别出的每个数据库。
2. 提取数据表架构（列名、数据类型、约束）。
3. 根据个人数据识别模式匹配列名。
4. 将识别出的个人数据列映射到第 30(1)(c) 条规定的数据类别。

个人数据列名模式：

模式	数据类别	第 9 条特殊类别
*name*、*first_name*、*last_name*、*full_name*	姓名	否
*email*、*e_mail*	电子邮件地址	否
*phone*、*mobile*、*telephone*	电话号码	否
*address*、*street*、*city*、*postcode*、*zip*	邮政地址	否
*dob*、*date_of_birth*、*birth_date*	出生日期	否
*ssn*、*social_security*、*tax_id*、*national_id*	国家身份标识符	否
*salary*、*compensation*、*bank_account*、*iban*	财务数据	否
*ip_address*、*ip_addr*	IP 地址	否
*diagnosis*、*medical*、*health*、*condition*	健康数据	是
*genetic*、*dna*、*genome*	遗传数据	是
*biometric*、*fingerprint*、*facial*	生物识别数据	是
*ethnicity*、*race*、*ethnic_origin*	种族/族裔来源	是
*religion*、*religious*、*belief*	宗教信仰	是
*union*、*trade_union*	工会会员身份	是
*political*、*party*	政治观点	是
*criminal*、*conviction*、*offence*	犯罪数据（第 10 条）	第 10 条

自动填充字段的逻辑

第 30(1)(a) 条 — 控制者身份

来源：Azure AD 租户配置 + 组织管理。
自动化：根据 AD 租户元数据完全自动化。

第 30(1)(b) 条 — 目的

来源：AD 企业应用注册表中的应用描述 + API 文档。
自动化：部分自动化。系统名称和描述可作为起点，但要满足第 5(1)(b) 条的明确性要求，仍需人工完善具体目的的表述。

方法：根据应用描述生成目的草案，标记为“草案 — 需由 DPO 审核”，并分配给处理负责人进行完善。

第 30 条第 1 款（c）项 — 数据主体和数据类别

来源：数据库架构分析 + API 请求/响应架构。 自动化程度：数据类别的自动化程度很高（按列名匹配）。数据主体类别需要结合表上下文进行推断。

第 30 条第 1 款（d）项 — 接收方

来源：AD 安全组（内部接收方）+ API 网关日志（外部集成）+ 云服务目录（处理者）。 自动化程度：自动化程度很高。AD 组可揭示内部访问情况。API 网关可揭示外部数据流。云服务目录可识别处理者。

第 30 条第 1 款（e）项 — 国际传输

来源：云服务区域配置 + API 网关目标 IP + CDN 配置。 自动化程度：自动化程度很高。如果云服务部署在非 EEA 区域，或 API 调用路由至非 EEA 端点，系统会标记潜在的国际传输。

第 30 条第 1 款（f）项 — 保留期限

来源：数据库表统计信息（最早的记录）、备份保留策略、生命周期管理规则。 自动化程度：部分自动化。可以检测实际保留期限（数据实际存在的时长），但无法检测预期保留期限（数据应当存在的时长）。系统会标记实际保留期限与策略规定的保留期限之间的差异。

第 30 条第 1 款（g）项 — 安全措施

来源：云安全配置（加密设置、访问策略）、AD 条件访问策略、WAF 规则、证书配置。 自动化程度：技术措施的自动化程度很高。组织措施需要手动记录。

自动化覆盖率概要

第 30 条第 1 款字段	自动化程度	是否需要人工审核
(a) 控制者身份	高（90%）	核实法律实体名称、DPO 信息是否为最新
(b) 目的	低（30%）	必须具体说明目的
(c) 数据主体类别	中（60%）	核实推断出的类别
(c) 个人数据类别	高（85%）	核实通过模式匹配识别出的列
(d) 接收方	高（80%）	核实外部接收方，补充 DPA 引用
(e) 国际传输	高（85%）	核实传输机制
(f) 保留期限	低（25%）	确定策略规定的保留期限，而不仅是实际期限
(g) 安全措施	中（70%）	补充组织措施

实现架构

┌─────────────────────┐  ┌──────────────────┐  ┌────────────────────┐
│   Azure AD / Okta   │  │  Cloud Catalog   │  │  API Gateway Logs  │
│  (Org structure,    │  │  (AWS/Azure/GCP   │  │  (Data flows,      │
│   app registrations,│  │   service list,   │  │   external calls,  │
│   security groups)  │  │   regions, tags)  │  │   volumes)         │
└────────┬────────────┘  └────────┬─────────┘  └─────────┬──────────┘
         │                        │                       │
         ▼                        ▼                       ▼
┌────────────────────────────────────────────────────────────────────┐
│                    RoPA Auto-Generation Engine                     │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐    │
│  │ AD Parser    │  │ Cloud Parser │  │ API Log Analyzer     │    │
│  └──────┬───────┘  └──────┬───────┘  └──────────┬───────────┘    │
│         │                  │                      │               │
│         ▼                  ▼                      ▼               │
│  ┌────────────────────────────────────────────────────────────┐   │
│  │              Field Mapping and Population Engine            │   │
│  │  • Pattern matching for personal data columns              │   │
│  │  • Data flow graph construction                            │   │
│  │  • Transfer detection (non-EEA region identification)      │   │
│  │  • Security control extraction                             │   │
│  └────────────────────────┬───────────────────────────────────┘   │
│                           │                                       │
│                           ▼                                       │
│  ┌────────────────────────────────────────────────────────────┐   │
│  │              Draft RoPA Generator                          │   │
│  │  • Creates draft entries with populated fields             │   │
│  │  • Flags fields requiring human review                     │   │
│  │  • Assigns to processing owners for validation             │   │
│  └────────────────────────┬───────────────────────────────────┘   │
└───────────────────────────┼───────────────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────────────────┐
│                Database Schema Scanner                              │
│  (Connects to identified databases, extracts schemas,              │
│   applies PII detection patterns)                                  │
└────────────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────────────────┐
│               RoPA Management Platform                             │
│  (OneTrust / TrustArc / Collibra / Custom)                        │
│  Draft entries queued for DPO and processing owner review          │
└────────────────────────────────────────────────────────────────────┘

局限性和风险缓解措施

1. PII 检测中的误报：像 "company_address" 这样的列名可能会被标记为个人数据，但它们可能属于业务数据。缓解措施：人工审核所有自动检测出的 PII 列。

2. 用途上下文缺失：仅凭技术元数据，自动化系统无法推断处理的业务目的。缓解措施：始终将目的标记为“草稿”，并要求人工具体说明。

3. 影子 IT 的盲区：未在 AD 或云服务目录中登记的系统无法被发现。缓解措施：将自动发现与定期人工问卷结合，以发现未登记的处理活动。

4. 加密或令牌化数据：如果数据在列级别加密或经过令牌化，架构分析可能无法检测到个人数据。缓解措施：手动维护加密/令牌化映射清单。

5. 同意和合法依据：无法从技术元数据中确定。始终需要法律部门/DPO 提供意见。