网络安全之企业安全浅析

网络安全之企业安全浅析本站　　目前安全行业中“二进制”和“脚本”流派广为人知，虽然他们是安全行业的主力军，但除了微观对抗之外，安全是一个很大的工程，比如企业安全管理，实际上并不属于上述两类

　　目前安全行业中“二进制”和“脚本”流派广为人知，虽然他们是安全行业的主力军，但除了微观对抗之外，安全是一个很大的工程，比如企业安全管理，实际上并不属于上述两类。确切来说，应归入另外一个群体：CSOs，加了s表示他们是一个群体，这个群体从生态链的顶端联接着绝大多数从业者和安全厂商。

　　企业安全是不是发现然后修复，再设置一下之类的工作？假如您的公司只有一个产品、两台、3个，我认为这个说法不能算错。不过在绝大多数情况下，企业安全远不止于此。和对抗能不能算企业安全？在一个过于纸上谈兵的企业这是不错的切入点，不过局部对抗发生于企业安全的各个场景中，它只能算是缩影，不是全貌。企业安全是什么？对传统乙方安全公司，对新兴的业务安全公司、移动安全公司，对甲方的互联网公司，对甲方的传统公司，对咨询顾问，对研究者，对活跃于各大SRC上的白帽子们来说，诠释肯定都不一样。

　　现在的安全行业里除了显得有些务虚的安全理论之外，要么就是一边倒的，要么就是过于超前、浮在表面没有落地方案的新概念，这些声音对企业安全实操都缺乏积极的意义。有些方是有实操意义的，并不像研究者声称的是纯务虚的东西，纯粹是位置决定想法的问题。还有些流行的概念在解决实际问题上的效果有待验证，并不像市场鼓吹的那么好。技术很重要，但只解决了一半问题，安全的工程化以及体系化的安全架构设计能力是业内普遍的软肋，多数人不擅此道。对市场上的各种观点，可能需要一个相对客观的评价：即某项技术或管理在全生命周期的各个环节中，在不同的行业、不同的场景下有什么样的价值，而不是很随意地贴标签。很多概念10多年前就有了，发明一个新概念讲与过去一样的事情，再给自己贴一个发明者的标签对行业没有积极的意义。纵深防御之类的概念在ISS没被IBM收购之前就有了，为什么现在有的人觉得这个词很新？因为过去没重视，或者说缺少实践。

　　企业安全是什么？可以概括为：从广义的信息安全或狭义的网络安全出发，根据企业自身所处的产业地位、IT总投入能力、商业模式和业务需求为目标，而建立的安全解决方案以及为保证方案实践的有效性而进行的一系列系统化、工程化的日常安全活动的集合。实际上，这里面的每一个项都会决定您的安全整体方案是什么，哪怕同是中国互联网TOP10中的公司，安全需求也完全不一样。

　　有人也许会觉得CSO干的活有点虚，但凡偏管理都是纸上谈兵。不直接回答这个问题，只举一个例子。大多数身在这个行业的人都知道遍地都是，入侵者甚至站在了的维度，国内的绝大多数除了password字段加盐值存储之外，其余信息都以明文保存。而在欧美等地隐私保护是有明确的法律规定的，映射到数据持久化这个细节，就是需要满足一定强度以上的加密存储。CSO就是需要制定这些策略的人，难道说这些都是形而上学无用的安全措施吗？在互联网公司，安全负责人会较多地介入到日常技术性活动中，但随着组织规模的扩大和行政体系的加深，CSO不再可能像白帽子一样专注于对抗的细节，这也是一个无法回避的现实问题。是不是一定要说出诸如时IE和其他浏览器的区别，才算是合格的CSO？这要看具体场景，对于国内排名TOP10以后的互联网企业，这个要求也许勉强算合理范畴，但对于规模非常庞大的企业而言，这个要求显然太苛刻了，在有些公司CSO属于法务类职位而不是技术类职位。

　　：基础、狭义但核心的部分，以计算机（PC、、小型机、BYOD……）和网络为主体的，主要聚焦在纯技术层面。

　　（2）平台和业务安全：跟所在行业和主营业务相关的安全管理，例如反欺诈，不是纯技术层面的内容，是对基础安全的拓展，目的性比较强，属于特定领域的安全，不算广义安全。

　　（3）广义的信息安全：以IT为核心，包括广义上的“Information”载体：除了计算机数据库以外，还有包括纸质文档、机要，市场战略规划等经营管理信息、客户隐私、内部邮件、会议内容、运营数据、第三方的权益信息等，但凡想得到的都在其中，加上泛“Technology”的大安全体系。

　　（4）IT风险管理、IT审计&内控：对于中大规模的海外上市公司而言，有诸如SOX-404这样的合规性需求，财务之外就是IT，其中所要求的在流程和技术方面的约束性条款跟管理重叠，属于外围和相关领域，而管理本身从属于IT风险管理，是CIO视角下的一个子领域。

　　（5）业务持续性管理：BCM（Business Continuity Management）不属于以上任何范畴，但又跟每一块都有交集，如果觉得（3）和（4）有点虚，那么BCM绝对是面向实操的领域。有网易、支付宝、携程等企业，因为各种各样的原因业务中断，损失巨大都属于BCM的范畴。有人会问：这跟安全有什么关系？安全是影响业务中断的很大一部分可能因素，例如，入侵导致必须关闭服务自检，数据丢失，用户隐私泄露等。又会有人问：这些归入安全管理即可，为什么要跟BCM扯上关系，做安全的人可以不管这些吗？答案自然是可以不管，就好像说：“我是个程序员，JVM、dalvik（ART）运行原理不知道又有什么关系，完全不影响我写代码！”事实上，BCM提供了另一种更高维度、更完整的视角来看待业务中断的问题。对于安全事件，它的方也比单纯的ISMS更具有可操作性，对业务团队更有亲和力，因为任何以安全团队自我为中心的安全建设都难以落地，最终都不会做得很好。

　　（6）安全品牌营销、渠道维护：CSO有时候要做一些务虚的事情，例如为品牌的安全形象出席一些市场宣介，presentation。笼统一点讲，现在SRC的活动基本也属于这一类。

　　（7）CXO们的其他需求：俗称打杂。这里不要理解为让安全团队去攻击一下竞争对手的企业这样负面上的事情，而是有很多公司需要做，但运维开发都不干，干不了或者不适合干的事情，安全团队能力强大时可以承包下来的部分。

　　基础的是在甲方的绝大多数安全团队能覆盖的事情，不管您的安全团队能力如何，在公司里有无影响力，这个是必须要做的，因为这是把您招过来的初衷。再往后的发展，是否止于此则看个人的想法。对于沉醉技术的人，其实不需要往后发展了，这些足够了。但如果您的安全团队富有活力和想法，即便您想止于此他们也不干，把部门做大做强是这些人的愿望，只有这样才能给安全团队更大的空间。这点跟乙方是不一样的，对于乙方而言，可以在某个单点领域上无限深挖，而不会遇到天花板，因为您始终是在满足主营业务的需求，即使您成为骨灰级的专家，公司也会对您在某方面创新有所期待而给您持续发展的可能性。但是在甲方，安全不是主营业务，归根结底，安全是一个保值型的后台职能，不是一个明显能创造收益的前台职能，是一个成本中心而非盈利中心。安全成本的大小跟业务规模以及公司盈利能力相关，公司发展时预算和人员编制都会增加，业务停滞时安全做得再好也不会追加投入，因为无此必要。反面的例子也有：做得不好反而追加投入的，那是一种技巧而非现实需要。在乙方，无论您的技能多厉害，公司都不会跳出来说“您已经超出我们需求了，还是去更强大的公司吧”（通常情况下）。但是在甲方，假设是在一个国内排名大约TOP5以后的互联网企业，养一个的大牛也会令人很奇怪，他是在给企业创造价值还是在自娱自乐是会受到质疑的，CSO也会被质疑是否花了大价钱挖来的人不是出于业务需要而是用于扩大自己团队在业内影响力这种务虚的事。假如公司到了Google这种级别，有一大堆产品，储备大牛则是顺利成章的，业务上显然是有这种需求的。不过还要看产出是否对主营业务有帮助，工作成果不能转化为主营业务竞争力的尝试性活动在公司有钱的时候无所谓，在公司收紧腰带时则其存在价值就有争议。

　　以狭义的安全垂直拓展去发展甲方安全团队的思路本质上是个不可控的想法，筹码不在CSO手中，甚至不在CTO手中，而是看主营业务的晴雨表，甲方安全是要看“脸”的，这个脸还不是指跨部门沟通合作，而是在最原始的需求出发点上受限于他们。因此有想法的安全团队在网络安全方面做得比较成熟时会转向平台和业务安全，平台和业务安全是一个很大的领域，发展得好，安全团队的规模会扩大2倍，3倍，并且在企业价值链中的地位会逐渐前移，成为运营性质的职能，结合BCM真正成为一个和运维、开发并驾齐驱的大职能。

　　BCM在很多人眼里就是DR（Disaster Recovery，灾难恢复），DR其实只是BCM中的一个点，属于下层分支。不过这对技术领域的人而言是最直观的部分，DR在互联网企业里由基础架构部门或运维主导。不过强势的甲方安全团队其实也是能参与其中的，而BCP（Business Continuity Plan，业务持续性计划）中的很大一部分跟安全相关。

　　广义的信息安全，比较直观的映射就是ISO2700x系列，行业里的绝大多数人都知道ISO27001和BS7799，这里就不展开了，对真正有安全基础的人而言，都是很简单的东西。在企业里能否做到广义的安全，主要看安全负责人和安全团队在公司里的影响力，对上没有影响力，没有诠释利害关系和游说的能力，自然也就做不到这些。另一方面，狭义安全主要对接运维开发等技术面公司同僚，但是广义安全会对接整个公司的各个部门，对于沟通面的挑战来说，又上了一个新的台阶，这主要取决于安全的领队人物自己拥有什么样的知识结构以及他的推动能力如何。

　　在企业完全涉及的7大领域中，对于第（4）条，如果您所在的组织有这方面的需求，安全职能自然也会参与其中，是否刻意去发展他则看自己需求，对某些做过IT治理和风险咨询的人，相信是有能力一并吃下的，如果是技术派，不建议去尝试。

　　第（6）条属于水到渠成的事情，到了那一步自然需要考虑，就算不想，公司也会让您去，明明做技术活，却也不知道为什么会跟这一类事情挂上钩。

　　第（7）条有人看时自动过滤了，不过安全负责人自身是否有瓶颈，能否在企业里发展起来跟这条有很大关系，甚至有很多从（1）发展到（2）、（3）的人都需要借助（7）这个渠道。

　　对于互联网公司，建议做（1）、（2）、（5）；对于传统行业，建议做（1）、（3）、（4）、（5）。

　　信息安全管理（设计流程、整体策略等），这部分工作约占总量的10%，比较整体，跨度大，但工作量不多。

　　：IDC、生产网络的各种链路和设备、、大量的服务端程序和中间件，等，偏运维侧，跟、打补丁、ACL、安全配置、网络和主机等这些事情相关性比较大，约占不到30%的工作量。

　　应用与交付安全：对各BG、事业部、业务线自研的产品进行应用层面的安全评估，，，代码框架的安全功能，应用层的，应用层的等，属于有点“繁琐”的工程，“撇不掉、理还乱”，大部分甲方团队都没有足够的人力去应付产品线交付的数量庞大的代码，没有能力去实践完整的SDL，这部分是当下比较有挑战的安全业务，整体比重大于30%，还在持续增长中。

　　业务安全：上面提到的（2），包括账号安全、交易风控、、反价格爬虫、反作弊、反bot程序、反欺诈、反、反垃圾信息、舆情监控（）、防游戏外挂、打击、安全等，是在“吃饱饭”之后“思淫欲”的进阶需求，在基础安全问题解决之后，越来越受到重视的领域。整体约占30%左右的工作量，有的甚至大过50%。这里也已经纷纷出现乙方的创业型公司试图解决这些痛点。

　　总体来看，传统企业偏重管理，有人说是“三分技术，七分管理”；而互联网企业偏重技术，三七开可以倒过来。其实这种说法也是不准确的，到底什么算技术，什么算管理，这些都没有明确的定义。安全领域大部分所谓管理不过是组织技术性的活动而已，充其量叫技术管理。

　　（5）使用基于传统的资产威胁脆弱性的风险管理方加上购买和部署商业安全产品（解决方案）通常可以搞定。

　　在规模不大的互联网公司，传统企业的风险管理方是可以沿用的。但在大型互联网公司，传统企业的方可能会失效，因为您可能连基础架构上跑什么业务都搞不清，想理清所有系统接口间的调用关系以及数据流去检视设计风险以及设置细粒度的访问控制就是件不现实的事情。产品线极多时，业内没有任何一个团队敢说自己有能力支持全产品线，对于高速发展的业务，当理清了您想要的时，说不定架构又发生变化了。只有对占公司整体营收比较主要的以及培育性质的战略级的核心业务，才有必要去深入调研并随之更新，其他的主要依靠自动化手段。

　　从安全建设上来看，传统企业的安全建设是：在边界部署硬件、IPS/IDS、WAF、商业扫描器、堡垒机，在上安装防软件，集成各种设备、终端的安全日志建设SOC，当然购买的安全硬件设备可能远不止这些。在管理手段上比较重视ISMS（管理体系）的建设，重视制度流程、重视审计，有些行业也必须做以及满足大量的合规性需求。

　　互联网可分为生产网络和办公网络，即便Google声称取消内网也是针对办公网络而非生产网络。互联网行业的大部分安全建设都围绕生产网络，而办公网络的安全通常只占整体的较小比重。但是某些传统企业可能完全没有生产网络而只有办公网络，那么也就变成办公网络的。随着社会“互联网+”进程的加速，很多传统企业也会有自己的生产网络，最终都变成和互联网公司一样的形态。所以对于那些在给传统企业客户提供咨询和解决方案的乙方的工程师，如果不学习互联网安全，也迟早会陷入困境。

　　互联网企业的生产网络中，安全解决方案基本上都是以为驱动的，怕被黑、怕拖库、怕被劫持就是安全建设的最直接的驱动力。互联网公司基本不太会考虑、合规这种形而上的需求，只从最实际的角度出发，这一点是比传统企业更务实的地方。曾遇到过一个例子，说要在上装防软件，推测就知道是传统企业的思路，不是没有真正实践过互联网企业安全就是没被业务线挑战过。在大型互联网企业，仅是性能损耗、运维成本和软件成本这几条就能分分钟把这种需求干掉，更不用进入对于防护这种更实际的话题了。很多标准说到底都是各厂商参与编写，博弈并达成妥协，有利于自己产品销售的代言，并不是完全站在建设性的角度的，作为乙方给政企客户写解决方案建议书无可厚非，但在互联网公司做企业安全，生搬硬套某些标准就会闹出笑线、从量变到质变

　　对于超过一定规模的大型互联网公司，其IT建设开始进入自己发明轮子的时代，安全解决方案开始局部或进入全部自研的时代。例如不会购买硬件，而是用+Netfilter的方式自建，不会部署硬件IDS/IPS，而是用其他方式来解决这个问题。其实不难理解，规模小的时候买台硬件放在最前面，省事。但是规模大了，难道去买1000台硬防放在IDC机房？成本上就没法通过批准。再说，基于分布式系统的CAP理论和Map-Reduce衍生的一系列互联网架构，本质上都具有“无限”的扩展能力，而对于传统的硬件盒子式的解决方案，其设计大多源于对小型网络体系架构的理解，基本不具备扩展能力，完全不能适应大规模的互联网架构。在这种情况下甲方安全团队自己动手去打造完全围绕自身业务的解决方案也就成必然趋势。

　　自研或对开源软件进行二次开发+无限水平扩展的软件架构+构建于普通中低端硬件之上（PC服务器甚至是白牌）+大数据

　　与办公网络和雇员管理相比，互联网公司的文化比较开放，一般不太会维持激进的安全政策（对雇员做太多方面的管制和限制），这点也是跟传统企业差别比较大的地方。

　　也有一些灰色地带，比如TCO较高的安全方案，一开始没感觉，但实质是吸毒，随着IDC的规模扩张，安全的成本越来越大，最后被自己巨大的成本“毒死”。对于做惯传统行业解决方案且客户手里都有大把预算的顾问来说，对这一点是没感觉的，几千万元的安全整体方案信手拈来，但是放到互联网中，一旦业务规模成倍增长，这些方案最终都会走入死胡同。不止是成本，如果不能做到兼顾宿主的性能，安全架构随整个业务架构水平扩展，保证高可用性，最终安全措施都会走进死胡同。

　　以安全集成为自身职业亮点的人如果不积极学习，会有很大贬值风险，因为以后不需要堆硬件盒子式的解决方案了，就算堆也不再是原来的堆法。

　　对于创业型公司而言，安全不是第一位的，是唱反调吗？应该只是大实话而已。安全建设的需求应该是：保障最基本的部分，追求最高性价比，不求大而全，映射到技术实现应该是做如下事情：

　　是不是觉得简陋了一点？估计很多乙方提供的服务除了卖产品之外也不会比这个效果更好了。不过，现在不少创业公司是拿了不小的风投的，也没那么寒酸。另外一个很重要的特征是，创业公司基本都上公有云了，不会自己再去折腾IDC那点事，所以相对而言以上措施中的一部分可以等价于：

　　具体怎么选怎么用就不展开讲了，不过不要因为迷信云平台关于安全能力的广告而自己不再去设防，毕竟针对租户级的通用型的安全方案其覆盖面和防御的维度是有限的。

　　这个层次对应市场上大多数公司的安全需求，它的典型特征是，业务营收的持续性需要安全来保障。公司愿意在IT安全上投入固定的成本，通常小于IT总投入的10%，不过这已经不错了。这时候开始有专职的安全人员或安全团队，建设上重视效果和ROI，会具备初步的纵深防御能力。对应技术上的需求为：

　　好像跟前面的描述比一下子抽象了？是的，这个层级的安全需求没办法很具体地量化。不同的业务模式对应的安全实现还是有很大的不同，加上这个区间里的公司营收规模可以差很大，对应的安全投入也可以差很多。那什么样的公司归入这个区间呢？比如四大行，国内TOP10甚至TOP5以后的互联网公司，大量的电信、金融、政府、能源等企业都属于这个区间，但为什么不把BAT归入这个区间？这样的分类岂不是不科学？之所以这样分类完全是从安全建设的复杂度上去考量的，而不是从安全建设的资金投入上去归类的。很多行业（比如金融）的安全投入很大，但这些解决方案大都是靠花钱就能买来的，而BAT的方案花钱不一定能买得到，很多都需要自己动手去打造，对安全团队的定位、能力和需求完全不一样。那BAT以外较大的互联网公司呢？他们会玩些各自特点的小花样，但是不会进入大范围的复杂的安全建设，这是由公司的整体面和业务决定的，不需要过分保障和超前业务的安全建设。

　　主要差别表现在是否大量地进入自己造轮子的时代，即安全建设需要依托于自研，而非采用商业解决方案或依赖于开源工具的实现。

　　那么平台级公司和生态级公司的区别又在哪里？从表象上看，生态级公司的大型基础架构如果用传统的安全方案几乎都无法满足，所以会大量的进入自研。而平台级公司则会依赖开源工具更多一些，不会对所有解决方案场景下的安全工具进行自研。如果有预算也会优先投在“业务安全”侧，比如反欺诈平台等等，而不会自己去搞入侵检测。当然，这有可能是个伪命题，有可能随着时间的推移，乙方公司也开始提供具有可扩展性、能应对分布式架构的方案，或者当时间尺度拉得长一点，平台级公司每年在自研上投入一点点，多年之后也具备了BAT级别的安全能力也并非完全不可能。不过这些都是理想状况，现实总是受到多方面因素制约的。

　　第一个因素是技术驱动在底层还是在应用层驱动业务。表象上，平台级公司和生态级公司都是以PC端Web服务为入口的平台应用和以移动端入口的移动应用。有的依赖于一些PC客户端或移动端偏底层的，但在技术实现方式上，平台级公司更多地直接使用或少量修改开源软件，而生态级公司的IT基础设施则会类似于Google的三篇论文一样，不仅仅停留在使用和少量修改，而是会进入自己造轮子的阶段。其中所造的轮子是否对业界有意义这种问题暂时不去评价，但对应的安全建设则反映出平台级公司的安全主要围绕应用层面，而生态级公司的安全会覆盖基础架构和应用层面两块。直接使用开源工具的部分交给社区去处理，自己跟进打补丁就行了，但如果是自己开发的，那么就需要自己去解决一揽子的安全问题，比如Google造了这个轮子，那一系列的安全问题Google需要自己解决，比如阿里自己去搞了一个ODPS，那阿里的牛人也需要解决这个，再比如华为在领域造了LiteOS这个轮子，自然也要去处理对应的问题，而这些偏底层的问题显然早已超出应用安全的范畴，也不是一般的甲方安全团队有能力应对的。其实有些平台级公司也是发明了一些轮子的，比如自动化运维工具，比如一些NOSQL，不过IDC规模两者之间仍然差得比较远，上层的业务复杂度也有差距，支持的研发团队的规模也有差距，对安全工具的自动化能力和数据处理规模仍然存在阶梯级的差别，这一点也决定了为什么要自研。安全其实只是IT整体技术建设的一个子集，当整体技术架构和实现方式进入自产自销阶段时，安全建设也必然进入这个范畴。对于很多实际上依靠业务和线下资源驱动而非技术驱动的互联网公司而言，安全建设去做太多高大上的事情显然是没有必要的。

　　第二个因素是钱，钱也分为两个方面：1）成本；2）ROI。假设安全投入按IT总投入的固定10%算，又假设生态级公司的安全建设成本是平台级公司的5~10倍，这个成本除了带宽、IDC服务器软硬件之外，还有技术团队，加起来才是总拥有成本TCO。10个人的安全团队和100个人的安全团队能做的事情相差太大。还有一方面则类似于“去IOE”，目前对于大型互联网没有合适的安全解决方案，即使有，这个成本可能也会无法接受，所以假如乙方公司能推出既能支撑业务规模，又具有性价比的方案，甲方安全团队真的没有必要再去造轮子了。

　　第三个因素是人。安全团队的人员数量也只是一个很表面的数字，安全团队的构成才是实力，能囤到大牛的安全团队和由初级工程师组成的安全团队显然是不一样的，首先前者的成本不是所有的公司都能接受，其次，平台不够大即使大牛来了也未必有用武之地。大多数平台级公司中安全团队的知识和经验集中在Web/、应用层协议、Web容器、中间件和，生态级公司则扩展至系统底层、二进制、运行时环境和内核级别，能力积累也存在差别。这里并无褒贬之意，仅在说明业务对技术的需求不一样。

　　那么，平台级公司在安全建设上是不是就没有乐趣呢？其实这类公司也玩一些小花样，比如修改SSHD、LVS，加入一些安全特性。可能也会自己定制一个WAF，或者搞搞日志的分析。但比如涉及DPI、全流量、、内核级别的安全机制，基本上都不会介入，对于一个规模不是特别大的平台级公司的甲方安全团队而言，这些门槛还是有点高。

　　生态级公司是不是全领域进军自己造轮子呢？也不是，主要工作还是在、WAF、扫描器、抗、日志分析等领域。在SDL环节上可能也会自己研发些工具，但很与比直接使用商业工具更短平快。另外自研工具有一个原则：都限定在“民用”领域，不会自己去发明一个RSA这样的东西。

　　的本质是改变企业需求方通过传统的渠道获取IT资源的形式。传统的方式是一个企业假如要构建信息化的能力，必须要采购硬件，采购软件，维护一个较大的IT团队，TCO很高。但是，到了云计算时代，这一切你都不需要，只要轻点鼠标就可以获取大量的计算、存储和网络资源，并且不再需要专门的人员去IDC机房维护服务器，不需要大量的运维人员，甚至某些通用的应用开发都省了，可以将手头的IT预算用于最需要的部分—完全聚焦于自己的业务，而不用费大量的精力维护基础设施，甚至资源的获取变得弹性：需要时轻易获取大量甚至海量的计算资源，用完后可以及时释放，不用担心资产闲置和老化。在IT产业的销售模式中被颠覆的一环是，传统企业不再直接购买服务器存储商业数据库，而是通过云计算平台获取。同样地安全到了云计算时代，企业客户会更希望通过云化的方式来获取和整合安全的解决方案，例如SaaS（Security as a Service），这就要求安全产品或解决方案本身需要支持虚拟化、软件化、分布式、可扩展性，并且利用大数据和人工智能，利用云端无限的计算和存储能力，缓解传统安全解决方案中数据的离散、单点的计算能容不足，信息孤岛和无法联动等问题。

　　对使用云的租户而言，云平台自身以及应用超市Marketplace（类似APP store）集成了各个安全厂商的云安全产品以及可托管的安全专家服务。如果自身没有太强烈地要主导安全实践的意愿，通常情况下通过应用超市和云平台免费提供的安全功能就可以快速构建基础的安全能力。如果希望得到进阶的安全防护，则必须自己进一步动手。

　　在传统的安全方案中，安全厂商以提供硬件安全产品和安全服务为主，而在云环境下，硬件形式的安全方案会越来越不合拍，与之相比，把竞争力构建在软件层面的安全方案会成为云上的主流。相比过去面对面提供安全服务，现在则转变为在租户侧部署各种安全传感器，通过在云端汇聚安全度量数据，结合威胁情报或由专家解读数据来提供可管理的一站式安全服务。