SQL Server 2005中，怎么防范数据库危险操作
SQL Server 2005中，如何防范数据库危险操作?
请教各路大侠，
1、恶意或者无意地，删除表或者数据
例如说 drop table / truncate table / delete from ..（大批量）
2、偷数据。某些别有用心的人，可能会大批量地导出数据库中的数据。
有哪些措施可以防范上面提到的危险操作呢？
例如说，我可以在数据库里映入哪些机制、权限之类的操作？
------解决方案--------------------
主要是在客户端程序中,特别是WEB程序中,防止注入.
另外,如果系统是B/S结构,则断开数据库服务器与WEB服务器以外的连接,防止不法连接.
如果系统是C/S结构,则要严格控制连接数据库用户的权限,可以用架构,角色等或直接授权指定用户进行指定的操作.
------解决方案--------------------
曾经有段时间维护过CRM数据库。下面的一些方法可供参考
1.CRM用的SQL帐号 尽量只给少部分的开发人员，在正式完成开发工作后，修改SQL用户密码
2.SQL帐号的权限角色要严格控制，只有极少数人（通常2人）具有DROP TRUNACATE权限
3.做好备份，尤其是日志备份很重要，真被DROP掉的时候能补回来
4.数据库备份文件严格管理，别被人拷回家了，如果是SQL2008及其以上版本，启用数据库证书加密
5.启用SQL跟踪。定时审计那些查询较多的语句（利用程序筛选判断）
6.限定防火墙策略数据库1433端口只能指定服务器开放
7.数据库服务器的远程桌面，文件传输，ipc$等 服务全面收缩或禁止
8.多用视图或存储过程提供给开发者。
9.启用全局DDL触发器。记录或者回滚不符合审计要求的DROP TRUNCATE CREATE REVOKE
------解决方案--------------------
http://topic.csdn.net/u/20091013/15/9f058df7-4d29-47bf-a338-b63fcab2abc0.html
看里面有关SQL注入的部分
------解决方案--------------------
1.规范各级人员的数据库帐号的权限.
2.SQL2008起有个审计功能,可以了解一下.
3.建立DDL触发器,记录危险操作的日志.
4.重要数据可加密处理,即使能访问也未必看得到.
不过话说回来,还是要信任大部分人的.
请教各路大侠，
1、恶意或者无意地，删除表或者数据
例如说 drop table / truncate table / delete from ..（大批量）
2、偷数据。某些别有用心的人，可能会大批量地导出数据库中的数据。
有哪些措施可以防范上面提到的危险操作呢？
例如说，我可以在数据库里映入哪些机制、权限之类的操作？
------解决方案--------------------
主要是在客户端程序中,特别是WEB程序中,防止注入.
另外,如果系统是B/S结构,则断开数据库服务器与WEB服务器以外的连接,防止不法连接.
如果系统是C/S结构,则要严格控制连接数据库用户的权限,可以用架构,角色等或直接授权指定用户进行指定的操作.
------解决方案--------------------
曾经有段时间维护过CRM数据库。下面的一些方法可供参考
1.CRM用的SQL帐号 尽量只给少部分的开发人员，在正式完成开发工作后，修改SQL用户密码
2.SQL帐号的权限角色要严格控制，只有极少数人（通常2人）具有DROP TRUNACATE权限
3.做好备份，尤其是日志备份很重要，真被DROP掉的时候能补回来
4.数据库备份文件严格管理，别被人拷回家了，如果是SQL2008及其以上版本，启用数据库证书加密
5.启用SQL跟踪。定时审计那些查询较多的语句（利用程序筛选判断）
6.限定防火墙策略数据库1433端口只能指定服务器开放
7.数据库服务器的远程桌面，文件传输，ipc$等 服务全面收缩或禁止
8.多用视图或存储过程提供给开发者。
9.启用全局DDL触发器。记录或者回滚不符合审计要求的DROP TRUNCATE CREATE REVOKE
------解决方案--------------------
http://topic.csdn.net/u/20091013/15/9f058df7-4d29-47bf-a338-b63fcab2abc0.html
看里面有关SQL注入的部分
------解决方案--------------------
1.规范各级人员的数据库帐号的权限.
2.SQL2008起有个审计功能,可以了解一下.
3.建立DDL触发器,记录危险操作的日志.
4.重要数据可加密处理,即使能访问也未必看得到.
不过话说回来,还是要信任大部分人的.