平台安全

在 Nodux 里保护你公司信息的各项技术控制，写到足够细，方便你的 IT 团队评估。

账户访问

密码

密码用 bcrypt 保存。这是一种专门为凭据设计的哈希算法：它被刻意设计得很慢，所以就算有人拿到了数据库，暴力破解的代价也很高。

密码不以明文保存，也不用可逆的方式加密。Nodux 里没有任何人能读到用户的密码，即使直接访问数据库也不行：哈希无法还原。

会话

每个会话都使用一个签名令牌，24 小时后过期。过了这个时限就必须重新验证身份：在共用设备上忘了退出的会话，会自己失效。

找回密码

找回密码的链接只能用一次，并且有有效期。用第二次，或者过期后再用，都不会生效。

尝试次数限制

登录和找回密码都有频率限制：超过阈值后，接下来的尝试会在一段时间内被拒绝。

一个在别的实现里经常出错的细节：计数器存在数据库里，而不是服务器内存里。应用运行在多个实例上时，内存里的计数器会随实例数量成倍增加，实际限制最后会比配置的高得多。在这里，计数是唯一且共享的，并以原子方式递增。

企业之间的隔离

Nodux 是多租户系统：很多维修商使用同一套部署。一家的数据绝不能出现在另一家的屏幕上，这是整个系统最重要的要求，我们用两层相互独立的机制来解决。

第 1 层：应用

每一次查询都会被限制在发起查询的用户的范围内，依据的是一条统一的集中规则。只有一条规则，就避开了老问题：如果每个页面各自拼自己的过滤条件，只要有一个页面拼错一次就够了。

此外还有一项自动化测试：它启动整个系统，创建两家数据不同的企业，用全部四种角色把所有接口逐一走一遍，验证没有任何角色能访问到别家的信息。每次代码变更、发布之前都会运行。

第 2 层：数据库

在这之上，还运行着 PostgreSQL 的 Row Level Security（行级安全）：数据库在每次查询时自己执行过滤，不依赖应用记得去要求。即使某个编程错误漏掉了过滤条件，数据库也不会返回别家的数据行。

应用连接数据库时使用的是一个没有超级用户权限的数据库用户。这不是小细节：在 PostgreSQL 里，超级用户会完全绕过 Row Level Security，策略虽然存在，却什么也过滤不了。用普通用户连接，策略才真正生效。

传输与存储

对象	方式
浏览器 → Nodux	HTTPS 加 TLS。网站只通过加密连接提供访问。
Nodux → 数据库	在服务商的私有网络内使用加密连接，不暴露在互联网上。
文件和照片	对象存储，通过凭据访问。私有附件无法通过公开 URL 访问。
备份	由存储服务商进行静态加密。详见备份与连续性。

按角色划分的权限

权限不是一个个单独配置的：每个人有一个角色，角色决定他能看到什么。模型简单，就更难配错。

角色	范围
管理员	本企业的全部业务。只有这个角色能归档和执行破坏性操作。
客服专员	本企业的日常业务，但不包括管理员专属的操作。
销售	自己负责的客户。管理员可以把范围扩大到全部客户。
技术员	分配给自己的工作。
客户	自己的设备、工单和文件。看不到其他客户的任何内容。

审计日志

敏感操作都会记录下是谁、做了什么、什么时候做的。日志默认保留 180 天，如果你的企业需要更长的期限，可以配置。

监控

应用的错误会自动上报到一个错误跟踪系统，并带有告警。目标是在用户报告之前就发现故障。

平台状态（数据库、存储、邮件、备份）通过一个健康检查接口公开，我们每次发布后都会查看。

我们没有的东西

我们没有 SOC 2 认证，也没有 ISO 27001 认证。我们一开始就说清楚，免得你的团队在流程进行到一半才发现。如果你们的政策把它们列为硬性条件，最好今天就知道，而不是在最终审核时才知道。

我们能做的是：书面回答安全问卷，签署保密及数据处理协议，并演示本页任何一项控制是怎么运作的。请写信到 soporte@nodux.link。

报告漏洞

如果你发现了安全问题，请写信到 soporte@nodux.link，附上复现所需的细节。我们会回复你，并告诉你是怎么解决的。我们没有漏洞奖励计划，但我们承诺认真对待，也不会追究善意报告的人。