SOA安全性基础知识，第1部分: 制定保护大型SOA应用程序的路线图

SOA安全性基础知识，第1部分: 制定保护大型SOA应用程序的路线图2011-10-01 IBM John Betancourt实现更好的 SOA 安全性的十个步骤

简介：本系列提供面向服务的体系结构（Service-Oriented Architecture， SOA）安全实现路线图。本系列共三部分，本文是其中的第1部分，将介绍一个包括十个步骤的流程，以帮助您进行从构建SOA安全团队到创建有效的需求收集流程等各个方面的工作。在第2部分，我们将了解如何创建抽象设计，第3部分将讨论测试用例。

最近我有机会参与了一个SOA项目——具体来说，是一个大型自动控制系统的安全实现。我尽可能地阅读了很多关于此主题的书籍；我在网上对此进行研究，甚至向以前的同事和朋友发送电子邮件询问相关事项。让我意外的是，没有提供我所需的逐步流程的路线图，不能帮助我完成保护大型SOA应用程序的目标。

最后，我不得不自己创建了一个这样的流程。我开发了本文中所述的包含10个步骤的简单流程。

第1步选择正确的团队

将大型关键基础设施应用程序迁移到SOA的工作令人望而生畏。对其进行保护甚至更为困难，经常需要采用全新的视角对其加以认识——甚至可能需要一组全新的安全人员进行相关工作。大部分安全团队在SOA方面甚至编程方面的培训极少。安全权威机构常用的方法是，只管发出要求并希望组织能够加以遵循。因此，第1步（这经常是最难的部分）是确保拥有正确的团队。

团队应该有个负责人，该负责人应该具有安全性和软件体系结构方面的知识，最好也能了解SOA的相关知识。与企业架构师类似，安全企业架构师（Security Enterprise Architect，SEA）将负责创建总体SOA安全模型，以便在每个粒度级别集成所有不同的安全性需求。SEA将进入SOA治理委员会，与企业架构师（Enterprise Architect，EA）一起确保所有 SOA 实现都符合安全性需求的相关要求，并对负责创建整个流程中所需的构件的安全业务分析人员（Security Business Analyst，SBA）和安全系统工程师（Security Systems Engineers， SSE）团队进行指导。SEA还将负责与编写安全性服务代码的程序员及在部署系统前对其进行测试的安全性系统测试人员合作。

第2步创建详细项目计划

对于大型SOA系统，第2步要求高层管理了解，将无法通过改进新的SOA将其纳入旧安全模型中：这样做根本行不通。如果从最开始的重点就是传统安全机制（如防火墙、入侵检测系统和安全监视），这将完全与SOA安全实现不沾边。您将负责通过制定详细的项目计划和预算，清楚地说明和反映SOA安全实现所必需的东西，确保每个人都对此心里有底。

您必需让大家认识到，到SOA模型的任何转换都会涉及到固有的安全矛盾：系统的SOA特征越明显，其安全性越差。通过面向服务的建模和分析技术将当前系统转换为SOA的过程要求形成业务设计的相关文档。通过使用可将业务设计与信息系统相关的正式语言，通常仅能说明矛盾、低效而复杂的非 SOA 系统的情况。不过，这个复杂性会掩盖住大部分问题所在，从而使寻找机会破坏企业系统的人难于找到这些脆弱的环节。对这些系统进行分解并启用SOA后，恶意用户所面对的体系结构就会简单一些，从而更便于进行破坏。

SOA支持者可能对此会加以否认，但负责保护系统安全的人知道，具有集中控制点且启用了Web的开放系统本身安全性就较差，而需要更为反应灵敏而灵活便利的方法。没有办法绕开这个问题，项目规划人员（经常会向SOA安全性方面分配一组适当的任务）必须记住，SOA安全性需要详细的项目规划和预算，为安全性团队分配必要的时间，以便分析和了解SOA实现所带来的新挑战。