跳到正文
>_ITDITDWeb 安全平台

安全指南

#安全基础#MFA#密钥管理#备份#AI 时代的防备

个人开发 / 小规模运营的安全底线：把行业标准的对策一次配齐

把个人开发者、小规模运营者最低限度该做的安全对策——只选行业标准的——浓缩到一页里。多因素认证、密钥管理、依赖的 CVE 监控、备份等，按『王国之钥 → 密钥与代码 → 应用本体 → 检测与恢复』的优先级，从本站的运营视角讲清楚先填哪一格。

发布于 2026-06-11 更新于 2026-06-11 4 分钟阅读

适用对象：个人开发者、小规模运营者中，「安全对策到底做到哪一步才算"最低限度"都搞不清」的人。这里完全不讲攻击手法，只把被视为行业标准的地基，按优先级浓缩到一页里。每一项都链接到深入文章，所以可以以此为起点，只读自己需要的部分。

本站的视角：不是『全都做』而是『按这个顺序填』

个人或小规模运营，没有把能做的事一口气全做完的余力。正因如此顺序至关重要。最上面的「王国之钥」一旦被夺走，下面的任何对策都会失去意义（攻击者能以你的身份把一切重置）。反过来，从地基开始逐层填，就能在有限的时间里把受害概率压到最低。这篇文章不追求知识的面面俱到，而是写成一张能让你立刻决定『下一格填哪里』的地图。

Tier 0 — 王国之钥

多因素认证 / 域名 / DNS / 邮箱 / 支付

Tier 1 — 密钥与代码

密钥不进 git / 提交前检测 / 密钥的隔离与吊销

Tier 2 — 应用本体

输入校验 / 认证与会话 / TLS 与响应头 / 邮件认证

Tier 3 — 补丁 / 检测 / 恢复

依赖 CVE 监控 / OS 更新 / SSH 与防火墙 / 日志 / 备份

本站的优先级地图。越靠上『一旦被夺走整体就崩塌』。从上往下逐项填。
几分钟
公开的密钥被滥用所需时间
已知缺口
严重事故的大半原因
1 处
王国之钥一旦失守就全盘崩塌
顺序
有限资源下的取胜之道

Tier 0 — 守住王国之钥（最高优先）

这里是一切的前提。一旦域名、邮箱、服务器管理面板被夺走，其他任何对策都会失效。攻击者能以你的身份重置密码、改写 DNS、登进服务器。所以最先要加固的就是这里。

1

加上抗钓鱼的多因素认证

给域名注册商、DNS、服务器管理面板、邮箱、支付都强制启用多因素认证。强度上 passkey / 物理密钥（FIDO2）＞ 认证器应用（TOTP）＞ 短信。短信会被 SIM 交换攻破，是最后的手段。
2

把邮箱当作「钥匙的父级」最严密地守护

几乎所有服务的密码重置都会发到邮箱。邮箱一旦失守，就会连锁性地全部失守。唯独邮箱值得强制启用物理密钥。
3

安全保管恢复手段与备份码

把多因素认证的恢复码放进密码管理器或物理上安全的地方。一旦丢失，你自己也会被拒之门外。
4

区分使用账户以减少单点故障

重要账户要避免复用密码，用密码管理器让每个都唯一。这样某一个服务的泄露就不会横向蔓延。

Tier 1 — 别泄露密钥与代码

本站的起因，以及世上的许多事故，都源自这一块的缺口。也就是 .env 或 API key 这类密钥，混进代码或公开仓库而外泄的模式。

1

密钥既不写进源码也不写进文档

把 API key、密码、连接信息分离到 .env 等文件里，并从 git 排除（.gitignore）。压根不写，才是最强的对策。
2

提交前用机器拦下密钥

用 gitleaks 等 pre-commit 钩子，从物理上拦下含密钥的提交。自己张起一张相当于 GitHub push protection 的网（→ 自建 Git vs GitHub）。
3

一旦泄露就以『全都泄露了』为前提全量轮换

只要有一丝怀疑，就立刻吊销并重新签发相关的密钥、令牌。别用「大概没事」放任不管。这是实际事故处置中最有效的思路（→ 密钥泄露被恶意刷费的经历）。
4

令牌要限定作用域、短命化

不要造一把全权限的万能令牌。按最小必要权限、短有效期、按服务区分。这样漏掉一把也能把损失封死。

自建 Git 尤其要当心

就算因为怕 GitHub 上「误公开」而改成自建运营，误提交也不会消失。反而因为没有 GitHub 标配的密钥拦截，提交前的密钥检测钩子在自建运营里是必备的。详情整理在 自建 Git 服务器与 GitHub，哪个更安全。

Tier 2 — 把应用本体做硬

这是对外公开的 Web 应用本身的最低限度。与其防新型攻击，本质更在于堵住常见的老缺口。本站把每个老缺口都在术语页里翻译成了防御视角。

1

不信任输入（堵住老缺口）

来自用户输入的 SQL 注入、XSS、SSRF、路径遍历，要用转义 / 参数化 / 白名单来堵住。
2

把认证、会话、权限做对

CSRF 对策、能看到他人数据的 IDOR 的权限校验、防 点击劫持 的框架控制。
3

让 TLS 与安全响应头生效

强制 HTTPS、设置 HSTS、CSP 等。自己的站点可以用 安全响应头诊断 来打分（CSP 可用 CSP 构建器 来拼装）。
4

防止邮件被冒充

如果用自有域名发邮件，就设置 SPF/DKIM/DMARC。可用 邮件认证检查器 来确认缺口。

Tier 3 — 补丁 / 检测 / 恢复

这是「即便被入侵，也能把损失压小、快速重建」的地基。像 osv-scanner 这样的依赖监控也归在这里。

1

用机器持续监控依赖的 CVE

放任已公开的已知漏洞（CVE）不管，是最多的事故原因。把 osv-scanner 或 pnpm audit 放进 CI / cron 持续运行（→ 不在 CVE 上落后的机制）。
2

自动更新 OS 与服务器

用 unattended-upgrades 等把 OS 的安全更新自动化。Git 服务器和各中间件的补丁也别放任不管。
3

加固 SSH 与防火墙

SSH 只用密钥（关闭密码认证、禁止 root 直接登录），用防火墙只开放必要端口，用 fail2ban 拖慢暴力破解。
4

用最小权限缩小爆炸半径

服务以非 root 运行，DB / 内部服务不对外公开。每台主机用不同的 SSH 密钥。设计成单点被攻破不会波及整体。
5

3-2-1 备份 ＋ 恢复测试

数据要 3 份副本、2 种介质、1 份在异地。必须加密。而且不只是「有备份」，还要实际能否恢复，亲自试一次。
6

留下日志以便察觉异常

留下访问、认证、错误的日志，让自己处在能察觉异常苗头的状态。察觉越晚，损失越大。

从哪里下手

「全部立刻做完」并不现实。下面把容易踩的顺序，和本站建议的顺序作个对比。

容易踩的顺序（低效）

  • 一上来就从花哨的应用漏洞对策开始
  • 多因素认证一直「以后再说」地拖着
  • 备份有在做，但从没试过恢复
  • 密钥先丢进了 .env，但没有检测钩子

本站建议的顺序

  • Tier 0：先加固王国之钥（多因素认证 / 邮箱 / 域名）
  • Tier 1：从结构上堵住密钥外泄（提交前检测 ＋ 全量轮换方针）
  • Tier 2：堵住应用的老缺口
  • Tier 3：用依赖监控 / 更新 / 备份恢复，达到"能重建"的状态

本站自己也按这个顺序在守护

本站把这里写的地基应用在了自己身上。用专用服务器不与其他服务混在一起（受害范围的隔离）／ 每台主机用不同的密钥 ／ 密钥既不写进 git 也不写进文档 ／ 依赖的 CVE 监控在每次部署前 ＋ 每日自动运行 ／ 向另一台服务器做异地备份 ／ 对外请求都走安全边界。一个教安全的站点，自己绝不能带着缺口——所以这套优先级，我们首先在自己身上执行。作为起因的那次事故，也并非新型攻击，而是这块地基的某一个缺口造成的。正因如此，我们才反复强调：比起花哨的对策，先打好地基。

接下来读

FAQ

Q个人开发最先该做的安全对策是什么？
A

守住『王国之钥』。具体来说，就是给域名注册商、DNS、服务器管理面板、邮箱、支付账户都加上抗钓鱼的多因素认证（passkey / 物理密钥）。这里一旦被夺走，其他所有对策都会失效，所以是最高优先级。

Q最低限度的对策是不是都一样重要？
A

不是。重要程度有明确的次序。本站建议按『①王国之钥 → ②密钥与代码 → ③应用本体 → ④补丁 / 检测 / 恢复』的顺序去填。资源有限的个人，从上往下逐项填，最能减少事故。

Q依赖包的 CVE 监控也算最低限度吗？
A

算。用 osv-scanner 或 pnpm audit 机械地持续检查依赖的已知漏洞，如今已是行业标准。多数严重事故并非新型攻击，而是已知缺口（CVE）被放任不管造成的。