最近安全圈里出了一件大事。7月29日，美国第七大银行Capital One称客户信息遭黑客窃取，被窃取信息数量约1.06亿条，涉及信息主要为2005~2009年期间该银行的信用卡用户的各项信息。

事件一经披露，导致Capital One股价大跌，并面临法律赔偿。作为美国第五大信用卡签发方，Capital One此次信息泄露有可能成为美国历史上最大规模的银行数据泄露事件。据外媒披露，黑客可能是利用了Capital One的防火墙的错误配置，入侵到其托管在亚马逊（Amazon）的AWS云端数据库，进而实施了数据窃取。

信息防泄露一直以来就是企业安全的重中之重，商业银行作为运营关键信息系统的机构历来重视信息的防护，但是企业做安全防护是体系化建设，黑客的入侵则是单点突破，在IT技术快速迭代变化的背景下，对防护体系的不断更新、加固提出了艰巨挑战，特别是在欧盟GDPR、国内网络安全法等相继颁布的监管趋严态势下，信息泄露需要银行安全付出更多关注。从一个银行“老安全人”的视角，我也来说说此次事件中的两类风险。

一、公有云被攻击的风险

云化服务是技术趋势，是不是采购了云服务后安全责任就移交给云服务商了呢？很遗憾不是这样，云安全一般采用责任共担模式，由服务双方共同保障。安全责任主体的划分是根据提供的云服务类型来决定的。该事件中，Capital One采购了亚马逊的AWS基础数据服务，但AWS要求用户数据的安全由客户主要负责。亚马逊称，云端客户能够完全控制他们自己开发的应用程序，且没有何证据表明其基础云服务受到了损害。从已披露信息看，客户数据应该是从Capital One侧泄露出去的。这里带给我们一个启示，对于采购了公有云服务的系统，云安全的责任主体要划分清楚，不能采购了云服务就认为安全责任都归属于云服务商，哪些层面的安全由云服务商负责，哪些层面由客户自己负责，要做到心中有数。

二、数据库拖库风险

数据库数据的泄露途经一般分为外部拖库、内部泄露。此次Capital One事件当中，嫌疑人是通过互联网进行的外部拖库攻击。从这几年积累的经验来看，列举如下几条可能的攻击路径：

1、利用网络控制不严格直接访问数据库（如数据库端口对外暴露）；

2、利用应用漏洞实施拖库（例如SQL注入）；

3、利用未知漏洞入侵内网后通过跳板间接访问数据库。

如前所述，在拖库攻防博弈中，防护人员需要封堵整个环境中的所有可能漏洞，而黑客只要找准一点、从系统最薄弱的点入手，层层渗透最终获得目标权限。攻击和防护是不对称的。从本次事件的角度出发，针对以上三种攻击路径，在此各提出一些传统有效的应对措施：

1、直接拖库攻击风险应对：

通过防火墙限制外部可访问端口；

部署IPS防护设备。

2、应用漏洞拖库攻击风险应对：

开展代码安全测试、上线前安全验收测试、上线后渗透测试等工作，发现应用安全漏洞并及时整改；

在互联网边界部署IPS、应用防火墙等安全防护设备，实时监测和阻断SQL注入等拖库外部攻击行为。

3、跳板拖库攻击风险应对：

DMZ区与其它业务区域严格隔离，重要数据库的网络边界设置防火墙；

部署用户集中管理系统，通过设置密码错误次数上限、用户操作行为录像等方式实现事前和事中控制；

安全补丁、操作系统补丁定期更新，各类服务器、数据库安全配置检查定期开展；

对扫描发现的漏洞及时修补，并对漏洞修补情况进行复查；

开展渗透测试、安全评估、科技检查来发现潜在安全隐患。

此外有媒体称，该事件其实自3月就开始了，嫌疑人3月发动了第1次攻击，4月发动了第2次攻击，Capital One是在7月收到提示邮件后才察觉攻击，对风险是无监控或监控失效的状态。如果该系统部署了异常流量监测、数据库用户设置了操作行为审计、针对防护设备的报警有所关注的话，还是有可能提前发现风险并修复漏洞的，不至于对风险毫无察觉。所以在日常安全运维工作当中，提高IT运维人员的安全意识，增强安全事件处理能力显得尤为重要。安全小伙伴儿们，信息泄露防护任重道远，和我们一起来探讨行之有效的解决之路吧。