AWS 安全笔记：云安全随想（上）

1. 前言

云安全的发展，随着云技术本身的发展，经历了比较长的时间进行持续的演进。

从最早AWS建设出来的安全产品体系开始，到后来的Aliyun的创新以及基于中国特色社会主义环境衍生出来的业务安全和服务的路线，以及类似Google从自由安全能力发展出来的BeyondCorp的云化等。在云计算的领域里面从来不缺乏新的字眼出现。

而现在，几乎是个有规模的常见都有自己的云和云安全中心，传统的生产网安全体系WAF，DDOS，HIDS，数据库审计等等也逐步进行了云化的尝试。

云平台的安全产品，有它自身的基于环境的创新式特性，也有传统方式所继承的方法，也有公司环境导致的设计理念，还有外部环境所促发的战略思想。

反正以后要改，就这样吧。感谢@云辑 和@冰粥 帮忙做的审稿。云安全是个大话题，所以其中肯定有错误的地方，我争取改进，要是懒得改就算了。

2. 可见性

2.1 可见

环境的可见性通常是企业接入云的第一个安全挑战，从最底层的网络，到服务器再到上层的多种形式的服务，日志所能覆盖的广度和宽度，服务的可配置性，可扩展性，服务状态的告警等等都会对安全建设造成影响。

具备规模的甲方生产网角度的所谓防护纵深来说，所覆盖的全链路日志，所对应的WAF、HIDS、RASP、NIDS、SOC、威胁情报，其根本的检测能力都必须依赖各类型的日志来获得对环境变化的感知能力，才可以实现上层的规则系统、机器学习、分析关联可视化等奇妙能力。

所以不可靠的说，云环境的可见性会决定防御纵深的上限。

2.2 日志

对于云平台来说日志的粗分类有三类， 平台层日志 、 服务层日志 、 系统层日志 。

1. 平台层的日志对应了云平台的各类型账户，服务之间的操作和api调用

2. 服务层的日志一般是各个类型的服务根据自身的特性所设计的日志

3. 系统层面则是从原来的各类型软件上云之后原生日志，比如数据库的日志什么的。

例如在AWS中，从平台的Cloudtrail，到服务层面的S3访问日志、VPC日志、DNS日志，再到各类数据库等的原生日志，服务本身的事件通知，这就构成了一个小的生产网日志的体系。安全团队基于这些日志数据建立对应的安全能力，比如AWS自身的Guardduty、Cloudtrail检测盗号和异常操作、从DNS日志检测DGA域名、VPC日志检测SSH爆破，端口暴露等。

2.3 进一步

在云端可见性的命题上，Google做了进一步的尝试，他们推出了Access-transparency和Access-Approval。

• A ccess-transparency用于向客户透明化谷歌员工对于用户资源的访问过程。用于客户当需要Google员工进行支持时能够保障它的操作访问过程是合理，合规，安全的。整个服务商的支持过程都能够通过日志被可见，能够直接关联到相对应的工单。

• Access-Approval则是用于谷歌员工在访问用户资源的时候让用户进行主动授权。

3. 安全中心

3.1 中心化

一张过期的图

“不负责任的说，SecurityHub是个半残废，Sentinel是个哥斯拉。”

负责任的说，SecurityHub是纯粹以提升运营效率为目的的集中式告警台，Sentinel则代表了更先进的安全概念的实践，包含了安全数仓，图算法，威胁阶段执行等多种想法的尝试。SCC的目标看起来还在摸索。

这两年基于云平台的一种中心化的安全平台成为一种新的趋势，可能是管理类的，运营类的，分析类的。你也可以说是老酒的新包装，但在技术实践还有产品模式上都有一定的创新。 包括AWS的SecurityHub，GPC的CSCC，阿里云的云安全中心（这个是安骑士变身的），Azure的Sentinel。

我们可以从常见的一种安全运营的工作流，预防，检测，调查，响应，恢复的视角来切入看待安全中心类的产品，可以看到各类产品显示出的差异。

3.2 AWS

从这个角度来说，SecurityHub简直是个半残废，因为这五个阶段，没有一个阶段SecurityHub是能够独立于任何外部组件的。

SecurityHub将自身的规则打入AWSConfig，由Config进行基线-合规检查，再向SecurityHub吐回去。由Guardduty，Macie，Inspector三大检测产品提供检测能力。虽然提供了数据面板，但从告警事件所提供的信息丰富度来说，还是远远不足的。由CloudwatchEvent和Lambda提供响应能力。就是，你把数据打出去然后用别的东西写响应组件。

SecurityHub合作支持集成列表

所以严格来说，SecurityHub是一个集中式告警台组件。通过多账户和外部安全能力的功能来建立统一的告警平台。与其他云安全中心全流程的可定制化不同，SecurityHub不管是外部安全厂商还是用户，只能往里打告警。除此之外提供的CIS合规检查，则是有一些类基线检查的功能。

从设计思路来说是契合场景的。AWS常见的组织Org模型多对应的多账户是达到了一定规模的企业常见的方案，极端的一个公司500+的账户，这样条件下如何契合环境的统一运营就成了一个重要问题。

3.3 其他云

Sentinel界面

与之对比Sentinel和SCC就成了另一类的极端，抛去Sentinel和SCC一样都实现了产品内的检测能力以外。在检测，调查，响应层面，Sentinal都通过平台自身的Azure Monitor所提供的一种DSL作为规则语法实现了插件化，还上传到了Github，可能有社区化的想法。最后二十多种的可集成数据类型，以及脚本化和界面化的规则编写功能以及现成的规则大礼包，再加上内部安全能力的集成。简直就是个哥斯拉。

SCC的插件类型，中间那排

SCC则与Sentinel类似，也实现了一种执行链路的插件化，但不具备Sentinel的层度，更多是基于现有告警和资产管理等流程的可定制性，并且根据自身的安全能力进行了增强，比如扫描器的集成。

而在另一个方面，SCC进行了资产管理的强化，资产管理和发现一直是安全建设过程中坑比较多的一个问题，而在云环境下，资产管理和发现所需要的成本则被大大较低了。在这个条件下创建统一的资产管理和变化跟踪的能力就成了可能。

3.4 随想

由可视化，指标体系，关联分析，人机交互命题组成的数据化运营能力。对第三方安全厂商，自身安全产品的整合能力。在云环境下对资产的可视，可控的资产管理能力。对生产-办公环境整体数据流的管理关联分析能力。基于甲方视角的安全运营流程的定制化，模版化。 云安全中心可以代表对这多种命题的摸索与尝试。