数据库安全策略

㈠ 数据库安全的安全策略

数据库的安全配置在进行安全配置之前，首先必须对操作系统进行安全配置，保证操作系统处于安全状态。然后对要使用的操作数据库软件（程序）进行必要的安全审核，比如对ASP、PHP等脚本，这是很多基于数据库的Web应用常出现的安全隐患，对于脚本主要是一个过滤问题，需要过滤一些类似“,; @ /”等字符，防止破坏者构造恶意的sql语句。接着，安装SQL Server2000后请打上最新SQL补丁SP4 。
SQL Server的安全配置
1．使用安全的密码策略
我们把密码策略摆在所有安全配置的第一步，请注意，很多数据库账号的密码过于简单，这跟系统密码过于简单是一个道理。对于sa更应该注意，同时不要让sa账号的密码写于应用程序或者脚本中。健壮的密码是安全的第一步，建议密码含有多种数字字母组合并9位以上。SQL Server2000安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非您确认必须使用空密码，这比以前的版本有所改进。同时养成定期修改密码的好习惯，数据库管理员应该定期查看是否有不符合密码要求的账号。
2．使用安全的账号策略
由于SQL Server不能更改sa用户名称，也不能删除这个超级用户，所以，我们必须对这个账号进行最强的保护，当然，包括使用一个非常强壮的密码，最好不要在数据库应用中使用sa账号，只有当没有其他方法登录到 SQL Server 实例（例如，当其他系统管理员不可用或忘记了密码）时才使用 sa。建议数据库管理员新建立个拥有与sa一样权限的超级用户来管理数据库。安全的账号策略还包括不要让管理员权限的账号泛滥。
SQL Server的认证模式有Windows身份认证和混合身份认证两种。如果数据库管理员不希望操作系统管理员来通过操作系统登录来接触数据库的话，可以在账号管理中把系统账号“BUILTINAdministrators”删除。不过这样做的结果是一旦sa账号忘记密码的话，就没有办法来恢复了。很多主机使用数据库应用只是用来做查询、修改等简单功能的，请根据实际需要分配账号，并赋予仅仅能够满足应用要求和需要的权限。比如，只要查询功能的，那么就使用一个简单的public账号能够select就可以了。
3．加强数据库日志的记录
审核数据库登录事件的“失败和成功”，在实例属性中选择“安全性”，将其中的审核级别选定为全部，这样在数据库系统和操作系统日志里面，就详细记录了所有账号的登录事件。请定期查看SQL Server日志检查是否有可疑的登录事件发生，或者使用DOS命令。
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使用的默认端口变为其他端口。
8．拒绝来自1434端口的探测
由于1434端口探测没有限制，能够被别人探测到一些数据库信息，而且还可能遭到DoS攻击让数据库服务器的CPU负荷增大，所以对Windows 2000操作系统来说，在IPSec过滤拒绝掉1434端口的UDP通信，可以尽可能地隐藏您的SQL Server。
9．对网络连接进行IP限制
SQL Server 2000数据库系统本身没有提供网络连接的安全解决办法，但是Windows 2000提供了这样的安全机制。使用操作系统自己的IPSec可以实现IP数据包的安全性。请对IP连接进行限制，只保证自己的IP能够访问，也拒绝其他IP进行的端口连接，对来自网络上的安全威胁进行有效的控制。
上面主要介绍的一些SQL Server的安全配置，经过以上的配置，可以让SQL Server本身具备足够的安全防范能力。当然，更主要的还是要加强内部的安全控制和管理员的安全培训，而且安全性问题是一个长期的解决过程，还需要以后进行更多的安全维护。

㈡ 我的本地安全策略显示Windows 无法打开本地策略数据库 拒绝访问数据库

Windows
无法打开本地策略数据库的解决方法
打开帐户策略和本地策略时报如下错误：
Windows
无法打开本地策略数据库。打开数据库时出现了一个未知错误。IIS报内部服务器错。怎么解决？
操作系统：Win2000+SP4
不是域服务器。
有时本地策略数据库(文件名:%SystemRoot%\Security\database\Secedit.sdb)会坏掉，使策略不发挥作用。下面提供一个恢复本地安全组策略数据库的办法，这也是一个恢复本地安全策略的办法。
注意:这个办法会使本地安全策略回到初始状态，也就是你原来在本地安全策略中进行的设置会全部丢失。
1.打开
%SystemRoot%\Security文件夹，创建一个“OldSecurity”子目录，将%SystemRoot%\Security
下所有的.log文件移到这个新建的子文件夹中；
2.在%SystemRoot%\Security\database\下找到“ecedit.sdb”全数据库并将其改名，改为“ecedit.old”
；
3.启动“安全配置和分析”MMC管理单元：“开始”->“运行”->“MMC”，启动管理控制台，“添加/删除管理单元”,将“安全配置和分析”管理单元添加上；
4.右击“安全配置和分析”->“打开数据库”,浏览“C:\WINNT\security\Database”文件夹,输入文件名“secedit.sdb”,单击“打开”；
5.当系统提示输入一个模板时，选择“Setup
Security.inf”,单击“打开”；
6.如果系统提示“拒绝访问数据库”,不管它；
7.你会发现在“C:\WINNT\security\Database”子文件夹中重新生成了新的安全数据库。在“C:\WINNT\security”子文件夹下重新生成了log文件。
安全数据库重建成功。

㈢ 企业里的数据安全怎么保证

找专业的公司做专业的系统，这样才能保证数据的相对安全，信息安全越来越重要，不能掉以轻心。

㈣ sqlserver有哪些安全策略

Microsoft建立了一种既灵活又强大的安全管理机制，它能够对用户访问SQL Server服务器系统和数据库的安全进行全面地管理。按照本文介绍的步骤，你可以为SQL Server 7.0(或2000)构造出一个灵活的、可管理的安全策略，而且它的安全性经得起考验。

一、验证方法选择
本文对验证(authentication)和授权(authorization)这两个概念作不同的解释。验证是指检验用户的身份标识;授权是指 允许用户做些什么。在本文的讨论中，验证过程在用户登录SQL Server的时候出现，授权过程在用户试图访问数据或执行命令的时候出现。
构造安全策略的第一个步骤是确定SQL Server用哪种方式验证用户。SQL Server的验证是把一组帐户、密码与Master数据库Sysxlogins表中的一个清单进行匹配。Windows NT/2000的验证是请求域控制器检查用户身份的合法性。一般地，如果服务器可以访问域控制器，我们应该使用Windows NT/2000验证。域控制器可以是Win2K服务器，也可以是NT服务器。无论在哪种情况下，SQL Server都接收到一个访问标记(Access Token)。访问标记是在验证过程中构造出来的一个特殊列表，其中包含了用户的SID(安全标识号)以及一系列用户所在组的SID。正如本文后面所介绍 的，SQL Server以这些SID为基础授予访问权限。注意，操作系统如何构造访问标记并不重要，SQL Server只使用访问标记中的SID。也就是说，不论你使用SQL Server 2000、SQL Server 7.0、Win2K还是NT进行验证都无关紧要，结果都一样。
如果使用SQL Server验证的登录，它最大的好处是很容易通过Enterprise Manager实现，最大的缺点在于SQL Server验证的登录只对特定的服务器有效，也就是说，在一个多服务器的环境中管理比较困难。使用SQL Server进行验证的第二个重要的缺点是，对于每一个数据库，我们必须分别地为它管理权限。如果某个用户对两个数据库有相同的权限要求，我们必须手工设 置两个数据库的权限，或者编写脚本设置权限。如果用户数量较少，比如25个以下，而且这些用户的权限变化不是很频繁，SQL Server验证的登录或许适用。但是，在几乎所有的其他情况下(有一些例外情况，例如直接管理安全问题的应用)，这种登录方式的管理负担将超过它的优 点。
二、Web环境中的验证
即使最好的安全策略也常常在一种情形前屈服，这种情形就是在Web应用中使用SQL Server的数据。在这种情形下，进行验证的典型方法是把一组SQL Server登录名称和密码嵌入到Web服务器上运行的程序，比如ASP页面或者CGI脚本;然后，由Web服务器负责验证用户，应用程序则使用它自己的 登录帐户(或者是系统管理员sa帐户，或者为了方便起见，使用Sysadmin服务器角色中的登录帐户)为用户访问数据。
这种安排有几个缺点，其中最重要的包括：它不具备对用户在服务器上的活动进行审核的能力，完全依赖于Web应用程序实现用户验证，当SQL Server需要限定用户权限时不同的用户之间不易区别。如果你使用的是IIS 5.0或者IIS 4.0，你可以用四种方法验证用户。第一种方法是为每一个网站和每一个虚拟目录创建一个匿名用户的NT帐户。此后，所有应用程序登录SQL Server时都使用该安全环境。我们可以通过授予NT匿名帐户合适的权限，改进审核和验证功能。
第二种方法是让所有网站使用Basic验证。此时，只有当用户在对话框中输入了合法的帐户和密码，IIS才会允许他们访问页面。IIS依靠一个NT 安全数据库实现登录身份验证，NT安全数据库既可以在本地服务器上，也可以在域控制器上。当用户运行一个访问SQL Server数据库的程序或者脚本时，IIS把用户为了浏览页面而提供的身份信息发送给服务器。如果你使用这种方法，应该记住：在通常情况下，浏览器与服 务器之间的密码传送一般是不加密的，对于那些使用Basic验证而安全又很重要的网站，你必须实现SSL(Secure Sockets Layer，安全套接字层)。
在客户端只使用IE 5.0、IE 4.0、IE 3.0浏览器的情况下，你可以使用第三种验证方法。你可以在Web网站上和虚拟目录上都启用NT验证。IE会把用户登录计算机的身份信息发送给IIS，当 该用户试图登录SQL Server时IIS就使用这些登录信息。使用这种简化的方法时，我们可以在一个远程网站的域上对用户身份进行验证(该远程网站登录到一个与运行着Web 服务器的域有着信任关系的域)。
最后，如果用户都有个人数字证书，你可以把那些证书映射到本地域的NT帐户上。个人数字证书与服务器数字证书以同样的技术为基础，它证明用户身份标 识的合法性，所以可以取代NT的Challenge/Response(质询/回应)验证算法。Netscape和IE都自动在每一个页面请求中把证书信 息发送给IIS。IIS提供了一个让管理员把证书映射到NT帐户的工具。因此，我们可以用数字证书取代通常的提供帐户名字和密码的登录过程。
由此可见，通过NT帐户验证用户时我们可以使用多种实现方法。即使当用户通过IIS跨越Internet连接SQL Server时，选择仍旧存在。因此，你应该把NT验证作为首选的用户身份验证办法。
三、设置全局组
构造安全策略的下一个步骤是确定用户应该属于什么组。通常，每一个组织或应用程序的用户都可以按照他们对数据的特定访问要求分成许多类别。例如，会 计应用软件的用户一般包括：数据输入操作员，数据输入管理员，报表编写员，会计师，审计员，财务经理等。每一组用户都有不同的数据库访问要求。

㈤ 计算机系统中的数据主要面临哪些攻击

计算机系统中和传输中的数据分别主要面临的攻击：
系统：
Passive Attack--release of contents
Passive Attack—traffic analysis
传输：
Active Attack—Masquerade
Active Attack—Replay
Active Attack—Modification of messages
Active Attack—Denial of service

㈥ 什么是安全审计，关于数据库的

安华金和数据库审计产品就是你说的关于数据库的审计产品，基于数据库通讯协议分析和SQL解析技术的产品，具备全面、高效的数据库监控告警和审计追溯能力。在行为分析基础上，数据库审计通过强大的风险行为描述语言，实现对数据库风险和攻击行为的有效描述，对于违反安全策略的访问行为进行及时告警，保证数据库操作满足合规性要求，通过系统自带数据库风险特征库，迅速实现数据库风险检测和告警，更多详情可网络参考一下。

㈦ IPsec安全策略主要由哪两个交互的数据库

SAD(安全关联数据库)和SPD(安全策略数据库)。
它并不是一个单独的协议，而是一系列为IP网络提供安全性的协议和服务的集合。IPSec主要包括安全协议AH和ESP，密钥管理交换协议IKE以及用于网络认证及加密的一些算法等。

㈧ 云数据库真的那么安全吗将数据传上云后，数据安全风险该如何避免

风险无处不在，关键在于如何进行有效防范。

应对方法：

检测发现

可以利用云应用检测工具发现当前所使用软件(包括谁使用及使用频率)，同时确定业务数据是否涉入。采用云访问安全代理(简称CASB)解决方案要求供应商提供影子IT评估意见以了解当前企业内部的IT问题严重程度。

风险评估

对特定应用进行制裁、监控及制止，才能构建良好的云应用环境。利用评级系统确定云应用风险特点。保证此评级与陈述体系能够对影子IT进行分析并便捷地上传、匿名化、压缩并缓存日志数据，然后轻松交付自动化风险评估陈述。

用户引导

确保全部员工了解常见网络违法战术。降低未知威胁带来的影响。未知威胁永久存在，但杰出的安全意识训练有助于缓解其后果。定期发布提醒并组织季度训练，这样能够轻松并以较低成本削减恶意软件风险。

策略执行

安全策略执行必须拥有高粒度与实时性。这些要求在云应用领域可能较难完成。根据用户做法、所用工具及事务规则设定策略控制方案，从而立足于用户群组、设备、方位、浏览器以及代理为背景设计相关内容。考虑使用安全网关(内部、公有云或混合云)，同时配合具备数据丢失预防(简称DLP)功能的CASB解决方案。

隐私与治理

云环境中的数据需要使用特殊的以数据为中心的安全策略。加密机制在各类环境下皆有其必要性，但加密令牌机制在云安全领域的作用往往尤为突出。保证加密机制不会影响到应用中的查找、排序、报告以及邮件发送等功能。如果加密机制令上述功能的正常使用受到不良影响，则用户往往会想办法回避加密。

加密流量管理

对于需要过超过五成流量进行加密的行业(例如金融服务及医疗卫生)，基于策略的流量解密可能需要匹配专门的SSL可视化子系统及/或专用网络架构。

事件响应

需要立足于低层级进行云部署以建立直观的人机界面，从而实现事件响应(例如多种格式查找、可视化、过滤及集成第三方SIEM系统)。