Oracle数据库安全面面观

张文宇 2015-12-08 09:59:00

转载声明：本文为DBA+社群原创文章，转载必须连同本订阅号二维码全文转载，并注明作者名字及来源：DBA+社群（dbaplus）。

专家简介

张文宇：10年以上IT服务相关工作经验，长期从事系统、网络及数据库方面的规划设计、工程实施与运维管理工作，具备丰富的运营商、医疗等行业项目经验。目前专注项目管理、解决方案、售前及咨询类工作。持有Oracle 8i OCP，10g OCM，及思科、微软等厂商产品认证。

概述

数据库中保存的数据涉及各类账号、密码、个人隐私、安全信息等敏感信息，核心数据是企业的命脉。通过建立完善的信息安全系统，保护企业核心数据尤其是企业商业机密，防止从内、外部泄密，已经成为当前众多企业的共识。

随着信息化建设的不断发展，IT安全建设的重点，已经从传统的网络安全、桌面安全、系统安全、应用安全和身份认证管理安全等领域，转向了如何加强IT系统核心的数据库安全防范。

数据库成为企业信息资产的同时，也被越来越多的不良之徒所觊觎。数据被违规访问、删、改、复制和缺乏审计的安全问题，已经成为IT系统最大的威胁。根据IOUG 和Verizon Business的最新市场调查，2010 年全球造成严重后果的IT安全事件中92%是针对数据库的侵入，89%的黑客采用了SQL注入技术，84%的外部攻击利用了管理不善的数据库用户权限。

那么，如何才能更有效地保护数据库不受侵害？如何解决非法访问的监控与审计？如何达到《信息安全等级保护条例》的信息安全合规要求？怎样才能满足中国SOX《企业内部控制基本规范》的规定？

本文从数据安全角度简述数据库安全的管理，从逻辑安全与物理安全两个方面进行论述。

安全状况分析

调查结果显示92%的记录源自被侵入的数据库服务器，也就是说数据库安全是确保数据安全的关键。

-- Databases and file servers, both repositories of so much valuable information, are also targeted regularly.

近年一些著名的泄密门：

省级电信公司的增值服务客户信息被竞争对手掌握
某移动公司的充值卡数据被篡改、作案者卖卡获利380万
某地社保核心参数被修改，导致当月所有缴费金额错误
某地社保受益账户修改，诈领养老金事件

数据泄漏的途径离不开以下三个层面：

存储层：直接盗走数据文件或备份文件，异地还原后得到数据；
数据访问：通过人为获取DBA等高权限用户的口令，或通过权限提升等漏洞得到一个高权限用户身份，进行数据窃取；
应用层：破解或通过工作便利获取应用中的数据库用户口令，绕开业务系统直接访问所有数据（因业务系统中往往对操作范围进行限定，只可获得局部数据）。

数据库的安全漏洞与威胁类别繁多，入侵数据库的常见手段不下几十种，攻击者最常使用的有：

通过暴力破解数据库用户口令，操纵数据库
利用缺省口令的漏洞访问数据库
利用权限提升的漏洞得到高权限用户身份，控制数据库
利用PL/SQL注入等，获取访问权限提升，操纵数据库
利用管理漏洞，获知DBA等合法用户名的口令，操纵数据库
入侵到数据库服务器主机，拷贝数据文件、或备份文件

数据逻辑安全防御措施

如前所述，真正行之有效的数据库防护的技术手段应该是从根源上，进行核心数据的增强访问控制。包括存储层上利用加密技术保护核心数据项、访问控制上采用独立的权限控制增强技术防止DBA等高权限用户，应用层保证数据库用户与业务系统的绑定无法绕开。

本文后续重点介绍数据库层面的数据安全防御措施。

3.1 用户管理

首先应针对数据库账号，将其按照功能进行分类，例如：数据库默认账号、程序账号、维护账号等。

数据库用户/用户组应配置相应的安全规则，如下：

使用用户profile进行属性控制，针对不同类型的用户，使用不同的profile属性：

3.2 权限管理

根据最佳实践，针对权限管理建议从用户权限、账号角色管理、数据字典保护、DBA组权限限制方面做到如下几点：

根据用户的业务需要，配置其所需的最小权限
使用数据库角色（ROLE）来管理对象的权限
启用数据字典保护，只有SYSDBA用户才能访问数据字典基础表
限制在DBA组中的操作系统用户数量，通常DBA组中只有Oracle安装用户

遵循权限最小化原则，使用角色对用户进行授权。

3.3 日志安全管理

日志安全方面，可从登录日志、操作日志、系统安全事件、数据库审计策略四个方面考虑：

记录登录日志：数据库应配置日志功能，对用户登录进行记录，记录内容包括用户登录使用的账号、登录是否成功、登录时间以及远程登录时用户使用的IP地址。
记录操作日志：数据库应记录用户对数据库的操作，包括但不限于以下内容：账号创建、删除，权限、口令修改，读取与修改数据库配置，读取与修改业务用户的敏感数据。记录需要包含用户账号、操作时间、操作内容以及操作结果几个方面。
记录系统安全事件：配置在系统层面记录安全事件，方便管理人员分析。
数据库审计策略：根据业务要求制定数据库审计策略。

3.4 数据库审计

需要特别强调一下数据库审计方面的内容，Audit审计的种类可大致分为如下几种：

强制审计：为每一次实例启动写出审计记录到OS文件，shutdown以及权限登录的记录存放在$ORACLE_HOME/rdbms/audit 目录下。其中对SYS用户的审计记录SYSDBA/SYSOPER等权限用户的操作，审计记录存放在OS 文件，SYSLOG中。
标准审计：记录用户针对数据库对象、语句、权限级别的行为。审计记录可以存放在OS文件、XML文件或数据库中(AUD$基表)，分为如下级别：

◎对象级别审计

◎权限级别审计

◎语句级别审计
细粒度控制：基于用户访问的数据记录用户行为。审计记录存放在数据库内(FGA_LOG$)或者XML文件中。

标准审计包括：SQL语句审计、系统权限审计与对象权限审计三类，流程及说明如下：

SQL 语句审计：幻灯片中显示的语句可审计影响表的任何数据定义语言 (DDL) 语句，包括 CREATE TABLE、DROP TABLE 和 TRUNCATE TABLE 等。可按用户名或者按成功或失败来设置 SQL 语句审计的重点：

SQL> AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL;

系统权限审计：可用来审计行使的任何系统权限（如 DROP ANY TABLE）。可按用户名或者成功或失败设置审计的重点。默认情况下，审计设置为 BY ACCESS。每次行使经审计的系统权限时，都会生成一条审计记录。可选择使用 BY SESSION 子句将这些记录组成一组，以便每个会话只生成一条记录。（这样，如果一个用户针对另一个用户的表发出了多条更新语句，则只收集一条审计记录。）请考虑使用 BY SESSION 子句来限制由于审计系统权限而对性能和存储产生的影响。

对象权限审计：可用来审计关于表、视图、过程、序列、目录和用户定义数据类型的操作。这种审计类型可按成功或失败设置审计的重点，而且可以按会话或访问权限分组。与系统权限审计不同，默认情况下，对象权限审计按会话分组。如果要为每个操作分别生成一条审计线索记录，必须显式指定 BY ACCESS。

细粒度审计Fine Grained Auditing (FGA)

FGA 策略通过DBMS_FGA包与表/视图/同义词关联起来，例如：

除脚本外，推荐使用Oracle Audit Vault 实时审计数据库活动。

Oracle Audit Vault 实时审计数据库活动实例：

3.5 敏感数据管理

数据安全主要针对数据库敏感数据进行安全保护，例如：姓名、电话、身份证号码、银行账号、用户密码等，包括：敏感数据的屏蔽、数据脱敏、数据加密三个方面，如下图：

工具方面推荐使用Oracle Database Vault 在数据库内部实施安全策略。

使用Oracle Data Masking 对生产数据进行不可逆的数据脱敏再用于非生产环境。

3.6 数据库漏洞管理

需要关注Oracle官方定期发布的补丁集，其中会包含最新的安全补丁，例如：

做到以上，我们的数据库就安全了吗？不！我们还忘记了，数据库物理安全！

数据库物理安全

4.1 概述

数据库的物理安全，主要指数据库的应急/容灾措施，安保层面暂不涉及。那么，数据库的容灾有多重要呢？

只有6%的公司可以在数据丢失后生存下来，43%的公司会彻底关门，51%的公司会在两年之内消失。
在灾难之后，如果无法在14天内恢复信息作业，有75%的公司业务会完全停顿，43%的公司再也无法重新开业，20%的企业在两年之内被迫宣告破产。

数据大集中的同时也带来风险的高度集中，系统集中的程度越高，系统故障影响业务的范围越大，系统集中的程度越高，数据损坏将导致大量的业务数据丢失。

数据高可用能够保证业务的连续性，包括：保障关键业务应用、消除和减少宕机时间；也必须做到保证数据的安全，因为数据是企业最重要的资产，要保证24x7的数据可访问。

常见影响业务连续性的因素包括计划内与计划外两部分：

★ 计划内

软件升级
备份、恢复、归档
数据中心迁移、整合
测试、容灾演习等

★ 计划外

系统处理能力下降
人为操作故障：错误/恶意删除数据；错误/恶意执行程序或命令等
系统故障： UPS故障、硬盘故障、CPU故障、数据库软件故障等
安全体系被攻破
供电系统瘫痪空调故障
机房结构性破坏：水灾、火灾、地震等
社会性恐慌：瘟疫等
环境紧急事件：污染等
城市事件：动乱、罢工等
气候灾难：台风等
战争、恐怖主义事件

4.2 容灾系统建设考虑的因素

1.风险分析

各种风险发生的概率及风险发生后对业务的影响程度

2.业务关键等级划分

关键业务/非关键业务
各项业务的容灾指标（RPO/RTO）

3.容灾策略

同城异址容灾/异地容灾
容灾层次：系统级、数据级、应用级和业务级
容灾范围：关键业务应急，全业务容灾
运营方式：主备中心，双中心
容灾规模：同级容灾，降级容灾

4.灾难类型

需要考虑哪些灾难？怎样的灾难？会使业务中断多久？

5.恢复速度

灾难发生后需要多久来启动及运行系统？能否承受数天或数分钟的等待？

6.恢复程度

需要恢复每条记录和交易吗？可以使用上星期或昨天的数据吗？需要恢复一切吗？有不相关的文件吗？什么是合法隐含的要求？有少数的一组人输入交易吗？他们可以重新输入灾难期间丢失的交易吗？这些交易十分重要而不容许丢失吗？

7.可用的技术

必须结合考虑所选技术在本地区的适用性、实现条件以及在实施时是否受某些现有条件的制约？

8.方案总体成本

如果要做到RTO和RPO越小，则投入的建设成本越大，从下面的曲线可以清楚地看到其相关性。

除实现灾难备份需要多少投资外，还要考虑不实现灾难备份会损失多少钱？

4.3 容灾备份技术规范简介

企业运营系统的容灾备份系统规划和建设目标一般包括：

实现关键业务系统及其关联系统的数据安全
减少计划停机次数、时间，消除对核心数据的争用
将异地中心接管业务的时间控制在可以接受的范围内
实现异地中心的软硬件设备和数据的复用

灾难恢复的衡量指标主要有RTO与RPO两个：

恢复时间目标（RTO，Recovery Time Object），指最大计划停机时间/意外停机时间，商业机构可容忍的最长停机时间是多少。
恢复点目标(RPO，Recovery Point Object)，指数据丢失限度，商业机构可承受的最大数据损失量是多少。

灾备解决方案的七个级别（7 Tiers for Disaster Recovery Solution 国际标准SHARE 78）：

等级零：无异地备份
等级一：备份介质异地存放
等级二：备份介质异地存放及备用场地
等级三：备份介质异地存放及备份中心
等级四：定时数据备份及备份中心
等级五：实时数据备份及备份中心
等级六：零数据丢失

业务恢复要求指标级别分类：

RTO从低到高分为5个级别，其中1级为最高级别：

RPO从低到高分为5个级别，其中1级为最高级别：

4.4 常见的数据保护技术

常见的数据保护/灾难备份策略主要分为四个大类：

传统的磁带备份，本地或异地存放
智能存储的远程磁盘镜像技术

◎存储厂商的磁盘镜像

◎虚拟存储
卷组复制技术（主机）
基于数据库日志的数据复制技术

◎数据库自身的容灾和复制技术 (Oracle Data Guard)

◎开放的数据库同步技术（如Oracle GoldenGate)
基于应用软件

此处我们主要介绍基于数据库日志的数据复制技术，包括Dataguard/Active Dataguard与GoldenGate两种Oracle公司的产品。

区别于传统的数据库高可用性技术与远程磁盘镜像技术，基于数据库日志的数据复制技术通过在生产与容灾端的网络上传输数据变更的部分，达到两端数据库的数据同步与一致性。

数据库级别复制：Oracle DG/ADG

Oracle Dataguard/Active Dataguard通过网络传输并应用数据库归档/在线日志。

可以分为同步复制与异步复制两种方式，使用同步复制可以实现数据的完全同步，即做到RPO=0，但也带来对网络状况要求高、远距离传输时容易影响应用等不利因素。采用异步复制，可以提供良好的性能，对生产端的影响非常小，相应的，无法做到RPO=0，灾难发生时会有一定的数据损失，两种方式的选择要从容灾系统建设的整体进行考虑。