INSIGHTS / 技术洞察

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

技术实践作者:广深互联技术团队
文章目录 9 个章节

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

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

引言

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

中小企业数据安全清单盾牌图

勒索软件加密文件、客户数据库被拖库、员工离职带走账号密码,这些事每年都在发生。需要注意的是,对大多数中小企业来说,不需要上来就堆安全设备、上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 基础建设的讨论,可以继续阅读广深互联官网和技术博客里的相关文章。


作者:广深互联技术团队

项目开始前,需要准备什么?

可以先整理业务目标、使用角色、当前流程和参考资料。我们会围绕需求范围、优先级和交付边界展开沟通。

已有系统可以保留并接入吗?

可以先评估已有系统的接口、数据权限与维护条件,再确定接入方式。无需因为新项目就默认替换所有系统。

软件开发费用如何评估?

费用取决于功能范围、设计、数据迁移、集成、测试和维护安排。先明确交付范围,再形成可比较的报价。

项目会交付哪些资料?

按约定交付设计、源码、部署说明及测试资料。依赖、第三方账号与素材权利等边界应在项目范围中写清。

AI应用如何保护企业数据?

先明确数据来源、访问角色、使用目的和模型接入边界;对于不确定结果与重要决策保留人工复核。

上线后如何维护?

根据系统使用情况约定维护范围、备份恢复、故障反馈与版本更新方式,具体响应时间以服务约定为准。

项目咨询