Data Act 的核心义务自 2025 年 9 月 12 日起适用。面向联网产品的默认设计义务自 2026 年 9 月 12 日起适用。数据访问已是安全控制问题,而非合同问题。
欧盟 Data Act 改变了谁可以访问与使用联网产品(包括联网车)所产生数据的格局。自 2025 年 9 月 12 日起,用户拥有更强的权利,以获取范围内的数据,并在许多情况下,可指示数据持有方将该数据提供给第三方。
对汽车企业而言,这同时带来机会与张力。车辆数据可支持维修、保养、保险、车队优化、充电、道路救援与新的出行服务。然而,用于交付这些价值的接口可能暴露个人数据、对安全敏感的遥测、专有 know-how、诊断能力,或在与命令路径组合时变得危险的信息。
因此实际问题不是 OEM 应"开放"还是"封闭"车辆数据。而是组织能否将对的数据、通过对的接口提供给对的方,同时保留网络安全、隐私、安全、商业秘密保护与证据。
因此,欧盟 Data Act 的落地远不止一个法律或 API 项目。每一个新接收方与新接口都会改变联网攻击面,故访问决策必须与架构、威胁、控制、测试、供应商与事件保持联通。
本指南说明如何构建该运行模型,以及 ThreatZ 如何作为汽车网络安全与证据层服务于此过程,而不冒充替代法律解释、隐私案件管理、同意系统、API 网关或客户身份平台。
为何 Data Act 成为 CSMS 与证据问题
Chapter II 的合规会反复产生工程决策。一个请求原则上可以合法,而实现仍不安全。同一数据集作为聚合导出可能是低风险,而作为带车辆标识的实时流则是高风险。一个合法接收方仍可能存在弱客户身份、令牌存储或分包商控制问题。
因此,Cybersecurity Management System 应把实质性的数据访问变更视为生命周期事件,并回答:
- 哪些车辆、功能、ECU、后端、API 与供应商产生或处理该数据?
- 哪些威胁场景因访问路径而改变?
- 哪些控制降低了这些风险,且如何核验?
- 哪个策略、软件、模式与架构版本支撑了该决策?
- 当所有权、接收方、软件或威胁变化时,什么会触发复核?
当法律分析、目录、TARA、API 测试、供应商证据与事件分散在不同系统时,这些关系难以维护。目标是构建联通的证据链,而不是一个巨型仓库。
Data Act 给汽车带来什么变化
Data Act 为联网产品与相关服务所产生数据的访问与使用制定了协调规则。欧盟委员会的车辆数据指引为汽车相关方提供量身解读,并聚焦于 Chapter II 的访问规则。
在实务上,车辆用户可能可以:
- 访问通过使用车辆或相关服务所产生的相关数据。
- 获取关于产生哪些数据以及如何访问的信息。
- 要求数据持有方将相关数据提供给所选第三方。
- 使用该数据获取售后或附加服务,而不必只依赖原厂。
该义务不会抹去其他义务。个人数据处理仍受数据保护法约束。商业秘密受保护。安全要求仍然适用。组织因此需要一致流程,能够解释为何某数据集按要求提供、转换为更安全的表示、在限定条件下受限、出于正当理由延迟,或上报至法律复核。
在发布前,法律团队应针对该车辆、服务与合同的具体情况,核实最新官方指引与每个实体的角色。本文聚焦工程与网络安全运行模型,非法律建议。
在设计接口前先识别参与方
一次联网车请求可能涉及比典型消费 IoT 服务更多的方:
- 车主、承租人、驾驶员、车队运营方或其他被认可的用户。
- OEM 或其他作为数据持有方的实体。
- 移动应用或联网服务运营方。
- 维修方、保险公司、充电服务方、车队平台、道路救援或独立开发者,作为数据接收方。
- 运营后端、分析服务、远程信息处理组件或数据经纪服务的 Tier-1 供应商。
- 云、身份或 API 管理供应商。
- 其个人数据出现在数据集中但并未提出请求的其他人。
角色可随数据集与服务而变化。一家 OEM 在一条数据流中是数据持有方,而在另一条流中可能是处理方或接收方。一个车队客户可能是车辆用户,而员工或乘客仍是数据主体。
为每个服务建立一份角色地图。记录法律实体、合同、车辆关系、数据来源、预期用途、技术客户、权限与责任人。给地图稳定的标识,使其决策可链接到对应的 API、车辆项目、供应商与网络安全分析。
缺少该映射,团队就可能构建技术上正确的接口,却把数据交给错误的方,持续时间过长,且基于已不存在的权益。
构建一份链接到架构的车辆数据目录
核心实施工件是一份与技术血缘相连的车辆数据目录。对每个数据元素或数据集,记录:
- 名称与通俗描述。
- 源功能、ECU、传感器、应用或相关服务。
- 生成触发条件、频率、精度与时延。
- 原始、预处理、推断或派生状态。
- 附加的车辆、用户与账户标识。
- 个人数据、商业秘密、安全与网络安全分级。
- 存储位置、保留、驻留地与供应商参与。
- 可用访问通道、API 版本与服务负责人。
- 用户权益与第三方共享状态。
- 必需的转换、脱敏、聚合或安全条件。
- 数据质量、单位、时间戳、语义模型与版本控制。
- 威胁场景、安全控制与核验证据。
- 责任人与审批人。
不要从数据库表列表开始。一个业务概念可能源自多个 ECU、在 TCU 中富化、在云服务中转换,并通过多个 API 版本暴露。目录必须呈现从车端生成到对外交付的血缘。
在基于图的网络安全模型中,数据集链接到其源组件、传输接口、暴露 API、接收方类别、威胁、控制与测试。
目录还应区分"现成可用"数据与"需要大量派生"的新分析。Data Act 并非要求从原始信号中创造一切可能的洞察。
把法律权益与技术授权分开
合法的用户指示并不自动证明某次具体的 API 请求应当成功。运行模型需要两个相关但独立的决策:
- 权益决策:该用户是否有权对此车辆、数据集、时段与接收方发起访问请求?
- 执行决策:该已认证客户是否对此精确请求持有有效、最新、最小权限的授权?
稳健流程包括:
- 对车主、承租人、车队管理员、驾驶员或委托代表的验证。
- 证明用户与车辆或账户的关系。
- 对第三方组织及其技术客户的验证。
- 明确的数据集、车辆、时段、频率与持续时长范围。
- 对用户指示与所需条件的记录。
- 具备细粒度 scope 的短时凭据。
- 服务端的对象与函数授权。
- 当所有权、雇佣、委托或服务终止时的撤销。
- 证明强制执行的令牌与已批准指示相匹配。
避免长期、覆盖整个车队的 API 密钥。对车队,把组织层管理与个别车辆/驾驶员权限分开。对合作伙伴,隔离租户,且每个生产客户都使用独立的工作负载身份。
ThreatZ 不应承担令牌发放或客户同意引擎的职责。它可以把权益记录或策略引用与车辆、数据资产、接口、威胁、控制与测试证据链接,从而让网络安全团队证明该技术策略为何充分。
直连访问与经数据持有方的访问
两种架构模式常见。
从联网产品直接访问
用户或接收方从车辆或本地接口取数。这减少对后端的依赖,但带来带宽、可用性、认证、版本与安全隔离方面的约束。使用专用读模型,而非通用路径进入诊断或控制。
经数据持有方访问
车辆将数据发送到后端,后者通过 API、门户、导出或流暴露。这更易扩展,但带来集中化风险、时延以及完整性方面的疑问。
许多 OEM 会采用混合模式。为每类数据记录假设、失效模式与所需证据;仅有移动应用视图并不构成机器可读的第三方访问策略。
把每条新增数据路径视为网络安全变更
新增的数据接收方或 API 不仅是商业集成。它可能改变信任边界、攻击路径、凭据、数据聚合、供应商依赖与运行监控。
当项目引入下列变更时,触发聚焦的 TARA 或变更影响评估:
- 新的外部接收方类别。
- 新的数据集、精度等级或更新频率。
- 新的直接车辆接口或网关规则。
- 新的 API 版本、认证方式或令牌 scope。
- 新的云、身份、分析或集成供应商。
- 增加敏感性的新的数据关联组合。
- 推断车辆状态、位置、安全态势或用户行为的新能力。
- 数据访问与诊断、命令或软件更新之间的连接。
分析应建模披露与服务滥用场景,而不仅是篡改。示例包括车队枚举、跨车对象访问、接收方凭据被盗、为偷盗或跟踪而聚合数据、架构侦察、拒绝访问以及对共享后端服务的利用。
在 ThreatZ 中,数据资产与访问路径可链接到相关系统要素、威胁、风险、控制、测试、供应商与事件。这样,后续变更复核就成了图查询,而非对不相干文档的人工比对。
采用基于威胁的限制,而非一刀切标签
有的团队可能把每个车辆信号都标为安全敏感。这难以辩护,且会削弱该法规的目标。也有团队在没有意识到精度、频率或关联可能带来风险时就对外开放数据。
采用定义清晰的安全分级:
- 低敏感:披露几乎不产生有意义的安全影响。
- 运营敏感:数据可助益画像、欺诈、偷盗或服务滥用。
- 架构敏感:数据揭示版本、网络结构、诊断能力或防御控制。
- 控制敏感:信息可支持提权、命令滥用或绕过保护。
- 安全相关敏感:披露或访问与另一能力组合后可能促成不安全行为。
对每条限制,把理由连接到具体的威胁场景、影响与控制缺口。说明风险是来自字段本身、精度、更新频率、历史深度、与其他数据集的组合、接收方环境,还是访问机制。
尽可能提供更安全的表示:聚合值、降低频率、伪名化标识、受控查询访问、安全处理环境,或在不暴露诊断秘密的前提下支持业务的数据。当组织能够展示自己考虑了相称的替代方案而非默认拒绝时,该决策更具说服力。
在同一决策链中保护个人数据与商业秘密
Data Act 与 GDPR 协同运作。工作流必须识别个人与混合数据集、相关数据主体、合法依据、最小化、伪名化、保留、传输与所有权转移规则。
商业秘密的处理也需要具体理由:面临风险的商业价值、所请求的字段、接收方的保障措施与相称缓解。字段裁减、受控查询、保密承诺、聚合或在不披露专有变量的前提下披露度量值,可同时保留访问与保护。
隐私、商业秘密与网络安全团队应使用相同的血缘与决策标识,使并行记录不会漂移。
做成 API 产品,而非合规端点
一个技术上可用的端点若不可靠、无文档、语义不一致或难以集成,仍会让用户失败。
成熟的车辆数据 API 应提供:
- 清晰的定义、单位、时间戳、质量标志与模式版本。
- 具备生命周期规则的稳定车辆与数据集标识。
- 细粒度授权 scope 与租户隔离。
- 与合法使用模式相匹配的速率限制。
- 必要时提供分页、过滤、批量导出与订阅。
- 不暴露敏感架构细节的错误响应。
- 服务级目标与维护通告。
- 弃用、迁移与接收方合规策略。
- 面向已批准接收方的沙盒。
- 安全事件、访问与管理操作日志。
盘点每个生产、测试、区域、合作伙伴与历史版本。被遗忘的 API 是常见暴露路径。把每个版本链接到其架构基线、软件组件、控制集与测试状态,使弃用与漏洞决策在各项目间可见。
防止数据访问变成车辆控制
读访问应在架构上与命令分离。被授权读取里程、电量或保养数据的接收方不应继承解锁车门、调整充电限值、清除故障码、调用诊断或触发更新的能力。
对以下功能,使用独立的域、凭据、网关与策略:
- 只读产品数据。
- 用户与账户管理。
- 远程车辆命令。
- 诊断与售后服务功能。
- 软件更新。
- 工程访问。
在服务器对每个对象与函数施加授权。测试:车辆 A 的令牌无法取得车辆 B;车队子用户无法访问整个车队;读 scope 不能调用写函数。包含针对标识篡改、过期权益、令牌重放、跨租户访问与隐藏遗留路由的负向测试。
该分离同时构成更清晰的网络安全论证。团队可以独立评估 Data Act 访问服务,同时明确显示命令与诊断路径处于其信任边界之外。
构建数据访问网络安全案例
与其在末端收集截图,不如为每个实质性访问模式定义一个小型保证案例。顶层 Claim 可以是:
车辆数据访问服务将已批准的数据集提供给已授权接收方,且不引入不可接受的网络安全或安全风险。
用如下子 Claim 支撑:
- 数据集与技术血缘完整且分级正确。
- 用户与车辆的关系以及接收方身份已被核实。
- 授权为最小权限、有时限、可撤销且在服务端强制。
- 读访问与命令、诊断及更新隔离。
- 隐私与商业秘密转换按批准实施。
- 安全控制针对代表性滥用场景已被核验。
- 软件、模式与供应商变更触发影响分析。
- 监控能够检测滥用,事件可被追溯到受影响的车辆与决策。
证据可包含架构基线、数据目录、TARA、策略版本、授权矩阵、API 安全测试、渗透测试发现、软件与 SBOM 版本、供应商声明、访问日志、事件演练与批准记录。
ThreatZ 非常适合承载该案例的网络安全侧,因为其知识图谱连接架构、资产、威胁、风险、控制、需求、测试、软件组件、漏洞、供应商、事件与报告。法律意见、隐私记录、合同与同意仍保留在各自权威系统中;ThreatZ 可存储引用与可追溯链接,而非复制这些系统。
这把"安全已批准"变成可审视的论证,并展示哪些服务依赖于给定的身份提供方、控制、库、供应商或策略版本。
把变更与事件链接回原始决策
数据访问是一项生命周期服务。所有权转移、供应商变更、API 发布、新的 CVE、失败的测试或滥用事件,都可能使审批时所依赖的假设失效。
定义自动触发复核的条件,包括:
- 身份或授权控制失败。
- 暴露的 API 组件出现新漏洞。
- 模式变更新增了敏感字段。
- 新增接收方用途或访问频率。
- 供应商所有权或托管变更。
- 涉及令牌窃取、爬取、枚举或数据泄露的事件。
- 车辆架构或网关变更。
- 依赖组件停止支持。
响应应识别受影响的数据集、API、车辆变体、接收方、控制与证据包。ThreatZ 的运维与 SBOM/供应链能力可将事件或漏洞连接到底层资产、风险、控制、组件与责任团队,同时由外部 API 网关与 SIEM 持续进行实时执行与检测。
以 ThreatZ 为中心的 12 周试点
选取一个高价值、范围可控的用例,如独立维修或车队保养。
1-3 周:建模范围与血缘
梳理用户、车辆、数据集、源功能、后端、API、接收方、供应商与法律决策标识。把相关架构导入 ThreatZ 或建立聚焦的系统模型。建立数据资产与信任边界。
4-6 周:分析风险并定义控制
对访问路径运行聚焦 TARA。定义身份、授权、隔离、最小化、日志、变更控制与供应商控制。把每条控制链接到其支撑的威胁与决策。
7-9 周:连接核验证据
实现或更新 API、网关策略、令牌、撤销与日志。把授权矩阵测试、对象级访问测试、渗透测试证据与软件/SBOM 上下文链接到相关控制与风险。
10-12 周:验证生命周期治理
运行一次完整请求,从用户指示到第三方交付与撤销。然后模拟一次变更或事件,如易受攻击的 API 库或被盗的接收方凭据。产出数据访问网络安全案例,并测量团队识别影响与证据的速度。
试点应留下可复用的目录类、威胁模式、控制、测试与报告模板——而不是一次一次性集成。
Data Act 就绪度度量
跟踪指标:在范围内并已链接到架构与接口的数据集比例;具备最新 TARA、控制与测试的访问模式;由供应商运营的路径具备最新证据;尚在运行的不被支持的 API 版本;授权测试覆盖率;撤销时间;漏洞影响半径耗时;以及链接回数据资产与风险的事件数。
最佳指标不是数据量,而是组织是否能通过一个受控、变更后仍可解释的流程,把对的数据交给对的方。
ThreatZ 如何强化 Data Act 运行模型
ThreatZ 可作为汽车网络安全证据层,贯穿五项互联活动:
- 建模访问路径。把数据资产链接到车辆功能、ECU、云服务、接口、API、接收方与供应商。
- 分析威胁。利用 TARA 工作流与可复用安全目录评估披露、授权、服务滥用、隔离与可用性场景。
- 连接控制与证明。把访问策略、安全需求、控制、测试用例、发现、软件组件与报告证据链接到其所应对的风险。
- 维护生命周期可追溯。使用版本控制、变更历史、SBOM/漏洞上下文与事件链接,识别此前的审批何时需要复核。
- 生成可审视的案例。为产品安全、合规、审计与项目管理提供最新、可追溯的安全视图,而不必为每次请求或复核组装一份新电子表格。
Uraeus AI 可建议相关威胁、控制或测试,并标记缺失的链接。法律解释、风险接受、隐私与审批仍由人类责任人承担。
ThreatZ 并非客户身份提供方、同意账本、隐私管理平台、API 网关或运行时检测系统。它使这些系统的网络安全决策可追溯到车辆、风险、证据与生命周期上下文。这正是 OEM CSMS 团队商业上相关的关键缺口:证明安全的车辆数据访问是活的网络安全案例的一部分,而非一个脱节的合规端点。
常见问题
Data Act 要求 OEM 暴露每一个车辆信号吗?
不。范围取决于该法规的定义以及通过使用联网产品或相关服务所产生的数据。组织应仔细分类数据,并把现成可用数据与新派生的洞察区分开。
能以网络安全为由拒绝请求吗?
安全顾虑应当具体、有证据,并在适用法律条件下处理。一句"所有车辆数据都很敏感"的笼统陈述不构成可信的运行模型。可能存在更安全的表示或受控访问方式。
Data Act 如何与 GDPR 交互?
Data Act 不取代个人数据法。当所请求的车辆数据包含个人数据时,各方仍需具备合法依据、透明度、最小化、安全与数据主体保护。
Data Act 就绪度中最重要的 ThreatZ 用例是什么?
构建一个数据访问网络安全案例,把数据集与 API 链接到架构、威胁、控制、测试、供应商、软件组件与事件。这为后续服务与接收方建立可复用模式。
好的首个试点是什么?
独立维修、车队保养、充电优化或道路救援都不错,因为用户价值清晰且所需数据有界。避免从宽泛的"全部车辆数据"项目开始。
权威参考
- 欧盟委员会关于 Data Act 的车辆数据指引
- Regulation (EU) 2023/2854——Data Act
- 欧盟委员会:Data Act 释义
- 欧盟委员会 Data Act 政策页