云安全运营总结 | 易学教程

云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！

做云安全运营也有一年多时间了，对云上安全建设和运营有一点粗浅的经验，希望可以抛砖引玉，借此文章能有机会和大佬们交流安全运营，安全建设方向的经验。

首先我贴一张思维导图，云上安全运营工作主要围绕此图开展，因为我们的身份是云安全乙方，所以不开展SDL工作。

一、风险管理

风险管理工作是安全运营的重头戏，风险管理是一个动态的过程，所以工作量不言而喻。

我们的风险管理其实和甲方的有些不一样，比如我们省去了对重要资产的估值这一步，只要是租户的资产，我们都ALL IN ONE，我们把重心放在更细粒度的发现风险项上。

1.1 云上风险项

1.2 自动化监控风险

阿里云几乎所有的产品都支持API调用，通过编写相关规则，可以实现自动化监控风险的功能。

例如安全组风险，通过如下代码可以获取到某个Region的所有安全组信息

返回的字典数据中，Permission字段包含了“授权方向”，“IP协议”，“授权范围”，“端口范围”，“授权策略”

通过如下示例代码可以过滤出存在高风险的安全组

这里仅以安全组风险举例，其它风险项如法炮制，都是调用阿里云API获取数据，并通过规则筛选出风险项。

6个风险项，以面向对象的编程思想封装成6个类。并设置计划任务，每天运行一次。

1.3 降低风险

降低风险也可以理解成风险处置。作为云安全乙方，我们没有权限对租户的风险项进行直接修改操作，只能通过以下两种方式通知租户进行修复：

钉钉告警
短信告警

1.4 责任划分

平台侧：负责发现风险，并通知到租户
租户侧：进行风险项整改工作

二、应急响应

资产数量多，难免会发生安全事件，所以应急响应也划分进了安全运营范畴。处理过多次应急响应事件，包括挖矿事件，对外ddos事件。入侵原因top3：ssh暴力破解，redis未授权访问，elasticsearch弱口令

2.1 事前准备

编写应急响应方案
工具准备：windows，linux杀毒软件，rootkit扫描工具

2.2 事中处置

遵守PDCERF模型进行应急响应工作。一般情况下，我会按照如下步骤进行应急

初步判断事件真伪
找到项目负责人，拉群成立临时应急响应小组
经租户授权许可后进行应急响应工作
备份快照
登录服务器，分析网络连接，并根据网络连接进行访问控制，例如挖矿通信端口1234，立即网络阻断掉该端口
通过网络访问控制，对内网机器进行隔离，降低内网横向感染风险
分析进程，kill恶意进程
检查启动项，删除恶意启动项
检查是否存在隐形账号，并通过工具自动化检查rootkit
杀毒软件对服务器进行全盘扫描，删除病毒
入侵溯源，重点分析：.bash_history, web日志，互联网服务(例如elasticsearch，redis)日志
找到入侵原因后，进行加固

2.3 事后关注

事后，要保持一段时间对该机器以及该网段其它机器进行重点关注，以防残留后门导致事件复发。

三、安全巡检

安全巡检是安全运营工作中频率最高的工作项。正常情况下，重要的部门需要一天进行2次巡检，早上下午各一次。

3.1 编写安全巡检方案

将巡检的操作流程，巡检项，注意事项进行文档化，一方面可以为新入职的安全工程师提供指导，另外一方面可以满足安全评审需要。

3.2 日常巡检工作

假设网络环境分为专有云区和公有云区，有5个租户，每天都要进行2次安全巡检，那么一天巡检的次数就是10次。需要关注的巡检项包括：

态势感知事件
主机安全事件
基线检查(风险)
漏洞检查(风险)

那么，浪费在5个租户上的巡检时间会非常多，好在阿里云提供了API，可以帮助我们从多租户双区域的手工巡检中解脱出来。这里我想表达的意思是，其实安全巡检本身没什么技术含量，但却又是一个重复繁琐的工作，利用好编程能力，可以很大程度上提高工作效率，这也是为什么很多公司要求安全运营人员要掌握一门编程语言的原因。

3.3 记录巡检数据

保存巡检数据主要是为了审计，为了问责。(个人观点)

假如4月1号早上发生了安全事件，作为安全运营工程师没有及时做好巡检工作，第二天巡检的时候才发现事件告警，导致了租户严重损失，这个责任是需要的安全工程师承担的。

巡检日志表格示例