服务器常用的组，主要分四类：Linux用户组、系统服务组、云安全组和资源/放置组。 Linux用户组管账户与文件权限，系统服务组管守护进程身份，云安全组管网络访问，资源组管云上分类与权限边界，把这四类分清楚,排查权限问题和配置安全组时就不会张冠李戴。
服务器常用的组有哪些？先把“组”的边界划清楚
很多人搜“服务器常用的组有哪些”，其实答案取决于你站在哪一层看，操作系统里，组是账户的集合；云平台里，组又可能是网络规则集合或资源集合，它们都叫“组”,但管理对象完全不同。
![[网络科普]大白话讲明白网络六种服务器类型](https://i0.hdslb.com/bfs/archive/430d1ce380dffbd16d8e432cd4fe651440f68575.jpg)
Linux服务器用户组和权限组有什么区别
Linux用户组记录在/etc/group里，用户的主组记录在/etc/passwd，组密码通常在/etc/gshadow，主组是用户创建文件时默认归属的组，附加组是额外获得的权限来源，权限组则更强调“授权”，比如sudo、wheel、adm、docker，它们本质上也是用户组,只是被系统或管理员赋予了特殊能力。
实操中,常用查看命令如下：
id alice：查看用户UID、GID和所属组groups alice：只看组名getent group sudo：查看某个组的成员cat /etc/group：列出所有组grpck：检查组文件一致性
主组和附加组的区别，直接影响新建文件的归属。 比如用户alice主组是alice，附加组是developers，她把文件保存到启用了SGID的目录，文件组才会继承developers，而不是默认的alice。
| 组类型 | 主要作用 | 典型名称 | 管理入口 |
|---|---|---|---|
| 主组 | 用户默认文件归属 | alice、ubuntu | /etc/passwd |
| 附加组 | 额外权限来源 | sudo、developers | /etc/group |
| 权限组 | 管理授权与提权 | sudo、wheel、docker | sudoers、/etc/group |
| 系统服务组 | 运行守护进程 | www-data、mysql、postgres | 服务配置、ps命令 |
系统服务组和守护进程组：进程也有“户口”
Nginx、MySQL、PostgreSQL、Docker、systemd-journal等，多数情况下会以专用用户和专用组运行，这样即使服务被攻破,攻击者拿到的也不是root权限。
查看方式很直接：
ps -eo user,group,comm | grep nginxps -eo user,group,comm | grep postgresgetent group docker
这里要特别说docker组，加入docker组的用户，通常可以启动挂载宿主机根目录的容器，实际权限接近root，中小公司图省事，常把开发人员直接塞进docker组，风险不小，更稳妥的做法是用rootless容器、Podman，或通过CI/CD平台代发。
云服务器安全组和用户组有什么区别
这是最容易混淆的一对。用户组在操作系统里，安全组在云网络层。 用户组决定谁能读文件、谁可执行命令；安全组决定哪些IP能访问22、80、443等端口，一个管“人”，一个管“流量”。
云安全组通常绑定实例或弹性网卡，入方向规则控制进来，出方向规则控制出去，配置路径一般是：云控制台 → 网络与安全 → 安全组 → 创建安全组 → 添加规则 → 绑定实例。
以开放SSH为例，别写0.0.0/0，可改为公司办公网段，例如0.113.0/24，再配合堡垒机，数据库端口3306、6379、27017也不要对公网开放,只允许应用服务器安全组访问。
除了安全组，云上还有资源组和放置组，资源组用于分账、分权、分类，电商项目”“测试环境”“财务系统”，放置组影响实例物理分布，分散策略适合高可用，紧凑策略适合低延迟集群，它们不替代系统用户组,而是补充云资源治理。
中小公司服务器运维常用组怎么设置
中小公司人手少，往往一人多岗，组设计要简单，但不能所有人共用root，可以按角色建组：运维组、开发组、数据库组、审计组。
网站发布场景可以这样落地：
- 创建发布组：
sudo groupadd deploy - 把开发加入发布组：
sudo usermod -aG deploy alice - 修改站点目录属组：
sudo chown -R :deploy /srv/www - 设置SGID，让新文件继承组：
sudo chmod 2775 /srv/www - 让用户重新登录或执行
newgrp deploy使组生效
数据库场景别让应用直接用root连接，MySQL可建
app_rw用户并限制来源IP，PostgreSQL用GRANT控制schema权限，运维提权场景，用sudo或wheel组，并通过visudo写精细规则：
%ops ALL=(ALL) /usr/bin/systemctl restart nginx%ops ALL=(ALL) /usr/bin/journalctl -u nginx
审计场景给只读组，例如auditors,再用ACL授权：
sudo setfacl -R -m g:auditors:rX /var/logsudo setfacl -R -m g:developers:rwX /srv/www
组管理改完后，已登录会话未必立即生效。 退出重新登录最稳，或者用newgrp临时切换。
云服务器安全组配置要额外收费吗
多数云厂商对安全组、资源组、用户组本身不单独收费，真正计费的是公网带宽、跨地域流量、NAT网关、负载均衡、日志服务等关联资源，北京、上海、广州等地域的价格差异，通常体现在实例、带宽和存储上，安全组功能多数情况下免费,具体以各云厂商计费文档为准。
如果你在云上只开了一台轻量服务器，安全组就是第一道门，默认安全组往往只开放22和80，够用就别乱加规则，临时调试完的端口,记得及时删除。
北京服务器运维组常用命令有哪些
北京服务器运维组常用命令和其他地域差别不大，核心还是围绕账户、组、权限和网络排查,常用清单如下：
- 账户组查询：
id、groups、getent group - 组管理：
groupadd、groupdel、gpasswd -a - 用户加组：
usermod -aG 组名 用户名 - 权限调整：
chown :组名 文件、chmod 2775 目录 - ACL授权：
setfacl -m g:组名:rwx 文件 - 组文件检查：
grpck - 进程组查看：
ps -eo user,group,comm - 安全组排查：云控制台安全组规则、实例绑定关系、流日志
- 端口监听：
ss -tulnp - 防火墙：
firewalld、ufw、iptables
排查“用户为什么访问不了目录”，按顺序来：先id 用户看组，再ls -ld 目录看权限，再看ACLgetfacl 目录，最后确认SELinux或AppArmor，排查“外网为什么连不上”，先看安全组，再看系统防火墙，最后看服务监听地址是不是
0.0.1。
服务器组管理避坑清单
- 不给普通用户直接root登录
- 不把开发人员长期放进
docker组 - 不用
chmod 777代替组权限设计 - 不开放
0.0.0/0的22和3389 - 定期清理离职人员组关系
- 定期执行
grpck和getent group - 云安全组规则配合资源组和标签管理
- 修改
sudoers必须用visudo
据工信部相关安全指南，最小权限原则是服务器安全基线的一部分。行业共识认为，账户、组、权限、网络规则要一起管，单靠某一项都不够。业内专家指出，容器组权限过大是常见风险，尤其是在测试环境直接复用生产镜像时，把组关系画成一张表，谁属于哪个组、组能访问什么、安全组放行哪些端口,审计时会轻松很多。
服务器常用的组有哪些相关Q&A
服务器常用的组有哪些必须掌握？
必须掌握的有Linux用户组、系统服务组、权限管理组、云安全组、资源组和放置组，Linux用户组看/etc/group，系统服务组看进程运行身份，安全组看云控制台规则，资源组看云资源分类和分权，日常运维最常用的是sudo、wheel、www-data、mysql、postgres、docker和云平台默认安全组。
Linux服务器用户组和权限组有什么区别？
用户组是账户的身份集合，权限组是带有授权能力的用户组，前者解决“你属于谁”，后者解决“你能干什么”。developers是普通用户组，sudo或wheel是权限组，查看用户组用getent group，查看提权规则用visudo。
云服务器安全组配置要额外收费吗？
多数云厂商对安全组本身不收费，计费集中在公网带宽、跨地域流量、NAT网关、负载均衡等关联资源，安全组规则数量、绑定实例数量通常有配额限制，超出配额可申请调整,功能费用仍以厂商计费文档为准。
服务器常用的组不是一张固定名单，而是按系统层、网络层、云资源层分层理解，先把用户组和安全组分清，再用最小权限落地,服务器管理就稳了。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/685893.html
