云安全是一种基础服务架构

互联网上每天新增的恶意代码和恶意网页都在数十万的量级,严重威胁着用户的上网安全。这些恶意代码,和曾经风靡一时的冲击波等传统病毒相比,变种更多、更新
更快,完全以经济利益为导向,更以网页挂马形式实施大面积传播。“所以传统以恶意代码签名为主的防御技术已力有未逮,各大安全厂商都纷纷在安全领域尝试新的思路和技术,在网络安全领域也出现了一个新的名词─云安全。但云安全只是一种基础架构,重要的是为用户提供多种更为实时的安全服务,如防病毒、URL及垃圾邮件过滤等,甚至还可以与软件即服务(SaaS)等商业模式配合,提供给用户更强大安全防护能力与更多的选择。”赛门铁克中国区技术支持部首席解决方案顾问林育民说。信誉服务识别Web攻击过去,用户只有在访问恶意网站或者恶意电子邮件时才有可能受到感染威胁,而现在,攻击者通过感染合法网站并利用其作为传播介质来攻击企业和个人用户,而且会特别针对用户所信赖的网站,例如社交网站等。林育民认为,面对不断变化的恶意网站,需要重新思考应对模式;尤其是在Web 2.0时代,须采用Web 2.0的手段对抗新兴的Web攻击手法。为此,赛门铁克
透过用户自愿参与的社群、全球超过200个国家部署的20万个以上风险监测点,以及全球1.3亿以上的赛门铁克用户不断提交的恶意代码,在云端组成一个完整的资料库,共享网站安全讯息,以Web 2.0的思维实时对抗最新的Web威胁!记者了解到,当全球任何角落的终端用户在加入赛门铁克信息安全共享社群後,会与云端的服务器保持实时联络,当发现异常行为或病毒等风险后,自动提交到云端的服务器群组中,由云计算技术进行集中分析和处理。
借助URL信誉数据库,赛门铁克可以按照恶意软件行为分析所发现的网站页面、历史位置变化和可疑活动迹象等因素来指定信誉分数,从而追踪网页的可信度。然后将通过该技术继续扫描网站并
防止用户访问被感染的网站。林育民说,为了提供更精确的讯息,赛门铁克不但为网站指定了信誉分值,通过不同的颜色给用户直观的体验,更提供了详细带毒的URL位置、恶意代码文件名、签名(MD5)及威胁名称。通过URL信誉分值的比对,用户可以知道某个网站潜在的风险级别。当用户访问具有潜在风险的网站时,就可以及时获得系统提醒或阻止,从而帮助用户快速地确认目标网站的安全性。通过这种URL库的信誉评分机制,可以防范恶意程序源头。由于对零日攻击的防范是基
于网站的可信程度而不是真正的内容,因此能有效预防恶意软件的初始下载,用户访问恶意网站前就能够获得防护能力。文件信誉评等将是趋势由于病毒的层出不穷,恶意代码的成长速度已经超过了正常应用的增长数目。鉴于恶意软件出现数量空前,赛门铁克认为单靠传统的黑名单防护技术已经不能满足当前的安全需求!为此,赛门铁克不但采用主动式防御技术以防范各类未知恶意代码,并缩短病毒定义库发布时间以实时防范各类新兴安全威胁,更推出了文件信誉评等云安全服务。传统黑名单技术可有效防范已知的恶意代码,而白名单技术可有效加速防病毒引擎扫描文件,这些技术已成熟地运用在现今产品中。但今日的恶意代码不但数量激增、更加隐蔽且更具针对性;对於未被黑白名单涵盖的
众多文件,已无法仅靠用户提交或主动收集恶意代码样本,进行分析後,再发布病毒签名进行防护!赛门铁克以Web 2.0的思维出发,推出文件信誉评等服务,借由主动自愿参与的用户安全社群蒐集文件背景信息,通过云端服务计算文件信誉分值,以实时房范最新的恶意代码威胁!林育民补充说,赛门铁克自2007年对自愿参与的诺顿用户社群提供文件信誉评等服务後,已收集了超过3亿笔不同文件的背景信息!事实上,用户对於电脑中的文件,不可能像在Web 2.0网站中对读过的书或购得的商品做出评等;为此,赛门铁克在设计文件信誉评等技术之初,即以对用户不造成干扰的自动化评等技术为主要目标!透过收集文件的名称与位置、签名(MD5)与第一次出现的时间等背景讯息,结合赛门铁克云端服务的数据库即可计算出该文件的信誉分值。当遇到既
有的黑白名单均无法识别的文件时,透过云端取得该文件是否是最近出现的、已有
多少终端存在此文件及赛门铁克是否已分析过该文件等背景信息,即可判断是否该拦阻或放行该文件的运行!记者了解到,赛门铁克的文件信誉评等技术,可与现有的病毒签名、启发式和入侵检测技术互补,来甄别各种新型网络威胁和有针对性的攻击,提供对不断推陈出新的恶意代码,更为主动与实时的安全防护。这一创新技术不但可保护众多的赛门铁克用户,更能更好的满足企业对安全防护软件易於部署、管理与运维的要求。事实上,赛门铁克文件信誉评等技术需要庞大的数据库来做支撑,如果没有
多年的技术沉淀和积累,想做到这一点是有难度的。利用以Web 2.0思维出发的文件信誉评等技术可以在当前恶意程序迅猛增长的情况下,有效的降低新型攻击带来的安全风险。此外,赛门铁克於2008年并购了MessageLabs,结合云安全与软件即服务(SaaS)的商业模式,提供给用户更实时的安全防护与更多的选择!【编辑推荐】 云安全指明安全的未来 云安全进入第三层次 展望已获得成果 云计算最大挑战是网络安全【责任编辑:faya TEL:(010)68476606】 原文:云安全是一种基础服务架构 返回网络安全首页

时间: 2024-07-31 22:15:52

云安全是一种基础服务架构的相关文章

几种常见的微服务架构方案——ZeroC IceGrid、Spring Cloud、基于消息队列、Docker Swarm

微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果.虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程. 本文选自<架构解密:从分布式到微服务>. 本文盘点了四种常用的微服务架构方案,分别是ZeroC IceGrid.Spring Cloud.基于消息队列与Docker Swarm. ZeroC IceGrid微服

一种云安全服务架构的设计与实现

1.研究背景 云计算是网格计算.分布式计算.并行计算.效用计算.网络存储.虚拟化.负载均衡.等传统计算机技术和网络技术发展融合的产物.借助SaaS.PaaS.IaaS.MSP 等先进的商业模式把这强大的计算能力分布到终端用户手中.云计算的核心思想,是将大量用网络连接的计算资源统一管理和调度,构成一个计算资源池向用户按需服务. 随着云计算逐渐成为未来发展的趋势,得到了当前业界乃至全社会的关注,被广泛认为是新一代信息技术变革和业务应用模式变革的核心.作为IT基础设施.信息服务的交付和使用模式及基于互

成小胖学习微服务架构·基础篇

看到最近"微服务架构"这个概念这么火,作为一个积极上进的程序猿,成小胖忍不住想要学习学习.而架构师老王(不是隔壁老王)最近刚好在做公司基础服务的微服务化研究和落地,对此深有研究. 于是成小胖马上屁颠屁颠的跑过去向老王请教:"王哥,我看微服务架构这么火,我也想学,您给我讲讲啥是微服务架构呗?" 老王笑了笑说:"要想知道什么是微服务架构,你得先知道什么系统架构设计." 成小胖的理想是成为一名架构师,平时积累了不少知识,因此对"系统架构设计&

SOA 架构中的ESB是更好的应用于异构系统集成整合还是用于统一服务调用/基础服务实施

一.讨论主题与观点       写一篇文章.发现一次自觉得有意思的SOA架构方面的讨论,源于昨天AgileEAS.NET SOA 平台群(113723486)里几个群友的一次关于ESB的一次讨论.       大家的讨论观点主要集成在:对于ESB的定义也有类观点,一类观点是把ESB定位于SOA架构之中的基础服务设施(书上都这么讲),还有一类观点就是ESB做为异构系统之间的集成和整合之间,其实ESB本身都能实现两种观点的功能,只是觉得在时下,应该更偏重于那一方面,两者的本质上最大的区别是,同一系统

一种云计算环境网络安全服务架构的设计与实现

1.研究背景 云计算是网格计算.分布式计算.并行计算.效用计算.网络存储.虚拟化.负载均衡.等传统计算机技术和网络技术发展融合的产物.借助SaaS.PaaS.IaaS.MSP 等先进的商业模式把这强大的计算能力分布到终端用户手中.云计算的核心思想,是将大量用网络连接的计算资源统一管理和调度,构成一个计算资源池向用户按需服务. 随着云计算逐渐成为未来发展的趋势,得到了当前业界乃至全社会的关注,被广泛认为是新一代信息技术变革和业务应用模式变革的核心.作为IT基础设施.信息服务的交付和使用模式及基于互

通过Ruby on Rails和docker构建微服务架构之入门教程

说到时下的架构,免不了会涉及到微服务.而谈到微服务架构,又跟容器和Docker技术脱不了关系.虽然容器和Docker并不完全是一回事,但两者是密不可分的,而且二者之间也有共同之处:在大型复杂应用的构建和运营方面,二者都可以大大提高企业的效率.   微服务可不像一般的应用,可以通过apt-get工具进行安装,大家可能会问了:我们该如何才能像安装应用一样实现这种服务呢?在很大的程度上,这个问题的答案是否定的,我们无法轻松实现这种服务.更准确的说,至少目前我们还无法实现.在一个系统中,最难修改的就是架

面向服务架构(SOA)的原则

架构 分布式计算将网络上分布的软件资源看作是各种服务.面向服务架构是一种不错的解决方案.但这种架构不是什么新思想:CORBA和DCOM就很类似,但是,这些过去的面向服务架构都受到一些难题的困扰:首先,它们是紧密耦合的,这就意味着如分布计算连接的两端都必须遵循同样API的约束.打比方说,如果一个COM对象的代码有了更改,那么访问该对象的代码也必须作出相应更改.其二,这些面向服务架构受到厂商的约束.Microsoft控制DCOM自不必说,CORBA也只是一个伪装的标准化努力,事实上,实现一个CORB

从面向服务架构(SOA)学习:微服务时代应该借鉴的5条经验教训

[编者按]本文作者为 Matt McLarty,通过介绍 SOA 的兴衰变化,总结了微服务应该借鉴的5条经验教训.文章系国内 ITOM 管理平台 OneAPM 编译呈现. SOA 的兴衰变化让我们更了解如何充分利用微服务 正如笔者在上文<微服务架构是敏捷软件架构>中提到的,笔者对微服务架构的第一反应,就是质疑它跟面向服务架构(SOA)有何区别.还有很多人将这两种架构联系在一起.詹姆斯·刘易斯和马丁·福勒在他们的权威博客中包含了一个侧边栏,进行微服务和 SOA 的对比.对此,怀疑派做出的回应是二

面向服务架构(SOA)和企业服务总线(ESB)

学习和研究在企业中实施面向服务架构(SOA),简单回顾SOA和ESB,重点关注微软在SOA领域的相关指导和.NET社区的相关开源的解决方案,和大家一起来探讨如何在企业里实现SOA,期望有实施SOA经验的同学发表意见. 一.SOA的历史      1996年,Gartner最早提出SOA.2002年12月,Gartner提出SOA是"现代应用开发领域最重要的课题",SOA并不是一个新事物,IT组织已经成功建立并实施SOA应用软件很多年了,BEA.IBM.等厂商看到了它的价值,纷纷跟进.S