我希望保护存储在一个表中的事件,该表与其他表有关系.事件通过Windows服务插入,即连接硬件和从硬件读取.
在事件表中有PK,日期和时间以及3个不同的值.
问题是每个管理员都可以登录并插入/更新/删除此表中的数据,例如使用sql management studio.我创建触发器以防止更新和删除,因此如果管理员不知道触发器,他就无法更改数据,但如果他知道触发器,他可以轻松地禁用触发器并执行他想要的任何操作.
所以经过长时间的思考我有一个想法,在表中添加新的列(字段)并在此字段中存储类似校验和的内容,将根据其他值计算此校验和.此校验和将在插入/更新语句中生成.如果有人手动插入/更新某些东西,我会知道它,因为如果我用校验和检查数据,就会出现不匹配.
我的问题是,如果你有类似的问题,你如何解决它?校验和使用什么算法?如何保护免受删除声明(我知道PK中的空数,但这还不够)?
我正在使用SQL Server 2005.
Mil*_*vic 10
由于管理员有权在SQL Server上执行所有操作,因此我建议使用一种明显的审计解决方案.在这种情况下 - 捕获数据库或SQL Server实例上发生的所有事情并将其保存在一个明显的存储库中.如果拥有权限的人(如管理员)修改或删除存储库中的审计数据,则会报告该数据
ApexSQL Comply就是这样一个解决方案,它具有内置的完整性检查选项有几种防篡改措施可以提供不同的完整性检查,并检测篡改,即使它是由可信方完成的.为确保数据完整性,该解决方案使用哈希值.哈希值是使用唯一标识它的特定算法创建的数值
中央存储库数据库中的每个表都具有RowVersion和RowHash列.RowVersion包含行时间戳 - 上次修改行的时间戳.RowHash列包含使用其他表列值计算的行的唯一行标识符
当修改审计存储库中的原始记录时,ApexSQL Comply会自动更新RowVersion值以反映上次更改的时间.为了验证数据完整性,ApexSQL Comply根据现有行值计算行的RowHash值.现在更新了数据完整性验证中使用的值,因此新计算的RowHash值将与存储在中央存储库数据库中的RowHash值不同.这将被报告为可疑的篡改
为了隐藏篡改,我必须为RowHash计算一个新值并更新它.这并不容易,因为用于计算的公式是复杂且未公开的.但那还不是全部.RowHash值使用上一行的RowHash值计算.因此,为了掩盖篡改,我将不得不重新计算并修改所有后续行中的RowHas值
对于ApexSQL Comply中央存储库数据库中的某些表,RowHash值是根据其他表中的行计算的,因此为了覆盖一个表中的篡改轨迹,管理员必须修改几个中央存储库数据库表中的记录.不是防篡改,但绝对使覆盖钢化轨道非常困难
免责声明:我作为支持工程师为ApexSQL工作
您在服务器级别执行的任何操作都可以撤消.这就是它角色的定义,你无能为力.
在SQL 2008中,您可以请求使用X事件审核所述SQL服务器,请参阅http://msdn.microsoft.com/en-us/library/cc280386.aspx.这是符合CC标准的防篡改解决方案.这意味着管理员可以停止审核并执行其恶作剧操作,但会记录停止审核.
在SQL 2005中,建议的审计解决方案是使用分析器基础结构.正确部署后,这可以防篡改.您可以使用触发器和约束来阻止数据更改并审核DDL更改.如果管理员更改了触发器,则在审核中可以看到.如果管理员停止审核,则审核中也会显示此信息.
您是否将此计划作为针对流氓管理员的一次性操作或作为要添加到您的产品的功能?在应用程序周期中使用数字签名对所有应用程序数据进行签名可能会非常昂贵.您还必须设计一个安全方案,以显示记录未被删除,包括最后记录(即不是标识列中的简单间隙).例如.您可以通过BINARY_CHECKSUM(*)计算CHECSUM_AGG,在应用程序中对结果进行签名,并在每次更新后存储每个表的签名值.有人说,这会减慢你的应用程序,因为基本上你序列化每个操作.对于单个行cheksums/hashes,您必须在应用程序中计算整个签名,这可能需要您的应用程序尚未拥有的值(即,要为您的插入分配的标识列值).你想走多远?如果管理员获取您的应用程序并监视您的哈希值,以什么顺序(这是微不足道的实现),可以打破简单的哈希.然后他可以重新计算相同的哈希值.HMAC要求您在应用程序中存储一个秘密,这对于一个坚定的黑客来说基本上是不可能的.这些担忧可能看起来有些过分,但如果这是一个你卖的应用程序,那么只需要一个黑客就可以打破你的哈希序列或者hmac秘密.Google最终将确保其他所有人都了解相关信息.
我的观点是,如果你试图通过技术阻止管理员,你就会面临失败的战斗.该管理员是你一个人相信,如果这是你打破的情况下,这个问题是信任,而不是技术.
| 归档时间: |
|
| 查看次数: |
1983 次 |
| 最近记录: |