4、统一身份认证：AD/LDAP集成、SSO单点登录、MFA多因子认证
身份认证这事儿，说实话，是混合云运维里最容易被低估的环节。很多人觉得不就是登个录嘛，搞那么复杂干嘛？但我在几个大项目里吃过亏之后，才真正意识到——身份认证要是没搞好，整个云环境就像没锁门的金库。
今天咱们就聊聊统一身份认证的三个核心模块：AD/LDAP集成、SSO单点登录、MFA多因子认证。这三个东西，说白了就是解决三个问题：你是谁？你能去哪？你怎么证明你是你？
4.1 AD/LDAP集成：把用户目录统一起来
先说说AD和LDAP。很多企业都有Active Directory，这是微软的目录服务。LDAP呢，是轻量级目录访问协议，算是一种标准。我个人的习惯是，不管底层用AD还是OpenLDAP，对外都暴露LDAP接口，这样兼容性最好。
为什么要集成？你想想看，如果每个系统都维护一套用户密码，运维人员得疯掉。我在一个金融客户那里遇到过，他们内部有20多套系统，每套都有自己的用户表。结果呢？员工离职后，IT要跑十几个系统去删账号，经常漏掉一两个，留下安全隐患。
集成AD/LDAP之后，用户信息统一管理。新增、修改、删除，一次操作，所有系统同步生效。这才是运维该有的样子。
核心要点：
- AD/LDAP作为用户身份的唯一数据源
- 所有业务系统通过LDAP协议对接
- 密码策略、账号状态统一管理
具体怎么集成？我拿一个典型的Linux服务器对接AD来举例：
# 安装必要的包
yum install -y sssd realmd oddjob oddjob-mkhomedir adcli samba-common
# 加入AD域
realm join --user=admin@example.com example.com
# 配置SSSD
cat >> /etc/sssd/sssd.conf << EOF
[domain/example.com]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
access_provider = ad
EOF
# 重启服务
systemctl restart sssd
systemctl enable sssd嗯，这里要注意。很多人在配置SSSD的时候，容易忽略access_provider这个参数。我曾经遇到过一个问题，用户能认证成功，但就是登不进去。查了半天，发现是access_provider没配，默认拒绝了所有用户。这个坑，我帮你们踩过了。
4.2 SSO单点登录：一次登录，到处通行
SSO，单点登录。说白了就是你在一个系统登录了，其他系统就不用再输了。这个体验，用过Google账号登录各种网站的朋友应该不陌生。
在混合云环境里，SSO的价值更大。你想想，运维人员可能要同时操作AWS控制台、Kubernetes集群、Jenkins、GitLab、监控系统……如果每个都要单独登录，一天光输密码就得花半小时。
我建议用OAuth 2.0或SAML 2.0协议来实现SSO。这两个是业界主流。我个人更倾向于SAML，因为它在企业级场景下更成熟，尤其是和AD/LDAP的集成更顺畅。
我的经验：
选SSO方案时，别只看技术，还要看生态。比如你们公司主要用AWS，那就优先考虑AWS SSO。如果自建，Keycloak是个不错的选择，开源、功能全、社区活跃。
SSO的典型架构是这样的：
用户 → 访问应用A → 重定向到IDP → 输入凭证 → IDP验证通过
→ 生成Token → 返回应用A → 用户登录成功
→ 访问应用B → 应用B检查Token → 发现已认证 → 直接登录这里面有个关键点：Token的时效管理。我见过一个案例，Token有效期设了24小时，结果有人离职后，他的Token还能用大半天。所以，我建议Token有效期不要超过4小时，并且要支持主动撤销。
4.3 MFA多因子认证：再加一把锁
光有SSO还不够。密码这东西，太容易被攻破了。弱口令、撞库、钓鱼……随便一个漏洞，整个身份体系就崩了。
MFA，多因子认证，就是在密码之外再加一个验证因素。常见的组合是：密码 + 动态验证码、密码 + 生物特征、密码 + 硬件Key。
我在一个政府项目里，要求所有运维人员登录堡垒机时必须使用MFA。一开始大家觉得麻烦，抱怨声不断。直到有一次，一个运维人员的密码被钓鱼邮件骗走了，但攻击者因为没有第二因子，始终登不进去。从那以后，再没人抱怨MFA麻烦了。
避坑指南：
我曾经遇到过一个问题：MFA的验证码时间不同步。原因是服务器时间和手机时间差了30秒，导致验证码总是无效。解决方案是统一使用NTP同步时间，并且把验证码的有效期从30秒延长到60秒。
MFA的实现方式有很多种，我列个表格对比一下：
| 方式 | 安全性 | 用户体验 | 成本 | 适用场景 |
|---|---|---|---|---|
| TOTP（如Google Authenticator） | 高 | 中 | 低 | 通用场景 |
| SMS验证码 | 中 | 高 | 中 | 用户量大的场景 |
| 硬件Key（如YubiKey） | 极高 | 低 | 高 | 高安全要求的场景 |
| 生物识别（指纹/人脸） | 高 | 极高 | 中 | 移动端场景 |
我个人推荐TOTP方案。成本低、安全性高、不依赖网络。你只需要在手机上装个验证器App就行。像Google Authenticator、Microsoft Authenticator、Authy都挺好用。
4.4 三者的整合实践
好了，现在我们把AD/LDAP、SSO、MFA串起来。一个完整的统一身份认证流程应该是这样的：
- 用户访问某个业务系统（比如Kubernetes Dashboard）
- 系统检测到未登录，重定向到SSO登录页
- 用户输入AD/LDAP账号密码
- SSO服务器验证密码，然后触发MFA验证
- 用户输入动态验证码
- 验证通过，SSO生成Token，用户登录成功
- 用户访问其他系统时，SSO自动验证Token，无需再次输入
这个流程看起来简单，但实际落地时有很多细节。我给你们一个参考架构：
+----------------+ +----------------+ +----------------+
| 业务系统A | | 业务系统B | | 业务系统C |
| (K8s Dashboard) | | (Jenkins) | | (GitLab) |
+--------+-------+ +-------+--------+ +-------+--------+
| | |
+---------------------+----------------------+
|
+---------+---------+
| SSO Server |
| (Keycloak) |
+---------+---------+
|
+---------+---------+
| MFA Service |
| (TOTP/硬件Key) |
+---------+---------+
|
+---------+---------+
| AD/LDAP |
| (用户数据源) |
+------------------+这个架构的好处是：每一层都解耦。AD只管用户数据，SSO只管认证流程，MFA只管二次验证。任何一个组件出问题，都不会影响其他组件。
关键配置示例（Keycloak + AD + TOTP）：
# Keycloak中配置LDAP用户联邦
# 1. 创建User Federation → LDAP
# 2. 配置连接参数：
# Connection URL: ldap://ad.example.com:389
# Bind DN: cn=admin,dc=example,dc=com
# Bind Credential: ******
# Users DN: ou=users,dc=example,dc=com
# 3. 开启MFA：
# Authentication → Required Actions → Configure OTP
# → 设置为REQUIRED
# 4. 配置Token有效期：
# Realm Settings → Tokens → Access Token Lifespan: 3600嗯，最后说一句。统一身份认证不是一次性工程。你部署完了，还要持续监控。比如：有没有异常登录？有没有暴力破解？MFA的验证成功率是多少？这些都要有告警。
我记得有一次，半夜两点收到告警，说某个账号在10分钟内尝试了200次登录。一看，是攻击者在暴力破解。但因为启用了MFA，他始终没进去。第二天我们直接封了那个IP，改了密码。你看，MFA关键时刻真能救命。
好了，这一章就到这里。下一章咱们聊聊日志和监控，那是运维的另一只眼睛。