个人隐私保护之三:数据安全防护实践
2019-12-31 10:00:22 Author: www.freebuf.com(查看原文) 阅读量:117 收藏

一、前言

自GDPR法规在欧盟发布以来,隐私保护在国内也逐渐完善了立法和相关标准的制定,今年四部委成立APP专项治理组后,许多公司也开始对APP进行的自查和整改。我们在此项工作中,发现许多细节内容并没有多少具体实施和落地的资料可以查阅,只能逐步在摸索中进行。

APP隐私政策保护主要在以国标GB/T 35273-2017《个人信息安全规范》,APP专项治理工作组编制了《App违法违规收集使用个人信息自评估指南》作为主要标准依据,尤其是《指南》是目前官方可能唯一发布的相对比较具体的重要参考。

上一篇《APP隐私保护之二——用户端隐私保护实践》中探讨了APP前端的一些法规要求和实践措施,本文着重探讨服务端及企业内部数据安全策略方面的数据安全保护机制,包括数据存储,使用,共享,转让,公开等数据生命周期中的核心环节。

以往文章:

《APP隐私保护之二——用户端隐私保护实践(上)》

《APP隐私保护之二——用户端隐私保护实践(下)》

二、个人信息保存

个人信息保存包括数据传输和数据存储的相关要求,APP运营方应该对数据传输和存储过程,方式,以及有效时间做相关的控制,并使用如加密,匿名化等技术措施作为数据保障的基础能力。

2.1. 数据加密和匿名化技术

2.1.1. 数据加密

(1)数据传输加密:通常会使用HTTPS等安全协议进行传输

SSL/TLS系列中有五种协议:SSL v2,SSL v3,TLS v1.0,TLS v1.1和TLSv1.2;

SSLv2 是不安全的,不能使用;

TLSv1.1 和 v1.2 都没有已知的安全问题,只有 v1.2 提供了现代的加密算法;

当然也可以用其他协议传输,将传输的敏感数据内容加密。

(2)数据存储加密:线上数据加密一般会对结构化数据的某几个敏感字段家加密,比如含有个人隐私信息的字段

数据库存储加密的三种方式:

开源的加密组件,如Key Management Service(KMS),通过开发SDK或集成至数据库中间层实现自动加解密。

数据库自身功能,如Mysql加密解密函数AES_ENCRYPT(),AES_DECRYPT();SQL Server加解密函数dbo.EncryptByPassPhrasePwd,dbo.DecryptByPassPhrasePwd。

商业数据加解密产品,有需要的可以自行了解一下

2.1.2. 匿名化处理

匿名化处理是使用场景

用户注销账户,删除数据时

大数据平台使用数据加工

收集个人信息后,建议将数据匿名化或去标识化,并将该信息与可用于恢复识别个人的信息分开存储(一般存储至大数据平台)。数据加工时,优先使用匿名化的数据,并加强对个人信息的访问控制,这样可以很好的控制个人隐私泄露的场景。

2.2. 人信息控制者停止运营后的处置机制

公司一般不会涉及到这种情况,但是做隐私合规时,需要这部分完善的管理制度。

a) 及时停止继续收集个人信息的活动;

b) 将停止运营的通知以逐一送达或公告的形式通知个人信息主体;

c) 对其所持有的个人信息进行删除或匿名化处理。

一般来说需要建立一套管理制度,或某个管理制度建立相关条款。并对上述要求具体实施细则建立一个操作流程。

三、个人信息使用

3.1. 个人信息使用的访问控制

个人信息的访问控制,我的理解主要是针对企业内部的数据访问机制,需要遵循最小权限原则,即用最少的人访问最少的数据。

常见的场景:

后台系统访问和获取数据的权限控制措施,系统统一认证鉴权

应用系统之间数据接口的权限管控,尤其是跨业务线,跨项目的情况

数据提取和拷贝机制

大数据平台,在线数据分析

办公网数据管控(桌管,零信任,线上文档编辑工具)

兜底方案:DLP,水印,染色,审计系统

3.2. 系统后台展示方式

涉及通过界面展示个人信息的(如显示屏幕、纸面),对需展示的个人信息采取去标识化处理等措施,降低个人信息在展示环节的泄露风险。例如,在个人信息展示时,防止内部非授权人员及个人信息主体之外的其他人员未经授权获取个人信息。

这里简单的解释就是系统展示也做脱敏,当然许多场景可能不能脱敏。

3.3. 用户请求的处理机制

(1)投诉处理机制

个人信息控制者应建立申诉管理机制和申诉跟踪流程,并在合理的时间内对申诉进行响应。具体做法分为四个步骤

建立申诉管理制度;

提供了有效的申诉渠道;

承诺了反馈时限;

承诺的反馈时限内进行响应。

申诉管理制度可以是一个独立文件,也可以是和客服建立的流程机制,甚至是知识库文件,建立制度的目的是规范申诉事件的处理方法,避免出现,无人响应,应答错误等情况

有效的申诉渠道一般在隐私政策中会有说明,最好还是建立多个申诉渠道,保证申诉渠道的通畅,比如电话,在线等,在APP中建立相应入口最佳。

承诺了反馈时限原则上不能超过15日。

承诺的反馈时限内进行响应是上述所有措施有效的保障:

第一,建立详细的申诉受理流程,客服,安全,法务,公关等岗位进行联动。客服直接面向客户进行简单的判断和争取收集,安全部跟进确认申诉事件判断最终结果,法务和公关进行最中事件解决的方案。

第二,保障上述流程进行,需要建立知识库,常见问题,需要收集哪些信息告知一线客服,并进行相应培训。

第三,安全部的数据溯源措施,工具,以及内部承接事件的应急处置方案建立。由于有时间限制,一般从客服接单后,只有不到10天的“破案”事件,所以溯源工具和标准化作业流程很重要。

第四,定期演练和培训,演练和培训是保障机制流畅运行的好办法。

第五,对自己的队友多鼓励,不要埋怨。尤其是制度建立之初,可能会有一些不靠谱的单子发过来,这时如果一味的埋怨一线客服可能会让整个流程变得阻塞。多分析原因,逐步积累知识库和培训素材,才是让一切变好的好方法

(2)个人信息获取副本和查询信息

获取渠道确认:可以是电话申请,线上申请等

获取途径:邮寄,在线提供等

身份认证:验证身份信息,可以通过输入密码,核对**等

信息提取流程:用户需要信息的类型,建立信息提取流程

证据保存:包括用户请求证据,***据,提取过程日志或记录。

四、个人信息的共享,转让,公开

4.1. 第三方共享转让

(1) 事先开展个人信息安全影响评估,并依评估结果采取有效的保护个人信息主体的措施。

参照《信息安全技术 个人信息安全影响评估意见稿》方法,这里不详细介绍了。

(2) 向个人信息主体告知共享、转让个人信息的目的、数据接收方的类型,并事先征得个人信息主体的授权同意。

一般通过隐私政策,隐私政策弹窗

(3) 共享、转让经去标识化处理的个人信息,且确保数据接收方无法重新识别个人信息主体。

只能尽量传输去标识化信息或脱敏信息,影响正常业务的还是可以共享个人信息的,主要看业务开展的模式。要建立相关制度,比如对第三方的安全要求,共享机制,安全协议,监控措施等。

(4) 准确记录和保存个人信息的共享、转让的情况,包括共享、转让的日期、规模、目的,以及数据接收方基本情况等

一般通过数据接口传输数据需要记录数据传输的日志,日志含有日期,访问规模,额外等级该接口的使用目的和数据接收方信息。

(5) 承担因共享、转让个人信息对个人信息主体合法权益造成损害的相应责任

处理个别案件和免责声明时要注意,可能需要让法务部了解一下。

(6) 帮助个人信息主体了解数据接收方对个人信息的保存、使用等情况,以及个人信息主体的权利,例如,访问、更正、删除、注销账户等。

客服的流程,客服能够帮助客户了解第三方信息。在与第三方签订合作时,需要将次义务特别说明。

4.2. 个人信息公开披露处理

(1) 事先开展个人信息安全影响评估,并依评估结果采取有效的保护个人信息主体的措施

同上,不介绍了

(2) 向个人信息主体告知公开披露个人信息的目的、类型,并事先征得个人信息主体明示同意

在公开披露个人信息前,需要通知并获得同意

(3) 准确记录和保存个人信息的公开披露的情况,包括公开披露的日期、规模、目的、公开范围等

公开披露场景很多,所以没有确定的方式。比如通过系统公开获奖名单,一般会脱敏个人信息,并且上传系统的日志中记录此次获奖名单即可。

(4) 承担因公开披露个人信息对个人信息主体合法权益造成损害的相应责任

(5) 不得公开披露个人生物识别、基因信息

4.3. 个人信息委托处理

(1) 个人信息控制者应对委托行为进行个人信息安全影响评估

同上,不介绍了

(2) 受委托者应:

严格按照个人信息控制者的要求处理个人信息。受委托者因特殊原因未按照个人信息控制者的要求处理个人信息,应及时向个人信息控制者反馈;

受委托者确需再次委托时,应事先征得个人信息控制者的授权;

协助个人信息控制者响应个人信息主体提出的请求;

受委托者在处理个人信息过程中无法提供足够的安全保护水平或发生了安全事件,应及时向个人信息控制者反馈;

在委托关系解除时不再保存个人信息。

应用场景很少,没有合适的场景和案例。基本遵循两点原则:第一,最小的保存时间原则,第二,委托的授权和个人信息处理方式对信息主体有知情权和同意撤销权

(3) 通过合同等方式规定受委托者的责任和义务;对受委托者进行审计

主要是审计工作的安排,如果很重大的项目建议采用定期审计,建议聘请外部审公司可以有效转移风险。一般项目可以考虑自动化审计工具,日志分析等方式。

4.4. 跨境

跨境目前比较复杂,要遵循我国跨境传输法律并遵循当地的法律要求。我国的跨境传输指南是现在比较常用的参考。欧盟的GDPR现在要求比较严格,所以传输至欧洲需要特别注意

五、结束语

上一篇主要是针对APP应用端,即用户侧的隐私保护内容,内容比较显性,大多是前端的修改,涉及很多文案工作。本篇针对的是服务端和公司内部的流程和机制,不仅仅是合规的需要,还是保护公司自身利益的需要。尤其是第三方数据共享时,数据流出公司防护边界,其泄露极可能影响到公司利益,并且很难排查。

本文主要从隐私要求,管理和法律方式对第三方的数据保护进行约束,公司内容防护建设也应注意对第三方的数据权限控制,并具备一定审计和溯源能力,比如使用脱敏,染色等技术。

*本文原创作者:Alkaid13,本文属于FreeBuf原创奖励计划,未经许可禁止转载


文章来源: https://www.freebuf.com/articles/database/223045.html
如有侵权请联系:admin#unsafe.sh