接进来的应用，能被管到哪一层

结论先行：企业把协作平台当作办公入口之后，平台上会陆续挂上一批应用：自建的审批流程、外部的客户管理工具、第三方的小程序。这些应用一旦被授权，拿到的往往不只是它自己那一块数据。要管好这件事，需要固定回答三个问题——这个应用能读到什么、它从哪里被调用、它的动作有没有留下记录。三者缺一，授权就会慢慢变成一张没人复核的清单。

授权容易，回收难

应用接入的心理成本很低：业务部门提出需求，管理员点几下完成授权，流程当天就能跑通。真正的成本出现在后面。三年之后回头看，平台上可能挂着一批已经没人使用的应用，它们仍然持有当初开通的那组权限；而这批权限里，有些是读取通讯录范围，有些是读取会话相关内容，有些是代表企业对外发送消息。

这类问题很难靠一次清理解决，因为它会反复发生。更可行的做法是把「授权」当流程管：接入前明确权限范围，接入后定期复核，退出时收干净。

问题一：它能读到什么

权限设计的起点是把「能装什么」与「能读什么」分开。装应用的人未必是能决定权限范围的人，尤其在业务部门自行申请的情况下。建议按数据敏感程度分档，而不是按应用名称逐个判断。

最后一类常被低估。具备推送能力的应用，在接收方看来发出的就是「企业官方消息」，这是它与其他应用能力最本质的区别。开通这项能力时，除了确认业务必要性，还应当配套内容审核与发送记录。

问题二：它从哪里被调用

账号权限是对的，不代表调用环境是对的。限制访问来源要解决的就是这一类风险：凭据本身没有问题，但它在不受控的网络位置被使用。协作平台侧可以做的收敛包括：把应用的调用锁定在固定出口地址范围内，仅允许来自企业内网或指定地址；对管理后台单独设置登录校验；对异地、非常用环境的登录动作单独告警。

这一类限制的价值在于抬高门槛。它挡不住所有情况，但能把「凭据在任意位置都能直接使用」变成「需要先解决位置问题」，中间多出来的这一步，就是被发现的窗口。

问题三：它的动作有没有留痕

问题一与问题二解决的是「能不能做」，第三个解决的是「做没做过、做了多少」。建议至少保留三层记录。

• 管理侧的操作记录。谁安装了应用、谁调整过权限、谁改过可见范围。这部分记录要能按时间与人回溯，并且管理员体系本身要有分级，避免一组账号掌握全部权限。
• 应用侧的行为记录。应用调用了哪些接口、在什么时段、频次如何。这里最值得关注的是批量行为：一个应用在短时间内做大量读写，无论是设计如此还是被滥用，都需要有地方能看到。
• 内容侧的留存。对涉及客户沟通与对外服务的场景，会话内容的留存往往是合规要求，也是纠纷时的依据。需要事先约定三件事：留存哪些范围、留存多久、谁能调阅。

把三件事做成固定动作

制度要落到动作上才有意义。建议固定三个节点。

• 接入前。申请单上写清应用用途、负责人、需要的数据范围、是否需要对外的消息能力。权限按上表的档位勾选，而不是「按应用要求全部同意」。
• 运行中。按季度或半年复核一次在用应用清单，逐条确认是否仍在使用、权限是否仍然需要。批量行为告警要有明确的接收人与处置口径。
• 退出时。应用下线或供应商变更时，收回权限、解除绑定、处理已留存的授权关系，并保留一份退出确认记录。这一步不做，清单就会一直变长。

边界与前提

其一，不建议一刀切禁止接入。业务需求是真实的，管得过死的结果往往是把资料搬回不受控的个人环境，反而更难追。其二，权限最小化是一个逐步收敛的过程，存量应用需要按批次复盘，不必一次改完。其三，留存与调阅涉及员工与客户的个人信息，范围与用途需要有明确依据并事先告知，不能以「技术可行」为理由无限扩大。其四，本文所述能力项为协作平台常见的安全配置方向，具体可用范围以本企业所使用平台的版本与配置为准。

落地清单

1. 导出当前平台上的全部在用应用清单，标注接入时间、负责人与最近使用情况。
2. 按数据类别逐条复核每个应用的权限范围，取消不再需要的授权。
3. 为涉及沟通内容与对外推送能力的应用设定单独审批与内容审核流程。
4. 限制应用与后台的访问来源，对异常登录位置设置告警。
5. 开启管理操作日志与批量行为预警，指定接收人与处置人。
6. 约定会话与内容的留存范围、时长与调阅审批方式。
7. 建立应用退出流程，把权限回收与记录留存写进标准动作。

平台上的应用治理本质上是一份清单加一套流程：清单管住「有什么」，流程管住「怎么变」。需要梳理现有应用的权限分布与复核机制，欢迎 预约咨询，奇摩可以结合你的平台版本与合规要求给出复核路径。