# 中小企业数据安全清单：7件必须落地的事

原文：https://www.99idc.cn/blog/enterprise-data-security-checklist.html

作者：广深互联技术团队

发布时间：2026-11-05T08:27:00+00:00

内容更新时间：2026-11-03T04:48:34+00:00

## 摘要

从技术负责人角度整理一份中小企业可落地的数据安全清单：密码加密存储、全站HTTPS、异地备份与恢复演练、操作日志审计、权限最小化、离职账号回收、数据库定期维护，不玩概念，只讲该做什么。

## 正文

## 引言



我们接触过不少中小企业，一提到"数据安全"就觉得是大厂和金融机构的事。其实中小企业反而是被攻击的重灾区——不是因为价值高，而是因为防护弱。



勒索软件加密文件、客户数据库被拖库、员工离职带走账号密码，这些事每年都在发生。需要注意的是，对大多数中小企业来说，不需要上来就堆安全设备、上SOC运营中心。先把下面这7件基础动作做扎实，有助于降低常见风险，但不能代替针对实际系统的安全评估。



本文不讲宏大概念，只列我们在项目交付中反复强调、并且要求默认做到的几件事。



## 一、登录密码使用专用哈希存储，避免明文和可逆方案



这是最基础、也是最容易被偷工减料的一环。



很多系统被拖库之后，所有用户密码直接泄露，根本原因是数据库里存的是明文，或者用了可逆的加密方式。一旦数据库被拿走，攻击者等于拿到了一把万能钥匙。



我们建议的做法：



- 使用单向哈希算法存储密码，例如 bcrypt、argon2 这类自带盐值和计算成本调节的算法；


- 不要自己写加密算法，也不要用 MD5、SHA1 这类已经被证明不安全的老方案；


- 同一套系统里，密码永远只存哈希值，业务代码里不需要也不应该出现"找回明文密码"的功能。



需要注意的是，用户忘记密码时，正确做法是让他通过邮箱或手机重置，而不是把原密码"发回去"——系统自己都不应该知道原密码是什么。



## 二、全站 HTTPS，不要只加密登录页



很多企业网站只在登录页加了 HTTPS，其他页面还是 HTTP。这相当于家门锁了，窗户全开。



HTTP 传输过程中，账号密码、Cookie、业务数据都可能被中间节点窃听或篡改。更现实的风险是，员工在咖啡店、机场这种公共 Wi-Fi 环境下访问后台，数据很容易被嗅探。



通常来说，现在给全站启用 HTTPS 的成本已经很低：



- 正规证书可以通过可信渠道申请，一年的费用并不高；


- 服务器端配置好 301 跳转，把 HTTP 统一重定向到 HTTPS；


- 页面里引用的图片、CSS、JS 资源也要改成相对路径或 HTTPS，避免出现"混合内容"警告。



应在交付清单中确认HTTPS配置、证书归属和续期责任；证书采购与运维费用以具体报价为准。



## 三、定期备份，并且一定要做恢复演练



备份这件事，单独说一句"我们有备份"是不够的。



我们见过不少客户的备份策略停留在"数据库每天自动导出一次"，但从来没有人验证过这份备份真的能恢复。直到服务器故障、勒索加密发生，才发现备份文件早就损坏、或者恢复步骤根本走不通。



我们建议的备份策略是：



- 保留多份独立备份，至少一份异地或离线；本机、同机房副本不能视为异地备份，并与生产访问权限隔离；


- 备份频率根据数据重要性定，重要业务库做到按小时或按天；


- 每季度做一次恢复演练，把备份真正还原到一台测试环境，跑通登录、核心业务流程；


- 备份文件本身也要加密，别让备份盘变成第二个泄露源。



需要注意的是，"有备份"和"能恢复"是两回事。恢复演练这件事，看起来是额外工作，但真正出事的时候，它是企业能不能活下来的分水岭。



## 四、操作日志要能审计，关键动作要留痕



风险既可能来自外部攻击，也可能来自误操作、越权和内部滥用，不能预先忽略任何一类。



例如：某员工偷偷导出客户清单离职；运营人员误删了一整批订单；财务改了某条关键金额却没人发现。这些事情如果没有日志，事后基本查不清。



我们建议在后台系统里默认开启几类日志：



- 登录日志：谁、什么时间、从哪个 IP 登录了系统；


- 关键操作日志：新增、修改、删除、导出、审批通过这类动作，要记录操作人、操作前后的关键字段；


- 管理员操作日志要单独留存，不能让管理员自己删。



日志不需要做得多花哨，关键是出问题的时候能顺着记录还原"谁在什么时候做了什么"。



## 五、权限最小化：员工只开工作必需的那部分



很多系统上线初期，图省事，给所有员工开管理员权限。时间一长，离职的、调岗的、外包的，账号都还留着。



权限最小化原则说起来简单：



- 新员工入职，按岗位角色开通权限，不要默认给"全部可见"；


- 岗位变动时，权限跟着职责走，做减法比做加法更重要；


- 临时需要的高权限（例如财务月结、客服后台导出），走临时申请，事后收回；


- 多人共用一个账号是红线，出了问题谁都说不清。



我们通常建议企业把权限按"角色"而不是按"人"来配置。岗位变动时改角色，比逐个改账号好维护得多。



## 六、员工离职，账号要系统性回收，不是只删账号



离职账号回收，看似只是删个账号，实际要收的东西比想象中多。



我们建议的离职回收清单：



- 系统后台账号禁用并停用；


- 企业微信、钉钉、邮箱、VPN 这类办公通道一并退出；


- 曾经生成过的 API Key、第三方系统授权 Token 要重置；


- 共享文档、云盘里的个人分享链接要收回；


- 公司配发的手机、电脑、U 盾要物理收回。



需要注意的是，很多泄露事件不是离职当天发生的，而是离职后几个月，员工用旧密码、旧 API 密钥还能登进去。回收这件事要做成 HR 流程里的固定动作，而不是靠领导记着。



## 七、数据库定期维护，别等出问题才管



数据库像汽车，不保养会慢慢出问题。



中小企业的数据库通常就一台服务器，长期不维护会出现：慢查询越来越多、索引失效、表空间膨胀、日志占满磁盘、补丁漏打被扫到漏洞。



我们建议的基础维护动作：



- 每天看一眼慢查询日志，超过阈值的 SQL 要优化或加索引；


- 定期清理历史日志和过期数据，别让磁盘被无关文件占满；


- 数据库版本和安全补丁按厂商节奏更新，不要永远停留在初始安装版本；


- 根据慢查询、空间和监控证据安排维护；不要默认定期重建InnoDB表或索引，此类操作可能锁表或占用额外空间，需测试、备份和维护窗口。



维护频率和人员配置应根据业务重要性与告警确定。自动检查不能代替异常响应、补丁验证和恢复演练。



## 写在最后



这 7 件事没有一件是高大上的技术概念，但合在一起，就是中小企业数据安全的底盘。



我们在交付企业网站、行业系统和后台应用时，建议按风险把相关项目纳入交付及维护清单：密码哈希存储、全站 HTTPS、异地备份加恢复演练、操作日志审计、角色权限、离职账号流程、数据库定期维护。上述内容是评估清单，不代表所有项目均包含持续安全运营；具体实施、演练频率、持续维护及费用应在合同中明确。



如果你的企业系统是好几年前找别人做的，建议对照这 7 条自查一遍。哪一条没做到，先补哪一条，比着急上什么新概念更实在。更多关于企业 IT 基础建设的讨论，可以继续阅读广深互联官网 (https://www.99idc.cn/)和技术博客 (https://www.99idc.cn/blog.php)里的相关文章。





作者：广深互联技术团队
