技能介绍

解决什么问题

在 BI 分析场景中，让分析师或自动化脚本直接访问业务数据库往往意味着高风险：一句拼错的 SQL 可能就能把生产表清空，一条 UPDATE 或 DELETE 语句足以破坏核心业务数据。更棘手的是隐私合规：查询结果里往往包含客户姓名、具体金额、销售负责人等敏感字段，这些内容一旦通过飞书或企业微信等外部渠道流转，就可能造成数据泄露。

如果完全靠人工审核 SQL 来规避风险，流程会变得极其笨重，也难以保证每一次查询都被完整记录。我们需要一种机制：既能让分析师自由探索数据，又能确保数据库不会被误写，敏感字段在流出内部环境前被自动剥离，且每一次查询都有明确的审计痕迹。

技能如何工作

这个技能是 integration-contract 五条契约在 BI 查询场景下的参考实现，通过多层防线将风险降到最低：

物理层只读隔离：数据库侧只创建 bi_ro@% 账号，GRANT SELECT ON bi_sandbox.* 是唯一授权。即使凭证泄露，攻击者也无法执行任何写操作。
应用层强制拦截：query_bi.py 在发送 SQL 前会调用 is_select_only() 检查，非 SELECT 语句直接抛出 PermissionError。查询超时通过 connect_timeout=5 控制，防止长连接拖垮数据库。
敏感字段脱敏：desensitize.py 根据 PERSONA.md 中定义的规则，自动剥离 customer_name、amount、sales_manager 等字段。脱敏策略按调用渠道路由：内部渠道返回原始数据，外部渠道自动应用脱敏规则。
全量审计留痕：每次查询都会调用 audit() 函数，将操作人、时间戳、SQL 语句、返回行数、调用渠道写入 audit/audit.log.jsonl。审计日志在运行时生成，发布包本身不包含演示日志。

切换到生产环境时，只需完成三步：将 bi_ro 的授权指向真实业务 schema（如 GRANT SELECT ON bi_prod.*），删除沙箱演示数据，然后根据调用方渠道传递对应的 channel 参数即可。

适用边界

当前技能处于沙箱验证阶段，已跑通核心逻辑，但尚未接入真实业务 schema。生产部署前需要在你自己的 CloudBase 环境中重新配置数据库账号和连接信息。
配置文件 config.local.example.json 中的口令仅用于本地演示，生产环境应通过 CloudBase 环境变量注入，不要将真实凭证提交到代码仓库。
脱敏规则基于 PERSONA.md 中预设的字段列表，如果你的业务有额外的敏感字段需要处理，需要自行扩展 desensitize.py 的逻辑。
审计日志目前写入本地文件，适合单实例或小规模使用场景。如果需要集中式审计或与 SIEM 系统集成，需要额外开发日志上报机制。