数据库水印算法(方案一)

数据库水印,解决方案一

1、可行性说明

  在调研中以及平时所见的数据表中得出一个规律:表与表的主外键关联,很多时候并不是有效数据,而是辅助的数据;还有就是有数据库访问权限的人很少,对没个层级来说,可使用数据的用户(直接访问数据库的用户)是少量的。
  基于上述规律,在不改变表间数据参照关系的前提下,将主外键进行变更,然后在生成的主外键上施加一定的隐含规则作为嵌入的水印信息,以此来保留数据的原始状态。一旦数据泄露,就可以通过提取的水印来追踪数据泄露的源头。该方案不仅可以在静态数据集上实施,也能在一定程度上支持动态数据集。
  溯源的出发点是为了在数据库中寻找有效的冗余空间,在不影响数据使用的前提下嵌入水印信息,并在数据泄露以后可以高效溯源。而主外键具有的优点刚好可以用来解决上述所有的基本要求:
    (1)水印嵌入位置较为灵活,可以自己动态的添加主外键值,且不需要过多额外的存储空间,不仅仅适用于小型系统,更符合当今大数据的背景;
    (2)可以用表结构变换(及一张表使用多个变换规则)来隐含一定的规则,以此作为嵌入数据表中的水印信息,这种算法对数据的类型没有任何限制;
    (3)由于主外键的关联性,攻击者一般不会破坏表间的主外键,因此可以抵挡元组攻击、属性攻击以及虚拟水印攻击等各种常见的数据库攻击类型,具有较好的鲁棒性。

2、相关介绍

  首先对算法中需要用到的变量或符号作一个说明。

2.1 水印系统需要维护的表有:

  字段属性表(attribute table)、用户层级表(K-Tree table)、密钥表(U-Key table)(此表应该是文件的形式放在本地以此保证密钥不会被泄漏,或者对密钥进行认证访问揭秘)
  字段属性表(attribute table):改表的功能,主要用来对原始数据表进行字段的划分,以此来让一个表可以适用多种规则,主要作用是,考虑到一个表字段可能会很多,而对于不用的用户来说,可以只会有权限查看一部份字段的值,因此也只可能泄漏一部分的值,所以我们还得从一部分的值中去溯源回来。如数据库原始表table1有如下属性:

原始表table1
priKey Name Pswd Tele Email Address

  那么我们就可以根据业务场景,及访问控制权限对表的字段进行划分,按照用户权限访问规则范围来划分,如:一个有3个权限角色,role1可以访问name、Tele,role2可以访问name,Email,role3可以访问name、address,那么就可以这样来构建属性拆分表:

table1_attrsplit
T Name Pswd Tele Email Address Scope
a1 1 0 1 0 0 x
a1 1 0 0 1 0 x
a3 1 0 0 0 1 x

说明:代表a1属性的,在表中对Scope范围内来处理嵌入数字水印,Scope一般用于有所有访问权限的人,起到一个混淆的作用,如DBA可以访问所有字段,经过他手的数据,就安范围来进行分属性加水印。
  用户层级表(K-Tree table):该 K-Tree 树状结构描述的数据分发的层级关系。树中节点的数据存储的是每个数据使用者的代号{U1,U2,…}。其中,根节点代表原始数据的拥有者,每个子节点的父节点代表上一级的数据分发者。如下,U0为数据原始拥有者:
在这里插入图片描述
  密钥表(U-Key table):该密钥存储表描述的是存储数据使用者的名称、代号以及对应的密钥和 0-1 属性表的表。
U-Key table

UserName User Code Key TN
U1 xx1 K1(U1) a1
U2 xx2 K2(U2) a1
U3 xx3 K3(U3) a2
DBA xx4 K4(U4) 1(代表所有属性)

2.2 系统需要用到的加密算法有:

  3DES(可以直接用国密,如果保密程度要求不是很高,一般对称加密算法都可以),算法主要用于对数据进行加密,不使用统一的密码,是为了防止被攻击。

3、算法描述

3.1 水印生成

  数据原始拥有者的数据在被分发之前根据业务场景对表的属性进行划分,配置规则。如下图所示。
在这里插入图片描述

  有3个用户,他们权限不同,所访问的字段属性也不相同,所以根据他们的访问权限,对表属性进行字段的划分。然后使用相应的密钥来对数据进行加密,加密后的水印信息去替换表的主键或者一个与他业务逻辑不相关的列,如果替换主键的话,就相应的要去替换其他关联表所引用的值,所以如果有不太强相关的字段,就直接替换字段的值,来存水印信息,这个可以用一个配置规则表来对每张表进行配置。

3.2 追踪溯源

  当发现数据疑似泄漏数据时,数据原始拥有者(或每个上级数据拥有者)通过相同的加密规则对原始数据加密,然后与泄漏数据比对,如果相同,则确认为泄漏数据。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章