文章总结: 本文探讨以数据为中心构建安全体系的核心理念,指出传统厂商多从网络安全视角将数据置于防御中心,而作者提出应站在数据维度分析访问过程,包括载体、方法、逻辑、资产访问拓扑和身份五个层次。关键发现包括数据易获得性导致风险暴露面扩大,建议优先治理高频访问场景如API安全,并推动从基于角色的访问控制转向基于属性的精细化管控。可操作建议涵盖最小授权、敏感数据阈值管理、核心数据隔离及权限回收等六项落地原则。 综合评分: 87 文章分类: 数据安全,安全建设,技术标准,解决方案,应用安全
也谈以数据为中心构建安全体系
原创
木言 木言
合规社
2024年6月6日 14:23 上海
在小说阅读器读本章
去阅读
探寻合规之道,共筑数据保障之堡。专注为数据安全管理者、技术专家、隐私法务、律师等专业人士打造的知识共享与交流平台。
点击 “合规社” > 点击右上角“···” > 设为星标⭐
■作者:木言
■编辑:王贤智
也谈以数据为中心构建安全体系
▽
目前多数的安全厂商谈数据安全,言必称以数据为中心构建数据安全体系,但是很多对于以数据为中心还是停留在传统的网络安全的视角,下图是目前多数厂商强调的以数据为中心的拓扑图:
网络安全视角的数据为中心
其核心是强调数据位于整个防御体系的中心,从数据的视角往外看,有数据库、操作系统、应用、硬件等等,想表达的外部的攻击突破的重重边界之后才能触达数据,本质上还是传统网络安全纵深防御的理念。
笔者认为的以数据为中心是站在数据的维度来看,主要包含两个维度;
第一个维度,是站在数据的视角往外看,数据访问的过程,当一个数据被访问时,其由内之外分别是载体、方法、逻辑、资产访问拓扑、身份。
载体:数据不可能虚空存在,那么他必然有一个载体,这个载体有可能是数据库、文档、PDF、大数据平台;
方法:访问某个数据命令,比如针对数据库中数据SQL语句,比如Select /Update等等, Windows操作系统操作命令,比如:copy/dir/ del等
上下文逻辑:访问某个数据的命令上下文逻辑关系,是否符合访问这个数据正常的逻辑,比如我们SQL注入攻击,就是不允许的运行逻辑
资产访问拓扑:身份访问业务系统数据,业务系统之间数据访问整体复杂的拓扑关系;
身份:具体访问资产的身份,身份包含了四个要素,分别是人、终端、账号、应用,共同构成了身体体系。
这是站在数据的视角来看数据本身,强调的数据本身,而不是操作系统、软硬件等等,于此对应的就是针对这些行为的数据安全管控手段。
载体安全举例:文档加密 本质上就是在载体维度保护数据内容安全;
方法安全举例:数据库准入 本质上是控制一些高危风险的数据操作来保护数据,如:Drop语句;
逻辑安全举例:WAF、数据库防火墙、API网关 这些产品都会针对一些SQL注入行为、API的注入行为进行监测和管控,是实现对数据的保护
资产访问拓扑安全举例:这里主要是系统之间的访问管控、身份对于系统数据访问管控;
身份安全:传统网络安全的范畴,主要是针对身份的管控,实现身份的全生命周期管理;
那么我们在构建数据安全体系的时候,可以围绕前文说的载体、方法、逻辑、资产拓扑、身份进行构建。
以资产为中心的第二维度是从数据流动的视角来看,前文提及数据在安全的维度有流动性的特征,那么以数据为中心就要求,当数据流动到任何位置,安全防护就应该覆盖到该位置,数据本身是为业务服务的,基于业务的需求我们需要看到数据、互相调用数据,最终数据流动至各个业务系统,每个业务系统又有不同的访问人员,前文提及的数据安全的另一个特性:易获得性,因此相比较网络安全,数据安全风险的暴露面是无限大,任何数据会从有序、无序最终到失控,这个是数据最终的宿命。
从建设的角度来看,很难做到当数据流动到任何位置,安全防护就应该覆盖到该位置,那么回归本质看问题,我们需要做到的优先解决数据访问量最多的场景优先治理,比如现在API安全产品是数据安全防护的重点之一,核心是通过API接口访问数据是目前数据访问量最多的场景之一。
前文主要阐述的时我认为以数据为中心的概念,核心强调的站在数据的视角往外看数据访问的过程,当一个数据被访问时,其由内之外分别是载体、方法、逻辑、资产访问拓扑、身份。
从这个过程逻辑来看,核心就是身份访问资产的过程,不考虑数据跨域的场景,域内数据访问主要两类典型场景,一类是人通过某个身份直接访问系统后端数据库数据,另一类是系统使用某个身份通过接口访问另一个数据系统数据库的数据。前者更多聚焦在人的安全,后者聚焦在业务的安全。
在网络安全中,一直强调身份的管理,数据安全相比较与网络安全,对于身份管理的要求更高,核心原因是前文提到的数据安全的三大特性特质之一:易获得性,任何人都有可能获取到数据,也有可能有意或者无意将数据泄露或者滥用。对于身份的管理这里不再阐述,本文主要想阐述的身份和资产的访问关系,这个访问关系由:方法、逻辑、资产访问拓扑共同组成。
下图是一个典型的身份访问数据资产的拓扑图:
核心是定义了不同的身份可以访问不同数据的资产权限等级,基本上是基于角色的访问控制RBRC定义访问权限,但仅是这样的,本质上是无法满足前文提及的以数据为中心的视角的安全需求。在以数据为中心的视角,身份和资产之间有方法、逻辑、资产访问拓扑,共同构成了身份访问数据资产的复杂关系,因此需要再往前走一步,探索基于属性的访问控制机制(ABAC)。
每一份数据有属主,即数据的owner,需要属主结合安全的诉求定义数据访问的各类属性,这些属性包含:主体属性(部门、岗位、职责、人)、 数据属性(数据类型、数据性质、数据量级、数据安全等级)、 环境属性(业务模式、行为模式、所处环境、业务逻辑),这种策略使我们从基于角色的粗放的访问控制,走向基于属性的精细化的访问控制,最终我们的目标是什么?目标是实现基于动态的身份访问数据资产能力血缘图谱,如下表所示:
当然,以目前落地的现状来看,要达到该目标仍然任重道远,那么基于可落地的实践角度出发,我们还是需要定义一些身份访问数据资产的基本原则,如下是个人的一些建议:
✔️1.最小授权原则,不同类别级别的数据应匹配对应的访问人员范围,不同岗位及级别的工作人员则应对应其最小必要的访问和处理权限,所有的基于数据的访问都必须基于身份和资产的不同定义不同数据访问策略;
✔️2.对于一般数据中的敏感数据,如果是定性数据,需要明确访问策略以及必要的逻辑或管理上的控制手段,如果是定量数据,还需要设定数据访问量的风险阀值,当达到阈值时,也需要设定必要的逻辑或管理上的控制手段;
✔️3.对于重要数据/核心数据,所有身份对其的处理活动必须有相应的隔离操作,原则上不允许直接暴露在身份前;
✔️4.对于身份访问资产的行为,设定部分可实现的风险策略同时进行不断调优。为什么我们这里不提UEBA,因为在数据安全领域,大概率UEBA是不可能实现的;(核心还是前文提及的数据的易获得性的问题,可获取数据的人太多,特别是前端业务人员,完全没有建立行为基线的可能性,相对后端的人员行为基线反而能够建立);
✔️5.对于特殊场景下的身份对资产的访问,需要单独构建相应的策略,如:对于临时的身份,设定临时性的数据访问策略及失效控制;对于要离职的身份,对于数据资产的任何访问要严格管控等
✔️6.需要有身份权限回收能力,特别是大的一些央国企、金融行业,其内部的人员借调、轮岗是很频繁的,这会导致其身份访问数据资产的权限是不断放大的,但是这些单位很少去进行权限回收,使其可访问数据的范围和敏感等级不断提升;
以上均是从可落地的角度来看,从安全的角度的来看,我们希望最终还是能够实现动态的动态的身份访问能力血缘图谱。
#
本文作者 木言 数字安全业务规划专家 在金融、政府、医疗、等行业有丰富的行业实践经验,对数据安全体系有深入的理解,长期关注和从事零信任、CARTA、CSF等技术框架在数据安全领域的实践落地,擅长数据安全方向的技术体系建设与应用、数据安全体系的创新与实践等。
-END-
「 数据合规知识星球 」是一个专注于数据安全和个人信息保护的资源和知识集散地。星球提供图解PPT、行业解决方案、数据安全合规管理制度模板、评估工具及评估报告模板、监管政策及标准汇编整理等,帮助组织或个人理解并遵守数据安全合规的法律法规,促进操作和业务流程的安全合规。
310+已加入 ⬇️⬇️⬇️ 
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:合规社 木言 木言《也谈以数据为中心构建安全体系》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。










评论