摘要: 今年RSA 2016美国的主题是“Connect to Protect” ，这是一个内涵过于丰富以至于有些隐晦的话题。RSA总裁Amit Yoran在他名为“The Sleeper Awakes”的Keynotes演讲里也没有把这个主题讲清楚——取而代之的...
今年RSA 2016美国的主题是“Connect to Protect” ，这是一个内涵过于丰富以至于有些隐晦的话题。RSA总裁Amit Yoran在他名为“The Sleeper Awakes”的Keynotes演讲里也没有把这个主题讲清楚——取而代之的却是大谈“Change”。这让笔者惊诧于是不是穿越回到了2015年。
不管怎样，笔者仍旧感叹今年RSA大会上异常丰富的议题内容，作为一名来自阿里云的安全从业者，可谓收获满满。接下来，我和大家分享一下在本次RSA大会上在云安全领域的一些收获。
集中管控和可视化是云安全最基础和最重要的能力
诚然，集中管控（Centralized Management）和可视化（visibility）都不是新名词了，但是却是云计算环境下压倒一切的基本安全能力。
我们知道，在云计算下，资源是分散的（decentralized），数据是分散的，脆弱性和威胁也是分散的，特别是在企业采用混合云部署后会加剧这种分散的状态。然而，最终对安全风险的管理必须终止这种分散的状态。因此，云安全首先需要解决的问题就是如何在一个everything decentralized的环境下实现风险的centralized管理和控制。
可视化与集中管控是相辅相成的。可视化是解决用户对威胁风险的感知问题——如果看都看不到，谈应对和防御就是多余的。在2015年风生水起的云盾态势感知服务可解决的诸多问题中，最为关键的一个就是应对可视化的挑战。对于可视化来说，关键能力在于对安全（大）数据（包括威胁情报）的广泛的收集和分析（通过机器学习），以及最终在多个维度上详细展示，包括可回溯的时间轴、路径、行为以及集中化的策略管理和执行。
在本次RSA大会上大放异彩的云访问安全代理（CASB）和安全自动化（Security Automation），其实本质上都是建立在解决了集中管控和可视化这两个关键问题的基础之上。关于CASB和安全自动化会在后面的文章中详细阐述。
无论对于CASB服务的提供商还是用户，首先要明确使用场景。
CASB是云访问安全代理（Cloud Access Security Broker）的缩写，是本次RSA大会在云安全领域在最重要的亮点之一。无论是Gartner，还是CSA（云安全联盟），都在大会上力推CASB。经过4年的摸索和不断完善，CASB终被市场所接受，成为当下云安全领域最耀眼的明星。2016年将是CASB大规模部署的元年。关于何为CASB，本文不再赘述。对其概念仍旧不太清楚的同学可以自行Google。
从产品定位角度上讲，CASB主要是定位在PaaS和SaaS层的云安全解决方案（当然也可以在IaaS的安全运维场景下使用），解决企业用户访问云端应用时，在统一登录、身份和访问管理、数据安全、威胁防御提及安全合规上的管理挑战。Gartner对于CASB的部署示意如下：
来源：Technology Overview for Cloud Access Security Broker ,Gartner
风险的可视化和集中管控是CASB的目标，代理机制使得上述目标成为可能。通过代理（往往是反向代理），CASB可以对企业的所有云端访问进行监控，特别对于混合云下的跨云、跨平台以及本地－云端的混合部署场景尤其具有意义。
看上去无所不能的CASB，在实际部署／使用时必须要明确CASB的关键业务场景，即CASB在什么场景下解决什么问题。其次，是服务的聚焦，对于SSO/IAM，或是DLP／加密，或是威胁检测与防御，再或是合规，都有其特定的使用场景。最后，是CASB业务的交付模式，是正向还是反向，是代理模式，还是API模式。对于云安全服务商来说，还要明确与SaaS／ISV的合作和风险规避问题。
安全自动化和DevSecOps对于云安全的重大意义
作为本届RSA的重头戏之一的创新沙盘大赛（Innovation Sandbox）的获胜者——Phantom，是一家致力于安全自动化的新创企业。
虽然安全自动化也不是一个新概念，但是在云计算的环境下赋予了新的价值。安全自动化解决了云产品／应用部署后，在运营阶段面对海量系统的安全威胁缺乏快速、甚至自动化发现和防护能力的问题。
安全自动化系统是一个风险集中管控的平台，核心是可周期运行脚本代码。用户需要首先通过脚本基于不同需求和不同场景建立template，template可以被持续地运行与当前实际环境（run-time）进行比对，如发现不匹配的情况，则基于预先设定好的策略进行自动化的处置（automatic enforcement），从而形成“检测－响应－防护”的自动化闭环。在上图Phantom的逻辑图中，从Malware的发现（基于SIEM、OS、VM建立的Template——Phantom Playbook）到实际的阻断都是自动化进行的。
说到这里，事情变得有趣了——如果安全自动化可以解决部署到运营的Gap，是否可以将这个自动化的过程再提前呢？是否可以介入到开发的环节中去呢？答案是肯定的，这就引出来安全自动化的核心理念——Security as Code（安全即代码）。与此同时，Security as Code正是DevSecOps的最佳实践。
云安全一个重要的发展趋势是云应用全生命周期的自动化安全解决方案，即从云应用的开发、测试、部署、运营和防御的完整生命周期的自动化安全解决方案。DevSecOps解决的是安全与开发、测试、部署和运营脱节的问题，保证安全在云应用的开发时即介入，结合红队（Red Team）的定期测试，最终目的是上线后即具有天然的安全免疫能力（immune system）以及自动化的闭环安全运营。
无论是Security as Code还是DevSecOps，都不是某一个产品／应用的交付问题，而是一个云计算整体安全体系的问题。涉及到云应用的开发、测试和部署（SDL）、运营和防御。对于开发者和运营者来说，好处都是无法拒绝的——只需要维护代码或template就可以，不需要触碰任何的业务组件或防御系统。此外，由于自动化是通过脚本实现的，因此可以保证安全能力在云环境下无损地复制、迁移和分钟级的快速部署。
“消失”的边界
在进入云计算的时代后，关于云安全最常听到的一个说法是：上云后，边界就不再存在，传统安全的边界防护思路过时了。
事实真是如此吗？个人认为，不是这样的。在云的环境下，边界并没有消失，而是改变了，边界防护的思路仍旧是一个有效的防御理念。
在传统网络框架下，系统和网络的边界都非常清晰。在云计算环境下，边界仍旧存在，只是不再以系统和网络为划分基础，而是以应用（Application）甚至进程（Process）作为边界，通过对应用、进程的隔离和访问控制实现云计算环境下新的边界控制。这也就是所谓的软件定义的分割（Software-Defined Segment）。
在本届RSA上，涌现了不少聚焦在Software-Defined Segment技术上的安全公司。以以色列公司居多，这的确是一个有趣的现象。其中，部分厂商将Software-Defined Segment与Security automation结合起来，创新地推出了云环境下端到端解决方案，实在令人赞叹。
作者：黑屏（blackscreen），阿里云安全事业部安全专家。
