SQL Server 安全篇——服务账号安全性（3）——服务账号的威胁与对策

本文属于SQL Server安全专题系列

 在安全领域中，“攻”“防”一直在持续着，并且很不幸，攻击者永远处于主动地位，一切防御方案都是基于已经发生的攻击来制定的，但是深入理解原理，不仅可以快速应对攻击，也能从中推测出一些可能的衍生攻击方案并作出提前防御。
  本文将集中在服务帐号上的攻击介绍。曾经看过一部外国电影，名字早忘了，但是有一句话一直记在脑海里（大概也有十几年了吧）：世界上不存在没有漏洞的系统。所以我不能完全防御所有的攻击，总会有漏洞可以进入你的系统。
 假设一个攻击者已经进入了实例，不管是来自于外部还是内部漏洞，比如SQL注入，一旦进入实例，那么就可以使用SMB（server message block）攻击来破坏服务器帐号凭据。又比如一直都被提醒的xp_系统存储过程如xp_dirtree，可以直接使用public角色即不需要任何权限就能够执行，进入实例后，使用这个系统存储过程，可以找到服务器上的文件夹信息甚至猜测的特定文件。要访问文件夹，必须先对SQL
Server引擎服务帐号授权，当存储过程借用服务帐号访问文件夹，那么攻击者可以使用 Metasploit 等工具中的 SMB 捕获来捕获身份验证请求。里面还包含哈希密码, 还包括伪随机加密号, 这意味着攻击者有足够的信息通过使用专用工具来显示明文密码。

防范策略：

首先当然是选择合适的服务帐号，如果动不动就使用最高特权的帐号，那么安全性可想而知。但是由于不同企业的实际需求不同，不能一概而论。需要权衡安全和操作支持力度。绝对的安全和绝对的便利都是极端的。比如微软的最佳实践是隔离服务帐号，单独专用。而在现实当中，随着数据库环境的增多及其他SQL服务的增加，帐号管理将面临越来越大的复杂度。但是如果为了减少这种现象而通用服务帐号，虽然增加了操作支持力度，但是也降低了安全性。
 这是一个权衡的问题，并没有绝对的对与错，对于域层面做得很好的企业，使用MSAs、gMSAs和适当使用虚拟帐号，会更有价值。但是即使在OS和域层面都已经做得很好，DBA团队所严重依赖的自动化管理操作又会因为虚拟帐号并没有足够权限而带来很多其他问题。
 对此，如果是使用域账号作为服务帐号，建议对每套应用进行隔离。但是要注意权限不能过高，也不能不够。
 在SQL 2016中，基于其需要服务帐号的组件，最多可以到11个服务帐号，每个帐号配置最低所需权限，这种量级如果扩展到HA/DR层面和且用层面，帐号数量将非常可观，不管有什么建议，都应该按照自己的实际情况做好规划和按计划调整现有环境。
 最后强调一下，每个服务帐号类型都有其好处和坏处，但是总得来说，优先使用虚拟帐号、MSAs和gMSAs会更加安全。另外从系统外围就应该做好各层的防御。