前言
配置审计（Config）将您分散在各地域的资源整合为全局资源列表，可便捷地搜索全局资源；同时帮助您记录云上 IT 资源的配置变更历史，持续自动地评估云上资源配置的合规性，实现云上 IT 合规治理。本文介绍如何使用
帮助您快速发现未配置防盗链的 OSS Bucket 并修复的案例。
实际案例
公司 A 有 10 个垂直的业务部门，每个业务部门分配了 1~2 个 OSS Bucket 用于存储运营图片，并直接在网页上使用的 OSS 生成的链接做图片内容的展示。我们知道 OSS 的费用分为存储费和流量费，当大量的外部请求获取图片资源时，产生的流量费用需要客户自行承担。为了杜绝不法网站盗用图片资源，OSS 开发了“防盗链”功能，详细的功能说明请参考:
防盗链公司 A 打算使用该技术方案，需要为 OSS Bucket 开启防盗链，并且设置 referer 白名单为
*.alibaba.com
和
*.aliyun.com
。作为公司的运维同学，非常不希望每个 Bucket 都检查并参考文档配置一遍，同时还需要额外制定对策防止 Bucket 配置被二次修改。
这时候，他想起了阿里云的一款云产品：
。
我们可以将配置审计（Config）的能力简单概括为3点：
- 统一的资源视角，多地域，甚至跨账号；
- 规则（Rule）检测资源配置是否满足要求；
- 持续检测资源及修复能力；
配置审计（Config）是如何工作的？
配置审计（Config）配合开启OSS防盗链功能
资源的配置数据通过异步消息通知会中心化的存储在
的数据库中。规则会采用定时、变更被动触发、用户主动触发的方式来对数据库的资源配置进行评估， 将评估结果展现给用户，同时会根据规则设置判断是否需要进行修正，如执行修正任务，新的资源配置数据会重新被
感知进入到下一次的评估循环中。我们一起来看看公司 A 的运维同学是如何通过
完成任务的。
设置规则
打开
配置审计控制台，进入
规则列表，点击
新建规则，即可看到
为用户提供的大量的托管规则（托管规则由平台开发并提供给用户使用），搜索“防盗链”或“referer”都可以搜索到该规则：OSS 存储空间开启防盗链功能。
点击应用规则，
第一步：设置规则名称、自定义风险等级、自定义备注信息；
第二步：可以根据实际的业务场景限定需要检查的资源的范围；可选项包括资源 ID、资源组 ID、地域、标签等；
第三步：设置允许的 referer 白名单及是否允许 referer 为空；
第四步： 设置是否开启自动修复，我们暂时先跳过，后续再讨论；
第五步：预览并提交
规则评估
规则创建完成后，规则便开始对存量的 Bucket 配置进行合规性的评估，参考规则的评估说明， “OSS 存储空间开启防盗链功能，视为合规”，该规则通过检查 Bucket 配置信息中的
RefererList.Referer
不为空判定开启防盗链功能是否合规。
规则评估完成后会生成一份评估结果，标注累计评估资源数、合规资源数、不合规资源数；您可以基于这份检查结果去手动配置。注意：对于新增的 OSS Bucket 同样会自动检测其合规性。
下图为检测结果：累计检测 23 个 OSS Bucket，23 个不合规，表示这 23 个 OSS Bucket 均未开启防盗链功能。
如何修复
如果 Bucket 的数量很多，繁重的人工配置可能会带来操作上的失误，别着急，
提供修正能力，对于规则评估出的不合规资源结合
运维编排（OOS）将其修复。可在规则详情页->修正详情，然后点击“修正配置”，完成修正配置。
注意有一个选项为：“自动修正/手动修正”，我们暂时勾选为“手动修正”。
这时候，在修正详情 tab，将会出现“执行手动修正”的按钮，点击此按钮，则手动触发对不合规资源的修复任务。
由于修复任务是异步发起的，您可以直接去对象存储的控制台->存储桶-> 权限管理 -> 防盗链查看是否修正成功，也可稍微等待一段时间(10分钟左右）再来
控制台查看最新的配置信息。
如上图所示，修复动作已经执行完成，OSS Bucket 防盗链已经正常设置， 回到
，继续等待片刻，修复触发的资源变更数据会回流到
触发规则的再一次评估，这时候我们发现所有的资源都变成合规状态。
持续评估并修复
如何保证其他运维人员在后续的时间里不再改变该配置呢？组织内部运行机制能够勉强完成任务，但是人总是会犯错误的。我们可以借助
的持续检测及修复能力。 在刚才配置修复设置中，将“手动执行”修改为“自动执行”，一旦资源发生了不合理的变更，
将会识别并将其自动纠正为正确的配置，防止异常修改。
如，我们在 OSS 控制台将某个 OSS Bucket 的配置规则修改为，改动点:
*.alibaba.com
改成了
*.alibaba-inc.com
稍微等待几分钟，我们会发现：
这里出现了我们刚才设置的错误的防盗链名单的 OSS Bucket，此时，自动修正已经触发，之所以还有 1 个显示为不合规，是因为
需要等待修正后的正确置到达中心化的数据库才能进行再一次的规则评估，将不合规资源评估为合规状态。
如上图，经过大约 10 分钟的时间，最新的 Bucket 配置信息已经到达配置审计，规则评估触发认定为“合规”。
我们再次回到 OSS Bucket 控制台查看最新的资源配置是否生效。
配置被重新设置回了
*.alibaba.com
*.aliyun.com
总结
以上就是使用
检测不合规配置并持续自动修复的全部内容，我们通过设置规则，规则评估及修复等完成从发现问题，定位资源，到手动、自动变配，形成了问题在
的闭环。
另外，我们还有很多适用于更复杂业务场景的规则及合规包，可以帮助企业运维、企业合规项目的同学们更高效地完成工作。
立即前往->