1、共 9 页 第 1 页 数据库安全 “ 为什么要 确保 数据库服务 安全呢 ?任何人都不能 访问 -这是一个非军事区的保护防火墙 ” , 当我们被建议使用 一个 带有 安全检查 机制的装置时, 这是 通 常的反应。事实上,在 防护 一个组织的信息 方面, 数据库的安全是至高无上的,因为它可能会间接接触 比我们意识到的 更广泛的 用户 。 这是两篇研究数据库安全文章 中的第一篇 。在这篇文章中我们将讨论一般数据库安全概念和 和比较普遍的 问题。在下篇文章,我们将 把焦点放在 特定的Microsoft SQL 和 Oracle 的安全关 注上 。 近来 数据库安全已成为一个热门话题。随着越来越多的
2、人关注计算 机安全,我们发现,防火墙和网络服务器比 以前 都更加 安全化了 (虽然这并不等于说现 在不再有许多 不安全的网络存在)。因此,重点是 加大对 技术 的 考虑 力度 , 譬 如 以更细腻的审查态度对待 数据库 。 一般 安全意识 在 我们 讨论有关数据库安全问题 之前 ,确保底层 操作 系统和支撑技术 的安全是审慎而且必要的 。如果一个 vanilla 操作 系统无法 为数据库 提供一个稳妥可靠的 安全基础 , 花费太多努力去确保数据库安全是不值得的。当安装操作系统时,有 许多好的文献资料可以参考。 经常遇到的一个 普遍 问题, 就是 作为网络服务器托管 Internet(or In
3、tranet)的 同一服务器 上数据库的 应用。虽然这可能节省的购买一个单独的服务器费用,但这 严重影响 了安全问题。 如果这是确定的, 当 数据库 开放 地连接到互联网 这种情况被证实了 。最近的一个例子,我记得是一个 Apache 网络服务器系统服务组织在互联网上提供 的 ,与 Oracle 数据库在互联网上提供有关 端 口 1521。在调查这个问题 时 进一步被发现, 访问该 Oracle 服务器是没有服务器加以制止 之类的 保 护措施的 (包括缺乏密码)。从互联网 发展前景 看, 这个数据库是不被推崇的, 但默认设置 的使用以及粗糙的安全 措施,使服务器 更加脆弱 。 上面 提到的问题
4、并不是严格地数据库问题 ,还可以被归类为 构建机制 和防火墙保护问题,但最终它 确 是数据库, 这 是毫不妥协的。安全方面的考虑 从 面 向 网络 的各部分来看 而被迫作出的。你不能 依靠任何他人或任何别的事以保护你的数据库安全。 由于 SQL 和 Oracle 开发的漏洞给攻击工具一个得以使用的空间。 我 在 最近 为 客户 做的 一项安全评估 中 偶然 发现 一个数据库安全方面的 有趣的是 。我们 正在进行 对使用一个数据库后端( SQL)以存放客户端的细节 的 企业内部应用软件 的 测试。安全审查 过程 进展顺利, 访问控制 基于 Windows 认证。只有 通过 认证的 Windows
5、 用户能够看到属于他们 的 数据。 这个 应用 软件 本身 好像对 输入要求 进行处理 ,拒绝直接 进入 资料库 的所有尝试 。 之后 我们在 工作的 办公室 偶然发现 一个 该 应用 软件的备份 。这个媒体 装 有 SQL共 9 页 第 2 页 数据库 的 备份,这是我们 重新存储到 笔记本电脑 上的 。所有安全 控制 均 到那些 原先并未恢复数据库 的位置上,而且 我们能够 在适当的位置无 任何限制 地 浏览完整的 数据 库,以保护敏感的数据。这可能像是一 种 妥协的系统 安全 的方式,但 确实是重要的 。往往 并 不是采取直接的方法攻击一个目标,并 且 最终 结果 是相同的 ;系统妥协。
6、数据库备份可 以 存储在服务器上,从而有利于 间接地访问数据。 以上 问题 有一个简单的办法来解决。在 SQL 2000 可以 为 备份 设定 使用密码保护。如果备份 使用了 密码保护, 当创建 密码时 就 必须使用 密码 。这是一种有效 而且不太复杂 的方法阻止备份数据的简单捕获。 然而这意味着 密码必须记住! 当前趋势 在 IT 安全方面有许多当前趋势,这些中的不少都与数据库安全联系起来 。数据库安全 方面的焦点正 吸引 着攻击者的注意力 。 由于 SQL 和 Oracle 开发的漏洞给攻击工具一个得以使用的空间。 这些工具 的 出现提高了赌注,我们已经看到,攻击 主要是针对 服务器暴露到
7、互联网 的 特定 数据 库端口。 贯 穿 安全业的一个普遍问题 是应用 软件 安全,特别 是 定制的 Web 应用程序。随着 Web 应用程序 的功能 变得越来越复杂,它带来 了 应用程序 编 码 方面的 安全 漏洞的更大的潜在威胁 。为了满足 应用软件的功能性要求 ,后端数据存储通常被用来 安排网页内容的格式 。这就需要更复杂的 后端数据 编码。开发者使用不同风格的代码开发,其中一部 分 没有安全意识,这 也许是开发错误的源头。 SQL 注入就是 当前 IT 安全业的一个热门话题。 随着愈来愈多的以期缩短时间的开发数据库的方式和手段的出现, 目前 在 技术安全论坛中, 争论是很平常的。 SQ
8、L注入是一 个容易让人误导的术 语 ,因为该概念 也 适用于其他的数据库,包括Oracle, DB2 和 Sybase 系统。 什么是 SQL 注入? SQL 注入的是 软件开发人员所不希望出现的 与资料库使用代码或指令发送 手段的交流 方法。 这是 发现在 Web 应用 软件 最常见的形式。任何用户输入 应用软件所不允许的内容是攻击的 一个常见来源。 在座很多朋友 已经看到了当访问网站时通常的错误消息框 ,而且往往显示用户输入没有得到正确处理。 一旦出现 这种类型的错误,攻击者将 把焦点放在 更具体的输入字符串 上 。具体的与安全有关的编码技术在使用组织 时 应加入编码标准。 由 于 这种类
9、型的脆 弱性所造成的损害,可以很深 刻 的,尽管这 会 取决于该 应用软件与数据库关联 的特权级别。如果 该软件以管理者类型权限访问数据 ,然后恶意运行命令也 会是 这一级别 的访问权限 , 此时系统 妥协是不可避免的。 还有 这个问题类似于操作系统的安全 规 则, 在那里,项目 应该 以 最低的权限运行, 而且 这是必要的 。如果 是 正常的用户访问, 然后启用这个限制。 同样的问题, SQL 的安全 也不 完全是一个数据库的问题。特定的数据库命令或要求,不应该允许通过应用层。这是可以 通过 安全码 的方式 加以 预防的 。 这是共 9 页 第 3 页 一个 场外话题,但应该被 应 用 的
10、一些基本步骤的详细 设计是有必 要的 。 第一步,在获取任何申请时须验证和控制用户输入。可能的情况下 , 严格 的类型应被设定 以 控制 具体数据(例如, 期望得到 数值数据 ,字符串类型数据等 ),并 在可能实现的情况下,如果 数据 是以字符型 为基础的 , 需要禁止特定的非字母数字字符。如果这 是 不能 实现 的, 应该做出争取使用替代字符的考虑 (例如,使用单引号, 这在 SQL 命令 中时通常被使用的 )。 在使用您的组织 时 具体的与安全有关的编码技术应加入编码标准。如果所有开发商都使用相同的基线标准, 特定具体的安全 措施,这将 大大 减少 SQL 注入妥协 的 风险。 能够 使
11、用 的 另一种简单的方法, 是清除 数据库中不再需要的 所有程序。这 些限制 了数据库中不再需要的或者多于过剩的被 恶意利用 的程度 。这类似于消除 操作 系统 内 不需要的服务 程序 ,是一种常见的安全实践。 总 结 总之,我已 做出的 以上 的大多数观点 是安全概念 的一般意识 ,并没有具体 到某个 数据库。然而,所有这些 确实应 用于数据库, 而且 如果这些基本的 安全 措施被应用 ,你的数据库 安全属性 将大大改善。在下一篇关于数据库的安全 的文章中 ,将侧重于具体的 SQL 和 Oracle 安全问题,有为 DBAs 和开发商 提供的 详细例子和意见。 在上 面, 我们讨论了一般数据
12、库安全概念和共同面临的 问题。在这篇文章我们将集中于特定的 Microsoft SQL 和 Oracle 的安全 问题 ,同样重要的是缓解这些问题的 解决方案。 数据库安全 与 一般 IT 安全问题有许多相似之处 , 都有 一 些 简单 的 安全措施和步骤,容易实施,从而大大提高安全性。虽然这些看起来像普通常识, 但是令人惊讶的是, 我们都看到有多少次,常见的 安全 措施 没有 落实 以至于 造成的安全风险。 用户 账 户和密码安全 在 IT 安全方面的 一个 首要 基本 规则 , 便 是 “ 确保你有一个 可靠的 密码 ” 。在此声明,我已假定 首先 一个密码 已被设定 ,虽然这种情况往往并
13、非如此。在去年的文章 中, 我 略微谈到了 关于 一般安全 意识 的问题 ,但我认为 再次强调这个问题是有必要的,而且至关重要。就像 操作系统,人们关注的焦点 是 内部数据库的账 号安全, 其目的在于管理账户 。 在 SQL 内 ,这将成为 SA 账 号 ,在 Oracle 内,这可以 是 SYSDBA 或 者是 Oracle 账 户。 SQL SA 服务账户 将“ SA”作为密码, 这是很常见的 , 或 者 更糟糕的 是 一个空白密码, 这 同样 很 普遍。 这类 密码 连最基本的安全规则都懒于限制 。用户 在 自己的域 账 户 上 将不允许有一个空白密码, 所以 为什么宝贵的系统资源, 例 如数据库容许被毫无保障。举例来说,一个空白的 “ SA” 密码 ,使 含有 客户端软件任何用