SQL Server在安全保障体系里的那些事，等保要求下的实操和心得分享

主要参考了我在实际工作中参与的几个需要满足“网络安全等级保护”（简称等保）二级和三级要求的SQL Server数据库建设项目，以及一些来自国内知名安全论坛如“看雪论坛”、“安全客”上技术同仁的零星经验分享，下面我就把这些实操和心得用大白话讲一讲。

等保不是什么神秘的东西,你可以把它理解成国家给信息系统定的一套“体检标准”，级别越高，要求越严格，SQL Server作为数据库，是存放核心数据的地方，在等保测评里绝对是重点检查对象，相当于心脏部位。

等保对SQL Server的核心要求是啥？

说白了,就是三件事：谁能动、动了什么、出事了怎么办，对应到专业术语就是身份鉴别、访问控制、安全审计，我们得向测评中心证明，我们的数据库在这三方面做得很到位。

具体怎么实操？

1. 谁能动”（身份鉴别和访问控制）

   • 严禁sa账号裸奔：这是最基本也是最容易栽跟头的地方，SQL Server默认有个超级管理员账号sa，很多开发图省事直接就用上了，密码可能还设得特别简单，等保首先要求你必须禁用sa账号，或者给sa改一个超级复杂的密码（长度、大小写、数字、符号都得有），并且记录谁用sa登录过，我们的做法是，干脆禁用sa，为每个需要操作数据库的人创建独立的账号。
   • 权限只给最小的：绝对不能一个账号通吃所有数据库，要遵循“最小权限原则”，一个负责报表查询的账号，只给它读的权限，绝对不能给它删除数据、修改表结构的权限，我们当时花了大量时间梳理业务，为不同岗位（如应用读写、后台查询、运维管理）创建了不同的数据库账号和角色，像搭积木一样分配权限。
   • 密码策略要强硬：不能再用“123456”这种密码了，我们要在数据库服务器层面或者域策略里，强制要求密码必须满足复杂性（大小写数字特殊字符混合）、有最短使用期限（比如不能一天改好几次）、有最长使用期限（比如90天必须换密码），这点可以参考微软官方文档关于如何配置强密码策略的部分。

2. 动了什么”（安全审计）

   • 必须开启审计：SQL Server自己有个叫“SQL Server Audit”的功能，或者也可以用第三方工具，等保要求你必须记录关键操作，什么是关键操作？谁成功登录了、谁失败了尝试登录、谁修改了重要数据（增删改）、谁修改了用户权限、谁查看了敏感数据。
   • 审计日志要保护好：光记录还不行，日志本身不能被轻易删除或篡改，我们的做法是，把审计日志写到另外一个专门的、权限很高的文件共享服务器上，数据库管理员自己都没法直接删除这些日志，这样就算有人入侵了数据库，他也抹不掉自己的犯罪记录，这点是参考了等保基本要求中关于审计数据保护的规定。
   • 定期看日志：日志堆在那里不看等于没用，等保要求你得有人定期去检查这些日志，看看有没有异常行为，半夜三经有个账号频繁登录失败，或者一个查询账号突然开始执行删除操作，我们当时是用脚本做了个简单的日志分析，把可疑事件发邮件告警。

3. 出事了怎么办”（其他加固措施）

   • 加密很重要：等保要求敏感数据在网络上传输和静止存储时都要加密，传输加密好办，强制要求应用程序用SSL/TLS连接数据库就行，静止数据加密，SQL Server有透明数据加密（TDE）功能，可以把整个数据库的文件加密，这样即使黑客把数据库文件偷走了，他也打不开，不过这个功能需要企业版，而且对性能有点影响，要评估好。
   • 补丁要跟上：微软经常发布安全补丁，修复已知漏洞，等保要求你有一个漏洞和补丁管理流程，定期评估和安装安全补丁，但这里有个心得：不能闭着眼睛直接在生产环境打最新补丁，一定要先在测试环境充分测试，确认不会把业务系统搞垮再操作。

一些心得体会

• 等保是个系统工程，不是数据库一个人的事，数据库安全依赖于操作系统安全、网络安全、应用安全，你数据库配置得再安全，应用系统存在SQL注入漏洞，黑客还是能轻松进来，所以需要和运维、开发、网络团队紧密配合。
• 文档记录极其重要，测评的时候，专家不会只看你界面怎么点的，他会要你提供一堆文档：安全策略文档、权限分配清单、审计日志检查记录、培训记录等等，平时不整理，临时抱佛脚会非常痛苦。
• 平衡安全和效率，安全措施肯定会带来一些麻烦，比如权限细分后，开发人员调试起来更费劲；复杂的密码老是忘记，不能因为追求绝对安全而让业务无法开展，要在中间找到一个平衡点，并且对内部员工进行安全意识培训，让他们理解为什么要有这些规定。

把SQL Server放在等保体系里考量，就是逼着我们把以前那些不规范的“野路子”收起来，用一套严谨、可追溯的方法来管理数据库，过程虽然辛苦，但做完之后，整个数据资产的安全性确实有了质的提升，心里也踏实很多，这些实操经验，其实也完全适用于任何对安全有要求的数据库环境，不单单是为了应付检查。