摘要：在业务支撑系统中，由于各分系统数据库较多，业务数据交互比较频繁，也经常使用数据库链接的方式来实现业务的处理，并且其中不乏有信赖度较高的数据库之间采用了同义词来方便在业务流程的开发与使用。同时由于复杂环境的存在使得这种方式存在潜在的安全隐患。文中通过实例的展现了安全隐患的产生过程及预防措施。
关键词：数据库链接 同义词 权限
中图分类号：TP311.13 文献标识码：A 文章编号：1007-9416（2012）09-0224-02
在通信运行商的业务支撑系统中，存在着关键业务数据库，非关键业务数据库，测试数据库等几十个数据库，各数据库相互独立，但又存在各种错综复杂的各类业务关系。而这种关系经常使用数据库链接来产生或紧或远的耦合性。本文将采用实例的方式来解述在数据库链接使用中的一个误区，同时也是一个安全隐患。
环境中有3个数据库，testdb（测试数据库），interdb（业务转发数据库），actdb（账务数据库）如图1。
在interdb中创建用户cxlink，并赋予部分权限：
sql>grant connect，select any table to CXLINK；
在testdb创建到interdb的数据库链接：
sql>create public database link INTER_LINK connect to CXLINK identified by "***" using "interdb"；
在interdb与testdb之间存在一个testdb访问interdb的数据库链接，权限仅为select any table。这样，应该认为testdb与ACTDB之间的操作应该影响不大，最多也是读取表信息的权限。
接下来看一下interdb与ACTDB之间的关系，业务转发数据库与账务数据库同为关键业务数据库，之间的关系较为复杂，在开发设计、存储过程调用等密切相关业务处理时，都做了较为密切的耦合，而这个密切的关系又是通过建立数据库链接，使用大量公用同义词的方式建立的。
ACTDB中用户bill被赋予以下权限：
sql>grant connect，resource，select any table，update any table，insert any table，delete any table to bill；
然后，在interdb数据库建立有指向ACTDB的数据库链接：
sql>create public database link ACTDB_LINK connect to bill identified by "***" using "ACTDB"；
同时，存在大量同义词，如：
sql>create or replace public synonym tab_act_data for tab_act_data@ACTDB_LINK；
因为有了这个权限较高的数据库链接ACTDB_LINK，和通过这个数据库链接建立的同义词，使得在interdb中可以方便的对ACTDB数据库进行读取与DML操作，但actdb和testdb之间还看不到有什么影响。
testdb现在与interdb和ACTDB之间有什么样的关系呢？下面进行几个操作，看看结果是否在意料之中。
在testdb选取一个用户scott，该用户只有connect角色权限和select any table权限。
操作1，在本数据库testdb下执行对本数据库表的操作：
sql>update int.tab_code_name set seq_id=555；
ora-01031：insufficient privileges（权限不足）
操作2，通过数据库链接执行对interdb的表操作：
SQL>update tab_ineter_data@INTER_LINK set aaa="szx5"；
ora-01031：insufficient privileges（权限不足）
操作3，通过数据库链接执行对interdb指向ACTDB的同义词的操作：
SQL>update tab_act_data@INTER_LINK set change="2006"；
65 row updated
突然发现，ACTDB的数据严重的暴露在testdb的一个极低权限的用户下，这个用户对interdb的数据是没有任何DML操作权限的，甚至在testdb都只有很低的权限。这足以让一个开发设计人员惊出一身冷汗，严重的安全隐患，严重的设计缺陷，但好像又不可思议，逻辑上不应出现这种现象。这考验了数据库开发设计人员的长远思维，甚至考验了DBA的洞察力。
来从数据库语句执行方式上分析一下这个虫洞效应出现的原因。熟悉oracle数据库技术的都知道，oracle数据库在执行一条语句时，会先进行语句解析，采取一种较为优化的方式来进行数据库的操作。当一条SQL语句从客户端进程传递到服务器端进程后，需要执行如下步骤：
（1）在共享池中搜索 SQL 语句的现有副本；
（2）验证 SQL 语句的语法是否准确；
（3）执行数据字典查找来验证表和列的定义；
（4）获取对象的分析锁以便在语句的分析过程中对象的定义不会改变；
（5）检查用户访问引用方案对象的权限；
（6）确定语句的最佳执行计划；
（7）将语句和执行计划载入共享的SQL区。
可以看到检查对象权限是在语句解析中执行的，而发起采用数据库链接的语句相当于在客户端向目标数据库发送了一个SQL指令，只是这个SQL指令被数据库链接又重新做了封装。而这个封装主要就是被赋予了数据库链接所具有的权限。
这样可以分析操作3种的DML语句从testdb发起后经历了如何的变迁。首先，语句在testdb经过验证，目标对象先指向了interdb，SQL指令要通过INTER_LINK数据库链接转发到interdb，在interdb，权限被赋予cxlink用户权限；在interdb上。发现它指向了一个同义词，同义词又是根据ACTDB_LINK创建的，这样，这条sql指令又被传递到ACTDB，注意此时，DML语句已通过ACTDB_LINK数据库链接获得DML（update）操作的权限， 而此时，该SQL指令才开始进行解析过程，而对象的DML权限在此时已被间接赋予。
这种情况的产生是令人生畏的，如何防止此类情况的发生呢。
（1）首先，从开发设计时应规范数据库链接的管理；
（2）其次，对同义词的创建和使用应进行谨慎的考虑，不能只考虑这2个库之间的问题，要对所有可以访问此类同义词的对象都要甄别；
（3）最后，如果真的出现此类情况，而由于业务复杂性无法修改的，只有通过对数据库加强稽核监控，保障风险降低到可控的范围。
通信运营商的业务支撑系统BSS承载着业务受理、用户缴费、账务处理等重要功能，同时，周围辅助系统有比较多，如联机采集系统、经营分析系统、结算系统、测试系统等。由于各系统都处于一个大的局域网之下，系统之间的关系又相当于主从系统或子系统，平时管理时相对较为开放，很多业务之间数据的传递都是通过数据库链接来实现的，而在数据库链接建立初始时所赋予的权限相对明了、直观，以至于对此类操作置于相对成熟、安全的管理范畴。但是，由于有了同义词的加入，使数据库链接的操作可以指向了第二跳的数据库，使得操作在不同情况下具有了不可预知的后果。所以，在数据库的开发设计、业务实现时加强数据库链接、同义词的管控不可大意，BSS系统数据安全的重要性对通信运行商不言而喻，如果由于此种原因致使数据被误操作和恶意篡改而造成业务中断的话，对通信运行商的信誉和能力将是巨大的考验。
