前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >云计算与企业自身安全策略结合到一起

云计算与企业自身安全策略结合到一起

作者头像
静一
发布2018-03-20 15:57:56
1.2K0
发布2018-03-20 15:57:56
举报

云计算、大数据及移动化是大势所趋,也的确能大大降低企业的成本和提高企业的效率,改变企业的运营方式和思维方式,所以,很多企业在考虑向云计算迁移,但又顾虑重重,考虑最多的是安全问题。任何事物都具有两面性,云计算也不例外,但不能因噎废食,特别是在这个技术飞快发展的时代,如果不及时抓住技术的趋势,充分地利用技术,就可能在激烈的竞争中很快失去优势。那么,如果向云计算迁移,如何扬长避短呢?云计算存在哪些不安全因素呢?在向云计算迁移的过程中应该注意些什么呢?在向云计算迁移的过程中应该采取哪些安全策略呢?本文将和大家分享向云计算迁移过程中的一些安全思路和做法。供大家参考,并欢迎补充。

一、知己知彼明察秋毫俯瞰云计算不安之因素

兵家有云:知己知彼,百战不殆。企业用户在向云计算迁移前,也需要全面了解自己的需求,明察秋毫,以全局的眼光充分认识云计算的安全风险和不安全因素,做好充分的准备来应对、抵抗和消除安全风险,使自己心中有数,有备无患。下面列出了一些云计算的安全风险和不安全因素,以供企业用户了然于胸。

云服务提供商采用的安全标准不统一,这使得企业用户在选择时很迷惑。

没有经过充分了解和评估云计算服务提供商的系统环境和相关风险,就贸然采用云服务。

云计算和移动化让整个企业的安全边界就没有了,使数据分散在多个设备和云服务中,这样企业的数据存储就很混乱,面临着数据丢失和永远失去知识产权的风险。

没有选用恰当的云模式。

账户或服务流量被劫持。

分布式拒绝服务(DDoS)。

不安全的云API会带来多种风险。

SAS70标准已经不适用于高速发展的云服务,而且它最初的设计目的是监督企业遵守财务报告规则。

对于多租户云服务来说,如果数据库设计不合理,只要有一个用户的应用程序存在一个漏洞,就可以让攻击者获取这个用户的数据,甚至还能危及到其他用户。

不靠谱的云服务提供商或者不可抗拒的灾难可能导致用户的数据丢失。

为了绑定用户,云服务提供商往往不为用户提供无缝切换机制,经常用安全控制的借口拒绝为用户提供关键性数据模块,增加交接的困难。

不怀好意的内部人员破坏性地访问网络、系统或数据。

完全依赖云服务供应商的安全性,没有将云服务供应商的安全策略与企业本身的安全策略结合到一起。

没有做好监督工作。

很多企业制定了详细的云安全策略后,就将其束之高阁了,再也不去修改其内容了,这是一个非常严重的错误,往往使企业遭遇安全问题。

二、步步为营有的放矢保障云计算安全之策略

充分认识了云计算的安全风险和不安全因素之后,就可以步步为营,有针对性地逐一制定安全策略,有的放矢,保障云计算安全。下面列出了一些让云计算更安全的方法和策略。供大家参考,并欢迎补充。

在向云计算迁移之前,做好充分地准备,进行充分地调查和评估。

通过可靠的安全标准对云服务提供商进行安全评估。规模最大且参与者众多的安全标准机构是CSA(CloudSecurityAlliance),即云安全联盟。

当对云服务提供商进行评估时,如果云服务提供商能够保证一个审计标准,这样要好于只听供应商一面之词。

评估云服务提供商时,不要把重点放在SAS70认证上。

在对云服务提供商进行评估时,要对基于云的系统进行安全评估和审计,这个过程必须包括:网络和系统漏洞评估、服务器/工作站/移动设备合规性评估、云/管理程序基础设施评估。

企业用户需要确保在服务水平协议中云服务提供商有自己的业务连续性、备份和灾难恢复计划,并确保该协议涵盖恢复时间目标/恢复点目标(RTO/RPO)以及性能和带宽基线要求。

在向云计算迁移之前,企业用户需要考虑的因素有:企业用户希望迁移到云中的应用程序的关键程度、合规问题、必需的服务水平、负载的使用模式,以及应用程序与其它企业功能的集成程度。

企业需要全面调查云服务供应商的安全技术和过程,并检查云服务供应商如何保障企业数据及他们自己的基础架构的安全。企业尤其需要关注如下方面:

应用程序和数据的可移植性:供应商是否允许企业将现有的应用程序、数据和过程导出到云中?能轻松地将这些导回来吗?

数据中心的物理安全性:云服务服务供应商如何从物理上保护其数据中心?他们使用哪种类型的数据中心?他们的数据中心操作员得到过怎样的培训,有什么技能?

访问和操作的安全性:云服务供应商如何控制对物理机器的访问?谁能够访问这些机器?它们如何管理这些机器?

虚拟数据中心的安全性:云架构是效率的关键。企业应当查明独立的组件(如网络节点、存储节点等)是如何构建的,还要调查这些组件的集成和安全保障方法。

应用程序和数据的安全性:云解决方案必须支持由企业自己定义组、角色,要有精细的基于角色的访问控制,还要有正确的口令策略和数据(静态数据和传输的动态数据)加密。

通过一些问题弄清楚云服务提供商安全控制架构的具体情况,避免陷入云计算提供商们的“留客”陷阱。其中的问题包括:

企业用户发送到云服务提供商处的数据到底该归谁所有?企业用户一定要在合同中注明,由业务流程生成的所有数据在协作周期内都归用户方所有,这非常重要。

云服务提供商如何将数据返还给用户?企业用户需要在合同中明确数据应以哪类格式进行返还,而且返还的数据格式最好无论何时都能轻松使用。通过测试确保云服务供应商有能力满足合同中的约定。

企业用户能真正访问数据吗?如果数据本身经过加密,企业用户是否有权访问加密密钥?企业一定要通过测试确保自己对数据拥有访问能力。

资源访问如何处理?对于基础设施即服务(IaaS)领域,当数据成为虚拟镜像的一部分时,企业用户需要确保自己同时拥有对应用程序与底层操作系统进行管理员级访问的能力。

能否访问用户数据?如果云服务提供商打造了一套用于容纳用户信息的数据存储体系(包括用户ID、角色、权限以及身份验证信息等),企业用户自己也需要建立同样的体系,确保自己有能力将包括用户信息在内的所有备份数据重新导入服务流程,因为这部分数据很可能被单独保存在应用程序数据之外。

参考其他客户的评价和意见。

对云服务进行反复测试。

选用适当的云模式。

企业用户需要将数据恢复时间、恢复点内容以及数据完整性评估方法都列入服务水平协议中,并明确列出惩罚措施。

与云服务提供商签订的安全条款内容应尽可能详细,将防止未授权访问、安全标准年度认证以及定期的漏洞测试等内容都以明文的方式列入合同。

将云安全与企业自身的安全策略结合到一起。

在为云计算修改安全策略时,企业需要考虑的因素有:数据存储在哪里、如何保护数据、谁可以访问数据、合规问题、服务等级约定(SLA)等。

分析云API的安全性。通过云服务提供商的API文档,确定其API安全性;通过安全的渠道保护传输的安全,如SSL/TLS或IPSec;进行身份验证与授权,可以通过提问一些问题来验证,如:API可以管理用户名和密码的加密吗?可以管理双因素身份认证属性吗?可以创建并维护细粒度的授权策略吗?内部身份管理系统和属性之间具有连续性吗?以及内部身份管理系统和云提供商提供的API扩展属性之间具有连续性吗?向云服务提供商提出要求,能够对API进行渗透测试和漏洞评估。

许多云服务提供商为客户提供利用API的访问和身份验证机制的加密密钥,保护这些密钥至关重要。

企业用户必须确定数据的重要程度,并检查用于数据传输的加密工具是否成熟。

采取集中存储数据,让有权限的人可以访问它,无论员工是否离开公司。

避免将机密数据存储在云端,关键性业务数据及规则性信息最好把握在自己手中。

对静态的、使用中的和传输的数据进行加密。

企业应使用最强健的加密密钥技术,如同态密钥管理来强化密钥的安全,并保护好密钥以及做好定期的备份。

在云加密问题上,企业必须负起责任,关键是定义哪些团队应为数据的安全负责。

对于已经实施了强加密的数据来说,企业应该仅允许有工作需要的员工访问,而且要培训这些员工如何访问加密数据,可以从什么地方访问,并要求他们遵循安全规程。

IT部门需要提供简单易用的工具来替代员工使用的不安全的共享工具来操作数据。

如果企业期望基于云的应用更多地通过共有Wi-Fi热点访问,SSL加密应该能够保护整个信息流。

使用公共密钥存储服务或者技术时,要确保密钥永远不会用应用代码或者数据存储在云端。

将云存储、数据加密和网站安全手段结合起来,可以为企业防御网络威胁构建强健的安全阵线。

每年对云服务提供商提供的服务进行第三方安全审计和认证,如果出现数据泄露事故,用户有权终止云服务合同。

确定双方的安全责任。

在云服务提供商由于失误造成企业用户的安全损失后,确定云服务提供商应该承担什么责任。

云服务提供商会尽量避免在云服务合同中承担任何赔偿责任,顶多是延长服务期限,在这种情况下,企业应该将抵偿的服务期限延长到24-36个月,而不是常见的12个月。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2014-09-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 云计算D1net 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
大数据
全栈大数据产品,面向海量数据场景,帮助您 “智理无数,心中有数”!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档