数据安全合规实践（二）安全需求评审：信息采集部分评审

数据安全合规实践（二）安全需求评审：信息采集部分评审 – 作者:guoqi_znuel

前言

上一篇文章讲到在安全需求评审阶段，为满足数据安全合规，应当让业务研发团队提交哪些信息。今天这篇文章，我想和大家一起探讨一下，收集了这些信息后，怎么去做评审。

首先，在SDL和devsecops概念普及及热炒的当下，基本上没有人不会承认安全需求评审在应用安全中的重要性。但在做安全需求评审的时候，尤其是大型企业，其实是很头疼的事情，它往往会有以下痛点问题：

（1）安全人员少，但系统多，没法覆盖（我所在公司，安全人员在100-200左右，应用安全组基本维持在10人左右，但需要面对集团活跃系统300-500套，每月发版次数在900次以上）；

（2）研发自提交的信息太简单，难以评审，每次都通过会议访谈又太耗时间；

（3）devsecops中对自动化要求较高，安全需求评审如何做到自动化；

自然，在安全需求评审中，融入数据合规内容，必然会增加工作量，也不会绕过上面三个问题。在本篇文章中呢，不会去专门讲我们在实践中如何做devsecops或者如何做安全需求评审，这些问题呢，我计划后面会做devsecops专题，来分享我们在实践中遇到的问题和解决的方案（如果按照b站的视频做法，这时候应该说如果点赞过万，我就xxxxxx）。

其实关于痛点2，在上一篇文章中，我们使用的方法有解决，即通过标准化的选项，减少业务研发人员自组织语言，便于安全评审人员快速理解；同时，通过举例，让业务研发人员理解安全合规的意图，减少对问题理解的误差。这样从双向减少了沟通成本。当然这里要注意一点，有些问题还是必然要进行访谈的，这个我们就不在这里展开了。

痛点1和痛点3其实是相关的，因为人力不足，效率低，所以要寄希望于自动化。那么上一篇文章中，标准化的选项，就为自动化提供了前提。当然在安全需求评审的自动化中，除了标准化的选项，我们还尝试了语义分析技术，但目前还在摸索过程中，各位大佬如果有好的想法也可以一起探讨。

所以接下来，我们就来看看如何在收集到标准化信息后，进行自动化的数据合规安全需求评审。同时，在此附上上一篇文章的链接。

在自动化的安全需求评审中，我们将需求分为以下几类：（1）需求合理性评估，如对是否应当采集该数据进行评估；（2）安全附加性要求，如对某个需求，附加需要注意的安全措施或者安全要求。

0x01 何时需要触发

根据GDPR的要求，出于相同或类似的目的处理相同类型的个人数据，并且已经为这些活动完成了DPIA，那么则无需进行额外的DPIA。因此，在此处，如果在业务研发团队提交了相同的业务功能模块、相同的采集数据集、相同的采集方式、相同的处理方式时，则不需要进行进一步评估。当然，有人说不能信任研发团队提交的数据，这个时候，其实就是要靠后续审计、安全测试等来追责了。