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

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

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

脚本语言 + 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 分支，还存在一个定时触发的配置，深入学习可以看看 这里！

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

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

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

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

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

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

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

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

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

我们同样以判断 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 请求开始了，很庆幸文档最后有基于各种语言的实现

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

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

Py Script vs Ali cc + fc

通过两种方式我们会发现，在自定义程度较高的场景下，我们不得不需要依靠一定的编程的能力来解决问题，python 也只是一个例子，无论是 runner 还是函数计算，都支持多种语言，两种方式的差异主要是体现在触发方式上

众所周知，软件开发没有银弹，每种方式都有适合的场景

接下来会从几个方面对比一下这两种解决方案

综上所述，对于仅限于阿里云的场景，如果对于成本的把控没有那么苛刻的话，云厂商提供的 配置审计 + 函数计算 无疑是更优雅的实现方式，和平台的集成度也更高，但是由于提供的环境不能灵活的自定义，所以一些特殊需求可能实现起来会比较复杂

反之如果有多云的需求，或者对整体执行的流程需要有复杂的定制，编程语言提供的能力会更加强大，也不失为一种选择

最后

无论选择哪种方法，实施资源安全扫描都是保护云环境的必要步骤

应根据自身的特定需求、资源状况和技术能力来制定相应的安全策略，在快速变化的云环境中，持续优化和调整安全方案将是确保企业持续稳定运营的关键