这一篇是 Networks and Network Security 课程的配套深度文,把 Module 4 的 安全加固 整理成”AI 帮你跑通后,这些槽位你必须自己确认”的 checklist。


一张图 — Of the Cloud vs In the Cloud

共担责任 是云计算时代最常被搞错、也最关键的概念:

┌─────────────────────────────────────────┐
│  IN the Cloud   ← 你的责任               │
│  ├── 数据 (你存的内容)                   │
│  ├── 应用 (代码、依赖、配置)             │
│  ├── 身份 (谁能访问、用什么权限)         │
│  ├── 网络配置 (端口、防火墙规则、VPC)    │
│  └── OS / 中间件加固 (打补丁、关默认)    │
├─────────────────────────────────────────┤
│  OF the Cloud   ← 云厂商的责任           │
│  ├── 虚拟化层 (KVM / Xen / Hyper-V)      │
│  ├── 物理服务器                          │
│  ├── 网络硬件 (路由、交换机)             │
│  ├── 数据中心 (电、空调、消防、门禁)     │
│  └── 基础设施安全 (机房物理保安)         │
└─────────────────────────────────────────┘

关键认知:几乎所有真实的数据泄漏事故都发生在 “in the cloud”——错开的端口、忘开的权限控制、泄漏到 git 的 API key、用了弱密码的 root 账号。云厂商在自己那一半几乎从不出事(出事就上头条了)。


不同云服务,你的”那一半”大小不一样

云服务分三档,你管的越少 = 越省事 = 也越受云厂商限制

服务模式云厂商管什么你管什么例子
IaaS (基础设施即服务)物理 + 虚拟化OS / 中间件 / 应用 / 数据 / 网络AWS EC2 / Vultr VPS / DigitalOcean Droplet
PaaS (平台即服务)物理 + 虚拟化 + OS + 中间件应用 / 数据 / 配置Heroku / Vercel / Supabase
SaaS (软件即服务)几乎全部数据 / 账号配置Gmail / Notion / Slack

用 IaaS(Vultr / AWS EC2)= 你的责任最多。你管 OS 打补丁、防火墙规则、SSH 配置、数据库密码——这些 AI 都能帮你跑通,但跑通 ≠ 配对

用 PaaS(Vercel / Supabase)= 你管的少很多,但仍然要管权限 / 加密 / API token / RLS — 这一层云厂商替不了你。


AI 不会替你做的 10 件事 — 通用 vibe-coder Checklist

AI 帮你跑通服务后,这 10 个槽位只有你自己能确认。按优先级排:

🔴 P0 — 这周必须做(出事=数据泄漏)

1. API key / secret 没有泄漏到 Git 或前端代码

  • AI 写代码时把 secret 硬编码进文件(它没意识到你要 commit)
  • 检查:git log -p | grep -iE "(api_key|secret|token|password)"
  • 检查:前端代码(浏览器能下载的)里绝对不能出现 service key / secret key——只能有 public / anon key
  • 工具:gitleaks / truffleHog / GitHub Secret Scanning

2. 数据库表的行级权限(RLS)

  • Supabase / Firebase 这类 BaaS 默认把数据库 anon 接口暴露在前端
  • 没开 RLS = 等于把数据库公开给全网读
  • 自检:在 SQL Editor 跑 SELECT * FROM pg_tables WHERE schemaname='public' AND rowsecurity=false;

3. SSH 配置加固

  • 改默认 22 端口(降低 99% 的扫描爆破)
  • 禁用密码登录,只用 key(PasswordAuthentication no)
  • 禁用 root 直接登录(PermitRootLogin no)
  • AI 给你装 fail2ban——值得装

🟡 P1 — 这周内做(收敛攻击面)

4. 防火墙规则最小化

  • 数据库端口(3306 / 5432 / 27017)绝对不对公网开
  • 应用端口(3000 / 8080)如果套了反向代理,也不对公网开
  • 只留 22 (改过的)/ 80 / 443

5. 身份认证强化

  • 所有云厂商账号开 MFA
  • 不同服务用不同密码(最小权限)
  • 不要给应用 root / admin 权限,够用就行

6. HTTPS 强制 + 自动续期

  • HTTP 永远 301 到 HTTPS
  • Let’s Encrypt + certbot 自动续期(过期了会 silent 挂掉很久)

7. 日志收集 + 关键告警

  • 至少把 SSH 登录失败 / sudo 使用 / 关键端口异常流量打开看
  • 不需要 SIEM,Vultr / AWS 自带的也够入门用

🟢 P2 — 这个月做(纵深防御)

8. 备份 + 备份可恢复测试

  • AI 给你设置自动备份你以为就好了——没测过的备份等于没备份。每季度恢复一次,确认可用。

9. OS 自动安全补丁

  • Ubuntu:sudo apt install unattended-upgrades + 配置自动 reboot
  • AI 跑这一步通常会问你愿不愿意,要愿意

10. 文档化 — 至少写一份 incident playbook

  • “服务挂了第一步看哪里”
  • “怀疑被入侵第一步做什么”
  • “API key 泄漏第一步吊销哪个”
  • 提前写,出事时脑子不空白

学 AWS 之前的特别提示

AWS 的整个产品线几乎全在”你的那一半”里:

AWS 产品你在做什么落在哪个槽
IAM给账号 / 服务分配权限身份 / 权限
VPC切私网,把数据库藏起来网络配置
Security Group有状态防火墙网络配置
KMS加密密钥数据加密
CloudTrail谁在你账号里做了什么日志审计
Secrets Manager别让 API key 进 Gitsecret 管理
Inspector自动找你 OS 上的漏洞OS 加固

AWS 不会帮你”自动安全”——它给你工具,配置错了就泄漏。这也是为什么 AWS 认证(Cloud Practitioner / Solutions Architect / Security Specialty)那么值钱——会配对的人不多。


AI 让你做云上配置时,1 个根本问题

读到任何 AI 给你的云配置,先问自己:

“这一步,云厂商帮我做了哪部分?剩下哪部分还需要我自己保证?”

举例:

  • AI 让你”在 Vultr 开一台机器”→ Vultr 给你硬件 + KVM 虚拟化,OS 一开机就是默认配置,所有 P0 你都没做
  • AI 让你”在 Supabase 建一张表”→ Supabase 给你 PostgreSQL,默认 anon 接口开着,RLS 没开 = 全网可读
  • AI 让你”在 Cloudflare 套上”→ Cloudflare 给你 DDoS 防护,但WAF / Bot Protection 默认是关的,要去开

AI 跑通 ≠ 配对。“跑通”只是云厂商那一半 + 你那一半的最低门槛。真正的安全在剩下 90% 的”你那一半”里。


云不是免费的安全,云是免费的脚手架。 脚手架搭起来你才能开始盖房子——盖不盖、盖得稳不稳,还是你的事。