防止开发人员开发后门程序，数据库安全之应用程序调用的危险

 

数据库安全本身是一个比较大的概念，其中包括数据独立性、数据安全性、数据完整性、并发控制和故障恢复等。这里我想讨论一下数据的安全性和应用程序对数据库调用的安全验证。

对于数据安全性，

一般采取隔离法则，即把重要的数据隔离出来。这种方法比较常用，操作性也强。

二是采用授权机制，通过数据库供应商的安全机制保护数据。通用的方法，不解释。

三是对数据进行加密后再存储于数据库。但这样对应用程序调用有影响，而且对于ORACLE这种供应商，一旦对数据进行加密，一些功能就不支持。所以这种方法适用于对应用程序调用要求不高，但数据安全性高的情况。

 

对于应用程序访问数据库的安全检验，是本文着重讨论的话题。先看一下常用的应用程序架构。

 
 

这种架构的好处就是避免了应用程序直接对关键数据进行操作，中间层用来进行系统认证、IP认证、授权认证。而真实数据库则是完全对外透明，应用程序服务A和B并不知道其地址、用户名和密码。中间层也不会对外开放，通过JMS消息机制传输数据，可以保证数据的安全和完整。

l  系统认证：对于图中，只有应用服务器A和B才能对数据库进行修改的操作。

l  IP认证：对于外网IP，非授权的IP进行过滤

l  授权认证：设定安全策略，例如，应用服务器A或B只能对授权了的数据进行操作，B不能访问A能访问的数据，A也不能操作B访问的数据。

 

这种架构可以防止大部分的非法入侵，除非你攻破了企业内网，并非法获取了数据库的用户名密码，否则这种方式是比较安全的。

但这种架构还是有问题，如果应用服务器中的应用程序留有后门程序，即应用程序开发人员有意或无意地创建了一些不用登陆便能使用程序资源的程序。无意地即在开发过程中，为了调试方便而开放了一些页面，可以查看数据库的内容，但程序实际运行中并未删除；有意地即刻意保留后门，供日后非法入侵所用。对于这种现象，我设计了一个中间层来保护数据的调用。如下图

 
 

但这种方法还是防范不了后门程序内嵌入已有程序里。比如说在一个页面里有一个隐藏按钮，此按钮可在页面通过程序显示出来，之后再调用这个按钮，让其去后台抓取资料。

像这样的情况就需要软件开发中的代码检查，即代码安全性检查，做到每个人提交的代码都需要相关人员进行审查，要有完整的代码跟踪记录。