国科信安数据库安全增强管理系统技术白皮书资料讲解.doc

Good is good, but better carries it.精益求精，善益求善。国科信安数据库安全增强管理系统技术白皮书-国科信安数据库安全增强管理系统技术白皮书国家国防科技工业局信息中心地址：北京市海淀区中关村南大街5号北京理工大学院内电话：010-6891141368911809传真：010-68911904邮编：100081通信地址：北京8184信箱版权声明最后更新日期2010年4月著作权注意事项本书版权为国家国防科技工业局信息中心所有。未经国家国防科技工业局信息中心书面同意，任何公司、单位或个人不得以任何手段复制本书的部分或全部内容。对印刷错误的更正，所述信息谬误的勘误，以及产品的改进，均由国家国防科技工业局信息中心随时做出解释，恕不事先通知，修正内容将编入再版说明书中。-目录1.产品背景12.解决的问题33.系统结构64.部署方案75.功能与特点96.支持特性107.性能测试数据101. 产品背景随着计算机技术的飞速发展，数据库的应用十分广泛，深入到各个领域。数据库系统作为信息的聚集体，是计算机信息系统的核心部件，其安全性至关重要。小则关系到企业兴衰、大则关系到国家安全。在重要单位或者大型企业中，涉及大量的敏感信息。比如行政涉密文件，领导批示、公文、视频和图片，或者企业的商业机密、设计图纸等。为了保障这些敏感电子文件的安全，各单位广泛的实施了安全防护措施，包括：机房安全、物理隔离、防火墙、入侵检测、加密传输、身份认证等等。但是数据库的安全问题却一直让管理员束手无策。原因是目前市场上缺乏有效的数据库安全增强产品。数据库及其应用系统普遍存在一些安全隐患。其中比较严峻的几个方面表现在：（1）由于国外对高技术出口和安全产品出口的法律限制，国内市场上只能购买到C2安全级别的数据库安全系统。该类系统只有最基本的安全防护能力。并且采用自主访问控制（DAC）模式，DBA角色能拥有至高的权限，权限可以不受限制的传播。这就使得获取DBA角色的权限成为攻击者的目标。而一旦攻击者获得DBA角色的权限，数据库将对其彻底暴露,毫无任何安全性可言。（2）由于DBA拥有至高无上的权利，其可以在不被人察觉的情况下查看和修改任何数据（包括敏感数据）。因此DBA掌控着数据库中数据安全命脉，DBA的任何操作、行为无法在技术上实施监管。而DBA往往只是数据的技术上的维护者，甚至可能是数据库厂商的服务人员，并没有对敏感数据的查看和控制权。现阶段并没有很好的技术手段来约束DBA对数据的访问权限，因此存在巨大安全隐患，特别是在DBA权限被非法获取的情况下，更是无法保证数据的安全。（3）由于C2级的商业数据库对用户的访问权限的限制是在表级别的。一旦用户拥有了一个表的访问权限，那么表中的任何数据都具有访问权限。但是一个表中可能存在敏感和非敏感字段。对于敏感数据，只有特定权限的人才能访问。此时数，据库自身的安全控制就显得力不从心。（4）数据库系统是一个复杂的系统，根据已经公布的资料，数据库存在许多风险，其中不少是致命的缺陷和漏洞。举例来说，全球公认安全性出众的数据库产品在2006年1月发布了其季度安全补丁包中就修补了多个产品中的80多个漏洞。其中不少漏洞可以非常容易地被黑客利用。一旦遭到攻击，攻击者可能以DBA的身份进入数据库系统，也可能进入操作系统，下载整个数据库文件。从上面分析可以看出，仅靠边界安全防护(防火墙、防病毒、入侵检测、漏洞扫描)是不可能解决数据库相关的所有的安全问题。尤其不能解决数据库内部敏感数据的安全问题。公安部、国家保密局、国家密码管理局和国务院信息化工作办公室等部委于2006年出台了相关规定，要求信息系统，尤其是重要部门的信息系统要充分运用密码技术对信息系统进行保护。对于采用密码对涉及国家秘密的信息和信息系统进行保护的，密码的设计、实施、使用、运行维护和日常管理等，应该按照国家秘密管理有关规定和相关标准执行；对于采用密码对不涉及国家秘密的信息和信息系统进行保护的，应该遵照商用密码管理条例和密码分类分级保护有关规定和相关标准。另外，国家出台了相关规定，要求重要部门的信息系统对数据资产实行等级保护。对于信息系统中的信息资产，应该根据其敏感程度，指定不同的安全等级，实施不同的安全保护策略。为增强数据库系统的安全，满足数字资产等级化的安全防护要求，有选择性的保护数据库内部敏感数据的安全性，本产品通过在数据库管理系统的内核中嵌入自主研发的安全防护系统，通过字段级别的访问控制来达到对敏感数据的防护目的。敏感数据以乱码的形式存在，通过数字签名实现强访问控制，非授权用户（包含DBA）查看到的数据为空，而授权用户的使用则不受任何限制。并且本产品对于应用系统来说是完全透明的，不需要基于数据库的应用系统做任何改动。2. 解决的问题本产品基于自主技术，重点解决如下3个方面的问题：（1）敏感数据的乱码存储在没有进行安全性加强的商业数据库系统中，敏感数据的存储和备份是以明文形式进行的。很容易从文件系统中得到存储的内容。即使是进口的安全数据库产品，核心技术被别人掌握，且加密算法受到限制，安全性同样得不到保障。所以，存储媒体（如：硬盘、光盘、磁带等）一旦被盗，或者存储文件被非法复制，后果将不堪设想。针对该隐患，本产品采用加密算法，将敏感数据的编码进行混乱，从而将敏感数据进行乱码存储。这样，即使存储介质或存储文件丢失，由于有加密算法的保护，获得者也不能得到真正的敏感数据。通过这种方法，实现对敏感数据资产的分级保护。为保证系统的易用性，本产品支持完全透明的混乱过程。除BLOB类型的字段外，部署本产品不需要对应用系统进行重新编译。图1所示为透明混乱过程的示意图。图Error! No sequence specified.透明混乱过程示意图如图1所示，数据在存入物理存储时，敏感字段通过加密变换，以乱码的方式存储到物理数据库中。假设密钥是安全的且混乱算法强度足够，则数据的存储也是安全的。在这种情况下，入侵者或者存储介质获得者只能看到乱码，而不能得到真实内容。在检索时，首先进行授权的检验，对于授权用户，敏感字段的乱码经过解密变换，以明文的方式返回检索结果。对于非授权用户，则返回乱码或者空。（2）乱码敏感字段的高效检索安全性与可用性是矛盾的。采用乱码存储以后的一个问题是破坏了原有数据的偏序关系，数据库原来的索引机制因此失效，导致数据的检索性能被显著的降低。因为此时对敏感字段进行条件检索时，需要对整个字段进行解密变换，再进行顺序查找。在记录数或数据量庞大的时候，性能可能降低到不可以被接收的程度。这将是引起数据库安全增强系统应用受到阻碍的最大的因素。而对密文建立外部索引的方法，会导致多用户并发访问时的数据不同步以及事务机制的失效。本产品采用自主专利的乱码索引技术，在数据库管理系统内核建立乱码索引，将敏感字段的乱码存储对数据库访问性能的损失降到最低。当用户对某一敏感字段进行条件检索时，DBMS首先通过乱码索引完成范围查询，从而避免了全部解密。同时自动支持多用户并发访问时的数据同步以及事务机制。（3）增强的授权管理目前广泛采用的C2级商业关系数据库产品中存在管理员权限过大的问题。在某些情况下，会导致敏感信息的泄密。针对该安全隐患，本产品采用高级技术手段，增设安全管理员和审计管理员，限制DBA的权限，使得DBA不能随意查看被保护的关键数据。只有同时经过DBA授权和安全管理员授权的用户，才能进行被保护数据的存取。同时安全管理员的授权行为收到审计管理员的监督。图2给出增强的授权管理机制的示意图。安全服务业务系统分区加密数据数据库管理员审计管理员安全管理员图Error! No sequence specified.增强的授权管理机制的示意图如图2所示，在本产品中，增设一个安全管理员和一个审计管理员。安全管理员的增设可以限制DBA的权限，以此解决DBA可以读取数据库中包括敏感信息在内的所有信息的安全隐患。而审计管理员独立于安全管理员，实现对安全管理员授权行为的监督。3. 系统结构本产品的系统结构如图3所示。图3系统结构图如上图所示，本产品内嵌于DBMS中，作为数据库系统内核的一部分，和DBMS运行在同一进程空间，极大的提高了增强系统的安全性和可靠性以及效率，也保证了该系统的良好跨平台特性。应用程序端通过与改造前完全相同的方式连接DBMS，增强系统在DBMS内部对请求进行授权检验。对于授权用户，通过请求密码服务对数据进行加/解密操作。对于非授权用户，则直接返回空值，达到保护敏感数据的作用。系统管理配置模块用于安全管理员对敏感字段管理，安全操作员进行安全策略的应用，以及审计管理员查看审计信息。4. 部署方案单数据库服务器环境下，系统的部署方式如图4所示。图4系统部署结构图如图4所示，在单机环境下，系统的部署非常简单。将本系统（英文简称DB-SIMS）服务器接入数据库服务器所在的网络中，安全管理员和操作员仅仅需要通过浏览器在远程通过系统配置管理模块即可完成整个系统的安装和部署。在实际应用中，还可以将DB-SIMS服务器和数据库服务器部署于同一个服务器硬件之上。对于多服务器环境，系统的部署方式如图5所示。如上图所示，对于多个不同的数据库系统，可以统一的进行管理。只需将DB-SIMS服务器部署在相应的网络上，就可以通过管理终端，通过浏览器将DB-SIMS安装到不同的数据库平台上。即使是在外网的管理员也可以通过Internet与内网相联，并通过管理终端，实现敏感信息的安全管理。DB-SIMS服务器是网络服务器和DB-SIMS系统的安装服务器。管理终端PC连接到该服务器上将系统注入到各个数据库中。针对各个数据库的安全策略存储于各个数据库中，便于数据的统一备份。即使DB-SIMS服务器崩溃，也不会导致系统整个数据库的服务中断。管理终端可以分布在任意安全管理员或者审计管理员可以操作的计算机上，只要可以与DB-SIMS服务器相连，就可以通过浏览器进行相应管理。5. 功能与特点功能：1) 根据分级保护原则，对敏感信息进行字段级细粒度的乱码保存；2) 灵活根据防护需要设置敏感数据列的混乱算法；3) 增设安全管理员，实现对DBA权限的削弱，实现对敏感数据的责权一致，数据所有者管理数据的访问权限；4) 增设审计管理员，对安全管理员的授权情况进行独立的审计，保证每一个操作都有记录可查，实现对安全管理员授权行为的监督；支持多安全管理员，各自拥有安全域。特点：1) 系统直接运行在DBMS进程空间，减少了进程间通信的性能损失，最大程度的提高了系统的安全性和可靠性；2) 采用自主专利的乱码索引机制保证高效率的密文条件检索；3) 对敏感信息访问权限粒度控制在字段级；4) 提供基于浏览器的简单、友好、易操作的操作界面；5) 对于常规字段类型，混乱过程对应用程序访问过程完全透明，无需客户端做任何改动，最小化对其他系统的影响；6) 对于BLOB类型的字段，提供实现透明加密的API；7) 支持多用户并发访问，支持数据的同步，支持事务机制；8) 所有的授权信息和审计信息都通过PKI技术保证记录的完整性和不可抵赖性；9) 良好的跨平台特性，支持任何平台上的Oracle9i、10g数据库。6. 支持特性支持平台：本产品支持任何已安装Oracle9i、10g的平台，例如：l Windows2000,XP,2003l Linuxl Solaris，HP-UNIXl AIX等支持的安全算法：l 支持软件混乱和硬件混乱l 支持经国家批准使用的专用密码算法l 支持用户自定制混乱算法l 支持MD5,SHA算法支持全透明混乱字段：l NUMBERl RAWl CHARl VCHARl Date支持通过API实现透明混乱字段：l BLOBl BFILEl CLOB7. 性能测试数据测试环境：l 硬件配置：内存1G，CPU2GHZl 操作系统：WindowsXP,SP2l 混乱算法：3DES（软件实现，128位密钥）l 测试表：TEST，如下图所示l ID:主键（1） 敏感字段：DATA性能测试一：敏感字段不作为查询条件查询语句：select*fromtestwhereid<=N;表中记录数返回记录数保护前时间保护后时间（秒）有乱码索引无乱码索引1万00.00.00.01000.00.00.010000.80.80.810万00.00.00.01000.00.10.110000.71.81.850万00.00.00.01000.00.10.110000.61.21.2分析：在正常使用情况下（返回记录小于1000条），性能损失在原表的2倍以内。时间延迟受返回记录数影响，主要用于敏感数据的解密操作。（2） 性能测试二：敏感字段作为查询条件查询语句：select*fromtestwheredata<=N；表中记录数返回记录数保护前时间（秒）保护后时间（秒）有索引无索引有乱码索引无乱码索引1万00.01.20.00.81000.11.90.01.410000.73.41.12.810万00.01.10.010.81000.11.50.115.410001.02.61.516.650万00.00.90.247.91000.01.00.260.510000.62.21.061.8分析：在正常使用，并且有乱码索引的情况下（返回记录小于1000条），性能损失在原表2倍以内，时间延迟受返回记录数影响，主要用于乱码的解密。当记录数较多，且没有乱码索引的情况下，保护后对查询响应的效率较低。（3） 性能测试三：插入（insert）语句前置步骤：TEST表中预先存储十万条数据。测试结果：插入记录数保护前时间（秒）保护后时间（秒）有乱码索引无乱码索引1000.00.70.05000.03.20.210000.16.60.8分析：在使用乱码索引的情况下，由于插入数据需要建立复杂的乱码索引，需要消耗一定时间，所以效率有一定损耗。该速度可以被绝大多数保密系统所接受。当无乱码索引时，插入操作的性能损失不大。（4） 性能测试四：删除（delete）语句前置步骤：表中预先存储十万条数据。测试结果：删除记录数保护前时间（秒）保护后时间（秒）有乱码索引无乱码索引1000.03.40.05000.116.80.110000.21000.2分析：在使用乱码索引的情况下，由于需要维护扩展索引，因此删除操作比较耗时，性能有一定降低。性能降低与表中的记录数正相关。该性能可以被大多数保密系统所接受。在不使用乱码索引的情况下，删除操作的耗时和原表无明显区别。结论：从以上测试结果可以看出，本产品在对敏感信息进行乱码保护的同时，保证数据库系统对查询操作具有很高的性能。对于使用乱码索引的情况下，对敏感字段做条件查询，性能损失在2倍以内。对于插入和删除操作时性能有一定损失，但是可以被大多数保密系统所接受。可以根据实际情况决定是否使用乱码索引，以保证更高的响应性能。例如：对于需要对敏感字段进行大量条件查询而不需要大量插入和删除的情况下，可以通过建立乱码索引保证查询效率。而对于需要大量插入和删除的情况下，则可以不建立乱码索引。对于不需要对敏感字段进行条件查询，或者记录数较少（低于1万）的情况下，可以不建立乱码索引。