利唐 i人事连接器：默认只读+白名单写，安全怎么兜底

9月2日，WorkBuddy 在深圳举办生态发布会，"连接器"被纳入开放平台五大功能模块。利唐 i人事连接器已上架该平台——借这波行业关注，我们把连接器"默认只读、白名单写"的安全口径讲清楚。

一句话锚点： 接入安全这件事，不必逐接口去核对——默认全只读、只开两类写白名单，边界在提问那一刻就拦住了。

安全团队评估一个新接入，关心的永远是同一个问题：它能写什么。

因为"能读"多是数据外泄的风险，而"能写"意味着可能改数据、发动作。利唐 i人事连接器的设计反着来——默认全只读，写操作只开两类白名单。这篇讲清楚这套安全口径怎么审、为什么省心。

一、默认只读，风险面天然小

连接器覆盖 12 个业务能力域，其中 10 个默认只读。

只读意味着：它可以查考勤、查花名册、查组织、查审批、查薪资台账、查绩效明细，但没有任何写的能力。没有写，就没有"改数据、发错误动作"的风险，这一大块审查直接省掉。

对安全团队来说，默认只读的价值在于：要审的面，从一开始就砍掉了绝大部分。

二、写操作白名单：只有工单与面谈

需要写的地方，只有两类，而且都是 HR 日常需要"当场发起、有留存"的动作：

工单——创建、回复、关闭、重新激活与附件。每一笔从创建到关闭的流转，都有记录。

面谈——数字人面试与陪练、面谈与会议发起、会话文档读写与分享、自定义分析同步。每一次发起与纪要，都有留存。

除此之外，不发工资、不打分、不做录用决定。可写的面窄到只剩这两类，审查范围也随之聚焦。

三、权限模型：按角色校验

安全不只靠"少写"，还靠"谁看谁的"。

连接器用一套权限模型承接不同角色的问法：**提问先过角色校验，再返回对应范围的数据。**员工只能看到自己权限内的那一份，看不到别人的，也查不到团队的数据；经理看团队视图，HR 看全量。

权限校验沿用 i人事 的权限体系，不另起一套——这意味着谁能在系统里看什么，接入连接器后依然看什么，边界不变。

四、安全口径，怎么落地

把上面三点连起来，安全审查的路径就很清楚了：

先确认默认只读——10 个域没有任何写能力，风险面已经大幅收窄；

再核白名单——写操作只有工单与面谈两类，逐项列清楚，就这两块；

看权限校验——沿用 i人事 权限模型，角色校验后返回对应范围。

对比"逐个接口审能不能写、能写多少"的传统方式，连接器把审查从"开放了多少"变成了"只开了多少"，范围更窄、更聚焦，上线阻力也更小。

五、换个角度看：三种角色各自看到什么

安全不只是"少写"，还体现在"谁看谁的"。用三种角色的视角，把权限边界看得更清楚：

员工——问"我的"：我还有几天年假、考勤有没有异常、审批批到哪一步。返回的是自己权限内的那一份，看不到别人的，也查不到团队的数据。

经理——问"团队的"：团队考勤异常有几次、下属绩效得分是多少、编制还差几个人。返回经理权限下的团队视图，看不到非团队的。

HR——看全量：花名册、入转调离、组织编制、招聘流程都能查，同时也是能在白名单内发起工单与面谈的角色。

三种角色，同一套数据，各看各的。这层"按角色分权限"的设计，让安全审查不用纠结"谁可能越权"——权限边界在提问的那一刻，就已经校验过了。

六、安全选型，收尾核对三件事

安全审查走到收尾，用三件事做收尾核对：

**核对一，写操作是不是白名单。**确认写能力只集中在工单与面谈两类，其余全部只读。写操作越集中，审查越聚焦。

**核对二，权限是不是沿用现有体系。**确认接入后"谁看谁的"和原系统一致，不另起一套权限。边界不变，风险就不变。

**核对三，动作是不是有留存。**确认工单的每次流转、面谈的每次发起与纪要，都有记录可查。留痕，是安全审查的兜底保险。

三件事核对完，基本可以把"它安不安全"这个问题，落成"它收得够不够窄、留得够不够全"两个具体答案。

常见问题

Q：连接器会拿到我们全部的 HR 数据吗？

A：不会。连接器不是"一把钥匙开所有门"，而是按权限校验后，只返回提问者权限范围内的数据。员工只能看到自己的那一份，看不到别人的，也查不到团队的数据；经理看团队视图，看不到非团队；HR 看全量。各自能看到什么，由权限模型决定，而这个权限模型沿用 i人事 现有体系——谁在系统里能看什么，接入后依然看什么，边界不变。

Q：权限校验是谁来做的？

A：沿用 i人事 的权限体系，不另起一套。也就是说，连接器不是自己发明一套"谁能看什么"的规则，而是直接复用企业在 i人事 里已经配好的权限。谁在系统里能看什么，接入连接器后依然看什么，边界保持一致。这也意味着，企业不需要为连接器单独维护一套权限，权限变更跟着原系统走，安全团队审查时也少一块要核的内容。

Q：写操作会留痕吗？

A：会。写操作集中在工单与面谈两类白名单内，每一笔都有留存——工单从创建到关闭的每次流转、每份会话纪要的读写与分享，都有记录可查。这意味着任何一次"发起动作"都不是无迹可寻的：谁发的、发了什么、处理到哪一步，都能回看。留痕既是安全审查的要求，也是日常管理里"出了问题能追溯"的保障。

Q：安全审查的范围怎么缩小？

A：靠"默认只读 + 白名单写"这组设计。12 个业务域里 10 个只读、没有任何写能力，先砍掉绝大部分审查面——没有写，就没有"改数据、发错误动作"的风险。剩下的写操作只有工单和面谈两类，逐项核完就结束。对比"逐个接口审能不能写、能写多少"的传统方式，审查从"它开放了多少"变成"它只开了多少"，范围更窄、更聚焦，上线阻力也更小。

Q：员工能看到别人的数据吗？

A：不能。提问先过角色校验，员工查到的只是自己权限内的那一份——我的年假、我的考勤、我的审批、我的合同，看不到别人的，也查不到团队的数据。这是权限模型在提问那一刻就拦住的，不是"靠自觉"。所以员工在使用时不用担心越界，安全团队也不用担心"员工会不会顺手看到不该看的"，边界在提问发生时就已经校验过了。