检测数据库篡改，有可能吗？

长时间的监听者，第一次的调用者。

'假设您有一个数据库表负责记录用户活动。此日志的完整性很重要，因此您希望能够检测是否有人修改了表中的任何数据。为了使事情变得更加有趣，还请考虑以下事实：您的系统可能由完全控制此可悲系统的邪恶SQL管理员操作。y ...

您将如何保护您的数据？

您将如何检测是否有人篡改了您的数据？

您可以使用无限的工具。（即哈希，加密等）

如果确实必须检测到已发生篡改，则将校验和字段添加到表中。每个新行的校验和必须包括上一行的校验和。然后，要验证内容，请在前进时逐步浏览计算校验和的数据集。如果计算出的校验和与表中的值不匹配，则表明某个值已被篡改。

-麦克风

如果“邪恶管理员”无权访问填充数据库的应用程序，则每个表上的额外一列将由其余列的加密签名组成。需要“禁止访问”条件，以使他们不能仅提取您的私钥并对虚假数据进行签名。

编辑：啊，正如评论者所指出的，我不认为管理员只是删除一行。为此，您将需要一个额外的行，该行具有每次更新的加密签名行计数（或其余表内容的签名哈希，上次访问时间或您选择的任何指示符）。

创建一个影子表，该表用您和应用程序都知道的密钥/盐对每个文件进行哈希处理。如果要检查数据篡改，请重新哈希用户表并与影子表进行比较。

如果您确实希望安全，请使用-为该表写入一次“读取许多介质”。

只需运行带有您的交易ID的纸质日志，然后将打印机放在只有一把钥匙的房间即可。使用财务系统，您会发现其中许多仍然依赖其纸质备份。几乎不可能“无法破解”纸质日志……这就是为什么人们不断推动投票机中的纸质日志的原因。

很多人说：“只要添加另一个数据库”，尽管我实际上在练习自己这种日志记录，但我并不信任它。恶意的内部人员可能会以多种方式破坏这种保护措施。

我们在这里所做的所有事情都是试图找到一种使事情发生的显而易见的方法。您将丢失日志。您将无法信任它们：如果我遇到了一个具有可靠日志记录系统的系统，那么我要么用垃圾数据填充它，要么就彻底擦除它。不要陷入Maginot的思路。

但是，如果您准备得足够多，以至于发生了太多的失败，那么您可以将破坏活动范围缩小到内部来源。您需要在数据库中四处浏览，需要保留大量的系统日志，需要监视IP流量，在服务器机房中放置摄像头，在控制台上放置键盘记录器等，等等。如果周围有足够的捕鼠器，则可能会在某个地方意外抓住它们。

让我们清楚一点：如果您假设使用Evil Sysadmin，则没有任何加密解决方案可以阻止他们以不可追踪的方式修改系统上的数据-有些解决方案可以防止他们能够解密信息，但没有其他解决方案可以阻止他们以他们认为合适的任何方式写新信息。

这种情况需要满足以下条件：

1. 该系统必然是独立的。如果您可以在Evil Sysadmin无法作为日志记录主机（例如syslog服务器）访问的情况下添加其他系统，那么问题突然变成了定期传输日志或哈希的琐碎情况。

2. 系统没有非软件一次写入组件。正如其他人所建议的，最简单的是打印机之类的东西，但是您可以使用CD或自定义一次写入硬件来防止出现此问题。如果Evil Sysadmin对计算机具有物理访问权限，则这些操作将变得更棘手，但并非不可克服。

3. 您需要确定性，而不是统计可能性。在＃1和＃2不可能的情况下，您唯一剩下的解决方案就是模糊化-如果Evil Sysadmin不了解陷阱，则将实施棘手的陷阱，以捕获篡改。

有效＃3的秘诀是战术上的意外。目的是向攻击者传达一种印象，即他们知道所有对策，而实际上却拥有他们不知道的更多信息。通常，这至少需要两个保护级别-您需要至少有一层保护，Evil Sysadmin可能会受到损害，因为他们会寻找它，而如果找不到，他们会得到保护可疑并深入研究，直到他们这样做为止。

重要的是，此封面应具有说服力，足以使Evil Sysadmin满意，以使他们一旦找到它，便无需再看了。然后，第二层使用替代技术来识别篡改并产生适当的警报。在此线程重新事务中有各种建议可以实现。解决方案的级别越低，成功的可能性就越大（即，与执行连接和查询的标准过程相比，修补数据库源代码的可见性要差得多，对内核的修补也不再那么可见，从而修改固件。） ）。

必须强调这不是一个完美的解决方案。无论您的设置多么复杂，都有可能有人发现/破坏了足够的信息来实施对策。＃1和＃2（正确完成）不是这种情况。就是说，如果您所保护的信息的价值足够低，以至于具有必要技能的人们对获取信息的兴趣将不大，则它应该提供可行的防御措施。

您可以使用触发器来审核插入，更新和删除。现在，如果“ evil SQL admin”禁用触发器，那么您将遇到一些更困难的问题。如果我想保护我的数据，我不允许邪恶的管理员完全控制系统。

每隔几个小时，哈希表的内容。还要记录开始和结束行。对于第二个哈希及以后的哈希，请对整个表的内容以及上一个哈希（检查哈希）中哈希的行进行哈希。如果先前的哈希值和校验哈希值不匹配，则表明数据库表已被篡改。我会将这些哈希发送给您，因此您可以检查流氓管理员是否已经通过并重新生成了所有哈希。我意识到仍然存在差距，但我认为除了这或已经提到的事情之外，还有更多的事情可以做（缺少删除他们的访问权限）。

考虑创建数据的滚动，快速，异地自动备份。如今，S3是如此便宜，以至于人们可能会mysqldump频繁地执行一种将整个数据存储库转移到Transatlantic备份存储库的类型过程。确切的频率取决于您DBA的邪恶性。

为了使该过程成为可能，只需在网络内部找到或设置一台机器，让邪恶的管理员一无所知，或者即使她怀疑有什么都不愿看。插电式计算机的简洁和优雅在这里不能被夸大。

注意实际的导出机制：不了解您的特定系统，我建议mysqldump还是将Oracleexp作为最简单，最愚蠢的解决方案。如果您的应用程序可以导出本机格式的数据（例如XML，JSON甚至协议缓冲区-换句话说，即SOA应用程序的各个部分用来相互通信的任何格式），那么format可以用作滚动转储的格式。

我已经在gitosis盒子上实现了这种方法。每三小时将内含物倒入欧洲S3桶中。这是另一个VCS的穷人VCS。

设置您的系统以将日志数据写入到邪恶的SQL管理员无法控制的远程系统中。这不会阻止该管理员删除或篡改您的日志记录程序，但会阻止他在事后修改它们。

这是一个常见的数据安全问题。简单的答案是-如果您只有一个“ evil SQL管理员”可以访问整个环境，那么您就无法保护数据。

关键任务数据的常见做法是登录到多个备份并通过确保没有任何人具有权限来进行保护。

如果您的应用程序始终在运行，则可以在数据库上启动事务，直到应用程序关闭后才释放它...这样一来，除了您的应用程序之外，任何人都无法查看该表...

同样可以，如果有时间，请对进出程序的所有文本字符串数据进行加密...

我也喜欢BobbyShaftoe的答案...不过，再进一步，看看是否可以使触发器进入“睡眠”状态，所以几分钟后所有记录都恢复原状...所以我们邪恶的管理员认为他进行了更改，但这些更改将被还原。

我认为这是一个很好的问题！但是您的方案违反了数据库的设计原则。

行校验和，触发导出到其他数据库-您所做的任何事情都是一种折衷方案！

我只能提出一些开箱即用的建议-如果您要应用某种类型的标准（例如PCI遵从性）会有所帮助吗？

如果失败了，我建议找另一份工作！我们行业中有足够的工作，您不需要与这些类型的人一起工作...

首先，请务必小心雇用谁来管理系统。

触发器填充的下一个审核表。即使他绕过更改触发器，您也至少可以查看更改之前的数据（尤其是备份数据）。

第三个自动备份已在异地删除。这样，即使坏人删除了数据库并删除了现场备份，您也有一个后备职位。确保数据库管理员无法访问异地备份，只有其他人拥有该权限，而其他人没有对该数据库服务器的生产权限。

接下来，除管理员外，任何人都没有对表的直接权限。这意味着使用没有动态SQL的存储过程。这至少防止其他人以未经授权的方式更改数据。现在，您的会计人员更难以进行欺诈。

除管理员和另一个作为备份外，其他任何人都没有生产管理员权限。这样，如果您发现触发器已更改，就知道是谁做的。现在出了问题，您只有两个嫌疑犯。

SQL Server 2008具有DDL触发器，可以告诉您进行了哪些结构更改。同样，如果触发器未记录更改，则默认情况下由管理员进行。

加密备份和某些个人数据，使其更难以窃取。现在，异地备份交付人员将很难再窃取您的数据。

即使证明不是他不值得信赖的数据，也要解雇所有被证明不值得信赖的管理员。如果他伪造时间表或窃取办公用品，他将窃取数据。如果他因犯下严重罪行（不是交通违法行为）而被捕，如果需要查看指控是否成立，可以将他停职。

当管理员决定转移到另一份工作时，请不要让他从告诉您要去的那一刻起就可以访问您的系统。如果您要解雇他，这一点尤其重要。

我发现这篇文章看起来很有趣，可能是一种可能的解决方案，尽管我还没有花时间去尝试利用漏洞。

我可以想象拥有两个独立的数据库，“邪恶的”系统管理员只能访问一个数据库。

一个数据库将向另一数据库提供一次性便笺簿，并记录谁请求该便笺簿以及何时请求。该填充以及当前时间和行数据可以被散列。

这样，如果邪恶的系统管理员更改了某些内容，则哈希将不会检出，并且如果他尝试重新哈希化，则将获得日志，记录何时应该发生什么事情。

如果系统管理员可以存储时间和一次性密码，则整个系统将崩溃。

这是一个看似困难的问题，我不确定任何协议是否真正有效，但是增加物理安全性和审计日志将是一个好主意。

如果要使用自动化方法，则首先必须知道该用户类型允许哪些操作和上下文。这是非常困难的，因为在适当的情况下，可以接受滴注，但对于日常用户而言则不可接受。

我确实喜欢纸质备份的想法，但是随着大量的用户群和大量的数据库使用，产生的信息量会很快变得非常安静。

我喜欢MikeMontana的解决方案，但我认为可能值得为其添加附录。遗憾的是我还不能发表评论，所以我将其发布在一个新的答案中，下面引用了原文：

如果确实必须检测到已发生篡改，则将校验和字段添加到表中。每个新行的校验和必须包括上一行的校验和。然后，要验证内容，请在前进时逐步浏览计算校验和的数据集。如果计算出的校验和与表中的值不匹配，则表明某个值已被篡改。

-麦克风

几个人指出：好的sysadmin可以重新计算校验和（如果您希望将代码编码在他的服务器上，甚至是一个问题），我为此添加了以下增强功能：

当将数据插入表中时，将使用公共密钥对其进行加密，因此任何人都可以将其添加到数据库中（假设您有多个人在使用它）。定期使用私钥解密数据并计算校验和。如果不同，则意味着数据库已被修改（要测试的内容）。然后，您重新计算校验和并将其插入表中（当然，公钥也被加密）。

如果邪恶的系统管理员尝试重新计算新的校验和，他将对加密数据执行此操作。

此外，如果您要远程访问该数据，则该方法可以通过在本地框上进行解密和校验和计算来抵御中级攻击。拦截的数据将保持加密状态，因此无法使用。

该系统的唯一缺陷是检测到数据库的任何事务。您可以抽象地解决此问题并说：

• 验证校验和
• 插入数据
• 重新计算校验和

但这消除了让任何人都可以访问数据而无需提供私钥的优势。

现在可以用另一种方式解决此问题，为此我建议您：

解决网格计算中的信任不对称问题

彼得·丁达（Peter Dinda）

http://portal.acm.org/citation.cfm?id=1066656

但实施细节变得更长。

虽然这里有一些很好的建议，但它们都会咬人。

因为您有一个“不受信任”的角色，即邪恶的管理员，作为您数据的保管人，您无法保护自己。网络协议和现实世界中存在多种方案，使您能够保护数据免遭不受信任的传输/快递公司的篡改。但是据我所知，没有什么可以像“您好。我是麦道夫先生，我曾经是纽约证券交易所的主席，您可以信任我。

电源/双电源控制分开。

我喜欢到目前为止已经提出的想法。我想加我自己的2美分。

在金融业中，权力分离对于保持一个人完全不邪恶是至关重要的。我们的核心处理解决方案由我们的簿记部门管理（祝福他们），所以我们程序员实际上并不能真正访问实时数据。

另外，第三方记录了与我们系统关键部分的交互。

总的来说，没有人能控制所有的制衡，使收益减少得足够多（以至于不值得协调）。

关于此主题有两篇引人入胜的研究论文，其中一篇提出了HMAC alogrith的用法。另一个提议使用压缩RSA方案和BGLS签名方案。

外包数据库中的身份验证和完整性

http://www.isoc.org/isoc/conferences/ndss/04/proceedings/Papers/Mykletun.pdf

关系数据库的一种通用无失真水印技术

http://www.dsi.unive.it/~cortesi/paperi/iciss09.pdf

我认为，根据已知的风险量，两者都是可行的解决方案。-基兰·库玛

除了审计，校验和等触发器之外，您还可以查看将数据库复制到另一个从数据库-没有人能够直接对其执行任何操作。

您仍然有可能会被触发器等弄乱，但是当他们被触发器弄乱时，这将是非常明显的，因此您可以检测到复制被破坏的那一点。

您可以添加一个触发器，以将数据副本发送到邪恶管理员也无权访问的非生产数据库中，以发送数据副本。管理员可以停止触发器的功能，但是问题是如何检测操纵，而不是阻止操纵。

由于您的管理员完全可以控制服务器，因此您可能需要一个外部审核解决方案，该解决方案旨在监视特权SQL Server用户的活动。

Guardium使网络设备可以记录数据库或服务器上的所有查询活动，并且它在网络级别（包括本地连接）进行记录，因此您无法在SQL Server级别进行任何干预。

这不会阻止您的恶意管理员更改表，但是，由于这是一个锁定的设备，因此恶意管理员无法更改表，然后说服设备说他没有这样做。

我在研究如何实施这种解决方案时找到了这个线程。我想到的一个（非常理论上的）解决方案就像使用完美的前向秘密密钥系统。

我的想法是，如果您有一个私钥-公钥对（称为Kpr和Kpb）和一组算法（A和B），那么：

（其中K'pr和K'pb是与Kpr和Kpb不同的有效私钥对）

使用此功能，您可以对数据库中的每一行进行签名，使用后丢弃所有私钥，但是将公钥与签名一起保存。然后，您可以将第一个公共密钥保存在邪恶管理员无法更改的位置（即，将其发送给您认识的每个人，将其打印在报纸上，在您的脸上刺青），所有上述这些。

由于不再有私钥，因此无法重新签名每条记录，并且您可以检查公钥是否全部是连续的。我只能想到两个缺陷：

• 如果邪恶的管理员获得了私钥的副本，那么他将可以更改此后的任何记录。可以通过使用硬件模块创建签名来规避此问题，因此无法从软件访问私钥。
• 邪恶的管理员将能够向表中添加数据。

问题是我不了解我所描述的一组算法。但是，我不是密码学家，所以有可能。

编辑：

经过更多的思考之后，我可能已经找到了一种使用现有工具实现此目标的方法。如果您要在第（n-1）条记录中包含第n条记录的公钥及其签名（您可以这样做，因为在编写记录时您可以访问下一个私钥）， d用上一个记录保护每个记录。删除私钥后，无法重新创建签名，因此，只要您拥有第一个公钥，您就可以始终验证整个表。这也消除了使用“顺序”私钥的需要，您可以简单地为每行生成一个新的私钥（尽管这会非常昂贵）。同样的缺陷仍然存在。

2016年该问题的答案将是使用区块链数据库。根据维基百科：

区块链主要通过将最近有效交易的批处理的哈希标记时间戳记为“块”来防止篡改，从而证明数据当时必须已经存在。每个块都包含先前的时间戳，形成一个块链，每个附加的时间戳会增强之前的时间戳。