安全策略需从进程权限隔离、任务数据流转可控、故障恢复不越权三维度切入：Master仅限端口绑定与配置加载，Worker降权运行且禁敏感操作，凭证由预置角色获取，任务元信息白名单校验，故障恢复须幂等校验与凭据重置。
Master 与 Worker 进程在负载均衡项目中不直接参与底层存储，但其调度、通信与状态管理行为会深刻影响存储层的安全边界。安全策略需从“进程权限隔离”“任务数据流转可控”“故障恢复不越权”三个维度切入，而非简单套用存储加密或访问控制模型。
进程权限必须严格分离
Master 进程以 root 启动仅用于绑定 80/443 端口、加载配置、派生 Worker 及接收信号，绝不接触业务数据或存储路径。Worker 进程必须降权运行（如 user www-data;），且禁止拥有以下权限：
- 无法读写 /etc、/root、数据库配置文件等敏感路径
- 无法执行 mount、chroot、ptrace 等系统级操作
- 文件描述符限制（worker_rlimit_nofile 65536;）需与 ulimit -n 一致，防资源耗尽型 DoS
任务分发过程禁止透传原始存储凭证
Worker 执行任务时若需访问后端存储（如对象存储、数据库、本地文件），凭证不得由 Master 直接下发。正确做法是：
- Worker 通过预置角色（如 IAM Role）或本地 token service 获取短期凭证，避免密钥硬编码或网络传输
- Master 仅下发任务元信息：例如 id=task-773, bucket=prod-logs, prefix=20260619/, format=parquet，不含 access_key、secret_key 或数据库连接串
- 所有存储访问路径须经白名单校验（如 Nginx 的 valid_referers 或自定义模块拦截非法 bucket 名）
故障恢复阶段防止状态污染与越权重放
当 Worker 异常退出或网络中断，Master 重启任务时，必须阻断三类风险：
- 禁止重放已部分写入的数据块（如 S3 multipart upload 的 part number 冲突），要求每个任务带唯一 nonce，存储侧做幂等校验
- Worker 崩溃前缓存的临时文件（如 /tmp/task_XXX.tmp）需由 cleanup 脚本自动清除，且目录挂载为 noexec,nosuid,nodev
- Master 重新分发失败任务时，不得沿用原 Worker 的身份上下文；新 Worker 使用独立凭据，并记录重试来源（如 retry_from=worker-3-failed）供审计追溯
安全不是加一层认证就万事大吉，而是让 Master 守住调度权、Worker 守住执行界、存储守住数据门——三者之间只交换必要元数据，不共享身份、不传递密钥、不默认信任。
