做云安全运营也有一年多时间了，对云上安全建设和运营有一点粗浅的经验，希望可以抛砖引玉，借此文章能有机会和大佬们交流 安全运营，安全建设方向的经验。
首先我贴一张思维导图，云上安全运营工作主要围绕此图开展，因为我们的身份是云安全乙方，所以不开展 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 | 安全组权限规则 | ||
|---|---|---|---|
| CreateTime | String | 2018-12-12T 07:28:38Z | 创建时间，UTC 时间。 |
| Description | String | FinanceDept | 安全组描述信息。 |
| DestCidrIp | String | 0.0.0.0/0 | 目标 IP 地址段，用于出方向授权。 |
| DestGroupId | String | sg-securitygroupid1 | 目标安全组，用于出方向授权。 |
| DestGroupName | String | SecurityGuard | 目的端安全组名称。 |
| DestGroupOwnerAccount | String | SecurityGuard | 目标安全组所属阿里云账户 ID。 |
| Direction | String | ingress | 授权方向。 |
| IpProtocol | String | TCP | IP 协议。 |
| Ipv6DestCidrIp | String | 2001:db8:1233:1a00::*** | 目的 IPv6 地址段。 |
| Ipv6SourceCidrIp | String | 2001:db8: 1234:1a00::*** | 源 IPv6 地址段。 |
| NicType | String | intranet | 网络类型。 |
| Policy | String | Accept | 授权策略。 |
| PortRange | String | 80/80 | 端口范围。 |
| Priority | String | 1 | 规则优先级。 |
| SourceCidrIp | String | 0.0.0.0/0 | 源 IP 地址段，用于入方向授权。 |
| SourceGroupId | String | sg-securitygroupid2 | 源安全组，用于入方向授权。 |
| SourceGroupName | String | FinanceDeptJoshua | 源端安全组名称。 |
| SourceGroupOwnerAccount | String | FinanceJoshua | 源安全组所属阿里云账户 ID。 |
| SourcePortRange | String | 80/80 | 源端端口范围。 |
通过如下示例代码可以过滤出存在高风险的安全组
这里仅以安全组风险举例，其它风险项如法炮制，都是调用阿里云 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 业务是否接入 WAF |
| 3. 服务器配置是否满足安全基线要求 |
| 4. 安全组是否满足安全要求 |
| 5. 安骑士是否在线 |
| 6. web 程序是否以最低权限要求运行 |
【转载自 FreeBuf】
- 本文作者：Haczhou 转载链接：（https://www.freebuf.com/articles/security-management/236249.html）
- 声明：本文来自 FreeBuf.COM，版权归作者所有。文章内容仅代表作者独立观点，不代表本人立场，转载目的在于传递更多信息。如有侵权，请联系 2769905554@qq.com。