审计范围与边界：云上资产识别、责任共担模型下的审计边界、第三方服务审计要点
各位同学，咱们今天聊一个非常实际的问题——审计范围与边界。
说实话，我刚开始做金融云审计那会儿，最头疼的就是这个问题。客户问「你们到底审什么？」我说「审云上资产」，客户又问「哪些算云上资产？」……嗯，这就尴尬了。边界不清，审计就是一笔糊涂账。
今天我就把这块掰开揉碎了讲。核心就三件事：资产识别、责任边界、第三方审计。
一、云上资产识别——你连自己有什么都不知道，审什么？
资产识别是审计的起点。没有资产清单，后面全是空中楼阁。
我个人习惯把云上资产分成四类：
| 资产类型 | 典型示例 | 审计关注点 |
|---|---|---|
| 计算资源 | ECS、容器、函数计算 | 镜像来源、补丁状态、配置基线 |
| 存储资源 | OSS、NAS、云盘 | 加密策略、访问控制、生命周期 |
| 网络资源 | VPC、SLB、NAT网关 | 安全组规则、流量日志、隔离策略 |
| 数据资源 | RDS、Redis、MQ | 备份策略、审计日志、敏感数据发现 |
你想想看，很多团队连自己开了多少个ECS都不清楚。我在项目中遇到过一家银行，审计时发现有三台「幽灵服务器」——没人知道是谁建的，也没人敢关。最后查出来是半年前一个实习生测试用的，一直挂着没销毁。
所以，资产识别的第一步是自动化发现。别指望人工登记，那玩意儿永远滞后。
核心原则：所有云上资产必须纳入CMDB（配置管理数据库），且CMDB必须与云平台API实时同步。审计时，以CMDB为准，但需要交叉验证云平台账单和资源列表。
这里给一个简单的资产发现脚本思路：
# 伪代码示例：云资产自动发现
def discover_assets(cloud_provider):
assets = []
# 调用云平台API获取所有ECS实例
ecs_list = cloud_provider.list_instances()
for ecs in ecs_list:
asset = {
'id': ecs.id,
'type': 'compute',
'name': ecs.name,
'tags': ecs.tags,
'create_time': ecs.create_time,
'status': ecs.status
}
assets.append(asset)
# 同理获取存储、网络、数据库等
return assets
说白了，资产识别不是一次性工作，而是持续的过程。每次审计前，先跑一遍全量发现，对比上次结果，找出新增、变更、下线的资产。
二、责任共担模型下的审计边界——谁的地盘谁做主？
这是金融云审计里最容易扯皮的地方。
云厂商常说「责任共担」，但具体怎么担？我给大家画个图就清楚了。
这张图我建议你保存下来。每次跟业务方讨论审计范围时，直接甩出来，省得吵架。
审计边界怎么定？我的经验是：客户能控制的，就是审计能覆盖的。
- 客户责任区：IAM策略、数据加密、网络ACL、应用配置——这些必须审，而且可以审。
- 云厂商责任区：物理安全、虚拟化安全、平台服务底层——这些审不了，但可以依赖厂商的SOC2、ISO27001等报告。
注意：千万不要试图去审计云厂商的物理机房。我曾经见过一个审计团队，非要进阿里云的张北数据中心现场检查……结果可想而知，被礼貌地拒绝了。这不是你的审计范围，你只需要验证厂商的合规资质是否有效即可。
还有一个容易忽略的点：共享责任区。比如安全组的配置——云厂商提供安全组功能，但规则是你自己写的。出了问题，谁的责任？我建议在审计报告中明确标注「责任共担项」，并给出双方各自应承担的义务。
三、第三方服务审计要点——别让外包成为你的短板
金融云上很少只用一家云厂商的原生服务。SaaS、PaaS、API网关、CDN……各种第三方服务混在一起。审计时，这些第三方服务往往是最大的黑洞。
我记得有一次审计一家互联网金融公司，他们用了某第三方风控服务。结果一问，对方连基本的加密传输都没做，用户数据直接明文传输。更离谱的是，这家第三方公司连个合规资质都没有。
所以，第三方服务审计，我总结了四个要点：
- 资质审查——第三方有没有等保三级？有没有金融行业认证？没有？直接一票否决。
- 数据流向——你的数据到了第三方那里，存不存？存多久？能不能删？这些必须在合同中写清楚。
- 访问控制——第三方服务以什么身份访问你的云资源？AK/SK？临时令牌？权限最小化了吗？
- 应急响应——第三方出安全事件了，多久通知你？有没有SLA？
小技巧：审计第三方时，别只看对方提供的材料。我习惯做一次「暗访」——用自己的测试账号调用第三方API，看看实际返回的数据里有没有不该出现的信息。有一次我就在返回的报错信息里看到了完整的数据库连接字符串……嗯，那个第三方当场被要求整改。
这里给一个第三方服务审计清单的示例：
# 第三方服务审计检查项
checklist = {
'资质': ['等保三级', 'ISO27001', '金融行业认证'],
'数据安全': ['传输加密(TLS 1.2+)', '存储加密', '数据销毁机制'],
'访问控制': ['最小权限原则', '临时凭证', '审计日志'],
'合规承诺': ['数据不二次使用', '数据本地化', '配合监管检查'],
'应急能力': ['事件响应SLA', '安全通告机制', '灾备演练记录']
}
你想想看，如果第三方服务出了问题，监管机构可不会管「这是外包的」——板子照样打在你身上。所以，第三方服务的风险，最终由你承担。审计时一定要把第三方纳入范围，不能有「法外之地」。
总结一下
审计范围与边界，说白了就是三句话：
- 资产识别——搞清楚你有什么，别漏了「幽灵资产」。
- 责任共担——客户管客户的事，厂商管厂商的事，别越界也别留空白。
- 第三方审计——外包不是免责牌，第三方出问题，你买单。
我曾经见过一个团队，审计范围画得特别大，连云厂商的空调温度都要审……结果审计资源全浪费了，真正该审的IAM策略反而没细看。所以，边界要清晰，重点要突出。
好了，这一节就到这里。记住：审计不是越全越好，而是越准越好。