Web安全讨论 敏捷开发需事先内置

　　云计算等新型应用模式的出现，促使更多的应用程序运行着互联网上，基于web应用程序可谓是随处可见。这无疑对应用程序的安全性是个巨大考验。敏捷(Agile)开发日渐流行，很多开发者都采用安全功能事后补充是这种开发方式，无疑为未来的应用程序埋下了安全隐患。安全性必须是应用程序开发方法当中一个不可或缺的部分，敏捷开发流程也不例外。

　　应用程序安全性已成为所有软件开发项目的一个关键部分。它包括在整个软件开发生命周期中采取的所有措施，旨在防止程序缺陷被人利用。在应用程序的需求征集、设计、开发、部署、升级或维护等阶段逐渐出现的众多缺陷成了网络攻击的基础。

　　由于应用程序缺乏固有的安全性，加上编程方法很糟糕，应用程序经常被黑客们钻空子，并且帮助导致了数据泄密及知识产权失窃引起的重大经济损失。这就是为什么安全性必须是应用程序开发方法当中一个不可或缺的部分，敏捷(Agile)开发流程也不例外。

　　据说敏捷开发流程早在2001年11月就问世了。近些年来，这种软件开发方法日渐流行。敏捷开发流程致力于把程序开发与客户需求和公司目标统一起来的迭代发现和开发。尽管如此，笔者还是发现，敏捷开发的基本特点往往决定了直到业务功能建成后才考虑安全问题。许多时候，安全不是事先添加到最初发布的功能中，因而使敏捷应用程序的安全功能成了事后扩充(bolted on)的，而不是事先内置(built in)的。

　　我在分析应用程序安全问题时，往往把它们分成两类：业务逻辑缺陷和技术安全漏洞。大家已认识到，安全必须事先内置到应用程序当中，而不是最后扩充上去。如果使用敏捷开发方法，这就带来了难题。这还引发了颇有意义的争论：敏捷开发是否适用于涉及敏感安全信息的应用程序?或者是否适用于为进入其他系统提供秘密通道(即后门)的应用程序?

　　与许多人一样，笔者也认为敏捷开发流程并不适用于对安全很敏感的应用软件。这主要是由于敏捷开发流程具有轻便、非正式、渐进式开发(build-as-you-go)的特性。安全功能必须事先内置，而不是事后扩充;因而，安全功能必须融入到整个敏捷开发流程当中。

　　项目动工之前就要开始考虑安全了。必须一开始就要制订安全策略和目标。之后及在项目定义步骤期间，必须制订及记录重要的安全需求和目标，并且告知开发团队。一旦我们奠定了这些安全基础，必须评估满足这些目标的必要条件。在范围界定和评估步骤，必须抽出时间来审查不断变化的需求，从而完善安全需求和目标。界定安全范围、估计所需工作量后，可以制订重要的安全计划。你在制订这些重要的安全计划时，必须明确安全协调活动，以便评估迭代开发工作过程中每个阶段的安全措施，并且确保这些措施已在考虑之中。现在基础打好了，我们就可以探讨在迭代开发周期(sprint，一般最多以30天为一个周期)内的安全。

　　迭代开发的首要步骤之一就是，为每个迭代开发周期确立一个主题，这个主题定义了这个开发阶段着重处理哪种类型的功能。明确了每个迭代开发周期的主题后，就要发现及记录预测的对安全带来的影响，可能还要在开发过程中建立桩模块(stub)。

　　借助建立桩模块这种方法，不需要先为完整功能编写代码，就可以开发应用程序的某些部分。现在有必要获取满足下面这个条件的与安全有关的场景和细节：它们要与某个迭代开发周期的迭代发现和开发过程中所定义的功能相一致。

　　发现了安全需求后，就必须作出这个决定：现在添加安全功能、为它们建立桩模块，还是推迟到以后的迭代开发周期来添加。两个方面确实影响了把安全添加到迭代开发周期当中的决定。其中对这个决定影响最大的就是，会不会部署及积极使用软件，以及会不会涉及安全风险和敏感信息。

　　如果软件要加以部署，就必须事先内置安全，并进行测试，这是迭代开发周期的一部分。不然，建立桩模块或推迟都是切实可行的选择。这时候，迭代开发开始了。软件开发好后，通常进行低层测试，还要演示，并让客户进行代码走查(code walkthrough)。这些测试用例和场景必须实际检验安全措施。话虽如此，实际检验这一步并不出现，这是我的个人经验。所有添加的与安全有关的功能和特性都必须进行实际检验和演示。测试和代码审查方面必须加大关注力度，尤其要注意竞态条件、跨站脚本、信息泄漏和SQL注入攻击。事实已证明，这四种编码问题都是Web应用程序当中最常见的软件漏洞。一旦完成了基本测试，就可以让软件进入到模拟的部署环境。

　　作为迭代开发周期一部分提供的软件安装到具有代表性的操作环境中。十有八九，开发环境与操作环境大不一样。这会导致软件操作问题和安全问题。这时就需要部署到模拟生产环境的环境中，那样才能解决这些问题。之前使用的所有测试用例和场景构成了回归测试(regression testing)的基础。自动化测试脚本重新运行，确认在新环境下能够正常操作。另外，建立新的测试脚本和场景，以便从头到尾全面检验软件;还要进行检查及测试，查找有无软件漏洞。一旦所有这些测试都成功通过，软件可以进入到下一个阶段：客户验收阶段。

　　在这个阶段，作为一个或若干迭代开发周期的一部分提供的软件进行演示、评估和验证，最终由商业客户决定验收或拒收。这一步必须包括对安全进行检查。正如客户有商业验收标准，他们也应当制订安全验证标准。尽管这看似过于绝对化，其实不是这样。有条件验收是普遍惯例。要是某个地方出现了变化，项目发起人往往只接收某个迭代开发周期的交付成果。如果确认了验收条件，就要安排时间进行返工。一旦安排了时间，满足验收条件所需的返工就必须完成。一旦返工完成，并通过测试，就要审查返工部分，并向商业客户进行演示，确保符合有条件验证的目的。

　　获得汲取的教训是指收集、记录及分析迭代开发期间所收到反馈的过程。这项工作很关键，那样随后的迭代开发周期就能从中获益。这项工作很关键的理由还在于，获得安全方面汲取的教训让团队成员有机会反省迭代开发周期过程中导致安全缺陷的任务、事件和活动。另外，获得汲取的教训需要回过头去分析一下风险管理工具，并记录优点和不足。

　　迄今为止开发出来的所有软件必须整合起来加以验证。一旦完成了这项工作，就必须加以验证，以确保功能正常。短期内还需要监测及跟踪，确保所有软件和系统组件能协同顺畅运行，没有带来安全漏洞。要站在安全的角度，测试系统之间的相互关系。必须在这个步骤创建及运用新的安全测试场景。

　　此外，如前所述，测试和代码审查方面必须加大关注力度，尤其要注意跨站脚本、信息泄漏和SQL注入攻击。一旦各方面可以协同顺畅运行、而且安全，就可以准备发布到生产环境了。软件发布管理(RM)是所有软件开发方法和项目当中比较新的一部分。RM充当所有业务部门和IT部门之间的连接纽带，可以保障顺利过渡至新系统。最后，是时候进入到下一个迭代开发周期了。收尾步骤表明某个迭代开发周期正式收工。另外，这个步骤带来了项目工件(artifact)，确保为代码编写了相应文档，并对代码作了备份和归档。这一步常常需要改变公司所部署的安全监控流程和功能。

　　安全行业把可怕事件频发的2008年称为“数据丢失年”，这是由于这一年发生了多起敏感信息安全泄密事件。美国国家情报总监Dennis C. Blair在国会听证会中声称，去年全球各地的众多公司因数据窃取而丢失的知识产权价值超过1万亿美元。软件漏洞是最主要的根源之一。这应该向从事应用程序开发的每个人敲响了警钟，不管他采用什么方法来开发;这还向敏捷开发项目发出了预警信号：它们需要确保事先加入而不是事后扩充了合理的安全功能。