sql数据安全

1. 如何保证SQLServer数据库安全

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

2. 保护SQL服务器的安全-安全安装

由于很多原因 需要作出安全决定的人常常没有明白数据的真正价值 所以经常无法对数据进行足够的保护 让需要你数据的人能够在需要的时候访问到它 并确保其有效性 可能是数据库管理员最重要的职责 但是 保持数据能够被访问并不意味着要让它对所有的人都开放 因此 你需要仔细保护数据的安全 然后只对需要它的人开放 闹脊 安全措施 普通的维护和数据库的更改应该让位于安全措施 这一过程包括如下步骤 ● 为缺省的系统管理员（SA）帐号分配一个复杂的密码 然后创建你唯一命名的帐号来处理管理工作 并给该帐号分配sysadmin角色 要确保新的帐号也具有复杂的密码 然后你就可以从sysadmin角色里把SA帐号删掉 ● 为每个用户设置单独的密码 但是更好的方法是使用Windows集成的安全（机制） 并让Windows来强制执行严格的密码规则 ● 要确定哪些用户需要查看什么数据 然后分配适当的许可 不要仅仅为图省事而给予用户过多的权限 例如 你的数据输入操作员就的确不需要查看其他人的工资 ● 确定哪些用户需要更改什么数据 然后再分配适当的许可 帐号管理人员应该可以看到所有的客户信息 但是你可能希望限制谁才有权更改这些信息 具体的说 掌握特定帐号的帐号管理人员可能是唯一一个被赋予权限更改客户数据的人 通过本系列的文章 你会了解到更多关于这些措施的内容 但是你应该从一开始就考虑安全的问题 否则 你数据库的任何用户都可能窃取或者删除你最敏感的数据 可能是什么出错？ 众所周知 SQL服务器在刚安装好的的时候并不安全 你必须花一些心思和精力来充分和成功地保证你服务器的安全 甚至在开始安装服务器之前 你就需要考虑两个非常重要的问题 ● 保护管理员帐号和密码的安全 ● 保护你的系统不受Slammer蠕液兆渗虫病毒的侵害 ● 保护刚刚安装好的服务器利用SA帐号 SQL服务器 的确具有缺省的安全（措施） 在安装过程中 SQL服务器会自动地创建一个管理员用户 并为其指定SA这个用户名和一个空白的密码 有些管理员会把这个SA的密码留成空白 或者设置为大家都知道的一个常见密码 这就使得其整个系统能够被轻易攻破 如果你犯了这个错误 那么任何人都可以登录进你的数据库 并做他们想做的事情 具有管理员许可的任何人都可以做他们想做的任何事——不仅仅是数据库 还有整台计算机 这肯定不是一件好事 你希望限制每个用户 只让他们访问他们需要的东西——不多也不少 在日常的管理工作中不要使用SA帐号 用一个真正安全的密码来收藏好这个帐号 然后 为管理工作专门创建另外一个帐猜卜号（具体是SQL服务器帐号还是Windows帐号 这要根据你的验证模式） 你需要避免很容易就会被猜出来的帐号名 或者控制整台服务器的帐号的密码 因为如果有人使用这个帐号成功地登录进来 那么游戏就此结束 一次令人警醒的事件——Slammer蠕虫 年 月 一个感染性极强的恶意代码 Slammer蠕虫将攻击目标瞄准了SQL服务器的安装过程 通过利用SQL服务器代码里的漏洞 它能够在安装SQL服务器的时候 绑架 计算机 并将自己的多个副本安 *** 其他被攻破的计算机里 利用某些帐号 这个蠕虫在被释放出来的 分钟之内就渗透进了Internet 微软花了大量的精力来发布补丁 但是Slammer的影响现在还时有发生 有些媒体甚至还宣称 它破坏了SQL服务器工作组的工作 结果导致SQL服务器下一版本的beta版发布被推迟 为什么在这一事件爆发数月之后你还需要关注这个问题？因为现在在网上每天还有受到感染的机器在向外发送Slammer的副本 如果把没有打补丁的SQL服务器连接到Internet上 你就可能成为下一个受害者 这次事件告诉我们 在插上连接到Internet的电缆之前 你需要保护好自己服务器的安全 并安装最新的服务包和补丁 服务包的重要性 服务包可以免费下载 所以你不会因为买不起而不去安装 Slammer蠕虫不会破坏数据 但是它会导致你服务的严重崩溃 其后果和数据被破坏一样严重 保护措施非常简单 下载服务包 或者服务包 a 这个蠕虫如何工作的技术细节在这里并不重要 重要的是 Slammer蠕虫所攻击的漏洞 已经在 个月之前由微软发布补丁进行了修补 但是还造成这么大的损失 受到这个蠕虫攻击的商业机构两次受害 一次是由没有保护好系统的管理员造成的 另一次是由蠕虫造成的 你也应该要记住 没有什么能够保证SQL服务器服务包 能够修补所有的漏洞 你应该定期访问微软的安全公告牌页面 以确保你能够得知未来服务包和补丁的发布 选择验证模式 在安装SQL服务器过程中你要首先作出的一个决定是选择使用哪种安全模式 安全模式有两种 ● Windows验证模式（也叫做集成模式） ● 混合模式 在Windows验证模式下 用户通过已有的Windows用户帐号连接到SQL服务器上 当用户使用合法的用户名和密码连接到服务器的时候 SQL服务器会验证用户的Windows登录信息 这样 用户只需要一次就能够同时登录进Windows和SQL服务器 帐号信息由Windows严格保存 混合模式是Windows验证和SQL服务器验证的结合 在混合验证模式下 有的用户可以只需要一次注册 就可以继续使用Windows的帐号来访问SQL服务器 而其他的人可以使用SQL服务器的用户帐号 这一帐号是同Windows帐号完全分离的 每个SQL服务器的帐号都会保存自己的用户名和密码 即使这两个登录的值完全相同 用户也必须登录两次——一次用于进入Windows 另一次用于进入SQL服务器 Windows验证模式要优于混合模式 其原因如下 ● 它提供了比SQL服务器验证更多的特性 ● 大多数管理员都认为Windows验证是两种模式中更容易实现和使用的 ● 在Windows验证模式下 没有必要在连接字符串里保存密码——又少了一样要保护的东西 ● Windows验证意味着你只需要在一个地方管理密码 而不是两个地方 不幸的是 不是所有的人都可以使用Windows验证 SQL服务器 （或者更早的版本）要求使用混合模式 Windows验证只能在SQL服务器 上使用 在某些情况下（例如 当你正在使用域以外的Web服务器 从域以内的SQL服务器上获取数据的时候） Windows验证无法工作 因为信任书无法通过域的边界 在这些情况下 你必须使用混合模式和SQL服务器登录 其他关于安装的提示 在安装SQL服务器的时候 有一些东西需要你考虑 ● 要将TCP/IP用作SQL服务器的网络库 这是微软所推荐的库 所顺理成章地成为经过测试的最佳库 如果服务器会被放在公众的Internet上 那么就要使用一个非标准的端口 这就可以让坏小子们更难找到它 ● 要使用一个低权限的帐号来运行SQL服务器 而不是用管理员帐号 这会在安全系统被攻破的时候限制其造成的损失 ● 不要允许未受安全保护的来宾帐号访问任何包含有保护数据的数据库 ● 将服务器从物理上锁在服务器房间或者柜子里 以保证其安全 要记住 大多数入侵都来自内部 结论 让安全从一开始就成为你工作重点的头一个 无论是保护你的数据不因为能力不足而遭受损失 还是要防止有意破坏而受到的损失 你都要花时间学习安全模式 然后小心地应用它 只需要一次安全恶梦 你就会成为安全的相信者 所以正视安全 睡个好觉 lishixin/Article/program/SQLServer/201311/22162

3. SQL数据库安全设置

首先就是打好SQL的补丁(Service
Pack),这样基本上就没问题了.
再有就是网站或者程序调用的时候,最好是不要用SA用户,而用一个非管理员级别的用户来读写数据库.
最后就是程序的防错处理了,以及在调用数据库的时候,尽量注意防溢出处理.
基本上就是这些.