【IT168 专稿】
    在很多国家，当新的行政区被确定的时候，都需要建立一套管理规定并任命一个人来执行这些规则，这个人可以立即被人们所认可并且建立起毫无疑问的权威。消费者正面临的Web 2.0应用程序正在迅速进入企业中，随之而来的还有必须解决的安全问题，就如同新的居民点需要它们自己的安全措施一样。

   Web 2.0技术推动了那些协作网站的发展，使用户可以参与其中并进行信息的共享。由于诸如AJAX（异步JavaScript与XML）和JSON（JavaScript对象标志）等技术的存在，Web 2.0应用程序具有交互性和吸引用户关注的特点。

    越来越多的企业正在积极的将Web 2.0技术应用到新的或现有应用程序中，以更好的服务它们的员工、合作伙伴和客户。其例子包括创建社区应用和论坛，以让客户参与到产品评价和评论中，并反馈自己的意见。部署这些应用程序的企业需要进行安全方面的加强，以避免这些关键的信息不会被恶意入侵者修改或被竞争对手截获。这些公司需要一个新的管理者来监视它们的关键信息。

   事实上，随着Web 2.0技术在企业中的采用，应用程序在设计时有很多问题必须要进行考虑，不仅仅要解决和其他企业级产品具有同样的标准、安全问题和体系架构问题，还要考虑专门针对Web 2.0技术的安全问题进行思考。

使用具有一致安全模型的富用户界面框架

    对于早期运送货物的马车来说，车匪路霸给它们带来了很大的忧虑，严重威胁了它们正常的货物运送。因此，它们雇用了护送队来和马车同行，以免意外发生。

    在消费者领域，企业Web 2.0应用程序与它们的竞争应用程序使用了相同的富用户界面技术。通过使用诸如AJAX之类的技术，开发者可以通过借助于XMLHttpRequest API（应用程序编程接口）来请求一个网址，而不用重新刷新浏览器页面，从而可以创建一个富用户界面体验。如此高度动态的应用程序比传统的Web应用程序具有更大的安全风险，因为传统Web应用程序对表现层和后端服务器之间的交互进行了一定程度的控制。但是，这些新的Web 2.0应用程序依然需要确保没有不请自来的“车匪路霸”攻击被注入。同样情况，使用诸如JSON技术创建的应用程序容易被JSON劫持所威胁，基于跨站点请求伪装的技术可以允许一个恶意服务来截取数据。在一个很多功能被嵌入在表现层的应用程序中，通常情况下，设计者对客户端进行安全检查，而没有在服务器端进行更多的访问控制检查。

把安全保障推送到服务层

    在很多国家，较高级的本地法律执行机构通常被认为是安全管理者或最高安全管理者。它通常负责它所掌管的地区的法律的强制执行。如果有任何人不能遵守这些法律，他们将会被迅速的逮捕并被制裁。

    通常情况下，企业应用程序从Web 2.0服务的增加中受益匪浅。举个例子来说，为了解决一个帮助支持系统，客户服务代表可以使用一个Web 2.0风格的应用程序来创建一个临时的社区，并邀请必要的参与者来进行合作并解决这个问题。这种社区可是使用群体性服务，包括讨论性的论坛和Wiki等，参与者可以分享想法并提出反馈意见；还有可以支持共享和发布文档的内容服务；帮助分类、共享和发现信息的标记服务。和管理者相似的是，每一个服务应该负责对其暴露的资源和信息进行保护。因此，安全工作要在每一个不同的服务层来进行，这是非常重要的。

    建议开发者在服务器端利用框架来帮助创建和配置它们暴露的服务和内容，从而提供一个服务器端组件来担任不同服务的代理。把策略执行放在服务器端，可以让用户界面开发者从在表现层进行认证的工作中解放出来，而且，更重要的是，让开发者可以使用不同的服务器端框架来进行安全执行。


使用WS-Security来执行消息级别的安全

    在美国两个州之间的边界上，经常会发生一个管理者认为另一个警长会负起管理责任的情况。为了拥有一个总的管理者，会安排一个地区联合管理者。它的责任是确保在国家内所有的州之间实行一致的安全管理。

    Web 2.0企业应用程序一般使用应用程序编程接口（API）或Web服务接口来与合作伙伴或企业内的其他应用程序服务来进行交互。这些可能传送机密数据的Web服务易于遭受到诸如参数操纵之类的攻击，在这种攻击中，在SOAP消息中的参数被利用来注入SQL、XPath（XML路径语言）和shell 脚本等。因此，确保在消费应用程序和服务之间流动的消息不被做手脚是非常重要的。使用安全套接字SSL的传输级别的安全和使用Web服务安全协议WS-Security的消息级别的安全都是必须需要的。XML加密也必须被用来维护数据一致性，而服务的真实性和完整性也应该使用XML签名来保证。企业应用程序应该确保这种类型的令牌文件被服务所支持，并将其封装作为SOAP头的一部分，这些令牌文件包括具有可选密码摘要的用户名、安全应用标记语言SAML令牌和其他内容。基于WS-Trust的解决方案可以被应用在合作伙伴之间必须达成信任的地方。开发者可以使用特定的框架来作为策略执行点的代理，它可以在不影响服务逻辑的情况下执行入站和出站的Web服务调用。诸如此类的框架可以提供一个分散的平台来配置跨服务的策略，并前瞻性的管理被应用程序所使用的服务。

管理跨应用程序和服务的角色和身份

    对于所有不同的法律执行机构来说，很明显都需要一个标准的方式来识别不同的个体。这样，一个徽章或一个星和一个相对的权限级别变得非常有必要，来确保每一个相关的人可以互相了解对方的角色。 

   根据企业中用户角色的不同，基于角色进行访问控制的RBAC模型可以被用来保护具有特殊权限的资源。因为它减少了安全规定的复杂度和成本，RBAC已经是当今企业中应用最普遍的许可模型。使用RBAC保护的资源大多数情况下由企业应用程序的管理员来创建和管理。但是，企业应用还必须处理这个访问控制模型，并执行不同的多人参与的服务。这些服务的角色和策略定义可能与不同的计划保持一致，并与那些企业应用程序有所区别。举个例子来说，如果一个企业应用程序使用一个提供内容管理功能的服务，一个具有在应用程序“查看”角色的用户将在内容管理后端具有“读者”角色。执行者因此将需要创建一个新的许可模型，来映射应用程序角色到服务角色上，那么任何在应用程序中被授予“查看者”角色的用户将相应的授予内容管理系统中的“读者”角色。因此，需要在应用程序和多人参与的服务之间建立一个合约（SPI/API），以推动这种新的许可模型，这样用户具有所有需要的访问控制权限来以一种一致的方式来使用应用程序，就如同在新的国家被建立后需要选举新的警长。

    Web 2.0应用程序所使用的服务的分布式的特点使其对现有的身份管理解决方案具有更进一步的要求。一个服务可以拥有自己的身份管理仓库，并使用一个与前端引用程序完全不同的认证模型。在应用程序身份库和服务的后端身份库中，用户可以具有不同的身份和证书。身份证书需要使用安全证书库来进行映射，或者身份应当使用WS-Security令牌文件进行再证实，以免服务暴露Web服务的接口。

使用分散授权

    对于任何一个行政辖区来说，通常有太多的人需要管理。因此，管理者必须提名一个代表来作为执行的角色。

    由于大多数基于Web 2.0的应用程序是需要合作的，并需要围绕用户产生的内容循环，访问控制经常基于用户档案的属性而不只是用户角色，就变得非常重要。授权检查还应该考虑发出访问一个资源请求的前后关系。这样的认证计划可以帮助管理员在一个更细化的级别来管理特权操作，诸如从wiki中删除一个项目页面。

总结

    企业员工已经开始询问，为什么通过互联网可以更容易的完成任何和问题的协作，但是在工作车间却不能。对此，企业开始将协作性的Web 2.0功能引入到企业应用程序中。随着越来越多的公司增加这类服务和技术到新的和现有的应用程序中，就需要一个新的“管理者”来确保信息不会被现代版的“车费路霸”和黑客所损坏。使用本篇文章中的一些非常好的实践经验，将有助于确保这些增强的Web 2.0功能的成功使用和部署。