阿里云 DevOps 资源安全扫描实践

news2024/11/24 18:21:59

随着企业上云进程的加速，云资源的使用量日益增长，云环境中资源的安全性和稳定性成为了企业业务运营的关键要素

面对多样化的云资源和复杂的应用场景，传统的安全管理手段已无法完全满足企业日益严苛的安全需求。为了确保云上资源的安全性，并在快速发展的业务环境中保持稳定性，企业需要采用更智能、自动化的解决方案

对于阿里云，我们实践了对云资源两种不同的扫描方式

脚本语言 + Github Actions

对于一些定制化的需求，最直观的方式当然是直接通过脚本的方式实现

从获取账号下的资源，到合规性到检查，到吐日志信息到控制台或者其他存储介质，最后代码提交到仓库的时候通过 Github Actions 触发脚本运行

整体流程看起来会是这样：

自定义规则校验

让我们从一个最简单的例子开始：Virtual private clouds (VPCs) must be configured and associated to the service

def validator():
	describe_dbinstance_attribute_request = rds_20140815_models.DescribeDBInstanceAttributeRequest(dbinstance_id='YOUR_INSTANCE_ID')
	runtime = util_models.RuntimeOptions()
	response = client.describe_dbinstance_attribute_with_options(describe_dbinstance_attribute_request, runtime)
	json = response.to_map().get("body")
	vpc_id = json.get("VpcId")
	return vpc_id != None

校验逻辑实际上非常简单，通过判断 rds 实例信息中有没有 vpc，sdk 文档可以到 openapi 中查看，获取账号下资源和吐日志的部份在这里就不过多展开了，相信还是比较简单的，也会有很多现成的方案

Github Actions 配置

不知道大家平时会不会用到 Actions 来做一些依赖版本更新的检查或者单测等工作，简单介绍一下，主要是通过 workflow 的方式定义工作流，Github 会扫描项目根目录下 .github/workflows 中的 yaml 文件，并行处理其中定义的 jobs

这对于社区开源项目当然没有什么问题，但是对于企业级私有项目并不能直接将脚本运行在公共的 runner 中，所以我们需要为仓库绑定一个 self-hosted 的 runner 来运行我们的脚本

name: "Ali"

on:
  push:
    branches: [master]
  schedule:
    - cron: '0 23 * * *'

jobs:
  Scan:
    runs-on: ["self-hosted"]
    steps:
      - uses: actions/checkout@v1

      - name: "Setup Python Environment"
        shell: bash
        run: pip install -r ./requirements.txt

      - name: "Trigger Script"
	      run: python3  ./main.py

Github Actions 提供了非常强大的自定义工作流的功能，可以看到在这个配置文件中我们不只是 push 到 master 分支，还存在一个定时触发的配置，深入学习可以看看这里！（https://github.com/features/actions）

那么到此为止我们走完了一个从验证到触发简单的流程

显而易见的这种方式提供了足够的灵活度（毕竟啥都是手搓的）但是另一方面这实在是稍显简陋，对于仅限于阿里云的资源扫描还有什么其他的方式吗？

阿里云函数计算 + 配置审计

阿里云已经考虑到了一些客户对资源审计的需求，所以有一个现成的配置审计控制台，支持通过账号组的方式跨账号扫描资源并汇总到概览页面，这似乎很美好，那让我们深入看看

厂商提供了三种方式定义规则：基于模版创建 / 基于条件自定义 / 基于函数计算自定义

当然一部分需求可以被现成的模版覆盖到，但是大部分并不能被很好的处理，条件自定义也只是提供了一部分字段给用户定义判断逻辑（聊胜于无

那么对于自定义程度比较高的规则我们唯一的选择只有函数计算

结合了模版和函数计算的流程看起来会是这样：

对于函数计算我们可以把他简单的理解为每个函数有一台机器，然后根据使用方的不同调用不同的方法，他也并不是只为配置审计这一个功能使用

我们同样以判断 vpc 是否存在为例子：

def evaluate_configuration_item(rule_parameters, configuration_item):
    compliance_type = COMPLIANCE_TYPE_NON_COMPLIANT
    annotation = None

    full_configuration = configuration_item["configuration"]
    if not full_configuration:
        annotation = "Configuration is empty."
        return compliance_type, annotation

    configuration = json.loads(full_configuration)
    if not configuration:
        annotation = "Configuration:{} is invalid.".format(full_configuration)
        return compliance_type, annotation

    vpc_id = configuration.get("VpcId")

    if vpc_id != None:
        compliance_type = COMPLIANCE_TYPE_COMPLIANT

    return compliance_type, annotation

这是处理判断的主要逻辑，当然还有涉及到和审计配置交互的逻辑在文档中也会有现成的部份 → 基于函数计算创建自定义规则

相信仔细看实现逻辑的话能在里面找到获取资源信息和向配置审计中回调结果的部份

但是如果所有信息都能直接从实例信息中获取到的话理论上我们也可以通过条件自定义的方式实现，对于 openapi 中提供的能力是一点没有，在环境中也没有提供现成的 sdk 那要怎么做呢？

只能是通过自研签名从最基本的 http 请求开始了，很庆幸文档最后有基于各种语言的实现

到此为止我们也走通了以阿里云配置审计 + 函数计算的实现方式

那么这就是完美的方案了嘛？