运营商数据库安全解决方案

行业需求与挑战

某直辖市移动公司,目前传统安全措施无法有效满足电信系统客户4700万用户、交易、卡管信息的保密需求。并且此运营商围绕着网络防护、主机防护和应用防护已经进行了一系列安全建设,具备相对安全的数据应用环境,但由于技术局限和有效的安全产品匮乏等原因,数据库自身安全的建设一直未能得到有效开展,当前多起数据泄露事件均与数据库安全措施缺乏有关。
当前,在CRM系统中至少存在以下重要数据库安全威胁,能够直接导致客户隐私信息泄密的发生:

1) 系统维护人员权限过高

负责CRM数据库的维护管理,直接掌握数据库DBA用户的口令;

这些人员被他人利用,完全可以随时登陆数据库,任意进行客户信息的获取。

2) 第三方人员直接接触用户敏感数据

负责业务系统的开发及实施,掌握业务系统中后台数据库用户的口令;

这些人员自身可以通过该用户,直接访问数据库,获得所有用户信息。

3) 其他内部工作人员通过网络获得用户数据

其他内部的工作人员,由于工作便利,可能通过内部网络,访问到数据库服务器。一旦进入数据库所在主机,则可以拷贝、盗取数据库文件,通过解析工具或异地还原即可获得所有用户信息资料。

方案概述

综合分析CRM系统中的数据库安全威胁,本方案以“保护客户隐私信息”为最终目标,以“最小的代价换取尽量大的安全提升”的原则,定义出该系统的核心敏感数据,并进行有效的安全访问控制。


基于DBCoffer的CRM系统数据防护部署图

在本方案中,通过DBCoffer将CRM系统中的客户姓名、电话、证件号码、地址等核心信息定义为敏感信息,将这些信息加密存储在数据库中;同时通过DBCoffer的密文权限控制体系,限制DBA、服务外包人员、第三方开发人员对敏感数据的访问权限,使其只能维护数据而无法访问敏感数据,远离了泄密和被篡改的危险;仅将敏感数据的访问能力开放给CRM系统应用,同时对这些敏感数据的访问,开启审计进行记录。

至此我们形成一套完备的CRM系统在存储层、传输层和应用层的全方位客户隐私信息保密解决方案:

A、敏感数据加密存储

对系统中最核心的客户姓名、电话、证件号码等信息进行存储加密,保证备份、存储设备丢失或数据文件被盗也不会引起关键客户个人隐私信息泄漏。

B、敏感数据访问权限控制与审计

通过独立于Oracle数据库之外的密文权限控制体系,使与业务本身无关的DBA、外包人员、维护人员不能访问明文的敏感信息,也无从引起企业敏感信息的泄密。同时开启安全审计功能,对敏感信息的访问进行记录,便于对异常访问行为进行事后追踪分析。

C、应用层防护增强

将数据库维护用户与应用系统访问数据库用户分离,并将CRM系统访问数据库敏感信息的用户与业务系统进行绑定,避免使用该用户绕过业务系统的个人信息访问行为,从而实现防止合法用户违规访问的防护目标。

方案价值

  • 安全防护客户隐私信息,维护运营商高端行业形象
    CRM系统中存储着大量客户隐私资料,如客户的姓名、电话、证件号码等,都是CRM系统中重要敏感数据、核心“数字财产”。网络防护、主机防护等仅仅是完 成了边界安全的目标,而DBCoffer通过存储层、数据访问层以及应用层的数据防护完成了客户隐私保密任务的“关键的最后一公里”,保障了客户隐私信息 的全程使用安全,可以有效避免客户信息泄密的风险,提升客户对电信运营商的信赖。
  • 维护个人隐私权益,减少对社会秩序的影响
    客户隐私信息的泄露,将不可避免地会对个人隐私权造成损害。无论是信息泄露之后用于商业目的“骚扰性”产品推广,还是被人恶意用来进行违法活动,都将侵害客户的权益,使造成客户人群的心理恐慌甚至影响正常的社会秩序。
  • 满足移动行业相关安全法律法规
    电信行业的相关法规,以及我国有关法律中,都已明确要求电信、金融等公共服务企业需严格保护个人隐私信息。
    使用DBCoffer解决方案对客户信息的安全防护,符合电信领域数据加密相关安全管理规范;符合国家宪法第38条和40条,对通讯领域中的隐私信息保密 要求;满足刑法第252条规定,条款涉及到手机邮件、短信、彩信等业务;满足《民法通则》第106条规定;满足《全国人大常委会关于维护互联网安全的决 定》。

方案优势

  • 从根源上彻底防止客户信息泄密
    从数据库级别进行防控,从根源上彻底控制客户隐私信息数据的泄露。
  • 变事后追查为主动防御
    通过加密技术和权限控制增强技术,将客户信息的数据从存储层进行保护,从数据库访问层进行有效的权限控制,使隐私身份信息的保护真正提升到主动防御的水平。
  • 变相互制约为权责分明
    通过三权分立,和独立于数据库自身权限体系之外的密文权限控制体系,使DSA(安全管理员)和DBA的权责更加分明。
  • 应用改造接近零代价
    对于现有应用系统的SQL语句、开发接口,都无需改造,原有Oracle核心特性均可继续使用。