软件实施交付转运维学习第五天：用户管理和权限管理

今天是软件实施交付转运维学习的第五天。前面四天我们分别了解了运维的基本概念、Linux常用命令。今天我们进入一个既基础又极其重要的模块——用户管理和权限管理。无论是操作系统层面还是应用系统层面用户和权限都是安全的基石。谁可以访问系统能看什么数据能做什么操作这些问题的答案都写在“用户”和“权限”这两个词里。一、为什么用户管理和权限管理如此重要在软件实施和运维过程中我见过不少事故起因往往很简单root账号被随意共享、普通用户被赋予了过高的权限、离职人员的账号没有及时注销……一个好的权限管理实践遵循最小权限原则——只给用户完成其工作所必需的最小权限不多给一分。举个例子一个只负责查询订单数据的运营人员不应该拥有删除订单的权限一个前端应用连接数据库的账号不应该拥有修改表结构的权限。用户管理和权限管理本质上回答三个问题你是谁—— 身份认证Authentication你能做什么—— 授权Authorization你做了什么—— 审计Audit二、Linux系统层面的用户管理作为运维人员首先要掌握操作系统层面的用户管理。以下以最常见的CentOS/RHEL系列为例。1. 用户相关文件Linux中用户信息主要存储在三个文件中/etc/passwd存储用户基本信息注意密码不在这里用x占位/etc/shadow存储加密后的用户密码只有root可读/etc/group存储组信息查看一个用户的详细信息id username # 输出uid1000(admin) gid1000(admin) groups1000(admin),10(wheel)2. 用户管理常用命令创建用户useradd -m -s /bin/bash newuser # -m: 创建家目录 # -s: 指定登录shell设置或修改密码passwd newuser删除用户userdel -r newuser # -r: 同时删除家目录修改用户属性usermod -aG wheel newuser # -aG: 追加到附加组不加-a会覆盖原有组3. 组管理组方便我们批量管理权限groupadd developers # 创建组 usermod -aG developers john # 将john加入developers组 groups john # 查看john所属的组三、Linux权限管理1. 基础权限rwxLinux的权限模型很经典读(r)、写(w)、执行(x)分别对应4、2、1的数值。查看文件权限ls -l 也可以简写成 ll # 输出示例-rw-r--r-- 1 root root 1234 Apr 9 10:00 config.conf # 解读-rw-r--r-- # 第1位-表示文件d表示目录l表示链接 # 第2-4位所有者权限u # 第5-7位所属组权限g # 第8-10位其他用户权限o2. 修改权限用数字方式最常用chmod 755 script.sh # 7421 (rwx)541 (r-x)用符号方式chmod ux script.sh # 所有者增加执行权限 chmod g-w config.conf # 所属组去掉写权限 chmod o-r secret.txt # 其他用户去掉读权限3.修改所有者chown 所有者:所属组 app.log # 同时修改所有者和所属组4. 特殊权限了解即可SUID让普通用户以文件所有者的权限执行该文件仅对可执行文件有效。SGID对文件让用户以文件所属组的权限执行对目录新创建的文件会继承目录的组权限。Sticky Bit主要用于公共目录如 /tmp限制只有文件所有者、目录所有者或 root 才能删除 / 重命名文件防止其他用户误删他人文件。四、应用系统的用户和权限实际操作中我们运维的更多是应用系统如CRM、ERP、OA。这些系统的权限模型虽然各不相同但万变不离其宗。1. 常见的权限模型RBAC模型Role-Based Access Control基于角色的访问控制是目前最主流的设计。它的核心思想是用户 → 角色 → 权限。用户具体的人或程序账号角色权限的集合如“销售经理”、“财务专员”、“系统管理员”权限对某个资源的某个操作如“订单-查看”、“用户-删除”这样做的好处是当有新员工入职时只需给他分配一个角色所有权限自动到位当某个岗位职责调整时只需修改角色包含的权限所有相关用户同步更新。2. 实施与运维中的注意事项在软件实施交付阶段我们需要帮客户梳理好权限体系这往往是项目中最容易被低估的工作量。实施阶段要做的事明确有哪些角色分别需要什么权限哪些权限是默认授予的哪些需要审批超级管理员账号如何管理建议双人持有、操作可审计运维阶段要做的事定期审计用户列表清理僵尸账号员工离职后及时禁用或删除账号这是很多安全事件的源头关注异常登录行为非工作时间、异常IP3. 数据库权限数据库层面同样需要严格控制-- 创建只读用户MySQL示例 CREATE USER readonly_user% IDENTIFIED BY strong_password; GRANT SELECT ON mydb.* TO readonly_user%; -- 应用账号建议只拥有DML权限不要给DDL权限 GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO app_userlocalhost;五、实战小案例假设场景我们部署了一个Web应用需要创建一个专门运行该应用的普通用户并确保日志目录可写但配置文件不可写。# 1. 创建应用用户不创建家目录指定shell为非登录 useradd -r -s /sbin/nologin webapp # 2. 创建应用目录 mkdir -p /opt/webapp/{bin,config,logs} # 3. 设置权限 chown -R webapp:webapp /opt/webapp chmod 755 /opt/webapp/bin chmod 750 /opt/webapp/config # 配置文件只允许webapp用户和组读取 chmod 775 /opt/webapp/logs # 日志目录可写 # 4. 以webapp用户启动应用不能用su - webapp因为nologin su -s /bin/bash -c java -jar /opt/webapp/bin/app.jar webapp六、常见错误与最佳实践常见错误直接使用root运行应用服务777权限遍地开图省事的代价是安全风险账号密码明文写在脚本里离职员工账号不及时清理最佳实践清单日常操作使用普通用户需要提权时用sudo严格配置sudoers不要给ALL(ALL) ALL重要操作通过sudo并配置日志审计定期执行last、lastlog查看登录情况应用之间使用独立账号互不干扰密码策略长度复杂度定期更换七、小结今天的主题是用户管理和权限管理。看似基础但真正做好的团队并不多。作为从实施转岗过来的运维人员我们有一个天然优势我们懂业务。知道谁该做什么、不该做什么这恰恰是设计好权限体系的灵魂。技术层面记住三个核心命令组就够了useradd/usermod/userdel、chmod/chown、passwd。更重要的是建立权限意识——任何时候能用最小权限解决问题就不要用更高权限。本文是“软件实施交付转运维”系列学习笔记的第五篇。从实施到运维不是从零开始而是能力的延伸和视角的转换。如果你也在经历这个转型欢迎一起交流。