1、浅析房管信息化系统数据库安全防护机制 一、房管系统存在的数据库安全威胁 1 缺省账户存在被利用风险 多数数据库在安装以后都会存在一些默认的缺省账户，例如 Oracle中就存在大量的缺省用户，这些用户名和密码随着安装后自动产生，有经验的黑客就可能利用这些账户和密码轻而易举地登录数据库后台，堂而皇之地窃取数据。 2 口令爆破 暴力攻击者不断地输入用户名密码组合，直到找到可以登录的一组。暴力过程可能是靠猜测，也可能是系统地枚举可能的用户名密码组合。通常，攻击者会使用自动化程序来加快暴力过程的速度。 3 与业务不匹配的数据库特权 当数据库用户天然具备了其工作职责所不必需的敏感数据访问权限时，这些权限可
2、能遭到滥用。房管系统的后台数据库 DBA，负责着系统运行维护和数据维护的任务。但是由于其 DBA的特殊身份，就天然具备了访问所有数据的权限 (包括敏感数据 )，对政府、单位的信息安全带来了威胁。 4 不受控的 访问数据库的账号和密码 目前，房管局各应用系统都需要通过一个或几个特定的数据库账号和密码访问数据库，来完成正常的业务流程。这些账号和密码或写在应用程序中或配置在配置文件中，虽然都不同程度地进行了加密或扰乱，但是由于管理不善或开发商的 IT 人员流动都可能造成账号和密码泄露。一旦被黑客或者不良用户获得后通过通用或专门数据库前端管理工具直接访问数据库，就会造成批量数据泄密或者破坏事件。 5
3、数据库本身漏洞 现在，数据库的漏洞攻击方法、工具在网络上任意公开，黑客或破坏分子可以轻易获取并下载 。而信息系统的开发人员大多只重视如何开发满足业务需求，在安全方面考虑比较少，数据库层面尤甚，导致已经公开的数据库漏洞得不到及时修补，数据库中的数据实际上就暴露在网络上，随时等待黑客的攻陷。 6 网络或操作系统层泄密 数据库内的信息要存储在文件系统上，表面上看这些数据的存储是无法直接理解的，事实上这些数据是以明文的形式有组织化存储的。通过 Dul、myDul这样的工具能够将这些数据直接导出成格式化文本，此时任何 Oracle用户认证和授权都不再生效。 底层操作系统 (UNIX 等 )中的漏洞 和安
4、装在数据库服务器上的其他服务中的漏洞可能导致未经授权的访问、数据破坏或拒绝服务。这种破坏最致命的威胁是通过拷贝走明文的数据库文件，从而获得数据库内的所有信息。 7SQL 注入 在 SQL 注入攻击中，入侵者通常将未经授权的数据库语句插入 (或 “ 注入 ”) 到有漏洞的 SQL 数据信道中。通常情况下，攻击所针对的数据信道包括存储过程和 Web应用程序输入参数。然后，这些注入的语句被传递到数据库中并在数据库中执行。使用 SQL 注入，攻击者可以不受限制地访问。 SQL注入攻击是最为常见的 Web应用程序攻击技术， 它会试图绕过 SOL命令。大量的现代企业采用 Web应用程序与其客户无缝地连接到
5、一起，但由于不正确的编码，造成了许多安全问题。 Web 应用程序中的漏洞可使黑客获取对敏感信息 (如个人数据、登录信息等 )的直接访问。在用户输入没有 “ 净化 ” 时，如果执行这种输入便会表现出一种 SQL 注入漏洞。 8 数据库通信协议漏洞 Oracle 层发布的补丁程序所修复的 23 个数据库漏洞中有 11 个与协议有关。许多漏洞涉及到甲骨文数据库使用的专有网络协议问题，该协议被称为 “ 甲骨文网络 ” 。据 Imperva 公司的技术总监 Amichai Shulman 称，这个协议从去年开始就已被意识到要增强其安全性。 “ 直到现在，谁也没有办法解决这个问题。 ”Shulman 表示
6、， “ 一旦有人盯住了这个含混不清的协议，那么他们肯定能找到其中的许多漏洞。 ” 通常，网络漏洞被认为是最危险的。 Shulman 说： “ 因为利用这些漏洞，不需要经过任何的数据库认证就能轻而易举的进入数据库。 ” 针对这些漏洞的欺骗性活动包括未经授权的数据访问、数据破坏以及拒绝服务。 9 敏感数据未加密 对于存储在数据库内的数据，均受控于数据库 自身访问控制权限体系，然而数据明文存储以及各种数据库自身的漏洞、口令破解、权限提升等安全问题，使得敏感数据的安全存储面临巨大挑战。房管系统中的房产信息、纳税记录等敏感信息均未进行加密或者扰乱处理，因此存在重大泄密风险。 10 审计信息不足 对于访问
7、数据库的各种行为，如建立连接、断开连接、各种 SQL 访问、访问的主体和客体、访问时间、结果状态等各种关键信息未形成完整的审计信息，无法进行事后的追查和分析，不能及时发现攻击和泄密行为，同时对管理员和外包服务人员不能形成震慑作用。 二、房管 系统数据库安全防护措施 1 保护默认的用户账号 为确保账号的安全，应避免因安装不需要的账号而带来不必要的风险。另外，对于数据库系统中已经安装但已不再需要使用的账号应定期检查并确认后及时删除。 2 制定密码安全策略 长期不更换密码，或由单一数字或字母组成的简单密码对数据库系统是巨大的安全隐患之一。根据密码复杂性规则，通常需要验证密码是否和账号一致、密码是否超
8、过一定字符长度、密码是否和过去的密码一致、密码是否很容易被猜测。因此，在制定数据库系统密码规范时，应该包括密码生存周期 、宽限时间、密码重复使用时间、登录失效、账号锁定和密码验证功能。 3 数据库用户最小授权 数据库用户最小授权原则就是，只需授予列级权限的不授予表级权限，只需授予表级权限的不授予模式级权限，只需授予对象权限的不授予系统权限。此外，在确定不需要使用某种权限时要及时收回角色和权限。最小授权原则有效地限制、分割了用户对数据库资源进行访问时的权限，降低了非法用户或非法操作可能给系统及数据库造成的损失。 4 三权分立 当前数据库管理员 (如 Oracle DBA)不仅拥有对所有对象的访问
9、 权限，同时具备对象权限和系统权限的授权和审计能力。这就需要对 DBA进行有效分权，保留其数据的访问权限，引入一个安全管理员负责敏感标记和授权，引入一个审计管理员负责设置审计对象和事后追查。特权的分离，有利于保证权力之间的制衡与监督，减少未经授权的访问和欺诈行为的发生。 在信息安全技术信息系统安全等级保护基本要求第三级 (安全标记级 )要求中，提出实现强制访问控制功能。强调访问控制机制对数据库系统中的每个存取对象指派一个密级，对每个用户授予一个存取级，任意一个对象，只有具有合法存取级的用户才可以存取， 可以有效地防止木马类的恶意攻击。目前，实现强制访问控制功能的方法除果用安全数据库管理系统外，
10、还可以通过部署第三方安全增强产品实现数据库强制存取控制机制。 6 保护访问数据库的进出网络通道 虽然防病毒软件和防火墙提供了一定级别的网络安全防护，但并不能因此认为网络通讯就 是安全的。数据库监听器作为连接数据库服务器的网络进程，正经受着巨大的攻击风险。首要的任务是对监听过程进行密码保护，其次可以允许或禁止客户端 IP 地址的访问，这也是保护数据库不被合法用户非法访问的简单而有效的办法。 6 数据存储加密 对于备份文件引起的泄密、明文存储带来的操作系统层和网络层的泄密，需要通过存储数据加密的解决办法。存储数据的加密，可以在应用层实现，调用 Oracle 的加密包或用户自己的加密包都可以实现，密
11、文数据的检索需要在应用层代码中完成；但这种方案只适用于小规模，当数据在几十万或上百万时性能就无法接受了。 Oracle 自身提供了透明数据加密 (DTE)的功能，但该功能无法防止黑客攻击 Oracle 后的泄密；同时这个功能无法支持国密局认可的加密算法，无法满足国家的安全规定。另一种解决方案，就是使用国内的具 有数据库加密处理能力的第三方软件，这种软件的使用上除了加密功能外，重点需要考察透明性、密文数据检索的效率和高可用性。 7 通讯加密 通过数据库自身的传输加密控制，可实现数据从服务器至客户端传输的通讯加密，可以保障数据的保密性和完整性。 8 独立的权限控制体系 当前黑客攻击 Oracle的
12、主要方法，以及 SQL注入攻击的主要方法，都是通过低权限用户升级到高权限用户完成对敏感数据的非法获取。对敏感数据建立一套独立于现有 Oracle 的权控体系，将有助于改善这种状况；即使能通过 Ora-cle的权限体系漏洞升级到高权限用户，也可以通过这种机制控制住数据的访问，当然这种权控体系与数据的加密将更为有效。 9 数据库审计 数据库审计是另一种常用的对数据库进行安全增强的方法，通过审计下用户的数据访问行为和管理行为，为泄密或危险事件发生后的责任追查留下线索。 Oracle 自身具有审计功能，但由于对性能的影响，以及相对难以使用的功能，一般在关键性业务系统上没有人使用。 Oracle 后来推出的Audit Vault 对此有所改善。第三方的一些审计工具，往往是从网络通讯协议的解析来实现数据库 的审计能力；这种方式对数据库的性能没有影响，但也存在一些缺陷：对于密文通讯的信道，无法获得 SQL语句。应用与服务器在一台机器上，无法获得访问行为；特别是 DBA 的操作大多是在 Oracle本机上，无法进行网络的监控。 10 数据库用户与应用绑定 对于应用程序中的数据库用户名和密码往往很难管理，通过该用户名和密码对数据库的使用第三方工具进行访问，将对数据库的安全带来不可估量的损失。 对于这种威胁的防护，最佳的手段就是将该用户与应用绑定在一起，即使用户名和密码泄漏了，也不会造成损失。
