企业考虑云计算的关注点之一就是性能。实现应用程序在云中的高速交付是一个涉及多方面因素的挑战性命题，其中包括一个整体的接入方法和一个对应用程序“请求-响应”路径的端到端查看。
性能问题包括：应用程序与数据相对于最终用户的地理位置，云中、云内外以及计算机层和数据存储多层次之间的I/O访问速度。当今，诸如CloudSleuth和CloudHarmony之类的众多服务研究报告试图通过从不同地理位置和采用不同应用程序的方法来度量和评估云计算供应商所提供服务的性能。
云服务技术堆栈
一直以来，一些云计算供应商都致力于提供特定软件堆栈的服务。通常，这就意味着他们从基础设施即服务（IaaS）转变至平台即服务（PaaS）。不同堆栈特定云可与其他的大多数流行软件堆栈相配合。
其典型代表包括：Heroku和Engine Yard的Ruby；VMforce和Google应用程序引擎（GAE）的Java/Spring（其中GAE还支持Python）；PHP Fog的PHP以及微软公司Windows Azure的NET。
如果你的应用程序使用以上堆栈之一进行构建，你可能需要考虑这些云计算平台。他们能够帮助你处理低层次基础设施的安装和配置工作，从而节省在时间和费用方面的巨大支出。另一方面，他们往往会要求开发商在进行架构和编写应用程序时遵循某些推荐的要求，以便于创建高等级的供应商级同步。
云服务服务级别协议
有些云供应商做出了提供更高等级服务的承诺，以示与其他行业竞争对手的不同。比如Rackspace提供更高等级云服务SLA，从而展开与云计算业内的巨头Amazon公司的竞争。
请注意，SLA通常只是当服务发生故障时结果的一个指示，而不是实际服务的可靠性。其典型代表是GoGrid 10000%确保的SLA。换而言之，GoGrid做出了100%正常运行时间的承诺。如果它无法满足这一级别的可靠性，它将赔偿用户100倍停机时所需支付的费用。
虽然SLA是评估所有供应商承诺等级的一个有效指标，但了解特定云供应商的实际正常运行时间是一个更为棘手的难题。大多数供应商都提供了一个用于表明服务正常运行的状态页面，但是这些页面显示的数据通常只是数天前甚至更早时候的。为了获得实际具有可靠性和可用性的长期数据，用户最好依赖于客户反馈以及诸如CloudSleuth和CLoudHarmony的比较服务。
云服务API：同步、社区以及生态系统
选择合适云供应商的另外一个关键因素在于开放应用程序编程接口（API），它为访问基础设施和执行 *** 作（例如配置服务器或解除服务器配置）提供外部调用方法。从很多方面来说，API都是重要的。
首先，一个API可得到多个供应商同时支持，同时供应商也为用户提供了更大的功能扩展自由度。因为当从一个供应商转向另一个供应商，或同时与多个供应商合作时，基本上不用对应用程序做重大修改，所以显得更为容易。
其次，API得到了社区开发人员的广泛支持，供应商可基于它构建一个具有配套服务和功能的完整生态系统。由Amazon web服务与应用（AWS）和Vmware云计算产品提供的API周围已形成庞大的生态系统，其中包括管理工具（如enStratus）、监控和管理工具（如Cloudkickh和RightScale）以及形成其完整云服务的其他服务。
Vmware本身不提供云服务，但是不同的供应商使用Vmware的堆栈和API，特别是vCloud。例如Terremark和Savvis。
Amazon公司和WMware公司以及Windows Azure都允许用户使用自己的堆栈和API实施内部云，从而使用户能够很容易地在混合云上管理和运行应用程序。所谓混合云是指由供应商托管，且在公司内部数据中心中运行的云。以Amazon公司为例，使用AWS启动通过Eucalyptus的API为私有云提供软件堆栈。
业内的一个最新发展是Rackspace公司与美国航天局（NASA）合作，两者协同众多厂商和云供应商在其一个称为OpenStack的项目中对其软件堆栈公开了源代码。它最有可能被视为行业标准，因此此举将有助于创建一个有望替代Amazon和Vmware生态系统的实际可行标准。
云服务安全性和法规遵从
公司考虑实施据云计算的两大障碍依然是安全性与法规遵从。Zenoss公司在2010年第二季度进行的调查显示，接近40%的受访者在被问及他们对云计算的最大关注问题时都选择了安全性。而紧随其后的选项是管理，它占受访者的265%。Zenoss的调查结果与其他云计算相关调查的数字是一致的。
而企业真正关注的问题并不是实际的安全威胁，而是他们无法遵守与安全相关的标准，如PCI。作为回应，当今许多云供应商都在吹嘘和炫耀他们所拥有的SAS-70 II型审计、安全白皮书和其他标准的证书。
正在发展的云供应商Logicworks推出了具有法规遵从的云计算产品，即遵守一级PCI的云产品。
云服务成本
一个比较云供应商的简单直接方法似乎就是成本。问题在于考虑到客户实际使用的资源和支付的费用，在供应商中并不具备可比性。供应商提供虚拟机（VM）资源，但其内存容量、CPU时钟速度以及其他功能却各异。此外，实际提供给客户的部件也是虚拟的，这也造成难以对客户实际使用的资源进行度量以及其他同在云中客户如何影响这些资源。
Amazon公司拥有EC2计算部门，Heroku向Dynos提交而其它厂商则创建自己的度量部门。度量评估不同云供应商成本和性能比的唯一真正可靠方法是使用相同的应用程序对多个供应商的服务进行试验，并比较运行结果。 云计算的安全和管理问题是众所周知的，除此之外，关于云服务的计费也是一个不小的挑战。云服务供应商们总是喜欢吹嘘说他们的服务使用起来有多么的简单，实际上，广大IT经理们都已发现云计算服务的计费并不简单。
云服务的计费是基于许多因素的，从所需的存储空间，到所使用的时间周期，再到每个月的流量分配，等等这些因素都可能成为计费参考。实际上还不止这些，一些云服务供应商还会基于SLA之内的一些隐性条款来收费。为了弄明白一项云计算服务的总费用，用户需要了解供应商账单上的每一项服务要素，以及其计费方式。
服务的计费项目
另一个决定服务真正费用的关键因素是所需的服务类型。对于一些企业而言，所谓的云服务可能只是服务器托管、专用服务器租赁，或是将应用运行在云中。而对于其它一些企业而言，云服务可能就是基于云的数据备份、业务持续性的维持，或是基本的存储托管。
对于广大用户而言，要弄明白云计算服务最简单的方式就是将注意力放在最主要的服务项目上。大多数云服务供应商都会将它们的服务分为三个基本类型：云中服务器、云存储、云工作站和云应用。每一项服务都有其自己的计费方式。
云中的服务器主要分为两种形式：虚拟服务器和物理服务器。换句话说，你既可以在虚拟服务器（与其他人共享物理硬件）上购买使用时间，也可以在专用服务器（你是该服务器唯一的租户）上购买使用时间。表1所示的就是云服务的计费方式：
整张实际上就是在对比不同云服务供应商的服务价格和计费方式。图中列出的每个供应商都会对一些额外的服务和功能征收额外的费用。此外，每项服务的价格也会随着协议长短、总的带宽需求或者所需存储规模的大小而有所变化。在许多情况下，用户是可以和供应商进行讨价还价的。
不同的服务类型
并不是说所有的云服务供应商都是一样的，如果你仔细观察一下供应商之间的区别以及他们各自处理用户需求的方式，就会发现这种差别是很明显的。为了给大家做一个对比，我们挑选了最为知名的三家云架构供应商：
GoGrid将负载均衡服务放在其服务器产品当中，而且不收取额外的费用，此外，他们还免费提供20GB的存储空间；
Rackspace使用的是一种完全不同的计费机制，随着使用量的增长，他们会降低每十亿字节带宽的费用。此外，该公司还在一些虚拟服务器上提供免费的备份服务；
Amazon的大多数服务随着使用量的增加都提供打折优惠，但是对于存储服务的启用和终止都会收取一定费用。
如果你考虑一下最为简单的云存储服务概念，就会很明显地发现这几种计费方式及供应商业务的区别（图2）。再次强调一下，这张图只是对比不同供应商的计费方式。像其它云服务一样，云存储服务的价格也会受到协议时间长短、总的带宽需求或是说所需存储容量大小的影响。此外，这些服务的价格也有足够的讨价还价的空间。
对于使用其服务器托管服务的用户，GoGrid最初提供20GB的免费存储空间，而且他们只为服务器托管用户提供云存储服务。独具特色的是，随着用户所购买的存储容量的增加，GoGrid的服务可以提供打折优惠。GoGrid的云存储服务是以一种定量的方式提供，目前为止还不提供用于启动或停止其它命令的Web服务应用程序接口。
Rackspace试图让它的存储服务计费方式变得尽可能的简单化。他们对于云存储服务的采购提供按比例增减的模式，随着总量的增加，服务的单价也会有所下降。此外，如果文件的大小超过250KB，他们不会收取存取费用。
Amazon S3对于已删除数据不进行收费，根据所需存储总量的增加还会提供一定折扣。对于那些试图将价格稳定下来的公司，他们提供定价合同。对于一些规模较大的文件传输公司，他们建议使用其输入和输出服务，这样可以节省成本。
理想地讲，云计算服务的计费模式应该和选择所需的存储功能和服务器计算资源没什么差别。而事实上，大多数IT经理都发现这种理想很难实现。他们必须仔细去考虑一些“隐性成本”，或是计费标准的变化，从而确定某项服务的真正费用。
更大的挑战来自于一些“非技术”的因素，用户必须考虑到那些独立于谈判条款之外或是隐藏于SLA协议之中因素。
解决这一问题的技巧就是用清晰而又精确的语言将每个合同期内每项服务的总费用写在纸上，这样才能明白真正的总预算金额。
二、数据库审计怎么审？
1、数据库访问流量采集
流量采集是数据库审计系统的基础，只有做到数据库访问流量的全采集，才能保证数据库审计的可用性和价值，目前主要的流量采集方式主要有两种：
镜像方式：采用旁路部署通过镜像方式获取数据库的所有访问流量。一般适用于传统IT架构，通过镜像方式将所有访问数据库的流量转发到数据库审计系统，来实现数据库访问流量的获取。
探针方式：为了适应“云环境”“虚拟化”及“一体机”数据库审计需求，基于“探针”方式捕获数据库访问流量。适用于复杂的网络环境，在应用端或数据库服务器部署Rmagent组件（产品提供），通过虚拟环境分配的审计管理网口进行数据传输，完成数据库流量采集。
探针式数据采集，还可以进行数据库本地行为审计，包括数据库和应用系统同机审计和远程登录后的客户端行为。
2、语法、语义解析
SQL语法、语义的解析技术，是实现数据库审计系统可用、易用的必要条件。准确的数据库协议解析，能够保障数据库审计的全面性与易用性。全面的审计结果应该包括：访问数据库的应用层信息、客户端信息、数据库信息、对象信息、响应信息、登录时间、 *** 作时间、SQL响应时长等；高易用性的数据库审计产品的审计结果和报告，应该能够使用业务化的语言呈现出对数据库的访问行为，例如将数据库中的要素客户端IP、数据库用户、SQL *** 作类型、数据库表名称、列名称、过滤条件变成业务人员熟悉的要素：办公地点、工作人员名称、业务 *** 作、业务对象、业务元素、某种类别的业务信息。这样的是审计结果呈现即便是非专业的DBA或运维人员的管理者或业务人员也能够看懂。
三、数据库审计的价值？
1、数据库相关安全事件的追溯与定责
数据库审计的核心价值是在发生数据库安全事件后，为追责、定责提供依据，与此同时也可以对数据库的攻击和非法 *** 作等行为起到震慑的作用。数据库自身携带的审计功能，不仅会拖慢数据库的性能，同时也有其自身的弊端，比如高权限用户可以删除审计日志，日志查看需要专业知识，日志分析复杂度高等。独立的数据库审计产品，可以有效避免以上弊端。三权分立原则可以避免针对审计日志的删除和篡改，SQL语句解析技术，可以将审计结果翻译成通俗易懂的业务化语言，使得一般的业务人员和管理者也能看懂。
2、数据库风险行为发现与告警
数据库审计系统还可以对于针对数据库的攻击和风险 *** 作等进行实时告警，以便管理人员及时作出应对措施，从而避免数据被破坏或者窃取。这一功能的实现主要基于sql的语句准确解析技术，利用对SQL语句的特征分析，快速实现对语句的策略判定，从而发现数据库入侵行为、数据库异常行为、数据库违规访问行为，并通过短信、邮件、Syslog等多种方式实时告警。
3、满足合规需求
满足国家《网络安全法》、等保规定以及各行业规定中对于数据库审计的合规性需求。并可根据需求形成不同的审计报表，例如：综合报表、合规性报表、专项报表、自定义报表等。
审计跟踪（Audit Trail）指按事件顺序检查、审查、检验其运行环境及相关事件活动的过程。审计跟踪主要用于实现重现事件、评估损失、检测系统产生的问题区域、提供有效的应急灾难恢复、防止系统故障或使用不当等方面。
审计跟踪作为一种安全机制，主要审计目标是：
（1）审计系统记录有利于迅速发现系统问题，及时处理事故，保障系统运行。
（2）可发现试图绕过保护机制的入侵行为或其他 *** 作。
（3）能够发现用户的访问权限转移行为。
（4）制止用户企图绕过系统保护机制的 *** 作事件。
审计跟踪是提高系统安全性的重要工具。安全审计跟踪的意义在于：
（1）利用系统的保护机制和策略，及时发现并解决系统问题，审计客户行为。在电子商务中，利用审计跟踪记录客户活动。包括登入、购物、付账、送货和售后服务等。可用于可能产生的商业纠纷。还用于公司财务审计、贷款和税务监查等。
（2）审计信息可以确定事件和攻击源，用于检查计算机犯罪。有时黑客会在其ISP的活动日志或聊天室日志中留下蛛丝马迹，对黑客具有强大的威慑作用。
（3）通过对安全事件的不断收集、积累和分析，有选择性地对其中的某些站点或用户进行审计跟踪，以提供发现可能产生破坏性行为的有力证据。
（4）既能识别访问系统的来源，又能指出系统状态转移过程。 安全审计跟踪主要重点考虑以下两个方面问题：
（1）选择记录信息。审计记录必须包括网络系统中所有用户、进程和实体获得某一级别的安全等级的 *** 作信息，包括用户注册、用户注销、超级用户的访问、各种票据的产生、其他访问状态的改变等信息，特别应当注意公共服务器上的匿名或来宾账号的活动情况或其他可疑信息。
实际上，收集的信息由站点和访问类型不同而有所差异。通常收集的信息为：用户名、主机名、权限的变更信息、时间戳、被访问的对象和资源等。具体收集信息的种类和数量经常还受限于系统的存储空间等。
（2）确定审计跟踪信息所采用的语法和语义定义。主要确定被记录安全事件的类别（如违反安全要求的各种 *** 作），并确定所收集的安全审计跟踪具体信息内容。以确保安全审计的实效，更好地发挥安全审计跟踪的重要作用。
审计是系统安全策略的一个重要组成部分，它贯穿整个系统运行过程中，覆盖不同的安全机制，为其他安全策略的改进和完善提供了必要的信息。对安全审计的深入研究，为安全策略的完善和发展奠定重要基础和依据。
1、以色列的Imperva，该系统功能还是满强大的，通过IDP探针，串联部署，阻断数据库数据安全威胁。但国内用户使用由于全英文界面，加上配置数据库安全策略很复杂，非专业数据库DAB *** 作起来很困难。更重要的是国内使用该产品，其技术手段需要依靠合作的数据库厂商来做支持。
2、IBM的Guardium：该系统强过国内的大部分产品，但由于其设计思路的原因，部署上需要在数据库服务器端安装“S-TAP” 轻量级系统探针；分级部署时需在数据库服务器端安装“S-GATE”，在总控服务器安装“Z-TAP”。该系统按照国外的审计需求，只针对满足国外需求的审计数据进行审计。过滤了大部分可能对国内用户有实用价值的审计信息。也是全英文界面，数据库安全审计策略配置很复杂，非专业数据库DAB *** 作起来很困难。
以上两个产品是国外的主流产品，国内市场上基本数据高端专业客户使用，价格很高。对国内绝大多数用户来说，具有有用性，但缺乏实用性， *** 作维护困难。只记录“关注”事件，逃避“IO”，失去“事后”追踪有用性， 增加“事前”管理和使用难度。 国内数据库产品主要厂商：
1、上讯信息——数据库安全审计系统；
2、北京安信通——数据库审计系统；
3、北京国都兴业——慧眼数据库审计系统；
4、深圳昂楷科技——数据库多重审计系统AAS；
5、安华金和——数据库监控与审计系统；
6、安恒信息——明御数据库审计和风险控制系统；
7、北京天融信——网络卫士数据库审计系统TopAudit-DB （简称 TA-DB）
8、北京启明星辰——天玥网络安全审计系统
9、北京莱克斯科技——ClearNet DBA数据库审计系统
10、杭州思福迪——LOGBASE业务数据库审计系统
11、杭州帕拉迪——DBxpert数据库审计系统
12、福建海峡信息——黑盾数据库安全审计系统
主要分为：国内原先具有网络审计产品的厂商，在网络审计产品的基础上经过简单包装，推出的数据库审计产品；国内厂商专门针对数据库通讯协议的特点，开发出专门的数据库审计产品；国外的数据库审计产品；OEM第三方的数据库审计产品，OEM对象可能是国内的产品，也可能是国外的产品。
区分这些数据库安全审计产品可以从几个方面来测试：
1、双向审计：只能实现单包返回状态分析，不能实现对查询结果进行分析。
2、长SQL语句漏审：超长SQL语句无法解析记录，提供逃避审计通道；
3、完全协议解析：解析协议解码不完全（无会话技术就不可能完全解码）；
4、参数值与SQL语句匹配：变量绑定不支持或不完整（审计素材有用性缺失）；
5、海量数据分析：无法全部存储分析审计数据，记录之后，不能查询；
6、海量存储：无法记录下原始数据包，缺乏最原始的审计依据；
7、及时警告：事后报警，做不到事前防范，事中报警；
8、多语句无法有效分割：长会话记录分散记录，审计困难；
9、客户影响：部分产品需要改变网络拓扑，甚至需要在数据库服务器上安装采集器，易造成安全漏洞。
10、应用用户关联：三层应用用户关联有20%以上会出现漏审和错审，尤其在高并发下更是如此。
这里重点评价一下好的数据库审计系统要求：能展现数据库完整会话 *** 作的系统。采用数据库访问协议完全解析技术，能实现对超过1460字节长度的SQL语句完整解析。除了能解析数据库绑定变量，还能解析该绑定变量的值。能完整记录SQL语句的返回结果集。同时由于是国内厂家自主知识产权，技术支持也比国外产品更直接、更有效。
如果说好的数据库审计系统的特征如下：
1、能展现数据库完整会话 *** 作；
2、具备对超过1460字节长度的SQL语句完整解析；
3、具备解析数据库绑定变量和该绑定变量的值；
4、能完整记录SELECT语句的返回结果集； 上市公司：萨班斯法案的要求
电信、军工、烟草、电力等行业需求
等级保护、分级保护的要求
此审计系统使用数据库本身的内置审计功能来审计绝大多数数据库 *** 作。但是，审计的细粒度级别非常低，并且很难恢复SQL *** 作本身。例如，对于数据删除 *** 作：从 EMP 中删除，其中 DEPTNO=10;假设表 EMP 中有 100 条记录满足条件 DEPTNO=10，则数据库审计系统中将有 100 个 DELETE *** 作，而不是真正的 SQL 语句：从 EMP 中删除，其中 DEPTNO=10。并且大多数现有数据库无法准确审计 DDL 语句，例如：ALTER TABLE XXX ADD （col单个数据库产品可以审计 DDL 语句，但这是通过创建数据库级触发器来完成的。
总之，这种基于数据库产品本身审计功能的审计系统的审计粒度和准确性是有限的。而且由于数据库产品本身的审计功能是基于数据库引擎的，所以消耗了生产数据库系统本身的资源。如果开启所有会话的所有数据库 *** 作审计，生产数据库系统的CPU资源将消耗15%~30%。因此，如果使用这样的数据库审计系统，通常只是有目的地审计单个数据或 *** 作，而不审计整个业务数据库中的所有 *** 作。
（二）外置旁路模式的数据库审计系统
外部审计模式的数据库审计系统是独立于生产数据库的系统，其工作原理是通过网络审计模式监听并收集所有客户端发往生产数据库的网络报文，然后在审计系统内部解包这些网络报文并恢复 *** 作命令（即 SQL 语句）里面。SQL语句捕获后，存储在数据库审计系统中，然后根据用户设置的条件生成告警或报告。与基于数据库产品的审计功能相比，外部审计模式下的数据库审计系统具有以下优点：不占用生产系统的任何系统资源，由于它基于网络审计模式，所有审计 *** 作都在审计系统上进行，因此不会占用生产数据库系统的系统资源;它可以准确地恢复SQL语句，因为所有从客户端发送到数据库服务器的SQL语句都是通过TCP/IP网络发送的，如果按照相应的数据库产品网络数据包格式对这些TCP/IP网络数据包进行捕获和解析，原则上可以得到所有的SQL语句代码。因此，网络审计模式下的数据库审计产品不仅可以审计DML *** 作，还可以审计数据查询 *** 作和DDL *** 作。具有良好的用户界面，可根据用户需求自定义报警条件，可以通过黑白名单减少每日报警次数。
目前，医院信息系统中的数据库审计产品大多采用这种网络审计模式。但需要注意的是，如果用户直接登录数据库系统所在的 *** 作系统，或者直接在数据库系统主机的控制台上执行数据库 *** 作，则不会生成数据库网络数据包，这种网络审计模式下的数据库审计系统无法审计这些数据库 *** 作。因此，如果要对生产数据库进行全面的审计，不仅要部署网络审计模式的审计系统，还要结合堡垒主机系统和桌面管理系统。
关注威翰德科技公众号解锁更多回答
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）