工作区就是那条边界，而钱从来不经我们的手。

01 · 就绪度一览

三种状态，分开说。

02 · 身份与授权

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

• Clerk 负责验证用户与当前的组织，而生产环境的运行实例带着那道验证需要的身份密钥。
• 要开启一次应用会话，必须有启用中的工作区，而且数据库里要有这个人的成员记录，完全对得上。
• 权限以数据库里的角色为准：所有者、管理员、设计师、运营人员、查看者，各有各的权限。
• 常规授权完全不看服务商那边的组织角色；只有「第一位所有者」的开通流程是个很窄的例外。
• Studio 的页面和 API 默认都要通过身份验证。具名的例外有两个：Stripe 带签名的那一条 webhook POST，以及 /api/health/ready 这个就绪端点——它是刻意公开的，报告平台此刻服不服务得了客户，不带任何客户数据或凭证，而且有一支巡检每十五分钟打它一次。你可以自己去开。
• 本地开发用的绕过机制，必须同时处于开发模式、显式打开开关，而且主机名指向本机，或以 .localhost 结尾。

一个工作区只有一位所有者，所以团队邀请、服务商与数据库之间的成员同步、改角色的自动化与审计事件，都不在这一页的范围里。

03 · 租户数据的边界

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

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

经过评审的迁移，对应用程序角色够得到的每一张租户数据表，都启用并强制行级安全；任何租户查询之前，工作区范围都已经在事务里设好。至于部署上去的数据库角色有没有带着绕过权限，那是要在生产的 Postgres 服务上做的运维核对，不是应用程序能自己证明的事。

04 · 请求与文件安全

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

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

05 · 上线发布安全

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

上线会把一次请求绑定到一个不可变的、已审核的版本。资格由项目实际用到的组件、它们需要的模块，以及相关的交付替换算出来。Naratake 项目是一个背后有数据库的完整应用：完整交付会开好那个数据库与后台，由 Pro 套餐销售；纯店面交付是同一个网站拿掉写入面，拿掉了哪些会逐条列在发布报告里。一个工作空间能请求哪一种，由提交事务内的权益决定，不是由前端决定。

1. 01
   冻结

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

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

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

3. 03
   验证

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

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

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

完整交付会为网站开一个自己的数据库与商家后台，访客送出的订单、订位、预约、顾客资料与名单都存得住。只有套餐同时具备商务与预约两个模块的工作空间才拿得到。纯店面交付发布的是同一个网站但不含访客会写入的部分，被移除的每个区块都会列在发布报告里。已发布网站的线上刷卡，用的是商家自己的 Stripe 密钥：发布时从工作空间的密钥保险库读出，只写进那一个网站；两把必须齐全且模式一致，否则网站会以「没有结账」发布，而不是发布一个坏掉的结账。那笔钱 Naratake 从不经手，也不抽成——Stripe 自己的刷卡手续费照收，在哪里都一样。你已经拥有的自定义域名，两个套餐各绑一个，并为它签发 HTTPS。

06 · 支付的边界

支付在生产环境已经配置好，而且配置不齐就一律拒绝。

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

服务商的客户、结账与订阅标识，都走一个权限很窄的专用计费角色；普通工作区的数据库账号碰不到全局计费记录表。生产环境里，套餐目录与它的 Stripe 价格映射都读得出来、结账按当前模式配置完成、webhook 签名密钥也在。这三项运行中的服务会逐项检查，少一项就把自己标成未就绪，因为「卡刷得过去、东西却开通不了」正是最该拦下来的失败。另有一支每小时运行的巡检，重读那些流程拒绝套用、又会动到钱的 webhook 决定；只要还有没清掉的，它就会失败。

07 · 我们的主张到哪里为止

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

生产环境一定走 HTTPS，而传输与存储的保护，建立在我们配置并持续重读的那些服务商上。我们把这件事当成拿得出来给你看的工程，而不是一套通过独立认证的加密方案。

08 · 客户要管的部分

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

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

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

09 · 报告安全问题

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

发一封简短的邮件，说明受影响的 Naratake 网址或界面、影响范围、可以复现的步骤，以及一个安全的概念验证。请不要访问其他客户的数据、影响服务运行、把内容带走、做拒绝服务测试，也不要在邮件里附上有效的密钥或敏感个人信息。报告会直接送到写这段代码的工程师手上。我们没有公开的漏洞赏金计划。