SQL Server 安全回顾

§十年以前, 数据库是:               •相对安全               •存储于中央数据中心 – 而非分布式               •外部信息访问需要通过职员，采购经理等.               •极少报道安全问题   §现在数据库越来越多的可以被外部访问:               •供应商直接连接               •顾客直接连接               •顾客和合作伙伴直接共享数据   §在应用程序栈中，数据是最宝贵的资源               •随着更多的整合和聚集，价值也在增长               •存在数据被窃取，篡改，或销毁的机会   §数据库安全是一个不断增长的问题:               •自从2001年1月已发出101个 DB 警告- www.securitytracker.com               •在 SANS/FBI的前20名列表上，有2个数据库方面的问题 -http://www.sans.org/top20/

一、 SQL Server 安全体系结构

身份验证模式 §SQL Server 提供2种安全模式:     •Windows 身份验证模式 (默认)        所有客户端支持被信任的连接（trusted connections)     •混合模式 (Windows 和 SQL Server 身份验证)        一些客户端不支持被信任的连接 Windows 身份验证模式 §Windows 2000 安全机制包括:     •密码属性和有效期     •审核     •账户锁定     •使用Kerberos进行交互认证    §其他的好处:                 •当用户登录到Windows 2000 时，一个令牌(token)被创建，因此无需为SQL Server重新输入凭证|                 •权限可以授予给Windows 组或者单个用户 Windows身份验证过程 §一个Windows 令牌通过安全支持提供接口(SSPI)传给SQL Server §SID在master 数据库的sysxlogins 表中被检查      •检查被拒绝的权限      •为用户检查被授权的权限      •如果没有发现用户权限，则检查组的权限 有关 Windows身份验证的问题 §在可能的情况下，推荐Windows身份验证模式连接到 SQL Server 2000 §然而, 需考虑到:      •域控制器不可用时，用户无法连接      •用户必须有一条连接到域控制器的网络路径      •用户必须在SQL Server 域所信任的域中      •在对组的改变被接受之前，用户必须先注销用户 推荐的安全模型 Windows 2000 用户 Windows 2000 组 登录 – SQL Server (对于组) 用户自定义数据库角色 (包含数据库用户) 分配 Windows用户到组 映射 Windows 组 to SQL登录账号 分配 登录账号到用户自定义数据库角色 给角色授予权限

二、网络考虑

§SQL Server 网络通信综述   §网络协议加密   §SQL Server 和防火墙  SQL 连接 APIs综述   §命名管道 (Named Pipes)              •造成更多的网络流量              •本地管道是非常快的   §TCP/IP Socket              •创造较少的网络流量   §多种协议              •RPCs   §所有的APIs 能支持加密通信              •通过 “super sockets” 包装 (wrapper) – ssnetlib.dll   §配置 客户端连接 API   §配置 SQL Server连接API SQL Server 通信安全   §确保通信渠道的安全              •默认情况下, 所有的通信是以明文形式, 除了用户 ID 和密码              •然而, 使用加密存在缺陷          http://www.nextgenss.com/products/ngssqlcrack.html              •使用SSL或Windows身份认证对此有所减轻   §SSL              •好处: 被所有的连接APIs支持              •缺点: 加密算法计算昂贵   §IPSec              •好处: 应用程序独立; 开销少              •坏处: 管理有些复杂 防火墙的应用   §将网络分割成多个安全区域，以防火墙分隔   §防火墙阻止所有通信，然后有选择性地仅允许所需要的通信   §确保在外围封锁与 SQL Server 有关的 TCP 端口              •端口 1433 - 由默认实例监视              •端口 1434 - 用户数据报协议 (UDP)              •与命名实例相关的其他端口   §如果将服务器安装到 Windows 域内部              •应配置内部防火墙允许 Windows 身份验证              •打开 Kerberos 或 NTLM 身份验证所使用的端口   §其他注意事项  禁用 NetBIOS 和 SMB   §外围网络中的服务器应禁用所有不必要的协议   §NetBIOS 使用下列端口：              •UDP/137（NetBIOS 名称服务）              •UDP/138（NetBIOS 数据报服务）              •TCP/139（NetBIOS 会话服务）   §禁用 SMB 要删除              •“Microsoft 网络的文件和打印机共享”              •“Microsoft 网络客户端”   §SMB 使用下列端口：              •TCP/139              •TCP/445

三、 SQL Security 最佳实践

安装上的考虑 - 服务器的隔离   §将一台计算机专用作数据库服务器。   §不要在域控制器上安装 SQL Server。   §不要在同一台计算机上运行 Microsoft Internet 信息服务 (IIS) 和 SQL Server。   §如果必须在一台计算机上运行多个服务，请在各自的 Windows 帐户下运行各个服务。   §在非系统卷上安装 SQL Server 程序和数据库文件，以便与操作系统分开。  安装上的考虑 - 仅安装必须的组件   §生产用的数据库服务器上选择 “自定义“ 安装选项, 可忽略以下组件              •升级工具 用于升级 SQL Server 6.5 版数据库              •性能计数器 用于性能监视和优化              •联机丛书 SQL Server 文档              •开发工具 包括可供 C 语言开发人员使用的头和库文件以及 MDAC 和 XML SDK、用于存储过程调试的界面              •代码示例  供开发人员学习的代码示例 SQL 服务帐号   §在本地计算机上，SQL 需要一个账号启动 SQL Server 和SQL Agent 服务               •有很多的安装以 LocalSystem 运行               •防卫: 配置拥有最少特权的本地帐号去作为服务账号启动本地计算机的SQL Server和 SQL Agent 服务   §本地 vs. 域账户来启动 SQL Service               •倾向本地帐号               •域帐号为攻击者提供不必要的起点               •然而,在很多的服务器上对很多本地账号的管理是一个弱点 服务账户需求   §对SQL数据文件夹和注册表的读-写访问   §对SQL 程序文件和EFS 键的读访问   §账号必须能 ‘以服务登录’   §配置账号密码选项为 用户不能更改密码’ 和 密码永远不过期’   §从企业管理器中设置服务账号将设置这些权限 通用安全大纲 经常为Windows和SQL Server升级 可能的话选择 Windows身份认证模式 特别小心在 IIS 上配置SQL XML支持 检查所有其他访问SQL Server 2000的方法     企业管理器，Microsoft Access,查询分析器，osql,等。 应用程序不要将敏感信息返回给客户     消息和错误信息要用更普遍的回应来代替 在每个服务器上创建标准的SQLAdmin 数据库用来创建用于管理的存储过程 所有用户的默认数据库改为一个数据库而非master 不允许用户在master 或msdb 上创建对象 考虑从生产服务器中删除pubs和northwind示例数据库 每个数据库的public角色代表数据库中所有用户和角色的默认权限     要严格的直接为public 角色授予权限     不要拒绝权限给 public 角色 从所有用户数据库中清除guest 账户 从物理和逻辑上隔离 SQL Server          加锁的机房，配以水警、火警/灭火监视系统     绝对不要直接连接到 Internet          定期备份所有数据，并将副本存储在现场以外的安全位置 应安装 SQL Server 于 NTFS 文件系统上     NTFS 更稳定且更易于恢复, 支持更多的安全选项  (ACL, EFS, …) 使用 Microsoft 基线安全分析器 (MBSA) 对服务器进行监视     MBSA 工具用来扫描几个 Microsoft 产品中普遍存在的不安全配置 http://www.microsoft.com/downloads/details.aspx?FamilyID=9a88e63b-92e3-4f97-80e7-8bc9ff836742&DisplayLang=en 链接服务器安全 使用企业管理器或者 sp_addlinkedsrvlogin 去管理链接服务器安全 为了高安全性,在 Windows 2000活动目录服务下使用Kerberos的安全账号委托特性|     当分布式数据的请求在服务器间传递时,客户可以保持以被Windows认证了的身份 DTS 包安全 DTS 包可以拥有一个所有者密码或者一个用户密码     所有者密码允许用户在DTS设计器中查看和更改包     用户密码允许用户执行这个包 分配 所有者密码给所有的包

四、 开发者和SQL 安全

§连接字串   §最低特权原则   §SQL 注入 攻击 如何安全的连接到 SQL Server 上   §连接字串指明使用哪种类型的身份认证方式               •ADO和ADO.NET的值一样   §Windows 身份认证               •连接字串包含 Trusted_Connection=yes   §SQL Server 身份认证               •连接字串包括 uid=username;pwd=password               •这个信息会被发到线上!   §请求的模式必须与 SQL Server 配置相匹配   §安全地存储连接字串               •更倾向DPAPI, 参考 Writing Secure Code. “Storing Secrets” 最低特权原则   §尽可能安全的连接               •不要使用 sa 登录! (或者任何 sysadmins 成员)               •为你的应用程序创建登录账号并授权它仅需要连接的数据库   §以最小的权限需要登录运行               •把登录账号的权限定为所需语句和对象的最小需要   §与直接对数据库的访问相比，视图和存储过程更好               •基于商业规则使用视图分割数据               •对所有的插入，更新，删除操作使用存储过程   §质疑开发者的非标准功能需求               •例如 扩张存储过程, 发电子邮件等. SQL 注入 攻击综述   §是一种脚本注入式的攻击   §恶意用户输入用来影响被执行的SQL脚本                防止 SQL Injection进攻   §不要用字串连接建立 SQL查询                •而使用 SQL 变量，因为变量不是可以执行的脚本   §创建存储过程    §使用变量SQL查询 防止 SQL 注入 的最佳实践   §不要信任用户输入!               •严格定义什么是有效输入并拒绝任何其他的形式               •使用Regular Expression来简化有效性定义               •不要依赖客户端进行检查 – 在服务器端检查   §不要暴露太多的信息/细节给攻击者 (信息暴露)   §使用低特权的登录账号连接数据库服务器实现深层次的防护               •不以sa或者sysadmin角色成员连接