在安全领域有一句老话：最坚固的堡垒，往往是从内部被攻破的。 而攻破堡垒的方式，90%不是什么高深的零日漏洞利用，而是一个没关的端口、一组默认密码、一个公开的存储桶。

作为一名开发工程师，我见过太多"惨痛教训"：某企业因为数据库端口对外暴露，300万条用户数据被拖库；某团队因为存储桶权限配置错误，核心代码被全网下载；某公司因为服务器开了22端口却没改默认密码，被植入挖矿木马，一个月电费多了八万块。

这些事故的共同特征是：不是技术不行，是配置不行。

今天，我就以一名一线开发工程师的视角，整理出一份覆盖云服务器、数据库、存储桶的安全配置检查清单。这份清单不讲理论，只讲实操——哪些配置一定要查，哪些疏漏一定要补，怎么补最有效。

建议收藏，每月对照检查一遍。

---

一、云服务器：你的"数字机房"，真的锁好了吗？

云服务器是所有业务的根基，也是攻击者最喜欢下手的地方。以下是我总结的十大高频配置疏漏，每一个都可能让你一夜归零。

1.1 安全组规则过于宽松

疏漏：为了图省事，把安全组规则设置为"全部允许"（0.0.0.0/0），或者开放了大量不必要的端口。

风险：22（SSH）、3389（RDP）、445（SMB）等端口一旦对全网开放，每天会收到数万次暴力破解尝试。

加固建议：

• 遵循最小权限原则，只开放业务必需的端口（通常只需80/443）
• SSH和RDP端口不要对全网开放，限制为公司办公IP段或通过VPN访问
• 定期清理过期的、临时的安全组规则

1.2 使用默认或弱密码

疏漏：服务器创建后直接使用默认密码，或者设置"123456""admin888"这类弱密码。

风险：这是勒索病毒最喜欢的入口。某医院的服务器就是因为RDP密码是"Admin@123"，被攻击者在4小时内植入勒索病毒，所有患者数据被加密。

加固建议：

• 密码长度不少于12位，包含大小写字母+数字+特殊字符
• 强制定期更换密码，周期不超过90天
• 更优方案：禁用密码登录，改用密钥对登录

1.3 系统补丁长期不更新

疏漏：服务器操作系统半年甚至一年没打过补丁，内核漏洞堆积如山。

风险：某远程代码执行漏洞（CVE）可以让攻击者无需任何认证，直接拿到服务器root权限。

加固建议：

• 开启系统自动更新，或每月至少手动更新一次
• 重点关注CVSS评分≥7.0的高危漏洞，优先修复
• 无法更新的老旧系统，考虑迁移到新版镜像

1.4 开放了不必要的高危端口

疏漏：135、139、445（SMB）、1433（SQL Server）、3306（MySQL）、6379（Redis）、27017（MongoDB）等端口对外暴露。

风险：SMB端口暴露是WannaCry勒索病毒的主要传播途径；Redis和MongoDB端口暴露，数据分分钟被删库或被勒索。

加固建议：

• 数据库端口绝对不要对公网开放，只允许内网访问
• 如果必须远程管理，通过SSH隧道或VPN接入
• Redis和MongoDB必须设置认证密码，不要用空密码运行

1.5 关闭或未启用系统防火墙

疏漏：操作系统自带防火墙（iptables/firewalld/Windows Firewall）被关闭，或规则过于宽松。

风险：即使安全组挡住了外部流量，内部横向移动也毫无阻拦。

加固建议：

• 启用系统防火墙，只允许必要的入站和出站流量
• 出站规则也要限制——防止被植入木马后向外发送数据

1.6 忘记关闭不用的服务和端口

疏漏：服务器上运行着FTP、Telnet、旧版Web服务等不再使用的服务，端口一直开着。

风险：每多一个开放的服务，就多一个攻击面。Telnet明文传输密码，FTP明文传输文件，都是重灾区。

加固建议：

• 定期盘点服务器上运行的服务，关闭所有不再使用的服务
• 用SSH替代Telnet，用SFTP替代FTP
• 旧版Web服务如果必须保留，至少限制访问来源IP

1.7 日志未开启或未集中收集

疏漏：系统日志、安全日志未开启，或者开启了但只存在本地，没有集中收集。

风险：被入侵后无法溯源，等保测评直接扣分。

加固建议：

• 开启操作系统审计日志，记录所有登录、提权、敏感操作
• 日志实时发送到集中式日志审计平台，留存不少于180天（等保要求）

1.8 未设置资源限制

疏漏：没有对CPU、内存、磁盘IO做任何限制。

风险：被植入挖矿木马后，CPU长期100%，一个月电费多几万块；或者被用于发起DDoS攻击，你的账号被封。

加固建议：

• 使用cgroup或云平台的资源配额功能，限制单进程资源使用上限
• 监控异常资源消耗，设置告警阈值

1.9 未启用入侵检测

疏漏：裸奔运行，没有任何入侵检测能力。

风险：攻击者在你的服务器上住了三个月你都不知道。

加固建议：

• 安装主机安全Agent，开启入侵检测、病毒查杀、基线核查
• 重点监控：异常登录、Webshell上传、反弹Shell、挖矿进程

1.10 备份策略缺失

疏漏：没有定期备份，或者备份和源数据放在同一个区域。

风险：勒索病毒一来，数据全丢，没有任何恢复手段。

加固建议：

• 实施"3-2-1"备份策略：3份数据、2种介质、1个异地
• 定期测试备份恢复流程，确保备份真的能用

---

二、数据库：你的"数据金库"，门真的关严了吗？

数据库是企业最核心的资产，也是攻击者最觊觎的目标。以下是数据库的八大高频配置疏漏。

2.1 数据库端口对外暴露

疏漏：MySQL的3306、PostgreSQL的5432、SQL Server的1433、MongoDB的27017、Redis的6379直接对公网开放。

风险：这是数据泄露的头号原因。某社交平台就是因为MongoDB端口暴露，2亿用户数据被黑客下载后公开售卖。

加固建议：

• 数据库端口只允许内网访问，绝对不要对公网开放
• 远程管理必须通过SSH隧道或跳板机

2.2 使用默认账户或空密码

疏漏：MySQL用root账户、MongoDB不设密码、Redis空密码运行。

风险：攻击者用扫描工具几秒钟就能连上你的数据库。

加固建议：

• 禁用或重命名默认账户（如MySQL的root）
• 创建独立的业务账户，只授予必要的权限
• 强制设置强密码

2.3 未开启数据库审计

疏漏：数据库操作没有任何审计记录。

风险：谁在什么时间查询了什么数据、谁删除了哪张表，完全无法追溯。等保测评直接扣分。

加固建议：

• 开启数据库审计功能，记录所有SQL操作
• 重点监控：批量查询、全表扫描、权限变更、敏感表访问

2.4 未加密敏感字段

疏漏：用户密码明文存储、身份证号明文存储、银行卡号明文存储。

风险：一旦数据库被拖库，所有敏感信息一览无余。

加固建议：

• 密码必须加盐哈希存储（推荐bcrypt或Argon2）
• 身份证号、银行卡号等字段加密存储（AES256或国密SM4）
• 启用数据库透明加密（TDE），底层存储全加密

2.5 权限过度授权

疏漏：业务账户直接给DBA权限，或者所有表都给SELECT权限。

风险：一个被攻破的低权限账户，可以通过权限提升拿到整个数据库的控制权。

加固建议：

• 遵循最小权限原则，只授予业务必需的表和操作权限
• 禁止应用账户执行DROP、TRUNCATE等高危操作
• 定期审查账户权限，清理僵尸账户

2.6 未限制连接数和来源IP

疏漏：数据库允许任意IP连接，连接数无限制。

风险：暴力破解无阻碍，CC攻击直接打垮数据库。

加固建议：

• 限制数据库最大连接数，防止连接耗尽
• 仅允许应用服务器IP访问数据库

2.7 未关闭远程访问功能

疏漏：MySQL的bind-address设置为0.0.0.0，允许任意IP远程连接。

加固建议：

• bind-address设置为127.0.0.1或内网IP，只允许本地或内网访问

2.8 备份文件未加密且暴露

疏漏：数据库备份文件（.sql、.bak）存储在公网可访问的路径，且未加密。

加固建议：

• 备份文件加密存储，访问需要二次认证
• 备份文件不要放在Web目录下

---

三、存储桶：你的"数据仓库"，真的只有你能进吗？

对象存储是云上最常用的服务之一，但也是数据泄露的重灾区。以下是六大致命配置疏漏。

3.1 存储桶权限设置为"公开读取"

疏漏：为了方便分享，把存储桶权限设置为公开读取，或者ACL配置错误导致公开访问。

风险：某车企的内部文档就是因为存储桶公开，被安全研究员下载后发现了未发布的车型设计图纸。

加固建议：

• 存储桶默认设为"私有"，需要共享时使用预签名URL
• 定期使用存储桶安全扫描工具检查公开访问风险

3.2 AK/SK密钥泄露

疏漏：Access Key和Secret Key硬编码在代码里、上传到Git仓库、或者写在配置文件里明文存储。

风险：攻击者拿到AK/SK后，可以直接操作你的所有云资源——删数据、开服务器、窃数据，为所欲为。

加固建议：

• 永远不要把AK/SK写在代码里，使用环境变量或密钥管理服务
• 定期轮换AK/SK，至少每90天一次
• 开启AK/SK使用告警，异常调用立即通知

3.3 未开启存储桶日志

疏漏：存储桶的访问日志未开启，或者开启了但没有分析。

风险：数据被窃取后，你连谁干的都不知道。

加固建议：

• 开启存储桶访问日志，记录所有读写操作
• 配置告警规则：异常大量下载、非工作时间访问、陌生IP访问

3.4 未设置跨域策略或设置过宽

疏漏：CORS策略设置为允许所有来源，或者未设置但默认允许。

风险：攻击者可以在恶意网站上通过JavaScript直接读取你存储桶中的数据。

加固建议：

• CORS策略只允许你自己的域名访问
• 严格限制允许的HTTP方法（只允许GET，禁止PUT/DELETE）

3.5 版本控制未开启

疏漏：存储桶未开启版本控制，文件被覆盖或删除后无法恢复。

风险：误操作或恶意删除后，数据永久丢失。

加固建议：

• 开启版本控制，保留历史版本
• 配合生命周期策略，定期清理过期版本

3.6 未设置服务端加密

疏漏：存储桶未开启服务端加密，数据以明文存储。

风险：底层存储介质一旦泄露，数据直接暴露。

加固建议：

• 开启服务端加密（SSE-S3或SSE-KMS）
• 敏感数据使用客户端加密后再上传

---

四、写在最后：安全配置不是一次性的，是持续性的

这份清单覆盖了云服务器、数据库、存储桶最常见的配置疏漏。但我必须强调：安全配置不是"设置一次就完事了"的事情。

业务在变，配置在变，攻击手段也在变。你上个月检查没问题，不代表这个月还没问题。

建议的节奏是：

• 每周：检查安全组规则是否有异常变更
• 每月：对照这份清单做一次全面检查
• 每季度：进行一次渗透测试或漏洞扫描
• 每次上线前：确认新增资源的安全配置合规

安全不是成本，是你能安心睡觉的底气。而这份清单，就是你睡前的最后一道安检。

别等出了事才来查配置——现在就打开控制台，一条一条对照吧。