切莫忽视SaaS云应用安全性

在2014年11月,应用安全服务供应商Adallom发布了一份名为“云使用风险报告”的研究报告,文中列举了在过去几年中Adallom从其用户那里收集到的云特有风险和安全性问题。大量有趣的统计数据表明有很多企业未能正确实施和管理云供应商的安全控制措施,其中重灾区在软件即服务(SaaS)。在该报告中还有一些更为有趣的数据:

  • 大部分企业并没有妥善管理SaaS应用的用户账户。在2013年至2014年之间,11%的企业SaaS账户都是“僵尸账户”——也就是说这些账户目前都没有与之相关的正常用户。此外,Adallom发现80%的企业都至少有一个僵尸账户未被禁用——通常这个账户属于一个前员工。
  • 最小权限的概念在云中并不适用。Adallom表示在很多账户中有很多的管理员,大约一百个账户中有7个是管理员。
  • 19%的云应用用户在可能的情况下都绕过了身份验证和访问管理的控制措施。
  • 企业私有文件中的5%实际上都可以从不同云应用环境公开访问,这表明企业缺少在云中实施访问控制。
  • 29%的员工使用他们的个人电子邮件账户来分享云应用文件。
  • 公司的平均共享信息为393个外部域。

这些统计数据反映出了很多的问题。首先,这些数字意味着安全团队可能在SaaS环境中并没有花很大精力用于配置、监控和管理数据与用户账户的信息。很多安全专家都把精力集中在关注云供应商整体控制能力上,以及那些可以被移植到PaaS和IaaS环境中的第三方或内部工具。他们很多人都在一个或多个方面忽视了SaaS安全性问题。其次,这些数据有力地表明,云中亚健康IT的规模和严重程度都在不断增加,即在较长时间内数据与用户账户无人问津或无人管理。

制定一个云应用安全性策略

那么,企业应当采取哪些措施来应对这些SaaS环境中的安全性问题呢?在开始着手之前,安全团队需要确定云应用安全策略到位,它为特定数据类型和敏感层次明确了控制要求。这应当与云风险评估过程紧密结合起来,后者主要对所提议的项目进行安全控制状态评估和候选供应商能力评估。除了供应商的一般安全状况以外,对于SaaS环境还需特别注意其他几个关键点。

首先,企业应找出供应商提供了哪些类型的身份验证和访问管理集成方法。例如一家与内部LDAP存储(如Active Directory)进行本地集成、支持针对身份数据交换和更新的SAML、以及为身份管理提供大量API的供应商将有可能更多地为安全团队提供更多功能,因为后者随着时间的推移希望能够提高对用户身份的管理能力。

然后,企业必须确定供应商是否支持数据生命周期控制,即非活跃用户账户将自动暂停或者短期用户可以拥有一个来自于实例的生命周期。

安全团队还必须找出可用于保护对保存在SaaS环境中数据访问的加密类型和访问控制选项。对于加密产品,他们应确定密钥的保存位置及其控制密钥的责任人。

此外,对管理控制台和参数显示面板的管理控制也是很关键的。在理想情况下,SaaS供应商对控制台及其功能提供了基于角色的访问,另外还包括证书、令牌以及集成现有企业控制与工具的其他方法在内的多重访问控制方法。

最后,企业需要确定是否能够得到SaaS环境中所有的活动日志,获得的频率以及日志的格式。是否有直接日志可用?如果没有,是否可以使用API来访问日志数据,或者脚本程序和自动化工具呢?一家企业获得的日志和事件数据越多,它就能把数据与SIEM结合得越好,日志管理平台也就能够分析在SaaS环境中的用户行为。

SaaS安全控制的重要性

在过去几年中,SaaS安全性并没有像PaaS和IaaS安全性那样表现得那么重要。但是,随着越来越多的敏感数据被保存在众多SaaS环境中,我们无法再容忍开放权限模式、亚健康账户或僵尸账户,或者将导致重大安全问题的过度权限分配。企业应当对他们目前正在使用的SaaS环境重视起来,评估其安全控制措施、用户当前状态、以及在SaaS中所保存的数据,并为在未来的任何SaaS实施计划做好准备。

本文作者:佚名

来源:51CTO

时间: 2024-09-24 04:38:07

切莫忽视SaaS云应用安全性的相关文章

Saas云应用趋势及企业网盘选型建议

不论你的公司是新兴的Saas云应用产品消费者中的一员,还是选择了自己部署IT系统的老牌大型企业,你都应该了解如今在Saas领域兴起的几个趋势,以及在企业内部部署Saas服务的诸多建议. 未来的云计算服务,Saas形态将占大头 Cisco最近做了一项调查研究显示,接近83%的企业正在积极寻求与云计算管理服务提供商(诸如Amazon.Microsoft)合作,来将企业目前的业务都搬上云端. 其原因是:传统的.依赖于纸质材料和书面说明的办公方式让企业内部的信息通道堵塞,看不到员工日常都在使用什么软件来

使用PaaS实现更好的云应用安全性

如今,最流行的云计算模式就是基础设施即服务(IaaS),但是它并不总是云应用安全的最佳模式.很多用户都知道平台即服务(PaaS)和软件即服务(SaaS)可以实现较好的成本节约,尤其对于那些无法访问高技能云计算技术资源的用户来说,更是如此.大多数人都不知道,PaaS尤其能够提供更高的安全性,甚至对于那些熟练用户来说,这也是一个具有决定性意义的好处.为了从PaaS安全性中获得更多的好处,我们应了解IaaS和 PaaS之间的基本安全性差异,并选择具有良好安全意识的PaaS供应商,开发应用程序以求实现P

如何聪明地选择SaaS云服务商

只要进行IT系统和应用的更新,就能够轻松地运营企业或开始数字化转型吗?哪些才是真正追求数字化转型的企业需要提前规划的重点呢?导入云端服务标志着数字化转型的开启,但不同的云服务商在提升企业经营水平上是有差异的,那么,该选择怎样的服务商呢? 一.中日SaaS云服务商的差异 服务能力的差异化 如果将云端业务完全委托给服务商会怎样?新的想法和应用是日本服务商经常打的招牌,通过网络调查,日本有各式各样形态和规模的SaaS云服务商声称"交给我,全部解决".而中国SaaS服务商提供的诸如金万维异速联

企业混合云的安全性浅析

首先是公共云,在公共云中云服务是通过公共互联网提供的.其次是私有云,其基础设施是专为单一组织的专一性使用而设计的,同时通常也是由该组织对基础设施进行托管和管理.社区云则是为一组用户的专一使用而配置的,这些用户拥有共同的商业利益和运营问题(例如安全性或合规性要求等). 最后,就是混合云了,根据国家标准和技术研究院(NIST)SP 800-145中的定义,混合云是"两个或两个以上保持各自实体独立性的不同云基础设施(私有云.社区云或公共云)形成的一个组合,该组合采用的标准或专用技术可实现数据和应用程序

我国SaaS云服务模式的构架、问题与对策研究

我国SaaS云服务模式的构架.问题与对策研究 张向阳 钟新波 基于云计算技术的SaaS云服务模式已经成为互联网各类创新应用的重要提供方式,但商业数据安全.运营管理.功能集成及管理创新等问题深远影响其广泛应用.针对SaaS云服务模式的构架.障碍等问题进行分析,并提出制定云安全标准.建立云信用体系.提高云功能集成等对策与建议. 我国SaaS云服务模式的构架.问题与对策研究

崭露头角SaaS云客服,未来可期但难点也不少

就在移动浪潮铺天盖地席卷了C端市场后,企业级软件市场也从传统PC时代装机卖软件模式过渡到SaaS模式.最近几年,中国SaaS市场以30%的年复合增长率保持着高速增长,企业级SaaS服务的风口正在积聚力量,快速渗透企业办公服务所涉及的市场.销售.客服.沟通.财务.采购.HR等各个层面. 作为其中垂直细分市场,SaaS客服也已全面打开,但当巨头涌入行业竞争加剧进入短刀相拼时期,决胜力量又是什么? 我国SaaS智能客服市场的发展除了人力成本的上升.移动互联网技术的普及和移动社交场景的涌现以及自然语言处

改善云迁移安全性最有效的三种方法

对于企业来讲,将IT系统迁移至云端进行交付是一种行业趋势.为什么会出现云端迁移这一趋势呢?成本效益和业务便捷是驱动企业CIO采取云端迁移的主要动力.目前,大部分现代企业已经开始着手向公有云迁移. 在云迁移过程中,从基础设施的部署到云托管平台的跳转,比如法规.数据治理.账单和成本管理,都是十分具有挑战性的.因此,在迁移过程中,公司CIO首要考虑的任务之一就是:尽量减少迁移风险. LinkedIn信息安全社区的一项调查显示,49%的CIO和企业认为,影响他们采用云计算的主要原因之一是担心数据的丢失和

如何确保混合云的安全性和性能?

部署只是混合云实施的一半工作.用户应如何确保他们的混合云环境是安全的并保持高性能运行的? 在零售业巨头Home Depot and Target发生了重大数据泄漏事件之后,云安全已成为了所有企业最为关注的问题.虽然云无须直接为这些数据泄漏事件担责,但是确保混合云中敏感数据的安全性是非常重要的一项工作,尤其这些敏感数据还是在公共云中被存储和处理的.安全漏洞将有损企业形象,造成客户流失并导致一系列显著的恶果,所以应当未雨绸缪在进行混合云规划过程中就重视安全性问题,而不是在出现漏洞之后才亡羊补牢,这一

SaaS云迁移计划的完整制定

应用迁移作为云计算的一个应用,一直是其问题之一,由于竞争性的市场变化能够创造新的"最佳选择",同时还能让提供商出局.导致大多数用户认为基础架构是蛮容易迁移的,不仅如此,大部分人还觉得平台即服务的迁移取决于所使用的应用性能. 由于SaaS应用属于提供商,无法迁移软件,因此服务通常不是迁移问题考虑的服务.不过迁移计划有助于用户处理价格和业务稳定性问题,甚至能够帮助用户还想把相同的应用,从一项SaaS服务迁移回自托管版本中. 第三方应用和SaaS优势 软件即服务(SaaS)应用基于提供商自己