数据共享规范实践总结

type

status

date

slug

summary

1 范围

略

2 规范性引用文件

《XXXX集团网络和数据安全管理办法》

《XXXX集团数据安全实施细则》

3 术语和定义

3.1 数据共享

数据共享是指在集团内部及集团与外部单位之间，按照约定的规则和权限，安全、可控地交换和使用数据的过程。

3.2 数据开放共享平台

数据开放共享平台是集团数据中台的重要组成部分，是集团数据中台对外提供数据服务的统一出口。数据开放共享平台基于数据资产目录和统一安全管控体系，通过数据服务共享、数据集共享两种方式，为集团各部门、外部单位提供合规、高效的数据服务。

3.3 数据服务

数据服务（API，Application Programming Interface），即应用程序接口，是一组预先定义的函数、协议和工具的集合，用于实现不同软件系统之间的通信和数据共享，允许不同系统进行数据交换。通过数据服务方式进行数据共享是集团数据共享的主要方式之一。

3.4 数据集共享

数据集共享是指通过数据开发治理平台数据采集工具，以数据集的方式将数据从数据开发治理平台推送至数据需求部门指定数据库的数据共享行为。

3.5 RESTful

RESTful是一种基于资源的接口设计风格。RESTful API通过统一的URI标识资源，使用标准的HTTP方法（如GET、POST、PUT、DELETE）进行操作，强调无状态通信和资源表现形式的转移，接口设计简洁、清晰、易于维护。

3.6 幂等性

幂等性指的是同样的API请求，在源数据未发生变更的情况下，无论执行多少次，都会产生相同的结果。

3.7 流量控制

流量控制用于防止API过载、避免恶意调用，常见策略包括QPS限制、调用配额、IP限制等。

3.8 预计算

预计算指在数据存储阶段提前计算好复杂的聚合指标，避免API在查询时进行高计算成本的实时计算，常见方式包括：ETL预计算、物化视图和缓存。

4 数据共享原则

4.1 依法依规共享

集团数据共享过程中，应严格遵循国家及行业相关法律法规，以及《XXXX集团网络和数据安全管理办法》、《XXXX集团数据安全实施细则》要求，确保数据共享合法合规。

4.2 充分共享原则

应在依法依规和保障数据安全的前提下，最大程度地实现集团内部数据共享，以提升集团数据开发利用整体效能。

4.3 最小必要授权

应遵循最小必要授权原则，仅在业务需要的范围内授予访问权限，避免过度授权，降低数据泄露和滥用的风险。

4.4 分类分级管控

应建立数据分类分级保护机制，依据数据安全定级规定，严格按照《XXXX集团数据安全实施细则》要求，对不同安全级别的数据采取对应的管控措施。

5 数据共享方式

5.1 数据共享方式

集团数据共享应依托数据开放共享平台进行，实时数据共享场景及其他未经数据开放共享平台的数据共享行为，需提交共享方案经数据治理与架构管控小组审批通过后方可实施。

数据开放共享平台提供两种数据共享方式：

（一）数据集共享，即通过数据开发治理平台数据采集工具，将数据集从数据开发治理平台推送至数据需求部门指定数据库；

（二）数据服务共享，即通过API接口按需提供数据服务。集团数据共享应优先采用数据服务共享方式。

5.2 数据共享方式选择

（一）适合采用数据服务共享的场景

1．多系统数据共享：不同应用需通过标准化接口访问同一数据集，避免数据库直连带来的安全风险。

2．动态数据访问：查询数据需支持动态过滤、聚合计算，而非静态数据文件。

3．准实时数据查询：业务系统需要低延迟访问数据，如订单查询、用户信息检索。

4．访问权限控制严格：需要API级身份认证、日志记录、流量控制，确保数据安全。

（二）适用采用数据集共享的场景

1．大规模数据传输：需要批量共享数据。

2．离线数据分析：数据用于BI报表、机器学习训练或定期数据归档。

3．非实时业务需求：数据更新周期较长，如每日、每周定期同步，不依赖实时查询。

（三）选择原则

1．业务需求优先：数据共享方式应根据业务需求选择，优先考虑数据访问频率、实时性、数据规模等因素。

2．性能与可扩展性：高并发、低时延场景优先采用数据API，大数据量、离线分析优先采用数据集服务。

3．安全与合规：涉及敏感数据、跨系统访问、权限控制的业务场景，推荐使用数据API，以加强安全管控。

4．标准化与复用：企业内部通用数据，应优先提供API服务，避免重复开发，提高数据复用性。

5.3 数据共享流程

集团内部数据共享服务依托数据开放共享平台统一管理，通过申请、审批、订阅流程，确保数据共享过程合法合规、安全可控、高效透明。

（一）申请

数据需求部门通过数据开放共享平台发起数据共享申请，支持以下两种方式：

1．单一资源申请：检索目标数据资源（数据集或API服务）后填写申请单，需明确申请数据项、申请单位、申请人及联系方式、资源使用场景、使用范围及期限。

2．批量申请：将多个数据资源加入“数据资源清单”后统一提交申请单。

（二）审批

数据需求部门提出数据共享申请后，数据开放共享平台遵照《XXXX集团数据安全实施细则》，根据申请数据项安全等级、数据项所属部门自动分配数据审核人，由数据审核人对数据共享申请需求进行审核，审核标准包括但不限于：

1．数据共享申请的使用场景、使用范围、期限是否符合业务逻辑，申请数据项否符合最小必要授权原则。

2．数据共享申请是否符合《XXXX集团网络数据安全管理办法》、《XXXX集团数据安全实施细则》等制度中关于数据共享的要求。

（三）订阅

1．新增订阅：审批通过后，需求部门可在数据开放共享平台中配置订阅参数。数据集共享订阅参数包括数据更新方式（定时推送或实时推送）、数据接收方式（如指定存储路径或接口地址）、订阅有效期；数据服务订阅参数包括订阅应用系统、订阅有效期等，订阅保存后即时生效。

2．订阅管理：需求部门可通过数据开放共享平台“我的订阅”模块修改订阅参数或终止订阅，变更需重新提交审批。

（四）外部单位数据共享

外部单位申请集团数据共享时，应按照以下流程执行：

1．因审计、纪检或上级主管部门要求需要对外提供数据的，应先明确所涉数据范围，根据所涉数据范围确定对接部门，由集团对接部门报其分管（协管）领导审批，查询工作由数据信息中心配合，查询结果由对接部门对外报送，并保障交接过程的数据安全；

2．其他外单位的数据查询申请，由申请单位向集团提交申请公函，由主办部门报其分管领导审批同意后，由数据信息中心配合查询工作，查询结果由主办部门对外报送并保障报送过程中的数据安全。

6 数据服务规范

6.1 数据服务开发规范

集团数据服务（API）开发应遵循统一的标准规范，包括数据服务架构风格规范、命名规范、封装规范、性能规范、版本管理规范等关键要素。

（一）架构风格规范

数据服务（API）应严格遵循RESTful架构风格，采用资源导向的设计模式，确保接口语义清晰，易于理解和维护。API的URL结构应基于资源进行组织，使用名词复数形式，如/customers表示客户资源集合，/customers/{id}表示单个客户资源。在HTTP方法的使用上，应保持标准化的查询数据语义：

1．GET：查询数据，如GET/orders/{id}获取订单信息；

2．POST：创建或执行特定操作，如POST/reports/export执行数据导出；

（二）命名规范

数据服务（API）的命名应准确反映核心数据资源的业务语义，提升数据可读性、易用性和复用性。建议采用“业务对象+消费场景”形式进行命名，例如：customer_profile_query（客户档案查询），禁止直接使用物理表名作为数据服务名称，以避免数据模型变更对数据服务的影响，并降低数据库耦合度。命名需符合集团数据标准，确保跨业务系统和数据域的一致性，避免命名不规范导致的理解偏差或错误使用。

数据服务（API）输入与输出字段必须保持统一的命名风格，建议统一采用下划线命名法（snake_case），例如：user_name、order_id。字段命名应具备明确业务语义，严禁使用缩写或无意义字段名，如不得使用unm代替user_name，或oid代替order_id。

字段数据类型必须保持一致，并在API接口文档中明确定义。时间字段统一采用ISO8601格式（如：2025-03-12T00:00:00Z），或yyyyMMddHHmmss格式，并需注明具体时区，确保前后端数据解析一致性。

（三）唯一标识要求

数据服务（API）必须具备唯一标识（ID），并与技术元数据进行关联，确保其在整个数据治理体系中的可追溯性和可管理性。唯一标识应支持全局唯一性，避免命名冲突，同时可作为数据服务的版本管理、权限控制和生命周期管理的基础。

（四）元数据关联要求

数据服务（API）必须与底层数据资源建立映射关系，以确保数据来源的完整性和一致性。映射关系应包括数据存储位置、数据表/文件路径、数据更新时间、数据依赖关系等信息，以便数据服务在演进过程中可审计、可监控，并支持变更管理。

（五）幂等性保障

数据服务（API）设计需确保幂等性，即在数据源未发生变化的前提下，相同请求的返回结果应保持一致。对于GET请求，天然符合幂等性要求。对于POST、PUT请求，应通过请求ID（requestId）机制或唯一性约束，防止重复提交导致的数据异常或重复写入。对于涉及实时计算或动态数据刷新的数据服务，需在API文档中明确说明可能的数据误差范围（例如缓存策略或数据同步周期可能导致的细微差异），以确保调用方正确理解API行为，并在业务逻辑中妥善处理可能的结果变动。

（六）轻量化规范

数据服务（API）应保持轻量，避免承担复杂的计算任务，如SUM、AVG、COUNT、JOIN、子查询、窗口函数等高成本计算逻辑。数据服务（API）的职责应仅限于数据访问，避免因复杂计算影响响应性能和系统稳定性。复杂计算的处理应该由数据处理层预先完成并以优化的数据形式提供，确保数据服务（API）的高效性和系统的可扩展性。

（七）封装规范

数据服务（API）需依据明确的业务需求进行封装。数据服务（API）封装需严格遵循业务边界（示例见下图），确保数据资源的合理组合及可复用性，避免跨业务域的数据整合影响数据治理的规范性。

1.允许在数据湖同一业务对象范围内，对一个或多个数据资源进行封装，形成标准化数据服务，确保数据服务（API）的逻辑完整性和业务一致性。

2.允许将数据湖中的单一数据资源及其关联的主数据进行整合，合并封装为数据服务（API），以支持数据消费端的一体化数据访问需求，提高数据的可用性。

3.不允许将数据湖跨业务对象的多个数据资源合并封装为一个数据服务（API）。涉及跨业务对象的数据整合，应在数据开发治理平台中完成整合，通过标准数据服务提供访问，以保证数据治理的规范性及业务边界的清晰性。

（八）分页规范

数据服务（API）在返回多条记录时，必须实现分页机制，以防止一次性返回过量数据，影响系统性能和调用效率。分页应采用limit+offset方式进行控制，确保调用方能够高效查询并合理管理数据流量。

为了避免超大分页请求对系统造成压力，需对limit设置上限值，如最大100条或1000条，具体阈值依据业务场景设定。API调试阶段可默认limit=100，但生产环境下应根据数据查询需求合理配置默认值，并确保limit不宜设置过大，以维护系统响应效率和资源占用的可控性。

（九）数据请求与响应规范

数据服务（API）必须清晰定义请求参数（入参）与返回参数（出参），确保数据调用的可理解性和一致性。

请求参数（入参）：应采用标准化的数据格式，支持必填字段校验、数据类型约束（整数、字符串、日期等）、默认值等，确保请求数据完整性。

返回参数（出参）：必须体现业务含义，不得直接暴露物理表字段，以防止数据库结构变更影响API兼容性。所有API输出应符合数据治理标准，保持结构合理、格式统一。

（十）返回格式与错误处理规范

数据服务（API）应采用统一的数据返回格式，确保调用方解析一致，减少兼容性问题。建议使用JSON作为标准响应格式，同时提供清晰的状态码（HTTP Status Code）与业务错误码。对于API运行异常，系统应返回标准HTTP状态码（4xx/5xx），并提供详细的错误信息。建议定义业务级错误码（如1001表示参数校验失败，1002表示查询超时），并在API文档中列出所有可能的错误码，以便调用方进行异常处理。

（十一）性能优化与超时策略

数据服务（API）应满足高性能、低延迟的要求，通常需满足99%的请求（P99）在500ms-3s内返回，具体性能标准依据数据量和业务需求设定。在数据服务（API）设计时，需合理规划数据查询策略，避免大规模查询导致响应时间过长。对于长时间运行的查询任务，可采用异步处理（如任务提交后轮询结果）替代同步API，以提升整体性能。数据服务（API）应提供超时设置与重试策略，如：

1．短查询请求（<3s）：应在3s内返回，前端可在5s后触发重试；

2．长查询请求（>10s）：建议使用异步任务机制，如POST/tasks提交查询，GET/tasks/{id}获取执行状态；

3．默认超时：对于后端执行较慢的API，建议API网关或后端服务设置最大超时时间（如30s），避免长时间占用系统资源。

（十二）版本管理规范

数据服务（API）版本升级必须保持向后兼容性，不应随意修改已有字段或调整数据结构。如需重大改动，必须通过版本号（如/v2/）进行区分，并给予调用方N-1版本的并行支持，确保平滑迁移。同时，需提供数据服务（API）变更通知机制，通过邮件、公告等方式提前告知调用方，确保业务系统有足够的调整时间。

（十三）参数校验与错误处理规范

数据服务（API）输入参数必须经过严格校验，确保合法性，防止SQL注入、XSS等安全问题。对于缺失必填参数、格式错误、非法数据，系统需返回明确的错误响应，如400 Bad Request，并提供易于理解的错误消息。

（十四）API文档规范

数据服务（API）必须提供完整的API说明文档，包括接口用途描述、URL及HTTP Method、请求参数说明（字段名、类型、是否必填、业务含义）、请求示例（JSONBody/URL示例）、返回字段说明（数据结构、分页格式、枚举值）、错误码列表及异常示例。

API文档需保持与实际实现同步，在API变更后及时更新，确保调用方可正确集成并使用数据服务。

6.2 数据服务安全规范

集团数据共享服务应建立严格的访问控制策略。无论是通过数据服务还是数据集方式提供数据，都必须严格控制数据访问权限，确保身份认证与授权机制的有效性，防止未授权访问及数据滥用。访问控制策略包括身份认证、授权管理、密钥管理、细粒度权限控制等多个方面，以确保数据共享安全、合规、可追溯，并符合最小权限原则。

（一）身份认证机制

数据共享必须遵循“身份先行”原则，确保所有访问者在获取数据前完成身份确认。身份认证方式包括IAM用户认证（基于Token）、APP认证（基于应用ID和密钥）等，所有生产环境的API必须开启身份认证，不得采用“无认证”模式，除非经过安全审查批准并有严格的访问控制措施。

（二）流量控制

1．流量控制的必要性

为保障后端服务稳定并防止恶意调用，数据服务（API）必须配置流量控制（RateLimiting）策略，以确保系统在高并发环境下的可用性。流控机制应基于数据服务（API）重要性、后端处理能力及业务需求合理设定，防止突发流量对数据库或计算资源造成过载冲击。

2．流控策略与限流方式

数据服务（API）可通过请求速率限制（QPS限流）、调用配额等方式进行控制。例如，对于计算量较大的查询接口，可限制其每秒最大调用次数（如20次），超出阈值的请求可采取拒绝（HTTP429）或排队处理，确保后端资源不被滥用。

3．数据服务（API）访问等级与差异化配额

对于对外开放的数据服务（API），可基于用户等级配置不同的配额策略，区分内部调用、合作伙伴、公共用户等不同类型的访问权限，合理分配系统资源。

4．生产环境与调试阶段的流控管理

在数据服务（API）调试和开发测试阶段，流控策略默认不生效，但在生产环境中必须严格执行，所有数据服务（API）在发布前应经过流控策略评估，确保其限流策略与后端服务能力匹配，以维持系统的高可用性、可扩展性及安全性。

（三）授权管理

认证完成后，需基于访问控制列表（ACL）、角色权限、属性控制等方式进行授权管理，确保不同用户或应用仅能访问其被授权的数据服务。

1．数据服务（API）级别授权

每个数据服务（API）仅允许被授权的用户或应用调用，即使具备有效Token或AppKey也无法访问未授权的数据服务（API）。应采用最小权限原则，仅向业务所需的主体开放相应数据服务（API），避免一揽子授权。

2．角色权限模型

可采用IAM角色进行权限分级，如“数据查看者”角色只能访问只读数据服务（API），“数据管理员”角色可访问管理数据服务（API）。可在Token或App信息中嵌入角色属性，后端服务依据角色确定数据访问权限。

3．授权审批流程

数据服务（API）访问权限需经数据接口所有者或管理员审批，授权记录必须保存，确保授权过程可追溯。未经授权的调用应返回“未授权”错误，并支持调用方通过数据平台提交授权申请，由运营人员进行审核。

（四）细粒度权限控制

在数据共享中，不同调用方对数据的访问范围可能不同，因此需要基于数据级、列级、行级等维度进行精细化权限管理，以保证数据最小化可用。

1．数据级授权

不同应用或用户访问的数据集不同，如不同合作伙伴仅能查询自己的业务数据，而不能访问其他合作方的数据。可通过应用绑定静态参数（如partner_id）方式，在数据服务（API）查询时自动添加筛选条件，确保调用方仅能获取与自身相关的数据。

2．列级权限控制

对于涉及敏感字段的数据服务（API），应基于访问者身份动态调整返回数据，如高级权限用户可查看完整数据，普通用户则仅能访问部分字段，或返回脱敏数据（如屏蔽身份证号部分位数）。

3．多级授权

对于关键数据服务（API）可实施二级授权，即使调用方已获取Token，仍需额外的授权码、管理界面确认或MFA认证才能执行敏感操作，如修改类数据服务（API）或批量导出数据服务（API）。

（五）密钥管理

对于基于数据服务（API）认证的密钥（AppKey/AppSecret）及其他访问凭据（如AK/SK），需制定严格的密钥管理规范，包括生成、分发、存储、轮换和吊销策略。

1．密钥生成与存储

所有密钥由系统随机生成，AppSecret仅在创建时展示一次，由开发者妥善保存，严禁明文存储在代码中或打印到日志中，建议存储在安全配置管理系统中。

2．密钥轮换

建议每季度或至少每年定期更换AppSecret，防止长期暴露的密钥被滥用。所有轮换操作需记录日志，并在更换后及时通知开发者更新调用配置。

3．密钥吊销

如发现密钥泄露风险，可在数据开放共享平台主动吊销或重置密钥，并立即通知受影响方进行更换。密钥的创建、修改、重置记录需完整留存，供审计追踪。

（六）访问日志与审计

所有数据服务（API）访问及管理操作必须记录日志，并符合可追溯、可审计要求，以确保访问行为合规可控。

1．日志管理

所有数据服务（API）访问请求需记录调用时间、调用方身份、访问API、返回状态等信息，并至少保存6个月，重要系统建议存储1年以上。

2．异常监测

系统应定期分析访问日志，监测异常模式（如突发大量API调用、非业务时间段的访问），并提供数据支持，以便识别潜在风险并优化安全策略。

3．安全事件响应

如发生数据泄露、未授权访问等事件，审计日志应作为关键证据，追溯责任主体，并采取相应措施（如吊销权限、加强访问限制）。