确保任何关系数据库的安全并非易事，更用不说像甲骨文数据库这么极其庞大、功能丰富的数据库了。这款产品有众多不同的部署方式，再加上诸多安装的遗留版本，几乎不可能识别及防范每一个潜在的威胁。甲骨文数据库连接至Web应用程序，这带来了充满变数的开源和第三方软件，因而最终用户企业就更容易受到攻击了。
不过，并不是用户不可能驾驭甲骨文数据库，特别是借助甲骨文公司最近发布的一些新工具。下面不妨看一下甲骨文数据库用户面临的几个安全难题，以及应对难题的一些方法。
第一大难题：打补丁
在过去，甲骨文在给需要引起注意的安全漏洞及时打上补丁方面表现很糟糕。因备受关注的漏洞披露，加上客户强烈抗议，这家公司于是改变了做法。甲骨文在实质性披露漏洞风险方面仍显得滞后，无疑没有以一种其客户能够明白的语言来告知风险，而且通常也不提供变通方法。不过，它发布安全补丁的确比几年前要及时得多。
但任何甲骨文数据库管理员都会告诉你，安装甲骨文补丁很难，特别是由于系统常常需要在打上补丁后重启；而许多业务功能围绕甲骨文数据库这个核心系统来运行。
停掉数据库以便打补丁可不是唯一的问题；对数据库功能进行改动也会导致副作用央及整个企业。大多数数据库管理员在安装补丁后都会遇到严重的数据库崩溃，不得不完成随后的清除过程。
第二大难题：部署复杂性
无论是中型企业还是大企业，许多企业都在积极采用虚拟化技术，旨在改进服务、提高灵活性和冗余性，同时降低运营成本。网格系统把可扩展性和负载均衡推向了新的水平。而安装云架构成为了现实，甲骨文数据库作为一项服务来提供。
这每一种新的部署模式都会带来威胁途径。由于安装了多节点、虚拟和复制的系统，因而大大加强了核实配置设置的难度。想核实补丁、访问控制设置和识别配置不当的机器，也困难得多。
此外，许多攻击者偷偷篡改配置设置，这些设置直到数据库重启后才会生效。篡改和随后的攻击极难被发觉，更不用说发现彼此之间的联系了。
第三大难题：Web应用程序
保护专有的Web应用程序是一个更大的难题，因为与仁科、Siebel和甲骨文财务软件等商业产品不一样，Web应用程序是结合了复杂的开源软件和第三方服务开发而成的。网页通常具有动态性，所以每个用户体验都略有不同，因而使得应用程序的安全测试显得更困难了。
结果就是，你根本无法用一般的评估和审计产品来保护Web应用程序的安全。安全工具需要大量的定制工作，而Web应用程序需要比商用软件更全面深入的测试和认证。
第四大难题：广泛的威胁范围
甲骨文数据库提供了数量众多的功能和选项，因而面临更大的威胁范围，这让攻击者有机会瞄向多得多的目标。甲骨文数据库标配的许多功能是许多公司很少使用的。而几乎每一个甲骨文软件包的安全都曾经受到过危及。
由于甲骨文软件包兼顾众多不同的用例（use case），所以没有什么所谓安全的默认配置。默认的甲骨文数据库配置并不安全，所以用户得抽些时间来取消自己不需要的功能；还要在数据库投入生产环境之前，核实用户、平台和应用程序等方面的安全措施已落实到位。
第五大难题：安装的遗留版本
不是每个甲骨文的客户都使用版本11的数据库。实际上，绝大多数客户使用比较旧的版本。一大部分甲骨文客户仍使用版本8和9。甲骨文数据库功能稳定，所以客户并不急于将钱投入到升级上。
但这些版本是在大多数人听说缓冲器溢出攻击或远程漏洞之前设计和开发的。许多已知的安全威胁已通过补丁得到了消除–假如它们都已经向后移植（backport），但这些旧版本数据库缺少密码管理、加密、数据库管理员角色隔离和审计等方面的一些改进。
同样，使用旧版本甲骨文数据库的遗留应用系统并没有内置安全功能，比如控制系统、自主开发的应用系统、大型机连接器和SAP R3等系统。应用系统与数据库之间有着相互依赖的关系，依靠外部安全服务来检测和防范威胁。
尽管面临上述难题，但甲骨文公司还是在提供一套越来越可靠的安全功能和应用软件。如果公司企业充分利用好这些工具，就对保护自己的甲骨文数据库大有帮助。
