企业网络如何防范云风险常见哪些云安全问题

随着多云及趋势的发展过去传統的策略显然已不适应新的云环境。尽管很多企业一直非常重视云安全问题,但其中很多风险点并没有得到实际解决大多数企业依然茬采用过去本地环境下的云安全措施,导致企业出现云安全策略不一致应用风险和漏洞增加的状况!最严重的问题是,很多私有云部署环境下的安全问题并不需要黑客高手侵入,而是缺乏安全常识!

很多安全问题都是防不胜防!即使在理想的环境下还容易出现重大安全事故,更何况你系统本身就有问题那等于是在给攻击者开了一扇门。所以为了确保云环境下的万无一失,我们除了在云安全措施上下功夫还要在安全常识问题上,提高警惕!

首先不要忽略“僵尸负载”。

很多企业往往会忽略在系统架构上运行着的僵尸负载尤其是在企业應用峰值期,一旦遇到严重的安全问题会首先把“僵尸负载”排除在外,不予理会

实际上,很多别有用心的人就是利用僵尸资源来窃取密码尽管僵尸工作负载并不重要,但是它构建于企业整体基础设施之上一旦疏于管理,会更容易遭遇入侵SkyBoxSecurity 2018年的一份报告显示,密碼劫持是主要的一种网络攻击手段DevOps团队要像托管加密货币一样,要确保应用资源不受威胁并采用有效的安全防范手段,来阻止一切恶意行为

其次,对AWS S3 Buckets的泄露问题要足够重视。

AWS尤其是 S3 Buckets是年头最长的云本地服务之一,还保持着过去的安全防护方式和规则因此成为勒索软件攻击的主要目标。有统计数据显示7%的 Amazon S3 bucket 都未做公开访问的限制,35%的 bucket 都未做加密这意味着整个 Amazon S3 服务器中都普遍存在这样的问题。

恶意参与者不仅可以通过S3 bucket访问企业的敏感客户数据而且还可以访问云凭据。很多具有灾难性的数据泄漏都是由于访问了不受限制的S3 bucket造成嘚,因此要定期检查AWS平台上的存储字段是非常重要的一项工作

其三,系统更新最好不要绕过CI/CD管道

每个DevSecOps团队都有一个惯性思维,认为系統程序更新时要通过CI/CD管道传递这样的系统部署才更加安全,但这并不意味着每次运行都要强制执行这一策略加快部署速度,避免出现咹全问题开放人员往往通过使用开放源码库的形式绕过CI/CD管道。

虽然这种方式为开发人员节省了系统发布和更新时间但却给安全团队带來了更大的负担,他们必须对异常工作负载进行额外扫描长期下去,开发团队会认为安全团队没有办法阻止未授权的工作负载只是简單地接受和执行。最终系统的安全状况会逐渐恶化,以至于恶意入侵者可以在不引起注意的情况下运行有害的工作负载但是到那时才發现,一切为时已晚

其四,网络访问要设限

许多DevOps团队并没有花费大量的时间,用在分段和单独的访问权限上而是依赖于一套完整的網络配置,同时这些配置远远不能满足必要的访问限制他们通常将所有的工作负载都放在一个单独的VPC中,这样就可以通过第三方流程访問

没有对公网访问设限,安全团队要想识别和隔离恶意行为要花很长时间。即使在短时间内DevSecOps团队发现了一些严重的漏洞,也无法在咹全配置文件中及时处理安全漏洞!

其五使用微服务时,规则设置要正确

当DevOps团队在容器中使用微服务时会面临更大挑战,分得越细意菋着你就越有可能出现错误的规则设置。

即使是最熟悉的规则和集群也会因疏忽产生大量漏洞。例如如果允许开发人员使用特定的IP通過SSH远程连接到生产环境时,就可能会在不知情的情况下允许敏感区域接入无限制公网访问。有时这些错误的规则配置会被忽略长达数朤之久。为了避免错误规则支持使用Amazon Inspector的Agentless进行监控,或则采用其他网络评估工具进行定期审计,非常必要

【凡本网注明来源非中国IDC圈嘚作品,均转载自其它媒体目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责】

  【IT168 安全】围绕云计算的喧嚣鈳能会让你以为明天就会发生大规模采纳云计算的事情。然而来自多方面的研究已经表明,安全是阻碍大规模采纳云计算的最大障碍现实的情况是,云计算不过是沿着主机、客户机/服务器和Web应用等技术演变路径自然而然的又一阶段而已所以它也和其他所有阶段一样,都有它自己的安全问题

  当然,对安全的担忧并不能阻止对这些技术的使用也不能阻止对于能够解决实际业务需求的云应用的采納。为了确保云是安全的需要将其作为技术的下一步进化来对待,而不是将其视为一次需要彻底改变安全模式的革命安全的策略和程序需要针对云模式进行调整,以便对云服务的采用做好准备和其他的技术一样,我们看 到一些早期用户通过带头部署私有云或者在公用雲中试验一些非关键性的应用而逐步打消了人们对于云模式的不信任

  企业和组织会询问很多问题,并权衡使用云计算解决方案的利與弊安全性、可用性和可管理性都是需要考虑的因素。本文所说的是组织应该考虑的10个和安全相关的问题回答这些问题有助于企业和組织能够对是否需要部署云作出决定,而且如果需要部署的话,究竟应该采用哪种云模式——私有云、公用云还是混合云?

  1.云部署会洳何改变企业的风险管理?

  部署云计算——无论是私有云还是公用云——都意味着你不再能够完全控制环境、数据或者人员控制上的變化会带来风险管理上的变化——在某些情况下风险会增加,而在另一些情况下风险可能会降低某些云应用对你来说会完全透明,而且能提供高级报表功能并且能够与企业现有的系统进行集成。此类应用会降低企业的风险而另外一些云应用或许无法改进其安全配置,無法与企业现有的安全措施相匹配因此有可能使安全风险变大。总而言之企业的数据及其敏感级别将会最终决定应采取哪类云模式才昰合理的。

  2.需要做些什么才能确保现有的安全策略能够接纳云模式?

  向云模式的迁移是改进企业整体安全状况和安全策略的一个机會云应用的早期用户将会发挥影响作用,帮助推动由云提供商实施的安全模式企业不必为了云而去创 建新的安全策略,而是应该扩展現有的安全策略去容纳新增加的云平台为了部署云而去修改安全策略,需要考虑的其实是一些和以前一样的因素:数据存放在哪儿如哬保护数据,谁能够访问数据遵从哪些监管条例,以及服务等级协议等等

  3.云部署会损害企业的法规遵从能力吗?

  云部署会改变企业的风险状况,因而可能会影响到企业适应各种法规遵从的能力这就要求在合规性需要与云部署相关联时,需要重新评估合规性需要有些云应用有很强的报表功能,可加以剪裁以适应特殊的合规性需要而有些应用比较通用,不太可能或者不能适应详细的合规性需要举例说,如果某个国家的法规规定企业的数据不得存放在国境之外,然而有些云提供商由于其数据中心的位置有可能无法满足这一法規的规定

  4. 云提供商是否在使用某种安全标准(SAML、WS-Trust、ISO或其他)?

  在云计算中,标准发挥着非常重要的作用因为各种云服务之间的互操莋性对于确保云不会陷入专利的安全孤岛来说是至关重要的。有不少的组织已经创建并扩展了支持云的各种标准倡议Cloud-standards.Org列出了和云计算有關的大多数标准组织,其中也有和云安全标准相关的组织

  5. 如果发生数据泄漏该如何处理?

  当企业在规划云安全时,必须要正确地淛定好防止数据泄漏和数据损失的规划这一点在企业与云服务提供商签署整体协议时是至关重要的一点。云提供商和企业双方都应该制萣数据泄漏告知政策或者必须遵从的监管规则企业必须敦促云提供商在一旦有需要时能够支持企业的告知需要。

  6. 在保障企业数据的咹全时谁是责任方?或者谁应被视为责任主体?

  在实际情况中,安全责任将是双方共担的然而在公众舆论的法庭看来(至少今天是如此),是企业而不是云提供商负责收集数据因此只有企业应被视为信息安全的最终责任人。如果企业与云提供商之间的协议签的滴水不漏戓许企业可以少负些责任,和云提供商责任共担但是从企业客户的角度来看,企业仍然会被认为是最终责任人

  7. 如何保证只有适当嘚数据存入云中?

  企业必须清楚哪些数据时敏感数据,依据数据和应用的关键与否来构建适当的安全模式这对于了解哪些数据可以存叺云中是非常重要的。这个过程应在考虑云部署之前很久就开始着手因为这是良好的安全行为的关键部分。很多企业使用数据泄漏防范技术来分类和标记数据

  8. 如何保证只有经过授权的员工、合作伙伴和客户才能访问数据与应用?

  身份管理和访问管理是早已存在的咹全挑战,这种挑战在云部署中会被放大一些技术性功能如联邦制、安全虚拟化系统和预配置等都在云安全中发挥着作用,就像它们在紟天的IT平台上发挥的作用一样扩展并补充企业的现有环境去支持云部署,将有助于解决这一问题

  9. 如何托管企业的数据与应用,怎樣的安全技术才是适当的?

  云提供商应当提供这方面的信息因为它会直接影响到一个组织遵从法规的能力。透明是重要和必须的因為这可以让企业基于对情况的了解而做出决策。

  10. 企业可通过哪些因素去了解和信任云提供商?

  在评估一家云提供商的信任等级时囿很多的因素可以考虑。这其中有很多因素和企业在考虑外包合同时所考虑的因素是相通的比如:提供商及其服务是否成熟;合同的类别,SLA、漏洞程序和安全策略;提供商的业绩记录;是否具有前瞻性的战略等等

  向一种新的计算平台的迁移绝非一件不加慎重考虑便能做决萣的事情。对这些问题的答案是复杂的通常还会引出更多的问题。本文也只是触及了再考虑云平台时的一些有关安全的浅层次问题而已

  另外,企业还应当了解到他们有能力去推动云中所用的安全技术的发展。应当明了云的消费者可以、应该,并且会期待着他们負起安全责任来从而使云成为一个真正能够节约成本,提高生产率的安全的平台

我要回帖

 

随机推荐