安全组配置是立体防护起点，必须绑定最小权限：仅开放80/443等必需端口，数据库禁公网、SSH限IP改端口，按DMZ与内网分层管控访问，同步实施用户/进程降权与动态规则审计。
安全组配置不是简单“开几个端口”，而是立体防护的起点。它必须和最小权限管理深度绑定，从网络层就卡住攻击入口，避免把防御压力全压到应用或系统层。
只放行业务必需的端口与协议
开放端口等于打开一扇门。多数被黑服务器，问题就出在开了不该开的口子。
- Web服务只需 80（HTTP）和 443（HTTPS），其他如 FTP（21）、Telnet（23）、SMB（445）、RDP（3389）一律关闭；
- 数据库（如 MySQL 3306、Redis 6379）绝不能暴露在公网，只允许内网特定 IP（比如 Web 服务器）通过安全组白名单访问；
- SSH 管理端口（默认 22）必须改非标端口（如 2024、2222），并严格限制源 IP —— 只允许可信办公网络或跳板机接入。
按角色/区域划分访问控制矩阵
不同区域之间不是“能通就行”，而要像交通管制一样明确谁可以去哪里、走哪条路、办什么事。
- 互联网 → DMZ（如 Nginx 反向代理）：仅允许 80/443，拒绝所有其他协议；
- DMZ → 内网核心区（如 API 服务、数据库）：只允许指定 IP + 指定端口（如 3306、6379），禁止主动扫描、文件传输等高风险行为；
- 内网 → 互联网：限制为 HTTPS（443）、DNS（53），禁用 FTP、P2P、SMTP 等非必要外连协议。
结合用户与进程级最小权限加固纵深防线
安全组管“谁能进来”，但进来了之后还得防“能干什么”。这需要操作系统与应用层同步降权：
- 禁用 root 远程登录，创建专用运维账户，并用 sudo 白名单限定可执行命令；
- Docker 容器不以 root 运行，Dockerfile 中显式声明 USER，并用 COPY --chown 控制文件归属；
- PHP 禁用 exec、system、shell_exec 等危险函数；MySQL 创建用户时只授 SELECT 或 INSERT 权限，而非全库 ALL PRIVILEGES。
动态更新与可观测性闭环
规则不是设完就不管。真实环境里，IP 会变、业务会扩、漏洞会新出。
- 安全组日志需开启并保留至少 90 天，重点分析被拒绝的连接（如高频扫 22 端口的 IP）；
- 每季度做一次端口策略复核，删掉半年未用的规则；
- 配合漏洞扫描与渗透测试结果，反向验证安全组是否真正堵住了攻击路径 —— 比如扫描发现某台机器仍可连通 Redis，就要立刻检查是安全组漏配，还是内网路由绕过了规则。
