数据中台实战课
郭忆
网易大数据专家
31971 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 19 讲
数据中台实战课
15
15
1.0x
00:00/00:00
登录|注册

11 | 怎么一劳永逸地解决数据安全问题?

安全性与效率的权衡
两种部署模式
Ranger审计功能
权限申请流程
OpenLDAP + Kerberos + Ranger实现用户、认证、权限管理
缺陷与解决方法
HDFS垃圾回收功能
线上集群数据同步到冷备集群
EC存储原理
HDFS数据备份
安全与效率的优先关系
机制五:开发和生产集群物理隔离
机制四:操作审计机制
机制三:精细化的权限管理
机制二:垃圾回收箱设计
机制一:数据备份与恢复
数据中台的数据安全重要性
微盟删库事件
思考时间
五大法宝
问题意识
怎么一劳永逸地解决数据安全问题?

该思维导图由 AI 生成,仅供参考

你好,我是郭忆。
在前面的课程中,我们了解了数据中台在数据建设效率、质量和成本方面的内容。而除了快、准和省以外,数据中台还必须是安全的。因为如果不安全,你很可能出现和“微盟删库跑路”同样的事情。所以,为了让你能重视数据中台的数据安全,我简单说一下这件事儿的情况。
2020 年 2 月 23 日 19 点,国内最大的精准营销服务商微盟出现了大面积的系统故障,旗下 300 万商户的线上业务全部停止,商铺后台的所有数据被清零。始作俑者是一位运维人员,他在生产环境数据库进行了删库操作,而刚刚上市不久的微盟就因此遭受了巨大的损失,从 2 月 23 日宕机以来,市值已经蒸发了 30 亿港元。这件事儿堪称史上最贵的安全事件。
那么从微盟的教训中,我们能得到什么警醒呢?在数据中台中怎么防止出现类似的事件呢? 我想这或许是你需要认真思考的内容。安全问题可大可小,不出事情,你可能根本不会重视,但是一旦出现事故,就是灾难性的。在网易,我们对数据中台的安全管理是非常严格的。
在刚开始构建网易数据中台的时候,我们就重点考虑了数据中台的安全保障,我把它归结为五大法宝。
接下来,我就带你深入分析一下,希望学完这部分内容之后,你可以回答这样三个问题:
如何解决数据误删除问题;
如何解决敏感数据泄露问题;
如何解决开发和生产物理隔离问题。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了数据中台建设中的数据安全管理问题,并提出了五大法宝。首先介绍了数据备份与恢复机制,详细阐述了网易HDFS数据备份的实现方式。其次,讲解了垃圾回收箱设计,介绍了HDFS提供的垃圾回收功能以及其存在的缺陷,并提出了对HDFS Client进行修改的建议。接着,文章详细介绍了精细化的权限管理机制,以及OpenLDAP、Kerberos和Ranger在数据中台中的应用。通过对这些技术的深入解析,读者可以快速了解数据中台建设中的数据安全解决方案,为解决数据安全问题提供了有益的参考。 在面对数据中台建设中的数据安全问题时,本文提出了五大法宝,包括数据备份与恢复机制、垃圾回收箱设计、精细化的权限管理机制、操作审计机制以及开发和生产集群物理隔离。这些法宝涵盖了数据安全管理的多个方面,为读者提供了全面的解决方案。此外,文章还介绍了不同企业对于安全性和效率的不同诉求,以及针对这些诉求的两种部署模式。通过本文的阐述,读者可以深入了解数据中台建设中的数据安全问题,并根据实际情况选择适合自身企业的解决方案。文章内容丰富,涵盖了数据安全管理的多个方面,对于数据中台建设中的安全问题具有重要的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《数据中台实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(13)

  • 最新
  • 精选
  • 吴科🍀
    引入权限管理,肯定会影响研发效率的。最好在项目开始前就引入。任务上线后再加入权限,要在开发环境严格测试,否则可能会任务因权限不足报错。 老师例子中,开发与生产两套集群用一个元数据的方案,提高了开发效率。但是,如果开发中要创建删除表,怎么避免不影响生产呢。 今天这一讲的5个最佳实践都很不错,很有借鉴意义。

    作者回复: 你好,吴科,每次一更新,就看到你的留言,非常的感动,感谢你的一路阅读~ 两套集群共享Metastore,在网易数据中台中,模型的创建和删除都是要通过第6讲模型设计中心中,通过工单完成的。 对应下来,比如da_music 项目,生产、测试集群物理隔离的环境下,平台会默认初始化两个库,一个是da_music_dev一个是da_music_online,开发模式下,我们提交任务是用的个人keytab,生产模式下,我们提交任务使用的项目keytab,因为keytab不同,所以我们可以限制,da_music_online只对项目keytab有更新和删除权限,个人keytab只有读取权限。这样就解决了你说的那个创建删除表,影响生产环境的问题了~ 感谢你的阅读,也感谢你的认可,期待再次相会。

    2020-04-27
    16
  • 尹英順
    郭老师,请教一个问题,数据安全框架Knox+Ranger是否可以实现认证、授权和审计功能?这个框架中还需要Kerberos作为安全认证体系吗?

    作者回复: 你好,knox 主要是基于restful api实现的安全防护,在网易,大家还是比较习惯直接用spark或者hadoop客户端提交任务,如果你们已经全部实现了Spark的服务化,即使用restful api 提交spark任务,我认为和knox集成,是可以的。但是如果做不到完全服务化掌控,还是需要Kerberos的。

    2020-05-07
    2
    6
  • 西南偏北
    这里面最难实现的应该是那个权限管理那一块,如果不是开始就介入做起来,到后面会越来越难做,我们公司目前就是面临这个问题…

    作者回复: 所以你就明白我提这个问题的用意了吧。权限越早接越有利,越往后,成本越高,因为迟早都要接。 @aof我看到每次一更新,你就在留言区第一时间互动,真的非常感谢一路以来的阅读,下一次见~

    2020-04-28
    2
    3
  • 风轻云淡
    老师,开发环境就是冷备份集群吗?

    作者回复: HI,你好,不是的,冷备集群,主要是用来存冷数据,一般来说是归档数据或者备份数据,一般使用EC存储的方式降低存储成本。 你说的开发模式,是指生产、测试集群分离,开发模式对应的是灰度集群或者测试集群,这个集群一般运行的是测试数据。 灰度集群和冷备集群并不是一个概念。感谢你的阅读~ 祝好~

    2020-07-19
    1
  • 龙轼
    不错。很全面。顺便说下之前我们在HDFS上做了一个安全路径检查,防止人为的失误删除直接跳过垃圾回收站的行为

    作者回复: 你好,龙轼, 你说的是rm 命令-skipTrash可以跳过回收站,做cmd的检查是吧? 一些大文件,为了避免进入回收站,造成存储浪费,所以hdfs提供了相关的命令参数,可以跳过回收站。 我觉得,避免hdfs数据误删除,主要是第一个区分对应的人是否有删除权限,另外就是有权限的人误删除之后,有恢复的机制,回收站就是后者。 感谢你的留言,也感谢你的肯定,祝好~

    2020-05-15
    1
  • Jie
    这里提到的全钻取是不是可以用黑盒模型来实现?

    作者回复: 你好,你说的是全维度钻取吗? 全维度钻取是基于数据中台的元数据实现的,数据中台中,一个指标有哪些可分析维度,然后基于不同维度的数据对比,给出结论。

    2020-05-02
    1
  • Bill
    赞,很细致。

    作者回复: 感谢你的认可,安全无小事,希望对你能有帮助。欢迎你在留言区与我互动,我们下次见。

    2020-04-28
    1
  • JohnT3e
    在进行权限管理时,先构建权限体系,再按照资源本身的重要性和价值进行。特别是对于一些维度表,往往包含比较敏感和丰富的信息。也可以从平台或者工具上入手尽可能透明化,降低权限对开发的影响。其实,注意影响还是在前期投入如何解决好改造和开发新需求之间矛盾。可以通过类似灰度发布的做法,逐步改造迁移。 另外,发现两处typo: “此时对应目录下面会生成一个.snaoshot 的文件夹。”中的.snaoshot应该是.snapshot “为什么考虑 DistCp 呢?因为它支持增量数据的同步。它有一个 diifer 参数”中的diifer应该是differ

    作者回复: 你好,首先感谢你对文章中单词拼写的指正。 你说的是对的,权限的引入要越早越好,通过平台,降低权限的使用门槛。 感谢你的阅读~

    2020-04-27
    2
    1
  • 数据脱敏管理,貌似没有提到过,数据中台应该会提供数据服务脱敏的能力吧。
    2020-11-16
    1
    1
  • 数据小白
    看来我盟的黑历史 ,在业内已经闻名遐迩了~
    2023-04-04归属地:上海
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部