最小权限与访问治理

• 理解 BeyondCorp 的核心思想（不信任内部网络）
• 掌握身份与设备状态驱动的访问决策
• 能说明替代 VPN 的落地要点

BeyondCorp 是 Google 提出的零信任模型，核心思想是"不再信任内部网络"，所有访问都基于身份与设备状态进行验证与授权。访问决策由多因素构成：主体身份（用户/服务）、设备状态（健康度、补丁、合规、是否受管）、访问上下文（时间、位置、行为）与资源属性，共同决定是否放行。替代传统 VPN 的落地要点：建立统一身份源与 MFA；建设设备清单与健康检查（如 Endpoint 管理、设备证书）；将应用按需暴露而不依赖网络边界，通过基于身份的设备策略（如 access proxy）控制访问；实现动态授权与持续验证，而非一次登录永久信任；对敏感资源做细粒度权限与审计。整体上是"以内网不可信为前提，用身份+设备+上下文做动态授权"。

考察零信任的落地能力。核心是"去内网信任、身份设备驱动、动态授权"，并说明替代 VPN 的具体工程要点。

• 理解 PAM 的凭据托管与访问控制
• 掌握自动轮换与到期策略
• 能说明会话审计与监控

PAM（如 CyberArk）实现特权账号全生命周期管理。凭据托管：将特权账号密码从运维人员手中抽离，存入选保险箱（Vault）并加密，用户不应直接持有密码，而是通过安全通道按需取用。自动轮换：平台定期或按事件自动更换密码，校验一致性（如 Windows 域、数据库、设备），更新后同步到目标系统，防止密码长期有效与泄露。会话审计：通过特权会话代理（PSM）建立代理会话，监控操作、记录屏幕/键盘流水、支持录屏与回放，并可在会话中执行命令审批与拦截。同时集成 MFA、审批流与访问策略，实现"整个生命周期、最小权限、全程审计"。整体上"托管+轮换+代理审计"三位一体。

考察对 PAM 能力的理解。核心是"凭据集中托管、自动轮换、会话代理审计"，并体现最小权限与合规价值。

• 理解 Boundary 的架构与定位
• 掌握动态授权与凭据代理机制
• 能说明会话审计与最小权限

HashiCorp Boundary 是一种面向访问的零信任工具，用于管理用户对基础设施（主机、数据库、K8s）的会话级访问。动态授权：通过角色（roles）与策略定义用户可访问的目标，授权随用户身份与上下文动态判定，不依赖固定的网络位置。凭据代理：Boundary 作为凭据代理，将后台凭据（如 SSH 密钥、数据库口令）安全地注入用户会话，用户不必直接持有长期密钥，且凭据可动态生成、短期有效。会话审计：所有会话经 Boundary 建立，支持会话生命周期管理、连接审计与注销，敏感操作可配置"会话录制/审批"。整体上实现"按需授权、凭据不落地、会话可审计"的最小权限访问。

考察对现代访问代理工具的理解。核心是"角色动态授权 + 凭据代理 + 会话审计"，体现零信任与最小权限的落地。

• 理解 SDP 的架构与原理
• 掌握单包授权（SPA）机制
• 能说明动态防火墙与隐藏服务

SDP（Software Defined Perimeter）通过"先验证后连接"的架构实现网络层最小暴露。核心机制是单包授权（SPA，Single Packet Authorization）：客户端在连接前发送一个包含身份与授权信息的加密 UDP 包，SDP 控制器验证后才开放特定端口；在未获授权前，服务端口对任何未授权主机不可见（隐藏），从而大幅缩小攻击面。动态防火墙：SDP 控制器根据授权结果动态下发防火墙规则，仅允许已认证的客户端访问特定服务，连接结束后自动撤销规则。整体上"SPA 验证 + 隐藏服务 + 动态开墙"，使服务只对已验证主体短暂可见，实现最小暴露与网络层面的零信任。

考察对 SDP 技术细节的理解。核心是"SPA 单包授权 + 动态防火墙 + 服务隐藏"，体现网络层最小暴露的实现原理。

• 理解 ABAC 的属性模型
• 掌握属性驱动的策略判定
• 能对比 ABAC 与 RBAC 的优劣

ABAC（基于属性的访问控制）通过主体属性（用户角色、部门、级别）、资源属性（数据敏感度、类型）、环境属性（时间、位置、设备状态、上下文）的组合，用策略规则动态判定是否授权。例如"仅当用户部门=财务 且 时间在办公时段 且 数据敏感度=低 才可访问"。与 RBAC 相比：RBAC 以预定义角色为中介，简单直观、易管理、适合角色稳定的场景；ABAC 更细粒度、动态、可表达复杂上下文，适合变化频繁、多约束的场景。ABAC 的劣势是策略复杂、难以维护、性能与审计成本高，可能出现策略冲突；RBAC 的劣势是角色爆炸与粒度不足。实践中常 RBAC 与 ABAC 结合，用角色做粗粒度、属性做细粒度增强。

考察授权模型的理解与对比。核心是"ABAC 属性驱动、动态细粒度；RBAC 角色中介、简单稳定"，并说明二者的结合使用。

• 理解 STS 临时凭证的机制
• 掌握其最小权限与短时效优势
• 能说明与传统凭证的风险差异

AWS STS（Security Token Service）通过 AssumeRole 等接口为身份签发短期临时凭证（AccessKey + SecretKey + SessionToken），有效期通常 1 到 12 小时，可附加会话策略收紧权限。优势：短时效降低了凭证泄露的暴露窗口，即使泄露也在短时间内失效；支持按需动态签发最小权限（结合权限边界与会话策略）；无需长期维护与轮换长期密钥；可通过角色切换实现跨账号、跨服务的联邦访问。风险与注意事项：需确保 STS 签发方（身份/角色）本身安全，防止未授权角色被误用；临时凭证仍需保护（传输与存储）；会话策略需正确配置，避免权限过宽；依赖时间同步与时钟漂移。整体上"短时效 + 动态最小权限 + 避免长期密钥"，是云环境最小权限的推荐模式。

考察云凭证安全。核心是"临时凭证短时效、动态最小权限、降低泄露风险"，并点出需保护签发方与会话策略。

• 理解 JWT 结构与 Claims 设计
• 掌握过期、撤销与泄露的应对
• 能说明最小权限与安全设计

JWT 的 Claims 用于承载授权信息，常见设计包括：sub（主体）、iss（签发者）、aud（受众）、exp（过期时间）、以及自定义权限 Claims（如 roles、scopes、permissions、资源限制）。设计时应只放最小必要授权信息，避免放敏感数据（如密码、PII），并明确 scope 粒度以支持最小权限。应对措施：过期——设置合理的 exp 并验证，过短则频繁刷新、过长则泄露窗口大，通常用短 access token + 长 refresh token 组合；撤销——JWT 无状态、难以主动吊销，需配合黑名单（redis 存储撤销的 jti）、token 版本号或短时效 + 刷新机制；泄露——使用 HTTPS、传输加密、服务端校验签名与 issuer/audience、绑定设备/IP 上下文、泄露后通过版本号或黑名单立即使失效。整体上"最小 Claims + 短时效 + 黑名单 + 签名校验"。

考察 JWT 授权与安全设计。核心是"Claims 最小化、过期与刷新、撤销机制（黑名单/版本号）、泄露应对"，体现对无状态令牌局限的认知。

• 理解 OPA 与 Rego 的授权模型
• 掌握策略分层与测试
• 能说明审计与版本管理

OPA（Open Policy Agent）是通用策略引擎，将授权决策从应用中解耦，通过 Rego 语言编写策略。OPA 通过查询接口（如 data.xxx.allow）接收输入（用户、资源、上下文），用 Rego 规则计算 allow/deny 决策，实现细粒度授权。策略分层：策略按模块化组织，如基础层（通用安全规则）、应用层（业务授权）、环境层（环境差异），通过 package 与 import 复用，避免重复与冲突。测试：用 OPA 内置的单元测试（rego test）编写输入输出用例，覆盖正常与拒绝场景，支持 CI 集成。审计：OPA 决策可实时输入审计日志（带入决策、输入、策略版本），追踪每次授权判定；策略应纳入版本管理（git）、评审与发布流程。整体上"Rego 决策 + 分层模块 + 测试用例 + 版本审计"。

考察对策略引擎的理解。核心是"Rego 声明式授权、分层复用、测试驱动、审计可追溯"，体现工程化策略治理。

• 理解 RBAC 的角色-权限模型
• 掌握角色爆炸与权限泛滥的成因
• 能说明治理手段

RBAC 通过"用户-角色-权限"三层建模：权限是原子操作（如读、写、执行），角色是权限集合，用户被赋予角色即获得权限。治理关键：角色命名规范、权限最小化、角色与权限的解耦管理。角色爆炸指角色数量不断膨胀（因权限组合过多、命名混乱），治理手段：对权限做合理聚合与角色层级化（父角色继承）、定期合并相似角色、用 RBAC 与 ABAC 结合降低角色数量、建立角色审批与回收机制。权限泛滥指用户被授予过多权限，治理手段：最小权限原则下初始只授必要权限、定期权限复核与回收、实施职责分离（SoD）、通过权限影响分析防止越权。整体上"用户-角色-权限建模 + 角色合并 + 最小权限 + 定期复核"。

考察 RBAC 建模与治理。核心是"三层建模、角色爆炸需合并/层级化、权限泛滥需最小权限与复核"，体现治理的系统性。

• 理解 Zanzibar 的关系型模型
• 掌握关系图与可达性判断
• 能说明适用规模与场景

Zanzibar（Google 开源）是一种关系型授权模型，以"用户-对象-关系"三元组为核心，如 (user:alice, viewer, doc:123)，表示 alice 对文档 123 有查看权限。权限判定通过关系图的遍历与可达性计算：某个用户对某对象是否有权限，取决于该用户是否在目标对象的关系空间中可达（如通过组、继承、共享关系）。它支持关系层级（如 folder 与 doc 的继承）、团队/群组授权与可扩展的社交类授权。Zanzibar 适合大规模、高并发、关系复杂场景，如社交网络、文档协作、内容平台（需要弹性扩展与低延迟判定）。相对而言，对简单、静态的角色权限场景，RBAC/ABAC 更轻量。整体上"关系三元组 + 图遍历判定 + 大规模低延迟"。

考察对现代授权模型的理解。核心是"用户-对象-关系三元组、关系图可达性、适合大规模复杂关系场景"，并说明与 RBAC/ABAC 的适用边界。

• 理解凭据代理的机制与价值
• 掌握短期凭据签发与注入
• 能说明最小权限与安全收益

凭据代理（credential broker）作为中间层，将长期密钥与凭据集中管理，应用与运维不再直接持有长期密钥。当应用需要访问数据库/云服务时，向代理发起请求，代理基于身份与策略验证后，按需签发短期凭据（如 STS 临时凭证、动态数据库口令），并注入到应用会话中；凭据在短时效后自动失效，从而卸载长期密钥的持有与轮换负担。运维人员可通过代理按需取用特权凭据，但凭据不落盘、不留存明文。收益：减少长期密钥的泄露面与轮换成本、支持动态最小权限（按请求签发最窄权限）、全程审计凭据使用。整体上"集中托管 + 按需签发短期凭据 + 动态最小权限 + 全程审计"。

考察对现代凭据管理模式的认知。核心是"代理集中托管、短期动态签发、应用不持有长期密钥、审计闭环"，体现最小权限落地。

• 理解项目粒度的资源边界划分
• 掌握跨项目越权的防护
• 能说明权限扩散的治理

基于项目的授权模型以"项目"为资源组织与权限边界，属于同一项目的资源与用户共享该项目的权限范围，如云平台的项目/资源组、租户隔离。划分资源边界：按业务、团队、环境（开发/测试/生产）划分项目，资源归属到具体项目，权限授予到项目而非全局。避免跨项目越权：通过项目级权限隔离（用户只能访问其所属项目资源）、项目间资源默认不可见、跨项目访问需显式授权与审批、结合 IAM 策略与项目维度的权限边界（如 permissions boundary）限制最大权限。避免权限扩散：对项目内用户授予最小权限、定期复核项目成员与权限、自动化回收离职/调岗用户、限制跨项目角色数量。整体上"项目即边界 + 显式跨项目授权 + 最小权限与定期复核"。

考察云/多租户下的权限治理。核心是"项目划边界、跨项目需显式授权、最小权限与复核防扩散"，体现资源与权限的耦合管理。

• 掌握权限复核的频率与范围设计
• 理解审批流程与自动回收
• 能说明与 HR 系统的集成

定期权限复核（access review）是发现并纠正权限泛滥的关键手段。复核频率：按风险分级，高风险系统（生产、财务、特权）每季度或更频繁，低风险系统半年/年度；复核范围应覆盖用户账号、角色、权限与特权访问。审批流程：由资产 owner/业务负责人对用户权限逐项确认，分为"保留/调整/撤销"三类，形成复核记录与审批留痕。自动回收机制：对复核中标记"撤销"、或超过复核期限未确认、或离职/调岗账号的权限，通过自动化脚本/流程自动回收，并配合临时冻结与通知。HR 系统集成：HR 的入职/离职/调岗事件自动触发账号权限的创建、变更与回收流程（如离职即停用），实现身份治理与权限治理的联动。整体上"分频复核 + 审批留痕 + 自动回收 + HR 事件驱动"。

考察身份治理与权限治理的落地。核心是"按风险分级复核、审批留痕、自动回收、HR 联动"，体现权限生命周期的闭环管理。

• 理解最小权限与零信任的关系
• 掌握持续验证如何补足静态授权局限
• 能说明动态授权价值

最小权限与零信任是互补关系：最小权限定义了"授权范围"（静态地限制用户能做什么），零信任强调"持续验证"（动态地确认每次访问是否可信）。最小权限作为静态基线，在授权时设定权限边界，但静态授权一旦授予，在会话期内可能被滥用或随上下文变化而过时。零信任的持续验证补足这一不足：每次访问都重新评估身份、设备、上下文与风险，支持动态收紧（如检测到异常行为立即降权/撤销）、基于上下文的动态授权（如敏感操作需重新认证）、以及会话级而非长期性授权。因此，最小权限提供"静态边界"，零信任提供"动态校验"，二者结合实现"既限制了能做什么，又确保每次访问都可信"。

考察对两者关系的概念理解。核心是"最小权限是静态基线、零信任是动态验证"，并说明持续验证如何应对授权漂移与滥用。

• 理解最小权限模型的核心概念
• 掌握职责分离的应用
• 能说明授权生命周期管理

最小权限模型落地的核心概念：主体——用户、服务账号、机器身份等受控实体，需明确身份与归属；权限——访问资源所需的最小操作集合，遵循"够用即可"原则，避免过度授权；职责分离（SoD）——将相互冲突的关键职责拆分为不同主体承担（如开发与运维、审批与执行、审计与操作），防止单一主体滥用权限；授权生命周期——包含授权申请、审批、授予、使用、定期复核、变更与回收全流程，保证权限从"授予"到"撤销"始终受控。落地时通过权限矩阵、角色与策略、审批流、定期复核和自动化回收机制实现上述概念，并配合最小权限校验与审计。整体上"明确主体、最小权限、SoD 拆分、生命周期闭环"。

考察对授权治理框架的整体把握。核心是"主体-权限-职责分离-生命周期"四要素及其落地机制，体现系统性治理思维。

• 理解 JIT（Just-In-Time）临时提权机制
• 掌握提权时限与审批链设计
• 能说明操作审计与自动降权

JIT（Just-In-Time）临时提权让用户平时保持低权限，仅在需要时按需临时获得更高权限，是实现最小权限的重要手段。落地要点：提权时限——临时权限设置有效期（如 30 分钟到数小时），到期自动失效，避免长期高级权限；审批链——按提权风险设置审批链（尽量自动化审批，高风险需人工审批），例如利用工单或 IAM JIT 服务，审批通过才签发临时凭证；操作审计——提权期间的所有操作全程记录与审计，留痕可追溯；自动降权——提权到期或任务完成后自动降回低权限，无需人工操作，并可与工单/会话绑定。整体上"低权限常态 + 按需提权 + 时限/审批 + 审计 + 自动降权"。

考察最小权限的动态落地。核心是"JIT 临时提权、时限、审批链、审计、自动降权"，体现"平时最小、用时短暂、全程可审计"。

• 理解 Kamus 的加密机制
• 掌握加密密钥与解密授权
• 能说明最小权限与集成

Kamus 是一个开源工具，用于在 Kubernetes 中加密 Secrets，实现"加密干拔"（encrypted secrets）——YAML 中的 Secret 以密文存储，只有授权的应用在运行时才能解密。其机制：加密时使用 Kamus 加密器（基于公有云 KMS 或本地加密服务）生成密文，密钥由云 KMS 管理；解密时应用容器内的 Kamus 解密器（作为 sidecar 或 init container）在运行时解密，解密权限由云 IAM/KMS 授权严格控制，仅授予特定 ServiceAccount 或工作负载。由此实现最小权限访问：开发者看不到明文密钥，应用按需在运行时解密，密钥不落明文于仓库。整体上"KMS 加密 + 运行时解密 + 按工作负载授权"，保护密钥并细化访问控制。

考察对 K8s 密钥管理工具的理解。核心是"加密存储、运行时解密、KMS 授权最小化"，体现云原生密钥最小权限。

• 理解 IAM permissions boundary 与 SCP 的作用
• 掌握二者的组合与层级
• 能说明最大权限范围控制

AWS 中，permissions boundary 与 SCP（Service Control Policy）从不同层级限制最大权限范围。SCP 作用于组织/OU/账号层级，是组织级策略，限制账号内所有 IAM 实体的最大权限（结构性的上限），即使账号给角色授予再多权限，也不能超出 SCP 允许范围。permissions boundary 作用于单个 IAM 角色/用户，是"边界策略"，限制该实体的最大权限；最终生效权限 = 显式授予的策略 与 权限边界 与 SCP 三者的交集。组合设计：SCP 划定组织级基线与强约束（如禁止生产账号删除资源），permissions boundary 为团队/角色设定上限，再在角色内授予实际最小权限。这样"组织级 SCP 兜底 + 实体级边界设限 + 角色最小权限"，实现纵深的最大权限控制。

考察云 IAM 的层级权限控制。核心是"SCP 组织级上限、permissions boundary 实体级上限、最终权限取交集"，体现纵深防御式权限设计。

• 理解云 IAM 策略语法与最小权限
• 掌握策略生效范围与作用域
• 能说明冲突处理与优先级

云平台 IAM（如腾讯云 CAM）通过声明式策略语法实现最小权限：策略由"作用（Action）、资源（Resource）、条件（Condition）、效果（Effect）"组成，如只允许对指定资源执行特定操作，可在策略中限定资源范围与条件来实现最小权限。生效范围：策略可通过直接绑定到用户/角色/组，或通过组织级/项目级策略生效，作用域决定能访问的资源范围。冲突处理：多个策略叠加时，通常按"显式拒绝（Deny）优先于允许（Allow）"的原则，即任何显式 Deny 都覆盖 Allow；同时配合权限边界（如 CAM 的权限边界）限制最大权限。实践上通过"最小 Action + 限定 Resource + 条件 + Deny 优先"来设计策略，避免权限过大与冲突。整体上"语法声明 + 作用域限定 + 拒绝优先 + 边界兜底"。

考察云 IAM 策略的最小权限落地。核心是"Action/Resource/Condition 限定、Deny 优先、作用域与边界"，体现云平台策略设计能力。

• 掌握各场景的最小权限落地
• 识别常见风险点
• 能说明实践细节

数据库：应用账号仅授予最小 DML 权限（如 SELECT/INSERT 于特定表），运维账号通过 PAM 取用临时权限，禁止 use 超级用户；风险点是滥用 root/管理员账号、权限长期未回收。CI/CD：流水线使用最小权限的专用服务账号，按项目隔离 Secret，权限只到构建/部署所需资源，避免使用全局密钥；风险点是凭据硬编码、流水线权限过大、密钥共享。云控制台：员工按角色授予最小权限，配合权限边界、MFA 与定期复核，高风险操作加审批；风险点是权限过大、离职未回收、临时凭证过期管控不严。落地要点：最小权限 + 临时凭证 + 定期复核 + 权限边界 + 审计，风险点本质是"过度授权、长期有效、未复核、无边界"。整体上"按场景最小化 + 动态临时 + 边界 + 复核"。

考察最小权限的实战落地。核心是"各场景最小权限配置 + 常见风险（过度授权/长期密钥/未复核）"，体现对典型生产环境的把控。

• 识别最小权限落地的常见误区
• 掌握平衡安全与可用性的方法
• 能说明正确做法

最小权限落地常见误区：一次性授予过多权限——为图省事直接给最大权限，导致权限泛滥；过度拆分——把权限拆得过于细碎，导致管理成本高、影响业务可用性；缺少定期复核——权限授予后不回收，长期累积过期权限；只做静态授权、无动态校验——权限一旦授予即长期有效。正确做法：按需分级授权，先授予最小必要权限，随业务需要按流程增补；采用动态临时授权（JIT、临时凭证）兼顾安全与可用性；通过角色/策略聚合管理，避免过度拆分；定期复核与回收，联动 HR 离职/调岗；配合权限边界与审计。整体上"先最小后按需增补 + 动态授权 + 合理粒度 + 定期复核"。

考察对最小权限落地平衡的认知。核心是"避免过多授权与过度拆分、用动态授权与定时复核平衡安全与可用性"，体现务实落地的思维。

• 理解机器身份密钥轮换的必要性
• 掌握双密钥过渡与轮换频率
• 能说明自动化工具与失败回退

服务账号/机器身份密钥轮换是降低长期密钥泄露风险的关键。轮换频率：按密钥类型与风险设置周期（如 30/90 天），敏感或高流动性密钥加密，并支持按需紧急轮换。双密钥过渡：在轮换时同时保留新旧两个密钥（共 2 个），新密钥先上线并验证，旧密钥在确认无依赖后移除，避免"切一半"导致的可用性中断。自动化轮换工具：使用云 KMS/Secrets Manager、或 HashiCorp Vault 等工具自动生成新密钥、更新下游依赖并撤销旧密钥，定时触发并记录审计。轮换失败回退：若新密钥未生效或依赖更新失败，自动回退到旧密钥，保留旧密钥有效期（如 24h 宽限期），并告警与重试；回退后排查原因再重新轮换。整体上"周期轮换 + 双密钥过渡 + 自动化 + 失败回退"。

考察机器身份密钥治理。核心是"轮换频率、双密钥平滑过渡、自动化、失败回退"，体现对可用性与安全平衡的把握。