先确认真实身份
正式用户需要真实认证、受控邀请、安全 Session，并对敏感操作使用更强验证。
租户隔离
切换公司不能只是修改浏览器参数。
每一次请求都必须证明登录身份、当前公司成员关系、允许的角色，以及所请求记录或文件属于哪个公司。
公司成员关系在服务器判断
API 决定用户属于哪家公司。修改网址、浏览器储存值或查询参数不能获得其他公司的数据。
最小权限角色
平台管理员、尾程快递公司、DSP 管理员与司机权限分开，高风险操作必须有明确授权。
文件也属于租户
POD 照片、导出文件和附件需要公司所有权、签名访问与删除规则，不能使用公开网址。
重要操作可以审计
成员变更、数据导出、路线改派、POD 决定、恢复批准与安全设置都需要持久审计事件。
备份架构
单公司恢复和整个平台灾难恢复，是两个不同问题。
一家尾程快递公司不一定需要一套独立物理数据库，但必须有可证明的数据隔离、按公司生成的恢复包，以及不会覆盖其他租户的 Restore 流程。
按租户生成备份包
在同一个一致恢复点导出该公司的关系记录、文件清单、配置与审计引用。备份包需要加密、完整性校验，并先恢复到隔离环境进行验证。
完整数据库与对象恢复
通过自动数据库备份、对象存储版本或复制、基础设施配置和完整平台 Restore 计划保护整个系统。
如果合同、监管、风险等级或规模需要，仍然可以为某家公司采用物理数据库隔离。但物理隔离不能代替正确权限与恢复设计。
恢复手册
只有成功恢复过的备份，才真正有用。
恢复流程必须先证明范围与完整性，并取得批准，才可以把数据切回正式环境。
确认事故范围
记录受影响公司、时间范围、系统、可能原因以及提出恢复要求的授权人。
选择恢复点
验证备份完整性、文件清单，以及该恢复点是否包含需要的记录。
先在隔离环境恢复
恢复到隔离环境，验证租户边界，并对账订单、事件与对象文件。
批准后切回生产
使用书面批准，保护恢复点之后的有效变更，监控切换并保留完整审计记录。
正式上线门槛
这些控制必须实际验证，不能靠想象。
公开演示可以评估流程，但正式客户上线需要证据证明安全与恢复控制真的能工作。
| 控制项目 | 需要的证据 | 重要原因 | 上线门槛 |
|---|---|---|---|
| 身份认证与 MFA | 真实身份服务、安全 Session、邀请与账号恢复流程 | 避免演示身份被错误用于正式运营 | 必须完成 |
| 租户权限测试 | 覆盖 API、数据库与文件访问的自动反向测试 | 证明一家公司不能读取或修改另一家公司 | 必须完成 |
| 监控与告警 | 请求、后台任务、接口、备份和安全事件都有指标与负责人 | 让静默失败在影响运营前被发现 | 必须完成 |
| 备份与恢复演练 | 自动备份证据，以及成功的单公司和整个平台恢复测试 | 证明可以在约定目标内恢复数据 | 必须完成 |
安全常见问题
恢复设计必须早于第一次事故。
租户和恢复边界属于产品架构，不是出事以后临时增加的功能。
可以为每一家尾程快递公司单独备份和恢复吗？
架构可以支持按公司生成恢复包和定向 Restore。恢复必须先在隔离环境测试、验证并批准，才能切换正式数据。
独立数据库是否自动代表安全？
不是。物理隔离可以减少部分风险，但身份认证、权限、文件访问、密钥、审计、备份和人员流程仍然需要正确设计。
NaviBatch 目前承诺多少 RPO 和 RTO？
目前没有公开承诺生产恢复指标。恢复点与恢复时间目标需要根据运营范围共同约定，并通过备份监控与恢复演练证明。
真实订单进入系统前，先验收安全与恢复。
正式测试应该书面约定身份、租户边界、备份范围、恢复目标和验收证据。