MySQL 数据脱敏方式盘点
对于企业而言,数据脱敏可以在数据共享或测试时用于保护敏感数据(如信用卡,社保卡,地址等)。通过对敏感数据进行脱敏处理,组织可以最大限度地降低数据泄露和未经授权访问的风险,同时仍能够使用真实的开发,测试和分析目的所需的数据。
有很多方法进行数据脱敏,比如遮挡,替换,洗牌和加密,等等,它们适用于不同场景。本文主要聚焦「遮挡」,用特定符号 (比如 X 或 ) 遮挡敏感数据,这种方法可以在脱敏的同时保持原有数据感观。
MySQL 企业级数据脱敏插件
MySQL 官方这边,数据脱敏只作为插件在 MySQL 企业版中提供 。 MySQL 数据脱敏插件的工作原理是插件中包含了用于进行数据脱敏的语法,例如 mask_inner
, mask_outer
, mask_ssn
等。
组织里有权限的人员(通常来说是数据库管理员)会首先定义一个显示脱敏数据的视图 (VIEW)。即使用户对敏感数据的访问受限,他们也可以将该视图视为一张表。因此,要访问数据,用户不是直接使用脱敏语法进行直接查询,而是从视图中查询即可。
这种方法很直接,但也有一定限制:
- 依赖于细粒度的 MySQL 用户账户 / 角色。实际上,大多数 MySQL 实例只有少数几个用户。要采用此插件,需要重新设计 MySQL 中的账户设置。
- 不同的脱敏规则需要定义不同的视图。随着底层表和变体数量增加,这会越来越难管理。
- 没有专门的模块来管理脱敏(毕竟只是普通的 MySQL VIEW)。
Percona 数据脱敏插件
Percona 数据脱敏插件 是前述 MySQL 插件的免费开源实现。它也提供了一组用于脱敏数据的函数。
同样,保护原始数据的方法是使用视图 (VIEW)。 然而,Percona 数据脱敏仅适用于 Percona Server for MySQL。如果你使用更主流的 MySQL,那就需要另寻他路了。
Bytebase 动态数据脱敏
不同于前两种,Bytebase 动态数据脱敏 不依赖于底层的 MySQL 视图和用户,而是通过 Bytebase 内部管理脱敏策略和授权管理。当用户通过 SQL 编辑器查询时,会自动应用动态脱敏策略。
Bytebase 动态数据脱敏包括以下组件:
- 全局脱敏规则:「工作空间所有者」和「DBA」可以批量定义全局脱敏规则。例如,可以将所有名为 email 的列脱敏程度设置为「半脱敏」。这样,修改脱敏策略就无需手动修改数千列了,还节省了维护视图的麻烦。
- 列脱敏规则:「工作空间所有者」和「DBA」可以将列设置为不同的脱敏级别。列脱敏规则优先于全局脱敏规则。
- 访问未脱敏数据:对于脱敏数据,「工作空间所有者」和「DBA」可以授予特定用户访问未脱敏数据的权限。
⚠️「工作空间所有者」和「DBA」均为 Bytebase 的角色。
对比
MySQL 数据脱敏和 Percona 数据脱敏插件的优势在于它们是在数据库本身中实现的。因此,无论以何种方式将查询发送到数据库,都会强制执行数据脱敏规则。对于 Bytebase 动态数据脱敏来说,查询则需通过 SQL 编辑器进行强制执行。
Bytebase 动态数据脱敏的优势在于其与所有 MySQL 发行版的兼容性,丰富的脱敏策略和访问授权。只要团队通过 Bytebase SQL 编辑器来查询数据库,那么 Bytebase 动态数据脱敏可以保障组织敏感数据的安全。
🔧 欢迎跟着教程来试试 Bytebase 动态数据脱敏。
💡 更多资讯,请关注 Bytebase 公号:Bytebase
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
MySQL的3种索引合并优化⭐️or到底能不能用索引?
MySQL的3种索引合并优化⭐️or到底能不能用索引? 前言 前文我们讨论过MySQL优化回表的多种方式:索引条件下推ICP、多范围读取MRR、覆盖索引等 这篇文章我们来聊聊MySQL提供的另一种优化回表的手段:index merge 索引合并 在阅读本文前,你需要了解MySQL的server层与存储引擎层如何交互、二级索引和聚簇索引的区别、回表等知识 如果同学不太了解这些知识可以回看前文: MySQL的优化利器⭐️索引条件下推,千万数据下性能提升273%🚀 MySQL的优化利器⭐️Multi Range Read与Covering Index是如何优化回表的? MySQL导致索引失效的八股文中有这样一条:使用or会导致索引失效 那么是不是所有场景都会失效呢?带着这个问题,我们往下看 案例使用上篇文章的座位表,并分别建立seat_code、student_id 两个二级索引 CREATE TABLE `seat` ( `seat_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '座位ID', `seat_code` char(10) DE...
- 下一篇
云原生微服务的下一站:Proxyless Service Mesh
本文分享自华为云社区《DTSE Tech Talk | 第46期:云原生微服务的下一站:Proxyless Service Mesh》,作者:华为云社区精选。 本期直播主题是《云原生微服务的下一站:Proxyless Service Mesh》,华为云云原生DTSE技术布道师、华为云技术规划专家,Sermant开源社区创始人杨奕以及华为云云原生DTSE技术布道师、Sermant社区PMC李来,和开发者一起交流了微服务架构演进历程、新一代的新一代云原生无代理服务网格Sermant如何解决以往架构的痛点以及实操演示如何改造升级微服务架构。 微服务架构各自的痛点 在微服务的概念出现之前分布式业务的改造最早是通过传统的SOA(面向服务)架构来进行的。SOA架构一般会部署集中式的Load Balancer或者中心网关。它的优点是架构简单,但是性能低下,可扩展性差。 此后微服务SDK架构开始流行起来,例如Dubbo和Spring Cloud,主要是通过业务应用中引入SDK来实现服务注册发现、限流降级、全链路灰度等服务治理能力。这种架构的性能卓越,功能丰富,但应用改造成本高,升级困难。 近年来较为流...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS8编译安装MySQL8.0.19
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Mario游戏-低调大师作品
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果