2. 云访问治理需求分析

云访问安全治理的第一步不是部署CASB，而是把“谁在用云、用什么云、数据怎么流、要治到什么程度”这四件事说清楚。需求分析做不扎实，后续的策略配置就会变成拍脑袋：要么把正常业务卡死，要么留下大量未覆盖的盲区。本节围绕四类核心工作展开——识别SaaS/IaaS/PaaS使用场景、发现影子IT、开展业务部门访谈、梳理数据流并定义治理目标。

一、识别三类云服务的使用场景

SaaS、IaaS、PaaS在访问治理中的关注点差异很大，不能混为一谈。SaaS是“开箱即用”的应用，治理重点是身份、共享、外发和终端接入；IaaS是租用的虚拟机与网络，治理重点是管理面访问、安全组、快照与密钥；PaaS是托管的运行平台，治理重点是API调用、服务账号、构建流水线与配置项。识别场景时，建议按“业务用途—使用主体—数据类型—访问方式”四个维度登记。

例如，市场部使用企业版在线文档协作（SaaS），主体是员工个人账号，数据类型为营销方案与客户名单，访问方式为浏览器和移动端；研发团队使用容器托管平台（PaaS）部署微服务，主体是服务账号与CI/CD流水线，数据类型为源代码与构建产物，访问方式为API与命令行；数据分析团队使用云主机（IaaS）跑批处理，主体是运维人员与临时实例，数据类型为脱敏后的业务数据，访问方式为SSH与内网。把这些场景列成清单，才能判断哪些需要CASB的API模式、哪些需要代理模式、哪些只需日志接入。

二、影子IT的发现方法

影子IT指未经IT或安全部门审批就被业务部门自行启用的云服务。它不一定恶意，但往往绕过了统一身份、日志留存和数据防泄漏。发现影子IT不能只靠问卷，需要多源数据交叉验证。常用方法包括：出口流量日志分析（DNS与SNI）、终端代理上报、CASB API对接已知SaaS、SSO登录日志比对、以及财务报销与采购记录核对。

实际操作中，可以先从防火墙或代理的DNS日志中提取高频外部域名，过滤掉已知白名单，再按域名聚类。例如，某月日志中出现大量*.notion.site、*.figma.com、*.slack.com的访问，而SSO中并未授权这些应用，就应列为疑似影子IT。随后通过终端进程与浏览器插件信息确认使用主体，再与业务部门确认是否属于正式采购。对于确认的影子IT，处理方式不是一律封禁，而是分级：涉及客户数据或源代码的，要求迁移到已审批应用或接入CASB管控；仅用于内部协作且无敏感数据的，可纳入观察清单并补做安全评估。

三、业务部门访谈：把技术清单翻译成业务语言

访谈不是让业务部门填安全问卷，而是理解他们的工作方式。建议按“业务目标—云应用—数据对象—协作方式—痛点”五条线提问。例如，对销售部门可以问：“你们用哪个系统管理客户？合同和报价单存在哪里？和渠道伙伴怎么共享文件？有没有因为权限问题导致看不到资料的情况？”对研发部门可以问：“代码托管在哪里？构建和发布走什么平台？测试数据从哪来？有没有把生产数据拉到本地分析？”

访谈输出应形成三份材料：应用清单（应用名、用途、使用部门、账号类型、数据级别）、数据分类表（数据对象、敏感级别、存储位置、共享范围）、风险点列表（未授权应用、过度共享、弱口令、无日志等）。这些材料是后续CASB策略的输入，而不是访谈记录本身。

四、数据流梳理与治理目标定义

数据流梳理要回答“数据从哪来、经过谁、落到哪、被谁看”。以一次典型的销售合同流转为例：销售在SaaS CRM中创建合同 → 合同附件上传到云存储 → 通过共享链接发给客户 → 客户下载后回传签署版 → 财务从云盘拉取归档。这条链路中，敏感数据出现在CRM、云存储、共享链接和邮件四个位置，每个位置的管控手段不同：CRM靠API扫描与权限审计，云存储靠代理模式做下载水印，共享链接靠外发策略限制有效期与密码，邮件靠DLP做附件识别。

治理目标定义要避免“提升安全性”这类空话，应转化为可度量指标。例如：可见性——30天内完成已审批SaaS应用100%接入CASB，影子IT发现率不低于95%；合规——所有涉及个人信息的云应用完成数据分类标注，审计日志留存不少于180天；防泄漏——敏感数据外发拦截率100%，误报率控制在5%以内；响应——高危告警从产生到处置不超过30分钟。这些指标需要与业务部门共同确认，否则执行时容易因“影响效率”被推翻。

最后需要强调，需求分析不是一次性工作。业务部门会不断启用新SaaS，研发会迁移新PaaS，数据流会随组织调整而变化。建议每季度做一次轻量复核：更新应用清单、复查影子IT发现结果、确认治理目标是否仍然成立。只有把需求分析变成持续机制，CASB的规则库才不会在三个月后变成一堆过期策略。