新炬网络 发表于 2013-09-26 14:58

云里雾里看Oracle12C Data Redaction

       来源新炬网络
       OOW第二天,我参加的座中均涉及Oracle Database 12C安全方面的新特性。其中最吸引我眼球的莫过于产品ORACLE Audit Vault and Database Firewall名为Oracle Data Redaction的功能。

       Oracle Data Redaction可以在数据库层面实现敏感数据的屏蔽,一个典型的例子为话务中心里面,通过特定的配置,可实现话务员仅能从获取屏蔽后的客户信用卡敏感信息,而经理则不受限制。

       Oracle Data Redaction的策略有多种,可根据数据库账号、应用程序账号、主机、时间等等多种维度结合项目需求实现灵活的配置,它最让人着迷的地方在于对应用程序透明,无需更改代码。这里有一个关键点,就是应用程序账号如何界定,在未接触真正产品前,讨论这方面内容意义不大。

       关于这个产品还需要提到的一个重要信息是,ORACLE Audit Vault and Database Firewall很可能可以实现向下兼容,Oracle 11R2新炬网络某个版本打了补丁后就可以使用,具体补丁发布时间尚未公布。

       在参加完第二个讲座后,我隐约感觉Oracle Data Redaction这个功能有不错的商业前景,于是讲座结束后就兴冲冲地在公司内部的OOW微信群提出想法,于是引发了两个小故事。

       第一个故事是到底“Oracle Data Redaction”能否实现以应用程序账号为条件实现敏感信息的屏蔽。这个理念有一定颠覆性,引用一位同事的说法,这就Oracle软件新炬网络本身“踩过界”,把一些应用程序层面实现的功能实现了。由于找不到相应文档支撑,谁也说服不了谁,于是后来公司让我们咨询一位DATABASE的售前工程师,由于没有具体文档支持,后者也仅是以“听说”这种口吻给予答复。总的意思是,可实现基于应用程序账号的判断,但与应用程序实现方式有关,部分应用可能受限制。

       第二个故事为我们一位在安全领域打滚多年的销售抛出的一个具体的例子,开发与运维人员联合犯案,通过自己编写的程序篡改信息非法牟利,问我们这个新的产品如何能解决这种场景。对于这个问题,在未接触新的产品前,我们无言以对。但我从中得到的信息就是,真正实现这种安全加固需求远比我想象中复杂,要想打动客户,需要提前做很充分的测试和准备。

       我的总结如下:

       1)Oracle Database 12c的 Oracle Data Redaction安全特性具有革命性的进步,在信息安全日渐重要的今天,具有不错的商业前景。

       2) Oracle Database 12c的 Oracle Data Redaction安全特性具体信息尚未真正明朗,需要实际测试。

       3) Oracle Database 12c的 Oracle Data Redaction与应用紧密结合,预计项目实施的技术难度不大,但是耗时较长,沟通成本巨大。
页: [1]
查看完整版本: 云里雾里看Oracle12C Data Redaction