正如我在之前的文章中所讨论的那样，应用程序安全专业知识是PaaS安全性的关键之所在。对于使用PaaS环境的企业来说，投资于教育与软件开发生命周期过程是极其重要的。但是，总的来说企业在应用程序安全方面的投资一直是缓慢的。

　　因此，对于PaaS环境的安全专业人士来说，挑战如下：虽然已为应用程序安全性投入大量资金，但是哪一种短期措施可作为PaaS安全性的权宜之计?例如，在Azure的支持下，微软公司的无数以开发为重点的安全资源发挥了巨大效应，但如果应用程序已经编写完成，那又该如何呢?可能未必有时间将SDL或威胁模型纳入特定的应用程序。

　　处于该位置的公司应当知道的有两件事：首先，Azure环境本身提供了一些非常强大的安全功能，以保护相关应用程序，这些功能包括诸如网络级控制、物理安全、托管强化等措施。但是这些保护只完成了一半的任务;无论做好了如何完备的保护，任何环境仍然可能因为未解决的应用程序而受到攻击。幸运的是，一旦所开发的程序在应用程序层增加了一些保护措施，那么就有一些我们可以依赖的功能。

　　这些权宜之计并不是唯一适用的应用程序安全措施——它们不包括你应该做的事(如SSL)，他们并不是普遍适用于每一个用例。但是，这些微软公司的Azure安全功能并不能帮助安全专家了解更多信息，因为他们可相对快速实施，要求尽可能少的代码更改，并可多次复用于现有应用程序而无需大量的业务逻辑复检。

　　Microsoft公司Azure安全：部分信任

　　Windows Azure可能会作为非管理员用户在本地操作系统上通过运行用户供应代码来提供某种针对颠覆应用程序攻击的隔离措施(从调用者的角度来看，这几乎是完全透明的)。但是，企业组织可以通过采用“部分信任”而非“完全信任”以便于进一步限制对某个角色的访问权限。

　　那些熟悉传统.NET上下文安全模式的人会认出这一概念，但是这个想法也通过限制应用程序本身功能而限制应用程序本身中安全故障所造成的影响。如同一些网络服务器和应用程序使用一个“受限”文件系统或受限权限模式一样，部分信任的概念也与之类似。微软公司提供了部分信任下的完整功能列表，以及如何在Visual Studio中启用该功能的说明。

　　但有一个需要注意的地方。虽然使用部分信任是从事小型应用程序/服务的一条康庄大道，但是大型或复制应用程序/服务(例如从一个现有.NET应用程序的直接端口)可能需要完全信任的权限以实现正常功能。

　　Microsoft公司Azure安全：AntiXSS

　　在应用程序上下文(更确切地说，是一个网络应用程序上下文)中发生的众多问题都源于恶意输入;换而言之，用户提供的输入是一种常见的攻击途径，除非输入受到限制或作为应用程序处理的一部分进行验证才会免除这个可能性。这并不容易实现;一般而言，需要花费相当的努力(和培训)以获知开发人员的业务逻辑从而明白应当过滤什么，为什么要过滤以及如何测试过滤措施是全面有效的。

　　正因为如此，微软公司免费提供了网络保护库(WPL)以提供一个输入验证封装库，以便于开发人员使用来解决部分类似问题。WPL中的AntiXSS库提供了相关功能，以便于开发人员可以集成编码用户输入，从而减少恶意攻击颠覆输入域从而对应用程序行为造成负面影响的可能性。

　　Microsoft公司Azure安全：使用诊断

　　能够防止攻击的下一个有效措施在于有办法知道它是否发生。在传统内部应用程序部署场景中，安全专业人士可以实施强化记录和检测控制措施以应对应用程序级安全风险。同样的策略也可应用于Azure。具体来说，可配置Azure的诊断功能以提供额外的安全相关信息，即不仅仅是仪器已经存在于应用程序本身。IIS日志、基础设施日志以及其他日志记录可以是一种留意应用程序的方法，即一旦运行就无需进行工作量巨大的规划、编码以及重新测试。

　　显而易见，这些措施不是针对PaaS安全问题的全面答案。理想情况下，该组织的目的是一个长期、复杂、以生命周期为重点的方法学，其中包括通过SDLC和流程变更事项应用程序安全性。但在短期内，当很难实现代码改变和难以立即上马时，这些简单易行的步骤可能会帮上忙。