核心原则是“最小权限+职责分离+动态验证”，需从系统账户、执行上下文、调用链路三层面收紧权限，隔离降权服务账户，限制系统调用与资源访问，执行前二次鉴权，并建立行为基线实时告警。
核心原则是“最小权限+职责分离+动态验证”，不是单纯给服务加个账号密码就完事。高权限服务组件一旦被劫持或误用，往往直接绕过应用层逻辑，直击系统底层，所以权限配置必须从系统账户、执行上下文、调用链路三个层面同时收紧。
服务运行账户必须隔离且降权
绝不能让关键服务（如定时任务调度器、日志采集 agent、API 网关后台进程）以 root 或 Administrator 身份运行。应为每个服务创建专用系统用户，仅赋予其完成本职工作所必需的文件读写路径、系统调用能力（如 cap_net_bind_service）和 SELinux/AppArmor 上下文。
- Linux 下用
useradd -r -s /sbin/nologin service-a创建无登录能力的受限用户 - 通过
setcap cap_net_bind_service=+ep /usr/bin/service-a授予绑定低端口能力，而非开放整个 root 权限 - Windows 中禁用服务账户的“作为服务登录”以外的所有用户权限，并移除其在 Administrators 组中的成员身份
限制服务可调用的系统接口与资源范围
越权指令常通过 exec、syscall、反射加载等方式突破边界，因此需在运行时主动收窄能力暴露面。
- 容器化部署时，在 Docker 或 Pod spec 中设置
readOnlyRootFilesystem: true，并显式挂载必要可写目录（如 /var/log/service-a） - 启用 seccomp 过滤器，屏蔽服务无需的系统调用（如
execveat、ptrace、open_by_handle_at） - 对 Java/Python 类服务，禁用危险类加载机制：JVM 加
-Djava.security.manager并定制 policy；Python 设置sys.path白名单 + 禁用__import__动态导入
指令执行前强制二次鉴权与上下文校验
不依赖服务自身逻辑做权限判断，而是在内核/中间件层拦截并验证每一次敏感操作请求。
- 利用 eBPF 在 sys_enter 阶段捕获 execve 调用，比对发起进程 UID/GID、父进程名、命令参数哈希与预设白名单
- 在 API 网关或服务网格（如 Istio）中注入 RBAC 插件，要求所有管理类接口携带服务级 JWT，并校验
aud（目标服务标识）与act（操作意图）字段 - 对 cron、systemd timer 触发的任务，要求其 unit 文件声明
RestrictSUIDSGID=true、NoNewPrivileges=true，并配合Delegate=false阻止子进程提权
建立服务行为基线并实时告警偏离
静态配置只是起点，真实攻击常表现为合法账户下的异常行为模式。
- 用 auditd 或 eBPF trace 工具持续采集服务进程的 open/exec/connect 等关键事件，提取 PID、PPID、cmdline、target path、return code
- 训练轻量级行为模型（如基于时间窗口的 syscall 序列频次统计），将首次出现的非预期调用（如 nginx worker 进程调用 python 解释器）标记为可疑
- 告警触发后自动冻结该服务实例，并推送完整调用栈与内存映像供取证，而非仅重启服务掩盖痕迹
真正有效的越权防护不在防火墙规则里，而在服务启动那一刻的 UID、它能碰的文件描述符数量、它被允许发出的系统调用集合，以及每次动作发生时有没有人盯着它的手指往哪按。
