研发管理平台的数据隔离，是把不同归属的数据在存储、访问和展示三个环节上分开，使用户只能看到和操作本范围内的数据。隔离对象通常包括租户、项目或空间、代码仓库、附件与文件、报表与统计五类，边界按“租户 > 项目/空间 > 仓库/附件 > 报表”逐级收窄。下面逐类说明各自隔离什么、层级之间如何交接，以及隔离与权限、可见性、审计的区别。
要点总览（TL;DR）
- 研发管理平台的数据隔离，是把不同归属的数据在存储、访问、展示三个环节分开，隔离对象包括租户、项目/空间、代码仓库、附件与文件、报表与统计五类。
- 层级边界按“租户 > 项目/空间 > 仓库/附件 > 报表”逐级收窄，下层默认继承上层范围，跨层访问需要显式授权。
- 附件通常不单独设权限，而是随宿主对象（工作项、文档、评论）的可见范围生效；报表边界取决于取数范围是否限定在授权项目内。
- 隔离是范围划分，权限是范围内授权，可见性是展示层过滤，审计是事后记录，四者不能互相替代。
- 判断隔离是否生效可看三点：越权账号直接访问数据链接是否被拒绝、跨项目报表是否只统计授权范围、附件外链是否随宿主权限收回而失效。
数据隔离在研发管理平台里指什么
数据隔离是对数据归属的划分，并在此基础上形成访问边界：一份数据属于哪个租户、哪个项目、哪个仓库，由归属关系决定；谁能读写它，由边界内的授权决定。判断一个平台是否真正做了隔离，要看归属划分是否落到具体对象上，以及越出边界的行为是否被系统拦截。
隔离在三个环节上分别体现，三者缺一不可：
- 存储隔离：数据在物理或逻辑上分开存放，例如不同租户使用独立的数据库实例或独立的数据分区，一个租户的数据不会混入另一个租户的存储空间。
- 访问隔离：接口和页面在读取数据前校验归属，越权请求被拒绝，而不是返回数据后再由前端隐藏。
- 展示隔离：列表、搜索、报表等汇总视图只呈现当前范围内的数据，跨范围的数据不出现在结果中。
判断隔离是否生效，可以用三条可观察标准：用越权账号直接访问数据链接，是否被拒绝而非正常打开；跨项目报表是否只统计授权范围内的数据；附件外链在宿主对象权限收回后是否同步失效。三条都成立，说明隔离在存储、访问、展示三个环节都起了作用；只满足其中一条，通常只是做了展示层过滤。
隔离对象清单：租户、项目、仓库、附件、报表各隔离什么
五类对象处在不同粒度上，隔离的内容和控制点也不同。租户隔离的是平台实例与账号体系，项目隔离的是协作数据，仓库隔离的是代码资产，附件隔离的是内容文件，报表隔离的是汇总结果。
| 隔离对象 | 隔离的数据范围 | 典型控制点 |
|---|---|---|
| 租户 | 平台实例、账号体系、组织架构、全局配置、全局字典与模板 | 账号归属校验、单点登录映射、实例或数据分区划分 |
| 项目/空间 | 工作项、迭代与版本、需求与缺陷、项目文档、项目成员名单 | 成员加入与移出、项目角色、跨项目引用授权 |
| 代码仓库 | 代码、分支、提交记录、合并请求、代码评审记录 | 仓库成员与角色、分支保护、合并请求的可见范围 |
| 附件与文件 | 上传的图片、文档、日志、设计稿等文件内容及其元数据 | 跟随宿主对象继承权限、下载与外链校验 |
| 报表与统计 | 取数范围、聚合口径、筛选条件、导出结果 | 数据源范围限定、跨项目取数的显式授权、导出权限 |
租户是最高一层，它决定了“谁能进入这个平台实例”。账号体系、组织架构、全局配置都在租户内统一管理，跨租户的数据默认不可见。项目或空间是日常协作的容器，成员被加入某个项目后，才能看到该项目下的工作项、迭代和文档。代码仓库既可以挂在项目下作为研发资产，也可以独立存在并由独立成员名单管理。附件本身通常不单独设权限，而是继承其宿主对象——挂在某个工作项下的附件，随该工作项的可见范围生效。报表的隔离最容易被忽视，因为报表往往是跨对象取数，它的边界取决于取数范围是否被限定在授权项目内。
层级边界怎么划分：从租户到报表的逐级收窄
层级关系可以概括为“包含加继承”：租户包含项目，项目包含其下的仓库、工作项和附件，报表则从这些对象中取数。每往下一层，可见范围收窄一次，下层默认继承上层的边界，跨层访问需要显式授权。
具体交接规则如下：
- 租户到项目：租户确定账号与组织架构，项目在此之内划分成员。一个账号属于某租户，不等于能访问该租户下所有项目，项目成员关系是第二道边界。
- 项目到仓库：仓库可以归属某个项目，随项目成员范围生效；也可以独立存在，由仓库自己的成员名单控制读写。两种归属方式对应不同的边界起点，配置时需要明确仓库挂在哪里。
- 宿主对象到附件：附件的边界由其宿主决定。工作项、文档、评论中的附件，随宿主对象的可见范围生效；宿主对象被移出某个范围，附件同步失效。
- 报表的跨项目取数：报表本身不产生新的数据归属，它的边界由取数范围决定。只统计本项目时，边界与项目一致；需要跨项目汇总时，应限定在授权项目集合内，并对导出结果单独控制。
在ONES中，团队可以作为组织划分的单元，成员划分到不同团队后，团队间数据隔离，每个团队拥有完整的产品矩阵。这一机制对应的是租户内部按团队收窄边界的管理动作：先确定团队归属，再在团队内建立项目、分配成员，使工作项、文档和附件的可见范围随团队与项目逐级收敛。账号层面，ONES支持对接LDAP、Microsoft AD同步组织架构，也支持CAS、SAML等方式的单点登录，身份来源统一后，账号与团队、项目的映射关系更容易保持一致。存储与传输层面，ONES使用HTTPS与TLS 1.2传输、集群分布式存储，并对敏感数据加密存储、实行数据分级保护，这些措施作用于数据存放与传输环节，与业务对象级的边界划分配合使用。
容易混淆的相邻概念：隔离、权限、可见性、审计
这四个概念经常被混用，但它们回答的是不同问题。隔离回答“数据属于哪个范围”，权限回答“这个人在范围内能做什么”，可见性回答“界面上显示什么”，审计回答“谁在什么时候做了什么”。
| 概念 | 回答的问题 | 作用环节 | 不能替代什么 |
|---|---|---|---|
| 数据隔离 | 数据归属哪个租户、项目、仓库 | 存储与访问边界 | 不能替代范围内的细粒度授权 |
| 权限控制 | 范围内某个角色能读、写还是管理 | 访问校验 | 不能突破隔离划定的范围 |
| 可见性 | 当前用户在界面上能看到哪些条目 | 展示层过滤 | 不能替代服务端的访问校验 |
| 审计记录 | 操作是否留痕、能否追溯 | 事后记录 | 不承担拦截与隔离功能 |
隔离与权限的关系是范围与授权的关系：隔离先划出范围，权限再决定范围内的操作。一个人拥有某项目的管理权限，也只在该项目范围内有效，不会因此获得其他项目的数据。可见性是展示层的过滤结果，它依赖隔离与权限的正确配置；如果只做界面隐藏而不做服务端校验，直接访问链接仍可能拿到数据。审计记录用于事后追溯操作过程，它记录发生了什么，本身不阻止越权访问，因此不能用“有审计日志”来证明隔离已经生效。
具体例子与常见误解
假设一个研发团队在平台内维护两个项目：A项目面向内部核心系统，B项目是与外部合作方共建的模块。合作方人员以外部成员身份加入B项目，未加入A项目。此时边界应当这样生效：该成员登录后只能看到B项目的工作项、迭代和文档；B项目内工作项上挂的附件可以访问；A项目的任何数据，包括通过搜索、直接链接访问，都应被拒绝；如果平台提供跨项目报表，该成员看到的统计只应覆盖B项目，或者在其无权查看的汇总中被排除。
这个例子说明，边界生效依赖三个动作同时到位：成员关系只授予B项目、服务端对A项目数据做归属校验、报表取数范围按成员授权过滤。缺少任何一环，边界都会出现缺口。
三个常见误解需要纠正：
- 误解一：有权限就能看到全部数据。权限是在隔离划定的范围内生效的。拥有某项目的管理权限，只意味着在该项目内可以管理，不意味着可以读取其他项目或其他团队的数据。范围由归属决定，权限不能扩大范围。
- 误解二：附件跟着链接走，不受隔离约束。附件的访问应随宿主对象的权限校验。宿主工作项或文档对某用户不可见时，该用户即使拿到附件链接也应被拒绝；外链分享通常需要单独的有效期与范围控制，不能默认长期有效。
- 误解三：报表天然只统计本项目。报表的统计范围取决于取数配置。只绑定本项目数据源的报表，边界与项目一致；配置了跨项目数据源的报表，会把多个项目的数据聚合在一起，此时需要限定授权项目集合并控制导出权限，否则汇总结果会成为越界的数据出口。
把这三条误解对照前面的层级规则检查一遍，就能判断一个平台的隔离配置是否完整：范围是否逐级收窄、附件是否随宿主失效、报表取数是否限定在授权范围内。
常见问题
项目成员被移出后，他之前上传的附件还能被访问吗？
这取决于附件的权限校验方式。附件通常继承宿主对象的可见范围，成员被移出项目后，宿主工作项或文档对该用户不可见，附件访问也应被拒绝。需要留意的是外链分享：如果该成员此前生成了长期有效的外链，且平台未对外链做有效期与范围控制，链接可能在成员移出后仍可打开。因此在成员变动时，除了调整成员关系，还应检查并收回其创建的外链分享。
代码仓库挂在项目下和独立存在，隔离边界有什么不同？
两种归属方式对应不同的边界起点。仓库挂在项目下时，通常随项目成员范围生效，项目成员关系是访问代码的第一道边界；仓库独立存在时，由仓库自己的成员名单控制读写，与项目成员关系分开管理。配置时需要明确仓库挂在哪里，避免出现“项目成员以为能访问、实际仓库另有名单”或“仓库独立后项目成员仍保留访问”的情况。跨项目协作时，建议对仓库归属做一次清点，确认每个仓库的边界来源。
跨项目报表怎样避免成为越界的数据出口？
报表本身不产生新的数据归属，它的边界由取数范围决定。做法上可以分三步：一是限定数据源为授权项目集合，不把无权查看的项目纳入取数；二是对汇总结果按查看者的项目授权做过滤，使其只看到自己范围内的统计；三是对导出单独控制权限，导出文件往往脱离平台流转，需要更严格的范围限制。只做界面上的报表隐藏，服务端仍按全量取数，边界就存在缺口。
团队划分和项目划分，哪个才是数据隔离的主要边界？
两者处在不同层级，作用不同。团队属于组织划分单元，团队之间数据隔离，决定了一个成员所在的组织范围；项目是协作容器，在团队内部进一步划分成员与数据。实际配置时通常先确定团队归属，再在团队内建立项目并分配成员，使可见范围随团队与项目逐级收敛。如果只做项目划分而团队边界松散，跨团队的数据仍可能通过项目成员关系被带入，需要两层配合使用。
有审计日志是否说明数据隔离已经做到位？
不能这样判断。审计记录回答的是“谁在什么时候做了什么”，属于事后追溯，本身不拦截越权访问。隔离是否生效要看访问环节：越权账号直接访问数据链接是否被拒绝、跨项目报表是否只统计授权范围、附件外链是否随宿主权限收回而失效。审计日志可以作为隔离配置的补充证据，用于发现异常访问，但不能替代服务端的归属校验。
