宜信SDL实践：产品经理如何驱动产品安全建设

一、序言

本文从产品经理的角度出发，对产品经理的安全职责、产品驱动安全的内涵、工作内容、工作方法、所需安全资源、以及产品经理的安全工作量进行了分析。希望所有产品经理在没有心理负担的情况下，有目标、有方法、有资源推进产品安全建设。

二、背景

安全是软件产品天然属性的一部分，“无安全不金融”，对于金融软件产品而言，安全尤为重要，因为客户总是能够从各种安全漏洞联想到他的金融资产安全和个人信息安全。以前偶尔会在一些安全沙龙或峰会听见同行吐槽，“信息安全说起来重要、做起来次要、忙起来不要”。吐槽背后的原因很复杂，其中很重要的一点是跟产品经理安全意识淡薄、不清楚如何推进产品安全建设有关，比如不重视产品安全属性、产品安全需求不明确、产品安全资源不充分、产品安全建设无从下手等。本文主要站在产品经理的角度，从产品经理能力维度出发，探讨产品经理如何推动产品的安全性建设。

众所周知，安全性作为软件产品的天然属性，从产品定义与规划角度来看，产品经理对产品安全负有不可推卸的责任，但产品经理如何履行自己的安全职责，业界还没有给出一个清晰可行的行动方案。

目前，软件产品安全需求通常是基于开发人员和安全人员的职业常识提出相应的解决方案，比如目前业内比较通用的敏感信息五要素分析方法：

这种方法简单易行，但往往不能涵盖所有的敏感信息，比如

• 用户的多系统用户数据关联ID（超级ID）。
• 交易过程中的音视频等多媒体数据。
• 各种非结构化的文档数据，如合同扫描件。
• 用户的行为画像数据等内容。

这些信息均为有价值的敏感数据，显然不属于前述的敏感数据范围，但往往没有明确的防护要求。从特定业务场景出发，产品经理对敏感数据范围及其业务价值最有发言权。

三、安全部门的尴尬

前述的敏感信息五要素分析方法是典型的安全驱动产品的方法，即安全部门推动产品相关各团队的安全工作开展。这种模式存在很多弊端，比如：

• 安全需求可能不完整，职业常识代替不了特定业务场景的深度分析；
• 产品各团队的安全工作资源无法保证，研发团队有理由认为安全团队干扰研发计划，研发进度与资源不变的情况下，额外增加了工作量；
• 安全部门通常没机会参与制订研发计划，产品研发计划与安全脱节；
• 安全团队高度依赖话语权，强制性驱动往往陷入窘境。

（图1 安全驱动产品）

众多的安全实践表明，安全驱动产品的思路与方法存在众多弊端，如果反过来，产品驱动安全，让产品经理明晰自己的安全职责、主动推动产品的安全建设，就会产生对比鲜明的效果。

四、产品驱动安全的合理性

产品驱动安全并非意味着产品经理单一角色推动产品的安全建设，而是说产品经理主动承担相应的产品安全责任，主动与安全部门一起推动产品的安全建设，由安全驱动产品的单轮驱动转变为产品驱动安全的双轮驱动。如下图所示：

（图2 产品驱动安全）

安全是软件产品的天然属性，是产品经理职责的一部分。同时产品经理作为产品规划演进与研发资源投入的指挥棒，可以保证研发团队在安全上的适度投入。通过简单分析，产品经理承担产品安全责任，主动推动产品安全建设应该是十分合理的逻辑。

五、产品如何驱动安全

产品经理有意愿做好产品安全，可能会问如下几个问题：

• 内容方面，产品经理需要做哪些安全工作；
• 能力方面，为了完成这些工作，产品经理需要具备什么样的安全能力；
• 方法方面，这些安全工作如何做，才能既兼顾产品业务功能研发与安全，又能保持研发敏捷性和项目管理流程不变形；
• 安全资源，从安全部门和其他部门可以获取哪些安全支持，来提升自己和研发团队安全工作的效率和效果，降低安全工作的能力门槛；
• 工作负担，安全工作会不会让产品经理很辛苦，影响其工作品质和生活品质。

为产品经理解决了以上问题，消除其后顾之忧，产品经理才有可能大概率地拥抱安全，从根本上解决研发与安全间的矛盾。

六、产品经理的安全工作内容

产品经理的安全工作内容大致如下：

• 明确产品安全需求；
• 保障安全研发资源，将安全工作设定到研发计划中，并分拨足够的安全研发资源；
• 推动研发团队安全能力建设，确保研发计划中的安全工作执行到位;
• 整合周边安全资源，确保研发计划中的安全工作执行到位。

（图3 产品经理的安全工作内容）

6.1 明确产品安全需求

产品安全需求是指站在业务角度，软件产品需要满足的数据安全需求、业务合规需求和业务连续性要求，它是业务安全需求的一部分。本文描述的产品安全需求通常包括：

• 产品承载的业务数据安全防护需求，主要关注点是业务数据的机密性和完整性。
• 产品相关信息的安全监管要求，如等级保护、行业信息安全监管等要求。
• 产品承载的业务连续性要求。由于通常由数据中心或运维部门统一牵头实施该项任务，本文将不会展开描述该项内容。

（图4 产品安全需求）

6.2 产品数据安全需求

产品数据安全需求是指系统安全体系应确保恰当的用户在恰当的时间与地点以恰当的途径用恰当的动作访问恰当的数据，确保其承载数据的机密性、完整性和可用性。即系统安全体系应确保类似于白名单的合法访问行为清单，只要属于清单范围内的行为均为合法行为，白名单行为之外的行为都是默认不恰当的数据访问行为，需要安全措施进行预防，本文称之为黑名单行为。

由于黑名单行为通常为黑客攻击行为，其典型行为的分析与罗列需要较强的攻防技术背景，不在业务人员和产品经理能力范围之内，需要安全专家根据产品运行环境进行分析，所以本文要求产品经理明确的产品安全需求通常为其白名单部分，黑名单部分需要产品经理组织安全专家和研发专家配合明确。产品设计所包含的各种安全措施主要目标就是确保白名单行为一定成功，黑名单行为一定被预防、监控和审计。

从业务安全角度出发，定义合法数据访问行为之后，还需要有数据访问行为审计手段，帮助业务确保访问行为的正确性，以及对违规的数据访问行为进行审计。

（图5 产品数据安全需求）

基于上文分析，白名单行为清单的明确只需要了解业务模型相关信息就可以做到，对于产品经理而言，不存在能力上的门槛。过程中产品经理需要明确的数据包括：

在明确上述信息的过程中，产品经理应遵循如下两个原则：

设计人员可以根据该白名单进行权限管理与访问控制模型设计，测试人员可以将白名单作为数据安全测试基线，任何违背白名单的测试发现均为系统的安全bug，比如：

• 敏感数据未脱敏。
• 多余的数据操作权限。
• 横向或纵向数据访问越权。
• 关键行为的日志痕迹缺失。

6.3 合规性需求

合规性需求是指由于系统运行地点、服务网络以及客户所在地区或国家相关部门，对服务提供模式、数据安全以及业务连续性提出了限制性要求。目前公司系统所面对的主要监管要求包括：

2019年国家相关部门提出了一系列App收集个人信息相关监管要求：

在产品经理罗列出合规要求、安全部得到相关部门的权威解释后，与产品线沟通建议各种安全措施设计，将会在很大程度上满足IT安全合规要求。等级保护相关要求为所有系统需要面对的共通要求，无需产品经理罗列，安全部可以直接解释。

关于具体安全需求的定义与维护方法，笔者将通过其他文章进行说明。

七、产品经理安全能力分析与建设

分析产品经理的安全工作内容，最主要的考验来自于明确业务安全需求的四个清单。相关安全能力分析如下表：

产品经理其他安全开发工作所需能力分析如下：

综上所述，产品经理要履行相关安全职责，必要的能力和素质是具有较高安全意识，能够理解相关安全基础概念，没有过高的能力门槛，通过一定的安全培训，产品经理完全可以达到相应的能力要求。

八、产品安全研发方法

针对目前敏捷开发与DevOps开发普遍落地的情况，安全开发不应固守与瀑布开发相结合的陈旧经验。因为瀑布开发周期长、资源充分，在繁杂的计划活动中安排一些零星的安全活动不会产生明显的延期压力和资源压力。而敏捷开发和DevOps开发要求快速响应用户需求的同时，兼顾开发质量与效率，如果在迭代计划中设置过重的安全开发活动，迭代开发容易失去敏捷特性。

为了将安全开发理念在敏捷与DevOps开发中得到贯彻，建议采用如下原则：

• 安全开发活动轻量化。轻量化可以通过工具化、自动化来实现，尽量减少人工耗费大和耗时长的安全开发活动；
• 安全开发活动分散化。将那些短期无法轻量化处理的安全开发活动分解并分散到多个迭代周期中执行；
• 安全开发活动并行化。将安全开发相关活动与其他活动并行，如渗透测试通常安排在测试的最后一个环节，避免单轮次渗透测试无法覆盖那些并行的修复点，当然渗透测试也可以由多个轮次来弥补这种情况，但通常资源不允许。实际上这种同步修复导致渗透测试覆盖率下降的问题，完全可以通过良好的沟通和团队文化建设进行弥补。
• 优化现有敏捷开发与DevOps相关的流程与工具平台，使得安全专家能够充分参与项目，提升安全开发沟通效率，快速获取安全反馈；
• 将安全专家纳入到敏捷开发和DevOps文化建设中来，信息安全人人有责，安全专家可以充分发挥教练员角色和守门员角色，使得团队人人有能力履行自己的安全职责，安全专家在恰当的时机对安全交付物进行质量把控；
• 提前进行安全基础设施规划与布局，如身份与权限管理系统、SSO系统、加解密平台与SDK、日志分析与监控平台、全流量检测平台等等，使得安全措施标准化、服务化和平台化，降低安全设计与编码的能力门槛，对安全基础设施的测试与验证取代设施所承载应用的大部分安全测试，可以有效消减安全测试工作量。

对于一些安全开发活动的计划安排示例如下：

上表中“多迭代执行”指的是按照一定要求，间隔多个迭代后执行一次。关于多迭代执行的安全活动需要制订一个执行基线，该基线无标准可参考，需要根据各产品线实际情况逐渐摸索调整。

安全活动的触发场景与基线不是固定的，随着团队安全能力与自动化、工具化程度的提高，多迭代执行的安全活动可能转变为每迭代执行；不是所有识别出来的安全活动都必须执行，一切以控制主要安全风险、不拖迭代项目后腿为基准。通常安全团队会与所有产品经理和项目管理进行多次沟通，提出一个多方基本认可的安全活动触发场景与基线表，供产品经理参考。

九、产品经理获取安全资源支持

产品经理在履行各项安全职责时，需要周边部门提供的安全服务与支持包括但不限于：

十、产品经理安全工作压力分析

产品经理安全工作压力分析如下表：

上表描述了产品经理可能会遇到的主要工作内容，但并不是全部内容。整体而言，会增加产品经理一定的工作量，但不会构成明显的工作压力。

十一、小结

产品经理对产品安全负有责任，通过明确产品安全需求中的白名单指明产品安全目标，通过制订安全研发计划、推动团队安全能力建设和协调周边安全资源，实现产品安全落地。

经过简短安全培训后，相关工作均在产品经理能力范畴，工作量不会对产品经理形成心理压力，灵活的安全活动触发标准也不会影响研发的敏捷性。笔者在这里衷心期望各位产品经理放心大胆、勇往直前地拥抱安全，和安全部一起不断地将产品安全推向新高潮。

十二、感悟

在笔者的工作经历中，安全部门为了推动安全工作，总是想着法地“抱大腿”，期望借助外力以推动安全工作，却没有注意到产品经理这个“大腿”，只需觉醒其安全意识，这一“大腿”不仅粗壮有力，而且有着主动拥抱安全的强烈动因。

安全部与产品经理合作，很容易建立基于迭代开发的常态化安全落地机制，而与其他部门合作，例如合规或法务，常常只在特定阶段推动特定安全工作的落地。建议各位应用安全同行和产品经理多多交流，因为：产品经理才是我们安全部最需要拥抱的“大腿”！

作者：危国洪 郭建伟

来源：宜信技术学院