sql安全性

Ⅰ 对于sql数据库的安全性、完整性，我需要采用什么方法来保证，

1.回滚，一组sql语句，当执行到一半时出错，就回滚到这组数据的开头，相当于没执行，然后你返回错误给用户错误的原因

2.锁表，当这句语句执行时，其他语句不能干扰,以免影响数据的正确性

具体每个语言都不一样，你搜搜吧

Ⅱ 如何提高SQL Server的安全性控制

SQLServer2000的安全配置在进行SQLServer2000数据库的安全配置之前，首先你必须对操作系统进行安全配置，保证你的操作系统处于安全状态。然后对你要使用的操作数据库软件（程序）进行必要的安全审核，比如对ASP、PHP等脚本，这是很多基于数据库的WEB应用常出现的安全隐患，对于脚本主要是一个过滤问题，需要过滤一些类似,‘;@/等字符，防止破坏者构造恶意的SQL语句。接着，安装SQLServer2000后请打上补丁sp1,sp2以及最新的sp3,sp4。在做完上面三步基础之后，我们再来讨论SQLServer的安全配置。1、使用安全的密码策略我们把密码策略摆在所有安全配置的第一步，请注意，很多数据库帐号的密码过于简单，这跟系统密码过于简单是一个道理。对于sa更应该注意，同时不要让sa帐号的密码写于应用程序或者脚本中。健壮的密码是安全的第一步！SQLServer2000安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非你确认必须使用空密码。这比以前的版本有所改进。同时养成定期修改密码的好习惯。数据库管理员应该定期查看是否有不符合密码要求的帐号。比如使用下面的SQL语句：UsemasterSelectname,、使用安全的帐号策略由于SQLServer不能更改sa用户名称，也不能删除这个超级用户，所以，我们必须对这个帐号进行最强的保护，当然，包括使用一个非常强壮的密码，最好不要在数据库应用中使用sa帐号，只有当没有其它方法登录到SQLServer实例（例如，当其它系统管理员不可用或忘记了密码）时才使用sa。建议数据库管理员新建立个拥有与sa一样权限的超级用户来管理数据库。安全的帐号策略还包括不要让管理员权限的帐号泛滥。SQLServer的认证模式有Windows身份认证和混合身份认证两种。如果数据库管理员不希望操作系统管理员来通过操作系统登陆来接触数据库的话，可以在帐号管理中把系统帐号“BUILTIN\Administrators”删除。不过这样做的结果是一旦sa帐号忘记密码的话，就没有法来恢复了。很多主机使用数据库应用只是用来做查询、修改等简单功能的，请根据实际需要分配帐号，并赋予仅仅能够满足应用要求和需要的权限。比如，只要查询功能的，那么就使用一个简单的public帐号能够select就可以了。3、加强数据库日志的记录审核数据库登录事件的“失败和成功”，在实例属性中选择“安全性”，将其中的审核级别选定为全部，这样在数据库系统和操作系统日志里面，就详细记录了所有帐号的登录事件。请定期查看SQLServer日志检查是否有可疑的登录事件发生，或者使用DOS命令。findstr/C:"登录"d:\MicrosoftSQLServer\MSSQL\LOG\*.*4、管理扩展存储过程对存储过程进行大手术，并且对帐号调用扩展存储过程的权限要慎重。其实在多数应用中根本用不到多少系统的存储过程，而SQLServer的这么多系统存储过程只是用来适应广大用户需求的，所以请删除不必要的存储过程，因为有些系统的存储过程能很容易地被人利用起来提升权限或进行破坏。如果你不需要扩展存储过程xp_cmdshell请把它去掉。使用这个SQL语句：usemastersp_dropextendedproc'xp_cmdshell'xp_cmdshell是进入操作系统的最佳捷径，是数据库留给操作系统的一个大后门。如果你需要这个存储过程，请用这个语句也可以恢复过来。sp_addextendedproc'xp_cmdshell','xpsql70.dll'如果你不需要请丢弃OLE自动存储过程（会造成管理器中的某些特征不能使用），这些过程包括如下：Sp_OACreateSp_OADestroySp_OAGetErrorInfoSp_OAGetPropertySp_OAMethodSp_OASetPropertySp_OAStop去掉不需要的注册表访问的存储过程，注册表存储过程甚至能够读出操作系统管理员的密码来，如下：Xp_regaddmultistringXp_regdeletekeyXp_regdeletevalueXp_regenumvaluesXp_regreadXp_regremovemultistringXp_regwrite还有一些其他的扩展存储过程，你也最好检查检查。在处理存储过程的时候，请确认一下，避免造成对数据库或应用程序的伤害。5、使用协议加密SQLServer2000使用的TabularDataStream协议来进行网络数据交换，如果不加密的话，所有的网络传输都是明文的，包括密码、数据库内容等等，这是一个很大的安全威胁。能被人在网络中截获到他们需要的东西，包括数据库帐号和密码。所以，在条件容许情况下，最好使用SSL来加密协议，当然，你需要一个证书来支持。6、不要让人随便探测到你的TCP/IP端口默认情况下，SQLServer使用1433端口监听，很多人都说SQLServer配置的时候要把这个端口改变，这样别人就不能很容易地知道使用的什么端口了。可惜，通过微软未公开的1434端口的UDP探测可以很容易知道SQLServer使用的什么TCP/IP端口了。不过微软还是考虑到了这个问题，毕竟公开而且开放的端口会引起不必要的麻烦。在实例属性中选择TCP/IP协议的属性。选择隐藏SQLServer实例。如果隐藏了SQLServer实例，则将禁止对试图枚举网络上现有的SQLServer实例的客户端所发出的广播作出响应。这样，别人就不能用1434来探测你的TCP/IP端口了（除非用PortScan）。7、修改TCP/IP使用的端口请在上一步配置的基础上，更改原默认的1433端口。在实例属性中选择网络配置中的TCP/IP协议的属性，将TCP/IP使用的默认端口变为其他端口.9、拒绝来自1434端口的探测由于1434端口探测没有限制，能够被别人探测到一些数据库信息，而且还可能遭到DOS攻击让数据库服务器的CPU负荷增大，所以对Windows2000操作系统来说，在IPSec过滤拒绝掉1434端口的UDP通讯，可以尽可能地隐藏你的SQLServer。10、对网络连接进行IP限制SQLServer2000数据库系统本身没有提供网络连接的安全解决法，但是Windows2000提供了这样的安全机制。使用操作系统自己的IPSec可以实现IP数据包的安全性。请对IP连接进行限制，只保证自己的IP能够访问，也拒绝其他IP进行的端口连接，把来自网络上的安全威胁进行有效的控制。

Ⅲ 如何保证SQLServer数据库安全

目前，针对SQL Server数据库的应用级入侵已经变得越来越肆无忌惮，像SQL注入、跨站点脚本攻击和未经授权的用户访问等。所有这些入侵都有可能绕过前台安全系统并对数据库系统攻击。对于数据库管理来说，保护数据不受内部和外部侵害是一项重要的工作。SQL Server 正日益广泛的使用于各部门内外，作为数据库系统管理员，需要深入的理解SQL Server的安全性控制策略，以实现管理安全性的目标。那么，如何确保SQL Server数据库的安全性呢，我们可以从以下两方面考虑。it培训机构
首先、采取业界已存在的且比较成熟的数据库审计解决方案来实现
实时记录用户对数据库系统的所有操作(如：插入、删除、更新、用户自定义操作等)，并还原SQL操作命令包括源IP地址、目的IP地址、访问时间、用户名、数据库操作类型、数据库表名、字段名等，如此，可实现对数据库安全事件准确全程跟踪定位。
实时检查数据库不安全配置、数据库潜在弱点、数据库用户弱口令、数据库软件补丁层次、数据库潜藏木马等。
进行全方位的多层(应用层、中间层、数据库层)的访问审计，通过多层业务审计，实现数据操作原始访问者的精确定位。
针对于数据库的操作行为进行实时检测，并预设置风险控制策略，结合对数据库活动的实时监控信息，进行特征检测，任何尝试性的攻击操作都将被检测到并进行阻断或告警;并支持通过邮件、短信、SYSLOG、SNMP、屏幕等方式告警。
其次、制定相关的数据库管理流程
不同的人员对数据库的操作职责不一样，所有人员对数据库的操作均需要事前审批，对一些非常重要的操作需要二级以上审批。申请操作时，需明确在什么人，什么时间，因为何事，对哪个数据库(或表)，进行什么样的操作，可能有什么样的风险及采取的补救措施等。
数据库数据的丢失以及数据库被非法用户的侵入使得数据库管理员身心疲惫不堪，数据库安全性问题对于数据库管理员来说简直就是噩梦。对于数据库数据的安全问题。本文对围绕数据库的安全性问题提出了一些安全性策略，希望对数据库管理员有所帮助。

Ⅳ SQL的安全性

如果对方知道SA密码，那是没办法的！
你可以修改SA密码！
不然SA的密码都知道了，这数据库的控制权就是最高了！

不过修改了SA密码，软件客户端应该要重新配置下，这个由于我没用过用友软件，所以不好意思，这里我就不清楚了！

Ⅳ SQL四个安全性等级

SQL的安全机制可以分为4个等级
客户机操作系统的安全性
SQL Server的登录安全性
数据库的使用安全性
数据库对象的使用安全性

Ⅵ 怎么实现本地SQL的安全性

SQL Server 2000的安全配置在进行SQL Server 2000数据库的安全配置之前，首先你必须对操作系统进行安全配置，保证你的操作系统处于安全状态。然后对你要使用的操作数据库软件（程序）进行必要的安全审核，比如对ASP、PHP等脚本，这是很多基于数据库的WEB应用常出现的安全隐患，对于脚本主要是一个过滤问题，需要过滤一些类似 , ‘ ; @ / 等字符，防止破坏者构造恶意的SQL语句。接着，安装SQL Server2000后请打上补丁sp1,sp2以及最新的sp3,sp4。
在做完上面三步基础之后，我们再来讨论SQL Server的安全配置。

1、使用安全的密码策略

我们把密码策略摆在所有安全配置的第一步，请注意，很多数据库帐号的密码过于简单，这跟系统密码过于简单是一个道理。对于sa更应该注意，同时不要让sa帐号的密码写于应用程序或者脚本中。健壮的密码是安全的第一步！SQL Server2000安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非你确认必须使用空密码。这比以前的版本有所改进。同时养成定期修改密码的好习惯。数据库管理员应该定期查看是否有不符合密码要求的帐号。

比如使用下面的SQL语句：
Use master
Select name,Password from syslogins where password is null

2、使用安全的帐号策略

由于SQL Server不能更改sa用户名称，也不能删除这个超级用户，所以，我们必须对这个帐号进行最强的保护，当然，包括使用一个非常强壮的密码，最好不要在数据库应用中使用sa帐号，只有当没有其它方法登录到 SQL Server 实例（例如，当其它系统管理员不可用或忘记了密码）时才使用 sa。建议数据库管理员新建立个拥有与sa一样权限的超级用户来管理数据库。安全的帐号策略还包括不要让管理员权限的帐号泛滥。

SQL Server的认证模式有Windows身份认证和混合身份认证两种。如果数据库管理员不希望操作系统管理员来通过操作系统登陆来接触数据库的话，可以在帐号管理中把系统帐号“BUILTIN\Administrators”删除。不过这样做的结果是一旦sa帐号忘记密码的话，就没有办法来恢复了。很多主机使用数据库应用只是用来做查询、修改等简单功能的，请根据实际需要分配帐号，并赋予仅仅能够满足应用要求和需要的权限。比如，只要查询功能的，那么就使用一个简单的public帐号能够select就可以了。

3、加强数据库日志的记录

审核数据库登录事件的“失败和成功”，在实例属性中选择“安全性”，将其中的审核级别选定为全部，这样在数据库系统和操作系统日志里面，就详细记录了所有帐号的登录事件。请定期查看SQL Server日志检查是否有可疑的登录事件发生，或者使用DOS命令。findstr /C:"登录" d:\Microsoft SQL Server\MSSQL\LOG\*.*

4、管理扩展存储过程

对存储过程进行大手术，并且对帐号调用扩展存储过程的权限要慎重。其实在多数应用中根本用不到多少系统的存储过程，而SQL Server的这么多系统存储过程只是用来适应广大用户需求的，所以请删除不必要的存储过程，因为有些系统的存储过程能很容易地被人利用起来提升权限或进行破坏。如果你不需要扩展存储过程xp_cmdshell请把它去掉。使用这个SQL语句：
use master
sp_dropextendedproc 'xp_cmdshell'
xp_cmdshell是进入操作系统的最佳捷径，是数据库留给操作系统的一个大后门。如果你需要这个存储过程，请用这个语句也可以恢复过来。
sp_addextendedproc 'xp_cmdshell', 'xpsql70.dll'
如果你不需要请丢弃OLE自动存储过程（会造成管理器中的某些特征不能使用），
这些过程包括如下：
Sp_OACreate Sp_OADestroy Sp_OAGetErrorInfo Sp_OAGetProperty
Sp_OAMethod Sp_OASetProperty Sp_OAStop
去掉不需要的注册表访问的存储过程，注册表存储过程甚至能够读出操作系统管理员的密码来，如下：
Xp_regaddmultistring Xp_regdeletekey Xp_regdeletevalue
Xp_regenumvalues Xp_regread Xp_regremovemultistring
Xp_regwrite
还有一些其他的扩展存储过程，你也最好检查检查。在处理存储过程的时候，请确认一下，避免造成对数据库或应用程序的伤害。

5、使用协议加密

SQL Server 2000使用的Tabular Data Stream协议来进行网络数据交换，如果不加密的话，所有的网络传输都是明文的，包括密码、数据库内容等等，这是一个很大的安全威胁。能被人在网络中截获到他们需要的东西，包括数据库帐号和密码。所以，在条件容许情况下，最好使用SSL来加密协议，当然，你需要一个证书来支持。

6、不要让人随便探测到你的TCP/IP端口

默认情况下，SQL Server使用1433端口监听，很多人都说SQL Server配置的时候要把这个端口改变，这样别人就不能很容易地知道使用的什么端口了。可惜，通过微软未公开的1434端口的UDP探测可以很容易知道SQL Server使用的什么TCP/IP端口了。不过微软还是考虑到了这个问题，毕竟公开而且开放的端口会引起不必要的麻烦。在实例属性中选择TCP/IP协议的属性。选择隐藏 SQL Server 实例。如果隐藏了 SQL Server 实例，则将禁止对试图枚举网络上现有的 SQL Server 实例的客户端所发出的广播作出响应。这样，别人就不能用1434来探测你的TCP/IP端口了（除非用Port Scan）。

7、修改TCP/IP使用的端口

请在上一步配置的基础上，更改原默认的1433端口。在实例属性中选择网络配置中的TCP/IP协议的属性，将TCP/IP使用的默认端口变为其他端口.

9、拒绝来自1434端口的探测

由于1434端口探测没有限制，能够被别人探测到一些数据库信息，而且还可能遭到DOS攻击让数据库服务器的CPU负荷增大，所以对Windows 2000操作系统来说，在IPSec过滤拒绝掉1434端口的UDP通讯，可以尽可能地隐藏你的SQL Server。

10、对网络连接进行IP限制

SQL Server 2000数据库系统本身没有提供网络连接的安全解决办法，但是Windows 2000提供了这样的安全机制。使用操作系统自己的IPSec可以实现IP数据包的安全性。请对IP连接进行限制，只保证自己的IP能够访问，也拒绝其他IP进行的端口连接，把来自网络上的安全威胁进行有效的控制。