云安全技术与应用（云安全运营总结）

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

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

一、风险管理

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

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

1.1 云上风险项

风险名称详情安全组风险[-1/-1,21/21,22/22,3389/3389,6379/6379,1433/1433,3306/3306]，0.0.0.0/0，入方向，允许RDS白名单风险白名单策略：0.0.0.0/0安骑士离线风险安骑士状态: offline漏洞调用云盾API获取相关数据弱口令风险数据库，tomcat，weblogic，RDP，SSH基线检查调用云盾基线检查API获取

1.2 自动化监控风险

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

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

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

Permission安全组权限规则**。CreateTimeStringDescriptionStringDestCidrIpStringDestGroupIdStringDestGroupNameStringDestGroupOwnerAccountStringDirectionStringIpProtocolStringIpv6DestCidrIpStringIpv6SourceCidrIpStringNicTypeStringPolicyStringPortRangeStringPriorityStringSourceCidrIpStringSourceGroupIdStringSourceGroupNameStringSourceGroupOwnerAccountStringSourcePortRangeString

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

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

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

1.3 降低风险

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

1、钉钉告警

2、短信告警

1.4 责任划分

平台侧：负责发现风险，并通知到租户

租户侧：进行风险项整改工作

二、应急响应

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

2.1 事前准备

1、编写应急响应方案

2、工具准备：windows，linux杀毒软件，rootkit扫描工具

2.2 事中处置

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

1、初步判断事件真伪

2、找到项目负责人，拉群成立临时应急响应小组

3、经租户授权许可后进行应急响应工作

4、备份快照

5、登录服务器，分析网络连接，并根据网络连接进行访问控制，例如挖矿通信端口1234，立即网络阻断掉该端口

6、通过网络访问控制，对内网机器进行隔离，降低内网横向感染风险

7、分析进程，kill恶意进程

8、检查启动项，删除恶意启动项

9、检查是否存在隐形账号，并通过工具自动化检查rootkit

10、杀毒软件对服务器进行全盘扫描，删除病毒

11、入侵溯源，重点分析：.bash_history, web日志，互联网服务（例如elasticsearch，redis）日志

12、找到入侵原因后，进行加固

2.3 事后关注

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

三、安全巡检

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

3.1 编写安全巡检方案

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

3.2 日常巡检工作

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

1、态势感知事件

2、主机安全事件

3、基线检查（风险）

4、漏洞检查（风险）

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

3.3 记录巡检数据

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

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

巡检日志表格示例

巡检时间巡检项租户备注2020.4.1 10:20基线检查某企业安全2020.4.1 10:20态势感知事件某企业安全2020.4.2 16:20基线检查某企业安全2020.4.2 16:20漏洞检查某企业安全2020.4.2 16:20态势感知事件某企业暴力破解成功2020.4.2 16:20主机安全事件某企业挖矿事件

上面的表格4.1没有对主机安全事件进行巡检，第二天才发现有挖矿事件，导致租户遭受了重大损失。所以作为安全运营工程师应该承担主要责任。

四、安全产品运营

云安全产品运营是我们云安全运营工程的职责之一。租户通过开通/接入申请，我们对安全产品进行接入，配置操作。

1、租户申请10个域名接入WAF -> 安全运营工程师进行配置 -> 本地修改hosts验证 -> 租户修改dns记录

2、租户申请10台ECS接入堡垒机 -> 安全运营工程师进行配置 -> 通过test用户验证可用性 ->完成配置

3、云盾功能性测试。（云盾版本升级后，或者同城容灾部署后）

五、编写文档

编写文档，并不是安全运营工程师的主要职责，这个工作应该由安全架构师或者首席安全官来做。但有时候安全团队会选择相信我，让我完成其中一部分文档的编写。例如《云上安全加固方案》，《安全巡检方案》，《应急响应方案》。有时候尝试做自己不擅长做的事情，能帮助自己快速成长。

六、业务上线评审（TODOLIST）

目前，租户的业务上线是没有经过我们安全评审的。比如项目方可以有权限自己开安全组，想怎么开就怎么开。业务系统上线前也几乎不会做漏洞扫描和安全测试。安全工作应该伴随项目规划到项目实施再到上线项目的整个生命周期。不经过评审就直接上项目，严重违背了安全建设生命周期。这一块需要规范起来，但一直没有时间去做。

云安全业务上线评审项1. 业务系统是否做过安全测试2. web业务是否接入WAF3. 服务器配置是否满足安全基线要求4. 安全组是否满足安全要求5. 安骑士是否在线6. web程序是否以最低权限要求运行

*本文作者：Haczhou，转载请注明来自FreeBuf.COM

,