用途
该技能用于在执行安全架构评审（Security Architecture Review）时提供结构化的检查框架。当用户提出“review the security architecture”“check authentication patterns”“evaluate trust boundaries”等请求时应当启用。它帮助评审者系统性地检查认证、授权、数据保护、信任边界与架构决策等维度，并给出安全模式与对应反模式的对照参考。
主要能力
认证架构（Authentication Architecture）
针对基于令牌的认证，逐项对照检查：
- 签发（Issuance）：安全模式为短时效令牌配合刷新机制；反模式为永不过期的长期令牌。
- 校验（Validation）：安全模式为每个请求都校验签名、签发方、受众与过期时间；反模式为只校验签名，或对“内部”调用跳过校验。
- 服务端存储：安全模式为无状态 JWT 或服务端会话存储；反模式为将令牌存于查询字符串或 URL。
- 客户端存储：安全模式为 HttpOnly Secure Cookie 或安全的平台存储；反模式为 localStorage、sessionStorage，或未设置 HttpOnly/Secure 标志的 Cookie。
- 刷新（Refresh）：安全模式为刷新令牌轮换（使用后旧刷新令牌失效）；反模式为不轮换、可重复使用的刷新令牌。
- 吊销（Revocation）：安全模式为令牌黑名单，或短过期时间配合刷新轮换；反模式为对已泄露令牌没有任何吊销机制。
会话管理方面：服务端会话应具有绝对超时（最大会话时长）和空闲超时；会话标识符必须为密码学随机且足够长（128 位以上熵）；认证状态变化（登录、权限提升）后应重新生成会话 ID；在可行时将会话绑定到客户端属性（IP 范围、User-Agent）以做异常检测。
凭据存储方面：密码必须使用现代 KDF 哈希——优先 Argon2id，其次 bcrypt 或高工作因子的 PBKDF2，并使用唯一盐值；不得单独使用原始密码学哈希函数做密码哈希（速度过快，且默认无盐）；盐值应按凭据唯一，以防止彩虹表加速暴力破解。
授权模式（Authorization Patterns）
- 基于角色的访问控制（RBAC）：正确做法是在 API 层显式检查角色（如
[Authorize(Roles = \"Admin\")]）；错误做法是在业务逻辑中用字符串比较检查角色（脆弱、区分大小写、易被绕过）。 - 对象级授权：错误做法是信任路由中的 userId、不做归属校验；正确做法是校验请求用户拥有该资源（示例中比较
cipher.UserId与_currentContext.UserId，不一致时抛出 NotFoundException）。 - 授权原则：在每一层都检查（API 控制器、服务层、数据访问层都应强制授权，不依赖单一检查点）；最小权限（默认拒绝）；失败关闭（检查失败或抛异常时拒绝访问，绝不失败开放）；不信任客户端授权（UI 可见性控制属于用户体验，不是安全措施，始终在服务端强制）。
数据保护（Data Protection）
静态加密：所有敏感数据须以 AES-256 或等效算法静态加密；加密密钥绝不能以可直接访问的方式存储于数据库中而不被另一密钥包裹；使用信封加密——数据用数据加密密钥（DEK）加密，DEK 用密钥管理系统中的密钥加密密钥（KEK）加密；Bitwarden 的端到端加密确保保险库数据在离开客户端前即已加密。
传输加密：最低 TLS 1.2，优先 TLS 1.3；禁用旧协议（SSL 3.0、TLS 1.0、TLS 1.1）；使用强密码套件（密钥交换用 ECDHE，加密用 AES-GCM）；移动应用在适当场景下使用证书固定；内部服务间通信同样应使用 TLS。
数据分级：
- 关键（Critical）：加密密钥、主密码、保险库数据——需要端到端加密、HSM 密钥存储。
- 机密（Confidential）：PII、电子邮件地址、账单信息——需要静态与传输加密、访问日志。
- 内部（Internal）：组织设置、功能开关——需要传输加密、基于角色的访问。
- 公开（Public）：营销内容、公开 API 文档——需要完整性保护。
信任边界（Trust Boundaries）
信任边界存在于数据在具有不同信任级别的组件之间跨越之处，每次跨越都必须校验。常见边界：客户端 ←→ API 网关；API 网关 ←→ 后端服务；后端服务 ←→ 数据库；服务 ←→ 外部 API；浏览器 ←→ 浏览器扩展；主线程 ←→ Web Worker。
每次跨越边界时应：校验所有输入（类型、格式、范围、长度，不信任上游校验）；认证调用方；对操作进行授权；对输出进行净化（按目标上下文编码/转义）；记录跨越（安全相关的边界跨越应可审计）。
零信任原则：不把内部网络位置当作认证的代理；每次服务间调用都应认证与授权；假设网络已被攻破，加密所有内部通信；对来自内部服务的数据与外部输入同样严格校验。
架构决策对齐（Architecture Decision Alignment）
评审设计前，先检查 Bitwarden 的架构决策记录（ADR）中与所评审组件相关的既有决策（规则见 ${CLAUDE_PLUGIN_ROOT}/references/adr-alignment.md：冲突即发现项，未记录的重大决策即缺口，引用前先核实状态）。应用于架构评审时：引用而非仅标记——当设计与已接受的 ADR 冲突时，指明该 ADR，并说明是应修改实现，还是该偏离需要自己的 ADR 来证明例外；关注缺口触发条件——新的信任边界、新的认证模式、新的数据存储，或其他没有相应 ADR 的重大选择，正是应被标记并记录的重大决策。
参考材料
references/crypto-algorithms.md——算法选择表（推荐与弃用）及常见密码学反模式代码示例。references/architectural-anti-patterns.md——常见安全架构反模式（隐式信任、单点故障、不安全默认值、单体认证）及其修复方法。
与威胁建模的连接
架构安全评审直接输入威胁建模流程：信任边界识别为数据流图中的边界划定提供依据；架构弱点成为威胁目录中的威胁；安全属性（认证、加密、访问控制）映射为安全定义中的安全目标；发现的反模式成为 Bitwarden 参与模型第一阶段初始安全评估的候选。开展架构评审时，应考虑发现项是否需要 AppSec 团队（#team-eng-appsec）介入进行完整威胁建模。
使用方式
该技能以规范文本与代码示例的形式提供评审检查项，评审时逐条对照被审系统。触发方式为用户的自然语言请求（如审查安全架构、检查认证模式、评估信任边界等）。具体的调用与安装方式暂未提供。
限制
资料未提供该技能支持的平台、版本要求、依赖项或收费信息。