📚 课程目录第3章身份认证

身份认证：用户认证方式（密码、多因素认证、SSO）、认证流程与最佳实践

核心原理：认证的本质与信任边界

身份认证回答的是“你是谁”的问题，其本质是验证用户所声称的身份是否属实。在AI平台中，认证处于安全架构的最前端，一旦被绕过，后续的权限控制、审计追踪都将形同虚设。认证机制通常依赖三类因子：所知（密码、PIN码）、所有（手机令牌、硬件Key）、所是（指纹、人脸）。单一因子存在天然缺陷——密码可能被钓鱼或撞库，令牌可能丢失，生物特征可能被复制。因此，现代AI平台普遍采用多因素认证（MFA），组合至少两种不同类别的因子，以扩大攻击者的绕过成本。

在AI平台场景中，认证还面临特殊挑战：模型训练与推理服务往往需要服务间认证（如Kubernetes中的ServiceAccount），而不仅仅是用户登录；同时，平台管理员、数据科学家、标注人员、外部API调用者等角色差异巨大，需要差异化的认证策略。理解认证的信任边界至关重要——认证只解决“身份确认”，不解决“权限大小”，二者必须分离设计。

关键认知：认证强度应与资源敏感度匹配。面向公网的JupyterHub入口需要MFA+SSO，而集群内部Prometheus抓取指标的请求可使用短时Token或mTLS，不必强制交互式MFA。

三种主流认证方式详解

1. 密码认证：最基础也最脆弱

密码认证仍是AI平台的基础认证手段，但必须配合安全策略使用。常见风险包括弱口令、密码复用、键盘记录器窃取。平台应强制实施密码复杂度策略（至少12位，包含大小写字母、数字与特殊字符），并启用密码哈希存储（推荐bcrypt或Argon2），严禁明文或MD5存储。同时，应设置登录失败锁定策略（如5次失败锁定15分钟），并定期进行密码泄露库比对。

2. 多因素认证（MFA）：显著提升账户安全性

MFA要求用户提供至少两种不同类别的认证因子。在AI平台中，推荐优先支持TOTP（基于时间的一次性密码）或WebAuthn硬件密钥。TOTP实现简单，兼容Google Authenticator等应用；WebAuthn抗钓鱼能力更强，适合管理员账户。短信验证码因其易被SIM卡劫持，不建议作为唯一第二因子。MFA应覆盖所有交互式登录入口，包括Web控制台、SSH登录（可通过PAM模块集成）、API密钥管理界面。

3. 单点登录（SSO）：统一身份入口

SSO允许用户使用企业身份提供方（IdP）的凭证登录多个系统。在AI平台中，SSO通常基于SAML 2.0或OIDC（OpenID Connect）协议实现。OIDC因其基于JSON和RESTful API，更适合云原生AI平台。通过SSO，平台无需存储用户密码，而是信任IdP的认证结果，同时可获得用户的组信息（Group Claim）用于后续RBAC授权。典型流程为：用户访问AI平台 → 平台重定向至IdP → 用户完成认证（可能包含MFA） → IdP返回断言/ID Token → 平台建立本地会话。

认证方式	适用场景	安全强度	用户体验	实施复杂度
密码	内部低敏感工具、临时环境	低（需配合策略）	中	低
MFA（TOTP/WebAuthn）	管理员、生产环境用户	高	中（每次需额外输入）	中
SSO（OIDC/SAML）	企业统一身份、多系统集成	高（IdP决定）	高（一次登录多处访问）	高

认证流程与协议交互

以AI平台集成OIDC SSO为例，完整认证流程涉及三个角色：用户浏览器、AI平台（客户端）、企业IdP（如Keycloak、Okta）。核心流程如下：

用户访问AI平台Web界面，平台检测到未认证，生成随机state参数并构造授权URL。
浏览器重定向至IdP的/authorize端点，携带client_id、redirect_uri、response_type=code。
用户在IdP登录页完成认证（若启用MFA则需额外验证）。
IdP通过浏览器重定向回平台的redirect_uri，并附上授权码code和state。
平台后端使用code向IdP的/token端点换取ID Token和Access Token（此过程为后端到后端，浏览器不可见）。
平台验证ID Token的签名（使用IdP的JWKS公钥）、issuer、audience和expiry。
平台从ID Token中提取用户身份（sub）和组信息（groups），建立本地会话（如设置HttpOnly Cookie），并执行RBAC授权。

# 平台后端使用授权码换取Token的示例（Python + requests）
import requests

token_endpoint = "https://idp.example.com/realms/ai-platform/protocol/openid-connect/token"
resp = requests.post(token_endpoint, data={
    "grant_type": "authorization_code",
    "code": authorization_code,
    "redirect_uri": "https://ai.example.com/callback",
    "client_id": "ai-platform-client",
    "client_secret": "your-client-secret"
})
id_token = resp.json()["id_token"]
# 随后使用JWKS公钥验证id_token签名，并解析sub、groups等claim

最佳实践：认证流程中必须校验state参数以防止CSRF攻击；ID Token的expiry通常较短（如5分钟），平台应使用Refresh Token机制维持会话，而非要求用户频繁重新认证。

案例：某数据科学平台的统一认证改造

某企业AI平台原先使用独立密码库，每个环境（开发、生产）各有一套用户表，导致数据科学家需要记住三套密码，且离职员工账号清理困难。安全审计发现存在多处弱口令和共享账号。平台决定引入Keycloak作为统一IdP，并实施以下改造：

将JupyterHub、MLflow、Kubeflow Dashboard全部接入OIDC SSO，用户使用企业AD账号登录。
为管理员账户强制启用TOTP MFA，普通用户可选启用。
在IdP侧配置组同步：数据科学家组映射到平台的developer角色，运维组映射到admin角色。
对于Kubernetes API访问，使用kubelogin插件完成OIDC认证，生成短期kubeconfig凭证。

改造后，用户只需一次企业认证即可访问所有AI工具，管理员账号因MFA保护而安全性显著提升，账号生命周期管理也收归到企业IT统一流程。整个改造耗时约2周，核心工作量在于各应用的OIDC客户端配置和Claim映射。

常见误区与复盘

误区一：SSO等于万能钥匙。SSO虽然统一了入口，但一旦IdP被攻破，所有下游系统都将失守。因此，IdP自身必须启用MFA、定期审计、最小权限管理。同时，AI平台不应完全信任IdP返回的所有Claim，应验证audience和issuer，防止Token被其他客户端滥用。

误区二：API密钥与用户认证混为一谈。许多AI平台允许用户创建长期API密钥（如sk-xxxx）直接调用模型接口。这些密钥本质上是“服务账户凭证”，应设置独立于用户密码的生命周期、权限范围和IP白名单。密钥泄露后应能快速吊销，且不应在代码仓库中明文存储。

误区三：忽略服务间认证。在Kubernetes中运行的AI训练任务需要访问模型存储或数据库，若仅依赖网络策略而缺乏服务身份验证，容易遭受横向移动攻击。应使用ServiceAccount + 短时Token或mTLS实现服务间双向认证，而非在Pod内硬编码数据库密码。

复盘要点：认证方案设计应遵循“纵深防御”原则——即使某层被突破，后续层仍能抵御。建议每季度审查一次认证日志，关注异常登录时间、IP地理跳跃、多次MFA失败等信号。同时，新接入的AI工具（如向量数据库、模型网关）必须纳入统一SSO体系，避免出现“影子认证”孤岛。