站在云端的SaaS之云安全（下）

2012-09-10

中国建设信息化 2012年18期

致远软件研发中心技术总监吴玉民

（接上期）

安全实施方法论

安全领域内三个比较主流的实施方法论分别是：等级保护、ISMS和微软SDL。其中，等级保护是我国信息安全方面的标准规范，为国家级的大型软件系统定级和等保实施提供指导，涵盖了技术和非技术领域的安全措施和指导。ISMS是国际信息安全规范ISO 27001的实施体系规范，主要以风险驱动的方式进行信息系统安全建设。微软SDL是以软件工程的方式，针对软件开发生命周期各个阶段定义相应的安全方法和措施，对软件研发过程具有重要的指导意义。在SaaS系统的整个生命周期中，可以将这三种安全实施方法进行融合并结合使用。在SaaS软件开发阶段，采用微软SDL方法论进行产品研发；实施运维阶段采用等级保护实施方法论；在安全风险的处置方面，可以借鉴ISMS的体系规范。

微软SDL方法论

SDL全称Security Development Lifecycle，即安全开发生命周期，是微软公司为了实现比尔·盖茨(Bill Gates)在2002年写下的“Trustworthy Computing—可信计算”备忘录的目标，是微软全部产品经过多年实践积累的一套软件安全开发生命周期方法论，如图15-15所示。不同于等级保护和ISMS信息安全实施方法论，微软的SDL更侧重从软件工程的角度指导整个软件产品的安全开发过程，而不包含诸如系统运维管理等非技术安全方面的指导。

1.Pre SDL需求—— 培训

软件开发团队的所有成员都应该接受合适的针对性培训，以增加对安全基础知识和安全及隐私方面趋势的了解。软件开发团队的每个人都应该每年至少参加一次安全培训。安全培训能够帮助确认软件是在安全和隐私了然于胸的情况下被创造出来的，同时也能够帮助开发团队直面当前的安全问题。项目团队成员应该被鼓励去积极寻求更多的安全和隐私方面的教育机会。

图15-15 SDL过程

2.第1阶段—— 需求

SDL的需求阶段包含项目的启动阶段，当你在最基础的层面考虑安全和隐私以及成本分析问题时，需要考虑是否为符合业务需要而改进安全和隐私，并因此付出开发和支撑的成本。项目启动阶段在基本的层面考虑安全和隐私问题是系统开发的原则。建立可信软件的最好机会是在软件的初始计划阶段，因为开发团队能够结合安全和隐私识别关键目标，减少方案和计划失败的可能。主要工作内容如下：

● 确定是否在所研发的软件中采用SDL。

● 确定负责跟踪和管理软件研发过程中安全问题的团队或个人。

● 确定bug跟踪工具能够跟踪安全问题并且能够随时动态查找到所有安全问题。

● 定义并文档化项目的安全bug条。

成本分析在投入设计和实现之前，了解考虑数据隐私问题的成本和需求是很重要的。隐私风险会增加开发和支持的成本，所以改进安全和隐私需要和商业需求一并考虑。这里的主要工作内容如下：

● 完成风险评估

3.第2阶段—— 设计

设计阶段是构建如何贯穿SDL的剩余流程的计划，从实现到验证，再到发布。在设计阶段，通过功能和设计规范的方法建立要遵循最佳实践，并且进行风险分析以识别软件的威胁和弱点。

影响软件可信计算设计的最佳时间是在生命周期的早期。功能说明需要描述直接被暴露给用户的安全或隐私功能，比如在高风险隐私功能被使用之前，需要用户身份验证才能访问特定数据或用户许可。设计说明应该描述如何实现这些功能，以及如何实现所有的安全特性。安全特性是关于安全的工程化设计的功能性特征，比如在所有数据处理之前做严格的校验，或者强制使用加密API。当功能设计时，仔细并尽早考虑安全和隐私是很重要的，要避免在软件开发临近结束时再去加强安全和隐私。主要工作内容如下：

● 创建描述直接暴露给用户的安全功能的功能性说明。

● 设计说明应该描述如何实现这些功能，以及如何实现所有的安全特性。

风险分析，在软件研发的设计阶段，仔细检查(Review)安全和隐私需求以及期望，以识别安全问题和隐私风险。在设计阶段识别和设法解决这些问题和风险是更有效率的。对于安全方面的问题，威胁建模(Threat Modeling)是用来识别软件当中威胁和缺陷的系统化过程，如图15-16所示。必须在软件设计阶段完成威胁建模。只有真正了解需要保护的资产、软件的威胁和缺陷以及软件如何减轻这些威胁的细节，团队才可能构建出安全的软件。这里的主要工作内容如下：

● Review安全需求和期望以识别安全问题。

● 完成对成本分析阶段识别的功能进行威胁建模。

4.第3阶段—— 实现

图15-16 SaaS系统威胁树

实现阶段要牢记软件的最终用户是最重要的。在这个阶段，创建由用户使用的文档和工具是为了让用户了解并决策如何安全地部署软件。实现过程中，要在开发生命周期中建立开发最佳实践，以尽早检测并排除安全和隐私问题。创建文档和工具，每一个软件程序的发布都应该在它的默认配置和部署当中被设计为安全的。然而，人们的使用方式不同，并且不是每个人都使用默认配置。因此需要提供给用户足够的安全信息，让他们能够了解并决策如何安全地部署软件。因为安全和易用性是冲突的，所以有必要在决定如何部署和操作软件时，告知用户存在的风险以及需要在风险和功能之间权衡。在开发计划和功能说明稳定之前，很难讨论特定的安全文档需求。一旦架构趋于稳定，用户体验团队就可以完成安全文档计划和安排。提交关于如何安全地使用软件系统的文档，这和交付系统本身同样重要。主要工作内容如下：

● 定义安全最佳实践文档和工具。

建立并遵循开发最佳实践，在软件开发早期检测并排除安全问题，有利于建立、传达并遵循开发安全代码的有效实践。很多资源、工具和流程可以帮助达到这一目标。投入时间和精力来尽早运用有效实践，可以帮助消除安全问题，并且要避免在开发后期甚至在软件发布之后对这些问题进行响应，因为这将是代价昂贵的。主要工作内容如下：

● 建立、传达并遵循能够在软件开发过程中，尽早发现并排除安全问题的开发安全代码的有效实践。

5.第4阶段—— 验证

验证阶段的主要目的是确保开发的代码满足在上一阶段确定的安全和隐私原则。为达到这一目的，可以利用安全和隐私测试以及安全推动，这是全团队范围聚焦在威胁模型更新、代码Review、测试、全面的文档Review和编辑。公共发行的隐私Review也将在验证阶段完成。安全和隐私测试，在代码完成之后快速开始安全测试。需要在实现阶段之后进行一次全面的测试并获得通过，因为潜在的问题和缺陷可能会在代码开发期间发生改变。安全测试在SDL中是很重要的。设计师和说明书可以勾勒安全设计，开发人员可以勤奋地编写安全的代码，但是测试过程将最终决定产品在真实世界是否安全。这里的主要工作内容如下：

● 定义模糊测试、渗透和运行时测试。

确定对哪种文件格式做模糊测试。

确定对哪种网络接口做模糊测试。

确定采用什么工具做文件和网络接口的模糊测试。

● 重新评估攻击面。

● 重新评估威胁模型。

安全推动是全团队范围聚焦在威胁模型更新、代码Review、测试和全面的文档Review和编辑。安全推动不是对缺乏安全准则的补充，它是有组织性的努力，以发现在开发时可能产生的变化，改进任何遗留代码的安全，识别并处理任何遗留的缺陷。不管怎样，应该注意，仅仅凭借安全推动是不可能构建安全的软件的。安全推动在产品进入验证阶段之后(代码/功能完成)出现，通常在beta测试开始时启动。安全推动的结果可能改变产品的默认配置和行为，因此应该在安全推动完成以及所有的问题和需要的更改都解决之后，进行一次最终的beta测试复查。注意，安全推动的目标是发现缺陷，而不是修复它们。修复缺陷的时间应该是在完成安全推动之后。主要工作内容如下：

● 决定是否需要做安全推动。

● 定义安全推动的步骤。

确定安全推动的时间表。

确定是否需要在安全推动之前加强人员培养。

确定是否存在任何其他需要加强关注的任务。

定义安全缺陷如何被跟踪。

公共发行隐私Review 在任何公共发行(包括alpha和beta测试发布)之前，对于验证期间产生的任何重要的隐私变更，都要更新相应的SDL隐私调查表。重要变更包括改变许可的形式、提示语言的重大变更、收集不同的数据类型和呈现新的行为。隐私需求必须在任何代码的公共发行之前定稿，安全需求则不必。不管怎样，必须在最终发布之前完成最终安全Review。主要工作内容如下：

● 对于验证期间产生的任何重要的隐私变更，都要更新相应的SDL隐私调查表。

● 与隐私顾问和法定代表一同创建经过审批的隐私公告。

● 公共发行之前，在合适的网站发布隐私公告。

6.第5阶段—— 发布

发布阶段是软件已经准备好向公共消费者发行，更重要的是，整个团队已经为软件到了用户手中即将发生的事情做好了准备。发布阶段的核心是制订行动计划，决定任何的安全或隐私缺陷都是在发布中被公开，还是从响应执行的角度将其推迟到下一版实现。另外，需要在发布之前完成最终安全Review(Final Security Review，FSR)和隐私Review。任何软件都可能伴随着未知的安全或隐私问题而被发布，哪怕再多的努力和计划都是如此。甚至在有着未知缺陷的软件发布那一刻，才发现新的紧急并且需要采取行动的威胁。同样，隐私倡导者们也会在软件发布之后提出隐私问题。因此，必须在软件发布之前做好响应潜在安全和隐私事件的准备工作。通过合适的计划，能够应对一般商业操作中发生的很多事件。团队还必须准备应对软件安全突发事件。如果在软件发布之前制定了应急响应计划，在由于安全或隐私原因而需要应急响应时，将节省时间、金钱并降低影响。主要工作内容如下：

● 确定谁负责安全服务。

● 提供负责安全突发事件响应的联系人信息。

● 确保处理所有类型的安全问题的流程到位，比如代码重用或继承于其他团队和第三方授权的代码。

● 创建文档持续模型，跟踪记录为了响应安全缺陷而立即发布的补丁，而不是完全依赖于不常发布的服务补丁包。

最终安全Review和隐私Review 作为软件开发项目活动的结束，需要确信软件足够安全。FSR将帮助做出这项决定。应该由安全团队完成FSR，在产品团队的帮助下确保软件符合所有SDL需求和任何由安全团队识别的附加安全需求(比如渗透测试或附加模糊测试)。 FSR可能会持续几天到6个星期，依赖于问题的数量和团队做出必要修改的能力。仔细地安排FSR非常重要。在Review时要有足够的时间找出任何严重问题，还需要有足够的时间做深入的分析，不足的时间可能导致在FSR完成之后还需要做出重大改变。主要工作内容如下：

● 定义软件开发结束时间以开展FSR。

● Review威胁模型。

● Review在当前发布中被延期或拒绝的安全问题。

● 所有安全工具的验证结果。

● 为Review提交请求给安全顾问。

发布到制造工厂/网站软件发布到制造工厂(Release to Manufacturing，RTM)或网站(Release to Web，RTW)是SDL过程结束的条件。指派给本次发布的安全顾问必须证实软件团队已经满足了安全需求。与之相似，对于带有P1级隐私影响的组件的所有产品，隐私顾问必须在软件上市之前证实软件团队是否满足了隐私需求。

7.Post SDL需求—— 响应

安全服务和响应执行。软件发布之后，产品开发团队必须准备应对任何可能的安全缺陷或隐私问题。另外，需要完成响应计划，以应对潜在的软件发布之后的问题。

等级保护实施过程

等级保护的相关实施过程方法论，对于SaaS系统在安全方面的建设实施具有很好的借鉴和指导意义。等级保护的实施过程分为信息系统定级、总体安全规划、安全设计与实施、安全运行与维护以及信息系统终止5大阶段，如图15-17所示。

信息系统定级

信息系统定级阶段的目标是信息系统运营，使用单位按照国家有关管理规范和GB/T AAAA-AAAA，确定信息系统的安全保护等级。信息系统运营、使用单位有主管部门的，应当经主管部门审核批准。

总体安全规划

总体安全规划阶段的目标是，根据信息系统的划分情况、信息系统的定级情况、信息系统承载业务情况，通过分析明确信息系统安全需求，设计合理的、满足等级保护要求的总体安全方案，并制定出安全实施计划，以指导后续的信息系统安全建设工程实施。对于已运营(运行)的信息系统，需求分析应当首先分析判断信息系统的安全保护现状与等级保护要求之间的差距。

安全设计与实施

安全设计与实施阶段的目标是按照信息系统安全总体方案的要求，结合信息系统安全建设项目计划，分期、分步落实安全措施。

安全运行与维护

安全运行与维护是等级保护实施过程中确保信息系统正常运行的必要环节，涉及的内容较多，包括：安全运行与维护机构的建立，环境、资产、设备、介质的管理，网络、系统的管理，密码、密钥的管理，运行、变更的管理，安全状态监控和安全事件处置，安全审计和安全检查等内容。在等级保护实施指南中则重点关注运行管理和控制、变更管理和控制、安全状态监控、安全事件处置和应急预案、安全检查和持续改进以及监督检查等过程。

图15-17 等级保护实施过程

信息系统终止

本活动的目标是在信息系统终止处理过程中，对于可能会在另外的信息系统中使用的信息采取适当的方法，将其安全地转移或暂存到可以恢复的介质中，确保将来可以继续使用，同时采用安全的方法清除要终止的信息系统中的信息。

信息安全管理体系(ISMS)

信息安全管理体系(Information Security Management System，ISMS)使得组织能够系统地管理信息安全。通过ISMS实施，组织能够基于对每个独立问题的技术应对措施的自身风险评估，确定必要的安全级别，制订计划并发布信息资产。ISMS的主要理念就是，要妥善地维护和改进组织中应该被保护的信息资产的保密性、完整性和可用性。特别是，通过ISMS风险评估衡量控制实现的影响，组织能够以更加有效果和有效率的方式改进信息安全。信息安全的三个目标：

● 保密性—— 信息对未经授权的个人、实体或流程不可用或不被暴露的属性。

● 完整性—— 保障信息资产的准确和完整的特性。

● 可用性—— 信息可按授权实体的需要而被访问和使用。

PDCA模型

通过应用“Plan-Do-Check-Act(PDCA)”模型处理信息安全相关问题，可以按照期望管理信息安全并达到满意效果。利益相关者的信息安全需求和期望，能够在流程中作为输出被产生，同时这些需求和期望也将作为流程的输入。关键是通过应用PDCA模型，可以实现流程持续改进的效果，如图15-18所示。

表15-3 PDCA解释

ISMS实施框架

在ISMS实施框架中，分为如下3个阶段（参见图15-19）。

阶段1：确定ISMS的范围和策略（步骤1和步骤2），组织应该依据业务、组织、地理位置、资产和技术等方面特性，定义ISMS的范围和边界。然后定义ISMS策略，包括战略风险管理环境，ISMS建立和维护的组织环境，信息安全的总体方向和原则等方面内容。当定义ISMS策略时，组织应该着重考虑源于业务和法律的，或良好需求和风险评定的信息安全需求。阶段2：基于风险评估确定应对措施（步骤 3-步骤 7）。

图15-18 PDCA模型

图15-19 ISMS实施框架

基于ISMS的范围和策略，组织应该定义风险评估方式。然后，通过对可能引起需要保护的信息资产的保密性、完整性和可用性造成损失的威胁和缺陷的识别，以及对业务的潜在影响来识别风险。在风险评估过程中，应当根据由于安全问题造成和可能造成的商业损失的评估结果来估计风险级别。然后，利用风险可接受标准，确定风险是可接受的还是需要被处置的。假如风险不可接受，组织应当选择采取哪种风险处置方案以应对风险，比如应用应对措施、接受风险、规避风险或转移风险。根据风险处置决策，选择合适的控制目标和应对措施。有必要的话，还有可能采取更多的控制目标和应对措施。

阶段3：计划适当的处置风险（步骤8-步骤10），组织应该为达到既定控制目标和应对措施而提议的残余风险取得管理层批准，并且取得实施ISMS的管理层授权。最后，组织应该准备一份适用性声明，描述选定的控制目标、应对措施和选择或排除的原因。