← 返回列表

一人公司安全基线：账号、密钥、备份与恢复

2026/9/13

B 方向·OPC 最佳实践（横切要害维度）。整个业务跑在少数几个账号上（域名/Cloudflare/GitLab/Paddle/LINE OA/Payoneer），一处失守全线瘫痪——这不是「锦上添花」而是上线前置项。

背景与问题

solo 开发者的攻击面与恢复力怎么配？公开的安全内容多为团队向，一人公司要哪些最小区块？账号丢失/密钥泄露/设备丢失三种灾难各怎么兜底？

发现

1. 密钥与账号卫生（事实，访问 2026-09-13）

  • indie 社区共识的「最简但最重要」清单：全账号 2FA（域名注册商/云控制台/邮箱优先）、密码管理器（Bitwarden/1Password，20+ 位独立密码）、密钥只进环境变量且 CI 里装泄露扫描（Gitleaks/TruffleHog）、定期轮换、数据库最小权限读写分离（Indie Hackers 清单、Cellopoint checklist）。
  • GitHub 账号是命门：Vercel 等部署面板由 GitHub 登录保护，主 GitHub 被攻破=灾难；建议开发用号与高价值账号分离、高价值账号上硬件密钥（同上、Mainmatter checklist）。
  • 密钥管理 indie 打法：不同项目/环境不共享密钥（一把泄露不能全线沦陷）、用云厂商托管加密存储（Cloudflare/AWS KMS）、轮换=换新料+杀旧料而非改变量名（Chad Nause·indie 密钥管理）。

2. 备份与恢复（事实，访问 2026-09-13）

  • 共识三条：自动备份异地存储、备份成功要有监控、恢复必须实测——「很多人在灾难发生时才发现备份根本恢复不了」（Mainmatter）；季度一次恢复演练进日历。
  • 硬件密钥（YubiKey ~$35/Solo 开源款）：皇冠账号（注册商/云/支付）配两把、分开存放；密码管理器本体用硬件密钥保护是 solo 恢复策略的地基（Yubico、1Password·硬件密钥说明）。
  • 一页纸应急文档是社区标配：泄露→吊销→轮换→查日志→通知，panic 时没文档会浪费最贵的黄金时间（Mainmatter）。

3. 公开内容空白：solo 的业务连续性（事实+推测）

  • 「founder 失能/账号继承」几乎没有系统化内容（本次检索确认）——而它同时是 opc-exit-microacquisition 的尽调项（买家要接管账号）与 APPI 义务项（japan-appi-data-compliance 五件套里的事故报告流程需要「谁能操作」的答案）【推测：封存的访问文档是三者共用的同一份东西】。
  • 哲学共识：简单压倒一切——安全的默认配置+备份+账号卫生，胜过叠加复杂安全栈（Kruw.io）。

结论

可行动启发：

  1. 上线前置的六件套（按本产品线栈映射）：密码管理器+全账号 2FA → 皇冠账号（域名注册商、Cloudflare、Paddle、LINE OA、Payoneer、GitLab）上硬件密钥两把分开存 → GitLab CI 密钥全部 masked+protected、装 Gitleaks → LINE channel token/Paddle webhook secret 季度轮换 → D1/R2 每日自动导出到独立账户 → 一页纸应急文档。
  2. 恢复实测进日历：每季度从备份在新环境拉起一次产品（含 LINE webhook 重绑与 Paddle webhook 重配），演练不过=备份不存在。
  3. 域名是皇冠上的皇冠：注册商账号最高防护（硬件密钥+专用邮箱+注册局锁），域名失守=邮件重置链全断——所有其他恢复都依赖域名还在。
  4. 封存访问文档（三用）：账号清单+恢复码+2FA 备份码，加密封存并指定紧急联系人——同时覆盖「设备丢失恢复」「APPI 事故响应」「出售交割」（opc-exit-microacquisition 尽调直接要这份）。
  5. 依赖与部署面：Dependabot 常开、生产与开发 GitLab 权限分离、部署密钥按环境隔离——全部免费，零理由不做。

待办 / 下次继续

关联

一人公司安全基线：账号、密钥、备份与恢复 · 我的站点