SelfLearn · 技术手记

切换深色模式

附录 D：练习题与参考答案 ​

先独立作答，再看答案。参考答案描述核心判断，不是唯一实现。

D.1 基础题 ​

  1. 为什么认证成功不代表可以读取工资表？
  2. 为什么账号不能作为现实主体的永久唯一标识？
  3. JWT 已正确签名，还需要验证哪些内容？
  4. TLS、mTLS、业务授权分别回答什么？
  5. 盐为何可和密码哈希同库，pepper 为何应分离？

答案 ​

  1. 认证只证明认证器控制权；授权还需角色/关系、资源、动作、上下文和策略。
  2. 一人可能多账号、重雇、合并/注销；账号属于具体系统生命周期。
  3. 允许算法、可信密钥、issuer、audience、时间，按场景还需 nonce/azp/jti/授权上下文。
  4. TLS 认证服务并保护传输；mTLS 也认证客户端连接方；业务授权判断该身份能否做具体动作。
  5. 盐用于阻止预计算/相同密码同哈希，不依赖保密；pepper 作为额外秘密，与数据库同失陷会失去价值。

D.2 认证与协议题 ​

  1. state、nonce、PKCE 的职责分别是什么？
  2. 为什么 ID Token 不该交给 API 当 Access Token？
  3. Passkey 抗钓鱼，为何恢复仍可能导致接管？
  4. Refresh Token rotation 如何发现重用？
  5. SCIM API 返回 200，为什么仍要周期对账？

答案 ​

  1. state 绑定浏览器请求/响应；nonce 绑定 OIDC 请求与 ID Token；PKCE 绑定授权请求方与 code 兑换方。
  2. ID Token 的受众和语义是 Client 的登录结果；API 需要为自己签发、含合适 scope/audience 的 Access Token。
  3. 攻击者可能通过邮箱/客服/弱证明添加新认证器，绕过原强认证器。
  4. 每次刷新作废旧 token；若旧 token 再出现，说明 token 家族可能泄漏，撤销整个家族。
  5. 下游可能异步失败、人工修改、事件遗漏或语义不一致；对账发现长期漂移并形成证据。

D.3 授权与治理题 ​

  1. RBAC 角色爆炸的根因是什么？
  2. ABAC 中属性缺失应怎样处理？
  3. ReBAC 如何解释允许决策，又如何避免解释泄密？
  4. 为什么 UI 隐藏按钮不是授权？
  5. 离职撤权怎样证明在五分钟内完成？

答案 ​

  1. 将部门、地区、项目、例外等每种组合固化为新角色，且缺少生命周期治理。
  2. 安全关键属性通常默认拒绝/要求补充，不能把 null 当低风险；具体按显式策略。
  3. 返回主体到资源的命中关系路径；对调用者不可见节点做脱敏或只给理由码。
  4. 客户端可被绕过，攻击者可直接请求 API；PEP 必须位于服务端不可绕过边界。
  5. 离职事件有时间戳和 correlation ID；各目标返回禁用/撤销证据；持续对账；指标计算最后完成时间并告警超时。

D.4 工作负载与零信任题 ​

  1. 为什么共享 Kubernetes 节点角色会破坏工作负载隔离？
  2. SPIRE 如何在不给工作负载 bootstrap secret 的情况下发身份？
  3. mTLS 已建立，为什么还要策略引擎？
  4. 短期证书是不是不需要撤销？
  5. 零信任是否意味着每个请求都让用户重新登录？

答案 ​

  1. 所有 Pod 继承同一云权限，无法按工作负载最小授权和归因。
  2. 本地 Agent 依据调用进程及平台 selectors 做 workload attestation，与注册条目匹配后提供 SVID。
  3. mTLS 只证明对端身份；策略决定该身份可调用哪些资源/动作。
  4. 短期降低暴露窗口，但高风险泄漏仍需删除注册、拒绝身份、轮换信任或其他快速控制。
  5. 不是；可延续受控会话并结合设备、风险和资源敏感度，仅在必要时 step-up。

D.5 检测与 AI 题 ​

  1. 攻击率 0.1% 时“全部判正常”的 accuracy 是多少？为何无用？
  2. 为什么身份模型应按时间切分训练测试？
  3. RAG 加引用为何仍可能越权？
  4. LLM 何时适合身份调查，何时不适合？
  5. 模型阈值为什么是业务决策？

答案 ​

  1. 99.9%，但 recall 为 0，一个攻击也没发现。
  2. 模拟上线只用过去预测未来，避免同一事件/实体未来信息泄漏，并暴露漂移。
  3. 若检索前未强制 ACL，未经授权片段已进入上下文；引用只展示来源，不阻止泄漏。
  4. 适合汇总证据、自然语言查询和调查建议；不适合替代验签、硬授权和无监督高风险封禁。
  5. 不同资源的误报/漏报损失、用户摩擦和处置成本不同，不能由离线模型指标单独决定。

D.6 Agent 安全题 ​

  1. Agent 为什么既需要自身身份又需要用户委托？
  2. token passthrough 的问题是什么？
  3. 为什么提示注入分类器不是安全边界？
  4. 有效 Agent 权限为何是交集？
  5. 怎样设计有效的人类确认？

答案 ​

  1. 自身身份用于验证代码/实例和归因；用户委托说明代表谁、为何、可做什么。缺一无法形成责任链。
  2. 下游可能误把 token 当为自己签发，丢失 audience/主体边界，让中间服务成为混淆代理。
  3. 攻击可变形且与正常内容混合；分类会漏报，必须用权限、隔离、审批限制成功后的影响。
  4. 用户有权不代表 Agent 应全部获得；Agent 被配置的能力也不能超出用户；任务和实时风险进一步收窄。
  5. 显示并绑定真实目标、动作、关键参数、数据范围和影响；高风险 step-up；批准后参数不可被替换；避免泛化和确认疲劳。

D.7 设计题 ​

  1. 为“员工让 Agent 汇总邮件并自动创建工单”画信任边界，列五个威胁和五条不变量。
  2. 为 1000 万用户 App 设计账号恢复，平衡接管风险与成功率。
  3. 为跨三朵云的支付服务消除静态密钥，设计身份、授权、迁移和回滚。
  4. 为季度权限复核设计排序模型，防止自动撤权伤害业务。
  5. 设计 IdP 签名密钥泄漏的检测、遏制、恢复与沟通。

参考评分点 ​

每题至少覆盖：主体/资源/动作、权威源、信任边界、正常与失败流程、攻击路径、最小权限、密钥、审计、指标、灰度/回滚、用户与业务影响。若包含 AI，补数据、eval、人工监督和漂移；若包含 Agent，补实例身份、委托、tool audience、沙箱、审批和 kill switch。