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

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

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

• 明确产品安全需求；

• 保障安全研发资源，将安全工作设定到研发计划中，并分拨足够的安全研发资源；

• 推动研发团队安全能力建设，确保研发计划中的安全工作执行到位;

• 整合周边安全资源，确保研发计划中的安全工作执行到位。

1575863913345098425.png

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

6.1 明确产品安全需求

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

• 产品承载的业务数据安全防护需求，主要关注点是业务数据的机密性和完整性。

• 产品相关信息的安全监管要求，如等级保护、行业信息安全监管等要求。

• 产品承载的业务连续性要求。由于通常由数据中心或运维部门统一牵头实施该项任务，本文将不会展开描述该项内容。

1575863920106084742.png

（图四 产品安全需求）

6.2 产品数据安全需求

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

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

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

1575863929433019591.png

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

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

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

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

• 敏感数据未脱敏。

• 多余的数据操作权限。

• 横向或纵向数据访问越权。

• 关键行为的日志痕迹缺失。

6.3 合规性需求

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

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

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

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

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

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

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

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

八、产品安全研发方法

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

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

• 安全开发活动轻量化。轻量化可以通过工具化、自动化来实现，尽量减少人工耗费大和耗时长的安全开发活动；

• 安全开发活动分散化。将那些短期无法轻量化处理的安全开发活动分解并分散到多个迭代周期中执行；

• 安全开发活动并行化。将安全开发相关活动与其他活动并行，如渗透测试通常安排在测试的最后一个环节，避免单轮次渗透测试无法覆盖那些并行的修复点，当然渗透测试也可以由多个轮次来弥补这种情况，但通常资源不允许。实际上这种同步修复导致渗透测试覆盖率下降的问题，完全可以通过良好的沟通和团队文化建设进行弥补。

• 优化现有敏捷开发与 DevOps 相关的流程与工具平台，使得安全专家能够充分参与项目，提升安全开发沟通效率，快速获取安全反馈；

• 将安全专家纳入到敏捷开发和 DevOps 文化建设中来，信息安全人人有责，安全专家可以充分发挥教练员角色和守门员角色，使得团队人人有能力履行自己的安全职责，安全专家在恰当的时机对安全交付物进行质量把控；

• 提前进行安全基础设施规划与布局，如身份与权限管理系统、SSO 系统、加解密平台与 SDK、日志分析与监控平台、全流量检测平台等等，使得安全措施标准化、服务化和平台化，降低安全设计与编码的能力门槛，对安全基础设施的测试与验证取代设施所承载应用的大部分安全测试，可以有效消减安全测试工作量。

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

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

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

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

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

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

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

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

十一、小结

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

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

十二、感悟

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

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

本文转载自宜信技术学院公众号。

原文链接：http://college.creditease.cn/detail/332