先把边界说清楚，信任才谈得上。

01 · 就绪度一览

三种状态，分开说。

02 · 身份与授权

在哪里登录，决定不了你在 Naratake 里有什么权限。

• 只有配置好生产密钥时，Clerk 才会验证用户和当前的组织。
• 要开启一次应用会话，必须有启用中的工作区，而且数据库里要有这个人的成员记录，完全对得上。
• 权限以数据库里的角色为准：所有者、管理员、设计师、运营人员、查看者，各有各的权限。
• 常规授权完全不看服务商那边的组织角色；只有“第一位所有者”的开通流程是个很窄的例外。
• Studio 的页面和 API 默认都要通过身份验证；唯一的计费例外，是 Stripe 带签名的那一条 webhook POST。
• 本地开发用的绕过机制，必须同时处于开发模式、显式打开开关，而且主机名指向本机，或以 .localhost 结尾。

团队邀请、服务商与数据库之间的成员同步、改角色与移除的自动化、撤销权限，还有审计事件，我们都还不敢说已经做到可上线的程度。

03 · 租户数据的边界

浏览器没办法指定要动哪个工作区。

项目与素材的路由，工作区标识一律从服务器上已验证的会话取得。网址里只有项目或素材的标识，决定不了要访问哪个租户。数据库这一层用的是不能绕过权限的应用角色，并且在事务里先设好工作区范围，才开始查租户的数据。

代码库里有角色与行级策略的完整说明，但生产环境的数据库角色和迁移状态，仍必须在选定的 Postgres 服务上逐项核对过，才能上线。

04 · 请求与文件安全

不可信的输入，一律先撞到上限。

• 任何会改动数据的路由，都要有通过验证的角色，而且请求必须完全同源。
• 保存时会检查版本前置条件与幂等键；过期的写入会被拦下来，不会默默覆盖更新的版本。
• 导入的项目压缩包会逐项检查：路径是否规范、是不是只有一份项目文档、文件数、解压后大小、压缩比、JSON 复杂度、结构定义有没有支持，以及项目身份是否相符。
• 云端图片有大小上限、读取时逐段设限，而且只有在声明的格式与文件头特征字节相符、且属于支持的位图格式时，才会收下。
• 存好的项目包或素材要送出前，会先核对服务器算出的哈希值。
• 没设置好数据库或私有对象存储时，直接返回“服务不可用”；生产环境不会退回用浏览器或内存暂存。

05 · 上线发布安全

还不支持的东西，在切成正式版之前就会被拦下来。

点击上线，系统会把这次请求绑在一个已审阅、不可改写的版本上，再按你放的组件、它们需要的模块，以及相关的交付替换，算出这个项目能不能发布。Naratake 项目本身是完整的应用程序，后面接着数据库；只是目前云端上线先支持不需要数据库的店面网站，因为托管数据库服务还没接上。需要数据库的项目，会在开始构建、产出制品或动到任何服务商之前就被拦下来。

1. 01
   冻结

   把这次请求绑在指定的版本，以及服务器已验证过的项目包上。

2. 02
   在生产环境之外构建

   交给后台任务，按照固定的接口产出一份有上限约束的发布制品。

3. 03
   验证

   在切换正式版指针之前，先确认制品与发布状态都对。

4. 04
   切成正式版，或回滚上一版

   保留发布记录，随时可以选回先前验证过的版本。

云端上线目前还没覆盖需要数据库在跑的模块——订单、收款、订座、预约、客户数据，以及其他跟经营有关的功能。这是目前这条交付路径的限制，不是 Naratake 项目只能做到这样。自定义域名在这页同样不做任何承诺。

06 · 支付的边界

支付由服务器决定；配置不齐，就什么都不做。

设置完成后，浏览器只能挑一个核准过的方案代号。实际映射到 Stripe、生成规范的返回网址、在调用服务商之前先写下一条持久的幂等记录，都由服务器负责。Stripe 的 webhook 只有一条路由：它读取有大小上限的原始内容，验签名、验 API 版本，重复或乱序的事件则靠持久记录与游标处理。

服务商的客户、结账与订阅标识，都走一个权限很窄的专用计费角色；普通工作区的数据库账号不得接触全局计费记录表。信用卡号一律在 Stripe 自己的页面上输入，不会经过 Naratake 的表单。

07 · 我们没有声称的事

没有证据，就不挂信任徽章。

生产环境一定要走 HTTPS，但传输与存储的保护，最终还是取决于你选的服务商与设置。Naratake 不会把这件事包装成一套通过独立认证的加密方案。

08 · 客户要管的部分

安全，也是团队的日常习惯。

• 保管好登录用的账号；服务商提供多因素验证，就把它打开。
• 角色给刚好够用的就好；有人不再需要这个工作区，就把权限收回来。
• 不要把密码、私钥、客户的机密或信用卡号，贴进页面文案、项目备注、客服邮件或公开素材里。
• 每次上线前，把内容、链接、表单、政策、集成，还有对外公开的经营信息都看一遍。
• 在生产备份与恢复流程通过测试之前，重要的原始内容请自己另外留一份。
• 怀疑账号、工作区或已上线的网站被入侵，请尽快告诉我们。

数据怎么处理，请看隐私声明；什么能做、上线责任归谁，请看服务条款。

09 · 报告安全问题

请给我们足够的细节，让我们能安全复现。

发一封简短的邮件，说明受影响的 Naratake 网址或界面、影响范围、可以复现的步骤，以及一个安全的概念验证。请不要访问其他客户的数据、影响服务运行、把内容带走、做拒绝服务测试，也不要在邮件里附上有效的密钥或敏感个人信息。我们目前没有公开的漏洞赏金计划，也没有响应时间的承诺。