2. 身份与访问管理基础

在身份安全工程师的面试中，最容易被低估的往往不是某个具体产品的配置，而是对身份与访问管理（IAM）基础概念的辨析能力。很多候选人能背出“认证是验证你是谁，授权是决定你能做什么”，但一旦面试官追问“认证通过后授权信息从哪里来”“账号开通和权限授予是不是一回事”“审计日志到底该记什么”，回答就开始模糊。这一节我们把认证、授权、审计、身份生命周期四个概念拆开讲清楚，并给出可落地的判断方法。

一、认证：解决“你是谁”的问题

认证（Authentication）的本质是验证主体声称的身份是否真实。这里的“主体”可以是人、服务、设备或应用程序。认证的核心不是“证明身份存在”，而是“证明当前发起请求的实体确实拥有该身份对应的凭证”。

认证因子通常分为三类：你知道的（密码、PIN）、你拥有的（令牌、手机、硬件密钥）、你固有的（指纹、人脸）。多因素认证（MFA）要求组合两类以上不同因子，而不是同一类因子的重复。例如“密码 + 安全问题”仍属于单因素，因为两者都是“你知道的”。

面试中常被追问的一个细节是：认证成功后系统得到了什么？答案是得到一个“已认证的会话或令牌”，其中至少包含主体标识（如 user_id）、认证时间、认证方式、认证强度等。这个结果会作为后续授权判断的输入。以 OIDC 为例，认证成功后返回的 ID Token 是一个 JWT，典型载荷如下：

{
  "iss": "https://idp.example.com",
  "sub": "u-1024",
  "aud": "crm-app",
  "exp": 1735689600,
  "iat": 1735686000,
  "amr": ["pwd", "otp"],
  "acr": "urn:mace:incommon:iap:silver"
}

其中 sub 是主体唯一标识，amr 记录实际使用的认证方法，acr 表示认证上下文等级。面试官如果问“如何判断这次登录是否满足高安全要求”，答案就是检查 acr 或 amr，而不是只看“登录成功”。

二、授权：解决“你能做什么”的问题

授权（Authorization）发生在认证之后，决定已认证主体对特定资源可以执行哪些操作。授权的三要素是：主体、资源、操作，有时再加上环境条件（时间、地点、设备状态）。

主流授权模型包括：

• RBAC（基于角色的访问控制）：权限授予角色，角色授予用户。适合职责边界清晰的场景。
• ABAC（基于属性的访问控制）：根据主体属性、资源属性、环境属性动态计算。适合细粒度、多条件场景。
• ReBAC（基于关系的访问控制）：根据实体之间的关系图判断，如“文档的编辑者”“组织的成员”。

面试中一个高频陷阱是：“用户属于管理员角色，所以能删除所有数据”这句话是否成立？不成立。角色只是权限的集合，真正生效还需要策略评估。例如 ABAC 策略可能规定“管理员只能删除本部门数据，且必须在工作时间内”。因此授权判断的完整输入应包括：主体属性、资源属性、操作类型、环境条件，以及当前生效的策略集。

实际落地时，授权决策通常由 PDP（策略决策点）完成，PEP（策略执行点）负责拦截请求并执行决策。一个简化的策略判断逻辑可以表示为：

决策 = 允许 当且仅当
  主体.部门 == 资源.所属部门
  且 操作 in ["read", "write"]
  且 环境.时间 在 09:00-18:00
  且 主体.认证等级 >= 资源.所需等级

面试官如果问“认证和授权能不能合并”，正确回答是：不能。认证回答“你是谁”，授权回答“你能做什么”，两者失败时的返回码也不同——认证失败通常是 401，授权失败通常是 403。这个区分在排查线上问题时非常关键。

三、审计：解决“发生了什么”的问题

审计（Audit）是对认证、授权、管理操作等事件的记录与追溯。审计不是简单的“打日志”，它需要满足三个基本要求：完整性、不可篡改、可关联。

一条合格的审计事件至少应包含：事件时间、主体标识、主体来源 IP、操作类型、目标资源、操作结果（成功/失败）、认证方式、会话标识、请求追踪 ID。以一次登录失败为例：

{
  "event_time": "2025-01-15T10:23:41Z",
  "event_type": "authentication",
  "subject": "u-1024",
  "source_ip": "203.0.113.45",
  "result": "failure",
  "reason": "invalid_password",
  "auth_method": "pwd",
  "session_id": null,
  "trace_id": "req-7f3a9c"
}

审计与监控的区别在于：监控关注“当前是否异常”，审计关注“过去发生了什么、谁做的、能否作为证据”。面试中常问“审计日志要不要记录密码”，答案是否定的——任何情况下都不应记录明文凭证，但可以记录认证失败原因（如密码错误、账户锁定、MFA 超时）。

审计的另一个关键点是关联分析。单条“登录成功”没有意义，但如果同一账号在 5 分钟内从两个不同国家登录成功，这就是异常。因此审计系统需要支持按主体、会话、追踪 ID 进行聚合查询。

四、身份生命周期：解决“身份从生到死”的问题

身份生命周期（Identity Lifecycle）管理的是身份从创建到销毁的全过程，典型阶段包括：入职开通、变更调整、离职回收、定期复核。很多安全事件不是因为认证或授权算法被攻破，而是因为离职账号未及时禁用、权限未回收。

面试中常被追问的细节是：账号开通和权限授予是不是同一步？不是。账号开通是创建身份主体（如 user_id、邮箱、初始凭证），权限授予是把该主体关联到角色或策略。两者可以自动化串联，但逻辑上必须分开，否则离职时容易出现“账号禁用但权限仍挂在角色上”的残留。

一个可落地的身份生命周期检查清单如下：

阶段	关键动作	判断依据
入职开通	创建账号、分配初始角色、绑定 MFA	HR 入职事件已确认，身份唯一标识已生成
变更调整	转岗时回收旧角色、授予新角色	转岗审批完成，旧权限已解除
离职回收	禁用账号、撤销会话、回收所有权限	离职时间已到，账号状态为 disabled
定期复核	按季度核对角色成员与权限	复核记录已签署，异常权限已清理

这里有一个容易被忽略的点：禁用账号不等于撤销会话。如果用户已经登录并持有有效令牌，禁用账号后令牌在过期前仍然可用。因此离职回收必须同时执行“禁用身份 + 撤销会话/令牌 + 回收权限”三步。面试中如果候选人只回答“禁用账号”，通常会被认为对令牌机制理解不足。

五、四个概念的联动关系

把四个概念串起来看：身份生命周期决定“身份是否存在、是否有效”；认证决定“当前请求是否来自该身份”；授权决定“该身份能否执行该操作”；审计决定“上述过程是否被完整记录并可追溯”。

面试中可以用一个具体场景来检验理解：员工离职当天，账号被禁用，但他之前登录的会话仍在有效期内，且他仍能通过 API 密钥访问数据。这个场景暴露了三个问题：会话未撤销、API 密钥未回收、审计未告警。正确的处理顺序是：先撤销所有活跃会话和令牌，再禁用身份，再回收权限和密钥，最后通过审计确认无残留访问。

掌握这四个概念的辨析，不仅是为了回答面试题，更是为了在实际工作中定位问题。认证失败查凭证和 MFA，授权失败查策略和角色，审计缺失查日志字段和采集链路，生命周期问题查开通回收流程。把问题归到正确的类别，才能选对排查方向。