安全关键应用程序 - 数据库行验证
这可能有点模糊，但我希望在 SO 的所有人员中，会有一些人以前遇到过此类问题。
背景
我们的应用程序是一个控制火车订单的 C# / .NET 服务。我们使用 LINQ-to-SQL 将铁路网络的状态和火车订单存储在 SQL Server 2005 数据库中。
我们有一个安全要求，COTS 软件本身不能被“信任”。
要求
因此，风险被捕获为：“SQL 服务器或操作系统修改静态或动态数据。”
我们的要求：“存储在数据库中的数据应经过验证，以便在读取时可以通过数据访问代码确认自上次提交以来数据没有更改。”
问题
我很想找到一种“自动”的方式来满足这个要求。
如果做不到这一点，有一种方法可以满足条件，而不必在数据库的每个表中创建列来存储计算的哈希值（然后我们必须在读取时对其进行验证）。
This is perhaps a little bit vague, but I'm hoping that in amongst all the people on SO there will be some who have ran into this type of issue before.
Background
Our application is a C# / .NET service that controls train orders. We use LINQ-to-SQL to store the state of the rail network and train orders in a SQL Server 2005 database.
We have a safety requirement that COTS software cannot be "trusted" per se.
Requirement
Thus the risk has been captured as: "SQL server or operating system modifies static or dynamic data."
Our mandate: "Data stored in the database shall be validated such that on read it can be confirmed by the data access code that it has not changed since the last commit."
Question
I would love to find an "automagic" way of fulfilling this requirement.
Failing that, a way to satisfy the condition without having to create columns in every table of the database to store computed hashes in (that we then have to validate against when reading.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
也许像 MD5 校验和这样的东西保存在与主数据相同或不同的表中。校验和将由您的 C# 应用程序生成，因此如果有人使用原始 SQL 进行更新，校验和将会关闭。
Maybe something like a MD5 Checksum that is saved in either the same or different table to the main data. The checksum would be generated by your C# application so if anyone did an update using raw SQL the checksum would be off.
那是微不足道的。在除快照之外的所有非脏读隔离级别下，读取的数据都是最后提交的数据。根据定义，自上次提交以来它没有发生变化（换句话说，如果它发生了变化，那么新值就是上次提交的值）。意外更改（因为要求提到“操作系统修改数据”）称为“数据损坏”，并由 页面校验和，或通过TDE。
也许真正的要求是，自从读入应用程序以来，数据库中的值没有发生变化？然后乐观并发控制，仅此而已确实如此。只需将每个“旧”值添加到 UPDATE WHERE 子句中，它就会自行处理。如果您没有更新任何行（并且您可以通过检查 @@ROWCOUNT 或使用 OUTPUT 子句知道这一点），那么您就知道该行已更改。还可以部署主动缓存。
That is trivial. Under all non-dirty-read isolation levels except snapshot, the data read is the last committed data. By definition, it has not changed since the last commit (in other words, if it has changed then the new values are the last commit). Accidental changes (since the requirements mention 'OS modifies data') are called 'data corruption' and are captured by page checksum, or by TDE.
Perhaps the real requirement is that the value has not changed in the DB since read into the application? Then Optmistic Concurency Control, that's all there is to it. Simply add every 'old' value to your UPDATE WHERE clauses and it will take care of itself. If you didn't update any row (and you'll know that by either checking @@ROWCOUNT or by using an OUTPUT clause), then you know the row has changed. Proactive caching can also be deployed.