数据屏蔽。静态与动态

在这篇文章中，我们将专注于数据屏蔽的机制，而忽略了一个巨大的问题：数据分类--知道谁可以访问什么数据。

在IT世界里，数据掩盖的问题经常出现，令人惊讶。 任何时候，当你需要分享一些潜在的敏感数据时，你可能需要隐藏、混淆、随机化或以其他方式掩盖其中的一些数据--我们将其称为 秘密数据.

在这篇文章中，我们将专注于数据屏蔽的机制，并掩盖一个巨大的问题：数据分类--知道谁可以访问什么数据。数据分类是一个完全不同的问题，特别是在拥有大量敏感数据的组织中。我将向你推荐另一篇涉及这个话题的文章。在本文的其余部分，我们将假设这个问题已经得到解决，并且我们知道谁可以访问什么数据。问题是--我们如何隐藏秘密数据？

数据掩蔽不仅仅适用于数据库 -- 它可以应用于文档、电子表格等，但在这里我们将重点讨论数据库。

有许多方法可以进行数据屏蔽，但一般来说，它们可以分为两类，每一类都有自己的优势和劣势。

静态掩码

静态掩码是最简单的解决方案。给定一个包含一些秘密数据的数据库，你复制该数据库并编辑该副本，以屏蔽任何需要屏蔽的数据。然后，你可以把副本提供给客户，他们可以对它做任何他们想做的事情。

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

优势

应该很明显，静态掩码是一个非常干净的概念。这与拿一把剪刀剪掉文件的部分内容的想法是一样的。秘密数据在副本中不存在，或者至少是不可读的，所以没有泄漏的风险。最终的用户只是没有秘密数据。

对于简单的数据库，你甚至可能不需要任何工具：一些简单的SQL脚本（或你的数据库使用的任何语言）可能就足够了。

因为秘密数据不存在，你可以给客户一份屏蔽数据库的物理拷贝，让他们在自己的机器上运行它。

缺点

数据的重复可能是一个问题。它需要更多的存储空间和一个更多的数据库副本漂浮在周围。这通常不是一个问题，例如，如果你向公众发布一个数据库；因此，只有一个版本的屏蔽数据库。

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

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

最后，我们生活在大数据的时代。有些数据集确实很庞大，制作和分发这种数据集的副本可能是一个令人生畏的提议。

动态屏蔽

动态屏蔽采取了一种不同的方法。与其制作一份数据副本并改变副本，不如在访问数据时，在数据到达用户之前，对其进行实时修改，从而为同一数据库的每个用户提供一个潜在的不同的数据视图。请注意，这并不影响数据库 -- 它只影响用户如何看待数据。

这假定你控制了数据库，而且客户是通过某种网络访问数据库的。如果用户控制了数据库，他们可以轻易地绕过屏蔽。

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

例如，Microsoft SQL Server提供了一些动态数据屏蔽功能，这可能足以满足许多场景的需要。PostgreSQL有Anonymizer扩展。SQL Server中的数据屏蔽是一个强大的功能，但它确实有一些限制。

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

优势

动态屏蔽的最大优点是，从理论上讲，它允许你只为每个人使用一个数据库。这就避免了我们前面指出的静态掩码的大部分问题。

动态数据屏蔽还意味着，你可以更新数据屏蔽规则，通常是即时更新，并在任何时候限制或扩大某些客户对某些数据的访问。而且，屏蔽不仅仅取决于用户是谁：它还可以取决于他们的 IP地址，一天中的时间，或者我们处于什么DEFCON级别--你明白的。

客户端可以立即获得新的和更新的数据，所以数据货币问题就消失了。

动态数据屏蔽意味着你在控制数据库。你可以（而且可能应该）监控客户正在做什么。如果以后出现问题，这对取证分析至关重要（想想剑桥分析公司）。在某些环境中，只要你密切关注客户如何使用数据库，甚至有可能通过合同强制执行数据保密性。

缺点

动态掩码可能不太安全，因为用户实际上是在连接到一个包含秘密数据的数据库。如果客户端使用复杂的查询语言（如SQL）来访问数据，那么可靠地掩盖数据是不容易的。例如，微软在他们的SQL服务器数据屏蔽文档中特别警告了这个问题。这可以通过使用查询控制来管理，如果这是一个选项的话。

动态屏蔽也可能是一个更复杂的解决方案，有更多的活动部件。解决方案越复杂，就越有可能出错。

结论

正如通常的情况一样，没有完美的解决方案：只有一系列的权衡，需要根据需求进行权衡。

如果你的数据集具有可管理的规模（这在很大程度上是一个相对的概念），对你来说，制作一个数据库的副本并在副本上做屏蔽可能是实用的。如果你能接受我们所概述的缺点，这就是一个很好的方法。简单的解决方案往往是最安全的。

但是，如果复制数据集是不切实际或不可取的，特别是如果你有多个客户有多种屏蔽要求，那么动态屏蔽可能是你唯一现实的选择。在这种情况下，你必须考虑数据库是否能满足你的要求，或者是否需要第三方的解决方案。即使你最终使用了数据库提供的数据屏蔽功能，你仍然可能从使用第三方工具来管理权限和数据分类中受益。