信任是一个工程问题

人们常问我，我认为 SnapLedger 面临的最大挑战是什么。

出人意料的是，我不认为是 AI。不认为是会计。也不认为是竞争。

我认为是信任。

毕竟，SnapLedger 要求客户把他们一些最敏感的业务信息交由我们保管——收据、发票、工资记录、雇佣合同、银行对账单、税务文件。这些文件不只是描述一家企业；在很多意义上，它们就是这家企业。

那么，凭什么有人会把这一切托付给一家初创公司？

我为这个问题思考了很久，得出了三个结论。

1. 数据早已在云上

第一，如今的问题不再是你的数据是否应该放在云上。对我们几乎所有人而言，它已经在那里了。

我们的电子邮件、照片、日历、银行应用、公司文件和源代码，全都存放在云端的某个地方。没有云服务，现代商业根本无法运转。

真正的问题是：数据一旦上了云，它被保护得有多好？

2. 安全与公司规模无关

第二个认识是：安全与公司规模的关系，出人意料地小。

许多人自然而然地以为大公司比初创公司更安全。我不这么看。

安全源于工程上的自律。一家小公司可以构建出色的安全架构，而一家大公司仍可能做出糟糕的工程决定。好的安全是成千上万个深思熟虑的设计选择的结果，而不是成千上万名员工的结果。

3. 站在可得的最佳基础之上

这引出了我的第三个结论。作为一家初创公司，我们不应试图发明自己的安全基础设施，而应建立在已有的最佳安全基础设施之上。

这正是 SnapLedger 构建于 Google Cloud Platform 之上的原因。Google 花费了数十年时间、数十亿美元，打造出全球最安全的云基础设施之一。每天都有数十亿人依赖它来使用 Gmail、Google Drive 和 Google Photos 等产品。站在那样的基础之上，让我们得以专注于打造出色的财务软件，而不必自己重新发明云安全。

安全是设计出来的，不是买来的

当然，使用 Google Cloud 并不会自动让一个应用变得安全。安全不是买来的，而是设计出来的。

从一开始，我们就决定让安全成为 SnapLedger 架构的一部分，而不是事后追加的东西。今天，这意味着诸如：

• 数据在传输中和静态存储时均加密。
• 以多因素认证保护管理访问。
• 遵循最小权限原则的严格身份与访问管理（IAM）。
• 持续备份与灾难恢复机制。
• 采用独立的管理员身份，而非共享的特权账户。
• 持续的安全监控与审计。

另一个重要的设计决定，是我们的部署架构。SnapLedger 被设计为一个全球部署的平台，而非单一的集中式服务器。

随着我们走向国际，客户数据可以部署并存储在适当的地理区域，以满足当地的监管要求，例如欧洲的 GDPR 和阿联酋的 PDPL。我们相信，客户不应在现代 AI 软件与合规之间二选一——他们应当二者兼得。

证书在思考之后，而非之前

有人有时会问，我们最终是否会去申请 ISO 27001 或 SOC 2 之类的认证。答案是会。这些认证之所以有价值，是因为它们证明安全流程被始终如一地执行。

但我不认为信任始于一纸挂在墙上的证书。信任开始得早得多。它始于工程师在每一个设计决定之前问自己一个简单的问题：

"如果这是我自己的财务数据，我会安心地这样存放它吗？"

如果答案是否定的，我们就重新设计。

归根结底，我不认为信任是你能要求客户给予你的东西。它是需要赢得的——靠成千上万个工程决定、数百个产品决定，以及对这些决定背后原因的彻底透明。

这也是我写这本创始人日记的原因之一。我并不指望人们仅仅因为我们说自己安全就信任 SnapLedger。我希望他们逐渐信任我们思考的方式。

其余的一切，都可以建立在这份信任之上。