🛰️ 🏒 💆🏽 破坏***不仅仅是随机化 👨🏿‍🔬 🖕🏾 🤳🏼

银行中存在一个问题：开发人员和测试人员需要被授予对数据库的访问权限。根据中央银行的PCI DSS要求和个人数据法，有很多客户数据不能用于向开发和测试部门披露。

看起来只要将所有内容更改为一些非对称哈希就足够了，并且一切都会很好。

因此，它不会。

事实是，银行的数据库是一组相互关联的表。它们通过名称和客户帐号连接在一起。由其唯一标识符组成的某个地方。通过存储过程的某个位置（在此开始痛苦），该存储过程根据此表和相邻表计算通过标识符。等等。

通常的情况是，系统的第一个版本的开发人员已经在十年前死亡或离开，并且在新的虚拟机监控程序内部的旧虚拟机监控程序中运行的内核系统（以确保兼容性）仍在生产中。

也就是说，在匿名化所有这些之前，您首先需要了解数据库。

谁去人格化，为什么？

由于存在法律和标准，他们从事非人格化或掩饰。是的，测试“销售快照”要好得多，但是监管机构可能会撤销此类航班的许可证。也就是说，掩盖业务本身。

在生产系统和开发测试之间，任何去个性化设置都是相当昂贵且笨拙的层。

匿名化（掩盖）项目的目标几乎总是准备与存储在生产数据库中的真实数据尽可能相似的测试数据。也就是说，如果数据包含错误-而不是电子邮件，则电话被阻塞，而不是姓氏的西里尔字母，等等，那么，伪装的数据应具有相同的质量，但会发生变化而无法识别。第二个目标是减少用于测试和开发的数据库量。整个卷仅用于负载测试，而对于其余任务，通常会根据预定义的规则（数据库截断）来完成某个数据切片。第三个目标是在不同的伪装和截断数据库中获取相关数据。这意味着不同系统中不同时间的数据必须统一匿名。

就计算复杂性而言，取消个性化设置与一些具有极高压缩率的数据库存档几乎相同。该算法大致相似。区别在于归档算法已经经过了多年的磨练，并且已经达到了几乎最大的效率。并编写了去个性化算法，以便它们至少可以在当前基础上工作并且非常通用。个性化后的软件通常可以正常工作。这是一个了不起的结果-每晚可以研磨40 TB。碰巧的是，对于客户而言，在性能较弱的服务器上每周每六个月将数据库驱动一次去个性化设置比较便宜，这也是一种方法。

如何替换数据？

每种数据类型根据代码中可以使用的规则而变化。例如，如果我们将名称替换为带有特殊字符和数字的随机散列，那么最初的数据验证将立即在实际测试中产生错误。

因此，首先，去个性化系统必须确定在字段中存储什么类型的数据。取决于供应商，使用了不同的方法，从手动标记到尝试发现数据库并自动检测存储在数据库中的内容。我们的做法是向市场推出所有主要解决方案。当有一个向导尝试查找数据并“猜测”其中存储了哪种数据时，我们将分析选项之一。

自然，要使用此软件，您需要访问实际数据（通常是数据库最近备份的副本）。根据银行业的经验，我们首先签署一吨文件，为期两个月，然后我们来到银行，我们穿衣服，搜身和穿好衣服，然后我们进入另一个房间，房间里放着一个法拉第笼子，里面有两个保安人员，并在脑后温暖地呼吸。

因此，假设在所有这些之后，我们看到一个表，其中有一个字段“名称”。该向导已经为我们将其标记为名称，我们只能确认并选择取消个性化的类型。向导会随机替换斯拉夫名称（有不同地区的据点）。我们同意并得到像伊凡·伊凡诺夫·彼得伦科（Ivan Ivanov Petrenko）-约瑟夫·阿尔贝托维奇·钦奇古克（Joseph Albertovich Chingachguk）这样的替补人选。如果这很重要，则保留性别；如果不保留，则替换将遍历整个姓名数据库。

替换示例：

. ->
->
->
->
-> -

下一个字段是Unixtime中的日期。向导也确定了这一点，但是我们需要选择去个性化功能。通常，日期用于控制事件的顺序，当客户先在银行转账然后开设帐户时，没有人真正需要测试。因此，我们会在30天内默认设置一个小的增量。仍然会有错误，但是如果这很关键，则可以通过将脚本添加到匿名化处理中来配置更复杂的规则。

该地址必须经过验证，因此使用俄语地址数据库。卡号必须与真实号码相对应，并经过验证。有时，任务是“使所有Visas随机万事达卡”-只需单击几下，这也是可行的。
向导的内部是配置文件。分析是根据预定义规则（属性，域）在数据库中搜索数据。实际上，我们读取客户数据库的每个单元格，对每个单元格应用一组正则表达式，将该单元格中的值与字典进行比较，等等。因此，我们在数据库表的列上具有一组触发规则。我们可以配置分析，无法读取数据库中的所有表，只能从表中获取一定数量的行或一定百分比的行。

里面到底是怎么回事

对于数据库中的每个条目，我们选择的去个性化规则都适用。在这种情况下，将在整个过程中创建临时表，并在其中写入替换内容。数据库中的每个后续记录都是根据这些替换对应表运行的，如果那里有对应关系，则以与以前相同的方式替换它。实际上，根据您的脚本和模式匹配规则，一切都会稍微复杂一些（例如，可能不正确的替换方法，例如，分娩或替换以其他格式存储的日期），但是通常的想法是这样。

如果有标记的对应关系“名称是西里尔字母-名称是拉丁字母”，则应在开发阶段清楚地指出它们，然后在替换表中它们将彼此对应。也就是说，该名称将以西里尔字母匿名，然后，例如，该匿名条目将转换为拉丁字母。在这一点上，我们正在远离“不提高系统中数据的质量”的方法，但这是为了某种系统性能而必须做出的折衷之一。实践表明，如果压力很大的功能测试没有发现其工作有任何妥协，那么就什么也没有。重要的一点是，整个非人格化不是加密。如果您在表中有几码输入，并且其中十个TIN不变，那又如何呢？一无所获，找不到这十条记录。

在该过程结束之后，转换表保留在去个性化服务器的受保护数据库中。该基数被剪切（截断）并在没有转换表的情况下传递给测试，因此，对于测试人员而言，去个性化变得不可逆转。

完整的匿名数据库将传递给测试人员以进行压力测试。

这意味着在使用数据库时，转换表会“膨胀”（确切的数量取决于替换的选择及其类型），但是工作基数保持原始大小。

该过程在操作员界面中是什么样的？

IDE的一般视图，使用其中一个供应商作为示例：

调试器：

从IDE开始转换：

配置表达式以在探查器中搜索敏感数据：

带有探查器规则集的页面：探查器

的结果，带有数据搜索的网页：

数据库中的所有数据是否都被屏蔽？

没有。通常，用于个性化处理的数据列表受该领域的法律和标准监管，此外，客户还对没人应该知道的特定领域提出了建议。

逻辑是，如果我们在医院掩盖患者的姓名，则可以掩盖或不掩盖诊断-仍然没人会知道他是谁。我们曾遇到过这样一个案例，即银行交易记录只是简单地用随机字母掩盖。级别上有注释：“贷款被拒绝，因为客户喝醉了，他呕吐到酒吧。”从调试的角度来看，它只是一个字符串。好吧，让她留下。

策略示例：

动态种子表是一个转码表，我们在其中添加了已经发生的重新编码。哈希值可能会非常不同，在使用相同TIN的情况下，通常会生成一个新的随机TIN，其中存储的第一个字符以及校验位。

是否可以使用DBMS本身更改数据？

是。在对数据进行个性化处理时，有两种主要方法-使用数据库本身更改数据库中的数据或组织ETL流程以及使用第三方软件更改数据。

第一种方法的主要优点是您无需在任何地方从数据库中取出数据，没有网络成本，并且使用了快速且优化的数据库工具。关键的缺点是每个系统都需要单独开发，缺少针对不同系统的通用转换表。需要转换表来实现个性化的可再现性，以及系统之间的进一步数据集成。

第二种方法的主要优点是，无论是哪个数据库，系统，文件还是某种Web界面都无关紧要-实施规则后，您可以在任何地方使用它。关键在于，您需要从数据库中读取数据，使用单独的应用程序对其进行处理，然后将其写回到数据库中。

实践表明，如果客户拥有一组需要进一步集成的系统，那么只能以第二种方法来实现最终的成本成本以及可接受的开发时间。

也就是说，我们可以做任何我们想做的事，但是ETL方法已经在银行业证明了自己的优势。

以及为什么数据根本不会手动损坏？

此操作只能执行一次。某人将坐三天，对一堆数据进行个性化处理，并准备一个包含500-1000条记录的数据库。困难在于必须定期重复该过程（随着数据库结构的变化以及新字段和表的出现），并且要大批量（针对不同类型的测试）重复该过程。常见的请求是取消对数据库的前10-50 GB的个性化设置，以使该数量平均分配到每个表上。

如果文档扫描存储在数据库中怎么办？

如果可以将文档简化为XML并转换回（例如，office文档），则还可以将其个性化。但是有时候，有些二进制文件，例如PDF / JPG / TIFF / BMP中的护照扫描。在这种情况下，普遍接受的做法是向相似的文档提供第三方脚本，并用随机生成的文档中的样本替换真实的文档。最困难的事情是在照片中，但也有类似服务，这是解决问题的方式都大体相同。

谁负责什么？

在更改软件或“追赶”之后进行更新时，过程会更简单。

但是，如果测试出现问题怎么办？

这通常会发生。首先，测试人员在进行第一次去个性化设置后，会更精确地制定对数据库的要求。我们可以更改取消人格化的规则或拒绝记录，例如“此处的操作应按时间顺序进行，而不要混乱”。其次，根据实现的不同，我们要么支持在数据库更改时取消个性化设置，要么保留所有文档，数据库结构和处理类型的说明，转移整个处理代码（xml / sql中的规则）并培训客户专家。

如何观看演示？

最简单的方法是通过PSemenov@technoserv.com给我发送电子邮件。

破坏***不仅仅是随机化