SQL Server里头加密和防注入那些事儿，怎么操作才靠谱点

在SQL Server里要保证数据安全，主要得搞定两块：一是数据本身别让人偷看了，也就是加密；二是别让坏人用歪门邪道把数据库搞乱或偷走数据，也就是防注入，这两件事做踏实了，数据库的安全性就能上去一大截。

第一部分：数据加密，让偷看者白忙活

加密就像是给数据上了一把锁,就算数据文件被人直接拷贝走了，没有钥匙（也就是密钥）他也打不开，看到的只是一堆乱码，在SQL Server里，有几种常见的加密方式，得根据情况选着用。

1. 透明数据加密（TDE） 这个功能的名字很形象，透明”的，它对咱们程序员和应用程序来说，几乎没啥感觉，你不需要改任何代码，它的原理是直接加密整个数据库的数据文件和日志文件。（来源：Microsoft Learn官方文档，SQL Server安全系列）开启TDE之后，任何写到磁盘上的数据都是加密的，读的时候再自动解密，这特别适合防止有人直接把服务器的硬盘拔走这种物理盗窃，操作起来也相对简单，主要步骤就是在数据库里创建一个主密钥，然后创建证书，最后对数据库启用TDE，但是要注意，TDE不加密网络传输中的数据，也不能防止有数据库账号的人直接查询数据，而且它会占用一定的CPU资源。

2. 列级加密 如果只有少数几列数据特别敏感，比如身份证号、密码、银行卡号，那没必要加密整个库，用列级加密更精细，这个就需要动点代码了，具体做法是，先用CREATE MASTER KEY在数据库里创建一个主密钥，然后用CREATE CERTIFICATE或CREATE SYMMETRIC KEY创建证书或对称密钥，最后在插入或更新数据时，用EncryptByKey这样的函数来加密具体的列值。（来源：Microsoft Learn官方文档，加密层次结构相关章节）查询的时候，再用DecryptByKey函数解密才能看到原文，这种方式的好处是控制精准，缺点是用了加密的列，数据类型会变成varbinary，查询起来不方便，也不能用索引，会影响查询速度，对于密码这种不需要还原的，更应该用的是单向散列（Hash）函数，比如HASHBYTES，存进去的只是指纹，永远无法反推原文，校验时对比指纹是否一致即可。

3. 备份加密 这是很多人会忽略的一点，你辛辛苦苦把数据库加密了，结果备份文件没加密，等于白干，SQL Server企业版支持备份时直接加密，在做备份（BACKUP DATABASE）命令里，可以指定加密算法和用的证书或非对称密钥。（来源：Microsoft Learn官方文档，BACKUP语句语法说明）这样生成的备份文件也是加密的，恢复时必须提供正确的证书才行。

第二部分：防SQL注入，把坏心眼儿堵在门外

SQL注入是头号安全威胁,原理就是坏人把恶意的SQL代码混在正常输入里，骗过程序一起发给数据库执行，比如一个登录框，他输入用户名时不是老老实实写“张三”，而是写“张三' OR '1'='1”，如果程序拼接SQL字符串，就可能绕开密码验证，防注入的核心就一条：永远别相信用户输入的东西，坚决不用字符串拼接SQL。

1. 参数化查询（首选方案） 这是最有效、最根本的解决办法，它的原理是把SQL代码和用户输入的数据分开传送，SQL语句本身是一个固定的模板，SELECT * FROM Users WHERE UserName = @UserName AND Password = @Password”，里面的@UserName和@Password只是占位符，程序执行时，把用户输入的值作为参数，单独传给这些占位符。（来源：OWASP基金会发布的应用程序安全指南）数据库引擎能清楚地知道哪些是指令，哪些是数据，绝对不会把数据当成指令来执行，无论用户在输入框里填什么妖魔鬼怪，到了数据库里都只是一段普通的字符串数据，无法兴风作浪，在C#、Java这些编程语言里，用SqlParameter之类的对象就能轻松实现。

2. 使用存储过程 存储过程是预先在数据库里编译好的SQL语句集合，应用程序通过调用存储过程名并传递参数来执行，因为存储过程的逻辑是固定的，参数也是传递进去的，天然就避免了字符串拼接带来的注入风险，这和参数化查询的思想是相通的，但是要注意，如果在存储过程内部又用EXEC动态拼接了传入的参数，那还是会存在注入漏洞，所以存储过程内部也要避免动态SQL拼接，或者使用sp_executesql并参数化。（来源：各类数据库安全最佳实践总结）

3. 最低权限原则 这是个非常重要的安全原则，给应用程序连接数据库用的那个账号，权限一定要给得“小气”，这个账号通常只需要有对特定表执行增删改查的权限就够了，绝对不要给它db_owner（数据库所有者）或者sysadmin（系统管理员）这种至高无上的权限。（来源：信息安全基础原则）这样就算万一被注入成功了，破坏力也有限，它删不了表，也删不了库。

4. 输入验证和过滤 这算是第二道防线，在数据传到数据库之前，在程序代码里先对用户输入做检查，如果期望是数字，就检查是不是数字；期望是邮箱，就检查格式像不像邮箱，可以过滤掉一些明显恶意的字符，比如单引号，但这个方法不能作为主要手段，因为坏人绕开过滤的方法太多了，编码一下可能就过去了，核心还得靠参数化查询。

总结一下怎么才靠谱：

• 加密方面：根据需求来，怕丢硬盘就用TDE；只有少数敏感字段就用心跳加密或Hash；别忘了备份也要加密。
• 防注入方面：铁律就是全面采用参数化查询（或参数化调用的存储过程），彻底告别字符串拼接SQL，给数据库连接账号最小权限。

把这两方面做到位,SQL Server的安全基础就打得很牢固了。