GuideAdvanced

企业级加固 · 让你的应用成为\"那栋难啃的房子\"的 8 层安全

上一份资源给了你发布前必备的 3 把锁。这一份是下一个级别:正经产品所用的加固。让我们从一个令人不安却也让人解脱的真相开始:没有什么是\"坚不可摧\"的。Google、Stripe、银行——全都可能被攻击。真正的目标不是刀枪不入;而是让攻击你的代价高到、麻烦到让攻击者放弃,转而去找更容易得手的猎物,并在事情发生时控制住损失,让一次失误不至于演变成一场灾难。就像你的房子:偷不了的房子并不存在,存在的是装了铁栅栏、警报器、狗和摄像头的那栋——小偷一看,盘算了一下要花多大力气,就去了邻居家。这就是目标:成为那栋难啃的房子。这里就是达成它的 8 层,用简单的语言,每一层都配上它的比喻和一个把它交给你的 AI 的 prompt。

Jun 20, 202615 min

这份内容是给谁的?

给那些真正想用 AI 构建东西、并且想要真正安全的人——一个 SaaS、一个有很多用户的应用、一个涉及金钱或敏感数据的产品。你不需要会编程,但这确实是本系列里最进阶的一份资源。如果你才刚起步,先做好[3 把基础锁](/recursos/protege-tu-app-rls-cors-headers);等你要动真格了,再回到这里。

那个令人不安(却也让人解脱)的真相

没有什么是"坚不可摧"的,谁跟你说不是这样,谁就在骗你。Google、Stripe、银行:都可能被攻击。那么,安全到底有什么用?真正的目标不是刀枪不入——而是让攻击你的代价高到、麻烦到让攻击者放弃,转而去找更容易得手的猎物。同时也是在事情发生时控制住损失,让一次失误不至于演变成一场灾难。

这样想 · 那栋难啃的房子

没有偷不了的房子。有的是装了铁栅栏、警报器、狗和摄像头的房子——小偷一看,盘算了一下要花多大力气,就转身去了邻居家。这正是安全的目标:不是不可战胜,而是要成为那栋难啃的房子。

核心概念:纵深防御

大公司之所以安全,靠的不是什么魔法妙招。它们安全,是因为筑了很多道墙,一道接着一道:如果攻击者越过了第一道,就撞上第二道,再撞上第三道。这叫做"纵深防御"。规则是:单单一个漏洞,绝不能足以让人闯进来。所以是 8 层,而不是一层。

第 1 层 · 门(谁进来、能进到哪)

有两件事人们常常混淆:身份认证(authentication)是"你真的是你说的那个人吗?"(登录),而授权(authorization)是"你有权限做"这件具体的事"吗?"(这个用户能看这条数据吗?)。黄金法则:默认拒绝。一切都是关闭的,除非明确打开——绝不能反过来。大多数数据泄露之所以发生,是因为有人把某个东西留成了"默认打开",然后忘了关。

把它交给你的 AI · 第 1 层texto

我想用"默认拒绝"的规则来加固我后端的身份认证和授权。每个 endpoint 都要生来就是关闭的,只有在有明确理由时才打开。请配置一个全局 guard,对所有内容强制要求身份认证,并且只允许把我指定的那些标记为公开。至于授权,请按操作(action)来验证权限,而不只是按登录状态。用简单的步骤向我解释你都做了什么。

第 2 层 · 邻居之间的墙(不让任何人看到别人的数据)

如果你有很多用户,这是最重要的一层

如果你的应用在同一个数据库里有很多用户,那个致命的风险就是:某个用户因为一个 bug,看到了另一个用户的数据。这个保护叫做 Row Level Security(RLS):数据库本身,一行一行地,强制执行"你只能看到属于你自己的东西"——即便程序员(或 AI)忘了在代码里做过滤。这是一道防疏忽的墙。它是一个正经产品和一个业余产品之间的差别。

这一层正是我们在上一份指南里看到的(第 1 把锁)。这里我们把它提升为一条架构规则:在一个多用户产品里,RLS 不是可选项,而是地基。

把它交给你的 AI · 第 2 层texto

我的应用是多用户的(很多客户共用同一个数据库)。请用 Row Level Security 确保完全隔离:在所有存有用户数据的表上启用 RLS,配上能保证每个人只能访问属于自己的东西的策略。我希望即使代码有 bug,也由数据库来强制执行。请用 (SELECT auth.uid()) 以提升性能,并限制在 authenticated 角色上。把 SQL 给我,并向我解释怎么测试一个用户"看不到"另一个用户的数据。

第 3 层 · 会计数的门卫(不让任何人把你淹没)

这样想

限流(rate limiting)是一个会计数的门卫:每个用户或 IP 每分钟都有请求次数的上限。如果一个攻击者每秒发出 10.000 个请求想把你搞垮,门卫在第 #100 个就把他拦下、挡在门外——服务器对剩下的连感觉都没有。这是你抵御洪水式攻击的安全带。

把它交给你的 AI · 第 3 层texto

给我的后端加上限流:按用户、按 IP 设每分钟请求次数的上限,在敏感的 endpoint(登录、注册,以及调用 AI 的那些)上更严格。当超过上限时,返回一个清晰的错误(429),而不要把服务器搞垮。告诉我一开始建议用什么样的上限,以及之后怎么调整它们。

第 4 层 · 外层护盾(让攻击连你的门都到不了)

在一个恶意请求碰到你的服务器之前,它会先经过一道外层护盾——Cloudflare 是标准做法。这道护盾吸收大规模攻击(那些 DDoS:成千上万台机器同时攻击你)、过滤掉已知的 bots,并拦截攻击模式。你的服务器藏在它后面,不会把自己的门直接暴露出来。这是第一道防线,也是大公司用的那道。

把它交给你的 AI · 第 4 层texto

我想在我的应用前面放一道外层护盾(像 Cloudflare 这样的 WAF/CDN)。请用简单的步骤引导我:把我的域名接入 Cloudflare、开启 DDoS 防护和应用防火墙,并把我的源服务器藏起来,让没人能直接打它。告诉我一开始要开启哪些配置,以及哪些是免费的。

第 5 层 · 把钥匙锁好(不让你的秘密泄露)

你最大的噩梦,而且理所当然

一个泄露在代码里的 API key,就像把你家的钥匙插在门上。规则是:(1)秘密绝不存在于代码或 git 里——它们存在一个单独的保险箱里(vault),以环境变量的形式注入;(2)你用户的钥匙要加密保存,每个用户用一把不同的密钥,这样就算数据库被偷,他们也读不出任何一把;(3)一个自动检测器(gitleaks)会在每次 commit 之前检查,确保没有任何秘密不小心溜出去——如果你想上传一把钥匙,它会拦住你。

把它交给你的 AI · 第 5 层texto

请保护好我的秘密(API keys、密码、tokens)。1) 把它们从代码和 git 里拿出来:放进环境变量,并创建一个忽略 .env 的 .gitignore。2) 如果我保存用户的钥匙,就在数据库里用每个用户一把的密钥加密它们。3) 把 gitleaks 配置成每次 commit 之前的 hook,这样如果我不小心想上传一个秘密,它会拦住我。用简单的方式向我解释每一步。

第 6 层 · 对一切进来的东西都保持怀疑

永远不要相信用户发来的东西。每一条到达你后端的数据,在碰任何东西之前,都要用一个严格的 schema 校验。这挡住了那些经典攻击:SQL injection(攻击者在一个表单里塞入命令来偷你的数据库)、prompt 注入(用户操纵你的 AI,让它绕过自己的规则),以及会搞垮系统的畸形数据。规则是:在每一个边界都做校验。所有外部来的东西,在被证明清白之前,都是可疑的。

把它交给你的 AI · 第 6 层texto

请对我后端的"所有"输入,在每个 endpoint 上、在处理任何东西之前,都用一个严格的 schema(用 Zod 或等价物)来校验。拒绝任何不符合 schema 的东西。特别是保护我抵御 SQL injection、对 AI 的 prompt 注入,以及畸形数据。给我一个能在每个边界应用的模式,并在我的某个 endpoint 上给一个例子。

第 7 层 · 别让一个用户把你的钱放血放干

AI 产品特有的风险

一个恶意用户(或者仅仅是一个 bug)可能对 AI 发起成千上万次昂贵的调用,把你的钱烧光。保护措施:一个按用户的预算——每个人都有每日的花费上限,达到就切断。此外,那个测量消耗的系统会检测出以异常方式花钱的人,在他对你造成伤害之前就把他拦下。这个计量表不只是记账:它是一道护盾。

把它交给你的 AI · 第 7 层texto

我的应用用了 AI(按用量花钱)。请保护我别让一个用户把我的额度放血放干:1) 给每个用户设一个每日 AI 使用的预算/上限,达到时用一条清晰的消息切断它。2) 按用户记录消耗,以便检测异常行为。3) 如果有人的花费突然飙升,提醒我。向我解释怎么设定这些上限,才不会影响到正常用户。

第 8 层 · 处处装摄像头(审计)

你保护不了你看不见的东西。每一个重要的操作都会被记录下来(谁、做了什么、什么时候),写进一个谁都无法删除的不可变日志。如果发生了什么奇怪的事,你手上有录像。而一套告警系统会在事情正在发生时就通知你,而不是事后。这才是让你睡得安稳的东西:如果有人想搞点什么,你能实时看到。

把它交给你的 AI · 第 8 层texto

给我的应用加上审计和可观测性:1) 一个不可变的日志,在重要操作(登录、数据变更、支付)上记录谁在什么时候做了什么,并且无法被删除或编辑。2) 告警,在发生可疑情况(大量失败的登录尝试、异常花费、峰值时的错误)时实时通知我。告诉我首先应该记录哪些事件,以及怎么接收告警。

那个总结了一切的真相

不是一堵高墙,而是很多道墙

大公司之所以安全,靠的不是什么魔法妙招:它们应用这些层,全部,有纪律地,一层都不跳过。安全不是一堵高墙——而是很多道墙,这样如果攻击者越过一道,就撞上下一道。纵深防御。单单一个漏洞,绝不能足以让人闯进来。

安全是从地基往上建的,不是在最后加的

最昂贵的错误:把安全"留到最后,有时间再说"。最后才加上去的安全从来都不管用;从地基往上建起来的,才管用。所以这些层不是附加项——它们是基础。从项目的第 1 天就把它们交给你的 AI 去做,而不是等到你快要发布了才做。

总控 prompt · 8 层一次到位

如果你想在启动一个正经项目时把它们一次性全部交待清楚,这个 prompt 把这 8 层总结好了,让你的 AI 从地基起就把它们考虑进去:

在一个正经项目开始时把它粘给你的 AItexto

我们要从第 1 天起,用"纵深防御"(很多层)来构建这个后端,做到企业级的安全。请在你构建的一切东西里都考虑这 8 层,并提醒我还缺哪一层:

1. AUTH:身份认证 + 授权,采用"默认拒绝"(一切都关闭,除了我明确打开的)。
2. 隔离:在所有表上启用 Row Level Security(每个用户只能看到属于自己的东西,由数据库强制执行)。
3. 限流:按用户/IP 限制请求次数,在敏感 endpoint 上更严格。
4. 外层护盾:前面放 WAF/CDN(Cloudflare),带 DDoS 防护并把源服务器藏起来。
5. 秘密:代码/git 里不放任何钥匙;vault + 环境变量;用户钥匙加密;每次 commit 前跑 gitleaks。
6. 校验:在每个边界用严格的 schema(Zod)校验所有输入;抵御 SQL injection 和 prompt 注入。
7. 成本护栏:按用户的 AI 预算,带自动切断;检测异常消耗。
8. 审计:不可变日志(谁/做了什么/什么时候)+ 实时告警。

先告诉我哪些适用于我的项目、我们按什么顺序去实现它们,别为我暂时还不需要的东西过度工程化。

在 NeuralOS 里,这些层就是地基

在 NeuralOS 里,这 8 层不是你附加上去的额外项:它们是构建各个应用所依托的基础的一部分——RLS、加密的秘密、限流、校验和成本上限,从第一天就有。理念是:让你不会因为疏忽而发布出不安全的东西。这就是在磐石上建造和在沙子上建造之间的差别。

保护你的应用 · 3 把基础锁(从这里开始)

如果这份资源对你来说太重了,那 3 项必不可少的保护是第一步。

C-A-R 协议 · 在发布前审计你的安全

把这 8 层放进审计阶段,也就是 AI 的构建者模式总会忘掉的那个环节。

#安全#enterprise#后端#纵深防御

Ready to build?