前⾔
数据安全并不是⼀个独⽴的要素，⽽是需要连同⽹络安全、系统安全、业务安全等多种因素，只有全部都做好了，才能最终达到数据安全的效果。数据安全⽣命周期 image.png
⼀：数据采集
1.流量保护
数据泄露有⼀部分原因是⽤户会话流量被复制。全站HTTPS是⽬前互联⽹的主流趋势，它解决的是⽤户到服务器之间链路被嗅探、流量镜像、数据被第三⽅掠⾛的问题。这些问题其实是⽐较严重的，⽐如电信运营商内部偶有舞弊现象，各种导流劫持插⼴告（当然也可以存数据，插⽊马），甚⾄连AWS也被劫持DNS请求，对于掌握链路资源的⼈来说⽆异于可以发动⼀次“核战争”。即使⽬标对象IDC⼊侵防御做的好，攻击者也可以不通过正⾯渗透，⽽是直接复制流量，甚⾄定向APT，最终只是看操纵流量后达到⽬的的收益是否具有性价⽐。
HTTPS是⼀个表⾯现象，它暗⽰着任何互联⽹上未加密的流量都是没有隐私和数据安全的，同时，也不是说有了HTTPS 就⼀定安全。HTTPS本⾝也有各种安全问题，⽐如使⽤不安全的协议TLS1.0、SSL3，采⽤已经过时的弱加密算法套件，实现框架安全漏洞如⼼脏滴⾎，还有很多的数字证书本⾝导致的安全问题。 全站HTTPS会带来的附带问题是CDN和⾼防IP。历史上有家很⼤的互联⽹公司被NSA嗅探获取了⽤户数据，原因是CDN 回源时没有使⽤加密，即⽤户浏览器到CDN是加密的，但CDN到IDC源站是明⽂的。如果CDN到源站加密就需要把⽹站的证书私钥给到CDN⼚商，这对于没有完全⾃建CDN的公司⽽⾔也是⼀个很⼤的安全隐患，所以后来衍⽣出了Keyless CDN技术，⽆需给出⾃⼰的证书就可以实现CDN回源加密。
⼴域⽹流量未加密的问题也要避免出现在“⾃家后院”——IDC间的流量复制和备份同步，对应的解决⽅案是跨IDC流量⾃动加密、TLS隧道化
2.业务安全属性
在⽤户到服务器之间还涉及两个业务安全⽅向的问题。第⼀个问题是账号安全，只要账号泄露（撞库&爆破）到达⼀定数量级，把这些账号的数据汇总⼀下，就必定可以产⽣批量数据泄露的效果。
第⼆个问题是反爬，爬⾍的问题存在于⼀切可通过页⾯、接⼝获取数据的场合，⼤概1⼩时爬个⼏百万条数据是⼀点问题都没有的，对于没有彻底脱敏的数据，爬⾍的效果有时候等价于“⿊掉”服务器。账号主动地或被动地泄露+爬⾍技术，培育了不少⿊产和数据获取的灰⾊地带。
3.UUID
UUID最⼤的作⽤是建⽴中间映射层，屏蔽与真实⽤户信息的关系链。譬如在开放平台第三⽅应⽤数据按需⾃主授权只能读取UUID，但不能直接获取个⼈的号。更潜在的意义是屏蔽个体识别数据，因为实名制，⼿机号越来越能代表个⼈标识，且⼀般绑定了各种账号，更改成本很⾼，到⼿机号就能对上这个⼈，因此理论上但凡带有个体识别数据的信息都需要“转接桥梁”、匿名化和脱敏。譬如当商家ID能唯⼀标识⼀个品牌和店名的时候，这个原本⽤于程序检索的数据结构也⼀下⼦变成了个体识别数据，也都需要纳⼊保护范畴。
⼆：前台业务处理
1.鉴权模型
在很多企业的应⽤架构中，只有在业务逻辑最开始处理的部分设置登录态校验，后⾯的事务处理不再会出现⽤户鉴权，进⽽引发了⼀系列的越权漏洞。事实上越权漏洞并不是这种模型的全部危害，还包括各种K/V、RDS（关系型数据库）、消息队列等等，RPC没有鉴权导致可任意读取的安全问题。
在数据层只知道请求来⾃⼀个数据访问层中间件，来⾃⼀个RPC调⽤，但完全不知道来⾃哪个⽤户，还是哪个诸如客服系统或其他上游应⽤，⽆法判断究竟对当前的数据（对象）是否拥有完整的访问权限。绝⼤多数互联⽹公司都⽤开源软件或修改后的开源软件，这类开源软件的特点是基本不带安全特性，或者只具备很弱的安全特性，以⾄于完全不适⽤于海量IDC规模下的4A模型（认证、授权、管理、审计）。外⾯防御做的很好，⽽在内⽹可以随意读写，这可能是互联⽹⾏业的普遍现状了。 对于业务流的鉴权模型，本质上是需要做到数据和应⽤分离，建⽴数据默认不信任应⽤的模型，⽽应⽤中的全程Ticket和逐级鉴权是这种思想下的具体实现⽅法。
2.服务化
服务化的结果在安全上的意义是必须通过接⼝访问数据，屏蔽了各种直接访问数据的途径，有了API
控制和审计就会⽅便很多。
1）所有团队通过服务接⼝公开他们的数据和功能。
2）不允许使⽤其他形式的进程间通信：不允许直接链接，不允许直接读取其他团队的数据存储，不⽀持共享内存模式，⽆后门。唯⼀允许的通信是通过⽹络上的服务接⼝调⽤
3）所有服务接⼝⽆⼀例外都必须从头开始设计为可外部化。也就是说，团队必须规划和设计能够将接⼝展⽰给外部开发⼈员。没有例外
3.内⽹加密
也就是在后台的组件之间的数据传输都是加密的
4.数据库审计
数据库审计/数据库防⽕墙是⼀个⼊侵检测/防御组件，是⼀个强对抗领域的产品，但是在数据安全⽅⾯它的意义也是明显的：防⽌SQL注⼊批量拉取数据，检测API鉴权类漏洞和爬⾍的成功访问。
除此之外，对数据库的审计还有⼀层含义，是指内部⼈员对数据库的操作，要避免某个RD或DBA为了
泄愤，把数据库拖⾛或者删除这种危险动作。通常⼤型互联⽹公司都会有数据库访问层组件，通过这个组件，可以审计、控制危险操作。
三：数据存储
数据存储之于数据安全最⼤的部分是数据加密。所有的服务，在原型设计阶段就会考虑到对数据加密的⽀持
1.结构化数据
主要是指结构化数据静态加密，以对称加密算法对诸如⼿机、⾝份证、银⾏卡等需要保密的字段加密持久化
2.⽂件加密
对单个⽂件独⽴加密,⼀般情况下采⽤分块加密
3.⽂件系统加密
⽂件系统加密由于对应⽤来说是透明的，所以只要应⽤具备访问权限，那么⽂件系统加密对⽤户来说也是“⽆感知”的。
它解决的主要是冷数据持久化后存储介质可访问的问题，即使去机房拔⼀块硬盘，或者从⼀块报废的硬盘上尝试恢复数据，都是没有⽤的。但是对于API鉴权漏洞或者SQL注⼊⽽⾔，显然⽂件系统的加密是透明的，只要App有权限，漏洞利⽤也有权限。
四：访问和运维
在这个环节，主要阐述防⽌内部⼈员越权的⼀些措施。
1.⾓⾊分离
研发和运维要分离，密钥持有者和数据运维者要分离，运维⾓⾊和审计⾓⾊要分离。特权账号须回收，满⾜最⼩权限，多权分⽴的审计原则。
2.运维审计
堡垒机（跳板机）是⼀种针对⼈⾁运维的常规审计⼿段，随着⼤型IDC中运维⾃动化的加深，运维操作都被API化，所以针对这些API的调⽤也需要被列⼊审计范畴，数量级⽐较⼤的情况下需要使⽤数据挖掘的⽅法。
3.⼯具链脱敏
典型的⼯具脱敏包括监控系统和Debug⼯具/⽇志。在监控系统类⽬中，通常由于运维和安全的监控系统包含了全站⽤户流量，对⽤户Token和敏感数据需要脱敏，同时这些系统也可能通过简单的计算得出⼀些运营数据，譬如模糊的交易数
⽬，这些都是需要脱敏的地⽅。在Debug⽅⾯也出过Debug Log带有CVV码等⽐较严重的安全事件，因此都是需要注意的数据泄漏点。
4.⽣产转测试
⽣产环境和测试环境必须有严格定义和分离，如特殊情况⽣产数据需要转测试，必须经过脱敏、匿名化。
五：后台数据处理
1.数仓安全
⽬前⼤数据处理基本是每个互联⽹公司的必需品，通常承载了公司所有的⽤户数据，甚⾄有的公司⽤于数据处理的算⼒超过⽤于前台事务处理的算⼒。以Hadoop为代表的开源平台本⾝不太具备很强的安全能⼒，因此在成为公有云服务前需要做很多改造。在公司⽐较⼩的时候可以选择内部信任模式，不去过于纠结开源平台本⾝的安全，但在公司规模⽐较⼤，数据RD和BI分析师成千上万的时候，内部信
任模式就需要被抛弃了，这时候需要的是⼀站式的授权&审计平台，需要看到数据的⾎缘继承关系，需要⾼敏数据仍然被加密。在这种规模下，⼯具链的成熟度会决定数据本地化的需求，⼯具链越成熟数据就越不需要落到开发者本地，这样就能⼤幅提升安全能⼒。同时⿎励⼀切计算机器化&程序化&⾃动化，尽可能避免⼈⼯操作。
对于数据的分类标识、分布和加⼯，以及访问状况需要有⼀个全局的⼤盘视图，结合数据使⽤者的⾏为建⽴“态势感知”的能⼒。
因为数仓是最⼤的数据集散地，因此每家公司对于数据归属的价值观也会影响数据安全⽅案的落地形态：放逐+检测型 or 隔离+管控型。
六：展⽰和使⽤
这个环节泛指⼤量的应⽤系统后台、运营报表以及所有可以展⽰和看到数据的地⽅，都可能是数据泄露的重灾区。
1.展⽰脱敏
对页⾯上需要展⽰的敏感信息进⾏脱敏。⼀种是完全脱敏，部分字段打码后不再展⽰完整的信息和字段，另⼀种是不完全脱敏，默认展⽰脱敏后的信息，但仍然保留查看明细的按钮（API），这样所有
的查看明细都会有⼀条Log，对应审计需求。具体⽤哪种脱敏需要考虑⼯作场景和效率综合评估。
2.⽔印
⽔印主要⽤在截图的场景，分为明⽔印和暗⽔印，明⽔印是⾁眼可见的，暗⽔印是⾁眼不可见暗藏在图⽚⾥的识别信息。
⽔印的形式也有很多种，有抵抗截屏的，也有抵抗拍照的。
3.安全边界
这⾥的边界其实是办公⽹和⽣产⽹组成的公司数据边界，由于办公移动化程度的加深，这种边界被进⼀步模糊化，所以这
种边界实际上是逻辑的，⽽⾮物理上的，它等价于公司办公⽹络，⽣产⽹络和⽀持MDM的认证移动设备。对这个边界内的数据，使⽤DLP来做检测，DLP这个名词很早就有，但实际上它的产品形态和技术已经发⽣了变化，⽤于应对⼤规模环境下重检测，轻阻断的数据保护模式。
除了DLP之外，整个办公⽹络会采⽤BeyondCorp的“零信任”架构，对整个的OA类应⽤实现动态访问控制，全⾯去除匿名化访问，全部HTTPS，根据⾓⾊最⼩权限化，也就是每个账号即使泄露能访问到
的也有限。同时提⾼账号泄露的成本（多因素认证）和检测⼿段，⼀旦检测到泄露提供远程擦除的能⼒。
4.堡垒机
堡垒机作为⼀种备选的⽅式主要⽤来解决局部场景下避免操作和开发⼈员将敏感数据下载到本地的⽅法，这种⽅法跟VDI 类似，⽐较厚重，使⽤门槛不⾼，不适合⼤⾯积普遍推⼴。
七：共享和再分发
对于业务盘⼦⽐较⼤的公司⽽⾔，其数据都不会是只在⾃⼰的系统内流转，通常都有开放平台，有贯穿整个产业链的上下游数据应⽤。
1.防⽌下游数据沉淀
⾸先，所有被第三⽅调⽤的数据，如⾮必要⼀律脱敏和加密。如果部分场景有必要查询明细数据，设置单独的API，并对账号⾏为及API查询做风控。
其次如果⾃⾝有云基础设施，公有云平台，可以推动第三⽅上云，从⽽进⾏（1）安全赋能，避免⼀些因⾃⾝能⼒不⾜引起的安全问题；
（2）数据集中化，在云上集中之后利于实施⼀站式整体安全解决⽅案（数据加密，风控，反爬和数据泄露检测类服务），⼤幅度降低外部风险并在⼀定程度上降低作恶和监守⾃盗的问题。
2.反爬
反爬主要是针对公开页⾯，或通过接⼝爬取的信息，因为脱敏这件事不可能在所有的环节做的很彻底，所以即便通过⼤量的“公开”信息也可以进⾏汇聚和数据挖掘，最终形成⼀些诸如⽤户关系链，经营数据或辅助决策类数据，造成过度信息披露的影响。
3.授权审核
设置专门的团队对开放平台的第三⽅进⾏机器审核及⼈⼯审核，禁⽌“⽆照经营”和虚假三⽅，提⾼恶意第三⽅接⼊的门槛，同时给开发者/合作⽅公司信誉评级提供基础。
4.法律条款
所有的第三⽅接⼊必须有严格的⽤户协议，明确数据使⽤权利，数据披露限制和隐私保护的要求，明确数据处理者⾓⾊和
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议