1.GDPR
2.DSMM
3.ISO27701
4.《银行业金融机构数据治理指引》
5.《个人信息安全规范》
依据数据的生命周期,我理了下在数据治理过程中需要注意的点及需要做的工作:
当然不止上面这些,比如终端安全、DLP等都需要进行严格控制,这些都是基于内部的数据安全控制措施,还有对于外部的威胁监控,比如敏感信息泄漏、业务方面的风险情报等也是我们需要关注的重点,不过在此不做详细介绍,仅列出一些在数据治理方面已经落地的点来做一下描述:
0X01 如何做好数据的分类分级标准
首先我们在做敏感等级的划分时一定不要定太多的等级,比如有这样定的S1、S2、S3、S4四级标准,也有这样定的四级标准:绝密、机密、秘密、非保密,当然也有定的绝密、机密、秘密、内部、公开五级标准,也有人提到定了7级的。
具体如何做,这个纯属看自己选择,在此则要提醒一下:不要定太多等级,落地比较困难,会给自己挖坑的,个人建议四级比较合适,比如:绝密、机密、秘密、非保密。
序号 |
字段名称 |
敏感等级 |
屏蔽规则 |
1 |
姓名 |
秘密 |
平** |
2 |
手机号 |
机密 |
133****5678 |
3 |
身份证号码 |
绝密 |
1234**********6789 |
其次,我们在制定数据标准的时候一定要考虑准确性和通用性,这两者之间其实是有点矛盾的,笔者在此就碰到过问题,我们有一个比较通用标准(手机号、姓名、性别、身份证号码…...),也有一个很详细的业务标准(个人中文名称、个人手机号、亲属手机号、代理人手机号……),这两套标准在我们数据打标落地的时候自然而然的就出现冲突,不过可以通过合理定位来解决这种冲突,通用字段标准用来做敏感数据打标,也是敏感数据识别的规则编写依据,而业务标准字段名称则作为业务使用是参考的一个数据标准。也可以将通用字段标准作为一个标签打在业务字段标准上,如下:
序号 |
业务标准字段名称 |
标签属性(通用字段名称) |
敏感等级 |
1 |
个人手机号 |
手机号 |
机密 |
2 |
亲属手机号 |
手机号 |
机密 |
3 |
代理人手机号 |
手机号 |
机密 |
比如,在应用系统中对敏感字段进行关键部位屏蔽,或者查看敏感信息时进行二次身份认证,这种一般是在数据属主查看自己敏感信息时可以用到,对于企业进行数据分析时用到的大量的客户数据则不能通过这种方法,因为会存在数据聚合场景下的信息泄漏的风险,通过关联性分析可以匹配出对应的客户敏感数据,所以在制定敏感数据屏蔽规则的时候一定要对其应用场景进行分析.
0X02 敏感数据识别
在我们确定好分级标准及字段标准后我们接下来要做的工作就是敏感数据的识别,对于敏感数据识别,我将其分为两部分:
0X03 隐私保护
围绕数据生命周期的安全过程,我将其分为两部分,数据安全和隐私保护,数据采集有内外之分,对于外部的数据采集需要数据属主的授权,在内部进行的数据采集则需要在不违背数据授权范围下进行,同时还要考虑数据的用途及业务合理性,但是我们再企业内部也经常会需要依托大量的用户数据进行一些分析统计,在此则不可避免的需要使用到用户的数据信息,那么我们又如何能够做到既不违背隐私保护的原则又满足自身的数据分析行为?
在此我们则需要引入《个人信息安全规范》中的解释,匿名化主要是指个人信息在通过技术处理后,无法被识破或还原;去标识化指在我们应用系统中展示敏感信息的时候我们可能会做一些屏蔽处理,可以通过屏蔽关键位置来进行掩码;双方进行数据匹配碰撞的时候则可以通过对唯一标示性字段进行不可逆的算法处理,比如sha256、sm3这种摘要算法,进行碰撞然后再将结果与自己数据的映射关系进行比对从而获取想要的结果,K-匿名的应用其实也是有很大的限制,多用于统计分析类的场景,因为不需要具体匹配到某个人,只是做一个统计分析的结果。
扫码关注
原文始发于微信公众号(Fintech 安全之路):我眼中的数据安全治理
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论