问：我看到有的文章说，数据库的保密数据不应该把编入索引或作为索引关键字。这是什么意思？我应该采用什么最佳方案来保证在我的公司里不会出现这种问题？

　　答：数据库索引就像是课本的索引一样。他们提供对查找所要求数据的快速参考点。从而减少了数据库伺候器的负担并加快了数据检索的次数。在一个关系型数据库中，每一个表格都应该有一个作为索引的主键值，这个主键的唯一作用是在数据库的各记录间创建一个定义好的链接和一个独一无二的值。为了保证数据库的技术实现与商务规则相分离，这个主键值不应该有任何实际的意义。比如：一个银行客户的表格可能用一列来存储每一个客户独一无二的银行账户号码，这个号码可能作为主键的候选之一。每一客户数据的主键值都是不同的。
 
　　为了加快客户数据的检索速度，比如说，每个客户的银行帐户号码或社会安全号码可以被编入索引。这个设定允许银行职员使用这条特殊的信息来快速搜索数据库。然而,Core Security Technologies公司的研究人员发现，这些索引是一种新技术攻击的对象。为了在数据库的索引运算方法中找弱点，攻击采用一系列嵌入的操作，然后从索引字段中提取数据。这些嵌入指令并不是攻击应用程序逻辑或代码的漏洞，所有数据库使用人员都可经常使用这样的嵌入指令。
 
　　最初的防范建议是不对保密数据使用索引。然而没有索引，数据检索是很复杂的。为了找到与银行帐号或社会安全号码相匹配的记录，数据库伺服器必须浏览所有表格，查找客户表格的每一行信息。而对于多表格相互间的复杂查询很大程度上取决于索引值。这些延迟会对大型商业数据库性能产生很大影响，可能会导致瘫痪。

　　不过，没有报导说这种攻击广泛存在, 它只是一种似是而非的威胁。数据库管理员应该更加密切地监控日志文件来寻找异常反复的嵌入操作。应用程序防火墙也需要致力于探测异常活动模式。对于新的数据库，设计者必须对数据模型和用户代码做出一些调整。对于必须进行索引的的每一列，都必须有一个对应的列来存储保密数据的散列值。然后，用这个散列值作为索引。这样，攻击者就不可能计算出保密数据的值了，从而有效地防止数据的攻击。通过搜索已编入索引的散列值，并将数据的散列值作为搜索准则进行传递，应用程序仍然能够有效地搜索保密数据。