当谈及安全性和云(如阿里云)计算模型的时候，平台即服务(PaaS)有着它自己特殊的挑战。与其他的云(如阿里云)计算模型不同，PaaS安全性所要求的应用程序安全性专业知识往往是大多数公司无法投入巨资就能够拥有的。这个问题很复杂，因为众多公司都使用“进驻式”基础设施级安全控制战略作为应用程序级安全性风险的应对措施(例如，一旦应用程序代码发布生产，使用WAF以缓解所发现的跨网站脚本程序或者其他前端问题)。因为缺乏对PaaS中底层基础设施的控制，这一战略在PaaS部署应用中变得不具实际操作性。

　　考虑到PaaS与控制相关的灵活性，你必须对底层计算环境具有一定的控制能力。如同IaaS一样，PaaS提供了近乎无限的设计灵活性：你可基于社交网站构建任何应用，来实现内联网网站或CRM应用程序。但是，与IaaS不同的是，应用程序下的“堆栈”是不透明的，这就意味着支持应用程序的组件和基础设施都是(根据设计)一个“黑盒”。也就是说，与SaaS类似，安全性控制必须内置于应用程序本身中;但与SaaS中服务供应商通常实施应用于所有客户的应用程序级安全控制不同的是，在IaaS中安全控制措施是针对你的应用程序的。这就意味着必须由你自己承担责任以确定那些控制措施是合适的并执行具体的实施。

　　这里的一个简单图示，表明了模型与客户之间的差异：

　　应用程序设计灵活性

　　功能控制比

　　底层透明度

　　对于那些在应用程序安全方面已投入巨资的组织来说，他们拥有固定满编训练有素的开发人员，独立的开发、测试以及生产流程，所以应对PaaS安全性问题应该是驾轻就熟的。而那些还未作出这些投资的机构可以遵循如下步骤，从而在一定程度上有助于应对PaaS安全性的挑战。

　　步骤一：建立安全措施

　　应用程序安全性的根本挑战远在PaaS实施前就已存在。因此，对于怎样完善生产安全、鲁棒的应用程序的部署措施已有相当的研究。有一个可提供直接支持的技术被称为应用程序威胁建模。一些很好的着力点是OWASP威胁建模页以及微软公司的安全性开发生命周期资源页。从工具的角度来看，是免费跨网站脚本(XSS)和SQL注入。拥有内部工具的企业可将其应用于PaaS的安全性措施，或众多PaaS供应商为客户以免费或者打折的价格提供了具有类似功能的工具。而当企业希望使用一个更为广泛的扫描策略的时候，他们还可使用诸如Google公司的skipfish这样的免费工具。

　　步骤二：扫描网络应用程序

　　众多公司已经接受了应用程序扫描，这是一个用于解决通用安全问题(例如跨平台脚本(XSS)和SQL导入)的网络应用程序扫描工具。拥有内部工具的企业可将其应用于PaaS安全性措施，或众多PaaS供应商为客户以免费或者打折的价格提供了类似功能的工具。而当企业希望使用一个更为广泛的扫描策略的时候，他们还可使用诸如Google公司的skipfish这样的免费工具。

　　步骤三：培训开发人员

　　应用程序开发人员完全通盘精通应用程序安全性原则是非常关键的。这可包括语言级培训(即他们目前用于构建应用程序所使用语言中的安全编码原则)及更广泛的议题，如安全性设计原则等。因为开发人员的减员和流动性等原因，这往往要求培训必须定期重复并作为常态保持下去，所以开发人员应用程序的安全性培训成本可能是较为昂贵的。幸运的是，还有一些免费的资源，例如Texas A&M/FEMA国内防备校园计划提供了一些安全性软件开发的免费电子学习资料。微软公司也通过其Clinic 2806提供了免费培训：微软开发人员安全性知道培训，这是一个开始你自己定制程序有用的入门级培训材料。

　　步骤四：拥有专用的测试数据

　　这样的情况总是在不断发生中的：开发人员使用生产数据进行测试。这是一个需要正确认识的问题，因为机密数据(例如客户私人可辨识的数据)可能在测试过程中泄漏，特别是在开发或试运行环境中并没有执行与生产环境相同的安全措施的时候。PaaS的环境敏感性更甚，而众多PaaS服务更易于实现部署、试运行以及生产之间的数据库共享以简化部署。如开源Databene Benerator之类的工具可产生符合你数据库特定结构的高容量数据，而数据格式调整有助于拥有专用的生产数据。通常，这些处理是属于特定框架的，因此你需留意找出一个能够在你的特定环境中正常工作的。

　　步骤五：重新调整优先级

　　这最后一个步骤是你可实施的最重要的一个步骤。既然PaaS可能意味着一种文化和优先级的调整，那么相应地接受这一调整并将其真正纳入自己的思想行为体系中。使用PaaS，所有都是与应用程序相关;这意味着组织的安全性将高度依赖于组织中的开发团队。若这不是PaaS的问题，那么这将会是一场噩梦了，因为在基础设施级你无法实施多少措施以缓解已识别的风险。若你一直以来都是依赖于基础设施级的控制以满足在应用程序级的安全挑战，现在是时候重新考虑。