本系列讨论面向服务的体系结构（Service-Oriented Architecture，SOA）安全性实现路线图。“SOA 安全性基础知识”系列包括三个部分，本文是其中的最后一个部分，将提供用于测试 SOA 安全性的规则。了解组织中用于构建最佳 SOA 安全性所需要的工具和知识。

在召集团队并开发新的 SOA 以后，现在是测试其安全性的时候了。测试使您可以了解远景是否与对成功的承诺保持一致。

测试应该分成两个阶段进行：生产前测试 和生产测试。生产前测试是允许对任何新的应用程序或硬件解决方案进行任何外部访问之前的最后步骤。此测试旨在模拟生产环境，不仅应该测试安全性，而且还应该测试负载、流程和功能。

生产前环境和生产环境之间通常存在微妙的区别——例如，硬件、操作系统配置和防火墙设置。因此，在生产测试期间，要重新检查在生产前做出的安全性改进。

预先为测试做规划

通过确定必须测试哪些组件以及如何最好地测试那些组件来开始您的测试。非管理用户是否可以获得管理权限？是否要对没有权限的用户隐藏私有数据？常见的黑客脚本是否能够找到被忽视的漏洞？结构化查询语言（Structured Query Language，SQL）注入是否失败？确保摆脱思维的束缚，并考虑恶意用户可能采用来渗透安全层的任何工具。通过考虑内部和外部项目的安全性，您可以同时在两个测试阶段中实现最大的测试覆盖面。

对所做的测试和测试时间做文档记录。对测试做计划安排对于避免测试人员和开发人员彼此干扰是非常重要的。测试会破坏应用程序，因此务必了解是哪些测试导致了破坏。此外，您可能需要在下班后运行某些测试，因此找到恰当的人员也是非常重要的。

您在本系列的 第 1 部分 组建了自己团队。从该团队选择最适合帮助进行安全性测试的成员。测试团队通常在构建阶段基本形成，此时人们自然地协作处理新 SOA 的功能、支持和使用方面。确保在形成这些团队时，在各个团队中引入安全专家。

还要考虑引入中立方以在测试期间提供帮助。这些测试人员可以是不参与最终 SOA 设计的精选用户或开发人员。这样的测试人员通常可以提供有关功能工作状况和安全性是否工作正常的中肯意见。在早期阶段征求外部安全专业人员的意见还可以引入大量的信息。这些专业人员专门处理安全问题，能够提供不同寻常的建议来保护数据避免未经授权的访问。专业的安全公司通常也提供了不同的专门研究，例如网络、应用程序和硬件，这些专门研究能够扩充您的当前人员的知识。这些团体通常拥有直接的供应商支持，因而通常能够提供不容易通过其他途径找到的高级信息。

在组建测试团队以后分配测试。向团队成员传达他们应该如何执行测试以及预期会得到什么结果。在显示“事前和事后”结果的书面检查清单中记录具有已知答案的问题。测试人员不仅要以正确的顺序执行任务，而且还要确定结果是否符合开发人员的预期。应用程序提供了某个结果并不意味着该结果是正确的。例如，如果新的 SOA 是客户订单系统的一部分，则要检查数学运算。装运费和税款是否计算正确？

设定标准

安全性测试应该同时遵守编程和行业标准。诸如 Payment Card Industry (PCI) 和 Health Insurance Portability and Accountability Act (HIPAA) 等行业遵从性标准具有关于如何处理数据的特定规则。

设置生产前环境

在将更改投入生产应用之前，始终考虑使用专用的生产前环境来测试更改。生产前环境应该与生产系统尽可能密切地匹配。这在测试负载和安全性时会变得非常关键。有时，细微差别也是非常关键的，例如同时在两个环境中使用相同版本的 Linux®。

例如，假设所构建的新 SOA 应用程序将使用 IBM® WebSphere®。测试和生产系统都已安装和更新最新版本的 WebSphere。然而，生产环境使用 SUSE Linux，而测试环境加载的是 Red Hat Linux。虽然两种 Linux 版本之间的区别非常小，但新应用程序的组件补丁安装方式会有所不同，从而导致在投入生产环境后失败而无法正常工作。

企业在生产前环境中使用较旧的服务器，在生产环境中使用更好、更快的服务器，这种情况并不鲜见。此决策出于经济考虑是有意义的，但是在测试负载和速度变化如何影响安全性时，这种做法将会导致问题。

当生产环境使用具有大量内存的多处理器硬件，而测试环境硬件使用单处理器并且仅有 1 GB 内存时，此问题会进一步恶化。应该保持使用同一代的处理器和相同的内存容量并标准化硬件供应商，从而简化这个问题。实现硬件标准化可以提供在两个环境中使用相似驱动程序和组件的优点。

使用虚拟环境

考虑使用加载有生产服务器备份的虚拟服务器来创建生产前环境。在诸如 Vmware 等虚拟化产品中拥有生产环境的精确副本可以简化服务器设置。如果特定的测试破坏了服务器，测试人员可以通过加载服务器的克隆副本来重新建立该服务器。

事故处理

在对外部世界实现 SOA 之前，应该决定您将如何处理安全漏洞。假设您某一天发现光标不受控制地移动，或者发现用户数据的打包文件被移动到 FTP 服务器。您是否会立即拔掉插头？是否会报警？是否会搭乘开往百慕大的第一个航班？

拥有确定和周密的计划会减少安全入侵所带来的一些恐慌。至少，安全漏洞响应计划应该包括联系人列表、初始响应团队和基本指示。联系人列表应该包括技术专家以及重要相关者，例如公司总裁。

基本指示告诉工作人员首先应该如何做，并确定用于保留证据的最佳方法。这些指示还应该包括执行任务的正确顺序——例如，首先应该拔掉插头还是应该给首席信息官 (CIO) 打电话？

响应团队应该包括信息技术 (IT) 专家和重要的管理人员。管理人员可以是其他部门的联络点，用以解释系统停止的原因。他们还可以稳定形势，因为有关漏洞的消息可能会导致恐慌。例如，管理人员可以警告客户服务部门网站已关闭，以便他们知道预期会有更多的电话呼叫。管理人员还可以构造客户服务代理人用于应付客户的措辞，以防止惊吓着客户。

此外，还要考虑使用一个外部法律团队作为响应团队的一部分，以帮助确定赔偿金额。外部供应商将具有比在职员工“更冷静的头脑”，并且还可以引入执法级别的法律工具。

实现后的测试

完成生产前测试并将应用程序转移到生产服务器并不表示测试的结束。生产测试是对您的 SOA 的最终考验。请记住，将在其中执行测试的环境与生产环境不可避免地存在细微的差别：当您正在构建 SOA 时，当前环境是一个活动的有机体。诸如防火墙配置、服务器修补程序和反病毒更新等次要更改都会影响生产前的安全性。

要在将 SOA 转移到生产环境之前执行的最合适安全测试之一是渗透测试。渗透测试从外部考验 SOA 应用程序，以尝试破坏安全性。这些测试最适合留给认证正义黑客（Certified Ethical Hacker，CEH）去执行：他们拥有竭尽全力地潜入组织内部所需要的工具和知识。CEH 使用攻击方法来利用不当的操作系统修补程序安装或错误的应用程序代码。

渗透测试通常至少执行两次。第一轮测试查找安全错误，并向 SOA 团队报告。第二轮以及后续的测试将在已纠正第一轮测试中发现的缺陷之后执行。让 CEH 执行“盲”渗透测试可以揭示有关 SOA 的大量信息。在这样的测试期间，在 CEH 尝试攻击系统之前，应该为其提供有关基础设施的最少信息。通过这种方式，CEH 可以获取外部攻击者在尝试渗透环境之前需要了解的实际场景。人们以为内部人员的考虑已天衣无缝，但是这些测试可以带来一些令人惊讶的结果。

总结

在您可能希望匆忙实现新的 SOA 时，请不要在安全方面走任何捷径。通过依赖 SOA 的基本原理，您可以避免数据被泄露。即使在将 SOA 交付使用之后，仍要继续使用以下安全措施：

• 在 SOA 开发小组的基础上组建安全团队。
• 开发测试并提供预期结果。
• 在独立于生产的环境中测试改进功能。
• 建立并维护安全标准。
• 在推出 SOA 之前执行渗透测试，并在之后定期使用渗透测试。

参考资料

• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
• 阅读整个 “SOA 安全性基础知识”系列，包括三个部分。
  • SOA 安全性基础知识，第 1 部分: 制定保护大型 SOA 应用程序的路线图，充分利用涵盖从 SOA 安全性团队构建到需求收集流程的各个方面的 10 步骤流程。
  • SOA 安全性基础知识，第 2 部分: 创建任何人都可以使用的高层次设计，讨论可帮助 SOA 安全团队开发成功的高层次设计的规则。
• 在 developerWorks 的 Architecture 架构专区中，获取用以提高您在体系结构方面的技能的各种资源。
• 浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。

• 下载 IBM 产品评估版，获得来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere 的应用程序开发工具和中间件产品。

讨论

• 参与论坛讨论。
• 访问 developerWorks Blog，从而加入到 developerWorks 社区中来。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号