如果我想创建一个简单的欺诈证明和不可否认系统，我应该考虑哪些关键功能？对于这个问题，我主要关注数据库行的完整性。这不是安全权限问题。
以足球数据库为例，我要实现的一些关键功能是：
防止DBA使用传统SQL修改行数据。例如，如果数据库行已经存储了 2:1 作为结果，如果 DBA 将结果更改为 2:3，我们应该能够检测到修改。所有更改都应通过主应用程序完成。
防止使用后端更改将一行数据复制到另一行。我们应该能够检测到欺诈行为的变化。
为了让我的系统更加防欺诈，我还应该考虑任何其他问题或功能吗？我应该注意哪些最佳实践？任何指示将不胜感激。
提前非常感谢。
创建一列，作为其他列的加密签名。只要 ID 包含在签名计算中，您就无法复制行，因为 ID 会发生变化。如果不重新计算哈希值，就无法执行任何修改，因此 DBA 的更改也可以被检测到。
请注意，这并不能解决 DBA 删除行的问题 - 它仅验证每个单独的行是否都经过了适当的业务逻辑。您可能会包含整个表的签名，但这开始变得相当沉重！
当然，在某些时候你需要一个秘密——签名密钥的私有部分。您的代码将需要访问该...并且无论谁编写该代码都可以包含一个后门，以便通过电子邮件向自己发送私钥等。我怀疑，迟早您必须信任某人。 （当然，您可以应用来自不同团队的多个签名 - 因此这些团队必须串通才能伪造任何东西。）
DBA 拥有相当于数据库 root 访问权限。如果没有，他们的效率就会很低。系统管理员也会遇到同样的问题，基本上你能做的任何事情充其量都只是安慰剂。对于具有该级别访问权限的恶意人员，您唯一能做的就是不向他们提供访问权限。
您能做的最好的事情就是通过创建审计跟踪来使其变得更难一些。记录用户何时登录、注销、做了什么、系统响应什么事件等等。其唯一真正的价值是，如果您手动决定稍后查看它，则能够（希望）重建发生的情况。
至于改变足球比赛的结果，问问自己这种情况发生的可能性有多大。当然，这实际上并没有改变足球比赛的结果。它只是改变了记录的方式。任何看到或参与过的人都会知道实际结果，那么有人在系统上更改它有什么价值呢？
在公司中，错误和恶意由和解流程处理。股票经纪人将拥有一个团队来运行系统上的报告，并将其与实际完成的银行交易进行比较。任何差异都会被标记为红色。因此，您可以更改系统上的余额，但它会得到备份。这个难题的另一部分是对 DBA 活动的限制并不能真正解决问题。应用程序开发人员可以发布任意代码。即使经过审查，构建工程师或具有生产环境根级访问权限的人员编译修改后的版本并运行该版本时，系统仍然可能会崩溃。
这个问题我思考了几年，终于想出了一个合理的解决方案。 Jon 关于需要对 PK 访问和用于加密的系统有一定信任的说法是正确的。如果这一点受到损害，那么您就是 SOL。但是，您可以解决输入和输出大小的一些问题。
再次 - 就像乔恩说的......你必须在某些时候信任某人。