演讲主题：应用和数据库安全审计创造客户价值

演讲内容：DBAPPSecurity亚龙（安恒）总裁兼技术总监 范 渊

各位领导、各位专家大家下午好，很荣幸有这么一个机会和大家交流应用和数据库安全领域的一些想法和一些技术。今天早上很多的厂家和专家讲的领域主要是在网络层,我的主题可能会与其他专家不太一样,我今天和明天的两个演讲，主要是放在应用和数据库安全这一块,由于时间关系今天重点从管理和产品上讲一下应用和数据库安全问题，明天更侧重于应用和数据库安全的技术细节及分析，包括比如说为什么会有这么多的肉鸡？木马从何而来，真正的安全风险是怎样形成产业链的，数据库的安全攻击表现为哪些方面等等各方面的一些细节。

那么先简单介绍一下我自己, 我之前是在浙江数据局网管和计费中心(1997年~1999年)，后来我一直在美国硅谷从事网络安全这一块的工作。先是从事相关像这里我们现在用的比较多的SOC（其实当时我们从2001年开始就已经做这方面），后来的那个合规性，后面我一直把自己的题目放在应用安全和数据安全这一块，我也很荣能够在本次大会上阐述自己的一些观点。

我们公司主要是在应用安全和数据库安全这一块领域，包括主动防御、安全服务和一些主打的安全产品，我们的运营商这一块的战略合作伙伴也有很多年的数据库的研发、维护和调优经验。我们在应用和数据库的入侵和深度主动防御方面有自己的异常检测，有自己的专利。

那么下面呢我会简单地讲一下数据库安全的一些概况。今天是感恩节，我首先祝大家感恩节快乐，其实人一辈子不只是在感恩当中渡过，不过有些时候感恩更像是一种，就是月初我们的计费系统如果说不出问题，也许也是一种感恩，或者说我们的客服系统如果说运行正常，数据不被窃取也是另外一种感恩。那么在这里面我所讲的就是说在分析到相关的一些风险之后，希望我们有很多的时候，这个感恩成为一种必然，而不是成为一种求报。

其实他山之石可以攻玉，就是说我们可以看一看，借鉴国外的一些经验和教训，国内其实也发生了很多这方面的数据安全的事件。2005年的时候当时大家可能都听说了，发生了很严重的数据泄漏的事件，涉及到信用卡方面的数据，有4000多万的用户数据被窃，大家都知道美国这方面的立法和制度是相当严格的，实际上这件事之后也促进了安全方面的一些相关议事和制度。

美国所发生的这个数据安全事情远远不只这些，包括在后面实际上有很多的法规已经明确规定了。大家可能后面也知道的，像在卫生领域，你只要有任何的用户数据如果是被泄漏的话，你必须有这个义务在第一时间内通知你的这个客户，那实际上从某种意义上来说变成是一种强制性的需求，可以想像，如果有一天我们在运营商这一块要实施相应的条款的话，我们会带来多少的压力？

那么国内呢？这方面的事件其实也是相当地多，比如：2006年北京移动冲值卡被窃取事件，另外呢在上海某公司工程师利用编写的程序，也是盗取移动冲值卡。像这一块事件发生的时候，实际上都根本没有在第一时间内被反馈或者说后续也没有一个真正的审计的手段。而很多次都是属于人家已经在市场卖这些卡，可能一些偶然的过失才会被发现这样的一些案件。数据库安全它所带来的损失可以说是非常巨大的，这一点大家可能都有一些共同的理解，包括客户的流失、机密的泄密、企业品牌的影响、法律的问题等等。

一个典型的IT与信息系统构成大家可以看一下，无论是从外网还是专网一块，数据库服务器或者说核心业务的应用服务器，都是处于整个系统的最核心部分。当然我毫不否认前面几位专家讲到的、通过网络来保护，就是说从各个层面来保护系统安全的必要性，但是它不可否认的一点，就是说所有的最重要的这些资产，或者说最核心的这些资产，尤其是对我们运营商来说，它是在这个数据库里面，包括客户信息、后面讲到的一些业务方面的信息。
数据库是企业数据信息的一个最终的载体，那么也是企业业务系统的一个核心，数据库所面临的风险其实是多方面的，今天其实早上有多位专家讲到，就是涉及到这样的管理合规性这方面，我觉得这个讲得是非常正确。实际上我当初也是参与了数据97的规范的制订，作为这个技术组的这个成员，当时一直在想一个问题，就是说这个管理流程和技术这一块的一些关系，那实际上最终来说可以有这么一些理解，我觉得可以探讨一下，就是说任何一个，像我们这样大的运营商或者企业，它如果说没有一套完善的规范或者说制度的约束，管理的约束，那任何的这个产品的堆叠，可以说都是无效的，但是反过来说，好的产品和管理，或者说策略的管理，它实际上从某种意义上来说支撑和支持了这些规范的实施，因为你要是所有的规范如果都限于这个纸面的话，大家都知道，也无法真正地、很好地来实施这些规范。

那么数据库所面临的这些风险，大的来说是分为这几个方面，一方面是管理方面，就是说内部人员的这个误操作，大家都知道对吧？这实际上也是很普遍的，就是说在数据库的一些操作过程当中，往往有些时候甚至是不可恢复，或者是也没有意识到一开始；还有就是违规的操作，比如说对于一些违规和越权的一些操作，对于一些帐单的修改、用户服务信息的修改（用户从交费用户变成公免的用户），这些对吧？或者是业务上的一些开通的后门，这些方面都是属于我们现在运营商所面临的一些问题。

另一方面就是第三方维护人员，因为我们现在有很多的维护团队，包括一些应用程序的支撑、一些维护管理的支撑，在这些方面他们实际上都是可以非常容易的，完全的、具有这个操作应用系统或者是数据库的权限。还有就是最高权限用户，就是通常据说的DBA，实际上大家都知道，普通情况下他做任何的事情，是缺乏相应的审计和追溯的；另外就是多人共用一个帐号，这个也是一个非常典型和普遍的问题，也是导致事后无法审计的一个缺点，这个我想也是今天早上周经理提到的，就是说像个人的这个认证，4A包括证书这一块，事实上也是跟这一块相关的。另外还有象员工离职的流程、离职后信息的泄漏等等。

那么技术上的风险那就更不用提了，因为数据库来说技术上的风险分为几大块，一个就是从外部应用程序所带来的风险，大家都知道现在由于项目的压力，应用程序的启动，往往都不会考虑或者基本不会考虑安全这方面的问题，而现在根据年初的ISA大会，已经公认最大的安全就是WEB安全，最大的安全问题就是WEB应用的漏洞，实际上就是可以通过应用程序的漏洞操控你的数据库，包括窃取你的机密信息、实施篡改或者相应的动作。另外一方面就是传统的、通过网络层的一些攻击或者说操作系统漏洞的攻击。再者就是对数据库直接的攻击，数据库这方面的漏洞实际上是非常地多的，我在下一个，就会讲，那么在明天的话也会有更多的一些细节上面的分析，比如说像数据库的木马、像数据库本身自身的这个权限和注入等等。另外还涉及应用提供商的后门。

审计的风险是在于日志的缺失和不完整，难以追溯和鉴定。另外就是说审计的一些绕过。那么大家都知道实际上对于数据库这一层上面的操作，比如说谁做了什么操作、做了哪些动作、该不该做？这些的审计我们目前来说，往往是非常缺乏的。简单地来说就是复杂的业务应用加这个异构的网络环境，加高度集中的信息共享，使得这个运营商核心数据库面临更大的安全挑战。

无独有偶，刚刚几个礼拜以前，有个朋友告诉我一个信息，某个省移动中心的客服系统遭到攻击以后，所有的客户数据和一些敏感数据被导出成文件并被下载下来，事后才知道是之前的业务提供商的工程师，利用一些漏洞，把这些关键、敏感的数据库下载了下来，这个事情还一直在追查当中。很多的时候，这些安全事件就在我们的身边。但是它有一个很大的特点就是它从某种意义上来说，它的发生是悄无声息的，为什么这么说呢？假如说我进行一次CC攻击，其实你很容易地觉察到，这个我可以称之为一种外伤，就是说对我进行DDOS攻击，我很容易地意识到，但是当发生这一类的信息篡改的时候，往往是很不容易觉察，而且你事后也缺乏一种真正的审计和追溯的一种手段，因为它都是通过正常的一些应用，或者正常的一些操作在进行，从某种意义上来说，它也可以说不是一种攻击，或者说是处于一种灰色的地带，那么这个就给我们的数据库带来更大的挑战性。

十个最普遍的数据库安全的威胁总结一下就是包括这几方面，一是越权的使用，一个是合法权限的滥用（我有这个权限我是可以改）。第三个就是权限的盗用，就是说通过别人的这个帐户或者说共用的帐户。第四个就是数据库本身平台的漏洞，第五个通过应用程序的SQL注入，第六个缺乏详尽的审计和追溯手段，第七个就是拒绝服务，它其实也存在着拒绝服务。第八个就是利用数据库通信协议的漏洞，还有弱监权机制。还有一个就是备份数据的保护这一块。

由于时间的关系我不可能对每一个都做详尽的讲解，数据库它有很多的共同点，像我们之前做就是说每一个数据库实际上都有自己相关的这种结合，专门的一个团队，我们的主要的优势和很多的这个经验也是在这一块，它也是很多运营商占据绝对的一个优势。那么数据库本身有很多的共同点，包括它自身用于管理数据的数据、用户名、口令、它自身的一些审计功能、自身的权限划分、口令管理的弱点，应用端口、本身存在的一些漏洞，还有就是有一点大家可能被忽视的就是，我们往往采用这个典型的安装，往往是这个带来安全问题的第一步，也是这个最关键的一步，为什么这么说呢？就是说它实际上这个典型安装给你带来很多一大堆你不需要使用的功能，甚至也带来包括在用户口令这一块配置的很多的风险。那么在这个时候你可能一辈子也用不到这些存储过程，或者说一辈子也用不到这些功能，但是它确确实实地就在你的这个数据库当中。所以说安全问题实际上从安装的第一步就已经产生了，一直到我们后面的业务系统，到我们的使用和审计，这个往往是我们容易被忽视的一点。

其实它还有一些很强大的文件的读写、还有像网络功能这样的一些函数和这个包，这些如果说被非法利用的话，也会带来非常大的一些隐患。

另外一点就是攻击悄无声息，就是大家可以看到从应用上面来讲，这是我比较喜欢使用的一个PPT，就是说传统意义上的安全和我们这一块有什么关系呢？从某种意义上来说，传统意义上的安全或者说他那些防护设备对这一块几乎没有作用，为什么这么说呢？防火墙他对80端口、443端口它是全开放的对吧？哪怕即使是现在我们有一些单位为了安全，比如说在应用程序和数据库之间，我进行了这个防护。再进行一次数据库防护，但是实际上这一块也是对这个1521端口都必须要全开放，所以这里面起不到任何的保护的作用。而对于WEB服务器，它本身就是说，它只是非常地机械地从你调用这个程序，参数传进去，他去调用这个数据库，这个时候发生攻击的话，很多的敏感数据，包括这个数据字典点和攻击都会在这个时候发生。

数据库本身也带有很多的脆弱性，监听本身就有一个很大的应用程序，我们当时接触很多的客户或者是一些朋友，为了系统的稳定性（比如：计费系统）我们往往不可能去跟着数据库软件版本的升级而升级，比如说现在数据库最新的是11g，10g应该说相对来说比较成熟了，但是现在有很多的业务系统，其实还用的是9i，那9i的话大家都知道，监听程序就有一些特殊的漏洞，它可以被利用。（当然10g也是有它自身一些新的弱点的产生。）在9I典型安装的情况下，利用监听程序的漏洞，可以在几分钟之内你就可以很容易地侵占这个数据库，你不需要事先知道他的用户名、口令。大家可能以前觉得，我这个数据库，我把用户名、口令给搞好了对吧？而且我一直在内网当中，像我这个DCN网当中或者说专网当中，我相对来讲应该是很安全的，但是实际上在这一块可以很容易地，就是说在这个网内进行，只要是在这个网络层（TCP/IP这一层）是通的，就可以很容易地对它进行攻击。除此之外就是说它本身还有很多的函数或者说存储过程，它自身存在着SQL注入，就是说并不是所有的SQL注入都发生在应用程序这一端。那么对于自身的这个SQL注入，你可以利用他现有的权限进行相应的提权。比如说你原来是一个普通的用户，但是大家都知道，真正执行存储过程或者函数的是最高的权限，如果说你利用了这个SQL注入提权的话，就会使得自己可以利用这个执行，把自己给提升，也就是说你拥有了DBA的权限，这个也是以前大家很容易被忽略的。

另外就是数据库的木马，数据库其实也有木马，以前我们只听说过操作系统有木马对吧？其实数据库木马的概念和操作系统木马是很相似的。数据库其实是一个很庞大的系统，也有用户、有用户管理，有各种各样的管理。举个例子来说，对于用户管理而言，如果是一个黑客，对数据库进行侵占以后建立了自己用户，这个后门的用户，黑客当然不希望DBA来查看用户信息的时候会被发现，这个时候他就会通过数据库木马或者说通过试图更改来进行相应的隐藏，包括对自己的进程这一块的隐藏，这样的话就是使得它达到一些恶意的目的。

刚才已经讲了好几次就是应用层的漏洞。那么从用户需求的概述来讲，它面临的安全问题，实际上是内部人员的，刚才讲误操作、恶意操作、权限滥用、外部攻击以及就是传统的防火墙IDS它无法解决的这一系列问题，就是说IDS它是作为网络层，那么它没有真正地从应用层或者说数据库层这个领域来防护，更加不用说提供细粒度的审计来达到安全需求。

而人工的操作审计呢，这个大家都知道几乎是不可能的对吧？更不用说在目前的情况下，实际上连原始的审计数据都没有。

作为企业来讲，数据库的这个私有性和复杂性，它也是需要有专门的一个综合的解决方案来完成从主动防御到被动防御、再到事后的智能追踪和审计，实现应用层的异常监控。

合规性的要求，实际上很多软件都对合规性有专门的要求，电信在今年专门发布了相应的安全规范，其中专门有一个章节就是提到了对数据库安全的审计，我们可以看到包括移动等更多的运营商的意识也是越来越高，或者是达到一个比较新的高度。实际上万变不离其宗，当初我第一次读ISO的时候，17996感觉好像挺枯燥，我不知道大家是不是有这样的一个感觉，那当然是好几年前了，但是实际上它真正是聚集了很多的一些经验，如果说你从应用层或者从数据库的角度刚才讲了那么多，从权限、从第三方的服务角度，你再回头去看看ISO的这个分量最重的两个章节，就是第十章和第十一章，一个是运行的管理，尤其是像第十章的第一节和最后一节，还有第十一章可能就会有一些新的理解。实际上包括像SOX它所基于的，实际上也有很大一块也是参照或者基于了ISO最基本的标准，它无非是从这个最佳的安全经验和体验管理这方面来约束了这一块，或者是强调了这一块。

从专业安全的产品来说，它必须满足几个要求，我觉得一个就是对现有的业务和系统没有影响，另外一个呢要实施分布的保护和可拓展、可集中的管理，另外能够适应主流数据库完全的解决方案，就是攻和防相结合的解决方案，并且具有相应的追踪、追溯的功能和一些智能化的功能，比如说刚才讲了，从应用程序过来的这些，你是否能够自己自动地做一些学习和识别。因为你这样大的一个流量，你说让人工去做识别，或者说做纯粹的一种被动的审计，那几乎是不可能的。就是说这样的话对这个维护的简单性就是提出了很高的要求。

传统的审计方案有哪些不足呢？就是说之前我在包括在美国也有这样的一些产品，它依靠数据库本身的LOG日志，那本身的LOG日志打开的话大家都知道，实际上作为DBA而言或者说作为很多的专业而言都是不可接受的，因为我们现在本身的系统性能压力都比较大，那在这种情况下，如果你打开它自身的审计的话，实际上这一块的压力会变得非常大。这几乎我谈下来，很多的DBA或者客户，或者是专业安全领域朋友都是不可能去接受，对吧？而且这里面还存在一个严重的问题，就是它没有满足真正审计里面的职责的区分。作为DBA来讲，我可以去关掉数据库的审计对吧？我关掉他的审计，我要是做了这个事情的话，也就变成不可追溯了，这样的话没有真正地提供一个满足合规性的要求的审计方案。

第二个是利用一些认证系统，认证系统大家都知道，实际上它并没有真正地涉及到对数据库的访问和操作的这一块，所以说认证系统它并没有一个真正的审计解决办法。

还有一些人利用一些系统，实际上它是缺乏一个灵活的一个策略定义的这样的概念。刚才华为的总工我觉得讲的，包括之前的好几位专家讲得很好的一点，就是说一个是被动防御和主动防御，还有一个就是从产品的堆叠到策略性的管理，实际上我们运营商之内的很多的业务流程我们大家都知道实际上是非常复杂的，不是说好像我一架上去东西，插上去，为了防御就是防御，没有这么简单的事情，只要我们都部署过，或者说是简单地了解过任何的一个这一类的方案的话，都应该说对这个有很深的一个理解。实际上不同的时间段我们可能对的安全或者审计的需求都是不一样的，不同的用户或者说不同的网段，不同的业务系统，那么在这个时候它就必须要做到应用层或者数据库层的灵活的策略定制。比如说某某用户，他可能只能读而不能写，有的甚至他可能只能读某几个表，而不是说所有的这个数据表。那么另外呢相关的一些关联操作，还有监控本地的操作，这些都是传统的系统它所缺乏的。那么另外它也无法做到在需要进行防御的时候进行防御。

这个时候就是说新的一些安全审计的手段，必须有它这一块领域的一个切实的需求，刚才讲了防火墙只能检测网络层这一块，那么IPS它只能是对网络层这一块的特征检测，实际上对这个细粒度的审计，现在还是很少做到的。
今天讲的是数据库防御和审计的方案，它实际上我们叫做八层的方案，实际上在第七层应用层和八层的业务层这一块的这样的防御和审计系统。
下面呢我花一点点时间把这一块的一些概述给大家讲一下，这一块大家如果是有更深的需要的话，可以拿一些资料，也有相关的一些白皮书。

这是面向运营商数据库的全方位的保护和审计的一个方案，它有几个特点，一个是实现了主动防御，或者说就是攻防的结合，它能够自己有模块，对这个数据库进行相应的风险评估，那这个的意义在哪里呢？就是真正地做到有的放矢，数据库它是什么版本？它有哪些模块？它的风险、脆弱性在哪里？这些本身就是你作为一个审计系统和防御系统它需要了解的。但是往往我们现在很多的解决方案这两块都是脱钩的。二上实现了全方位的访问和控制，就是从管理层面、网络层面、数据库层面。三是多种形式的实时防护的这些告警，比如短信、电子邮件、大家知道的管理手段阻断。四是细粒度的审计分析，就是说从数据库具体的动作、表、视图、具体的字段、返回值，甚至是从用户各个方面的细粒度的审计。

做到了数据库运行状况的真正可视化，但没有任何影响它的性能的情况下。也就是说不需要影响它任何现有系统的部署和性能的情况下，提供了数据库运行的可视化和数据库操作的可跟踪、可鉴定和可审计。

这张图可以说比较概要地反映了刚才讲的这些理念，大家可以看到，不管是从你的系统来，还是说从你的数据库客户端来，或者是DBA直接的维护和管理。所有这些的操作，都统一地被这个防御系统，就是这个盒子所能够进行相应的收集、审计、归纳和分析。它有自己的动态建模，它也有自己的实时监控和防御，同时还包括了特征引擎和异常引擎。为什么叫异常引擎呢？大家有一点可以认识到，其实作为一个应用系统，大概运行相对成熟的话，不管它是一个客服系统还是说内部的计费系统，从应用角度来讲它是处于一个相对稳定的状态，在这个时候就是说作为我们的系统，它对这一块进行学习和分析跟踪是很有意义的，因为这一块往往数据量非常大，但是呢它的相对成熟性、稳定性较高，这个时候如果说发生应用层这些方面的攻击或者说变异，或者说自身的一些误操作的话，往往我们能够很容易地通过异常引擎来分析或者检测到。传统的、纯数据库的审计产品，这些审计产品我把它归纳为是一个非常被动地、纯粹的数据收集，为什么这么说呢？我就是从网络上给你同一种所有的数据，都给你抓下来，然后往数据库一丢，然后你要查询行啊，你要查询什么数据，你来查。你要做什么报表，就是你自己去定一个报告或者说用我已有的一些报表，这种系统实际上真正地在这种海量数据里面，它实际上从某种意义上来说它所起到的一个作用到最后你会发现就是非常有限的，为什么这么说呢？一个系统如果说不能融入它事先的，像一些安全的知识，它的应用层的一些理解，对于整个流程的一些理解和多方位的安全和防护的话，其实一个纯粹的被动的审计和查询系统，就是说只能说是很小一部分满足了我们现在的这一块的一些需求。这也是我比较想强调的一点，也就是说有的时候我们可能脑子里到处都是在蹦一些各种各样的安全产品，或者是所谓的一些审计产品，但是就是说真正能够从一些本质上来做一些区分或者是理解，那抛开我们自己的方案不讲，我觉得对于运营商的每一个人实际上都是很有意义的，实际上我刚才也是讲在运营商，在八、九年前，那当时作为甲方，我也是看很多的这个安全产品，或者是一些方案。

刚才讲了风险自动化评估这一块，我们其实有一个独立的模块，也是我们相关的一款工具，那么它可以对整个，可以说对数据库本身的3A、数据库木马、数据库本身的漏洞、补丁、版本进行相应的自动化的评估和分析，这样的话就是在之后的防御和审计当中，它就可以做到有的放矢，这实际上也是之前讲到的有一部分，就是一个主动防御的理念。

那么这样做还有一个很好的意义就在哪里呢？它减少了误告警，实际上也就是真正突出了你所应该关心的这一个告警，而不是说我给你一大堆告警，最后你发现呢，比如说我有一个包的攻击，你最后发现其实我这个数据库什么都没有装对吧？或者说我是针对一个9I的告警，但是其实你用的数据库是10g，所以在这样的情况下，你如果说整天，因为我之前在2001年做一个综合安全管理，是一家非常大的公司啊，那如果你需要对这样一个海量的告警数据来进行分析的话，而且缺乏这个等级性的划分的话，真正的要想去做这一块的管理几乎是不可能的。
它的核心用途呢大家通过这个部署就可以看到，就是说它可以旁路也可以直连的方式，那一般来说现在很多的客户都还喜欢旁路的方式，因为不影响任何的部署，也不影响性能对吧？

从外防这一块，就是说外部的恶意攻击，包括针对数据库漏洞的攻击、应用程序漏洞的攻击、外部帐户的盗用，外部的黑帐户等等，通过这个简单的示意图地大家可以看到；对误操作，也就是内控这一块，比如说误操作、越权操作、恶意操作、权限划分，或者各类的审计。其实权限这一块我也想讲一下，之前我们为了做部署应用的方便，很多时候我们应用系统的用户都是赋于DBA的权限，用DBA权限这样做当然是最方便，因为我肯定保证他在这方面不会出问题，我不会来找我，但是往往这一块就带来很多的安全隐患，所以说这一块的，所有的这些东西，都是应该要通过刚才讲的主动防御和监控和审计来发现这一类的问题。作为应用程序这个用户而言，绝对不可能需要拥有DBA的权限，我想这一点大家一定要记在心上。

另外一块就是它的防御审计系统的功能，从某种意义上来说其实也是4W，就是某个用户访问某个应用或者操作某个数据库时候，它如果说有相应的，匹配相应的操作或者异常检测能够检测到，那么我们可以采取灵活的一个安全策略。这里面就是说可以有多个方面的这样的一些策略的关系和事后的跟踪和追溯、监督的手段。

不仅仅是数据库本身的协议，对于FTP的操作，实际上也要做相应的审计，为什么说是很有必要的呢？大家都知道很多时候我们需要FTP相应的数据上去，所以作为一个综合的解决方案，这一块的审计是必然的。那另外呢就是，其实刚刚上一次，我们在做安全服务的时候，有一个非常敏感的用户，他的门户网站突然发现，WEB根目录的底下有一个告警，说你这个WEB有漏洞，希望你怎么样，他当时很慌张，但是他也搞不清楚这个告警是通过WEB攻击进来的还是通过FTP的漏洞给传进来的呢？就是说缺乏这种审计手段，那么明天的话我也会仔细地分析一下WEB应用的风险和一些技术的细节，像SOC注入等等。

但是这里面所讲的就是说，如果你不能对这一块进行追踪和审计，就像WEB应用这一块的审计，或者是通过FTP这一块行为的审计的话，在这个事后你就会变得更加困难，就是说事后的一些追溯。

这次由于时间关系我主要讲的是数据库的防御和审计，那实际上我们也有一个专门针对WEB应用的防御和审计的一款系统，跟这个数据库的防御和审计正好是配对，也是作为一个比较完整的解决方案。大家有兴趣的话可以到时候从网站上或者外面的演示可以看到。

这个方案从各个方面，比如说像谁做什么操作，什么时间、什么操作、多少操作、结果是什么？是否符合这个规范，如何进行数据库层的AC而操控，刚才讲了什么用户，我能够操纵那些表，我可以读但是不能删除，这样的一些策略可以说以往我们所有的策略管理所不能做到的对吧？那么另外一个就是谁该对这个恶意操作负责，怎么追溯、调查和取证，那这些都是它所具备的。

技术实现这一块，因为时间关系稍微快一点给大家过一下。有兴趣的话可以具体地交流。一个是高速环境下的限速捕获技术，一个是专利级双引擎技术，智能化的安全模型和灵活的策略配置。首先在不影响现有部署的情况下，它实际上是从网络上可以实现一个高速的捕获和深度的分析，所以为什么我们讲深度的防御和审计系统。还有就是这一块的硬件引擎和优化能力。第二个是它有基于双引擎的技术，就是说我们之前大家都知道，很多采用的是一种特征匹配，但是往往在这个时候是不够的，有些时候某一个动作你很难真正地去定义它是一个攻击还是不是一个攻击，一旦到了数据库应用的层面，我同样一个动作，对于某一个用户可能是攻击，对于另外一个用户很可能是正常的行为，这个时候你必须要有相应的异常检测模块来进行相应的异常检测，包括你后续灵活的应用层的策略的定制。

那么可以分为四大块，协议分析、模式匹配、异常检测和关联分析。大家可以看到就是说这是一个，相对来说比较形象的一个过程就是说，首先过来你可以基于你应用层的访问控制对吧？谁，他是不是拥有这样的一些权限，是否拥有访问这个表的权限，或是否拥有修改这个表的权限，他是否在导整个一个表的数据，或者在删除整个一个表的数据，这些都可以通过相应的访问控制，然后你有相应的登记安全的知识，有自己的相应的特征引擎，有针对这个数据库本身协议的一些漏洞，还有一些是很明显的恶意的操作，那么这样的话我们必须要对此进行相关的一些监控，另外一个就是异常的引擎，刚才已经讲过了，就是一个安全模型。那么简单来说四大块，协议分析、模式匹配、异常检测和关联分析。关联分析它也是可以，根据会话过程或者你之前的行为判断来进行行为分析。那么其中的这个策略配置，他就可以讲到，有一些是传统的比如说你是网络层的，IP哪些网段，还有一些就是应用层，或者说哪些用户他能够做什么，根据你的这个规章管理的制度来进行相应的定义，他可以定一个比如说你是什么样的程序你能够连，你什么样的程序你不能连，那你的主机是什么？你的数据库对象是什么？你的应用的用户名是什么？你的数据库动作是什么？那么相关的所有的响应动作，比如说你是什么样的告警、或者什么样的阻断。另外就是结合安全经验，预设置这个安全策略的一些实例。这个时候因为你是相对属于一个静态的时间。那么还有一个就是所有的FTP这些例子，其实也相当多了。那么还有就是根据我们的审计的要求或者是我们自身的一些，就是最少的这个特权对吧？和这个必须权限这一块，还有就是说禁止DBA来访问这个业务表，因为作为DBA而言，他的作用就是来进行相关的数据库的维护和相应的动作，他不应该去访问业务表或者是操作业务表，这本身也是职责划分或者是权限划分的这一块所必须要求的一块道理。那么另外一个就是，对敏感表做特殊的保护，包括对有些表内容的，就是我们讲的CIA这一块做相应的保护。

产品的部署可以说快一点，考虑到我们目前的复杂性和异构的环境，它可以支持多种的部署方式。旁路方式和直连方式，并且支持多种流量带宽，千兆以及千兆以上的，另外如果有多个应用分布在不同的地方的话，它支持的这种分布式的部署，也就是说它可以有多个实验室，然后它可以统一地发生一个服务，这样的话实现比较灵活的一些控制管理。

这里面的体系架构就是我刚才讲的一个传感器和服务器，它既可以在一个盒子内，它也可以在分布式的部署，这样的话对于我们这个管理上和部署上带来比较灵活的特点。

从安全管理的一个生命周期来讲，就是大家很熟悉的，这一块就是正好形成了一个闭环，我不知道大家注意到没有，就是前面讲的从主动防御、发现这个弱点，到监控到这事后的审计和分析，正好形成了这样的一个闭环。
这里就是我讲的自动化风险评估的一个流程，对于你的弱口令，对于你的补丁，对于你有威胁的配置或者弱配置，潜在的弱点统一地进行评估，而且也有相应的报表，这个模块也有相对独立的模块，大家可以有兴趣可以上我们网站看一下。

动态创建安全模型，刚才我已经有一些解释了，从应用或者从某个应用用户而言，这个我就不再多讲。那么这里面这个部署图就是说，从刚才可以说也作为一个总结性的部署吧，就是说4W，它对各个，从你的这个终端而来的、从应用程序而来的、从FTP而来的这样一个综合性的一个监控审计和防御，就是深度应用和数据库层的审计和防御功能，那么达到应用层级的访问控制，特征检测和异常检测、管理分析。那么这是他的一些相应的报表和一些监控。

对于存储过程的还原，对于指定用户、指定时间段内的跟踪、分析、回放，远程访问操作审计，具体的这些功能这里不再多讲了。实际上无论是对于SOX所基于的、大家应该是看得比较多的一个示意图，对于应用的数据库层实际上都有相关的这个规定，我之前也讲了，包括ISO。这些事件追溯和回访的一些例子，来达到一个真正的深度的应用数据库层的这样一个解决方案。

对于历史数据的分析和风险趋势的管理，给我们的分析和决策带来很大的帮助。这个是很多的动作、数据这样的一些，在复杂的情况是你自身的一些分析，实际上通过一定的数据挖掘，你也有可能发现一些，就是说之前可能忽略的一些情况，或者说在管理上的一些漏洞。

那这里面是它相关的一些报表、相关的一些功能。其实有基于SOX，也有相应的这个数据库的或者是基于WEB的应用的。审计的，动作审计的、访问对象的和他的一些详细的数据库的操作语句。

大家可能会问，你的价值体现究竟体现在哪里？实际上我始终有一个概念，就是说你不是为了安全而安全，尤其是在应用和数据库层面，它的价值体现就显得更为明显，为什么这么说呢？有一些是大家都很容易理解的对吧，我如果说挽回了一个你事后可能会瘫痪或者糟攻击，就像刚才讲的很多的数据遭窃取这样的一些隐患的话，本身就是很大的安全，很大的价值的体现，但实际上还远远不止这些，比如说现在有很多时候，都是包括一些帐单修改或者是一些系统用户到这个普通用户的修改，实际上这些本身就是我们企业直接经济损失的部分，避免了这样的操作也是价值的体现。另外就是外部的审计压力和要求。本身大家知道，就是满足SOX审计的需求是非常长期的一个过程。

还有像客服系统，本身的这个市场数据的分析，也给价值的创造也带来了一些契机，这一块为什么这么说呢？我简单地讲一下，实际上我刚才讲我们也专门针对客服系统，比如说像WEB应用系统的保护和审计，那这一块的话实际上，这些客服系统的数据本身是非常宝贵的。因为它本身就是说，对关键字的搜索，客户他所真正关心的业务，这样的话实际上从这个角度来说，他可以为这个市场分析和决策提供很多有价值的数据。

那么我今天所要讲的主要就是这么多，谢谢大家。