恢复被篡改的账本数据库

  • 项目

适用于： SQL Server 2022 (16.x) Azure SQL 数据库Azure SQL 托管实例

发生篡改后如何恢复？

修复任何类型的篡改最直接的方法是将数据库恢复到可验证的最新备份。 为此，可以将数据库还原到不同的时间点，并使用更早的数据库摘要验证账本。 可以成功验证的最新时间点是保证不被篡改且可用于继续处理事务的时间点。 因此，请务必频繁备份，以尽可能接近篡改时间。 备份计划会自动为 Azure SQL 数据库完成。 尽管此方法很简单，但它有一个重要的注意事项：如果在发生篡改后执行了任何事务，则需要接受这些事务将丢失的事实，或者需要重新插入已验证事务的信息并重新计算数据库账本中第一个篡改事件后发生的这些新事务的哈希，从而手动修复账本表。

篡改类别

根据篡改的类型，在某些情况下可以修复账本而不丢失数据。 应考虑两类篡改事件。

篡改不会影响进一步的事务

篡改事件修改了账本中存储的某些数据，但不会影响任何进一步的事务。 这可能是因为在任何事务处理篡改数据之前就检测到攻击，或者因为攻击在影响数据时，不会影响新事务。 例如，如果使用账本表存储银行事务详细信息，篡改现有事务的详细信息不会影响新事务，新事务将处理当前余额。

由于篡改不会影响篡改事件后发生的任何事务，新的事务执行和生成的结果是正确的。 因此，理想情况下，应该在不影响这些事务的前提下使账本保持一致状态。

如果攻击者未篡改数据库级账本，则很容易检测和修复。 数据库账本与生成的所有数据库摘要处于一致状态，并且附加到数据账本的任何新事务都已使用早期事务的有效哈希进行哈希处理。 因此，生成的任何数据库摘要（即使对于发生篡改后的事务）仍然有效。 你可以尝试从备份（这些备份仍可使用账本验证验证为安全）中检索被篡改事务的正确表账本有效负载，并通过覆盖表账本中的篡改数据来修复操作数据库。 这将创建一个记录修复事务的新事务。

篡改进一步事务使用的受影响数据

篡改事件影响了以后由进一步事务使用的数据，从而影响其执行。 例如，在当前帐户余额存储在帐本表中的银行应用程序中，修改表的当前状态对于进一步事务可能会是灾难性的，因为它可能允许新的事务超支。

如果攻击者篡改了数据库账本，请重新计算块的哈希以使其内部保持一致（直到根据外部数据库摘要进行验证），那么将在无效哈希上生成新的事务和数据库摘要。 这会导致账本中的分叉，因为生成的新数据库摘要映射到无效状态，即使使用早期备份修复账本，所有这些数据库摘要都永久无效。 此外，由于数据库账本已损坏，因此在验证这些事务之前，你不能信任有关篡改后发生的事务的详细信息。 因此，也许可通过以下方式还原篡改：

  1. 使用备份还原已篡改事务的状态。
  2. 验证账本从备份恢复的最后一个事务之后直到账本结束的部分。 为此，必须使用链分叉部分的数据库摘要。 尽管数据库摘要与账本的原始部分不匹配，但它仍然可以验证账本的分叉部分尚未篡改。 如果这些也显示篡改，这意味着发生了多个篡改事件，并且需要以递归方式应用进程，以便从备份中恢复账本的不同部分。
  3. 通过重新插入已验证事务的信息并重新计算数据库账本中第一个篡改事件之后发生的这些新事务的哈希，手动修复表账本。

相关内容