身份与最小权限

• ccache 缓存票据实现无密码、免交互的 SSO 登录
• keytab 存放长期密钥，用于无密码初始认证
• 跨节点调度（如 HPC/Spark）中两种方式的取舍与安全差异

Kerberos 中 ccache（凭证缓存）保存用户获取的 TGT 与 TGS 票据，利用票据时效，使后续认证无需再输密码，实现单点登录（SSO）；但 ccache 是短期凭证，需定期 renew，且明文保存在文件系统，需保证权限与加密。keytab（key table）存放长期密钥（长期密钥即用户密码的哈希形式），程序可用它无密码地向 KDC 获得初始 TGT，适合无人值守的服务进程；但 keytab 一旦泄露等于泄露长期凭据，风险更高。在跨节点调度（如 HPC、Spark）中，ccache 因票据可跨节点复用、支持票据转发（forwardable）而便于在计算节点间传递身份，但需注意票据有效期与 renew 管理；keytab 则便于为服务账号提供服务身份，但需严格管控 keytab 文件权限与轮换。

取舍关键在于"短期票据 vs 长期密钥"的信任与生命周期。ccache 短期、可 renew、适合交互式 SSO 与票据转发；keytab 长期、固定、适合服务进程，但泄露后果严重。跨节点调度常结合两者：入口用 keytab 获取 TGT，节点间用 ccache 传递票据。

• AuthorizedKeysCommand 动态获取公钥，适配 AD/LDAP
• AuthorizedPrincipalsCommand 获取证书主体，用于 CA 签名场景
• 每次连接调用外部命令的延迟与缓存策略（结果缓存、TTL）

OpenSSH 的 AuthorizedKeysCommand 在服务器端每次 SSH 认证时外部调用指定命令，从 AD/LDAP 动态查询用户的公钥，取代逐台维护 authorized_keys；AuthorizedPrincipalsCommand 则从目录获取用户的证书主体（principals），配合 CA 签发的证书用于认证。主要问题在于每次连接都触发一次目录查询，若 LDAP 延迟高或认证频繁，会显著增加连接延迟。缓解策略：本地缓存查询结果（键为用户名，带 TTL 过期），采用异步预取与批量查询，或将目录数据库同步到本地做缓存，同时设置合理超时与失败降级（fallback 到本地文件）。

动态集成换来了"集中管理"的收益，代价是引入外部依赖延迟。缓存策略需要在"凭证新鲜度"与"连接延迟"之间权衡，用 TTL 保证撤销（revoke）能在合理时间内生效。

• FAST armor 用 armor ticket 保护初始请求
• S4U2Self 为用户代理获取服务票据
• S4U2Proxy 用 TGS 票据进行协议转换与受限委派

在 Kerberos 委派场景中，FAST armor 用预先分发的 armor ticket 加密 KDC 请求，防止攻击者重放或篡改初始 AS 请求，缓解"AS-REQ 重放"与破解性攻击；S4U2Self 允许服务代表用户向 KDC 申请服务票据（用于协议转换，如为 Web 用户生成服务票据）；S4U2Proxy 允许服务用得到的 TGS 票据作为证据，代表用户请求其他服务（受限委派）。风险在于委派链中票据可被转发、被滥用来横向移动，攻击者可利用委派性漏洞（如约束委派中服务被攻破）获得冒充用户的能力。缓解：使用受限委派（服务票据仅允许转发到指定服务）、启用服务票据加密与 renew 限制、对委派服务最小化授权、启用 S4U2Self 的 PAC 校验、结合 FAST 保护请求、审计委派事件。

委派本质是"身份传递"，风险随传递链增长。缓解核心是"限制票据能转发到哪、由谁使用、有效期多长"，并保护请求过程本身（FAST）。

• SCIM 2.0 的批量（Bulk）操作
• 过滤表达式（filter）的查询复杂度
• 速率限制与分页对目录性能的影响

SCIM（System for Cross-domain Identity Management）用于跨系统同步用户/组身份。批量操作（Bulk）可一次提交多个增删改请求，减少 HTTP 往返，但过大的批量会占用目录服务资源、可能造成部分成功需回滚；过滤表达式（filter）支持 userName eq "x" 等查询，复杂过滤（如 and、跨字段、or/not）若不命中索引会退化为全表遍历，拖慢目录查询；速率限制与分页（startIndex/count）控制单次请求规模，限流防止突增打挂目录，但过小的分页会导致大量往返、过大的分页又增加内存压力。性能影响需在批量大小、过滤复杂度、分页与限流之间做平衡，并配合索引与异步处理。

身份同步是高频批量访问目录的典型场景。性能的核心是"查询能否命中索引、批量是否可控、是否限流"。合理设计过滤与批量、设置分页与限流，才能保证目录服务稳定。

• alg=none 允许无签名 token
• 算法混淆：RS256（非对称）降级为 HS256（对称）并代入公钥作密钥
• 服务端必须固定算法并显式校验

JWT 头部 alg 字段声明签名算法。alg=none 表示不带签名，若服务端默认接受该值，攻击者即可构造任意 payload 的假 token 通过认证。算法混淆攻击中，服务端验证 RS256 但攻击者把 alg 改为 HS256（HMAC 对称算法），此时服务端会拿"公钥字符串"当作 HMAC 密钥去验证，而公钥是公开的，攻击者便可用公钥作为 HMAC 密钥对任意 token 签名，从而绕过验证。防御必须：服务端固定只接受预期的算法集合（如只允许 RS256），显式校验 alg 头与预期一致，禁止 fallback 到 none 或 HS，并拒绝弱算法；同时用独立的密钥解析逻辑区分对称/非对称密钥。

根因是"信任了 token 头部声明的算法而未在服务端校验"。攻击者通过篡改 alg 让验证逻辑落入可控分支。固定算法集合并显式校验，是消除该歧义的关键。

• POSIX ACL 的 mask 字段限定了命名用户/组的有效权限
• mask 与 owner/group/other 的交互
• 查看有效权限（effective）字段排查

POSIX ACL 中，mask 字段限制的是"命名用户、命名组与所属组"这三类条目的有效权限（effective permissions），而 owner、other 不受 mask 限制。当 mask 缩小（如设为 r--）时，即使命名用户条目写着 rwx，其有效权限也只会是 r--。因此 mask 会"裁剪"命名条目的实际生效权限。排查时用 getfacl 查看各条目，注意 mask 行以及命名条目中标注的 effective: 权限值（如 user:alice:rwx # effective:r--），或 getfacl -e 直接显示有效权限；同时确认 owner/group 的权限位与 mask 的关系。

mask 是"权限的上限门"，它把命名条目的请求权限与 mask 做交集得到有效权限。排查看 mask 值及每条目的 effective 标记，才能找出"写了权限却不生效"的原因。

• setuid-root 以 root 运行，漏洞即提权
• no_new_privs 阻止 exec 时提升权限，但并不降低已提升的权限
• seccomp 限制系统调用但漏洞本身仍以高权限执行

setuid-root 二进制以 root 有效 UID 运行，一旦存在可利用漏洞（如缓冲区溢出、命令注入），攻击者就能在 root 权限下执行任意代码，直接提权。no_new_privs 标志阻止进程及其后代在 exec 时获得新的权限提升（如禁止 setuid 生效），但它不改变当前进程已获得的高权限，也不能阻止漏洞在 root 上下文中的利用；seccomp 沙箱限制可用的系统调用集合，能阻止某些提权技术（如 execve 新 shell、ptrace 附加），但无法覆盖所有攻击路径，且配置复杂、易遗漏。因此二者只是"缓解"而非"根治"。降权设计（以最小权限的专用账号运行、setuid 后立即降权、拆分高权限组件、只保留必要 capability）才是根本——即使有漏洞，攻击者也只能获得低权限。

关键区别是"权限是否本就不该那么高"。no_new_privs/seccomp 是在高权限已存在时收窄攻击面，机器可能被绕过；降权是从源头消除高权限攻击面，是纵深防御的根基。

• ALL 授予任意命令执行，NOPASSWD 免密扩大滥用
• 最小化：仅授予必需命令、限制参数、禁止 shell
• 用 journalctl 审计 sudo 调用

sudoers 中 ALL 规则授予用户以 root 执行任意命令的能力，NOPASSWD 又免去密码，二者叠加使攻击者一旦取得该用户就能免密任意提权，且难以追溯，攻击面被极大放大。最小化策略：仅授予业务必需的特定命令（而非 ALL）、限制允许的参数、禁止授予 shell/编辑器等可逃逸命令（如 vi、less、find），用 sudo -l 复核实际权限，并设置 timestamp_timeout 缩短免密窗口。审计：journalctl -u sudo 或查看 /var/log/auth.log 记录 sudo 调用（用户、命令、退避结果），配合集中日志与告警来发现异常提权。

ALL+NOPASSWD 违背最小权限，把 sudo 变成"免密 root 开关"。落地是"给最小命令、留审计痕迹、收免密窗口"，把提权路径收窄并可追溯。

• K8s service account token 的自动轮换
• 云平台定期轮换密码/密钥
• 回收（离职、改密、吊销）策略

服务账号凭据需自动轮换以降低长期泄露风险。K8s 中，service account 使用短期 Token（Projected Token，默认 1 小时 TTL 自动轮换）、绑定到具体 Audience，并支持自动注入到 Pod，无需人工改密；长期 ServiceAccountToken 应禁用或收紧。云平台中，服务账号密码/访问密钥应设置自动轮换周期（如 30/90 天），IaaS 密钥（如 AWS IAM 访问密钥）用到期策略与自动轮换机制，SSH key 通过集中管理（如密钥管理服务）定期签发短期证书或轮换。回收策略：账号下线/权限变更时立即吊销对应密钥；对泄露的密钥及时吊销并轮换；K8s 中删除 ServiceAccount 及关联 Token，云平台中删除密钥并审计其使用；建立"一旦泄露即轮换、定期强制轮换、离职即回收"的闭环。

轮换的收益是把"凭据有效窗口"压缩到有限时间，降低泄露损失；回收是"撤销不再需要的凭据"。自动轮换依赖短期凭证与集中管理，回收依赖权限变更联动与审计。

• real/effective/saved UID 三者的含义
• effective UID 决定权限检查
• setuid 降权时未同时降所有 UID、未恢复/残留的常见错误

Unix 中 UID 分三类：real UID（进程真实用户）、effective UID（决定多数权限检查，如文件/进程访问）、saved UID（保存原有效 UID，供在权限间切换）。setuid 程序以 owner 的 effective UID 运行。降权时（即以高权限启动后主动降为低权限）最容易犯的错误是：只降 effective UID 而未降 real 和 saved UID，导致后续仍可通过 setuid()/seteuid() 恢复高权限；或降权后未放弃对关键资源的访问（如已打开的高权限文件描述符）；或降权顺序错误、未同时设组权限（setgid）。正确的降权应同时把 real/effective/saved UID 都设为低权限值，并关闭遗留的 high-priv 资源，使进程无法再回升高权限。

effective UID 决定当前权限检查，但 saved UID 是"回升高权限的入口"。降权若只改 effective 而保留 saved/real，攻击者仍可恢复。彻底降权必须清空所有可回升的 UID 并清理资源。

• capabilities 把 root 拆成细分能力
• permitted/effective/inheritable/ambient 集合的含义
• exec 时集合的转换规则

Linux capabilities 将 root 的无限权限拆分为细粒度能力（如 CAP_NET_ADMIN、CAP_SYS_ADMIN、CAP_DAC_OVERRIDE），使进程可以只获得所需能力的子集。四个集合：permitted（本进程可用的能力上限）、effective（当前生效的能力，供权限检查）、inheritable（可被 exec 继承的能力）、ambient（exec 后自动保留在 permitted/effective 的能力）。exec 新程序时，新进程的 permitted = (file capabilities 或 root 才有的) ∩ 相关集合，effective 由 permitted 或 file 的 effective 位决定，inheritable 与文件 inheritable 位取交集，ambient 用于在 exec 后自动重新获得原本会丢失的 inherited 能力。转换本质是"集合按 executor 的权限与文件能力位求交集"，防止能力被无意扩大。

capabilities 是"最小权限"在权限拆分上的落地。各集合的转换规则保证 exec 时能力只减不增，ambient 是显式让能力在 exec 后延续的机制。理解集合转换才能正确配置容器/工具的权限。

• PAM 四种管理组：auth/account/password/session
• 模块组合与堆叠顺序
• LDAP/SSSD/RADIUS 的接入差异

PAM（可插拔认证模块）把认证拆成四组：auth（验证身份）、account（检查账户状态与访问策略）、password（修改密码）、session（会话建立/结束时的钩子）。四个组按 PAM 配置文件堆叠多个模块，按控制标志（required/requisite/sufficient/optional）决定成功与否。LDAP/SSSD/RADIUS 接入差异：直接 LDAP 认证通过 pam_ldap 查询目录验证密码，链路是"应用→PAM→LDAP"；SSSD 通过 pam_sss 连接本地缓存与后端（LDAP/AD），支持缓存、离线认证与多后端，链路是"应用→PAM→SSSD→LDAP/AD"；RADIUS 通过 pam_radius 把认证请求转发给 RADIUS 服务器（常用于网络设备、VPN、802.1X），链路是"应用→PAM→RADIUS server"。差异在于认证后端、缓存能力、协议与适用场景。

PAM 是认证的"编排层"，组合与顺序决定认证与授权的行为。SSSD 提供缓存/离线，LDAP 直连简单但无缓存，RADIUS 面向网络接入场景。选型取决于可用性、缓存与协议需求。

• OAuth2 授权码/客户端凭证/密码等令牌流
• ID Token 与 Access Token 的区别
• scope 作用域与最小权限

OAuth2 定位是"授权"（授权第三方访问用户资源），通过多种令牌流（authorization code、client credentials、device、refresh token 等）换取 Access Token；Access Token 携带 scope 作用域，限定第三方能访问的资源与操作，实现最小权限授权。OIDC（OpenID Connect）在 OAuth2 之上增加"身份认证"，额外签发 ID Token（JWT，含身份信息 userinfo），让客户端确认用户身份。Flow 示例：授权码流程中，资源拥有者授权后认证服务器返回授权码，客户端用授权码+密钥换取 Access Token 与 ID Token。作用域（scope）如 openid、profile、email、api.read 表示请求的权限范围，客户端只应请求所需 scope，服务端按 scope 发放 Access Token。

OAuth2 管"你能访问什么"（授权），OIDC 管"你是谁"（认证）。Token 流决定获取令牌的方式，scope 决定令牌的能力边界。分离认证与授权、按 scope 最小化授权是核心。

• SSH CA 签发短期用户证书
• 取代逐台维护 authorized_keys
• 信任模型（信任 CA）与吊销（证书期/CRL）差异

普通 SSH key 模式下，每台服务器需把用户的公钥写入 authorized_keys，逐台分发、难以集中管理。SSH CA（证书授权）模式下，由可信 CA 为用户签发短期用户证书（含用户名、有效期、principals），服务器配置 TrustedUserCAKeys 信任该 CA，即可验证任何由 CA 签发的证书，无需逐台维护公钥，实现集中签名与快捷分发。信任模型差异：普通 key 是"逐台信任具体公钥"，SSH CA 是"信任签发的 CA + 证书有效期内"；吊销差异：普通 key 需手动从 authorized_keys 删除（难以即时生效），SSH CA 靠证书有效期（短期 TTL 自动过期）天然收敛风险，配合吊销列表（CRL）或 revoked_keys 即时吊销已签发证书。

SSH CA 把"信任具体公钥"升级为"信任签发者"，配合短期证书让吊销与轮换自动、集中。有效期内自动过期收窄泄露窗口，CRL 处理紧急吊销。

• 授权码流程的授权码截获风险
• PKCE 的 code_challenge/code_verifier 机制
• public client 无 client_secret 必须用 PKCE

授权码流程中，授权码（code）在浏览器重定向时传输，可能被截获；而 public client（如 SPA、移动 App）无法安全保存 client_secret，若被截获授权码也无法验证来源，攻击者可拿授权码换取令牌。PKCE（Proof Key for Code Exchange）在授权请求时生成随机 code_verifier，发送其 SHA-256 哈希 code_challenge；换取令牌时携带 code_verifier，认证服务器验证其哈希与 code_challenge 一致才发令牌。即使攻击者截获授权码，因没有 code_verifier 也无法完成令牌交换。因此 public client 因为没有 secret 可依赖，必须用 PKCE 作为替代的"证明请求者拥有授权码"机制，防止授权码被截获后利用。

PKCE 把"客户端身份"从静态 secret 换成"动态 code_verifier"的持有证明。public client 无 secret，PKCE 是唯一可靠的防截获手段，也是 RFC 7636 的强制要求。

• 四种控制标志的语义
• required 与 requisite 的差异
• sufficient 提前成功、optional 不强制

PAM 控制标志决定模块结果如何影响最终认证：required 表示该模块必须成功，失败则最终失败（但会继续执行后续模块）；requisite 表示该模块必须成功且一旦失败立即终止后续模块并整体失败；sufficient 表示该模块成功即整体成功（可跳过后续模块，通常用于可选认证方式）；optional 表示结果不决定性，仅当整个栈无其他决定性结果时才参考。最终结果由 required/requisite/sufficient 共同决定：任何一个 required/requisite 失败则失败；sufficient 成功可提前成功；optional 仅作兜底。

标志设计决定"认证是否可被替代、失败是否立即中断"。required 累计、requisite 短路、sufficient 提前成功、optional 兜底，理解它们才能正确编排多因素与多后端的认证栈。

• 低端口绑定需 root 权限
• capability 方式（CAP_NET_BIND_SERVICE）
• socket activation（systemd）代绑端口

Unix 惯例是低于 1024 的端口需 root 才能绑定。避免长期 root 运行有三种方案：capability 方式——给进程授予 CAP_NET_BIND_SERVICE 能力，使其能绑定低端口而不必拥有完整 root 权限；socket activation——使用 systemd socket 单元预先绑定端口，由 systemd 把已监听 socket 传给服务进程，服务本身以低权限运行；反向代理——前端用 nginx/haproxy 等以 root 绑定 80/443，再把请求转发给后端以低权限运行在高端口的应用。三者都把"绑定低端口"与"应用长时间以 root 运行"解耦。

核心是"最小特权"——只给绑定低端口所需的最小权限，而非整个 root。capability 粒度最细、socket activation 由 systemd 托管、反向代理最通用，三者可组合。

• RBAC 角色授权与 ABAC 属性/上下文授权
• 最小权限的角色与属性设计
• 特权账号管理（PAM）与临时提权

最小权限原则要求"只授予完成职责所需的最小权限"。RBAC（基于角色的访问控制）通过角色汇总权限，把用户分配到角色，便于按职责授权；ABAC（基于属性的访问控制）根据主体、资源、环境等属性（部门、时间、地点、敏感级别）动态决策，能表达更细粒度的上下文敏感策略。最小权限落地：角色按"最小职责集"设计、避免超级角色滥用、定期权限复核；ABAC 用属性组合收窄授权范围。特权账号管理（PAM/特权访问管理）对高权限账号（root、管理员、服务账号）做统一保管、密码/密钥轮换、会话审计与临时提权（临时授权、用后即还），避免特权常驻。

RBAC 解决"谁有什么角色"，ABAC 解决"在什么条件下能做什么"，两者结合可精确表达最小权限。特权账号管理把"高权限"变成"临时、可审计、可回收"的资源。