一、SqlServer默认设置的那些坑
刚接触SqlServer的时候，总觉得微软的产品开箱即用很省心。直到有次半夜被叫起来处理数据泄露事故，才发现默认配置里藏着不少"惊喜"。今天就带大家扒一扒这些隐藏的雷区。
先说个最常见的坑：sa账户默认启用。这个超级管理员账户就像把万能钥匙，默认密码复杂度要求低得可怜。见过太多企业直接用"sa/123456"这种组合，黑客们都要笑醒了。
-- 检查sa账户状态示例（T-SQL）
SELECT name, is_disabled
FROM sys.sql_logins
WHERE name = 'sa';
-- 安全建议：要么禁用，要么改超强密码
ALTER LOGIN sa WITH PASSWORD = 'C0mpl3xP@ssw0rd!2023', CHECK_POLICY = ON;
还有个默认开启的"xp_cmdshell"，这玩意儿能让SQL Server直接执行操作系统命令。想象下黑客拿到数据库权限后还能操作服务器是什么场面？
二、权限管理的水有多深
权限管理默认配置就像个不设防的金库。新建的数据库用户默认拥有public角色，而public角色默认有连接任何数据库的权限。这相当于给每个访客发了万能门禁卡。
-- 查看public角色权限示例
SELECT permission_name, state_desc
FROM sys.database_permissions
WHERE grantee_principal_id = DATABASE_PRINCIPAL_ID('public');
-- 正确做法：精确控制权限
REVOKE CONNECT TO public;
GRANT CONNECT TO specific_user;
更可怕的是"跨数据库所有权链接"这个默认开启的功能。当数据库A和B都有用户User1时，User1在A的权限可能莫名其妙延伸到B。我们项目就吃过这个亏，开发环境的测试账号居然能访问生产库！
三、加密配置的致命疏忽
你以为的加密和实际的加密可能差着十万八千里。SqlServer默认使用自签名证书进行TLS加密，这种证书在中间人攻击面前形同虚设。
-- 检查加密配置示例
SELECT session_id, encrypt_option
FROM sys.dm_exec_connections;
-- 升级加密配置的正确姿势
-- 先在Windows服务器安装CA签发的正式证书
USE master;
GO
DROP CERTIFICATE MySSLCert;
GO
CREATE CERTIFICATE MySSLCert
FROM FILE = 'C:\certs\official_cert.cer'
WITH PRIVATE KEY (FILE = 'C:\certs\private_key.pvk',
DECRYPTION BY PASSWORD = 'Pr1v@teK3yP@ss');
还有个容易被忽视的点：默认情况下，备份文件是不加密的。见过有人把数据库备份到共享目录，结果备份文件被轻易拷贝走的案例。
四、审计功能的正确打开方式
默认的审计配置基本等于没配置。关键操作比如谁删了表、谁修改了权限，这些日志默认都不会记录。等出了事查日志才发现一片空白。
-- 创建服务器级审计示例
USE master;
GO
CREATE SERVER AUDIT DataSecurityAudit
TO FILE (FILEPATH = 'E:\SQLAudits\')
WITH (QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE);
GO
-- 添加关键操作监控
CREATE DATABASE AUDIT SPECIFICATION TrackSensitiveOperations
FOR SERVER AUDIT DataSecurityAudit
ADD (SCHEMA_OBJECT_CHANGE_GROUP),
ADD (DATABASE_PERMISSION_CHANGE_GROUP),
ADD (SELECT, INSERT, UPDATE, DELETE ON SCHEMA::dbo BY public);
GO
-- 启用审计
ALTER SERVER AUDIT DataSecurityAudit WITH (STATE = ON);
记得把审计日志存到独立服务器，否则黑客清理现场时可能连审计日志一起删了。别问我怎么知道的...
五、实战中的加固方案
经过多次血泪教训，我们团队总结出一套加固方案。首先是禁用所有危险功能：
-- 安全加固脚本示例
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 0;
EXEC sp_configure 'Ole Automation Procedures', 0;
EXEC sp_configure 'clr enabled', 0;
RECONFIGURE;
-- 禁用SA账户
ALTER LOGIN sa DISABLE;
然后是权限最小化原则。我们为每个应用创建专属账户，权限精确到表级别：
-- 精细化权限控制示例
CREATE LOGIN AppLogin WITH PASSWORD = 'AppSpec1ficP@ss';
CREATE USER AppUser FOR LOGIN AppLogin;
-- 只授予必要的读写权限
GRANT SELECT, INSERT, UPDATE ON dbo.Customers TO AppUser;
GRANT EXECUTE ON SCHEMA::proc TO AppUser;
DENY DELETE ON dbo.Customers TO AppUser;
最后是定期安全检查脚本，我们设置SQL Agent作业每月自动运行：
-- 安全检查脚本示例
DECLARE @Results TABLE (CheckItem NVARCHAR(100), Status NVARCHAR(50));
-- 检查sa状态
INSERT INTO @Results
SELECT 'SA Account Status',
CASE WHEN is_disabled = 1 THEN '安全' ELSE '危险' END
FROM sys.sql_logins WHERE name = 'sa';
-- 检查xp_cmdshell状态
INSERT INTO @Results
SELECT 'xp_cmdshell Status',
CASE WHEN value_in_use = 0 THEN '安全' ELSE '危险' END
FROM sys.configurations WHERE name = 'xp_cmdshell';
SELECT * FROM @Results;
六、那些年我们踩过的坑
说说真实案例。某次客户投诉数据异常，查了半天发现是开发人员在测试环境执行了跨库查询，误改了生产数据。根本原因就是默认的跨数据库所有权链接。
还有个更惨的：某电商平台被拖库，调查发现攻击者通过默认开启的SQL Server Browser服务获取了实例信息，再利用弱密码爆破成功。如果当初禁用这个服务，可能就避免了这场灾难。
最离谱的是有次数据泄露，居然是因默认错误日志包含敏感信息。黑客通过精心构造的错误消息，居然把数据库连接字符串给套出来了！
七、最佳实践总结
经过这些教训，我们总结出SqlServer安全加固的黄金法则：
- 安装完立即修改sa密码并禁用
- 关闭所有不必要的功能（xp_cmdshell、Ole Automation等）
- 实施最小权限原则
- 启用细粒度审计
- 使用正式证书加密通信
- 定期检查安全配置
- 备份文件必须加密
- 错误日志脱敏处理
- 禁用SQL Server Browser服务
- 保持补丁更新
安全没有银弹，但堵住这些默认设置的漏洞，至少能让攻击者知难而退。记住，数据库安全不是一次性工作，而是需要持续监控和改进的过程。
最后送大家个实用脚本，一键检查常见安全问题：
-- SqlServer安全体检脚本
SELECT
'SA账户状态' AS 检查项,
CASE WHEN is_disabled = 1 THEN '安全' ELSE '危险' END AS 状态,
'建议禁用或加强密码' AS 修复建议
FROM sys.sql_logins WHERE name = 'sa'
UNION ALL
SELECT
'xp_cmdshell状态',
CASE WHEN value_in_use = 0 THEN '安全' ELSE '危险' END,
'建议禁用该功能'
FROM sys.configurations WHERE name = 'xp_cmdshell'
UNION ALL
SELECT
'跨数据库所有权链接',
CASE WHEN is_db_chaining_on = 0 THEN '安全' ELSE '危险' END,
'建议关闭该功能'
FROM sys.databases WHERE name = DB_NAME()
UNION ALL
SELECT
'TLS加密状态',
CASE WHEN encrypt_option = 'TRUE' THEN '安全' ELSE '危险' END,
'建议启用加密'
FROM sys.dm_exec_connections WHERE session_id = @@SPID;
评论