昭通建站公司账号权限怎样分级：从观察、判断到复查的完整方法
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1302838c9751.html
📄
昭通建站公司账号权限怎样分级：从观察、判断到复查的完整方法
账号权限分级，本质是按“人需要做什么”来分配最小够用的操作范围，而不是按职位高低简单发账号。对于昭通建站公司承接的项目，常见角色包括客户方管理员、内容编辑、业务对接人，以及建站方项目经理、前端、后端和运维。分级的目标是让每个人只能碰自己该碰的部分，出问题时能查到是谁改的。
先观察：现有账号乱在哪里
动手改之前，先把现状摸清楚，常见现象有这几类：
- 多人共用一个后台账号，日志里只显示同一个用户名，无法定位操作人。
- 内容编辑拥有主题、插件甚至数据库的修改权限，改一篇文章却可能动到站点结构。
- 离职人员账号仍能登录，或密码长期未更换。
- 服务器、域名解析、建站后台三套系统各用各的账号，没有统一台账。
把每个账号列成一张表，记录：使用者、所属系统、当前权限、最近一次登录或操作时间。这张表是后续判断的依据，没有它，分级只能凭感觉。
判断：按操作风险划分层级
权限分级可以参考下面的四层模型，具体名称可以按项目习惯调整，关键是每层能做什么、不能做什么要写清楚。
- 只读层：只能查看后台数据、文章列表和统计数据，不能保存任何修改。适合客户方需要看进度但不需要动手的人。
- 内容层：可以新建、编辑、发布自己负责的文章和页面，可以上传图片，但不能改主题文件、插件、用户和站点设置。这是内容编辑、文案人员的常规层级。
- 管理层：可以管理用户、调整菜单和栏目、安装或停用插件、修改部分站点设置。适合客户方负责人和建站方项目经理。
- 技术层：可以改代码、动数据库、改服务器配置、管理域名解析。只给实际需要排障和部署的开发和运维，且尽量一人一账号。
判断某个账号该放哪一层，问三个问题：这个人日常要完成什么任务？这个任务最少需要哪些按钮？如果误操作，最坏会坏到什么程度？三个问题的答案基本就能定层。
处理：把分级落到具体系统
不同系统的权限颗粒度不一样，落地方式也不同。以常见的自建站程序为例，后台一般有“管理员、编辑、作者、投稿者”这类内置角色，可以在此基础上微调，而不是从零自建。下面是一段示意性的角色配置思路，仅作说明，实际字段以所用程序为准：
角色：内容编辑 → 允许：发布文章、上传媒体 → 禁止：安装插件、编辑用户、修改固定链接
服务器和域名侧同样要分级。服务器登录建议每人一个密钥或账号，禁止共享 root；域名解析后台只给一到两人管理，变更前留记录。数据库账号按用途分开，网站运行账号不给建库删库权限。
执行时按这个顺序做：先建好角色和权限模板，再逐个把现有账号归入对应角色，最后处理共享账号——能拆分的拆分，拆不了的至少改密码并登记使用人。每改一个账号，就在台账上更新一次。
复查：确认分级真的生效
改完不等于生效，需要用实际账号验证。检查项包括：
- 用内容层账号登录，尝试进入插件或用户管理页面，应被拒绝或看不到入口。
- 用只读层账号尝试保存一篇文章，应无法提交。
- 查看操作日志，确认能区分不同账号的动作。
- 核对台账，确认没有遗漏的旧账号和测试账号。
如果验证时发现某个角色仍能越权操作，说明权限模板没配对，回到上一步调整，而不是临时给个人加权限绕过。复查建议在每次人员变动、项目交付和重大改版后各做一次。
下一步，先把你手上这个项目的账号台账列出来，标出每个账号当前层级和实际需要的层级，两者不一致的就是要处理的对象。
