去年十月，一个做家居品类的跨境卖家找到我，说他们一个主力链接被改成了 1 折，持续了将近六个小时才被发现。直接损失加上后续的排名下滑，折算下来大概四十多万人民币。
排查的过程比损失本身更让人难受。后台日志显示，那次改价来自一个三个月前就已经离职的运营账号。这个账号没有停用、没有改密，权限还是当初的"全店铺、全品类、可改价"。在这三个月里，没有任何一个在职员工知道它还能登录。
这件事之后，我复盘了手上二十多个跨境电商团队的账号与权限问题，得到一个有点反直觉的结论：绝大多数被归因为"权限管理没做好"的事故，真正的失效点其实在账号层，而不是权限层。权限表本身往往是对的，错的是那张表背后站着的人。
所以这篇文章我不打算讲"权限管理有多重要"。我想给的是一套可以直接拿去对照的诊断逻辑：先把账号问题和权限问题拆开，再按"人、号、权、行"四个断点逐层排查，最后决定先修哪一层、暂缓哪一层、放弃哪一层。中间的落地案例我用自己实际配置过的数跨境环境来说明，涉及具体数字的地方我会标注口径，哪些是观测、哪些是推演，我会说清楚。
大部分人一谈权限管理，第一反应是角色、菜单、按钮、数据范围。这些都是第二步。第一步永远是一个更朴素的问题：现在用这个账号的人，是不是我们以为的那个人？
这两个问题经常被混在一起谈，但它们的技术对象完全不同。身份核验关心的是凭证是否被正确的人持有；权限授权关心的是这个身份能触达哪些对象、执行哪些动作。前者失效，后者就变成一张写着漂亮规则却没人遵守的纸。
我见过的典型症状是：团队花了两个月把角色矩阵做得非常精细，运营、客服、采购、财务各有一套权限，结果一次价格事故照样发生。原因很简单，那套角色矩阵是按人配的权限，但人用的账号是一个共用主账号。精细的权限挂在一个不可信的身份上，等于没做。
我把账号安全拆成三层闭环，顺序不能颠倒：
三层的关系是：第一层不成立，第二层就是装饰；第二层不成立，第三层只能事后追责；第三层不成立，前两层出了问题你也发现不了。很多团队是"第二层做得最好、第一层最差、第三层基本没有"，这正好是最脆弱的组合。
如果你只想记一句话，记这个：当一笔异常操作出现时，你能否在十分钟内说出"这是谁的账号、他当时该不该有这个权限、他什么时候拿到这个权限的"。
能，说明你的账号安全基本成立，剩下的是优化问题。不能，那你的问题不在权限表上，在账号生命周期的管理流程上。后面的诊断，全部围绕这个判断标准展开。
账号数量增长有一个容易被忽略的特征：它跟人数的关系不是线性的，而是跟"业务组合"的关系更大。三个人守一个店铺时，账号可能只有两个；十二个人管六个店铺、四个平台、两个站点时，账号数量会跳到三四十个，因为每个平台后台、每个 ERP 环境、每个数据工具、每个广告账户都要有对应的登录入口。
更麻烦的是，这些账号之间的对应关系没有天然的记录人。人在增多，账号在增多，但"谁负责哪个账号"这件事，通常只存在于某个人的记忆里。记忆一旦离职，管理就断档。
场景一：主账号成了"公共工具"。主账号有全店铺权限，方便，于是旺季时大家一起用。方便的结果是，日志里所有操作都显示为同一个人，出了事只能靠回忆和互相印证来定位，而这个过程的成本往往比损失本身还高。
场景二：子账号借来借去。某个同事休假、某个店铺临时没人管，就把子账号给另一个人用。这在技术上完全合规，在管理上却制造了一个盲区，账号背后的身份和实际操作人不一致。假期结束账号还回去，但没有人改密码，也没有人复核这几天的操作。
场景三：离职流程只管到工位，管不到账号。很多团队的离职交接清单里有电脑、有门禁卡、有企业微信，唯独没有"账号清单"。尤其是那些不在核心名单里的人，临时客服、外包美工、离职前只做了一个月的助理，他们的账号往往被彻底遗忘。
国内电商团队的账号结构通常是两层：平台后台 + 内部系统。跨境团队是三层，而且三层的权限模型互不相同。
| 层级 | 典型对象 | 权限特征 | 最容易失控的点 |
|---|---|---|---|
| 平台侧 | 各站点卖家后台 | 主账号权力极大，部分操作不可逆 | 主账号共用、子账号超范围授权 |
| ERP / 数据侧 | 订单、库存、刊登、数据看板 | 可以批量操作，影响面广 | 批量改价、批量改库存、导出客户数据 |
| 服务商侧 | 代运营、外包设计、物流对接 | 由外部人员持有，不受内部人事流程约束 | 边界模糊、离职不通知、权限只增不减 |
三层叠在一起，就会产生一个典型问题：平台侧收紧了，ERP 侧没同步；ERP 侧收紧了，服务商侧还是老样子。任何一层的短板都会让另外两层的投入打折。这也是为什么我要强调"先修账号"，账号是三层里唯一共通的载体，账号边界清楚了，三层的权限才有对齐的基准。
我把账号与权限的诊断拆成四个断点。这套框架的好处是每一层都能独立打分，避免"整体感觉不安全"这种没法执行下去的结论。
人的断点核心不是"人不可靠"，而是"人的状态变化没有被流程捕捉到"。入职时为了不耽误业务，账号往往一小时就开好；离职时因为各种原因，账号回收经常拖到一周以后，甚至不回收。
这里有一个很现实的矛盾：入职开账号的速度，和离职收账号的速度，在大多数团队里是不对等的。开得快是因为业务在等，收得慢是因为没人催。这个不对称，就是风险的来源。
自问句：这个账号现在的责任人是谁，如果明天他离职，谁负责处理它？
号的断点有三个层次。最严重的是主账号共用，因为它直接摧毁了可归因性。其次是子账号借用，它摧毁的是身份真实性。第三层是外部服务商账号，它摧毁的是管理边界的完整性。
值得单独说的是第三层。代运营、外包美工、物流服务商这些角色，在业务上是"半个同事"，在管理上却是完全的局外人。他们的账号既不在人事流程里，也很少出现在权限复核清单上。我见过一个团队，代运营换了公司，前一家公司的账号还在系统里，权限是"可查看全部财务数据"。
自问句：除了在职员工，现在还有多少外部账号可以登录我们的系统？
权的断点有三个常见形态。第一是"一刀切"，要么全开要么全关，因为细分角色的成本太高。第二是"不同步"，岗位变了权限没变，从运营转到客服的人，还留着改价的权限。第三是"不复核"，权限只有增加没有减少，半年之后没人说得清某个账号到底能干什么。
这三个形态里，危害最大的是"不同步"，因为它制造的是隐性权限。当事人自己可能都忘了还有这个权限，管理者更是完全不知情，直到某天这个权限被用到。
自问句：有没有一个账号，它的权限范围超过它当前岗位实际需要的范围？
行的断点有两种：一种是日志根本没有，另一种是日志有但没人看。后一种更常见，也更容易让人产生虚假的安全感。
日志的价值不在于"出事之后能复盘"，而在于"日常有没有人在看异常"。如果一份日志只在事故后被打开，那它本质上是一个昂贵的赔偿依据，而不是一个预防工具。真正有用的做法是定义几个会触发查看的阈值：单次改价幅度超过多少、非工作时间登录、同一账号短时间跨地域登录、批量导出超过多少条记录。
自问句：上一次有人主动看操作日志是什么时候，因为什么？
我会让团队按 1 到 10 分给自己打分，分数越高代表风险越大。下面这个对照表可以直接用。
| 断点 | 低风险（1-3 分） | 中风险（4-6 分） | 高风险（7-10 分） |
|---|---|---|---|
| 人 | 入职与离职都有账号清单，回收有时限要求 | 离职有口头交代，但无书面清单 | 离职流程完全不含账号环节 |
| 号 | 一人一号，外部账号单独管理且定期复核 | 主账号少数人共用，子账号偶尔借用 | 主账号多人共用，外部账号无人清点 |
| 权 | 按岗位建角色，岗位变更触发权限变更 | 按人配权限，变更靠临时通知 | 权限只增不减，从不复核 |
| 行 | 有日志，有异常阈值，有人定期看 | 有日志，但只在出事后查 | 日志不可查或无法归属到人 |
这是最普遍的误区。团队做完角色矩阵，心理上就认为安全问题解决了。但如果身份层没有收紧，角色矩阵只是在描述"一个共用账号可以做什么"，而不是"某个人可以做什么"。
判断方法很简单：如果你的权限表里，同一个角色被多个人共用同一个登录凭证，那这套分级在追溯层面等于不存在。
账号安全的触发点几乎全部来自业务侧：新人入职、员工离职、岗位调整、新开店铺、接入代运营。这些动作没有一个发生在 IT 部门。IT 能提供工具和规范，但真正的执行者是用人部门。
所以当我在一个团队里听到"账号安全是技术同事在管"，我基本就能预判他们的离职账号回收会出问题，因为技术同事永远不知道谁离职了。
权限管理有一个特点：它是会自然回退的。你今天清理干净，三个月后新招五个人、新开三个店铺、换一家代运营，权限就又长回原样。这不是执行力问题，是组织变化的必然结果。
把权限管理当成一个项目，它就会在项目结束的那天开始退化。把它当成一个例行动作，它才有持续性。
很多系统都提供操作日志，于是团队认为这一项已经完成。但日志有三个维度决定它是否有用：能不能归属到具体的人、能不能按对象检索、能不能覆盖关键动作。
如果日志只能按时间顺序往下翻，不能按"某个店铺"或"某个商品"去查，那它在真实排查场景里的价值会大打折扣。我见过太多团队花几个小时在日志里翻页，最后放弃了。
外部账号的特殊性在于，它脱离了内部人事流程。员工离职你会知道，代运营合同结束你不一定第一时间知道；员工转岗有记录，外包美工换人往往只是群里说一声。
更麻烦的是，外部账号的权限通常开得比内部还宽，理由是"方便他们做事"。这是一个短期省事、长期埋雷的典型取舍。
权限不是同等重要的。我会先把所有操作分成两类：不可逆的和可逆的。改价、删除商品、提现、修改收款账户、删除客户数据，这些属于不可逆；查看数据、导出报表、创建草稿，这些属于可逆。
不可逆动作的权限，无论团队成员多资深，都应该单独收紧。可逆动作的权限可以相对宽松，因为它最坏的结果是返工。这个切分方式比按岗位切分更有效，因为它直接对应损失的形状。
按人配权限的团队，管理成本会随人数平方级上升。按岗位建角色，管理成本跟岗位数量的关系更接近线性。更重要的是，岗位是稳定的，人是流动的，你的权限体系应该建立在稳定的那一层上。
这里有个实操细节：角色不要建得太细。我见过一个团队为了"精确授权"，建了二十多个角色，结果没人记得清每个角色的差异，最后大家默认给了最宽的那个。角色数量的合理区间，通常是 5 到 10 个。
这是我认为最关键的一条判断。账号安全做不好的团队，问题几乎都不是技术能力，而是账号的开立与回收没有触发条件。它依赖某个人的记忆，而记忆是不可靠的。
正确的做法是让账号动作成为人事动作的强制步骤。入职流程走完才能拿到账号，离职流程不完成账号回收就无法结清。把账号清单写进交接单，比写进任何制度文件都有效。
如果你的资源只够做一件事，我建议做可追溯性，而不是可限制性。原因很实际：限制会被绕过（"帮我改一下"），但追溯无法被绕过，只要有日志，动作就一定留下了痕迹。
可追溯还有一个隐性好处：当人们知道自己的操作会被记录并可能被查看时，行为会自然趋于规范。这是一种比制度约束更便宜的管理手段。
我会用这一个问题去检验所有改进措施。角色矩阵能不能回答？能，权限变更日志会记录。二次验证能不能回答？能，登录记录会记录。账号回收能不能回答？只能部分回答，需要有人执行并在系统里留痕。
凡是无法回答这个问题的措施，我都会把它排到后面，因为它无法进入管理闭环。
去年底我参与了一个跨境卖家的账号体检。团队 12 人，运营 6 个店铺，覆盖三个平台两个站点，年 GMV 大概 8000 万。他们的数据中枢用的是数跨境，日常的订单汇总、库存看板、利润核算都在上面跑。
找我的起因不是事故，而是一次内部争议：一批库存数据对不上，运营说是采购改了，采购说没动过，最后谁也没说服谁。这种情况其实已经是强信号，当一件事说不清是谁做的时候，账号体系已经开始失效了。
很多人以为账号盘点是查表，其实是查人。我先让他们把三个东西列出来：所有能登录数跨境的成员、所有能登录各平台卖家后台的账号、所有外部人员持有的访问凭证。
结果比预想的多。系统里活跃成员 12 个，但有 3 个是已经离职或转岗的；平台后台有 2 个共用主账号，实际使用人超过 6 个；外部还有一家代运营和一位外包美工持有查看权限。也就是说，名义上 12 个人的团队，实际可以触达系统身份的有 19 个。
盘点这一步不需要任何技术能力，只需要耐心和一份清单。我把清单模板写成了可以直接复制的形式：
账号盘点清单（每个账号一行）
─────────────────────────────
账号标识 | 姓名/归属 | 身份类型 | 在职状态 | 最近登录 | 权限范围 | 责任人 | 处理动作
ops_a* | 张某 | 内部员工 | 在职 | 今日 | 全店铺 | 运营主管| 保留，降为分店铺
ops_old* | 李某 | 内部员工 | 已离职 | 87天前 | 全店铺 | 无 | 立即停用
vendor_dy*** | 某代运营 | 外部服务商| 合作中 | 3天前 | 全店铺只读| 运营主管| 收窄为2个店铺
─────────────────────────────
统计口径：以盘点当日系统成员列表为准，含停用状态但未清理的账号
这份清单我自己用了很多次，它的价值在于把"感觉上有很多账号"变成了"确切的 19 个，其中 3 个必须马上处理"。
这个团队原来的做法是按人配权限：谁需要什么，就加什么。时间一长，权限表变成了一堆个性化配置，没人说得清每个账号到底能干什么。
我帮他们做的第一件事是把权限从人身上挪到岗位上。数跨境的成员管理里可以按角色划分可见范围和数据操作范围，我就按他们的实际岗位建了 6 个角色：运营主管、店铺运营、客服、采购、财务、只读观察员。
关键的取舍在于把"改"和"看"彻底分开。财务和客服只保留只读，采购只保留库存相关动作，店铺运营按店铺维度授权而不是全店铺。运营主管保留跨店铺权限，但数量从原来的 6 个人压缩到 2 个人。
一个实操建议：角色名就用岗位名，不要用"高级权限""普通权限"这种模糊词。模糊的角色名会在半年后让你无法判断谁该在哪个角色里。
前面两步解决的是存量问题，第三步解决的是增量问题。我们定了一条规则：任何人的账号变更，都必须由用人部门在系统中发起，并且留下一条记录。
具体到动作上只有三条：入职当天开账号，并在盘点清单里登记；岗位变更当天调整角色；离职当天停用账号并改密，由运营主管确认。
为了让这条规则真的能执行，我建议他们把账号清单放进了离职交接单的第一项。因为离职交接单是必须签字的东西，把它放在第一项，就不会被忘掉。
最后一步是把"有日志"变成"日志有人看"。我们定了四个触发查看的阈值，写进运营主管的周例行事项里：
这四个阈值不是安全规范，而是管理抓手。它们的意义在于把"要不要看日志"这个模糊决策，变成"有没有触发阈值"这个明确判断。
三个月后我回访过一次。下面这些数字是他们自己统计的，口径是系统后台的操作记录与内部工时统计，我做了脱敏。
| 观察指标 | 整改前 | 整改后（第 3 个月） | 变化说明 |
|---|---|---|---|
| 可登录账号总数 | 19 个 | 13 个 | 清理了离职与冗余账号，外部账号从 2 个保留至 1 个 |
| 主账号持有者数量 | 6 人 | 2 人 | 改为一人一号后，跨店铺权限集中在主管层 |
| 账号盘点耗时 | 约 16 人时/月 | 约 4 人时/月 | 因为有了清单模板和角色体系，盘点变成核对而非重建 |
| 异常操作定位平均耗时 | 约 21 小时 | 约 3.5 小时 | 账号可归属后，从"排查所有人"变成"查一个人" |
| 权限变更留痕覆盖率 | 约 45% | 100% | 所有变更走系统发起，不再有口头授权 |
需要说明的是，这些数字不代表所有团队都会有同样的改善幅度。团队的基础管理水平和业务复杂度差异很大，我更希望你看的是变化的方向，而不是具体的倍数。
止血层的目标是消除"明天就可能出事"的敞口，不追求体系化。三件事，一周内可以完成。
这三件事的共同特点是：不依赖任何新系统，只依赖一个决定。它们能覆盖相当一部分"凭证被盗"和"离职人员回归"类风险。
制度层解决的是"以后怎么办"。核心是两件事：角色矩阵和授权审批。
角色矩阵的关键是确定"谁有权批权限"。我的建议是：不可逆动作的权限，由业务负责人审批；可逆动作的权限，由直属主管审批。这个分级让审批成本跟风险大小挂钩，避免所有事都往上报导致流程被绕过。
同时要明确一条：跨店铺、跨平台的权限，必须走更高一级审批，并且要有明确的到期时间。没有到期时间的权限，就是永久权限。
系统层的重点是三件事：角色在系统中的落地、店铺维度的授权收口、操作日志的可检索性。
这里我想强调"可检索性"。很多团队以为日志是系统自带能力，不需要投入。但真正的落地工作是确定哪些动作必须留痕、按什么维度检索、留存多久。这三件事定不下来，日志就只是个存着没人用的文件。
如果你用的是像数跨境这类把多店铺数据集中处理的环境，建议先把店铺维度的可见范围收口，再谈动作权限。原因是数据可见范围决定了"谁能看到什么"，它比"谁能做什么"更早产生风险，信息泄露往往比误操作更难挽回。
持续层的全部内容就是一件事：把复核变成例行动作。我建议的节奏是：每月一次账号清单核对，每季度一次权限矩阵复核。
月度核对只看三件事：有没有新增账号没有登记、有没有离职人员账号没回收、有没有外部账号到期没处理。季度复核看的是角色本身有没有需要调整的地方。前者是执行检查，后者是体系检查。
下面这份清单按四个断点分组，每条都是可以明确回答"是"或"否"的句子。如果超过三条答"否"，建议先从止血层开始。
| 断点 | 自查项 | 合格标准 |
|---|---|---|
| 人 | 是否知道当前所有能登录主账号的人及其数量？ | 能立即说出确切数字和姓名 |
| 离职人员账号是否在 24 小时内被停用或改密？ | 有记录可查，最近一次符合要求 | |
| 岗位调整后，权限是否在同一周内同步变更？ | 变更留痕，且能追溯到发起人 | |
| 号 | 主账号是否只由不超过 2 人持有？ | 超出即视为不合格 |
| 是否存在子账号借用、代登录的情况？ | 最近一个月内没有发生过 | |
| 外部服务商账号是否有明确到期时间？ | 每个外部账号都有到期日 | |
| 权 | 权限是按岗位配置，还是按个人配置？ | 按岗位配置，角色数量在 5-10 个之间 |
| 是否有人拥有超出当前岗位范围的权限？ | 复核后为零 | |
| 最近一次权限复核是什么时候？ | 在最近一个季度内 | |
| 行 | 关键动作（改价、改库存、提现、导出）是否全部留痕？ | 覆盖率达到 100% |
| 日志能否按店铺、按商品、按账号检索？ | 至少支持按账号和店铺检索 | |
| 是否定义过触发查看日志的异常阈值？ | 至少有 3 条明确的阈值规则 |
没有一种账号安全方案适合所有团队。资源有限的时候，取舍比方案更重要。下面是我按团队规模给出的判断。
这个阶段最不需要的是复杂的角色矩阵。三个人五个角色，只会让大家觉得烦，然后一起用主账号。
我认为这个阶段只需要三条：一人一个账号，不许共用；离职当天停用账号；不可逆操作两人确认。这三条不需要任何系统支持，靠约定就能做到。真正要放弃的是"日志体系"和"精细化角色"，成本太高，收益太低。
这是最关键的阶段。团队已经有分工，但还没形成惯性；账号数量从十几个涨到几十个，靠记忆已经管不住了。此时建角色矩阵、定授权审批规则，成本可控，效果立竿见影。
这个阶段要放弃的是"一次做到完美"。角色不要建太细，先把不可逆动作的权限收住，剩下的可以分两次迭代。同时，把账号清单模板做出来，后面所有管理动作都基于它。
这个规模下，规则通常已经有了，问题在于执行会走形。新人入职多了，主管没时间逐一配置权限，就会倾向于"先给个宽的，以后再收"，而"以后"永远不来。
这个阶段的重点是把复核变成例行动作，并且让复核结果可查。同时建议把权限变更纳入管理者考核，不是因为安全重要，而是因为这是唯一能让管理者持续关注的方式。要放弃的是"靠自觉"，这个规模下自觉已经不够用了。
到这个规模，账号与权限管理已经是一个独立职能，兼职做不下去。需要有人专门负责账号生命周期、权限复核和外部账号管理，并且这个人要有跨部门的权限去推动。
这个阶段要放弃的是"统一一套权限打天下"。多主体、多站点、多平台的团队，往往需要按业务单元做权限分区，这会增加管理复杂度，但比全局混在一起更安全。
这是一个单独的取舍。服务商账号的便利性和安全性天然冲突：给得宽，服务商效率高；给得窄，沟通成本高。
我的建议是按"是否需要写入"来分。只读权限可以开得宽，写入权限按动作逐个开，且必须设定到期日。更进一步的做法是给服务商单独建账号，而不是发一个内部账号的临时权限，这样在日志里就能一眼区分内部操作和外部操作。
回到开头那个案例。那件事真正的教训不是"权限给多了"，而是一个已经离开的人，仍然握着一把能打开所有门的钥匙，而没有人知道这把钥匙还在。
权限体系描述的是"能做什么"，它只有在身份可信的前提下才有意义。所以我的建议顺序始终是：先修账号，再谈权限，最后完善留痕。这三步的投入产出比差异很大，把顺序做反，就会出现"权限体系很精致、事故照样发生"的尴尬局面。
另外我想强调一个容易被忽略的视角：账号安全的第一价值不是防住坏人，而是让管理变得可归因。当一个团队能清楚说出"这件事是谁做的、他该不该做、他什么时候有这个权限的"，很多管理问题会自然消解，不是因为大家变谨慎了，而是因为模糊空间消失了。
如果你现在就想动手，我的建议是三件事按顺序来：
三个月后再回头看，你会发现改善最大的往往不是"风险降低了多少"，而是"出事之后，大家不用再互相怀疑了"。这大概是我做这类项目时，最有成就感的部分。
我自己是运营负责人，团队从3个人扩到十几个人，主账号密码在群里传过好几手，一直觉得能用就行。直到前段时间出了一次改价事故，谁都说不清是谁改的、什么时候改的，我才开始怀疑问题不在人，在账号本身。我就想知道，共用主账号的真实代价到底在哪，以及有没有不太折腾的改法。
共用主账号的核心代价不是通常说的被盗号，而是不可归因。一旦多人共用，任何一次误操作、误改价、误删listing都只能追到账号，追不到自然人，管理动作就失去了依据。改法可以分三步走：第一步把主账号降级为只做授权、不做日常操作的管理入口，日常运营一律走各自的子账号；
第二步按岗位建角色再授权，人员变动时只调角色归属，不再逐个勾权限；第三步主账号密码由一到两个人掌握并封存，需要登录时走登记。一个可用的判断标准是，如果一次异常操作发生后，你无法在十分钟内说出这个动作是哪个自然人、在什么时间、从哪个IP或设备做的，就说明账号层已经失控，这时候再谈权限分级意义不大。
上次有个运营离职，交接了一堆表格就走了，账号我隔了快一周才想起来去停。当时也没出什么事，我就没太当回事。后来听说有离职人员用旧账号登进去看数据、甚至动listing的，我才有点慌。我想知道离职账号回收有没有一个明确的时间节点和动作清单，而不是靠记性。
离职当天、最晚T+1是应该守住的节点。具体做三件事：一是停用或删除其子账号，并检查这个账号在ERP里是否还挂着未完成的审批或授权；二是修改他接触过的所有共享凭证，包括主账号、店铺后台、绑定邮箱和企业邮箱；三是回收其绑定的手机号、邮箱以及可能存在的浏览器保存登录态。
如果他本身是管理员或有授权权限，还要做一次倒查，看看他授权出去过哪些账号，一并复核。特别提醒一点，不要因为删号把历史操作日志一起清掉，很多团队在事故复盘时才发现日志已经随账号删除了。判断依据不是账号列表里还有没有这个人，而是他是否还持有任何能绕过后台登录的凭证。
我一开始是给每个人单独勾权限，谁要什么就给什么，觉得这样最灵活。后来人一多，我自己都记不清谁有什么权限了，有人转岗、有人离职又回来，权限就越堆越多。我现在拿不准的是，角色化管理听起来像是大公司才需要的东西，小团队直接按人配是不是反而更省事。
按人配最大的问题是权限只增不减，人走了权限容易被忽略，人转岗了旧权限还在。做法上建议先建四到六个基础角色，比如运营、客服、采购与供应链、财务、主管或管理员，把权限挂到角色上，人员变动时只改他属于哪个角色。小团队同样适用，因为角色的数量取决于岗位类型而不是人数，二十个人很可能也只有四种岗位。
一个简单的判断标准是，如果一次岗位调整需要你打开权限配置页勾选超过三次，就说明这个环节该角色化了。另外有一条内控红线建议守住：任何角色都不应同时拥有修改价格或金额的权限，和审批自己发起的变更的权限，这两项合在一起，等于给误操作和内部风险开了绿灯，而这一条恰恰是最容易被忽略的。
后台确实有二次验证也有一堆日志，我该开的都开了，但说实话平时基本没看过。每次都是出了事才回头翻，还经常翻不到想要的时间段和操作对象。我不确定这些功能是要怎么用才算真正起作用，还是说开了就等于安全了，所以想问一个能自测的口径。
开了不等于有用，可以从三个口径去核对。第一是二次验证的覆盖面，不能只有管理员开，所有能登录主账号、以及能操作资金、价格、库存的账号都要强制开启，否则等于留了一扇没锁的门。第二是日志的可回答性，一份够用的日志至少要能回答四个问题：谁做的、什么时候做的、做了什么、从哪里来的。
其中做了什么要细到动作加对象，比如改了哪个店铺哪个SKU的价格、从多少改到多少。如果日志只有某某登录成功这类记录，事后归因是做不了的。第三是留存与导出，确认留存周期能否覆盖你的业务复核周期，比如月度对账或季度审计，以及能不能导出成表格。
最后是使用方式上的建议，把查日志从应急动作变成例行动作，每周抽查一次高风险操作，比如改价、改库存、批量上下架、导出客户数据，每月做一次账号盘点。如果你现在能立刻拉出上周所有改价操作及其操作人，说明配置基本可用，拉不出来就先补日志覆盖范围，再谈其他加固。
读者评论
账号层比权限层更关键这个判断我认同。我们公司权限矩阵做了三轮，角色分得很细，结果去年一次批量改价还是查不到人，因为运营组共用的是同一个主账号。精细的权限挂在不可信的身份上，确实等于没做。
作为运营说句实话，主账号共用很多时候是效率逼出来的。旺季临时调价、跨店铺接单，开子账号要走审批，等批下来链接已经凉了。文章说要先收紧账号层我理解，但如果不同时给出审批提速方案，一线还是会绕回去。
四个断点的自评表很实用，我照着给自己团队打了一遍，权的断点拿了七分。但打分本身太主观，同一件事不同人打出来能差三分。建议配合固定的季度复核节奏，否则打分只是又一次自我安慰。
文章里那张归因分布图标注了样本推演，这点比较诚实。但主账号共用占三成、离职账号占两成四这些比例，如果只是二十多个团队的复盘推演，拿来当行业分布参考还是要谨慎，方向可信，数字别当基准。
日志那块戳到痛点了。我们不是没有日志，是从来没人看，出事才翻。真正难的不是搭日志，是定阈值和排值班，阈值定紧了全是误报，定松了等于没有。这块文章提了方向，但落地成本其实比账号回收更高。