云 EPM 的数据安全怎么验：六项机制与责任划分

图：云 EPM 的安全机制（贝则科技）

直接回答：验云 EPM 的数据安全，一共六项机制：身份与访问、租户隔离、加密与密钥、审计留痕、备份与恢复、数据出口管控。核心判断是，安全能力不靠问卷结论，靠能不能拿出可复现的证据；厂商答「符合行业标准」等于没答。关键数字上，一个 200 家法人、5 级合并层级的集团，云上活跃账号常以千计，只要有一个离职账号未回收，全套合并底稿就等于对内部公开。

合并报表与预算系统的数据，性质上和一般业务系统不同。它装的是集团尚未披露的经营结果、未来的盈利预测、以及各家子公司的完整损益。对上市公司来说，这些东西在披露前属于敏感信息，泄露的后果不是罚款，是监管问询与市场信任。

偏偏这类系统的用户面很宽。总部财务、各板块财务、子公司填报人员、外部审计师、偶尔还有券商和评级机构，几百上千个账号分散在几十个组织里，权限规则复杂到没人能完整说清。上云之后，这套复杂度并没有消失，只是从机房搬到了别人机房里。

所以云 EPM 的安全验证，本质是两件事：机制是否真实存在，责任是否划得清楚。前者靠证据，后者靠合同。

云 EPM 的数据安全是指什么，验的是哪一层

云 EPM 的数据安全，是指在使用云端部署的合并、预算、管理报告系统时，围绕数据的访问、传输、存储、使用、销毁全过程中，保护其机密性、完整性与可用性的机制总和。它包含三个层次：平台层由云服务商负责的物理与基础设施安全，应用层由产品方负责的身份、权限与加密机制，以及使用层由客户自己负责的账号治理与数据分类。

绝大多数安全评估只问到应用层就停了。问卷发过去，对方答「数据加密存储、支持单点登录、通过等保三级」，评估结束。这三句话都对，但都没有回答真正的问题：加密的密钥谁持有，单点登录能不能管到子公司层级，等保三级覆盖的是哪个系统边界。

验证要往下追一层，追到能拿出东西看。加密要看到密钥管理方式与轮换记录，权限要看到实际的角色配置截图与审批流，等保要看到测评报告里的系统范围。拿不出证据的，就是没有。

六项机制，逐项看证据

下面六项是云 EPM 场景里真正决定风险敞口的机制。每项都附上可验证的证据形态，问的时候可以直接照着要。

机制	验什么	可接受的证据
身份与访问	是否支持与企业身份源对接，权限能否按法人、按报表、按单元格粒度控制	角色配置清单、单点登录对接方案、权限矩阵样例
租户隔离	多租户环境下数据是否物理或逻辑隔离，隔离边界在哪一层	架构说明、隔离机制描述、可参考的第三方测评范围
加密与密钥	传输与存储是否加密，密钥由谁生成、谁保管、多久轮换	加密算法与协议清单、密钥管理说明、轮换周期
审计留痕	登录、查询、导出、规则变更是否留痕，日志保留多久，客户能否自主导出	日志字段样例、保留周期说明、导出权限与操作路径
备份与恢复	备份频率、保留份数、恢复演练是否做过、恢复时长承诺	备份策略文档、最近一次恢复演练记录、恢复时长指标
数据出口	数据能被谁以什么方式带出，导出是否受审批约束，接口是否限流限域	导出审批流设计、接口白名单机制、异常导出告警规则

这六项里，第四项与第六项的验证价值被普遍低估。审计日志的意义不在于出事之后追责，而在于让「谁在什么时候导出了什么」这件事变得可知。很多集团的真实泄漏路径不是黑客攻破，而是内部人员把整张合并底稿导出成表格带走，全程没有任何记录。数据出口管控同理，未加约束的批量导出功能，等于给每个账号配了一把复制数据的钥匙。

责任划分：厂商管什么，客户管什么

云安全的常见误解是把它当成一个整体交出去。实际上责任是分层的，分不清就会出现「都以为对方管」的真空地带。下面这张表可以作为合同谈判的底稿。

责任项	云服务商	产品方	客户
机房物理安全	负责	不涉及	不涉及
平台漏洞修补	负责	配合	不涉及
应用权限模型	不涉及	负责设计	负责配置与复核
账号生命周期	不涉及	提供工具	负责执行
数据分类分级	不涉及	不涉及	负责
备份与恢复演练	负责平台层	负责应用层	参与演练确认
导出行为审批	不涉及	提供机制	负责审批执行

看这张表会发现，客户自己承担的责任比想象中多。权限模型是产品方设计的，但配成什么样、谁拥有什么权限，是客户自己的事；账号该开该关，更是完全在客户手上。很多安全事件追到底，根因都在客户侧的执行，而不是平台能力不足。

这也是选型时容易被忽略的一条：产品方能不能把权限模型做得足够细，以及能不能提供权限复核的便利工具。做不到这两点，客户侧的治理就无从下手。

三个常被跳过的验证动作

问卷之外，有三件事值得在选型阶段亲自做一遍，成本不高，信息量很大。

1. 要一次恢复演练记录。不是要备份策略文档，是要最近一次实际演练的时间、范围、结果和耗时。有记录的团队，说明这件事被当作流程在跑；只有策略文档的，说明还没真正恢复过。
2. 现场做一次权限复核。请对方在演示环境里，把某个子公司填报人员的权限完整拉出来看一遍，再模拟一次组织调整后的权限变更。这个过程会暴露权限模型的真实颗粒度，比任何架构图都清楚。
3. 要一份日志样例。真实的一条登录日志、一条导出日志、一条规则变更日志，看字段是否足以支撑追溯。字段不全的日志，留着也没用。

这三件事做下来，通常半小时到一小时，比读三十页安全白皮书有效。

资质证书能证明什么，不能证明什么

ISO27001、等保测评、SOC 报告这类材料，在招标环节经常被当作安全能力的凭证。它们确实有价值，证明组织层面建立了信息安全管理体系，也经过了外部审视。但它们证明的是体系存在，不是这个具体的合并系统在你这套用法下是安全的。

看这类材料时，注意三件事。一，测评范围覆盖的是哪个系统、哪个机房，是否包含你要用的那个部署形态。二，测评时间，体系认证通常有有效期，过期材料不能作为依据。三，报告里的不符合项与整改情况，这部分往往比结论页更有信息量。

另外要区分「产品通过认证」和「某个部署实例通过测评」。前者是产品资质，后者才接近你的实际使用环境。这两者在销售材料里经常被混着说，问的时候要拆开。

贝则在这类项目里的做法

贝则自身的资质包括 ISO9001、ISO20000、ISO27001 与 CMMI，是国家高新技术企业与北京市专精特新企业，2025 年口径下的科技型中小企业。这些是组织层面的证明，落到具体项目上，做法是三条。

一是把权限设计前置到调研阶段。看账、梳股权、出场景清单的时候，同步梳理各角色的数据可见范围，权限矩阵和合并层级一起定，不留到上线前补。二是把账号治理写进交付清单，包括初始账号清单、权限复核流程、离职回收触发机制。三是驻场陪跑至少一个完整周期，权限相关的问题在这个阶段最容易暴露，也最容易顺手改掉。

产品侧，磐石合并报表系统与经纬全面预算系统都支持按法人、按报表、按操作类型的多级权限控制，BDM 数据管理平台负责取数与映射环节的通道管控。部署形态上支持本地、私有云与混合云，选择权在客户。

落地要点

给三条可执行的建议。选型阶段把六项机制逐项要到证据，拿不出证据的当作不具备；合同里附一张责任划分表，把客户侧的动作写成义务，避免交付后无人负责；上线后每季度做一次权限复核与一次恢复演练，把这两件事变成例行动作而不是年度项目。

安全这件事的特点是，平时看不见，出事时全是细节。把细节在选型阶段问清楚，比事后补制度便宜得多。

常见问题

Q：云 EPM 的数据放在云上，是不是比放本地风险高？

A：不能一概而论，取决于机制与治理水平。云服务商在物理安全、平台补丁、灾备能力上通常强于企业自建机房；但客户侧的责任更重，账号治理、权限复核、导出管控都要自己做。本地部署把风险集中在自己手里，云上则把风险分散到分层责任上，关键是每一层都有人负责。

Q：怎么判断权限粒度够不够细？

A：看三个维度能不能独立控制：法人范围、报表类型、操作类型。能按法人限定可见范围、能区分法定报表与管理报表的访问权、能区分查看与导出两种动作，基本够用。如果只能做到「按角色分管理员与普通用户」，那对集团场景来说太粗。

Q：审计日志要保留多久才合适？

A：没有统一答案，取决于监管要求与内部制度。实践上建议覆盖至少一个完整的年度审计周期，这样年报审计时能回溯全年的关键操作。更重要的是确认客户能否自主导出日志，如果调取日志要提工单等厂商处理，实际使用中基本不会去用。

Q：数据导出功能要不要直接关掉？

A：不建议一刀切。合并与预算的日常工作中，导出到表格做二次分析是刚需，关掉会逼出更隐蔽的绕行方式。更合理的做法是分层：常规范围的导出放开并留痕，大范围或含敏感科目的导出走审批，异常时间或异常频次的导出触发告警。

Q：混合云部署对安全有什么影响？

A：主要影响边界管理。混合云意味着数据在本地与云上之间有往返通道，这条通道的加密、鉴权、限流需要单独设计，不能默认继承两端的安全策略。另外要明确哪一侧是数据主副本，避免出现两套数据各自为政、口径不一致的情况。