| | |
| | |
为什么坚不可摧？
坚不可摧！是Oracle 从2001年11月开始展开的一场声势浩大的市场宣传活动的主题。其
这样粗线条的描述引伸出许多的问题：
(1)如何断言坚不可摧！安全性专家经常说安全性是一个过程，而不是一个结果。而且
(2)为什么声称坚不可摧？安全性专家并不希望成为黑客的目标，一些黑客也认为这可
(3)坚不可摧的真正含义是什么？如何使供应商和顾客了解一个产品的安全可靠性，以
及这种安全性是否在每一次的版本升级中持续不变。提供安全可靠的软件是非常艰巨的任务，
什么是坚不可摧？
坚不可摧是Oracle对我们的客户群体在生产，分布和支持等各环节向企业提供最安全的关
坚不可摧是我们在过去，现在和将来对我们的客户所做出的安全性承诺。
坚不可摧不是三个星期，或者半年的市场宣传；坚不可摧是建立在经过十年考验的安全
坚不可摧将我们的核心产品的安全开发过程扩展到整个Oracle的产品系列中。
坚不可摧的反义词是什么？
简单地看，“坚不可摧”似乎是市场部轻率的举动。毕竟，没有哪家企业希望成为黑客的
目标，许多的黑客是非常聪明和坚韧不拔的。毕竟，没有哪个产品是完美的。
愤世嫉俗者和持否定态度的人可能会为坚不可摧寻找一个代名词，它是许多供应商对于他
(1)“有些安全性”并不足够好。
(2)“我们所创造的并且作为产品每六个月发行的安全性”并不恰当。
(3)“补打了12个最新的安全性补丁程序的安全性”是不光彩的。
许多的供应商从没有梦想过它们是坚不可摧，因为他们在其产品的安全性上，甚至可扩展
到在其客户的系统上付出的是最小的努力。他们并不关心，但它显示着。他们并不关心，但它
(1)运行缺乏安全性软件增加“黑客保险”的保险费
(2)忽视基本安全性机制所导致的由病毒引起的数十亿美元的损失
(3)对于把安全性作为事后追加的补救措施的安全性产品，为它追加各种补丁程序所增
坚不可摧是Oracle基于多种原因所做出的郑重承诺：
(1)安全性的重要性。9.11唤起了人们对信息安全性如同物理安全性同样的重视。最终
的恐怖袭击可能是隐藏在暗处的一些人通过某种设备对计算机系统发动的袭击，它可以彻底摧
(2)企业信誉。Oracle的最初的客户都是那些在安全性方面在世界上久负盛名的企业。
从公司成立至今二十五年来，我们的核心客户群体始终包括那些在世界上由于安全性而久负盛
名的企业。我们在安全性上的良好声誉是我们的资产，如果我们不是坚不可摧，我们将失去这
(3)节约成本。有人说“现在付款，或将来付出代价”对安全性是十分贴切的。不论是
对客户还是对我们自己而言，如果Oracle从一开始就把安全性认真的解决好，而不是当既成事
对于那些嘲讽坚不可摧只不过是市场噱头的人应该自问一个问题：为什么并不是每个供应
坚不可摧为信息技术领域的所有供应商建立了一套必须遵守的标准：即使Oracle今天不能
把所有事情做得很完美，但我们的安全性可以比竞争对手做得更完善，客户正是基于此决定购
买我们的产品，安全性将在整个行业中得到改善。坚不可摧不仅是我们对我们的客户群体所做
出的承诺，它还是我们的承诺，如果这样做，我们将在整个行业中改善安全性。
坚不可摧包含那些因素？
坚不可摧软件的一个关键因素是对保证的独立评定，即通过一系列正式地安全性评估，一
个第三方组织可以证明我们的产品安全性声明是有效的。对保证的独立评定是坚不可摧的关键
因素，因为，从安全性的角度出发，你如何建立自己的产品比你建立了何种产品更为重要，而
且，只有当你了解了“如何建立”，“何种产品”才是有效的。
坚不可摧的第二个因素是对安全产品生命周期的承诺。保证是生成和维护生命周期的重要
部分；实际上，为了建立安全性的正确性，你必须保证安全产品的开发过程是可重复的，从而
可以保证在追加新的功能的同时没有破化原有的安全性机制。正如Gartner Group的John
Pescatore所说：安全性不在软件中“测试”，它应该在需求分析和计划等最初阶段就作为最
下面的章节将详细介绍Oracle的信息保证测定和安全产品的生命周期。
什么是信息保证？
随着互联网的发展，信息安全性的重要性也日益增长。企业信息的存储，管理，以及对数
据库的访问都迅速增长，而且访问这些数据库的产品和工具也急剧增长。同时，随着客户将他
们的企业推向网络，互联网增加了软件产品开发的速度。
在这种环境中，许多供应商都力求尽可能快地在他们的产品中追加新的性能和功能，但他
们几乎都忽略了这些性能的安全性。这些供应商可能会在推出产品之前进行一次粗略地安全性
检测，但是产品发行的主要因素是在产品发行之前可以装填多少新的功能？而不是利用我的产
品如何保证客户系统的安全。从反面看，对正确实施的强有力地安全性的需求也恰好在更多的
进入市场的时间强制去迎合它时开始增长。网络化的企业增加了许多安全性的冒险，这是因为
最新（而且可能是极少安全性）产品正在保护更加成熟的后台数据存储，而且因为进入市场的
在这种环境中，对于信息保证的需求? 即，证明产品的安全性机制是正确的和形成良好
的? 是极为重要的。不然，客户在供应商的市场部将显得不知所措：即使某些供应商可能每
两天半就会发布一次安全性警告。所有的供应商始终都会声称他们的产品是安全的，能够证明
供应商的安全性声明的主要手段是按照国际基准，采取独立的（即第三方）正式的安全性评估
。这些基准可以被看作是下面问题的定义，即“你的安全性宣言的含义是什么？”只有一个独
立的安全性评估才能证明供应商的安全性宣言的正当性，因为所有的供应商都会声称自己的产
品是安全的。让它有所不同，正式的安全性评估是使供应商在安全性宣言的问题上做到“投入
正如许多消费者不会购买没有Underwriters’ Laboratory™(保险业实验室)评定或
没有咨询顾问的消费者报告的产品或设备一样，消费者也不会购买没有独立安全性评估的关键
历史上，曾由一些特定国家的评估基准，然而过去几年的趋势更趋向国际化。例如，共同
基准是一个国际标准化组织（ISO）标准（15408），许多国家不仅同意共同基准，而且，通过
相互认证还接纳在其他国家举行的共同基准评估。今天，Oracle只在我们的服务器产品上实行
共同基准评估，和联邦信息处理标准（FIPS）-140评估，它对于暗号化模块有效。
信息保证的独立测定也需要经过美国联邦政府的认可。联邦策略指示，即国家安全性电信
信息系统安全性策略（NSTISSP）11号，需要涉及国家安全性的信息系统应具有独立测定的保
证，如共同基准评估或FIPS-140评估。在后911时代，按照NSTISSP #11的要求，对于这种评估
在正式的安全性评估方面，Oracle无疑在该市场处于领先地维，在过去的十年中，对于每
一个主要的世界级基准，它共经过十四次独立的安全性评估。坚不可摧的安全性宣言正是建立
在Oracle数据服务器的十四次安全性评估所提供的独立测定保证的基础之上，它面向了每一个
主要的世界级安全性评估基准，包括共同基准(ISO-15408)，该基准实际上是世界级的评估标
这些正式的独立安全性评估为Oracle，同时也为我们的客户带来了许多益处。
(1)更安全的产品。在评估过程中，安全性评估机构会发现安全性的薄弱环节，而作为
完成评估的条件之一是这些薄弱环节必须得到改善。
(2)可获得验证的安全性开发过程。一个正式的安全性评估包括对开发过程的回顾，其
中包括产品安全性架构，功能规范，设计规范，测试规范以及实际的测试过程。安全性必须是
这些过程的集成，而且是可重复的，以获得和维护安全性评估。
(3)安全性文化。Oracle对安全性评估的义务的最有价值的结果最终是“安全性文化”
。安全性不是一个功能的追加，它从一开始就植根于我们的产品，而且到现在经过十余年的时
正式的评估是我们的安全产品生命周期的一部分，在这十四次安全性评估当中，Oracle每
次都要在安全性方面追加$1,000,000的投资，以保证其安全性机制是正确的。这些成本还不包
Oracle很少做正式的产品“风险评定”，该部分内容将在本文的以后章节介绍。随着时间
的推移，当产品趋向更长产品生命周期的成熟时，我们希望“风险评定”的内容能够融合到与
安全的产品生命周期
除了前面提到的保证的评定之外，坚不可摧还包括一个Oracle范围内的对安全产品生命周
期的承诺。安全性不是在产品完成之后“宣传”出来的，它必须镶嵌在产品的开发和交付过程
的各个环节。安全性必须是一个企业DNA的一部分，应该在产品的开发和交付的各个环节融合
Oracle的安全开发过程包括下列所有因素：
(1)安全的编程标准
(2)对功能，设计，和测试规范的安全性模板
(3)安全性复原检测
(4)集中的安全性功能
(5)产品风险评定和正式的安全性评估
(6)产品的安全性发布基准
安全的编程标准
建立和交付安全产品的唯一途径是要求每一个开发人员具有安全编程标准的知识和义务，
对交付安全产品具有个人的责任。因此安全编程标准成为Oracle的每一名开发人员都必须遵守
安全性编程标准遵循了Oracle其他开发标准的习惯。例如，Oracle具有一个很长的，每一
名开发人员都必须遵守的编程标准。程序的审查将由开发项目经理根据编程标准完成。正如你
不可能组建一个能认真地审查每条程序的单独的小组，但必须在所有的开发人员中形成一种必
须遵守的责任感一样，你不可能为保证程序的安全性而雇用大量的“安全性警察”。每一个开
发人员必须对基本的安全性编程习惯具有足够的知识和义务。
Oracle安全编程标准也指导开发部门在适当的地方使用集中的安全性功能。例如，开发人
员没有必要为使用加密技术而成为密码系统的专家（他们中的绝大部分也不是）。实际上，密
码系统是典型的易于出错和难于正确的系统。因此，开发人员只需了解如何正确使用标准的（
安全编程标准通过以下的途径保障安全性：
(1)接受过基本的安全编程习惯培训的开发人员可以避免在发行周期的早期经常出现的
(2)经过长时间的重复性操作，安全性成为开发人员技能的基本成分。
(3)开发人员可根据需要经常性的向安全性专家请教（因为编程标准也包括指定对核心
Oracle定期举办安全性编程标准的培训，编程标准也在持续性的获得改善和提高。Oracle
也经常性的将“经验和教训”融入到编程标准中，这些经验和教训可能来自一些伦理的黑客性
攻击行为，它会报告发现一些安全性弱点，也可能来自行业信息共享研讨会（IT ISAC）参与
编程标准也为Oracle的所有开发人员形成了一条必须遵守的安全性基线，例如，伦理的黑
客性攻击团队在需求团队通过回顾编程标准和其他安全性清单完成“自我评定”之前，不会采
我们强调编程标准的另一个原因是“现在付款或将来付出代价”的经济规律。Oracle可以
运行多个操作系统，也可以在任何给定的时间内，支持多个版本的产品。我们的一些竞争对手
只能运行一套或两套操作系统，对于他们来说，将他们的客户用作他们的质量控制组织是非常
便宜的（但对他们的客户却不便宜）。如果他们发现一些缺陷，这些供应商只不过是在两个操
作系统的两个版本上提供一个补丁程序。相反，Oracle为一个安全性缺陷已经发布了78个补丁
Oracle降低的成本（通过在最初阶段建立正确的安全性机制）也使客户减少了投入。客户
下载，测试并将补丁程序应用到他们的系统中去是非常昂贵的。我们的一个竞争对手每两天半
发出一个安全性警告，客户就不得不为这些安全性缺陷不断地为自己的系统安装补丁程序。最
终，一旦他们没有坚持下去，他们可能就会被寻找没有安装补丁程序的安全性漏洞的最新的病
对功能，设计，和测试规范的安全性模板
Oracle具有功能，设计，和测试规范的标准模板。标准模板包括安全性和功能性规范部分
测试规范包括能够促进开发相关测试以验证安全性机制。例如，一个共同的安全性薄弱环
节是缓存过载（大约有80%的已公布的安全性薄弱环节是缓存过载）。测试规范模板不仅告诉
开发人员需要测试边界条件，而且还包含有实例讲解如何检查边界条件。需要注意的是：尽管
从上世纪六十年代开始人们就已经十分清楚地了解它，但缓存过载还是很难根除的。我们正在
探索编码检测工具用于更好地检测缓存过载和其他类型的共同的安全性错误，以完善我们的标
我们把尽可能详细的安全性需求纳入测试模板，通过测试所有的潜在错误条件，可以使开
发人员更容易地避免共同的安全性错误。黑客只需发现一个薄弱环节就能臭名远扬，开发人员
需要堵死所有的薄弱环节。利用详细的测试规范可以帮助开发人员更容易地建立坚不可摧的程
安全性复原检测
复原检测是安全性评估所必须的测试，它不仅能验证安全性机制是否工作正常，而且可以
在我们的复原检测中，Oracle具有一套专门的安全性测试套件。对于核心数据库服务器，
Oracle每天都运行一整套复原检测，而且目前正在扩展我们的开发环境，使我们每天可以运行
二十套复原检测。这将更易于迅速发现安全性问题。
作为一个持续性改善过程的一部分，Oracle还将复原检测扩展到认定和修复新的安全性薄
弱环节上。例如，Oracle在开发环境中进行了13,000次新的复原检测，结果在编码库中发现了
缓存过载，它制定了大部分的商业化轻量级目录访问协议（LDAP）的实施。如果你不能避免所
集中的安全性功能
Oracle有一个集中的安全性小组，他们的责任和权力是：
(1)为Oracle内部的各个开发团队提供核心的安全性工艺
(2)为Oracle的产品指示安全性方向
核心安全性小组植根于服务器技术中，他们对Oracle9i 数据服务器和Oracle9i 应用服务
器的产品负责，它们共同构成了可被Oracle所有的产品使用的核心安全性平台。
例如，Oracle具用可用于加密技术的公用库，包括它们自己的运算法则，以及安全性钥匙
的生成，和一个加密套接字协议层的实施。
安全性集中化的原因有许多方面。首先，安全性不是很容易做好的，建立安全性专家组是
最佳的选择，而不是要求每一名开发人员都成为安全性所有方面的专家，特别是安全性方面（
如加密）易于出错难于成功的。第二个原因是经济尺度，即不可能使需要加密套接字协议层的
每一个开发团队都建立他们自己的SSL库。与大量不能共同工作的工艺，和各种不同的质量和
保证相比，拥有一套经过精心测试和优化的安全性工艺的核心是最佳的选择。
集中的安全性也可以使安全性评估获益，因为你可以验证（即通过FIPS-140评估）被多个
产品所使用的核心加密工艺。它为所有使用这些库的产品提供了同一保证的水平。
产品风险评定和正式的安全性评估
如本文前面所介绍的，坚不可摧的安全性是所有信息的保证：保证安全性机制是正确实施
Oracle对我们的核心服务器产品始终坚持独立的安全性评估，到目前已建立了14项评估：
(1)Oracle 商标安全性正根据共同基准进行EAL4评估，该评估有望在2002年上半年完成
(2)Oracle9i 数据库服务器和Oracle9i 商标安全性第二版将被提交进行根据共同基准
(3)Oracle9i 应用服务器（第二版）将被提交进行FIPS-140评估。
尽管正式的安全性评估会带来明显的好处，但它们并不适合于所有类型的产品，原因如下
(1)技术? 许多新的，面向网络的产品采用了一些被评估实体或实验室没有很好理解的
技术。安全性的研究者或“黑客”经常会利用该领域的最尖端的技术
(2)进入市场的时间? 对每一个服务器产品，评估约需一年的时间，它是面向网络产品
的两个产品发行周期。从字面上看，当评估完成后，该产品也已经过时了。
(3)费用? 每件评估约需$1,000,000。如果考虑到进入市场的时间问题，没有人会花费
$1,000,000去评估一个产品，而当评估结束后该产品已经过时。
为了增加我们对正式评估的承诺，Oracle已经将我们的保证组的活动扩展到包括那些暂时
不能进行正式评估的产品的风险评定，和各种“伦理的黑客”活动。风险评定可以包括从安全
性架构评定，到“黑盒子”测试（安装产品并试图非法访问）和“白盒子”测试（我们可以调
查产品的源程序）等方方面面。尽管风险评定不可能达到正式保证的水平（即EAL4），因为没
有正式的方法论介入，我们通常也不会利用第三方的资源，但我们仍然相信这些活动将强化我
们产品的安全性，并能建立我们自己的“黑客思维”的技能。最终，我们自己攻破自己产品总
我们从风险评定中所获得的知识将融入到我们的编程标准和黑客技术中，使他们成为持续
Oracle希望随着面向网络的产品的成熟和它们安全性技术的易于理解，它们应该获得正式
的评估。目前在我们产品的主要安全性组件中所实施的风险评定将会适时地被正式评估所替代
产品的安全性发布基准
Oracle已经开发了安全性的项目清单，它已成为我们发布过程的一部分。在产品物料清单
中的每一个行物料的所有者都必须完成一个安全性项目清单，该清单是专为确定产品是否遵守
安全编程标准（也为避免前十五个或一些共同的安全性错误）而设计的。这些项目清单也包括
缺省的配置需要，例如，可在安装中获得文件许可以强化“优先权限”的考虑，而不是在安装
在某些情况下，安全性项目清单提出了在安全性实施中的一些问题，它们可能会导致产品
最终的发行基准是：Oracle是否能够推迟产品的发行以便于在发行之前改正安全性的薄弱
环节？按照定义，最显著的安全性问题是“因精彩而停止”，我们将停止产品的发布以改正它
们。如前面所述，它是“现在支付”（推迟发行），或“将来付出代价”（它将在各种平台上
发布补丁程序并为我们的客户带来诸多不便）。
与其他的安全性开发过程一起，Oracle不断改进安全性项目清单，使它对开发人员更有帮
助和保证更完善的安全性。在发行的每一版产品中，对安全性的可发行性的需求将通过风险评
定获得更严格并纳入最新的“经验教训”及被发现的薄弱环节。
例如，Oracle通过我们的“伦理黑客”发现我们自己的系统管理员在数据库的安装中并不
经常改变缺省的密码。虽然我们的文档劝告客户改变缺省密码，我们认识到为保证安全应使它
更容易。（毕竟，系统管理员已经习惯了不去做许多东西事情。）根据这种情况，我们改变了
Oracle9i 数据库的缺省安装，在几乎所有缺省账户中锁定并使密码失效。
Oracle的坚不可摧承诺意味着在缺省模式下产品的安全性会日益增加，因此产品具有无限
的可被接受的安全性，而系统管理员将会为此付出极小的附加操作。甚至被发现的，实际上是
配置问题的“薄弱环节”将成为导致开发变更的候选因素。在保证产品安全性问题上，如果能
自动地完成的越多，系统管理员需要做的就越少（系统管理员一般很少会阅读在文档中所述的
安全性薄弱环节
安全性产品生命周期的一个重要方面是处理薄弱环节。遗憾的是，即使是最严格的安全开
发过程也不可能造就没有缺陷的软件，或者没有安全性缺陷的软件。
Oracle对坚不可摧软件的承诺包括处理明显的安全性薄弱环节的方面，以保护我们客户的
系统。我们对这些薄弱环节的反应包括两个方面：
(1)对明显的安全性薄弱环节采取积极的和负责的处理，包括在所有可能影响到的平台
上尽快地为薄弱环节安装补丁程序，以及通过发布安全性警告向客户发出通知。
(2)根据我们的开发过程回顾薄弱环节，以确定我们在未来的开发中应如何避免类似的
Oracle通过安全性警告将明显的安全性薄弱环节通知我们的客户群体：它的内容包括一个
简短的薄弱环节描述，回避方法和补丁信息，我们将把它们公布在Metalink
(http://metalink.oracle.com/)，和TechNet(http://technet/depl
oy/security/alerts.htm) 站点。我们也会通过一些渠道将它发布到一些大型的安全性预警社
区，这些渠道包括Internet Security Systems’ (ISS) X-force通知，或通过信息技术信息
共享和分析中心(ITISAC)。通常，安全性警告所发布的薄弱环节一般具有下列的特征：
(1)薄弱环节暴露了一个严重的安全性漏洞（如一个没有被授权的用户可以被赋予他没
有被授权的权限，或一个普通的用户可以变成SYS或SYSDBA）。
(2)薄弱环节是广泛的，设计多个版本和/或多个操作系统。
(3)薄弱环节是相对容易被发现的。过去，这意味着一个并不十分精通的用户可以发现
它，在互联网时代，随着黑客技术，黑客研讨会和黑客工具的增加，几乎所有人都可以发现安
(4)几乎没有防范或只有有限的防范措施。
(5)薄弱环节在目前正在得到支持的Oracle产品中被发现。
在处理由于我们所支持的大量的平台，或所支持的大量产品版本所造成的安全性薄弱环节
上，Oracle面临一个特有的挑战。如果我们在通过一个警告通知我们的客户之前，能够在所有
可能影响的平台上为明显的薄弱环节打上补丁程序是最理想的。这可以使所有的客户，不论是
版本或平台都能够保护他们的系统。偶尔，假如薄弱环节在互联网上已经被发布得众所周知，
我们会在所有的补丁完成之前发出我们的警告。在这种情况下，我们会调动所有的力量尽快完
Oracle相信所有的客户应该受到同样高水平的安全性保护。同样的，我们不能把有关安全
性薄弱环节的信息或内部消息只提供给有选择的或喜欢的客户群。所有的客户都有一些敏感的
即使Oracle自己的IT部门，也只是在补丁被公布的一、二天之前才获得通知（以便于我们
有时间在警告被公布时为我们自己的系统打好补丁）。我们仍有一些理由不会把我们进一步的
信息共享到即使对安全性最敏感的客户，如美国政府，信息公开法(FOIA)是主要的原因。我们
在信息被公布之前发布到政府的任何信息，都应该通过信息公开法请求发布给John Q.Hacker
。没有FOIA对于安全性威胁的共享信息的解除，即使对政府实体而不是对一般公众，Oracle也
最后，我们签署了“安全性黄金法则”：对待客户的系统应该象对待自己系统的安全性一
样。我们把客户的系统看作象我们自己的一样，因为他们的就是我们自己的。
结论
世上没有安全性的魔术子弹，但Oracle始终站在我们的产品安全性以及我们客户的系统安
全性的背后。应为我们自己的企业也是运行在Oracle之上，我们也是提供坚不可摧软件的既得
利益者。坚不可摧建立在我们具有20年为世界上最具安全性意识的客户建立系统的实力和经验
的基础上，这些客户中包括智能部门和国防部，也建立在由十四个独立的安全性评估所提供的
保障基础上。（我们最强劲的竞争对手只分别具有零个或一个评估。他们为什么不在安全产品
的生命周期和可证明的安全软件上进行投资呢？）
坚不可摧的软件是一个长期的承诺，它已经在实施过程中，它将被扩展到对每个Oracle产
品的相同的开发方法和保障评定中。今天，所有强烈关注安全性的客户都只会把他们的数据库
运行在Oracle上。我们的承诺是把我们具有最完善的安全性的数据库扩展到Oracle所开发和发
行的每一个产品当中：任何地方都坚不可摧。
市场活动终有结束的时候，但坚不可摧是我们在过去，现在和未来对客户所做出的安全性
承诺。
| |
|
|
| |
| |
|
