了解组织中用于构建最佳
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版本之间的区别非常小,但新应用程序的组件补丁安装方式会有所不同,从而导致在投入生产环境后失败而无法正常工作。
企业在生产前环境中使用较旧的服务器,在生产环境中使用更好、更快的服务器,这种情况并不鲜见。此决策出于经济考虑是有意义的,但是在
测试负载和速度变化如何影响
安全性时,这种做法将会导致问题。
[page] 当生产环境使用具有大量内存的多处理器硬件,而
测试环境硬件使用单处理器并且仅有1GB内存时,此问题会进一步恶化。应该保持使用同一代的处理器和相同的内存容量并标准化硬件供应商,从而简化这个问题。实现硬件标准化可以提供在两个环境中使用相似驱动程序和组件的优点。
使用虚拟环境
考虑使用加载有生产服务器备份的虚拟服务器来创建生产前环境。在诸如Vmware等虚拟化产品中拥有生产环境的精确副本可以简化服务器设置。如果特定的
测试破坏了服务器,
测试人员可以通过加载服务器的克隆副本来重新建立该服务器。
事故处理
在对外部世界实现
SOA之前,应该决定您将如何处理安全漏洞。假设您某一天发现光标不受控制地移动,或者发现用户数据的打包文件被移动到FTP服务器。您是否会立即拔掉插头?是否会报警?是否会搭乘开往百慕大的第一个航班?
拥有确定和周密的计划会减少安全入侵所带来的一些恐慌。至少,安全漏洞响应计划应该包括联系人列表、初始响应团队和基本指示。联系人列表应该包括技术专家以及重要相关者,例如公司总裁。
基本指示告诉工作人员首先应该如何做,并确定用于保留证据的最佳方法。这些指示还应该包括执行任务的正确顺序--例如,首先应该拔掉插头还是应该给首席信息官(CIO)打电话?
响应团队应该包括信息技术(IT)专家和重要的管理人员。管理人员可以是其他部门的联络点,用以解释系统停止的原因。他们还可以稳定形势,因为有关漏洞的消息可能会导致恐慌。例如,管理人员可以警告客户服务部门网站已关闭,以便他们知道预期会有更多的电话呼叫。管理人员还可以构造客户服务代理人用于应付客户的措辞,以防止惊吓着客户。
此外,还要考虑使用一个外部法律团队作为响应团队的一部分,以帮助确定赔偿金额。外部供应商将具有比在职员工“更冷静的头脑”,并且还可以引入执法级别的法律工具。
实现后的测试
完成生产前
测试并将应用程序转移到生产服务器并不表示
测试的结束。生产
测试是对您的
SOA的最终考验。请记住,将在其中执行
测试的环境与生产环境不可避免地存在细微的差别:当您正在构建
SOA时,当前环境是一个活动的有机体。诸如防火墙配置、服务器修补程序和反病毒更新等次要更改都会影响生产前的
安全性。
要在将
SOA转移到生产环境之前执行的最合适安全
测试之一是渗透
测试。渗透
测试从外部考验
SOA应用程序,以尝试破坏
安全性。这些
测试最适合留给认证正义黑客(Certified Ethical Hacker,CEH)去执行:他们拥有竭尽全力地潜入组织内部所需要的工具和知识。CEH使用攻击方法来利用不当的操作系统修补程序安装或错误的应用程序代码。
渗透
测试通常至少执行两次。第一轮
测试查找安全错误,并向
SOA团队报告。第二轮以及后续的
测试将在已纠正第一轮
测试中发现的缺陷之后执行。让CEH执行“盲”渗透
测试可以揭示有关
SOA的大量信息。在这样的
测试期间,在CEH尝试攻击系统之前,应该为其提供有关基础设施的最少信息。通过这种方式,CEH可以获取外部攻击者在尝试渗透环境之前需要了解的实际场景。人们以为内部人员的考虑已天衣无缝,但是这些
测试可以带来一些令人惊讶的结果。
总结
在您可能希望匆忙实现新的
SOA时,请不要在安全方面走任何捷径。通过依赖
SOA的基本原理,您可以避免数据被泄露。即使在将
SOA交付使用之后,仍要继续使用以下安全措施:
·在
SOA开发小组的基础上组建安全团队。
·开发
测试并提供预期结果。
·在独立于生产的环境中
测试改进功能。
·建立并维护安全标准。
·在推出
SOA之前执行渗透
测试,并在之后定期使用渗透
测试。
第四十一届CIO班招生
国际CIO认证培训
首席数据官(CDO)认证培训
责编:kaifangli
免责声明:本网站(http://www.ciotimes.com/)内容主要来自原创、合作媒体供稿和第三方投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等)版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时,请及时通知本站,予以删除。