SQL Server安全专题

186 篇文章 6 订阅
65 篇文章 0 订阅

 

     随着大数据、云计算的兴起跟数据量的几乎全量存储,使得安全性越来越受重视。所以这里根据工作经历、多本专家书籍跟官方文档整理出一个安全系列专题,但是毕竟安全这个东西,很广、很深,而且涉及从行政手段、技术手段,从网络到硬件到操作系统最后到数据库甚至行列的内容,无法真正写一个完完全全的专题,更多地是希望起到抛砖引玉的作用。

     另外由于某种目的(应该在2018年就会揭开答案),有某些部分应该写进去但是我特意没有写,不过我觉得写进去的应该已经足够应付大部分情况。本系列主要版本集中在2008~2014中。

     最后,由于专题部分都很长,耗时也会相对长一点,在这个过程中,不排除会改动已发布的内容(主要是debug和丰富内容),所以希望读者能够不定期查看。


     备注:由于博客的编辑器反复变动,实在没有精力在短时间内调整成好看的样子,希望读者不要过于介意布局是否美观。我会尽量不停地修复和改进。

 

 这一篇是一个“目录”,为了让读者有一个概览和快速链接,已经写完的文章会同步添加链接



安全模型篇


SQL Server 安全篇——SQL Server 安全模型(1)——安全性主体层级
SQL Server 安全篇——SQL Server 安全模型(2)——实例级别安全性
SQL Server 安全篇——SQL Server 安全模型(3)——数据库级别安全性


审核篇


SQL Server 安全篇——SQL Server 审核(1)——概览
SQL Server 安全篇——SQL Server 审核(2)——审核实操
SQL Server 安全篇——SQL Server 审核(3)——自定义审核事件


数据层篇


SQL Server 安全篇——数据层面安全性(1)——架构
SQL Server 安全篇——数据层面安全性(2)——所有权链接( Ownership Chaining)
SQL Server 安全篇——数据层面安全性(3)——模拟(Impersonation)


服务账号篇


SQL Server 安全篇——服务账号安全性(1)——服务账号类型
SQL Server 安全篇——服务账号安全性(2)——SQL Server服务
SQL Server 安全篇——服务账号安全性(3)——服务账号的威胁与对策


安全元数据篇


SQL Server 安全篇——安全元数据(1)——安全主体(Principal)元数据
SQL Server 安全篇——安全元数据(2)——安全对象(Securable)元数据
SQL Server 安全篇——安全元数据(3)——审核(Audit)元数据

SQL Server 安全篇——安全元数据(4)——加密(Ecryption)元数据

SQL Server安全牌——安全元数据(5)——元数据自身安全性


加密篇


SQL Server 安全篇——SQL Server加密(1)——加密概念
SQL Server 安全篇——SQL Server加密(2)——加密数据
SQL Server 安全篇——SQL Server加密(3)——透明数据加密(TDE)


外围篇


SQL Server 安全篇——降低外围威胁(1)——网络配置

SQL Server 安全篇——降低外围威胁(2)——禁用不安全功能

CheckLists

Securing Checklists

  • 5
    点赞
  • 32
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
SQLServer安全及性能优化 修补漏洞 安装程序补丁修补漏洞 随时关注微软官方网站补丁升级 关闭不必要的端口 关闭联必要的服务 数据库引擎 SQL Server Analysis Services SQL Server Reporting Services SQL Server Integration Services SQL Server 代理 SQL Full-text Filter Daemon launcher SQL Server Browser 同时开启所有服务系统性能会变得很差,根据需要手动启动或者禁用某个服务 DTC: Distributed Transaction Coordinator(分布式事务处理协调器),用于协调多个数据库、消息队列、文件系统等等资源管理器的事务,由于内部开发中并不使用这个功能,远程数据库服务器上也并不经常使用,因此建议关闭这个服务 禁用不使用的协议 Shared Memory 默认为已启用状态,这个协议只能用于本地连接,不能用于远程连接,一般用于其它协议出问题的时候管理作诊断使用 TCP/IP 禁用不需要使用的协议,减少网络攻击对象 减少监听的网卡和IP地址 改变监听端口号 安全地设置账户 Windows身份验证[微软推荐的方式] 优势: 1.访问SqlServer时速度更快,不用输入用户名和密码 2.可以利用Windows系统的自身工具和安全策略管理账户 3.安全确认和口令加密、审核、口令失效、最小口令长度和账号锁定 SqlServer身份验证 1.将sa账户名更改为其它账户名比如nocial,防止黑客利用sa进行攻击 2.删除不使用的账户 3.对已有账户设置安全密码[强制密码规则] 4.限制登录->远程登录、匿名登录 5.限制用户角色和权限,一般将权限设置到最低。设置角色的时候不要为public角色授予任何权限,并且从sysadmin这个角色中删除windows的administrators组,提高系统安全性。 删除不必要的数据库对象 删除危险的存储过程 xp_cmdshell:执行操作系统命令,这是一个系统后门[可以移动文件位置、创建用户、提升用户权限],建议不需要则删除掉。 ole自动化存储过程 任务管理存储过程 强化文件和目录安全 数据库最终以文件的形式存储在文件系统中 使用NTFS设置权限 限制共享【不能设置为完全控制】 及时审核日志 sqlserver的审核机制可以帮助跟踪并且阻止系统中没有授权的用户他的行为。比如没有授权的用户登录系统会阻止这次登录,并且把这次操作给记录下来。审核机制既能跟踪失败记录也能跟踪成功记录。所有的数据库平台均在不同程度上提供了审查功能。 跟踪用户行为 保护数据库 数据库性能优化 数据库的性能优化主要有两个方面:减少查询比较次数、减少资源的征用。 使用工具Sql Server Profiler优化数据库的性能,减少资源的征用 SqlServer Profiler的功能 Sql Server Profiler的用法  定义跟踪  登录连接、失败和断开  Select、Insert、Update和Delete语句  SQL批处理的开始或结束  写入到Sql server错误日志的错误  安全权限检查  Profiler执行的事件 让Profiler监视我们感兴趣的事件,可以监视的事件太多,监视太多会大大降低性能和增大表数据,只监视与数据库的性能密切相关的哪些事件。常见的感兴趣的事件:  执行查询的性能  单个用户或应用程序的活动  逻辑磁盘的读写  语句级别上的CPU占用  Standart模板的事件类 优化数据库性能可以从五个层次来进行:  优先级一:减少数据的访问【减少磁盘访问】  优先级二:返回更少数据【减少网络传输或磁盘访问】  优先级三:减少交互次数【减少网络传输或磁盘访问】  优先级四:减少开销【减少CPU及内存开销】  优先级五:利用更多资源【增加资源】 技术上从四个方面来解决性能优化问题 1、调整数据库结构设计 2、调整应用程序结构设计 3、调整数据库SQL语句 4、调整服务器内存分配 如果不熟悉sqlserver可以使用数据库引擎优化顾问来对数据库提出优化建议,然后通过系统管理的修改达到目的。 数据库引擎优化顾问  数据库引擎优化顾问介绍  分析一个或多个数据库的工作负荷和物理实现,工作负荷可以是优化的sql语句或者sqlserver profiler的跟踪文件和数据表。我们可以在运行引擎优化顾问前运用sqlserver profiler记录一些事件,然后将跟踪结果存储为文件或者数据表,然后把这些提供给数据库引擎优化顾问,让它去分析。  提出合理的物理设计结构,物理设计结构包括数据库中的索引、索引视图、非聚集索引、聚集索引视图等等。对工作负荷进行分析后,数据库优化顾问会建议添加删除修改数据库的物理设计结构。推荐一组合理的物理结构以降低工作负荷的开销。从而提高数据库的性能 数据库性能优化的常见问题 如何发现问题,如何分析导致性能降低的原因仍然是数据库管理员要掌握的知识。 事务占用资源的时间过长,造成阻塞 许多用户同时访问数据库的时候会产生大量事务,许多用户同时竞争一个资源导致占用资源的时间过长,造成阻塞。从而降低了数据库执行效率。产生这样的现象的原因如下: 1、多表连接查询,查询期间占用多个表 2、事务需要占用太多资源,容易出现多个事务占用对方资源的状况。从而导致死锁 解决之道: 1、避免多表连接查询,联合过多的表会在查询中占用过多的资源。很容易因为别的事务占用资源而相互等待。 2、使用统一的SQL语句规范,特别是访问表的顺序要保持一致,这样可以避免互相占用资源而导致的死锁。 不合理的数据文件设置,影响事务处理的性能 当事务处理产生大量数据的时候,数据文件的大小如果设置不合理将导致数据文件的不断扩展,这也会影响到事务处理的性能,进而影响到整个数据库的性能。 1、频繁操作数据库,导致日志文件增长的过快,因为日志文件记录数据库的原始操作。所以它的增长速度比数据文件要快得多。当日志文件的增长大小设置不合理的时候会导致频繁地扩展文件。从而影响性能 2、查询操作比较频繁,系统数据Tempdb的大小设置不合理。 查询操作比较频繁的时候系统数据Tempdb增长得会比较快,因为查询所产生的临时数据都存放在这个数据库上。如果Tempdb过小当查询数据量较大的时候Tempdb会自动扩展,如果遇到频繁的查询会导致Tempdb不断扩展,从而影响系统性能。这种情况我尽可能地使查询的返回结果比较小 3、大量插入数据,导致数据文件增长过快。不要设置数据文件的自动收缩,它会在忙碌的系统上导致不必要的性能开销。所以如果没有特别需要不要设置数据库的自动收缩。最好采用手动收缩。 磁盘数据组织不合理,导致磁盘的访问次数过多 数据库的磁盘访问都是按照页来访问数据的,无论访问的数据再少都是以页为单位读取,1页为8K。所以如果将经常访问的数据放在一起,数据库读取尽量少的页面就能够完成读取操作。这样效率自然就提高了。也减少了磁盘头的来回移动。否则会多次读取硬盘页面导致访问的效率降低。 对于表A和表B、表C、表D,如果经常查询表A和表B中的数据,那么可以将他们放在同一个文件组M中;如果经常访问表C和表D中的数据可以将他们放在同一个文件组N中。这样读取效率就比较高,因为一次读取就可能包含了两个表中的数据,因此提高了查询效率。要解决“磁盘数据组织不合理,导致磁盘的访问次数过多”这个问题,我们可以将经常读写的数据放置在不同的磁盘上,也就是将经常在一起被多表连接查询的表放在同一个文件组上。这里强调:这里反复提到的“不同的磁盘”指的的是不同的磁盘,而不是同一个硬盘的不同分区。 批量导入数据的时候,要进行特殊设置 当用户需要大批量导入数据的时候会突然增加很多日志记录,并且如果数据表上有索引,数据表每增加一条记录就会在索引上增加一条数据从而降低插入的性能。解决方案: 1、大批量导入数据的时候设置数据库的恢复模式为“大容量日志恢复模式” 2、导入前禁用索引,导入完毕后重建索引。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值