我们的合作流程

保护您的业务记录。

加密、访问控制和经过测试的恢复方案分别保护业务的不同环节。开发前,我们会解释这些措施,并与您确认系统需要哪些保护。

决定谁能修改记录。

销售人员可以查看发票,财务人员可以记录付款。在下方切换角色,看看同一条记录对不同员工有何区别。

员工权限 · 发票访问交互示例

选择员工角色

此示例使用本地权限规则。生产环境的权限也必须在服务器端执行并测试。

INV-3091未付款

Evergreen Builders

S$2,592

销售角色只有查看权限

尝试记录付款,查看权限检查,再切换至财务角色。

改编自 Ceus One Demo · 虚构数据 · 无真实交易

基于角色的访问控制(RBAC)。 权限由团队商定,应用必须在服务器端执行。

了解业务如何恢复运作。

恢复测试应以可打开的发票、可核对的总额和可取回的文件为结果。我们先商定恢复目标,再据此测试。

备份副本记录、文件与配置

在独立环境还原

INV-3091已恢复副本

Evergreen Builders

S$2,592

  • 打开发票
  • 比较总额
  • 取回附件
使用虚构记录说明恢复过程。实际结果在项目恢复测试时记录。
恢复点目标(RPO)
商定从最近可恢复副本到事故发生之间,最多可接受损失多少近期工作。
恢复时间目标(RTO)
商定恢复可用系统的目标时间,再通过还原测试实测。
查看审查文件

掌握系统的自主权。

工作开始前,我们会商定您的所有权、可导出内容,以及另一家服务商接手所需资料。

  • 账户与访问权限

    记录各账户归属、您的访问方式,以及如何撤销 Ceus 的权限。

  • 记录与导出

    约定可下载记录与附件清单,并提供导出样本供团队检查。

  • 代码与交接

    书面条款涵盖代码所有权或许可、操作指引,以及系统依赖的服务。

各项保护如何配合。

纵深防御在登录到存储记录的每个阶段设置检查。这些是我们为项目确定范围并验证的控制措施。

  1. 您的团队

    MFA 与 FIDO2 通行密钥

  2. 传输连接

    TLS 1.3

  3. 应用程序

    服务器端 RBAC

  4. 您的记录

    AES-256 与密钥管理

服务商、设置、责任与例外会写入方案,并在上线前检查。
  • 账户保护

    MFA · FIDO2 / WebAuthn 通行密钥 · Argon2id

    即使密码被盗,也不应足以接管管理员账户。

  • 员工权限

    RBAC · 最小权限 · 租户隔离

    使用基于角色的访问控制按岗位限制操作,并通过租户隔离分开共享系统中各组织的记录。

  • 数据加密

    TLS 1.3 · AES-256 · 密钥管理(KMS)

    保护客户记录、发票和文件在系统间传输及存储时的安全。

  • 文件与凭证

    密钥库 · 凭证轮换 · 签名 URL

    服务凭证不能进入浏览器代码或版本库。支持时,私有文件使用有期限的签名下载链接。

  • 流量保护

    WAF · API 限流 · DDoS 缓解

    结合 Web 应用防火墙和请求限制,减少恶意流量、重复登录尝试,以及对高成本 API 操作的滥用。

  • 安全测试

    OWASP ASVS · SAST / DAST · SCA

    测试 SQL 注入、跨站脚本(XSS)和访问控制缺陷,同时扫描源代码与依赖。

  • AI 安全措施

    权限感知 RAG · 提示注入测试 · 工具白名单

    检索增强生成(RAG)必须在读取记录前检查权限。限制 AI 只使用获准工具,重要变更须由人工批准。

  • 审计日志与响应

    审计日志 · 事件关联 · 事件响应

    让重要变更可追溯,并在收到警报时为团队提供明确行动步骤。

  • 备份与恢复

    灾难恢复 · RPO / RTO · PITR 评估

    商定恢复目标,再评估时间点恢复(PITR),在支持时把数据库恢复到指定时间。

完整提纲包含实施检查和验收证据。独立测试与支持范围另行商定。

阅读完整审查提纲(英文)

了解团队需要审查的内容。

这些示例文件展示项目中需要记录的决定和检查项,使用的是虚构数据或空白字段。

Ceus Solutions示例文件

员工访问权限矩阵

Ceus One 示例 / 发票权限

商定各角色可查看哪些记录,以及可批准哪些更改。
角色查看发票记录付款
经理允许允许
销售允许拒绝
财务允许允许
拒绝访问测试
销售角色直接发起的付款请求必须被服务器拒绝。
授权访问测试
财务角色可以记录付款,该操作会出现在审计日志中。

由您的负责人批准角色权限;交付团队在上线前记录服务器测试结果。

仅作说明,不含客户数据,也不代表已完成审计。

可打印示例 · 1 页下载示例(PDF,英文)

关于数据的常见问题。

您或您的技术顾问可以与我们一起审查安全控制、服务商选择和验证结果。

SHA-256 有什么用途?

SHA-256 为信息生成数字指纹,也称哈希值。与可信原件的哈希值比较,有助于检查文件传输后是否发生变化。它不会加密文件,也不会保护文件内容的隐私。迁移时,文件校验和可以配合记录数量和余额核对使用。密码需要使用专门的密码哈希算法,例如 Argon2id;直接使用 SHA-256 不适合存储密码。

我们的信息会存在哪里?

我们会说明拟定的存储位置、接收记录的服务,以及可以访问记录的人员。项目检查涵盖传输和存储加密,以及如何撤销授予 Ceus 或其他服务商的权限。云托管负责部分系统保护;我们也会记录 Ceus、您的团队和托管服务商各自的责任。

AI 会使用我们的机密信息吗?

AI 功能应只能访问双方同意的数据来源。我们会记录哪些信息离开您的系统、由哪家服务商接收、在哪里处理,以及账户的数据保留和模型训练设置。客户记录、内部文件和消息历史需要分别决定。承诺不将数据用于训练,本身并不代表服务商完全不保留数据。

你们能满足我们的安全要求吗?

请在需求调研阶段提出要求,以便我们评估是否适合。独立测试、特定认证、私有托管或受监管业务,需要另行评估并确定范围。托管服务商获得认证,不代表在其平台上开发的应用也获得了认证。

从具体问题谈起。

不需要准备需求书,也不需要先弄懂技术原因。

说说您遇到的难题