发布在即!企业 AIGC 应用程度测评,3 步定制专属评估报告。抢首批测评权益>>> 了解详情
写点什么

从 CIO 视角出发审视云环境下的安全议题

  • 2015-06-03
  • 本文字数:3730 字

    阅读完需:约 12 分钟

“很多人都在过度强调安全而非机遇,这就像是一个人更害怕生存而非死亡。”

- James F. Bymes

安全如今已经成为一个广泛的议题,并且渗透到了 IT 事务中的方方面面。纵观我在技术业界打拼的这么多个年头,我发现“安全”已经成了一个能够迅速扼杀任何创新型努力的词汇。在云计算发展的早期阶段,那些对云技术了解不深的人们总会就其安全性水平问东问西。相较于更为重要的、如何利用这项新技术帮助企业自身实现商业价值,他们往往首先把安全性作为技术演进的最大障碍。举例为说,2012 年我就开始利用 AWS 支持企业级项目,当时我所能依靠的只有自己的同事、团队以及他们所拥有的解决问题的经验。然而我们的研究结果大大坚定了自己的信心,事实上 AWS 为我们提供了一种远优于孤军奋战的系统安全保护途径。

作为一位前任 CIO 兼 AWS 客户,下面我将结合自身经历聊聊自己眼中的云环境安全性问题:

我知道,安全性目前是、未来也将继续是 AWS 所关注的核心议题之一。因为只有这样,AWS 才能为来自众多行业及政府机构的如此广泛且多样化的客户提供服务。我们拥有 PCI 系统、PII 数据、SOX 要求以及需要保护的知识产权信息。在了解到其它企业有能力在云环境下开发出足以顺利满足上述控制框架要求的、令人满意的解决方案之后,我们既受到启发、又对云技术的未来充满信心。

可以确定的是,AWS 方面投入了大量资源进行其服务平台的保护工作,相关资源总量远远超过我们用于运营支持的资源总和——而这还仅仅是在安全层面。与其它运行着自有数据中心的企业类似,我们也一直不断对成本、上市时间、质量以及安全性作出权衡。在这方面作出决策绝非易事,而且我们往往很难弄清自己是否做出了正确的选择。没能认真评估防火墙变更、线缆配置错误或者过于躁进地进行操作系统配置有可能影响我们的安全水平。如果大家在企业环境中拥有长期工作经历,我相信各位绝对能明白这两者之间的联系。光是想想单纯因为我们自身因素而造成的安全风险,就已经足够把我们吓得魂不附体。而且如果把安全性当成企业运营中的头等大事,大家几乎没办法继续完成其它业务工作。

我知道,缩小受攻击面能够让我们将精力集中在自身的差异化特性当中。充分运用 AWS 所提供的安全机制能够帮助我们将一部分原本用于实施裸机保护的资源解放出来,转而用于保护应用程序。已知安全漏洞的逐步增加以及黑帽社区的日益壮大意味着我们必须进一步强化针对托管基础设施的应用程序安全保护力度。在 AWS 的帮助下,我们能够在增添新型资源的同时、又不至于让其它方面的配额过于捉襟见肘,这样一来我们对于安全保障工作的心态也更加平和。当然,这种共同分担的责任模式并不代表客户方面可以完全卸下包袱,但由此带来的助益却是不容否定的。至少就个人而言,我是乐于运用一切可资利用的帮助。

根据我掌握的情况,AWS 在全球安全发展前景方面的前瞻性要远远强于我们这单位一家企业的水平。我当然也希望能够充分享受由此带来的规模经济收益。事实上,我们也希望能够将 AWS 服务改进所带来的收益分享给自己的每一位客户。

在我看来,自动化机制能够大大降低出现人为错误的可能性,而且这一点在安全性以及应用程序开发领域也同样适用。我们希望尽可能多地将自动化方案引入那些需要反复进行的技术任务。根据我了解到的情况,AWS 高度依赖于自动化技术以实现规模化提升,同时降低人为错误的发生空间,并借此改进自己的安全性模型。能够拥有这样一位出色的合作伙伴,将鼓励并引导我们同样利用自动化手段实现收益增长。

CIO & LEADER 网站最近采访了 AWS CISO Stephen Schmidt,并就一系列安全议题展开探讨。在此次采访中,Stephen 谈到了 AWS 在安全性领域所采取的规模化、投资以及自动化机制等举措。我认为此次采访进一步增强了自己的信心,并坚定了我建议合作伙伴采用或者考虑采用 AWS 的决心。本次采访内容发布在 2014 年 12 月的 CIO & LEADER 实体杂志当中,以下转述内容全部得到了 CIO & LEADER 网站的授权。

CIO & LEADER: 大多数企业信息安全负责人都没能成功顶住 DDoS 以及 APT 等下一代安全威胁带来的压力。您面临的此类安全威胁是否更大?您又是如何加以化解的?

Stephen Schmidt:我们见证着一切在互联网上的发生。我希望分享一些有趣的数据来给大家提供更为直观的量化印象。在每 500 个 IP 地址当中,就有 1 个通过互联网被路由至 Amazon 网络当中,而且 700 个 IP 地址当中约有 1 个被映射至 EC2 实例处。大家可以把我们看作一套规模极为庞大的望远镜阵列,旨在发现一个极小的目标。这套设施允许我们识别出针对客户的安全威胁,并建立起自己的服务以帮助这些客户抵御此类威胁。举例来说,很多 APT 攻击者试图收集大量合法的用户名与密码内容。正是出于这个理由,我们不允许在网络中传输的用户名与密码中包含客户数据。我们还推出了多种智能验证令牌,这是因为利用物理设备进行验证更为安全、而且其更难被攻击者们所盗取。

CIO & LEADER: 第三方风险同样受到安全从业人员的高度关注。作为一名 CISO,您如何处理这些风险呢?

Schmidt:为了最大程度降低此类风险,最重要的是确保我们的各合作第三方与我们遵循同样的安全标准。我们需要严格确保此类规则贯彻到位,并通过审计实现约束。举例来说,如果我们在某国建立了一套 CloudFront 主机代管设施,那么我们就要求该代管服务供应商提供与自身完全等同的安全水平。这部分内容在双方合作协议当中明确标定,而且我们会定期对其进行检查。

因此,我一个专项团队,其任务在于每年多次到访世界各地的每一座代管设施。我们采取突击检查的管理方式,以确保合作方能够根据既定规则完成自己的份内任务。我们的要求非常严格,而且在检查过程中要求对方员工全部撤离现场。举例来说,他们是否使用经过认证的固定件、螺钉或者螺母,这样我们才能保证自己无法从外部将其拧下。我们还会检查墙上的检修孔尺寸,确保其符合规定的规格要求,这样恶意人士就无法将手伸入实施破坏。我们也在检查中确保所有延伸出设施的线缆都包裹有保温导管。凭借着这一系列标准,我们才能通过检查来确保供应商满足我们的所有特殊要求。

CIO & LEADER: 看起来 AWS 确实拥有一套可靠的第三方风险应对策略。但您如何应对来自企业内部的安全威胁?

Schmidt:应对内部威胁的最佳途径就是限制指向数据的人为访问。因此,我们在内部采取的措施之一在于主动降低有能力访问信息的人员数量。

尽管如此,我们的业界规模一直处于疯狂增长当中,我们每一周都需要削减能够访问客户信息的内部员工数量。我们能够以自动化方式实现这一调整工作。举例来说,如果某人需要多次——超过一次或两次——重复同样的工作,那么我们就会将其纳入自动化流程。我们会有针对性地建立起一套能够自动完成该项任务的工具。此类方案拥有两大优势。首先,工具基本不会犯错,它们不仅能够顺利完成任务、而且可以保证每次都同样顺利完成任务。相比之下,员工则可能带来多种意外因素,并因此造成问题。其次,工具能够显著提高可用性。因此,自动化对安全性及可用性的贡献确实值得肯定。

CIO & LEADER: 那么,AWS 在 2015 年中设定了怎样的发展方向?贵公司将关注哪些技术成果及解决方案?

Schmidt:对 AWS 而言,我们下一步将高度关注的就是加密机制。加密机制将无处不在,也就是说加密技术将覆盖到每一个领域。我们的工程技术人员将高度重视的另一个领域在于向客户提供针对加密机制的控制能力,这样他们就能实现密钥内容管理。第三则是确保我们为客户提供一系列工具,帮助他们做出更理想的安全性决策。

过去供应商往往会告知客户,一旦有问题出现,他们将很快到场并加以修复。但在 AWS,我们选择了完全不同的解决思路。相比之下,AWS 给出的方案是:目前的这种状况还有提升的空间,而这里的这个按钮能够切实带来提升或者修正。总结来讲,我们为客户提供他们所需要的工具,此类工具成本极低甚至完全免费,这样他们完全可以自行解决问题。

CIO & LEADER: 那么作为一位 CISO,您下一步打算在哪些领域投入资金?

Schmidt:我们在自动化技术领域投入了大量资源,因此我们打造的主要成果之一就是工具。而我们还将大量自动化要素引入常见的安全测试、渗透测试以及配置管理测试等日常事务当中,旨在确保一切以计划中的方式顺畅运转。在这些领域,我们每一年都会投入大量资金。

采取上述举措的原因有二,其一当然在于安全效益,其二则单纯是因为我们无法在不借助自动化机制的情况下运营如此庞大的设施体系。随着规模的不断提升,如果我无法快速推广自动化机制,我们根本不可能雇佣到那么多水平出色的安全工程师来保护全部 AWS 服务。我们投入了大量资源以实现自动化技术。

为企业创建安全系统是每一位 IT 高管人士的核心信条。为什么不使用目前市面上最出色的工具来实现同样的效果?大多数专业的安全从业者都会告诉大家,这一切都取决于客户所具备的实际设备。出色的方案并不足以替代人才、实践以及艰苦的工作,但如果采用更强大的设备则能够带来良好的性能表现,并吸引客户加以使用。云服务虽然无法取代业务系统中的杰出人才、专业知识以及管理机制,但确实能够显著提高企业获得成功的可能性。

革命尚未成功,同志仍需努力。

原文链接: https://medium.com/aws-enterprise-collection/a-cio-perspective-on-security-in-the-cloud-5dd73db8a702

2015-06-03 06:411145

评论

发布
暂无评论
发现更多内容

微信朋友圈的高性能复杂度

Geek_16d2b8

#架构训练营

最全总结 | Android 系统抓包喂饭教程!

星安果

android 抓包

Web Components系列(七) ——自定义组件的生命周期

编程三昧

前端 组件化 2月月更 WebComponent

六年安卓开发的技术回顾和展望 | 社区征文

拭心

android 程序员人生 shixinzhang 新春征文 2月月更

Linux系统编程-进程创建(fork)、外部程序调用(exec)

DS小龙哥

进程 fork 2月月更

架构学习【02】——朋友圈高性能复杂度分析

tiger

架构实战营

微信朋友圈高性能架构设计

五月雨

架构实战营 「架构实战营」

微信朋友圈高性能复杂度分析

Bear

「架构实战营」

使用 Cilium 增强 Kubernetes 网络安全

张晓辉

Kubernetes 云原生 ebpf cilium

微信朋友圈架构设计

卡西毛豆静爸

架构实战营

微信朋友圈复杂度分析&架构设计

AragornYang

架构训练营 架构实战营

微信朋友圈的高性能复杂度分析

Leo

架构实战营

国内外最顶级的十大敏捷项目开发管理工具盘点

PingCode

Linux系统编程-进程概念、进程管理、信号处理

DS小龙哥

2月月更

「架构实战营」模块二作业 朋友圈复杂度

hxb

「架构实战营」

微信朋友圈的高性能复杂度分析

石小天

架构实战营

计算机毕业设计安卓疫苗预约APP源码,后台java springboot

清风

安卓 计算机毕业设计

微信朋友圈高性能复杂度分析

浪飞

几种数据库存储引擎比较

乌龟哥哥

:MySQL 数据库 2月月更

微信朋友圈复杂度分析与设计

刘帅

微信朋友圈架构设计

随欣所遇

#架构训练营 架构训练营5期

[架构实战营]-朋友圈的高性能架构设计

邹玉麒

「架构实战营」

微信朋友圈的高性能复杂度分析

凌波微步

「架构实战营」

《MySQL入门很轻松》第3章:数据库的创建与操作

乌龟哥哥

:MySQL 数据库 2月月更

WebRTC 如何在安卓系统上采集音频数据 | 社区征文

liuzhen007

音视频 WebRTC 新春征文 2月月更

如何用 Python 实现一个单链表

宇宙之一粟

Python 数据结构 单向链表 2月月更

架构实战营模块九作业

spark99

架构实战营

从冬奥看中国科技(二):造雪突围进行时

脑极体

人工智能在客户关系管理软件销售和服务模块中的应用 | 社区征文

Jerry Wang

人工智能 机器学习 SaaS 新春征文 2月月更

作业2朋友圈高性能复杂度

Geek_28cf33

Linux系统编程-Shell脚本基本使用(数组、函数、字符串处理)

DS小龙哥

Shell 2月月更

从CIO视角出发审视云环境下的安全议题_安全_Stephen Orban_InfoQ精选文章