我希望这篇文章有助于在加密与屏蔽的讨论上提供一点"技术性的光"。想问我其他的问题吗！我们很好地给出了一个关于我们网站上的数据屏蔽和加密之间的区别的简单、朴素和肮脏的解释，而且我们还就这些差异编写了一个很好的教程。我们的公司总裁也参与了Securosis的Adrian Lane的博客文章，这篇文章讨论了数据屏蔽和加密，但我想花点时间给这三个问题增加更多的色彩，并在这个问题上再深入一点。这将有助于那些正在评估解决方案并需要"检查表"的人。1.-加密对于保护需要在某个时刻返回其原始值的数据非常有用，例如在传输过程中，存放在生产数据库中等。2.-当数据不需要返回原始值时，加密不是屏蔽的合适替代品，例如开发、单元和QA测试，加密保护数据，但只有在加密密钥安全的情况下。如果加密密钥被发现，它可以解锁所有东西。对于大多数数据屏蔽策略，没有"主密钥"。当然，与DMsuie的算法不同，这就是为什么我们的平台在确保非生产数据真正安全且不会受到损害（无论发生什么情况）时是铁定的。4.-如果加密用于在非生产环境中保护生产数据，则会带来技术问题。例如，像John这样的小名字在加密时是一个很长的字符串。这意味着数据库表可能无法存储整个加密字符串（通常列有一个指定的"宽度"，可能不够大，无法容纳加密字符串）。对于使用这些数据的应用程序也是如此，UI设计可能无法容纳这么大的字符串。5.-如果加密用于保护数据库或特定表，通常，使用该数据的应用程序需要在屏幕上显示之前对其进行解密。这意味着，尽管数据受到保护，不让用户通过访问数据库来浏览表，但在使用该数据库的应用程序中仍然可以使用敏感信息。这显然是生产场景所需要的，但是，在开发/QA中，这是一个安全风险。6.-使用DMsuite的数据屏蔽解决了与非生产环境和非生产活动中的数据相关的技术/风险问题，方法是使用原始数据作为算法的输入，以一致、可重复的方式永久性地更改开发数据，因此最终得到的数据质量是产品级的，但没有生产风险。我还被问到有关格式保留加密（FPE）的问题。FPE最明显的一点是，它仍然是加密的，尽管模糊处理的值保留了相同的格式，但实际上它只是一个混乱的数字/字符串，其格式与原始数据相同。这对于基于数字的数据是有效的，比如SSN和信用卡号码，但是当你把名字和姓氏转换成一个不现实的混乱字符串时，实际上会使开发人员/质量保证人员更难进行测试，因为数据不再是真实的。约会对FPE来说也是个棘手的问题。从本质上讲，FPE是一种点式解决方案，但它不能提供DMsuite数据屏蔽所提供的广度/深度。