创建一个简单的不可否认/防欺诈系统
如果我想创建一个简单的欺诈证明和不可否认系统，我应该考虑哪些关键功能？对于这个问题，我主要关注数据库行的完整性。这不是安全权限问题。
以足球数据库为例，我要实现的一些关键功能是：
防止 DBA 使用传统 SQL 修改行数据。例如，如果数据库行已经存储了 2:1 作为结果，如果 DBA 将结果更改为 2:3，我们应该能够检测到修改。所有更改都应通过主应用程序完成。
防止使用后端更改将一行数据复制到另一行。我们应该能够检测到欺诈更改。
为了让我的系统更能防欺诈，我还应该考虑任何其他问题或功能吗？我应该注意哪些最佳实践？任何指示将不胜感激。
非常感谢。
What are the key features should I consider if I want to create a simple fraud proof and non repudiation system? For this question, I am mainly concentrating on the integrity of the database rows. This is not a security permission question.
Using a soccer database as an example, some of the key features that I would implement are:
Prevent DBA from modifying the row data using traditional SQL. For example, if the database row has already stored 2:1 as the result, if DBA changed the result to 2:3, we should be able to detect the modification. All changes should be done via the main application.
Prevent the copying of a row of the data to another row from using the backend changes. We should be able to detect the fraud changes.
Are there any other issues or features I should consider to make my system more fraud proof? What are the best practices that I should be aware of? Any pointers would be most appreciated.
Many thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
创建一列作为其他列的加密签名。只要 ID 包含在签名计算中，您就无法复制行，因为 ID 会发生变化。如果不重新计算哈希值，则无法执行任何修改，因此 DBA 的更改也可以被检测到。
请注意，这并不能解决 DBA 删除行的问题 - 它只是验证每个单独的行是否都经过了适当的业务逻辑。您可能会包含整个表的签名，但这开始变得相当沉重！
当然，在某些时候您需要一个秘密——签名密钥的私有部分。您的代码需要访问该...并且无论谁编写该代码都可能包含后门，以便通过电子邮件向自己发送私钥等。迟早您必须信任某人 ，我怀疑。 （当然，您可以应用来自不同团队的多个签名 - 因此这些团队必须串通才能伪造任何东西。）
Create one column which is a cryptographic signature of the other columns. So long as the ID is included in the signature computation, you couldn't copy a row because the ID would change. No modifications could be performed without recomputing the hash, so the DBA's change would be detectable too.
That doesn't tackle the problem of DBAs removing rows, mind you - it only validates that each individual row went through the appropriate business logic. You could potentially include a signature for the whole table, but that starts getting pretty heavy!
Of course, at some point you need a secret - the private part of the signature key. Your code will need access to that... and whoever writes that code could include a back door to email themselves the private key etc. Sooner or later you have to trust someone, I suspect. (You could apply multiple signatures, of course, from different teams - so the teams would have to collude in order to forge anything.)
直言不讳：你在浪费时间。
DBA 拥有相当于数据库 root 的访问权限。如果没有，他们的效率就会很低。系统管理员也会遇到同样的问题，基本上你能做的任何事情充其量都只是安慰剂。对于具有该级别访问权限的恶意人员，您唯一能做的就是不向他们提供访问权限。
您能做的最好的事情就是通过创建审计跟踪来使其变得稍微困难一点。记录用户何时登录、注销、做了什么、系统响应什么事件等等。其唯一真正的价值是，如果您手动决定稍后查看它，则能够（希望）重建发生的情况。
至于改变足球比赛的结果，问问自己这种情况发生的可能性有多大。当然，这实际上并没有改变足球比赛的结果。它只是改变了记录的方式。任何看到或参与过的人都会知道实际结果，那么有人在系统上更改它有什么价值呢？
在公司中，错误和恶意是通过和解流程处理的。股票经纪人将拥有一个团队来运行系统上的报告，并将其与实际完成的银行交易进行比较。任何差异都会被标记为红色。因此，您可以更改系统上的余额，但它会得到备份。
这个难题的另一部分是对 DBA 活动的限制并不能真正解决问题。应用程序开发人员可以发布任意代码。即使经过审查，系统仍然可能在构建工程师或具有生产环境根级访问权限的人员编译修改版本并运行该版本时出现故障。
To be perfectly blunt: you're wasting your time.
DBAs have the equivalent of root access to your database. If not, they're going to be rather ineffective. The same issues arise with system administrators and basically anything you can do is little more than a placebo at best. The only thing you can do about A malicious person with that level of access is not give them the access to begin with.
The best you can do is make it a little harder by creating an audit trail. Log when users log in, log out, what they do, what events the system responds to and so on. The only real value of this is being able to (hopefully) reconstruct what happened if you manually decide to go in and look at it later.
As for changing the result of a soccer match, ask yourself how likely that is to happen. Of course it doesn't actually change the result of the soccer match. It simply change how it was recorded. Anyone who saw it or participated will be aware of the actual result so what value is there in someone changing it on the system?
In companies, error and malice and handled by reconciliation processes. A stockbroker will have a team that runs reports on what's on the system and compare it to bank transactions actually done. Any discrepancies get red flagged. So you could change your balance on the system but it will get backed up.
The other part of this puzzle is that restrictions on DBA activity won't actually solve the problem. Application developers can release arbitrary code. Even if it's reviewed the system can still break down at build engineers or someone with root-level access to the production environment compiling a modified version and running that.
这个问题我思考了几年，终于想出了一个合理的解决方案。 Jon 关于需要对 PK 访问和用于加密的系统有一定信任的说法是正确的。如果这一点受到损害，那么您就是 SOL。但是，您可以解决一些与输入和输出大小相关的问题。
1 - 散列记录（固定长度）
2 - 使用私钥加密记录（您可以选择算法，以便您高度确信加密的输出不会超出您的存储限制 - 我相信这里有更聪明的人可以解决这个问题）
3 - 使用 WORM 存储，以便不可能删除记录。是的，有人可以窃取驱动器来“删除它”...所以不完美...有人可能篡改我的实现或基础设施，这样我实际上就没有使用 WORM 存储...但这让我得到了一个相当好的结果地方。
再说一遍——就像乔恩说的……在某些时候你必须信任某人。
I've been thinking about this for a few years and have finally come up with a reasonable solution. Jon is right about needing to have some trust around PK access and the system used for encryption. If that is compromised, you're kind of SOL. However, you can get around some of the issues with size of input and output.
1 - Hash the record (fixed length)
2 - Use a private key to encrypt the record (you can select algorithms such that you have high confidence that the encrypted output will not exceed your storage limit -- I'm sure there are smarter people here that can clear that up )
3 - Use WORM storage so that record deletion is just not possible. Yes someone can steal the drive to "delete it" ... so not perfect... someone could tamper with my implementation or infrastructure so that I am non in fact using WORM storage.... but this gets me to a pretty good place.
Again - Like Jon said.... you've got to trust someone at some point.