金融行业即时通讯：柜台、网点与后台的权限怎么分

金融行业即时通讯的权限管理，难点往往不在功能多少，而在三个词容易被放在同一个层级里比较。柜台是岗位，网点是组织层级，后台是职能条线。如果直接按这三个词建三档权限，常见结果是要么把柜台当成一个部门，要么把网点当成一个角色，最后不是权限过宽，就是协作被卡住。

更稳妥的做法是先拆成两个维度。组织层级决定一个人属于哪个机构、能看到谁；岗位角色决定他能做什么、能看什么数据。在这两个维度之上，再用数据敏感度和沟通边界切分权限。银行有网点，保险、证券的营业部和分公司也有类似的层级与条线，这套拆法同样适用。下面按这个思路，说明柜台、网点、后台的权限差异、隔离线、配置步骤和验收方法。

先拆两个维度，别把岗位和组织混为一谈

组织层级是总行、分行、支行、网点，以及条线、项目组、外部协作区。它回答的是通讯录里能看到谁、消息能发到哪个范围。岗位角色是柜员、网点负责人、客户经理、运营、风控、合规、科技、审计。它回答的是能建什么群、能发什么文件、能不能进后台。

同一个柜员，组织上属于某个网点，角色上是前台操作岗；同一个网点负责人，组织上是一个网点，角色上是基层管理者。 权限要按组织层级和岗位角色的组合授予，而不是给每个网点只设一个管理员账号，也不是给每个岗位直接开全行可见。

数据敏感度是第三个变量。金融数据的安全级别不同，能进群、能转发、能下载的范围也应该不同。《金融数据安全 数据安全分级指南》（JR/T 0197-2020）按数据安全性遭到破坏后的影响对象和影响程度，把金融数据从高到低分为 5 级到 1 级。机构不需要在即时通讯里重建一套数据分级，但应该把客户身份、账户交易、信贷审批、风控名单、内部通知等数据映射到已有的分级结果，再决定哪些内容允许在群里传、哪些只能在线看、哪些必须走业务系统。

沟通边界是第四个变量。本网点内、跨网点、跨条线、对外协作，风险完全不同。 权限矩阵的每一格，最好都能回答一个问题：这类角色，在这个范围内，对这种数据，能做这个动作吗？

柜台、网点、后台，权限差异在哪里

先给结论。柜台岗位的权限应该窄，重点是防止共享账号和文件外流；网点层的权限应该本网点可见、可管，但不能横向看到其他网点的客户信息；后台职能按条线跨网点工作，权限更深，因此更需要岗位分离、访问限制和操作留痕。

权限类别	柜台岗位	网点管理层	后台职能
通讯录可见范围	本网点为主，加必要的运营、授权联系人	本网点全员，按需查看上级机构	本条线跨网点，最小必要
群组权限	加入本网点群，不建跨网点群	可建本网点群，拉人需审批	可建条线群、项目群，敏感群需审批
文件与消息	收发日常文件，限制批量转发和下载	管理本网点群文件	敏感文件按审批流转，配合水印和留存
后台管理	无	本网点部门管理员	按权限分组，系统、审计、安全角色分设
登录与访问	固定终端或内网，限定 IP 段	本网点 IP 段	指定 IP 或设备，强认证
账号生命周期	入职开号，离岗锁定，离职回收	定期复核本网点账号	权限定期复核，离任审计

柜台岗位的权限窄，不是不信任柜员，而是这个岗位的日常协作不需要全行通讯录和后台业务群。 柜台账号最重要的是做到一人一号。 共享终端在网点很常见，交接班时如果账号不锁定，下一个使用者就能看到上一个柜员的会话和文件。技术上可以用短时锁定、退出登录、终端管理来配合，制度上要明确禁止共用账号。

网点层容易被误解成一个角色。实际上，网点负责人、客户经理、柜面主管的权限并不相同。网点负责人需要看到本网点组织架构、管理本网点群和成员；客户经理需要和本网点、上级行、产品部门沟通；柜面主管需要处理授权和异常。 共同点是默认不横向可见其他网点的通讯录和客户群，跨网点协作通过项目群或临时群完成，按事情授权，事情结束就收回。

后台职能的权限最深，因为运营、风控、合规、科技本身就要跨网点处理事务。权限设计的关键不是少给，而是分得开。系统管理员负责账号、组织和系统参数，不负责业务群内容；部门管理员只管本部门或本条线；审计或安全角色可以查看规则和记录，但不修改业务配置。 能让一个人同时管账号、管权限、管审计，权限体系就失去作用。

三类角色也有共同底线：实名账号、最小权限、离岗回收、操作留痕。把这四条做好，比堆很多细碎开关更有效。

三条隔离线，决定权限是否真的有效

第一条是网点之间默认不互见。通讯录按组织树分级，A 网点的柜员看不到 B 网点的完整通讯录，除非业务上确实需要。网点通讯隔离不是把网点彼此隔断，而是把默认可见范围收窄。跨网点协作不要靠把所有人拉进一个大群，而是建临时项目群，明确群主、成员、期限和清退规则。 客户信息不进群，必须走业务系统，这条规则比任何技术开关都重要。

第二条是前后台之间按事授权。后台的运营群、风控群、合规群不默认对柜台开放；柜台只进与本网点服务直接相关的通知群。敏感文件不在柜台终端落地，确实需要查看的，用在线预览、水印、限时访问等方式控制。这里的技术手段包括组织隔离、部门通讯隔离、IP 登录限制、界面水印等，但前提是先把哪些群属于后台、哪些文件不能进柜台定义清楚。

第三条是管理与业务之间分权制衡。《商业银行内部控制指引》（银监发〔2014〕40号）强调制衡性原则，要求梳理不相容岗位并实施分离，形成相互制约的安排；同时要求明确部门、岗位和上下级机构之间的职责，建立授权体系，对分支机构权限实施管理和监控。映射到即时通讯，就是管理员账号不用于日常聊天，系统管理、安全管理、审计管理不集中在一个账号，网点管理员的权限不超出本网点。

这些隔离线也能对应到等保 2.0 的要求。GB/T 22239-2019 提出授予管理用户所需的最小权限，实现管理用户的权限分离；安全审计要覆盖到每个用户，对重要用户行为和重要安全事件进行审计。 权限分得对不对，最终要看能不能审计到人、能不能追溯到他做了什么。

七步把权限矩阵落到系统里

第一步，盘点角色、数据和群。列出组织层级、岗位角色、现有群、群主、成员来源、文件类型，标出哪些群包含客户信息、交易指令、风控材料。完成标志是拿到一份角色清单、数据清单和群清单，而不是直接进后台改配置。

第二步，画权限矩阵。用角色做行，用通讯录、群组、文件、后台管理、登录访问、账号生命周期做列，每一格标允许、需审批或禁止。完成标志是矩阵能覆盖柜台、网点管理、后台职能三类典型角色，并且每个允许项都有业务理由。

第三步，搭组织架构。按总行、分行、支行、网点建树，条线和项目组单独建协作区，外部合作方放进独立的外部协作区。组织架构要和人力资源系统或 LDAP/AD 对得上，避免两套账号。完成标志是新员工入职能自动进入正确部门，离职能同步禁用。

第四步，配管理员和权限分组。系统管理员、部门管理员、普通成员分级；后台权限按权限分组配置，不直接给个人开超级权限。系统管理、安全管理、审计管理尽量分设，至少不能由同一个日常账号兼任。完成标志是每个管理员都能说清楚自己管什么、不管什么。

第五步，设访问边界。对柜台和后台分别设定允许登录的 IP 段或网络区域；移动端和外部访问单独评估；敏感岗位开启界面水印；有统一身份目录的，接入 LDAP/AD。完成标志是换一台不在允许范围的设备或网络，账号无法登录，或者登录后看不到不该看的内容。

第六步，管账号生命周期。入职开号、转岗调权、离岗锁定、离职回收，四个节点都要有责任人。离职时除了禁用账号，还要转移群主、移交文件归属、清理外部协作权限。外包和驻场人员单独建号，设定到期时间，不和工作量绑定。完成标志是随机抽查一个离职账号，确认无法登录，且相关群已有人接手。

第七步，试点和验收。先选一个网点和一个后台条线试点，用后面的五个场景测试，记录失败项，修正后再推广。权限变更前备份配置，变更后保留回滚方案。完成标志是验收清单全部通过，且业务部门确认没有影响正常协作。

四个容易漏掉的细节

共享终端和共享账号。 网点大堂、柜台的终端经常多人轮用。账号必须一人一号，交接班退出登录，终端设置自动锁屏。技术上可以限制登录 IP 和设备，制度上要把共用账号列为违规。

轮岗、顶班和临时授权。 柜员轮岗、网点负责人休假，都会产生临时权限。临时权限要有明确期限和审批人，到期自动失效，不能靠口头约定长期保留。

外包、驻场和外部协作。 外包人员不需要进内部通讯录。单独建外部协作区，只开放项目相关的人和文件，项目结束就停用。外部协作区里不要放客户身份信息和交易明细。

离职、调岗和群主转移。 账号禁用只是第一步。离职员工如果是群主，群会失去管理者；经手的文件也需要移交。把群主转移和文件归属转移写进离职流程，避免人员离开后群无人管理、文件找不到负责人。

用五个场景验收权限

权限设计完成后，不要只看配置页面，要按角色实际登录测试。下面五个场景可以直接作为验收用例。

测试场景	预期结果	失败信号
柜台账号搜索其他网点员工	搜不到，或只能看到公开信息	能翻到其他网点完整通讯录
网点管理员尝试把柜员拉进后台敏感群	需要审批，或被拒绝	直接拉人成功，无人记录
后台普通成员尝试转发敏感文件到外部	无法转发或下载，操作留痕	文件可以随意转发，无记录
离职账号尝试登录	立即失败，群主已转移	账号仍可登录，群无人管理
部门管理员尝试修改系统配置或查看无关群	无权限	能进后台修改配置或查看其他部门群

测试时至少覆盖 PC 端和移动端。移动端容易成为权限缺口，比如手机丢失、扫码登录、离线文件缓存。 移动端权限不是 PC 权限的附属品，要单独验证。

工具怎么选：先看权限模型，再看功能清单

选型时先问权限模型，不要先看功能列表。至少要确认六件事：组织架构能不能按总行、分行、支行、网点分层；有没有角色和权限分组；能不能做组织隔离或部门通讯隔离；通讯录可见范围能不能按层级设置；管理员能不能分权；账号离职回收和登录限制是否支持。

然后看部署和数据边界。金融机构如果要求数据留在自有服务器，私有化部署是前提；通信全加密、消息在数据库中加密存储、服务端文件加密存储，这些能力要按版本核对。界面水印、IP 登录限制、LDAP/AD 认证、组织隔离等高级安全能力，通常在专业版中出现，开源版以核心通讯能力为主。 不要假设所有版本默认具备同一套安全能力。

喧喧IM 的权限结构比较贴近这类场景。XXB 后台在用户菜单里维护部门和角色，在权限菜单里维护权限分组，账号和权限不是混在一起管理的；组织架构支持树形配置，可设置通讯录可见范围；后台管理权限可以细分，并在相应版本中提供部门通讯隔离、组织隔离、IP 登录限制、界面水印和 LDAP 认证等能力。它支持私有化部署和纯内网运行，数据留在企业自有服务器，适合对数据边界有要求的金融机构。详细的后台用户与权限操作可以看 XXB 后台的用户与权限管理。

安全能力的边界可以看 通讯安全能力。如果机构正在做私有化选型，可以先看 私有化部署方案。如果要在开源版和专业版之间做选择，先核对 开源版与专业版的功能差异。开源版免费开源、核心功能开放，专业版提供更丰富的高级安全能力，具体以当前版本和官方文档为准。

需要提醒的是，权限模型再细，也替代不了制度。 系统能限制能不能做，但决定该不该做的是岗位职责、审批流程和审计问责。 选型时把这句话放在功能清单前面，后面会顺利很多。

常见问题

柜台人员需要看全行通讯录吗

通常不需要。柜台日常联系的是本网点、运营、授权和必要的条线联系人。全行通讯录会增加信息暴露面，也会让柜台被无关消息打扰。需要跨网点协作时，用项目群按事授权，比开放全行通讯录更可控。

网点之间能不能互相看到通讯录

默认不建议。网点之间是平级组织，客户信息和人员信息没有必然的共享需求。确有业务协作时，可以开放必要的联系人，或者建跨网点项目群，但要有审批、期限和清退规则。

后台管理员能不能查看所有聊天记录

这取决于机构制度和产品能力，不能一概而论。更合理的做法是区分系统管理员、安全管理员和审计角色，按职责授予查看范围，并对查看行为本身留痕。如果机构要求消息留存和审计，要在选型时确认审计范围、留存周期、导出方式和版本差异。

外包和驻场人员怎么开权限

单独建号，放进外部协作区，只开放项目相关的联系人和文件，设置到期时间，项目结束立即停用。不要给外包人员内部通讯录的完整可见范围，也不要把客户身份信息和交易明细放进外部协作群。

开源版能不能做权限分组

开源版提供组织架构、用户管理和权限管理等核心后台能力，但组织隔离、IP 登录限制、LDAP 认证、服务端文件加密、数据库消息加密等高级安全能力，需要按版本核对。 先用开源版验证核心通讯和基础权限，再根据合规要求评估专业版。

权限划分没有一套通用模板。柜台、网点、后台只是三个观察角度，真正要落地的是组织层级、岗位角色、数据等级和沟通边界的组合。我的建议是，先选一个网点和一个后台条线，把权限矩阵画出来，用五个场景跑一遍，再决定要不要全行推广。 先把谁能看到谁、谁能做什么说清楚，再谈工具。

参考资料：

• 中国银监会《商业银行内部控制指引》（银监发〔2014〕40号），2014年
• GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》，2019年
• 中国人民银行 JR/T 0197-2020《金融数据安全 数据安全分级指南》，2020年