安华金和防统方解决方案

安华金和医疗系统

主动“防统方”解决方案1.方案综述

建立统方

数据保护区

统方数据

访问追踪

(1) 从根源解决“防统方”难题

(2) 变事后追查为主动防御

(3) 变相互制约为权责分明

(4) 应用改造接近零代价。

2.医院面临的“防统方”困境

2.1. 医疗信息系统“统方”四大途径

目前，卫生行业信息系统均采用专网互联，并采用了防火墙、杀毒软件等基本的安全防护软件，但仍然存在众多安全威胁和监管漏洞，导致非法“统方”行为的发生。

2.1.1.医疗系统使用者非法“统方”

医院的HIS等医疗系统，集中了处方统计分析业务、处方查询（药剂科），以及挂号、病历、诊疗信息管理等核心业务模块，后台涉及到医生、药品、剂量、单价、应收金额等直接或间接能够“统方”的信息，这些功能和数据如果缺少严格的控制，将给非法“统方”提供极为便利的条件：

（1）利用处方统计分析业务功能，在HIS中进行直接“统方”

一些医院的药剂科本身就兼具正常“统方”的职责，在一定的时间药剂科科长需要对医生、药品和剂量信息进行统计，以防止医生用药比例过高导致医生停诊。

但目前HIS系统对该权限控制不严格，导致任何人员、任何时间、任何机器均能滥用“统方”功能。

（2）利用处方查询业务功能，在HIS中进行间接“统方”

对于药剂科的处方查询、处方打印操作，本身就需要具备查看处方中的药品、医生名称、药品数量等关键信息的权限。合法的业务操作是基于处方编号进行精确查询，仅能返回特定处方的信息。

但这时如果应用系统的开发控制不严，被人为篡改查询语句或植入按时间范围、按医生及药品名称进行批量查询的报表，则能够迅速地获取批量处方信息，并在此基础上间接地完成“统方”。

2.1.2.开发人员、维护人员非法“统方”

医疗信息系统的开发和维护人员掌握着系统访问数据库的用户名和口令，这些人员经常需要在医院内部进行日常工作，完全可以使用该数据库用户直接登录数据库，构造“统方”SQL语句进行非法“统方”。

2.1.

3.DBA人员非法“统方”

信息科人员掌握着SYS、SYSTEM等超级用户，这些用户具备了访问所有数据的权限；从而使毫无业务需要的DBA人员能够访问所有处方数据，具备“统方”的最佳途径；

另外，DBA人员也可以直接查询数据库中的用户密码表，使用具备“统方”权限的应用用户登录到HIS系统直接进行非法“统方”。

2.1.4.黑客入侵医疗系统非法“统方”

在高额利益的驱使下，当前黑客窃取“统方”数据的问题已不容忽视。总结黑客的手段无外乎以下三种：1）利用HIS等医疗系统的Web漏洞入侵数据库；2）利用数据库漏洞直接入侵数据库；3）入侵数据库服务器主机直接窃取数据库文件、备份文件等。

2.2. 政策“防统方”缺乏技术手段支撑

2010年6月21日颁发的《卫生部关于进一步深化治理医药购销领域商业贿赂工作的通知》中明确指出，“要对医院各个部门通过计算机网络查询医院信息的权限实行分级管理，对医院信息系统中有关药品、高值耗材使用等信息实行专人负责、加密管理，严格统方权限

和审批程序，未经批准不得统方，严禁为商业目的统方。”

福建省卫生厅近日发出《关于加强医院信息系统管理的通知》，凡是有可能涉及对药品、医用耗材用量按医生进行查询统计的模块或软件应予以卸除，并且要对信息系统中的药品相关信息查询功能模块进行清理，删除一般科室功能模块中药品信息查询统计程序。不得授权其他科室和个人查询医生用药情况。

但在以上国家政策和地方政策颁布下，由于缺乏具体的技术手段作支撑，现实中的“统方”事件仍然不断发生：

2005-2008年海宁某医院信息科信息管理员王力，通过医生用药数据库中的药品及医疗设备的采购资料、医生用药量等信息资料，向药品经销商沈某、方某等人出售“统方”信息，共获得14万元。

2008-2010年1月杭州某医院计算机网络中心副主任金某与职员林某，向药品销售商李某等人出售“统方”信息，共获得13万元。

2011年9月，黑客多次潜入福州多家三甲医院，接入内网窃取医院的用药信息，然后高价卖出，累计获利上百万元。

……

2.3. 单纯审计手段无法防止非法“统方”

当前部分省市医院采用审计软件“防统方”，却面临3大致命缺陷：

1）事后分析，无法主动阻止内部人员非法“统方”行为的发生；

2）难以准确地定位“统方”发生的具体操作人员，因此无法辨别非法“统方”和正常“统方”，不能起到震慑的作用；

3）无法阻止来自于外部黑客的攻击和存储层的数据泄密。

3.安华金和“防统方”解决方案

3.1. 方案简介

安华金和“防统方”解决方案基于安华金和数据库保险箱系统实现，以“统方”数据为中心，建立“统方数据保护区”，监控和限制对“统方”数据的操作行为，建立主动防御为主和事后追踪为辅的综合“防统方”解决方案。

(1) 关键数据加密、并实现三权分立

对医疗系统用户表的口令字段加密，对“统方”三要素（医生、药品、剂量）中的剂量相关信息加密，DBA对加密数据不再拥有授权权限和审计权限，在没有密文访问授权的前提下，DBA也不能访问加密数据，同时DBA的密文访问尝试也会被审计下来。有效控制和审计DBA的非法“统方”行为，同时防止黑客利用漏洞窃取处方信息的行为。

(2) 将密文访问权限与医疗系统绑定

HIS等医疗系统需要对其使用的数据库用户开放密文的访问权限，以开展正常的业务操作。开发、维护人员完全可以凭此数据库用户绕过医疗系统直接登录数据库，进行非法“统方”，因此本方案将该用户的密文访问权限与指定的医疗系统绑定，防止该应用漏洞。

(3) 启用字段组权限控制

部分HIS等医疗系统有正常的“统方”需要，同时也是商业目的“统方”的一大主要途径。本方案要采用字段组权限控制对医疗系统“统方”进行有效的控制，具体将“医生”、“药品”、“剂量”设置成字段组，正常“统方”时需要向安全管理员申请该字段组的访问权限，否则同时出现这三列的查询将被禁止，从而杜绝通过医疗系统任意统计处方和泄漏处方信息的行为。

(4) 开启处方数据的访问审计

对加密的处方数据开启访问审计，便于追查和监控DBA和开发、维护人员的“统方”操作行为，起到有效的震慑作用。

3.2. 方案介绍

DBCoffer 安全管理终端处方信息查询模块

统方功能模块“统方”途径：

利用His 系统的“统方”功能直接“统方”。由于有合法“统方”的需求存在，因此在现有的His 软件中，无法完全屏蔽该功能；His 使用者利用该功能进行非法“统方”。 利用His 系统的统计功能间接“统方”。通过某些His 系统的统计信息如药品价格可以推导出药品名称，则通过“单价”+“总价”+“医生”也可以推导出“统方”信

息。

防御手段：

字段组访问控制：

直接“统方”的防御：对同时出现“药品”+“剂量”+“医生”的查询进行授权控制

间接“统方”的防御：对同时出现“单价”+“总价”+“医生”的查询进行授权控制

（2）开发及维护人员“统方”

“统方”途径：

利用His系统中的用户名、密码，使用数据库访问工具，直接访问数据库中的“统方”数据进行“统方”；

利用His系统维护人员的身份，获取存储在数据库中的His用户名和密码，模仿合法用户登录His系统进行“统方”。

防御手段：

将His系统访问数据库的用户名和密码与His系统绑定，使用户无法绕开His系统访问数据库。

对His系统中的用户名和密码加密，结合随即盐扰乱策略，增加对这些信息的保护。（3）黑客“统方”

“统方”途径：

利用数据库的漏洞，对数据库进行漏洞攻击，使普通用户具备超级用户权限，访问数据库中的“统方”数据。

对数据库文件进行底层直接访问，由于文件中存储的是明文，通过DUL和MyDUL 工具直接导出“统方”数据。

防御手段：

对数据库建立独立于数据库管理系统的权控体系，使黑客的权限提升漏洞无效。

对数据存储文件中的数据进行加密，使导出数据为密文。

（4）DBA“统方”

“统方”途径：

利用超级用户权限，直接察看“统方”数据。

利用超级用户权限，获取存储在数据库中的His用户名和密码，模仿合法用户登录His系统进行“统方”。

防御手段：

建立对“统方”数据的三权分立体系，使超级用户在未受权限下无法察看“统方”

数据。

对His系统用户名和密码进行加密，使超级用户在未受权限下无法察看His系统登录信息。

3.3. 方案的价值与优势

通过建立主动防御为主和事后追踪为辅的综合“防统方”解决方案，使DBA、开发人员、维护人员、黑客彻底远离“统方”问题的中心—“统方数据”，帮助医院有效管理医疗系统的“统方”权限，彻底解决借助信息系统非法“统方”的难题。

(1) 从根源解决“防统方”难题

从数据库级别进行防控，从根源上彻底控制“统方”数据信息的泄露，为医疗信息化打好底层基础。

(2) 变事后追查为主动防御

现有的一些“防统方”技术，通过监控和记录数据库的访问行为，分析数据库访问的异常行为，找出可疑的“统方”行为，是一种事后追查方式，分析效果也难以预料。

DBCoffer通过加密技术和独立权限控制技术，将“统方”数据与无关工作人员进行隔离，有效防止非法“统方”行为的发生。

(3) 变相互制约为权责分明

现有的一些管理解决方案，更多地是相互制约的角度出发，增加对DBA工作的人员监督；但使工作的成本增加，工作的效率降低，工作职责的混乱。

DBCoffer通过三权分立特性，使DSA(安全管理员)和DBA的权责更加分明，从而有效地将数据维护和业务需求进行分离，既能保证DBA完成日常数据库维护工作，又能使管理层或督察人员有效控制“统方数据”的访问。

(4) 应用改造接近零代价。

DBCoffer的实施，对于现有医疗系统透明，无需改造，原有Oracle核心特性均可继续使用。同时DBCoffer集中控制的模式，能够更快地、无缝地融合到现有医疗信息系统中。

4.DBCoffer产品简介

4.1. 产品特点

●透明数据加密

DBCoffer支持国际先进的密码算法，以及我国的密码管理机构认定的加密算法。对数据库的指定列进行加密，保证敏感数据在存储层为密文存储，防止数据库数据以明文形式暴露，以实现存储层的安全加固。

透明的数据加密有两层含义，一是对应用系统透明，即用户或开发商不需要对应用系统进行任何改动；二是对有密文访问权限合法用户看到的是明文数据，该过程对用户完全透明。

●增强访问控制

DBCoffer增设数据安全管理员（Data Security Administrator，DSA）。DBA和DSA完全独立，共同实现对敏感字段的强存取控制，实现真正的责权一致。DBA实现对普通字段的一般性访问权限控制，DSA实现对敏感字段的密文访问权限控制和加解密处理。

该功能是对Oracle访问控制能力的加固，防止了特权用户对敏感数据的非法访问。

●敏感数据审计

DBCoffer增设安全审计管理员（Data Audit Administrator，DAA），提供对数据库中敏感数据的访问进行审计追踪。传统的审计技术，由于审计的信息量大，审计功能的开启，将对性能造成极大的影响；而DBCoffer中仅针对敏感数据进行审计，极大降低了审计的负载，从而有效保证了在开启审计功能时的数据库性能。

●应用绑定安全

DBCoffer应用绑定功能可以实现对Oracle用户与应用的捆绑。现在的应用软件对Oracle数据库访问的用户名和密码，保护措施都较弱，或出于管理的角度，需要对部分用户公开。虽然应用本身进行了有效的权限设定，但可以通过应用访问的数据库用户名和密码访问敏感数据。通过DBCoffer应用绑定功能，防止通过数据库浏览或管理工具，使用应用的数据库用户名和密码访问敏感数据。

●高效数据检索

DBCoffer进行安全增强后，依然能够对加密数据进行索引查询，从而保持Oracle数据库的高效访问能力。

DBCoffer通过专利的、高度安全的加密索引技术，突破了传统技术对加密列不能使用索引的限制；在保证索引数据的高度安全基础上，提供了对已加密数据为检索条件的索引查询；在加密列上进行的等于、大于、小于和Like操作依然可以使用索引。

●高度可靠支撑

DBCoffer通过与Oracle的数据集成存储、RAC支持、双机热备、自动透明故障切换、应急模式、快速数据恢复等技术，使DBCoffer提供与Oracle相当的高可用支持和异常故障处理能力。

●简单、易用、灵活

DBCoffer产品稳定可靠，产品化程度高，图形化管理界面，简单易用。安华金和数据库加固系统提供三个级别的产品，单服务器的软件版，单服务器的硬件版，网络版，部署灵活。

4.2. 系统功能

●数据加密

对指定加密列按照指定算法进行加密后，存储到Oracle中的数据为密文。

能够实现对以下数据类型的列的加密：VARCHAR2，VARCHAR，CHAR，CLOB，BLOB，NUMBER，DATE。

授权用户读到的信息是明文，非授权用户读到的是空或密文。

密钥策略应用：

1) 可以对加密列指定加密算法、密钥长度、密钥有效期；在加密转换和脱密转换中使用这些策略。

2) 可以对一个已经存在的加密列指定新的加密算法、密钥长度。

3) 用户可以对加密列更新密钥（密钥更新）。

4) 加密策略和密钥更新后，已加密数据需要按照新的密钥和加密策略进行加密（数据轮转）。

●透明访问

透明访问包含以下几个层面的需求：

SQL语句透明：SELECT、UPDATE、INSERT、DELETE四种SQL语句进行操作，应用程序不用作修改即可拥有安全特性。

存储程序透明：对于应用透明支持的含义还包括对存储过程透明的支持。

开发接口透明：提供对应用开发接口的全面透明支持，包括：JDBC、ODBC、OLEDB、ADO、OCI等。

数据访问能够做到对象透明：指定加密列的数据库对象，应用在访问时不用变更表名、列名、列类型或显示调用解密函数。

管理工具尽可能透明：Oracle提供的前台管理界面（如：企业管理器、查询分析器）仍然可以正常使用。

●三权分立

增设数据安全管理员（Data Security Administrator，DSA）。

DBA和DSA完全独立，共同实现对敏感字段的强存取控制，实现真正的责权一致。

DBA实现对敏感字段的访问权限控制，DSA实现对敏感字段的加/脱密权限控制。仅有DBA授予的访问权限而没有DSA授予的加/脱密权限，用户只能访问到密文，或者只能得到空字段值。DBA拥有对加密字段的管理能力，而没有查看和修改真实数据的能力。

实现加脱/密功能的授权管理，包括：

1) 用户管理：把Oracle中的用户引入到DBCoffer中，以方便对其授权。

2) 角色管理：在数据库保险箱中建立自己的权限角色，可以对角色进行授权，用户可属于某角色，将继承该角色的权限。

3) 安全域管理：指的是敏感字段的集合，需要安全员指定。

4) 授权管理：指安全域中的字段赋予角色或用户的过程。

5) 能有效防止新特权用户的产生：

不存在某种授权路径或安全漏洞，使某个工作人员同时具备DBA和DSA的权限，也就是不存在能够设置加密策略的同时，又可以进行数据管理的特权用户。

DSA用户的安全登录能够提供用户名/密码方式，也可以提供USB Key方式。

●自身安全

数据库保险箱在提供Oracle的安全增强的同时，也要保证自身的安全，以防止产生新的安全漏洞，包括：

保证数据库保险箱所提供的安全功能不可旁路；

数据库保险箱管理的密钥信息不泄露、授权信息不可篡改；

对数据库保险箱的管理功能的使用，也即DSA的身份要经过强认证。

●产品化

安装包：提供成熟安装包，使安装和部署过程简单；

管理界面：提供易用、美观的GUI界面，使DSA能够通过简单的界面操作，就能完成复杂的管理功能。

4.3. 系统兼容性

●操作系统兼容性

兼容Windows，UNIX，Linux，AIX等当前主流操作系统型号。

●密码算法兼容性

AES128，AES256，3DES，SCB2（国密办批准）。

●加密设备兼容性

支持国密办和机要局指定的加密设备；要求这些加密设备的加密速度不低于200M/S。

●Oracle数据库兼容性

Oracle 8i，9i，10g，11g。