清空/etc/shadow密码字段会导致用户免密登录，而非锁定；正确锁定应保留哈希并加!!前缀，使用passwd -l命令实现，解锁后需用chage -l确认策略未阻断登录。
别把“清空密码”当成锁账户
在UOS或主流Linux系统中，直接把/etc/shadow里某行的密码字段删成空（比如变成user1::19663:0:90:7:::），系统会认为该用户“无需密码即可登录”，这跟锁定目标完全相反。正确做法是保留原有哈希值，并加!!前缀，例如!!$6$salt$hash。用passwd -l 用户名命令能自动完成这个操作；解锁时别只跑passwd -u，还得检查chage -l 用户名，确认密码过期策略没卡住登录。
服务别让root一直挂着跑
很多服务像Nginx、MySQL、自研后台，默认由root启动后就长期以root身份运行。一旦被攻破，攻击者等于拿到整台机器的控制权。必须降权：
- 在systemd单元文件里明确写
User=www-data和Group=www-data - 加上
NoNewPrivileges=yes，防止进程后续提权 - 如果要监听80或443端口，改用
setcap 'cap_net_bind_service+ep' /usr/bin/nginx授权，而不是留着root跑 - 对应的服务账户shell统一设为
/usr/sbin/nologin，彻底禁掉交互式登录
RBAC权限别搞混作用域
Kubernetes里常有人用RoleBinding绑一个ClusterRole，然后以为权限只在当前命名空间生效。其实ClusterRole本身没有命名空间概念，它的实际生效范围取决于绑定方式——单个RoleBinding + ClusterRole确实只影响当前命名空间；但要是多个命名空间都做了同样绑定，就等于变相实现了跨空间授权。稳妥做法是：
- 优先定义命名空间级的
Role，配合RoleBinding使用 - 真需要集群级权限时，才用
ClusterRoleBinding，且必须严格审查subjects里的ServiceAccount来源 - 定期执行
kubectl auth can-i --list --as=system:serviceaccount:ns:name验证真实权限边界
文件权限别只看数字，得看底层拦不拦
chmod 644配置文件、755目录看起来很规范，但可能根本不起作用：
- 挂载选项带
noexec，脚本就算有x位也执行不了 - SELinux上下文错乱（比如显示
unconfined_u:object_r:default_t:s0）会直接拦截合法访问 - 全局可写目录（
o+w）没清理干净，尤其/tmp以外的临时路径，容易被利用提权
建议用find /path -type f -perm /o+w扫一遍可疑文件，再用ls -Z核对SELinux标签，确保上下文匹配。
