荟聚奇文、博采众长、见贤思齐
当前位置:公文素材库 > 计划总结 > 工作总结 > SQL总结-最佳做法检查表

SQL总结-最佳做法检查表

网站:公文素材库 | 时间:2019-05-29 22:28:38 | 移动端:SQL总结-最佳做法检查表

SQL总结-最佳做法检查表

总结:最佳做法检查表

以下检查表总结了本白皮书中讨论的各种最佳做法。有关详细信息,请参阅上面的讨论。

管理员检查表

在安装之前设置环境物理安全防火墙确保服务器的物理安全。在服务器和Internet之间放置防火墙。总是在外围防火墙上阻止TCP端口1433和UDP端口1434。如果命名实例在其他端口上侦听,则还要阻止这些端口。在多层环境中,使用多个防火墙创建屏蔽子网。隔离服务,降低受到威胁的服务被利用来危害其他服务的风险。绝对不要在域控制器上安装SQLServer。以单独的Windows帐户身份运行单独的SQLServer服务。在多层环境中,在单独的计算机上运行Web逻辑和业务逻辑。创建Windows帐户,尽可能只让其具有运行SQLServer服务所需的最小特权。使用NTFS。对关键的数据文件使用RAID。服务隔离服务帐户文件系统安装最新版本和ServicePack服务帐户身份验证模式强密码总是安装最新的ServicePack和安全修补程序。使用尽可能具有最低特权的帐户运行SQLServer服务。使用企业管理器将服务与Windows帐户相关联。要求使用Windows身份验证与SQLServer连接。即使在使用Windows身份验证时,也总是为sa帐户指派强密码。对所有SQLServer帐户都总是使用强密码。安装之后的配置选项和设置删除或保护旧安装文件在安装之后删除或存档下列文件:sqlstp.log、sqlsp.log和setup.iss。对于默认安装,这些文件位于:\\ProgramFiles\\MicrosoftSQLServer\\MSSQL\\Install文件夹中;对于命名实例,这些文件位于:\\ProgramFiles\\MicrosoftSQLServer\\MSSQL$\\Install文件夹中。如果当前系统是从SQLServer7.0升级的,请删除下列文件:%Windir%文件夹中的setup.iss;WindowsTemp文件夹中的sqlsp.log。

为命名实例选择静态端口安装之后的配置选项和设置(续)设置登录审核级别启用安全审核即使在Windows身份验证模式下也要保护sa帐户的安全删除示例数据库

为SQLServer的命名实例分配静态端口。将登录审核级别设置为“失败”或“全部”。对Sysadmin操作、固定角色成员身份更改、所有与登录相关的活动以及密码更改启用安全审核。在选择适当的审核选项之后,应该编写审核脚本,将它包装在存储过程中,并将该存储过程标记为AutoStart。即使在配置为要求进行Windows身份验证的服务器上,也要为sa帐户指派强密码。从生产服务器中删除示例数据库。安全操作安全模型备份策略减少功能、减小受攻击范围减少管理员强密码跨数据库所有权链接Xp_cmdshell加密角色和组权限分布式查询学会使用SQLServer安全模型。定期备份所有数据并将副本存放在安全的非现场位置。测试灾难恢复系统。通过只运行环境所必需的服务和功能,减小系统受到攻击的范围。限制少数几个受信任用户拥有sysadmin固定服务器角色的成员身份。确保对于所有的SQLServer帐户使用复杂密码。如果系统不使用跨数据库所有权链接,请禁用它。在默认情况下,只有sysadmin角色的成员能够执行xp_cmdshell。不应更改此默认设置。不要将执行xp_cmdshell的权限授予sysadmin角色成员以外的用户。安装证书以启用SSL连接。证书应该使用服务器的完全限定的DNS名称。在SQLServer服务帐户下使用EFS加密数据库文件。如果应用程序要求加密数据,请考虑使用诸如Protegrity和ApplicationSecurityInc.之类的供应商的产品。将用户汇集到SQLServer角色或Windows组中以简化权限管理。绝对不要向public数据库角色授予权限。在支持分布式查询的环境中设置SQLServer时,使用链接服务器(而不要使用远程服务器)。仅将链接服务器的访问权限授予那些需要它的登录。对于除sysadmin固定服务器角色的成员以外的所有用户,禁止对除SQLOLEDB以外的所有提供程序进行特殊(adhoc)数据访问。只允许对受信任的提供程序进行特殊数据访问。

来宾帐户安全操作(续)服务帐户不要启用来宾帐户。如果需要更改与SQLServer服务相关联的帐户,请使用SQLServer企业管理器。如果更改多个服务,则必须使用企业管理器将所做的更改分别应用于每个服务。建议的定期管理过程Microsoft基准安全分析器(MBSA)将MBSA添加到每周维护计划中,并按照计划中的任何安全建议操作。定期扫描帐户,查看是否有使用空密码的帐户,并删除使用空密码的帐户或为它们指派强密码。删除不再使用的帐户。定期扫描固定服务器和数据库角色,确保只将成员身份授予受信任用户。验证已被标记为AutoStart的存储过程是否安全。确保数据库用户与服务器级登录之间的映射正确无误。定期运行带有report选项的sp_change_users_login,确保映射按预期方式工作。不允许直接更新目录。使用sp_dboption枚举和验证启用了跨数据库所有权链接的数据库。扫描登录枚举固定角色成员成份启动过程登录到用户的映射直接更新目录跨数据库所有权链接修补实例的最佳做法实例检测和枚举保留您所负责的SQLServer的所有版本和语言清单。在清单中包括MSDE实例。使用SQLScan和SQLCheck(可从Microsoft网站获取),扫描域中的SQLServer实例。订阅Microsoft安全公告。维护与生产系统的配置相匹配并且可用于测试新修补程序的测试系统。在将修补程序应用于生产系统之前,认真测试修补程序。考虑修补不需要太多测试的开发系统。公告修补应用程序开发人员检查表

除上面的所有项目外,开发人员应将下列内容视为最佳做法。

常规有效地使用所有权链接

在单个数据库中使用所有权链接来简化权限管理。

使用角色来简化权限管理和所有权打开加密功能(SSL或IPSEC)不将SQLServer错误传播回到用户防止受到SQL插入攻击尽可能避免使用跨数据库所有权链接。如果必须使用跨数据库所有权链接,请确保这两个数据库总是部署为单个管理单元。向角色指派权限,而不要直接向用户指派权限。如果希望在删除拥有对象的用户时不必更改应用程序,则可以让角色拥有对象,而不是让用户直接拥有对象。对服务器启用加密连接,并考虑只允许建立加密连接。如果允许使用SQLServer身份验证,则强烈建议您使用IPSec加密网络层或者使用SSL加密会话。您的应用程序不应该将SQLServer错误返回给最终用户,而是将它们记录到日志中或者将它们传输给系统管理员。通过先验证所有的用户输入,然后将其传输到服务器,防止受到SQL插入攻击。只允许具有最小特权的帐户将用户输入的内容发送到服务器,从而限制可能受损的范围。使用必需的最小特权运行SQLServer本身。多层选项同一个域/受信任域(完整的Windows身如果应用程序服务器和数据库服务器位于同一个域中或者位于受信份验证)任域中,则应使用Windows身份验证,并配置“完全提供”功能(所有客户端上下文都与SQLServer建立通道连接)。这样,可以审核访问SQLServer的所有用户,允许执行Windows安全策略,并且无需将凭据存储在中间层。在该方案中,客户端连接到应用程序服务器,应用程序服务器从而模拟客户端并连接到SQLServer。应用程序服务器上的每个用户都必须在数据库服务器上有一个有效的Windows登录,且必须启用委派功能。该方案中进行交互的所有系统(包括域控制器)都必须运行Windows201*或更高版本。用来运行应用程序的帐户必须能够委派其他帐户(即,必须针对此帐户打开ActiveDirectory用户帐户选项“帐户可委派其他帐户”)。客户端帐户必须能够被委派(确保取消选中ActiveDirectory用户帐户选项“敏感帐户,不能被委派”)。应用程序服务必须有一个有效的服务主体名称(SPN)。注意如果安全计划要求最小化用户对数据库服务器的访问权限或者企业策略禁止委派,建议不要在跨数据库或Internet级别的安装中使用“完全提供”功能。

多层选项(续)混合方案(部分Windows身份验证)不同的非信任域或没有域(不进行Windows身份验证)如果在面向Internet的层中,并非每个用户都有一个单独的Windows域帐户,则建议将身份验证分成几个阶段。在验证用户身份的外层,如果不加密整个会话,至少应该使用SSL加密凭据。应该使用Windows身份验证连接到数据库服务器,并在特权很小、只具有执行数据库服务器功能所必需的权限的单独安全上下文中转发事务信息。这样,可以将中间层有效地作为服务器和Internet之间的附加防御层。注意建议不要在中间层和SQLServer之间使用SQLServer身份验证,因为使用SQLServer身份验证需要存储凭据。如果必须在中间层和SQLServer之间使用SQLServer身份验证,那么应该创建几个帐户,并让它们分别具有与不同种类的用户对应的不同级别的特权。这要求您向中间层中添加逻辑,以便按照所需的特权级别分配连接。如果不能在各层之间使用Windows身份验证,则应要求对登录序列进行SSL加密。最好加密整个会话。还应使用DPAPI加密必须存储的凭据。应将加密凭据存储在用ACL保护的注册表项中。软件供应商检查表

除上面的所有项目外,下列安全开发做法也已被证明对于提高各种开发环境中代码的质量及安全性非常有用。

安全过程了解各种安全问题确保开发小组的成员了解主要的安全问题:当前存在的威胁、安全趋势、更改安全环境以及受到攻击的情形。要求对所有开发人员和测试人员进行相关的安全培训。增强对跨站点脚本、缓冲区溢出、SQL插入和危险的API等问题的认识。确定对产品构成威胁的各种具体类型,例如拒绝服务、特权升级、欺骗、篡改数据、信息泄漏和丢弃。针对每个组件逐一分析产品受到的安全威胁。基于产品构建安全威胁检查表。在产品开发周期的每个阶段(从设计到测试)增加安全审核步骤。

安全过程(续)安装MSDE如果将MSDE与应用程序一起分发,则应遵守下列附加准则:使用“Windows安全模式”作为默认设置安装MSDE。绝对不要使用空的sa密码。在向客户分发MSDE时,应使用Microsoft提供的安装程序,而不要使用合并模块。在安装将只作为本地数据存储运行的MSDE实例时,应该禁用服务器网络库。如果产品中包括MSDE,则应让您的客户知道这一点。他们将来可能需要安装或接受MSDE特定的软件更新程序。MSDE在默认情况下安装SQLServer代理,但是将服务启动类型保持为“手动”。如果应用程序不使用SQLServer代理,则应将此设置更改为“禁用”。在产品文档中包括安全性最佳做法信息。

扩展阅读:SQL的一些重要操作方法总结

SQL的一些重要操作方法总结

一、对表中数据进行更新的情况说明

㈠、用一个表中的数据更新另一个表★实现方法:

先打开原始数据表;然后用循环的方式查找原始数据表,把相应的数据用UPDATE命令来更新目标表。

USEDOWHILE!EOF()

UPDATESETWHERESKIPENDDO

循环也可以用SCAN语句来实现。USESCAN

UPDATESETWHEREENDSCAN

㈡、从一个表中检索出一些数据再用来更新另一个表所谓“检索”是指从一个表中统计或计算出一些数据。★实现方法:

先用SELECT语句进行检索,把检索到的结果暂存到临时表中;然后用循环的方式查找临时表,用UPDATE语句来更新目标表。

SELECTFROMINTOCURSORDOWHILE!EOF()

UPDATESETWHERESKIPENDDO

当然也可以和前一种情况一下,循环用SCAN语句。㈢、在同一个表中更新

直接使用UPDATE语句即可(可一次更新多条记录),不需要用循环。

二、在表中插入记录的情况说明

㈠、插入记录内容不是来自别的数据表直接使用INSERTINTO命令即可。㈡、需要从另一个数据表(源表)提取数据

这时不能直接用INSERTINTO命令,需要分两步进行。★实现方法:

用SELECT语句从源表中提取数据,并存入到一个数组中,然后使用INSERTINTO命令的格式二插入到目标表中。

SELECTFROMINTOARRAYINSERTINTOFROMARRAY注:如果用在SELECT语句后直接加上子句INTOTABLE的方式存入到目标表,会覆盖目标表上的原有数据。三、SQL语句运行时出现错误解决方法1、分步调试,先调试基本部分是否正确。

2、检查语句中出现的符号是否是半角(英文)符号。关掉中文输入法重新键入相关的符号。

3、是否遗漏了相关的子句,单词是否拼错。检查格式是否符合SQL语句的规定。

4、多表查询时检查表的顺序(要确立主表,辅表,位置)5、检查是否要分组。

6、如果分组了,有没有分组条件,是否把分组条件放到了WHERE子句。

7、检查WHERE条件中的条件是否写错,出现的字段名是否出现在表中。

8、检查“:”号,是否多了或者少了。

9、检查引号,只有在表示字符常量是才加引号,其它的一律不能加;另外引号不能是中文引号。

友情提示:本文中关于《SQL总结-最佳做法检查表》给出的范例仅供您参考拓展思维使用,SQL总结-最佳做法检查表:该篇文章建议您自主创作。

来源:网络整理 免责声明:本文仅限学习分享,如产生版权问题,请联系我们及时删除。


SQL总结-最佳做法检查表》由互联网用户整理提供,转载分享请保留原作者信息,谢谢!
链接地址:http://www.bsmz.net/gongwen/747386.html
相关文章