角色与安全
FortressFlag 自带四种角色和一组生产环境保护，它们围绕一个想法设计：在非生产环境里快速行动应该毫不费力，而改变生产环境应该要么需要合适的角色，要么需要第二个人。
| Viewer | Developer | Admin | Owner | |
|---|---|---|---|---|
| 查看 flag 和团队 | ✓ | ✓ | ✓ | ✓ |
| 更改非生产环境 | ✓ | ✓ | ✓ | |
| 提议和批准生产变更 | ✓ | ✓ | ✓ | |
| 直接更改生产环境 | ✓ | ✓ | ||
| 查看 SDK 密钥 | ✓ | ✓ | ✓ | |
| 签发和吊销 SDK 密钥 | ✓ | ✓ | ||
| 管理团队、项目和环境 | ✓ | ✓ | ||
| 读取和导出审计日志 | ✓ | ✓ | ||
| 账单、用量和组织策略 | ✓ |
几点表格装不下的说明：
- Viewer 和 Developer 只看得到被授予的项目。
- 没有人能授予高于自己的角色。Admin 可以邀请 Developer，不能邀请 Owner。
- 完整的矩阵在应用内发布，所以你在控制台里看到的，始终反映服务器实际执行的。
生产变更：第二双眼睛
Section titled “生产变更：第二双眼睛”Developer 不能直接写入生产类别的环境——但也不必等 Admin。Developer 提议一次变更（一次切换、一次规则编辑），任何第二个人——另一位 Developer 或更高角色——审核并批准它，批准即应用。
这个形态是有意为之的，作为买家值得理解：
- 这是同伴审核，不是层级审核。两位 Developer 一起就能改变生产环境。要点在于，Admin 以下没有任何一个人能独自改变它。
- 自我批准一律拒绝——按人，而不是按角色。即使是 Admin 也不能批准自己的提案。
- 审计日志会记下双方的名字，在每一个被应用的提案上——谁提议的，谁批准的。
Admin 和 Owner 仍然可以直接写入生产环境；提案路径的存在，是为了让团队其他人有一条安全的进入路线。
布尔 flag 的状态可以定时：周五 09:00 UTC 把 holiday-banner 打开。变更对每一个读取方都在选定的时刻精确生效，而对一个环境做定时需要的权限，和现在就写入它所需的权限相同——一个定时就是一次带时间戳的写入，它被要求达到同样的标准。
每一次状态变更都会落进一份只追加的审计日志：谁、做了什么、什么时候、从哪里，以及变更前后的值。Admin 和 Owner 可以在应用内用过滤器浏览它，并导出为 CSV——用于事故复盘、合规请求或审计师。演练见导出审计日志。