安全架构概览:Rexfin 如何保护你的财务数据

安全页面往往是一堆形容词的堆砌,“企业级”“银行级”。对一个正在决定是否把真实报表数据交给某个工具处理的财务团队来说，这没什么用。真正有用的是实际的架构:什么被加密了，谁能看到什么，出错时会发生什么，事后又有什么证据可查。以下就是这些问题的答案，达到一个安全评审人员真正会追问的细节程度。

加密与隔离，直白说明

数据在传输中使用 TLS 加密，静态存储时使用 AES-256 加密。任何已连接系统的凭据都保存在一个独立的密钥存储中，而不是应用配置里。每个组织的数据和模型都与其他所有组织的数据和模型在逻辑上隔离，你的任何数据都不会被用于训练共享模型或第三方模型:你的报表和你的模型始终留在你所在组织的边界之内，不会被并入任何地方的通用训练集。

默认拒绝而非默认放行的访问控制

权限背后的设计原则说起来简单，实践中却很容易做错:对一份文档、一个数字或一条来源引用的每一次读取，都要经过同一个访问决策，而这个决策默认是拒绝访问，而不是授予访问。如果一个用户没有被明确授予某项访问权限，答案就是否定的，而不是“界面上不显示，但底层其实还能访问”。明确的拒绝始终优先于明确的允许，因此通过某一条路径(比如群组成员身份)获得的访问权限，仍然可能被一条明确点名该用户的更细粒度规则所阻断。

这一点之所以重要，是因为有一种很容易被忽视的失败模式:一份文档可以在界面中被隐藏，而 AI 助手仍然在工作上下文中拥有它，并可以基于它进行推理或引用。把某样东西从屏幕上藏起来，却让它在底层依然可以被访问，是一种披着友好外衣的泄露。Rexfin 在决定 AI 助手可以检索和引用什么内容的同一层实施访问控制:如果一个人打不开某份文档，负责回答其问题的助手同样看不到它。

角色叠加在这个基础决策之上:谁只能查看数字，谁可以在自己有权限的板块内编辑模型，谁可以代表组织管理访问权限和导出内容。任何角色都不能凌驾于底层的访问检查之上，即使一个人拥有广泛的编辑权限，他依然无法触碰或导出一个从未被授权访问的板块。

到数据层的每一次连接都经过身份验证并受到限定

在内部，负责保存已提取数字并运行核验的服务永远无法被直接访问，每一次请求都携带一个特定的、受限定的凭据，并且只经由私有网络传输，绝不经过公共互联网。一个没有有效凭据的请求会被直接拒绝，不存在退回到开放的、未经身份验证的读取这种情况。而且，如果某次部署不知怎么以一个占位凭据启动，应用会直接拒绝启动，而不是带着一套纸面上存在、但实际上并未启用的安全控制运行下去。

一份可以证明未被篡改的审计轨迹

记录“谁做了什么”是基本要求，更难的问题是证明这份日志事后没有被悄悄修改过。Rexfin 的访问和操作日志采用哈希链结构:每一条记录都包含前一条记录的加密哈希值，因此任何对记录的篡改、删除或插入都会在那个确切的位置打断这条链，而一次核验检查可以走完整条链，并精确报告断裂发生的位置。这把“我们保留日志”变成了一件可以核验的事情，一种你可以验证的完整性，而不是一个只能凭信任接受的承诺。想了解这套原则如何延伸到每一个生成的答案，请见答案审计日志。被拒绝的访问尝试同样会被记录，而不仅仅是成功的操作，因此试探性地访问你不该访问的内容，这个行为本身也会在轨迹中留下痕迹。

这如何与平台的其他部分相连

安全架构不是事后加装到产品上的附件，它是同一种“默认拒绝”的本能，体现在核验如何运作中(一项未解决的检查会被诚实地报告出来，而不是被猜测),也体现在摄取如何运作中(一份无法分类的报表会被隔离，而不是被强行处理)。“拒绝而非假设”这一原则贯穿访问控制、核验和摄取的方方面面，因为一个建立在经得起推敲的数字之上的平台，必须把同样的标准应用于谁能看到这些数字，而不只是这些数字是否正确。

关于认证:我们的信息安全项目参照 ISO/IEC 27001 风格的控制措施设计，这是海湾合作委员会及政府相关买家实际会要求的标准，我们也明确说明正式的第三方认证尚未启动，而不是暗示审计已经在进行中。完整、最新的项目状态请见信任中心。如果你对海湾合作委员会数据驻留有具体要求,数据驻留选项介绍了目前可用的方案。

适用人群

适合任何采购评审中会提出比一份市场页面更尖锐问题的人:需要在事后能够重建一次权限变更的合规负责人，需要确认 AI 助手不能看到其用户看不到的内容的 CFO,想知道一次部署失败会发生什么的 IT 负责人。预约演示,我们会按照你的评审所需的细节程度，详细讲解数据处理、访问控制和部署方式，或者阅读主题栏目概览了解更全面的图景。