技能介绍

为什么需要把云库存搬进 SQL

做安全审计或合规检查时，最常见的摩擦点不是「查不到规则」，而是拿不到一份可以被反复查询的基线。资产分散在 AWS、Azure、各家 SaaS 后台里，配置信息要么锁在控制台页面，要么只能通过一组临时 API 调用现拉现算。结果就是审计证据只能靠截图和手工记录，漂移检查（drift check）也没法自动化，因为两次采样之间没有可比对的结构化数据。

CloudQuery 本身是配置数据同步工具，但它产出的数据需要落到一个能被持续查询的地方，否则每次审计都得重跑一遍同步、再手工整理。这个技能要解决的问题很具体：把云和 SaaS 的配置数据抽取成可查询的表，让后续的审计、漂移检查、证据收集都能直接用 SQL 完成。

它是怎么工作的

技能围绕一条主链路展开：

抽取：通过 CloudQuery 的 source 插件，从目标云或 SaaS 系统中拉取配置与库存数据。插件是前提，技能本身不负责插件的发现或生成。
落地：同步结果写入已配置好的目标数据库或数据仓库，形态是可查询的表。这一层决定了后面能用哪些 SQL 能力，以及并发查询的上限。
查询驱动的审计：数据到位后，审计动作变成一组 SQL 查询——检查某类资源是否满足基线、对比两次快照之间的配置差异、按资产维度导出证据集。

也就是说，技能的价值不在同步逻辑本身，而在把「同步」和「审计」这两件事的接口标准化：只要表结构稳定，换审计规则不用换数据管道。

适用边界与注意点

依赖前置配置：需要 CloudQuery CLI、已配置好的 source 插件、已就绪的目标数据库或仓库，以及目标系统的访问凭据。缺任意一项，同步链路都跑不起来。
不是规则引擎：技能负责把数据放进表，不负责判断「这样是否合规」。审计规则仍需自行编写 SQL 或在上层工具中定义。
首次同步的一致性：第一次全量同步耗时取决于资产规模和插件覆盖范围，建议在低峰期执行，并确认目标库有足够容量。
凭据管理：目标系统的访问凭据是敏感信息，应按环境隔离存放，避免写进代码仓库。
官方文档是主要参考：安装与插件细节以 CloudQuery 官方文档为准，技能描述不覆盖所有插件的具体参数。