执行权限如何严格限制

wen 开源项目 2026-06-27 28

本文目录导读：

执行权限如何严格限制

操作系统层面的权限控制（最基础）
应用程序与代码层面的权限控制
数据库与数据层面的权限控制
网络与基础设施层面的权限控制
审计、监控与白名单
一个最佳实践清单

严格限制执行权限是系统安全的核心任务之一,它的核心原则是最小权限原则，即只授予完成任务所必需的最少权限，并且只授予最短暂的时间。

要严格限制执行权限,需要从操作系统层面、应用程序层面、网络与数据层面以及审计与监控层面进行层层设防，以下是具体的方法和最佳实践：

操作系统层面的权限控制（最基础）

这是大多数权限问题的起点,主要针对用户、文件和进程。

文件和目录权限（Unix/Linux）：
- 避免使用 777：永远不要给文件或目录设置 chmod 777（所有人读、写、执行）。
- 明确属主和属组：使用 chown 和 chgrp 确保文件属于正确的用户和组。
- 使用 chmod 设置精确权限：755（属主可读写执行，同组和其他人只读执行）或 700（仅属主可完全控制）。
- 特殊权限位：
  - SUID（Set User ID）：绝对避免在非必要程序（如 vim、bash）上设置SUID，这会允许任何用户以文件所有者的权限执行该文件，是高风险操作。
  - SGID（Set Group ID）：小心使用，主要用于协作目录。
  - Sticky Bit：对 /tmp 等共享目录设置（chmod +t /tmp），防止用户删除或重命名不属于自己的文件。
用户和组管理：
- 最小化Root用户使用：禁止直接使用root账户登录，强制使用 sudo 进行提权。
- 精细化 sudo 配置：修改 /etc/sudoers 文件，为特定用户或组授予仅特定命令的执行权限（user ALL=(ALL) /usr/bin/systemctl restart nginx），而不是授予所有命令权限。
- 禁用不需要的服务：关闭不必要的系统服务（如 telnet、rsh），减少攻击面。
- 使用容器化：将应用放入 Docker/Podman 等容器中，并以非Root用户运行容器内的进程（通过 USER 指令或 docker run -u）。
Windows 权限控制：
- NTFS 权限：使用明确的“允许”和“拒绝”规则。
- 用户账户控制（UAC）：保持开启，阻止未经批准的自动提权。
- Active Directory：使用组策略（GPO）控制用户和计算机的权限。
- 以最低权限运行服务：不要将服务配置为以 LocalSystem（最高权限）运行，应使用 NetworkService 或自定义的低权限账户。

应用程序与代码层面的权限控制

应用程序本身也必须有权限控制机制。

权限分离：将一个应用拆分为多个进程，一个 Web 服务器分解为：
- 高权限层：处理权限校验、用户认证，运行在隔离的环境中。
- 低权限层：处理业务逻辑、数据和视图，运行在受限的沙箱中，低权限层只能访问必要的数据和API，不能直接操作系统。
API 权限验证：
- 强制校验：在每一个 API 端点的入口处（如路由中间件），强制校验调用者的身份和权限（如 OAuth 2.0 Scope、Role-Based Access Control）。
- 最小化 API Key 权限：为每个 API Key 分配只能访问特定资源（如只读数据库）的权限。
沙箱 / 隔离机制：
- JavaScript 沙箱：对于运行用户脚本的平台（如浏览器插件、在线编辑器），使用 vm2 或 iframe sandbox 严格限制脚本对文件系统和网络的访问。
- WebAssembly：Wasm 运行时有天然的内存安全隔离。
代码签名：要求所有可执行文件、脚本必须有数字签名，操作系统或应用只允许执行已签名的代码。

数据库与数据层面的权限控制

数据是核心资产,必须严格限制谁可以“执行”数据库操作。

最小权限原则：为应用创建一个独立的数据库用户，只授予 SELECT、INSERT、UPDATE、DELETE 权限（按需选择），绝不授予 CREATE、DROP、ALTER、GRANT 等管理权限。
使用视图与存储过程：通过视图或存储过程提供对数据的有限访问，而不是直接暴露表，这样，用户只有执行存储过程的权限，而没有直接修改表的权限。
行级安全：对于多租户应用，使用数据库的行级安全策略（如 PostgreSQL 的 RLS），确保用户只能“执行”对自身数据行的查询。

网络与基础设施层面的权限控制

防火墙与安全组：
- 默认拒绝：设置防火墙规则，默认拒绝所有流量，只放行必要端口（如 80、443、SSH 管理端口）。
- IP白名单：限制只能从特定的 IP 或 VPC 网络访问管理接口（如 SSH、数据库端口）。
身份与访问管理（IAM）：在云服务（AWS、Azure、GCP）中使用 IAM 角色和策略，将服务器的权限与个人用户解耦，一个 EC2 实例不需要有 root 密码，而是通过 IAM Role 获取临时凭证。
网络策略限制：在 Kubernetes 环境中，使用 Network Policy 限制 Pod 之间的通信，只允许必要的服务互相访问。

审计、监控与白名单

审计日志：
- 记录所有sudo操作、权限变更（chmod、chown）和敏感命令执行。
- 使用 auditd（Linux）或 Windows 安全事件日志，并实时发送到 SIEM 系统。
应用程序白名单：在关键服务器上，只允许运行预先批准的可执行文件，工具如：Linux 的 AppArmor、SELinux、SecComp，Windows 的 AppLocker。
行为监控：监控异常的进程行为，一个 Web 服务器进程突然去执行 /bin/sh 或 powershell.exe，这通常是攻击迹象，应立即告警并阻断。

一个最佳实践清单

永远不要用 root/管理员运行应用，创建专用低权限用户。
为每个功能或服务创建独立用户，避免权限交叉。
文件和目录权限：先拒绝所有，再开放必要。
数据库：只授权 CRUD，绝不授权 DDL。
API：在入口处做严格权限校验，不要信任前端。
环境变量与配置文件：绝不存储密钥，使用密钥管理服务。
使用容器和 sandbox 进行隔离。
启用并审查审计日志。
定期进行权限审计：检查是否有过度授权的用户或文件。

核心思想是：任何权限的授予都应该是一个有意识的、受控的、可审计的决策，而不是一个默认的、宽松的设置。