• 数据屏蔽:静态与动态


    数据屏蔽问题在 IT 领域经常出现。任何时候您需要共享一些潜在的敏感数据,您可能需要隐藏、混淆、随机化或以其他方式隐藏其中的一些数据——我们将其称为秘密数据。

    在本文中,我们将重点关注数据屏蔽机制并掩盖一个大问题:数据分类——了解谁可以访问哪些数据。数据分类是一个完全不同的问题,尤其是在拥有大量敏感数据的组织中。我会向您推荐另一篇涉及该主题的文章。对于本文的其余部分,我们将假设此问题已得到解决并且我们知道谁可以访问哪些数据。问题是——我们如何隐藏秘密数据?

    数据屏蔽不仅适用于数据库——它还可以应用于文档、电子表格等,但这里我们将重点放在数据库上。

    进行数据屏蔽的方法有很多种,但总的来说,它们可以分为两类,每一种都有自己的优点和缺点。

    什么是静电掩蔽
    静态屏蔽是最简单的解决方案。给定一个包含一些秘密数据的数据库,您复制该数据库并编辑副本以屏蔽任何需要屏蔽的数据。然后您可以将副本提供给客户,他们可以随心所欲地使用它。

    当然,对于大型数据集来说,这可能不是一个微不足道的过程。想象一个具有数千个表和数十亿行(或更多)的关系数据库。但是有一些(昂贵的)工具可以帮助您完成这项任务。

    优点
    很明显,静态屏蔽是一个非常干净的概念。这与拿一把剪刀剪掉文件的一部分是一样的。副本中不存在机密数据,或者至少不可读,因此不存在泄露风险。最终用户根本没有秘密数据。

    对于简单的数据库,您甚至可能不需要任何工具:一些简单的SQL 脚本(或您的数据库使用的任何语言)可能就足够了。

    由于不存在秘密数据,您可以将屏蔽数据库的物理副本提供给客户,让他们在自己的机器上运行。

    缺点
    数据的重复可能是个问题。它需要更多的存储空间和一个浮动的数据库副本。这通常不是问题,例如,如果您要向公众发布数据库;因此,只有一个版本的屏蔽数据库。

    但是,如果不同的客户有不同的要求,您可能需要制作多个数据库副本,每个副本都有一组可能不同的关于屏蔽哪些数据的规则。当然,如果您对不同的客户端有不同的规则,您现在不得不担心每个客户端只能访问他们自己的自定义版本的数据集,而不能访问其他任何人的。跟踪所有这些可能会变得很有挑战性。

    另一个问题是副本是数据库的快照,可能需要定期更新。每次这样做都是犯错的机会。

    最后,我们生活在大数据时代。有些数据集确实非常庞大,制作和分发此类数据集的副本可能是一项艰巨的任务。

    什么是动态掩蔽
    动态掩蔽采用不同的方法。数据不是制作数据副本并更改副本,而是在数据到达用户之前在访问时即时修改,从而为同一数据库的每个用户提供可能不同的数据视图。请注意,这不会影响数据库——它只会影响用户查看数据的方式。

    这假定您控制数据库并且客户端通过某种网络访问它。如果用户控制了数据库,他们就可以轻松绕过屏蔽。

    一般来说,动态屏蔽可以由数据库本身完成,也可以由数据库服务器和数据库客户端之间的一层完成。

    例如,Microsoft SQL Server 提供了一些动态数据屏蔽功能,这对于许多场景来说可能就足够了。PostgreSQL 有Anonymizer 扩展。SQL Server 中的数据屏蔽是一项强大的功能,但它也有一些局限性。

    一些第三方解决方案在数据库外部提供数据屏蔽,但它们通常依赖于特殊的驱动程序或特殊的客户端。一种更通用的方法是基于代理过滤,它依赖于深度数据包检查和修改以在数据到达客户端之前屏蔽数据。

    优点
    动态掩码的最大优势在于,理论上,它允许您只为每个人使用一个数据库。这避免了我们之前发现的静态遮蔽的大部分问题。

    动态数据屏蔽还意味着您可以更新数据屏蔽规则(通常是即时更新),并随时限制或扩大某些客户端对某些数据的访问。屏蔽不仅仅取决于用户是谁:它还可以取决于他们的 IP 地址、一天中的时间或我们所处的DEFCON 级别——你明白了。

    客户可以立即访问新的和更新的数据,因此数据流通问题消失了。

    动态数据屏蔽意味着您正在控制数据库。您可以(并且可能应该)监控客户在做什么。如果以后出现问题,这对于取证分析至关重要(想想Cambridge Analytica)。在某些环境中,甚至可以通过合同强制执行数据机密性,只要您密切关注客户如何使用数据库即可。

    缺点
    动态屏蔽可能不太安全,因为用户实际上连接到包含秘密数据的数据库。如果客户端使用复杂的查询语言(如 SQL)访问数据,那么可靠地屏蔽数据并非易事。例如,Microsoft在其 SQL Server 数据屏蔽文档中特别警告了此问题。如果这是一个选项,这可以通过使用查询控制来管理。

    动态遮罩也可以是一个更复杂的解决方案,具有更多的移动部件。解决方案越复杂,出错的可能性就越大。

    结论
    通常情况下,没有完美的解决方案:只有一系列需要根据要求进行权衡的权衡。

    如果您的数据集的大小是可管理的(这在很大程度上是一个相对概念),那么制作数据库的副本并在副本上进行屏蔽可能是实用的。如果您可以接受我们已经概述的缺点,那么这是一个很好的方法。简单的解决方案通常是最安全的。

  • 相关阅读:
    抖音很火的情侣公众号天气推送
    C语言--每日五道选择题--Day3
    下篇:技术 Leader 的思考方式
    leetcode:507. 完美数(python3解法)
    聊聊不是产品经理的程序员如何做产品经理
    模型进行MindIR格式文件导出时报错,请问如何定位错误,以及如何解决?
    HDR和泛光
    Canvas 图片上传,JAVA后端使用 MultipartFile 接收
    Markdown(1):markdown设置标题、插入代码、插入图片、配置vscode插件
    Mysql主从同步配置
  • 原文地址:https://blog.csdn.net/vvoennvv/article/details/128124727