数据库安全模式（精选十篇）
数据库安全模式 篇1
一、防火墙管理模式
防火墙技术是近期发展起来的一种保护计算机网络安全的技术性措施, 它在某个机构的网络和不安全的网络之间设置障碍, 阻止对信息资源的非法访问, 也可阻止专利技术从网络上被非法输出。也就是说, 防火墙是一道门槛, 用它来控制进、出两个方向的通信。防火墙技术是被动防卫型安全保障系统, 它的特征是在网络边界上建立相应的网络通信监控系统来实现安全保障, 要求所保护的网络是一个相对封闭的拓扑结构, 只是在有限出口与外界联络。建立防火墙就是利用专用安全软件、硬件以及管理配置, 对内部网络与外部网络之间的往来信息进行检测、控制和修改。防火墙最常采用的技术有数据包过滤 (Packet filter) 、应用网关 (Application Gateway) 和代理服务器 (Proxy Server) 。数据包过滤技术是根据数据包的源地址、目的地址、TCP (传输控制协议) 端口令等因素或它们的组合来综合判断, 只有满足逻辑条件才允许通过, 选择的判断依据即为系统内部事先设置的过滤逻辑包, 这一过程多在路由器上完成。防火墙系统一般由许多软件与硬件共同构成。其主要作用是在保护专用网络免受外部攻击的同时, 使网络用户能够在最低风险状态下访问公共网络。档案信息系统防火墙应能为档案信息的共享、交换提供如下安全保障:保证所有档案信息的共享、交换都是授权访问, 在转发所有信息流的同时能够逐项屏蔽掉可能有害的服务;能够封锁所有信息流, 只对需要的服务逐项开放, 以保证档案信息的共享、交换平台免遭攻击或非法入侵, 保护关键系统免受外部或内部的攻击;支持私有数据加密, 保证通过因特网进行的档案信息的共享、交换活动不受破坏, 具备反欺骗功能, 能够检测并屏蔽掉来自网络外部的非法数据包, 广泛支持WWW、HTTP、FTP等服务。采用防火墙的访问控制原则, 在网络层控制内外网之间计算机的互访、在档案专网和公网之间、在档案馆局域网和档案专网之间分别设立防火墙并建立相应的访问控制策略, 以限制馆内外用户的进出访问。通过防火墙也可以将馆内局域网划分为更细的网段, 如开放区、业务操作区和数据服务区等, 分别实施不同安全级别的管理。
二、C/S管理模式
在网络链接模式中, 除对等网外, 还有另一种形式的网络, 即客户机/服务器网, 即C/S。在客户机/服务器网络中, 服务器是网络的核心, 而客户机是网络的基础, 客户机依靠服务器获得所需要的网络资源, 而服务器为客户机提供网络必须的资源。档案馆内采用C/S运行模式, 管理方便, 运行效率高, 每个用户的操作权限是根据其业务需求来指定, 主要包括对系统的功能操作权限和数据操作权限两大类;档案专网内的授权用户可以采用C/S和B/S (浏览器/服务器) 两种模式访问业务数据, 其安全授权方式一方面通过档案馆与外网之间的防火墙访问控制策略进行限制;另一方面通过应用程序的身份认证来判断该用户是否是档案管理信息系统的合法用户, 来限制其访问权限。
1. C/S架构软件的优势。
一是应用服务器运行数据负荷较轻。最简单的C/S体系结构的数据库应用由两部分组成, 即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器, 也称为应用服务器。一旦服务器程序被启动, 就随时等待响应客户程序发来的请求;客户应用程序运行在用户自己的电脑上, 对应于数据库服务器, 可称为客户电脑, 当需要对数据库中的数据进行任何操作时, 客户程序就自动地寻找服务器程序, 并向其发出请求, 服务器程序根据预定的规则作出应答, 送回结果, 应用服务器运行数据负荷较轻。二是数据的储存管理功能较为透明。在数据库应用中, 数据的储存管理功能, 是由服务器程序和客户应用程序分别独立进行的、前台应用可以违反的规则, 并且通常把那些不同的 (不管是已知还是未知的) 运行数据, 在服务器程序中不集中实现。对于工作在前台程序上的最终用户, 无须过问 (通常也无法干涉) 背后的过程, 就可完成自己的一切工作。在C/S体系下, 数据库不能真正成为公共、专业化的仓库, 它受到独立的专门管理。
2. C/S架构软件的劣势。
Internet上的用户分布地域较广, 因此, 档案馆内部采用C/S运行模式是非常合适的, 但是C/S模式本身的缺点和不足也是很明显的:客户端需要安装专用的客户端软件。首先涉及到安装的工作量;其次任何一台电脑出问题, 如病毒、硬件损坏, 都需要进行安装或维护;再次, 系统软件升级时, 每一台客户机需要重新安装, 其维护和升级成本非常高。这也使得C/S构架具有了投资大且维护成本高的劣势。采用C/S架构, 要选择适当的数据库平台来实现数据库数据的真正“统一”, 使分布于两地的数据同步完全交由数据库系统去管理, 但逻辑上两地的操作者要直接访问同一个数据库才能有效实现。
三、人工同步安全管理模式
修改数据库状态以便修改归档模式 篇2
第一步【关闭数据库】： shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
第二步【打开数据库到mount状态】： startup mount;
ORACLE 例程已经启动。
Total System Global Area612368384 bytes
Fixed Size1250428 bytes
Variable Size142609284 bytes
Database Buffers461373440 bytes
Redo Buffers7135232 bytes
数据库装载完毕。
第三步【修改归档模式】： alter database archivelog;
数据库已更改。
第四步【打开数据库】：alter database open;
国产数据库复制“高铁”模式 篇3
2014年10月，IBM将开放Informix数据库源码给国产数据库厂商天津南大通用数据技术股份有限公司（以下简称“南大通用”）的消息引起了业界的广泛关注，根据协议，南大通用可以基于IBM Informix推出自有的数据库。如今该数据库正式对外亮相，这就是GBase 8t（t表示这是一款交易型数据库），它与南大通用原有的分析型数据库GBase 8a、安全数据库GBase 8s、内存数据库GBase 8m等共同构成了南大通用未来参与数据库市场竞争的产品组合。
“GBase 8t是南大通用基于IBM的Informix自主构造的面向国内关键行业应用需求的交易型数据库，它具有与Oracle、DB2等国际一流数据库产品一样的高稳定性、高性能和高可用性。”南大通用CTO武新在GBase 8t的产品发布会上表示。
GBase 8t的推出意味着我国有了一款具有自主可控能力的高端数据库产品，有了可以和这些一流数据库同台竞技的机会。据介绍，GBase 8t可胜任大并发量核心事务处理，具有完备的高可用集群解决方案；容易维护，可通过零宕机实现计划内数据库软件的升级和维护；具有完备的自我配置、自我管理、自我恢复的能力；支持云部署，完全可以部署于要求极为严苛的数据库应用环境，将为中国的数据库用户带来新的选择。
众所周知，我国的IT产业长期处于缺“芯”（CPU）少“魂”（基础软件）的尴尬局面。作为基础支撑软件的数据库就属于这里所说的“魂”之列。和操作系统一样，数据库的核心技术长久以来被Oracle、IBM等少数厂商把持，虽然国家从政策和资金等方面给予国产数据库厂商支持，然而，一直没有根本性的改变。其根本原因在于，一直以来各种国内自主可控的产品缺乏市场历练，难以获得行业核心项目的信任。很多时候不是产品的技术不行，而是根本没有机会。
而GBase 8t选择了一条不同的路，在引进、消化、吸收再创新的基础上，推出了一套自主创新、能自主可控的高端数据库产品。武新称之为复制“高铁模式”：中国高铁正是通过引进、消化、吸收、再创新走出了一条属于自己的发展之路。
“Informix是一款可以与Oracle、DB2比肩的非常成熟的产品，出道30多年来拥有庞大的用户群，赢得了用户的信任。这要比从头来开发一个自己的数据库更容易为市场所接受。”武新告诉计算机世界记者。
显然，武新的预言不虚，中国市场对GBase 8t给予高度肯定。在新闻发布会上还举行了与合作伙伴的签约仪式，这些合伙伙伴包括浪潮、华为、中标软件、东软、东方通、启明星辰等，它们将与南大通用一起共同推出整合了GBase 8t的各种应用解决方案。而在此之前，南大通用已经与这些厂商进行了紧密合作，针对这些合作的软硬平台对GBase 8t进行产品优化和适配。
为了打开市场，在发布会上，南大通用还宣布启动“GBase高校行”计划，将向一些高校免费赠送GBase 8t等软件，并提供技术指导，其用意也在于为国产数据库建立起一支人才队伍，进而打造一个更好的应用环境。
数据库安全模式 篇4
随着计算机技术的不断发展, 越来越多的企业通过建立管理信息系统来提高管理效率。这些系统通过将现有的管理流程、表单等信息固化到系统, 不仅减少纸质单据的记录, 方便了审批操作, 更使得数据的统计变得简单高效。对于管理信息系统而言, 除了系统本身功能外, 数据无疑是用户最为关心的内容。随着系统实用化程度的不断提高, 大量的管理数据通过应用程序进入到后台数据库。目前, 无论是套装软件还是定制开发应用程序, 数据的管理仍旧是基于关系型数据库。电力企业中存在着许多的敏感信息系统, 如营销系统、财务系统、招投标系统等, 这些系统的数据一旦泄露或者遭到篡改, 必然会给社会造成很大的负面影响。
数据库的使用者可分为2类:一类是数据使用者;另一类是数据库维护者。对于普通用户, 即系统操作员来说, 一般作为数据使用者的身份通过前端应用程序或后台通过直连方式访问数据库, 对数据进行操作。除此之外, 信息人员需以数据库维护者的身份对数据库进行日常维护操作, 如维护数据库账户, 对数据库进行备份或恢复, 或对系统表结构进行修改等。传统的数据库管理员具有超级权限, 可以对数据库进行任意操作。数据库维护员可以通过该角色实现对敏感信息的窃取、篡改、偷窥等操作。本文将通过结合数据加密、权限分离及审计3种模式, 确保数据库维护员在正常运维数据库的同时避免敏感信息的泄露。
1 数据库安全现状分析
目前, 常见的数据库用户主要分为应用系统用户 (业务员) 、数据库管理员和应用程序开发员。数据库使用现状如图1所示, 业务员通过前端应用程序以普通业务数据库用户角色访问数据库;数据库管理员则可以绕过应用程序, 从后台以DBA用户身份直接登录数据库对其进行操作及维护;开发人员为了验证新的功能是否正确, 也需要从数据库中抽取部分数据用于开发测试。不难发现, 现有的这种工作模式存在着极大的数据泄露风险。
1) 数据库管理员可使用DBA用户直接访问数据库。众所周知, 传统的DBA用户具有超级管理权限, 可以对数据库进行任意操作, 如直接通过后台导出方式将数据窃取, 增加了数据被偷窥、篡改及泄露的可能。
2) 开发员在进行系统测试时也可能会看见某些敏感信息。
3) 一旦发生数据泄露, 缺少有效的监督审计手段。
针对以上面临的3种风险, 本文将分别阐述通过各种技术手段实现一种全方位数据安全加固模式。
2 全方位数据安全加固关键技术
2.1 数据加密
众所周知, 业务数据以关系表结构的方式保存在数据库中, 数据库维护员可以通过后台导出数据的方式将敏感信息进行导出。因此, 有必要对敏感数据进行加密。
数据插入时, 通过将明文数据进行加密变成密文保存至数据库, 当查询访问该数据时, 可通过解密将密文重新转换成明文。
目前, 基于密钥加密的算法有对称加密算法和公私密钥算法2类。对于绝大多数对称加密算法, 加密密钥与解密密钥相同[1], 文献[2]则对加密过程进行介绍。某明文M, 经过密钥K进行加密后生成密文C, 即EK (M) =C;解密过程正好相反, 即DK (C) =M。一般常见对称加密算法包括DES、3DES、AES等, 这类算法加、解密速度快, 满足数据库访问性能的要求。与对称加密算法不同, 公私钥加密算法加密密钥 (公钥) 与解密密钥 (私钥) 不同, RSA算法是使用最广的公私钥加密算法, 某明文M, 经过公钥K1进行加密后生成密文C, 即EK1 (M) =C;再经过私钥K2进行解密得到明文M, 即DK2 (C) =M。然而, 公私钥加密算法解密速度慢, 不适用于数据库加密。
本文选取AES算法对敏感字段进行加密, 并将密钥存放在“钱包”中, 只有使用正确的口令方可打开“钱包”, 取出密钥对数据库进行解密, 从而确保即使数据被全部导出, 在其他设备上导入后也无法正常显示。通过这种措施降低数据被恶意导出的风险, 加强了对敏感数据的保护。
2.2 权限分离
根据工作情况的不同, 用户对数据库所需的权限也是不一样的。普通用户需要具备数据的查看、新增、删除及修改的权限;对于数据库管理员或维护人员, 需要具备数据库的启停、备份、归档以及数据表结构维护的权限。因此, 权限需根据具体的角色需要来进行适当授予。
目前, 业务系统数据库账户角色主要分为2种: (1) 普通业务账户, 应用程序通过该账户对数据库中的数据进行访问; (2) DBA账户, 运维管理人员通过该账户进行日常的维护, 并可以任意访问数据库中的数据。这种分配方式使得运维管理人员具有过高的权限, 使得数据存在被恶意偷窥或篡改的可能。Sanduh等人在文献[3]中通过基于角色的访问控制 (Role-Based Access Control, RBAC) 模型, 即从用户角色分配、角色权限分配和角色继承分配3方面约束数据库管理员权限。韩兰胜等人在文献[4]中提出了基于角色访问控制的最小权限原则、权限制约原则和权限抽象原则, 最小原则是指在RBAC中的角色仅赋予其完成任务所需的最小权限, DBA账户实际上就是违反了该原则, 它被赋予了过大的权限, 使得数据变得不安全;权限制约原则是指相互排斥的权限不应赋予同一角色, 例如DBA账户同时具备创建数据库账户及授予各账户各种操作的权限, 这就违反了权限制约原则;权限抽象原则由于不涉及安全, 这里不再赘述。
基于以上原则, 本文提出将数据库管理员的角色分解为安全员及管理员2种角色, 实现普通用户与运维用户的权限分离。权限分离示意如图2所示, 原有的数据库管理角色被分成安全员和管理员, 安全员负责对普通应用账户进行正确读写授权, 管理员则仅保留数据库维护管理、账号管理、表结构管理等运维权限。普通应用账户的创建由管理员完成, 而安全员则根据普通用户的实际工作内容进行适当授权, 这满足了最小权限原则。同时, 安全员与管理员互相制约, 相互独立。管理员不能创建或者销毁安全员角色, 而安全员也不能对管理员进行授权。换句话说, 所有的数据访问操作仅有普通应用账户可以完成, 安全员只负责数据访问操作授权, 其自身也无法进行数据访问操作;管理员仅具有非数据外的运维操作权限。同时还引入了审计员的角色, 其与安全员、管理员一样, 是独立存在的, 不能被创建或销毁, 其职责是负责对数据库内所有用户行为进行审计。
通常, 信息人员负责保管管理员口令, 业务人员负责保管安全员口令、业务员账户, 而审计员账户则可以由审计人员负责保管。这种权限分离的授权模式解决了电力行业中敏感系统的运维管理问题。例如, 营销系统中存有大量社会用户的敏感信息, 如个人身份证号、银行卡号、手机号、家庭住址等, 这些信息一旦泄露, 会给企业及社会造成负面影响。通过这样的授权模式, 仅有营销系统用户可以通过登录前端系统对系统数据进行访问, 而后台运维人员无法访问数据内容。如需新增业务员用户, 需信息人员以管理员角色新增账户后, 再由业务人员以安全员角色对其进行正确授权后方可生效。如需后台进行数据修改, 需信息人员以管理员账户登录数据库后, 业务人员使用正确的普通用户进行操作。信息部门与业务部门相互制约, 任意一方都难以擅自违规操作, 即使出现泄密事件, 也可通过审计员查看审计记录, 追查违规操作源。
2.3 数据库审计
数据库审计指的是对数据库用户的操作行为进行审查及记录。比较典型的审计报告应该具备以下内容:操作用户、操作行为以及操作改变的数据。文献[5]提出通过将审计功能植入到关系型数据库平台中, 对数据库的事务日志进行审查, 跟踪数据和数据库结构的变化, 并生成记录文件。这种方式有2个弊端: (1) 审计记录存储在本地, 存在DBA用户可以篡改审计数据的可能性; (2) 审计功能不能对数据访问语句进行审计, 如select语句, 存在敏感数据被偷窥的可能。
审计服务器部署示意如图3所示, 通过将审计服务器与数据库隔离部署, 并对审计服务器中的数据进行加密, 从而确保审计数据不被篡改。以Oracle数据库为例, 数据库执行的所有SQL语句将会临时保存在共享池的缓存中。因此, 需要对某些关键字段的查询进行定义, 使得审计服务器自动捕获符合条件的SQL语句, 从而实现对数据访问的审计。事实上, 市面上已有成熟的软件可实现此功能, 如甲骨文公司的Audit Vault就是基于此原理, 其通过在数据库服务器端部署代理, 作为审计收集器, 根据事先预置的审计策略对符合条件的操作行为进行记录, 并将记录以加密形式回传至审计服务器中保存并分析。
2.4 数据屏蔽
在系统测试时, 为了使测试效果更为理想, 系统测试人员会将生产环境的真实数据导出到测试环境中, 这可能导致部分敏感数据泄露。如果通过简单的自造数据测试, 往往不会达到理想的效果, 因为某些系统功能会与数据密切相关。
数据屏蔽示意如图4所示, 通过一些规则, 将生产数据库中的敏感数据按照自定义规则不可逆地转换为其他内容, 并保留敏感数据的特征, 从而既达到了测试效果, 又避免了敏感信息泄露。事实上, 通过PL/SQL编程编写屏蔽转换脚本即可实现该功能, 也可采用其他成熟软件来实现, 如Oracle的数据屏蔽包等。
3 全方位数据安全加固模式的设计与实现
通过上述分析, 分别采取数据加密、权限分离、操作行为审计及数据屏蔽4种方式, 可以克服传统模式的缺点。
1) 数据加密。进行数据插入操作时, 通过AES算法对敏感字段进行加密, 并将密钥存放在特定位置中, 当查询该数据时, 只有使用正确的口令方可获取密钥, 对数据库进行解密, 确保即使数据被恶意导出, “偷窥者”也无法看到正常的明文数据。通过这种措施, 降低了数据被恶意导出的风险, 加强了对敏感数据的保护。
2) 权限分离。将数据库管理员的角色分解为安全员及管理员2种角色, 实现普通用户与运维用户的权限分离。原有的数据库管理角色被分为安全员和管理员, 安全员负责对普通应用账户进行正确读写授权, 管理员则仅保留数据库维护管理、账号管理、表结构管理等运维权限。普通应用账户的创建由管理员完成, 而安全员则根据普通用户的实际工作内容进行适当授权, 这满足了最小权限原则。同时, 安全员与管理员互相制约, 相互独立, 管理员既不能再创建或者销毁安全员角色, 而安全员也不能对管理员进行授权。换句话说, 所有的数据访问操作仅有普通应用账户可以完成, 安全员只负责数据访问操作授权, 其自身也无法进行数据访问操作;管理员仅具有非数据外的运维操作权限。最后, 引入审计员角色, 其与安全员、管理员一样, 是独立存在的, 不能被创建或销毁, 其职责是负责对数据库内所有用户行为进行审计, 这种权限分离的授权模式解决了电力行业中敏感系统的运维管理问题。
3) 操作行为审计。通过将审计服务器与数据库隔离部署, 并对审计服务器中的数据进行加密, 从而确保审计数据不被篡改。
4) 数据屏蔽。在对系统功能进行测试时, 为了使测试效果更为理想, 同时避免敏感信息被泄露, 可通过一些规则, 将生产数据库中的敏感数据按照自定义规则不可逆地转换为其他内容, 并保留敏感数据的特征, 从而在达到良好测试效果的同时又能避免敏感信息被泄露。
数据加固模式示意如图5所示。
实现全方位的数据安全加固的步骤如下。
1) 单独部署一台审计服务器, 并在原数据库上部署代理, 通过设置审计策略, 捕获符合审计范围的操作语句, 返回审计服务器进行存储。
2) 对审计服务器中的记录及数据库服务器中的敏感信息字段进行加密。
3) 将原超级管理员用户的权限分解为安全员与管理员, 分别负责操作授权及系统运维职能。
4) 编写屏蔽脚本, 将数据库中的敏感数据进行转换后发送给测试服务器进行测试。
在这种模式下, 可以从技术层面有效避免发生数据泄露事件, 即使发生泄露, 也能很快进行定位。对于盗窃者而言, 这样的设计无疑增加了窃取难度, 且一次不留痕迹的数据盗窃仅靠一方难以完成, 需多方密切配合才可能实现。
4 结语
随着信息技术的不断发展, 业务管理对信息系统的依赖性也越来越大。同时, 业务对信息安全的要求也越来越高。目前, 虽然可以从技术上对数据进行安全加固, 增加数据盗窃成本和难度, 但也无法完全确保数据的绝对安全, 需配合管理手段进行管控。在管理方面, 本文提出将不同权限分配不同的管理部门, 除此之外, 还需对机房人员进出登记, 运维人员操作也必须有相应严格的管理要求。
数据库安全问题涉及到企业的重大利益, 除了数据库本身, 还需结合一些网络安全技术, 通过防火墙等入侵检测技术、防病毒技术、漏洞挖掘技术等对数据安全进行加固。数据安全工作任重道远, 仍需不断完善数据保护的技术和手段。
参考文献
[1]SCHNEIER B.应用密码学[M].北京:机械工业出版社, 2000.
[2]周立力.企业数据库安全与加密设计[J].山东冶金, 2005, 27 (5) :59–61.ZHOU Li-li, Design of database security and encryption in enterprise[J].Shandong Metallurgy, 2005, 27 (5) :59–61.
[3]SANDHU R S, CONYNC E J, FCINSTCIN H L, et al.Role-based access control model[J].IEEE Computer, 1996, 29 (2) :38–47.
[4]韩兰胜, 洪帆, 骆婷.基于角色的访问控制中的安全三原则[J].华中科技大学学报 (自然科学版) , 2006, 34 (1) :36–38.HAN Lan-sheng, HONG Fan, LUO Ting.Three security principles for role-based access control[J].Journal of Huazhong University of Science and Technology (Nature Science) , 2006, 34 (1) :36–38.
数据库安全模式 篇5
关键词：CDIO 数据库 案例驱动 “三点一线”教学法
中图分类号：G623文献标识码：A文章编号：1673-9795（2012）10（a）-0107-02
我国高等工科教育的迫切任务是尽快培养与国际接轨的中国工程师，然而我国工科的教育实践中还存在不少问题，如重理论轻实践、强调个人学术能力而忽视团队协作精神等问题。CDIO[1]教育理念旨在通过注重培养学生系统工程技术能力，尤其是项目的构思、设计、开发和实施能力，以及较强的自学能力、组织沟通能力和协调能力，吸收世界先进的工程教育理念，建立符合国际工程教育共识的课程体系。为了更好地推广CDIO教学理念和方法在中国的推行，教育部组织相继召开了几个大型会议，香港大学、清华大学等40多所国内外高校的专家学者，对当前高等工程教育存在的热点问题进行了热烈的讨论，普遍认识到工程教育改革的紧迫性与必要性。我校的若干专业和课程正在试图采用这种教育模式培养学生，本文探讨了数据库课程在实施CDIO模式下的教学过程中的经验和体会。
1 数据库课程CDIO教学模式总体架构
我们的学生在学习了原有课程内容后，仍然感到知识零散，所学内容关联不足，从事系统开发大体知道该怎样做，却无法高效地立即投入工作，有种无从下手的感觉。分析缘由，与我们始终按照理论线贯穿课程内容有主要原因。而数据库课程[2]是一门实践性非常强的课程，学习该课程的目的主要是为了应用，CDIO教学理念的提出为数据库教学提供了一个非常好的思路。基于CDIO教学模式是在已有教学模式的基础上做出调整，建立一个如图所示的二维空间散点图，这是课程设计和实施的蓝图。
图1中横坐标代表CDIO四个阶段，纵坐标代表学生获得的知识和能力，散点代表不同阶段所涉及的课程内容的分布。从图中可以看出，不同阶段需掌握的知识点和所获得的能力有所不同。在新的教学模式中，更强调案例结合和项目驱动，强调数据库技术知识的教学与实际系统开发紧密有机地结合。
2 基于CDIO的数据库课程改革
按照CDIO大纲的要求，结合CDIO的12条标准，[3]对数据库课程的改革主要体现在以下几个方面。
2.1 重新组织课程内容，实践与理论并重
数据库课程内容的特点是较为离散，通常是根据数据库管理系统（DBMS，Database Management System）的构成及功能讲授数据库课程，也即理论部分占主要地位，而实践相对较弱一些。但从实际工作及将来对该门课程的使用需求看，更着重在数据库的实践应用上。因此，有必要对该课程的内容重新组织，并根据工程教育的需要，引入新的要素。课程内容主要调整的思路是：系统设计篇提前，与基础知识有机结合。包括：
第一部分：系统分析：以实际系统为例，讲授系统分析方法和原则，主要介绍概念模型的基本概念，包括实体、属性、联系和E-R模型等。
第二部分：系统设计：包括两部分，即相关基础知识和相关实践应用。基础知识包括数据模型、记录、表、码、完整性约束、视图、范式等；实践应用包括，根据实际系统资料，设计一套符合指定范式需求的领域数据库，以及SQL语言和数据库的安全控制。
第三部分：系统实现：主要包括系统代码实现过程中需要的各种技术，其中数据访问技术直接利用前一阶段的成果，是实现数据库应用的核心技术。
第四部分：系统运行：DBMS系统安装和配置，应用系统安装和运行。
该部分的改革集中体现了CDIO中的标准1—— 背景环境和标准3—— 一体化课程计划。
即以系统的生命周期为授课主线，运用构思—— 设计—— 实现—— 运行作为课程传授的背景环境，将零散的数据库理论知识融入到系统的构造过程中，做到理论和实践的有机结合；制定了明确的计划，让学生在学习过程中同时获得个人能力：即提出问题、分析问题和解决问题的能力；人际交往能力：在系统开发过程中，设置团队开发模式，团队成员需要良好的沟通，才能形成一个完善的系统；系统构造能力：明确在实际的企业环境下进行系统的CDIO运作。
2.2 分层次案例驱动的教学模式
根据难易程度设置多个案例，案例根据其规模、复杂度和适用的环境进行分级。案例包括学生较熟悉的学生信息管理系统、教学信息管理系统、在线考试系统等，也有来自企事业的项目，如，油田信息管理预测系统、商品在线购物系统等。对系统的介绍可以加强学生的感观理解和认识。通过展示系统的原理、概念，以及在实际生活中的用处、表现，可以增强学生学习的兴趣和动力，从而收到了较好的教学效果。教师授课时根据教学需要灵活选用其中一种或几种，学生在实验或设计时，可根据自身情况，如，动手能力或解决问题的能力的强弱选择其中的一种。初级的案例一般设计实现过程简洁，动手快，容易在较短的时间内掌握系统的整个构造过程；而高级的案例能使学生更好的强化对系统开发的了解，从而将所学到的理论知识应用到实际工作中。鉴于计算机软件开发技术的迅速发展，在案例分析、设计和实现的过程中，选择较新的教学实验环境，设计科学的实验大纲；同时建立网上课程学习平台，开展网络教学。实验环境的精心选择有利于学生在将来走入社会后，尽快的投入工作，适应社会需要。该部分集中体现了CDIO标准5—— 设计实现的经验和标准6—— 工程实践场所，这两条标准阐明了实践环节所应提供的素材和支持环境，即软件和硬件环境，在实践時，二者相辅相成，缺一不可。
2.3 “三点一线”的教学方法
以应用为主线，基础理论为支撑点，启发式教学为切入点，系统实现为出发点，兼顾理论的同时，突出应用。将数据库的基本概念、思想和方法与应用实践相互关联，教师把握基础理论和应用技术的脉络；在实践和技术相关章节中，对应用技术的阐述，既结合具体产品，适当地对原型进行分析，又不失同类产品和技术的一般性，使其具有广泛的指导作用。“三点一线”教学法是数据库课程在实施CDIO模式过程中总结出来的，该方法强调教师改变以往以讲授为主的模式，更多地采用启发和讨论相结合的方法刺激学生去主动接受信息，并在目标明确的基础上，自行分析、判断和操作，在“三点一线”教学指引下，养成主动学习的优良习惯。该部分集中体现了标准7—— 一体化学习经验、标准8—— 主动学习和标准10—— 提高教师的教学能力。
2.4 开放式的师资队伍建设
师资队伍建设是该课程建设的重中之重，要想培养一流的学生，必须有一支一流的教师队伍做支撑。鉴于IT行业更新速度快的特点，要坚持长期对教师进行新技术培训。即使长期培训，也不可能保证教师掌握所有的新技术。需要探索一种与掌握先进技术的企业进行良性互动的办法，采取“请进来、送出去”的模式。聘请企业中掌握先进技术高级讲师来为我们学生讲课，同时把我们的教师定期送到企业，参加企业实际项目的开发，摸清市场的需求，及时调整教学内容。该部分体现了标准10—— 提高教师的工程实践能力。
2.5 合理的考核评价体系
建立合理的考核评价体系，综合考核学生掌握技术知识的能力和程度，个人分析和解决问题的能力，以及系统构造的能力。考核方式多元化，技术知识和部分个人能力采用笔试形式；系统构造能力及解决问题的能力采用讲解和答辩的方式，综合考虑的因素有：选题难度、工作态度、与他人合作情况、系统开发的质量、书写报告的质量、回答问题的情况、是否有创新等。该部分体现了标准2—— 学习效果和标准11—— 学习考核。在实际考察学生各项能力的基础上，给出考核评价成绩表，从而真实再现CDIO教育模式下的教学效果。
3 结语
建设一门课程，首先需要全方位分析其在整个教学体系中既定的地位、目标，面向的学生对象的知识和能力结构，需要拓展和延伸的方向，然后才可以规划课程的内容、进度、教学方式及评价体系。本文基于CDIO教育模式，重新审视数据库课程内容的组织和教学方法，按照最能体现工程教育理念的模式重新整合，以期能在未来的教学中达到更好的效果。
参考文献
[1]E.Crawley.Rethinking Engineering Education：The CDIO Approach[M]. Springer series in optical sciences，2007，133（3）.
[2]萨师煊，王珊.数据库系统概论[M].北京：高等教育出版，2006.
数据库安全模式 篇6
云存储是在云计算概念上延伸和发展出来的, 是指通过集群应用、网络技术或分布式存储系统等功能, 将网络中大量各种类型的存储设备通过应用软件集合起来协同工作, 共同对外提供数据存储和业务访问功能的一个系统。云存储面临的安全威胁是指:数据上传到云存储中, 用户需要依靠CSP (CloudStorage Provider) 来保护数据的内容安全;然而, CSP自身或其内部员工都有可能主动或被动的泄露用户数据。云存储安全的根本目标是要保证云存储数据的安全, 包括数据的完整性、私密性、可用性、以及数据安全共享。
(1) 完整性:在云存储中, 完整性保护由CSP负责实施, 用户没有直接保护和管理数据完整性的能力。但用户期望能够感知数据是否因硬件失效、操作失误等威胁而被破坏, 能够在需要时直接验证数据的完整性。
(2) 机密性:机密性是云存储数据安全的基本需求, 主要包含两方面的内容。一方面, 云存储需要采用一定的访问控制手段来保护用户数据不被非授权用户访问;另一方面, 云存储中的数据需要经过足够强度的加密处理, 来保障数据内容的机密性。
(3) 可用性:数据可用性是指用户随时可以访问云存储服务的能力。但由于存在不可控的风险, CSP并不能保证云存储服务总是可用的。
(4) 数据共享安全:云存储区别于本地存储的一个主要特征是开放性, 因此采用云存储进行数据共享具有天然的便利性。云存储中的数据共享安全在实质上是访问控制增强, 即通过安全可靠的访问控制措施, 保证数据按照用户指定策略进行共享而不被泄露。现有大多数云存储服务都提供了一定的访问控制功能来支持数据共享。
1 云存储数据完整性验证模型
云存储数据完整性验证分为静态数据验证和动态数据验证。针对云存储系统数据的完整性验证, G. Ateniese[1]创新性地提出了PDP (Provable Data Possession) 模型, 该模型允许客户无需撤回存储在云端的数据就能验证数据的完整性, 极大地降低了传统模型通过撤回数据进行验证所带来地下载开销。与此同时, Ari Juels[2]等人提出了POR (Proofs of Retrievability) 模型, 该模型能够让服务器提供给客户完整撤回全部数据的证明, 独立验证数据块集合哨兵“sentinels”随机分散于存储数据块集合是此模型的核心技术。这两种模型都是针对静态数据保护的, 譬如archive档案室、back-up services备份服务器。HovavShacham[3]和德克萨斯大学的Brent Waters基于PDP同态签名技术创造性地提出了CPOR (Compact POR) 模型, 能够整合一系列的CSP的回应从而减少带宽, 而且能对存储的数据进行无限次的校验审计。至于动态数据保护模型, C. Chris Erway[4]等人利用基于次序的验证转移列表第一次提出动态的PDP模型, Wang Qian[5]等人运用Merkle哈希树构造出了公共审计的动态数据完整性验证模型。另外为了降低客户在线审计所带来的开销, 可以加入可信第三方TPA (Third Party Auditor) 代替客户对CSP存储的数据进行公共审计。公共审计相比私有审计有更少的客户花销, 但同时也带来了数据泄密的隐患。为此Wang C等人利用Mask“面具”技术提出了防止数据泄露给TPA的私密保护的数据完整性验证模型。
2 云存储数据可用性、可靠性模型机理
云存储数据的可用性、可靠性和灾难恢复性可用数据容错技术得到部分解决。当数据的完整性检测到错误或丢失时, 利用数据的冗余来进行恢复数据。具体地, 当下数据冗余技术包括复制备份 (replication back-up) , 纠删码 (erasure coding) , 网络编码 (network coding) 。Reza Curtmola[6]提出了多备份 (multi-replication) PDP模型, 结合了数据完整性验证和修复技术。纠删码作为经典的编码技术, 相比复制备份技术能有更少的修复开销, 一个 (n, k) 数据编码通过下载k个数据块就能恢复全部的数据。Kevin D. Bowers[7]等人在云存储的背景下提出了一个具有二维纠删码特性的数据存储模型, 同时还包含审计过程。2010年, A.G. Dimakis[8]等人开创性地提出了网络编码 (也叫再生码regenerating code) 技术, 该编码适用于高风险、多事故存储系统, 比一般的纠删码具有更少的修复带宽。基于最小割原理 (cut-bound flow) 可以得到两个极值点MSR (minimum storage regenerating) 和MBR (minimum bandwidthregenerating) 分别表示节点存储最小的前提下最小化带宽和带宽最下的前提下最小化节点存储。再生码又分功能修复 (functional MSR/MBR) 和精确修复 (exact MSR/MBR) 。精确修复相比功能修复有更好的防窃听 (eavesdropping) 能力, 功能修复具有较易的构造。Bo Chen[9]等人基于网络编码构造了分布式存储系统远程数据审计的模型, 融合了数据完整性和可用性两大特性。之后基于再生码, 还出现了本地修复码 (Locally Repairable codes) 。
3 云存储数据访问控制模型
云存储的访问控制为了进一步提高数据共享时的安全性和灵活性, 用户可以在建立“加密云存储 (Cryptographic CloudStorage) “的基础上, 采用高效的用户自主的密文访问控制机制来保护云存储数据共享安全。在基于密文访问控制机制的云存储中, 即使非授权用户获取了共享数据也不能解密得到明文, 因此可以防止在共享过程中发生内容泄露。此外, 采用加密云存储时, 用户可以通过选择加密时的数据对象粒度, 来指定共享时的访问控制粒度。使用加密云存储进行数据共享的过程就是密文访问控制过程。密文访问控制机制以用户为中心, 从用户的角度来实现云存储中的数据安全保护。密文访问控制研究最早可以追溯到Akl和Taylor提出的, 基于公钥密码算法实现的分级访问控制系统 (Hierarchical Access Control, HAC) 。随着密码学的不断发展, 密文访问控制技术也在不断完善, 先后出现了 基于非对 称加密、 单向Hash、身份基 加密 (Identity-Based Encryption, IBE) 、属性基加密 (Attribute-BasedEncryption, ABE) 等算法实现的密文访问控制机制。ABE能够支持基于属性的访问控制, 能够有效的减轻密文访问控制机制中的密钥管理开销。ABE的前身是IBE, 2001年Boneh和Franklin首次实现了基于双线性对的IBE机制, 该机制直接使用用户身份标志来生成公钥, 在使用时无需校验用户公钥的真实性。2005年, Sahai和Waters[10]在IBE技术的基础上提出并实现了模糊 (Fuzzy) IBE机制, 该机制实现了基于身份的加解密。随后, Goyal等人提出了基于属性的访问控制方法, 并首次将ABE分为密钥 策略的属 性基加密 ( Key-PolicyAttribute-Based Encryption, KP-ABE) 和CP-ABE。基于KP-ABE的访问控制机制中, 由数据使用者规定访问控制策略, 适合于数据查询类应用。Shucheng Yu[11]、Wang C等人基于属性基加密、重加密和懒惰加密技术提出了细粒度、可拓展和数据机密性质合一的云存储访问控制模型。
4 结语
以上作者对云存储模式下数据的安全保护处理的相关技术进行了粗略的探讨, 但是云存储数据部署的模型系统涉及的主题和内容很广泛, 真正全面精细的了解掌握云存储数据安全处理技术需要联系实际的需求以及基础设施的完备性。
摘要：以云存储在信息系统开发与建设的需求为背景, 探讨能够兼容动态数据审计和网络编码的分布式存储系统实现原理以及基于ABE属性基加密的细粒度访问控制的安全增强模型, 为云存储数据保护提供有效的方法。
关键词：云存储,审计,网络编码,访问控制
参考文献
[1]Ateniese, G., Burns, R., Curtmola, R., Herring, J., Kissner, L., Peterson, Z.and Song, D.:‘Provable Data.Possession at Untrusted Stores’.Pro.14th ACM Conference on Computer and Communications Security (Alexandria, VA, Oct.28–31) , ACM Press, New York, 2007, pp.598–609.
[2]Juels, A., Kaliski, B.S.and Pors, Jr.:‘Proofs of Retrievability for Large Files’.Proc.the 14th ACM conference on Computer and communications security (CCS’07) , 2007, pp.584–597.
[3]Shacham, H.and B.Waters.:‘Compact Proofs of Retrievability’.Proc.the 14th International Conference on the Theory and Application of Cryptology and Information Security (ASIACRYPT’08) , 2008, pp.90–107.
[4]Erway, C., Kupcu, A., Papamanthou, C.and Tamassia, R.:’Dynamic Provable Data Possession’.Proc.16th ACM Conference on Computer and Communications Security (Chicago, Nov.9–13) .ACM Press, New York, 2009, pp.213–222.
[5]Wang, Q., Wang, C., Li, J., Ren, K.and Lou.W.:‘Enabling Public Verifiability and Data Dynamics for Storage Security in Cloud Computing’.Proc.14th European Symp, Research in Computer Security (ESORICS 09) , 2009, pp.355–370.
[6]Curtmola, R., Khan, O., Burns, R.and Ateniese, G.:‘MR-PDP:Multiple-Replica Provable Data Possession’.Proc.ICDCS’08, 2008, pp.411–420.
[7]Bowers, K.D., Juels, A., and Oprea, A.:’Hail:A High-Availability and Integrity Layer for Cloud Storage’.In ACM Conference on Computer and Communications Security, 2009, pp.187–198.
[8]A.G.Dimakis, P.G.Godfrey, Y.Wu, M.J.Wainwright, and K.Ramchandran, “Network Coding for Distributed Storage Systems.”IEEE Trans.Inf.Theory, 56 (9) , pp.4539–4551, Sep2010.
数据库安全模式 篇7
网络技术的发展在给大众带来便利的同时, 信息的安全机制也经受了越来越多的挑战。企业内部因为业务的需要, 经常涉及到多个网络之间的数据传输。通常称内部主业务网为可信端网络, 而非主业务网络称为非可信端网络[1]。既要实现可信端和非可信端实时、高效的通信, 又要保证可信端数据不被黑客通过非可信端非法窃取或篡改, 使用网络隔离是最好的解决办法[2]。网络隔离技术的目标是在确保可信端网络内部信息不外泄的前提下, 与非可信端网络实现网间数据的安全、实时、高效率交换。网络隔离主要分为物理隔离和逻辑隔离, 重点是物理隔离[3]。物理隔离是解决不同网络间安全问题最有效的方式, 在党、政、军等基于不同网络的领域被广泛应用。网络物理隔离主要有以下3 个特征:1 每一次数据交换都需要经历数据写入和数据读出两个过程[4];2 内网与外网永不连接;3内网和外网在同一时刻最多只有1 个与物理隔离设备建立非TCP/IP的数据连接[5]。
传统的物理隔离的数据传输主要以光盘、U盘的单向拷贝为主, 该方式在一定程度上解决了网络间的数据通讯问题, 但也为物理隔离网络之间增加了通讯的难度, 并间接为病毒的传输提供了可能。
物理隔离的使用, 在解决网络间通讯安全问题的同时也为一些需要在网络间交换的数据的通讯带来了诸多不便。我院利用服务器已有的外设部件互连标准 (Peripheral Component Interconnect, PCI) 接口结合相应的安全权限机制自主研发了隔离通信卡, 在不牺牲物理隔离安全性的同时, 又能够针对特定的业务实现不同网络间安全、实时、高效率的数据通讯。
PCI是目前计算机使用最为广泛的接口, 几乎所有的主板产品上都带有这种插槽。PCI是在CPU和原来的系统总线之间插入的一级总线, 具体由1 个桥接电路实现对这一层的管理, 并实现上下层之间的接口、协调数据的传送。其工作频率为33 MHz/66 MHz, 当PCI总线工作在33 MHz频率时, 传输带宽达可达133 MB/s。在同一个机房, 具有“物理隔离”的两个网络之间的机器, 通过安装PCI接口硬件进行通讯, 是解决短距离、小数据量数据实时传输的便捷方式。
1 具体实现过程
在两个通讯服务器之间实现通讯, 首先需要在服务器之间建立相应的连接, 通过自定义的通讯协议在两台服务器之间进行数据交互。由于只是针对特定的业务, 为了保障数据交互的安全, 在PCI接口硬件之间所采用的交互协议要尽可能简单并带有严格的数据加密保护措施, 对数据通讯服务器实行接收指令的限定, 通过特定的指令返回相应的数据处理结果。在数据处理服务端定义相应的指令集用于接收固定的指令, 再针对特定的指令返回处理结果。对于非法的指令直接丢弃。基于PCI接口连接的数据交互原理, 见图1。
该交互方式实现了物理隔离网络之间的通讯, 在最大限度地提高通讯效率的前提下, 保证了物理隔离网络之间的安全性。在安全保障方面, 通过硬件的方式实现传输加密;非标准协议握手验证和加密通讯在不同操作系统是通过操作系统本身的权限控制机制, 限制客户端与服务器端的访问权限。
1.1 硬件准备
硬件端主要由PCI总线接口芯片CH365、USB接口芯片CH375、 逻辑控制芯片ATF16V8B组成[6]。 其中, CH365 是一种32 位转8 位、数据传输速率可达7 Mbit的计算机PCI (或PCI-E) 总线接口芯片;CH375 是一个具有8位数据总线和读、写、片选控制线以及中断输出的USB总线通用接口芯片, 并且里面带有2 个可用于数据交换的64字节收发双向缓冲区;ATF16V8B是可写入控制逻辑的控制芯片[7]。硬件通信原理, 见图2。
由图2 可见, 驱动软件通过PCI总线向CH365 芯片发起64 字节的数据传输请求, 并通过ATF16V8B芯片通知CH375 芯片并查询相应状态直到当CH375 芯片可写时, CH365 芯片向CH375 芯片写完数据并产生中断告知CH375芯片;CH375 芯片收到此中断信号, 则通过USB协议向对方的卡发送待传输的64 字节数据。对方的CH375 芯片收到数据后将数据存放在64 字节接收缓冲区, 同时向ATF16V8B芯片发出中断信号并等待CH365 芯片接收数据, 待数据接收完毕后关闭中断信号。由于CH375 芯片具有2个64 字节缓冲区, 可以将2 个缓冲区分别设置为接收缓冲区和发送缓冲区, 由此构成数据收发的全双工链路。
1.2 通讯协议
1.2.1 通讯链路的建立
通信卡虽然不建立标准的TCP/IP链接, 但是为了保证数据收发的同步, 建立链接时仍然使用类似于TCP/IP的“3次握手”协议和“4 次分手”协议[8]。
所谓的“3 握手”就是对每次发送的数据量怎样跟踪、协商, 使数据段的发送和接收同步;当数据发送、接收完毕后何时撤消联系, 并建立虚拟连接。为了提供可靠的传送信息, TCP在发送新的数据之前, 以特定的顺序号将数据打包并传送给目标机。TCP总是用于发送大批量数据。当应用程序在收到数据后做出确认时也要用到TCP。握手时序通信原理, 见图3。
第1 次握手:建立连接时, A端发送syn包 (syn=j) 到B端, 并进入SYN_SEND状态, 等待B端确认。
第2 次握手:B端收到syn包, 必须确认A端的SYN (ack=j+1) , 同时自己也发送一个SYN包 (syn=k) , 即SYN+ACK包, 此时服务器进入SYN_RECV状态。
第3 次握手:A端收到B端的SYN+ACK包, 向B端发送确认包ACK (ack=k+1) , 此包发送完毕, A端和B端进入ESTABLISHED状态, 完成3 次握手。
由于TCP连接是全双工的, 因此每个方向都必须单独进行关闭。这个原则是当一方完成数据发送任务后就发送1 个FIN来终止这个方向的连接;收到1 个FIN只意味着这一方向上没有数据流动。1 个TCP连接在收到1 个FIN后仍能发送数据, 首先进行关闭的一方将执行主动关闭, 而另一方执行被动关闭。
1.2.2 数据帧格式
通讯卡采用有限数据通信模式, 即数据服务器所能接收的指令事先定义并保存在相应的请求指令集。数据处理服务器端接收到的数据首先需要进行解密, 再进行有效性判断, 不符合的数据一律被认为是无效数据 (丢弃) ;对于符合指令处理程序的数据, 根据指令的要求加密后返回给客户端。这样, 即使黑客掌握通信协议向PCI硬件卡发送的信息, 也无法进行正确的加密、解密, 其指令也是数据处理服务器不认可的[9]。
CH375 芯片里面带有2 个可用于数据交换的64 字节收发双向缓冲区, 在通信协议设计时, 协议的帧头固定占用4个字节, 帧数据区占用60 个字节。4 个字节的帧头又分为握手区和指令区, 第1 个字节用来存放上位机的通讯信道和握手协议信号;第2~4 这3 个字节用来存放具体的通讯指令。
第1 字节握手区的8 bit又分为两部分。第一部分为前3 bit, 用来存放通讯信道, 支持23=8 种通讯信道, 即已配对的1 套通信卡可以支持上位机8 种通讯程序;第二部分为剩下的5 个bit, 用于存放握手协议和分手协议的应答信号, 协议支持25=32 种协议握手信号。
指令区3 个字节的字长支持224=1703936 种有效性通信指令。内部通信指令还可区分为控制指令和数据传输指令。控制指令占用第3 字节, 包含3 次握手和4 次分手指令集合, 最多可以达到28=256 种指令;数据传输指令共同占用第2、3 字节, 包括数据传输开始、数据帧中传输、丢弃指令、数据重发、数据结束等指令。指令集支持216=65536种指令。为了保证通信卡的通用性, 协议保留第1 字节给上位机自行定义。上位机用户可以根据具体的应用自行定义指令格式, 指令集数量支持224-216-28=16777216-65536-256=16711424 种指令。
帧数据区由缓冲区的第4 字节和其他59 个字节组成, 其中第4 字节的低4 位组成的最大可表示64 数值、代表59 个字节的数据长度。高4 位组成的最大可表示64 数值、表示数据传输的加密标准[10] (数据加密标准涉及通信卡通信安全, 此处不展开说明) 。由此构成的帧格式示意图, 见图4。
1.3 通信端配置
在准备好硬件与定义相应的通讯协议后, 基于不同的操作系统还要进行相应权限分配的设置。本通讯方式在数据传输时, 在请求客户端服务器与数据处理服务器间并没有相应的标准协议, 而是分别在两个服务器的操作系统中定义了通讯双方所能够访问的目录。该目录通过操作系统用户的权限来设定, 只具备读、写的功能, 并限定存储文件类型为文本类型。这样的限定将会极大降低服务器间传递恶意程序的可能性, 从而提高服务器的安全性。
1.4 通讯设备的使用
经过硬件、通讯协议以及通讯两端之间的安全配置后, 只需在通讯的服务器上安装相应的上位机驱动程序, 并进行简单的配置, 即可为通讯的双方提供相应的安全数据通讯。
在数据处理服务端, 需要配置可接收的指令集, 并设置接收数据的加密机制。当请求客户端发起正确加密的指令后, 服务器通过监控指定目录接收的指令, 从数据库或者其他存储介质中获取到处理的结果数据, 并通过加密的方式传输到请求客户端。请求客户端接收到的数据同样放在指定的目录下, 请求客户端通过将返回的数据格式与相应的发送请求进行匹配, 形成相应的结果数据, 返回给最终用户。
由于通讯卡内部CH365 数据传输速率可达7Mbit并且采用全双工通信链路, 去除协议包的数据流量损耗, 实际的通信速率可以达到6.4 Mbit。在给医保、农保和互联网提供查询应用时, 其速率已和普通互联网接入的下行带宽相当。在实际使用中, 应用程序并未有明显的网络隔离中断等待。对用户和黑客也实现了网络透明, 让恶意程序无法进入可信端窃取和破坏数据, 实现理想的隔离, 使数据高速率、安全地进行通信。
2 结语
本文提出了一种利用PCI接口作为多个网络之间物理隔离方案的通讯机制, 使通讯双方在同一机房实现交互数据量小、并发量不大的单链路多信道业务通讯。在本文中涉及到的硬件、软件配置, 并不需要很高的成本, 只是利用了最基本的服务器的已有接口, 并配合简单的传输配件, 即可组成1 个便捷的跨网络安全数据传输设备。该机制从硬件层面、软件层面都对物理隔离网络之间的数据通讯设置了相应的安全保障, 能够实现物理隔离网络之间高效率、实时、安全的数据交换, 并减少了病毒传输的可能性[11], 在特定的业务方面有较强的可用性。
摘要：目的 实现多个网络之间的数据安全传输。方法 在两个通讯服务器的PCI插槽上安装我院自主研发的隔离通信卡, 通过自定义通讯协议在两台服务器之间进行数据交互。结果 在保证原物理隔离安全性的基础上, 实现了通讯双方在同一机房的数据交互量小、并发量不大的单链路多信道业务通讯。结论 利用PCI接口作为多个网络之间物理隔离方案的通讯机制, 在特定的业务方面有较强的可用性。
关键词：PCI接口,网络技术,网络安全,物理隔离
参考文献
[1]王洪强, 詹永丰, 张蔚, 等.基于网闸实现物理隔离的网上预约挂号系统[J].中国数字医学, 2010, 5 (11) :71-72.
[2]王朝坤, 付军宁, 王建民, 等.软件放篡改技术综述[J].计算机研究与发展, 2011, 48 (6) :923-933.
[3]常建国, 宫彦婷, 徐京渝, 等.医院HIS网络与医保网络间数据交换安全解决方案[J].中国医疗设备, 2012, 27 (3) :63-67.
[4]张继永.网络隔离技术与信息安全[J].中国信息界, 2010, (9) :25-26.
[5]陈强, 付强, 张勇.浅谈网络隔离技术[J].北京交通, 2010, (4) :195-197.
[6]于京杰, 戚仕涛.医院内网终端准入控制与测试研究[J].中国医疗设备, 2012, 27 (6) :42-44.
[7]伊勇, 李宇.PCI总线设备开发宝典[M].北京:航空航天大学出版社, 2005:67-69.
[8]何鹏举, 王万诚, 李高盈, 等.网络隔离设计器的设计与使用[J].控制工程, 2002, (6) :52-53.
[9]郭栋.加密与解密实战功略[M].北京:清华大学出版社, 2003:189-240.
[10]余威.安全隔离系统中隔离方案与实现[D].北京:清华大学, 2004.
数据库领域中的模式及模式匹配 篇8
为了有效地组织、管理数据, 提高数据库的逻辑独立性和物理独立性, 人们为数据库设计了一个严谨的体系结构, 模式是通过某些数据结构连接起来的数据成员集合, 是数据成员的逻辑级视图。数据库领域公认的标准体系结构是三级模式结构, 它包括外模式、模式和内模式。
1.外模式
外模式又称子模式, 对应于用户级。它是某个或某几个用户所看到的数据库的数据视图, 是与某一应用有关的数据的逻辑表示。外模式是从模式导出的一个子集, 包含模式中允许特定用户使用的那部分数据。用户可以通过外模式描述语言来描述、定义对应于用户的数据记录 (外模式) , 也可以利用数据操纵语言 (Data Manipulation Language, DML) 对这些数据记录进行描述和定义。外模式反映了数据库的用户观。
2.模式
模式又称概念模式或逻辑模式, 对应于概念级。它是由数据库设计者综合所有用户的数据, 按照统一的观点构造的全局逻辑结构, 是对数据库中全部数据的逻辑结构和特征的总体描述, 是所有用户的公共数据视图 (全局视图) 。它是由数据库管理系统提供的数据模式描述语言 (Data Description Language, DDL) 来描述、定义的, 体现、反映了数据库系统的整体观。
3.内模式
内模式又称存储模式, 对应于物理级, 它是数据库中全体数据的内部表示或底层描述, 是数据库最低一级的逻辑描述, 它描述了数据在存储介质上的存储方式与物理结构, 对应着实际存储在外存储介质上的数据库。内模式由内模式描述语言来描述、定义, 它是数据库的存储观。
在一个数据库系统中, 只有唯一的数据库, 因而作为定义、描述数据库存储结构的内模式、描述数据库逻辑结构的模式, 也是惟一的, 但建立在数据库系统之上的应用则是非常广泛、多样的, 所以对应的外模式不是惟一的, 也不可能是惟一的。
总而言之, 一句话, 外模式对应的是用户看到的信息, 例如视图;模式是一个全局的逻辑视图, 如基本表;内模式是对应的存储结构, 例如表的存储文件。
数据库的三级模式是数据库在三个级别 (层次) 上的抽象, 使用户能够逻辑地、抽象地处理数据而不必关心数据在计算机中的物理表示和存储。实际上, 对于一个数据库系统而言, 物理级数据库是客观存在的, 它是进行数据库操作的基础, 概念级数据库中不过是物理数据库的一种逻辑的、抽象的描述 (即模式) , 用户级数据库则是用户与数据库的接口, 它是概念级数据库的一个子集 (外模式) 。
用户应用程序根据外模式进行数据操作, 通过外模式与模式的映射, 定义和建立某个外模式与模式间的对应关系, 将外模式与模式联系起来, 当模式发生改变时, 只要改变其映射, 就可以使外模式保持不变, 对应的应用程序也可保持不变;另一方面, 通过模式一内模式映射, 定义建立数据的逻辑结构 (模式) 与存储结构 (内模式) 间的对应关系, 当数据的存储结构发生变化时, 只需改变模式—内模式映射, 就能保持模式不变, 因此应用程序也可以保持不变。
二、模式匹配
模式匹配是在作为输入的模式中有对应语义关系的元素间产生一个映射。给定两个模式, 根据可利用的信息, 发现语义对应的模式成员之间正确的映射关系的过程。模式是通过结构联系的一系列元素的结合, 模式匹配是数据交换的核心, 以两个模式S、T作为输入, 产生匹配对, 每个匹配对的一部分元素来自S, 另一部分元素来自T, 通过匹配表达式指出两部分元素如何关联, 例如, 模式T中的成员credit_limit_amount (信用额度) 与模式S中的成员credit_range存在映射关系credit_limit_amount=credit_range。模式T中的成员list_price与模式S中的成员price与tax_rate存在映射关系list_price=price* (1+tax_rate) 。由于准确的语义信息只有模式设计者才能掌握, 不能在表达式中完全表达, 所以模式匹配的自动实现是一个难于解决的问题。目前主要有基于模式内部信息的模式匹配和基于大规模数据和背景知识的模式匹配。
模式匹配的最终目标就是寻找两个或多个模式元素之间的语义上的对应关系。即给出两个模式S和T, 对S中的每个元素s, 利用所有可用信息 (包括模式信息、数据实例以及用户反馈信息等) 在T中找到与s在语义上最匹配的元素。在很多领域, 模式匹配都起着重要的作用, 例如Web数据源集成、电子简历、数据仓库的装载、数据库设计、站点的建立与管理、基于组件的开发等。模式匹配的定义从不同的角度有着不同的描述, 下面从几个不同的角度分别描述模式匹配的定义:
定义1 (解释和非解释的匹配) 令Mi=match (R (r1, r2…rn) …fm (sm) ) , 其中Mi是一个匹配结果, match是一个匹配算法, R是大小为n的一个元模式, s是一个大小为m的目标模式, fi是任意的一个一对一的函数, 应用于目标模式中i列的值。称给定的匹配算法match是一个非解释的匹配, 当且仅当在不考虑函数fi时两个匹配的结果M1和M2是相同的。相反, 如果两个结果是不同的, 就称为解释的匹配。
定义2 (元素匹配和结构匹配) 结构匹配算法利用表中列之间的关系, 而元素匹配算法仅考虑单一列的特性。
定义3 (1∶1的模式匹配) S和T是给定的两个模式, 其中, S={S1, S2…SN}, T={T1, T2, …Tm}, 对于模式S中的任一元素Si, 利用所有有用信息, 寻找模式T中与之语义相似度最高的元素Tj。
定义4 (复杂匹配) 给定S和T两个模式, O={O1, O2, …Ok}是一组在一定规则集R的约束下可应用到模式T上的操作集合, 对模式S中的每一个元素s, 寻找出与之相似度最高的元素t, t可以是T中的一个元素, 也可以是由T中的元素在规则R约束下构造的一个规则。
复杂匹配包括1∶n匹配, n∶1匹配和n∶m匹配。
三、模式匹配技术存在的问题
匹配操作研究在一定程度上解决了简单模式匹配中发现的问题, 但距其使用还有很大的距离, 除了当前的匹配方法不能较好的挖掘语义关系的原因外, 还有未充分研究匹配前的预处理, 匹配结果的动态维护, 自动匹配与用户参与的配合以及复杂模式中的匹配问题等因素。因此模式匹配在应用中存在以下问题。
1.匹配效率不高, 质量较差。
假设模式S有X个实体, M个属性, 模式T有Y个实体, N个属性, 如果仅考虑1∶1的成对属性匹配, 至少需要M*N次比对, 如果属性较少, 则工作量较小, 质量较好;如果属性较多, 则效率较低且质量较差。但实际应用中往往是属性和实体很多, 此外由此产生的匹配结果将是一个非常巨大的映射集合, 人工处理的工作量将是很大的。实际上, 直接成对匹配是没有意义的, 因为绝大多数比较计算都发生在语义无关的模式成员之间。
2.重复匹配。
在数据库中, 实体之间的联系通常通过主外键表示, 因此某些键码属性在多个实体中存在, 另外, 实际应用中为了方便查询和处理, 某些常用的信息可能存在冗余, 如果直接匹配会产生大量重复匹配。
3.同名异义的语义冲突匹配。
即名称相同或相似, 实际语义不同。例如, 在数据库建设中, 数据源S中的实体S1和实体S2都用属性amount描述金额, 但S1表示交易类信息, S2表示申请类信息;假设数据库模式S1中, 属性amount仅代表交易金额, 如果不考虑完整的语义和逻辑分类, 直接进行匹配, 很可能将S2中的amount与数据库中的相应属性建立匹配, 但实际上它们属于不同的语义背景, 毫无关系。
4.复杂匹配关系的处理难度加大。
主题数据库保障模式初探 篇9
主题数据库是面向业务主题的数据组织存储, 它的设计和建立与要解决的主要问题相关联, 很好地解决了应用系统之间的信息共享问题、源数据唯一性、规范性等问题。
随着数据业务的不断增长, 必然会对主题数据库的数据内容和提供的服务方式提出新的要求, 因此建立一套主题数据库的保障模式, 确保用户的访问质量是信息保障的一项重要任务。下面先介绍两种主流业务保障模式, 分析它们各自的优缺点, 然后, 结合用户和信息保障的实际情况尝试提出一种主题数据库保障模式。
1 数据主要保障模式
1.1 数据集中式保障模式
数据集中保障模式中数据集中存放到数据库中, 用户通过网络与数据库连接, 数据库为用户提供访问服务。这种保障模式的优点在于结构简单, 便于维护;缺点是当数据库支持的访问服务出现变动时, 用户必须学习使用新增服务, 并且无法及时对用户新增需求进行反馈。因此该模式主要用于业务简单且稳定的系统中。
1.2 业务集中式保障模式
业务集中式保障模式分前台业务受理区、后台业务集中处理区和数据库3个部分。前台业务受理区主要负责接受用户的访问, 向用户反馈业务受理结果等任务。后台业务集中处理区负责解读用户需求信息, 利用数据库处理用户需求, 并将最终结果反馈给用户。后台业务集中处理区与前台业务受理区通过网络连接, 后台直接访问数据库, 前台通过后台完成业务, 但不能直接访问数据库。
业务集中式保障模式的优点:①确保服务质量。在业务集中式保障模式中, 大部分业务由服务保障人员专门负责处理;②减少用户访问时间。当用户将业务交与后台后, 可以将更多的精力放在其他事务的处理上;③减少服务的培训工作。由于服务保障人员完成大部分服务, 主要是对服务保障人员进行培训。
业务集中式保障模式的缺点:①对网络带宽和稳定性要求高;②对服务保障人员的素质要求高;③对服务保障策略的要求高。
由于业务集中式保障模式具有以上特点, 实际经常运用于业务的访问服务较复杂且变化的系统中。
2 主题数据保障模式基本结构
2.1 主题数据分类
信息保障中心建立主题数据库目的是为用户提供数据服务。因此我们在考虑主题数据库的保障模式之前, 首先要对主题数据进行分类分析。这里我们将数据分为:简单数据、复杂数据。
简单数据是指已经存主题数据库中, 提供了访问服务, 并且用户已经掌握该服务操作方法的数据。对于简单数据用户可以通过系统提供的服务独立完成访问。
复杂数据包括以下三类数据:
(1) 是指与主题相关, 但没有保存在主题数据库中的数据。
(2) 已存在于主题数据库, 但没有提供访问服务的数据。
(3) 已存在于主题数据库, 并提供了访问服务, 但当前用户没有掌握该服务操作方式的数据。
主题数据中的简单数据和复杂数据并不是静止不变的, 而是复杂数据不断向简单数据转换的过程。一旦对于用户, 复杂数据满足保存于主题数据库、提供了访问服务、服务为用户掌握这3个条件, 那么该数据就转换为简单数据, 下次用户就可以直接访问了。
规划建设主题数据库, 必须遵循一套完整的工程标准, 当它建成时, 就应当满足用户绝大部分的实际需求。因此, 用户对主题数据的需求是大多是简单数据, 少量是复杂数据。
2.2 主题数据保障模式基本结构
本文借鉴数据集中模式和业务集中处理模式, 提出了一种主题数据保障模式, 基本结构如图1所示:
主题数据保障模式是根据用户对简单数据、复杂数据不同的两种访问方式建立的, 由5个模块组成。
(1) 前台用户访问区:
用于接受用户需求, 反馈结果给用户, 在本文中简称为前台。
(2) 主题数据交流平台:
用于主题服务人员在处理复杂数据时, 与用户进行交流的平台。在本文中简称为交流平台。
(3) 后台服务保障区:
帮助用户对主题数据库进行访问, 是主题数据保障模式的核心, 它由主题数据服务人员组成。在本文中简称为后台。该工作区需要完成以下工作:
①该区服务人员通过交流平台理解前台所提需求;
②根据用户需求在主题数据库中寻找满足需求的数据和服务;
③如果主题数据库没有满足用户需求的数据, 服务人员通过其他数据源寻找;
④如果主题数据库没有满足用户需求的服务, 服务人员委托第三方建立新的服务;
⑤维护主题数据库的数据与服务;
⑥维护主题数据交流平台, 介绍主题数据库的数据和服务的内容, 引导用户通过交流平台获得访问主题数据库的经验和方法。
(4) 主题数据库:
本文的主题数据库是一个宽泛的概念, 由两部分组成。一部分是指围绕主题建立的虚拟数据库系统, 另一部分是指为访问该虚拟数据库建立的相关服务。
(5) 其它数据来源:
是指围绕主题建立的一些潜在的数据来源渠道, 当服务人员发现用户需求无法在当前主题数据库中得到满足时, 可以利用这些渠道寻找信息 (例如搜寻其它数据库, 请教该领域内的专家, 在互联网上搜索等等) 。
2.3 主题数据保障模式基本流程
如前所述, 我们将主题数据简单数据和复杂数据两类。图2描述了主题数据保障模式的基本流程, 其中对简单数据的访问处理较简单, 用户直接通过所掌握服务访问主题数据库即可。对于复杂数据的访问处理较为复杂, 其详细处理流程如图2所示。
复杂数据保障基本流程如下:
(1) 如果用户发现当前主题数据库无法满足需求时, 将需求发布到交流平台。
(2) 服务人员对从交流平台中得到的用户需求, 首先要与用户进行交流, 以便正确理解需求。然后对需求进行分析, 根据分析结果做如下3种处理:
①如果发现当前主题数据库提供的数据和服务可以满足用户需求, 主要是因为用户对主题数据库提供的服务使用经验不足造成的, 服务人员可通过交流平台指导该用户实现需求;
②如果主题数据库存放有所需数据, 但当前服务不能满足用户需求。服务人员可以通过交流平台与用户沟通, 以便确定是直接提供该数据访问方式, 还是委托第三方建立新的服务来满足用户需求;
③如果主题数据库的数据不能满足用户的需求, 服务人员将进行下一步操作。
(3) 服务人员通过其他数据源获取满足用户需求的数据。值得注意的是, 这里获取数据的来源必须是权威的, 即得到官方认可的数据源。
(4) 在获取满足用户需求的数据后, 服务人员将该数据来源添加到主题数据库中。如果添加的数据不能通过已有服务访问, 请参见步骤 (2) 中②处理。
(5) 服务人员通过交流平台将新的数据和服务的描述信息反馈给用户, 用户根据该信息访问主题数据库。
3 主题数据保障模式的特点
本文提出的主题数据保障模式有如下特点:
(1) 确保了服务的效率。
本模式允许用户通过提供的服务直接从主题数据库中获取所需数据。这在需求大多数为简单数据的情况下, 确保了用户获取数据的效率。
(2) 确保了服务的质量。
在本模式中, 当用户在无法直接从主题数据库中获取所需数据时, 可以在专业的服务人员帮助下获取, 从而确保了用户获取数据的质量。
(3) 减少访问时间。
在本模式中, 用户对自身短期内无法直接获取的数据, 只需提供需求信息, 而由服务人员在后台对需求信息进行解释、分析、查找、总结获取最终结果。将极大减少用户访问数据的时间和精力。
(4) 减少培训时间。
随着能够提供给用户的数据和服务将越来越多, 如果不对用户进行培训, 难以确保用户对数据的正确访问。本模式对复杂数据的访问主要通过服务人员来实现, 因此只需要对信息服务保障人员进行培训, 减少对用户的培训要求。
摘要：为用户提供主题数据库是数据保障的主要工作。结合信息化实际情况, 探讨主题数据库的保障管理策略。
关键词：主题数据库,保障模式
参考文献
数据库安全模式 篇10
[关键词]Java连接池JDBC设计
中图分类号：TP18文献标识码：A文章编号：1009-8283(2009)04－
1绪论
Java语言以其面向对象、安全性、平台无关性，以及多线程和分布式等特点，成为风靡全球的程序设计语言。基于Java的技术也赢得了越来越多的企业级用户。在面向企业的应用系统中。数据库访问技术是其核心技术之一。JDBC是SUN公司发布的Java领域访问数据库的规范。执行查询两个部分。本文以连接池设计模式为理论依据，提出了一个数据库连接池方案，其基于JDBC的实现可以达到：(1)每一个数据库连接得以高效、安全的复用，避免频繁的数据库连接建立、关闭的开销；(2)限制最大连接数量；(3)为恶意的连接建立超时参数等。
2连接池模式叙述与设计
设计模式是近年来面向对象软件设计领域的研究热点之一。研究设计模式的目的在
于，撇开具体应用环境中的细节，在比较高的抽象层次上应用已被证明是行之有效的一般方法，解决在软件设计中重复出现的同类问题。
模式具有不同的粒度和抽象水平，但是它们之间存在共性，可以采用一个模板来控制对模式的描述。
3JAVA数据库连接池方案的实现方案中除了有上文连接池模式中成员：
客户对象(Client)、连接池对象(Connection-Pool)、连接实例对象(connectlonObjeot)以外，还根据实现需要增加了数据库管理者对象(DBManager)和计时器对象(Timer)。
4两种方案试验对比与结论
4.1理论对比
采用连接池和不采用连接池两种方案的
(1)基于Java的应用程序(包括JavaApplet／Servlet和Application)是直接通过数据库管理器获取和释放数据库连接。这将影响Java应用程序的性能。这种影响是由数器进程创建和关闭那些连接对象而引起的。应用服务器一般需要花数秒的时间来建立数据库连接。而且是分别对每一个来自Java应用程序的请求进行连接建立和关闭。(2)基于Java的应用程序可以透明地共享资源池的多个连接对象。在此情况下，因为连接池预先在启动时创建连接对象，所以，在应用程序请求使用连接对象时，不会引起数据库资源管理器上的系统开销。
4.2试验设计
使用同一个Java数据库应用程序，该程序的数据库访问模块有两种选择：1)有连接池方案；2)无连接池方案。每一方案中数据库系统又有三种选择1)基于SUN Solaris平台的Oracle数据库；2)Windows NT平台上的Oracle数据库；3)Windows NT平台上的MicrosoR Access数据。上述两种选择一共有六种组合，对每一组合模拟30个客户，客户每隔3秒钟访问数据库一次的情况。记录50次访问的数据，对其取平均值。
4.3试验结果和总绩
从试验数据可以看出，是否采用连接池方案对于执行查询的时间影响不明显，两种方案所花的时间基本相当。这说明无论是否采用连接池，在数据库访问的两部分时间中，执行查询所需的时间，都是不可能显著降低的。
而两部分时间中的另一部分——建立连接的时间，在采用连接池前后有显著差别。对于象Access这样的小型数据库(仅用在开发期间的测试中)，其响应时间的差别特别明显。这说明了在Java数据库程序中。建立连接这部分时间还是值得斟酌的。即使因为Oracle专业级别的处理能力削弱了这种反差，但是3-4倍的时间差距，还是能够成为在大量并发访问的情况下选择连接池方案的理由。