精通 DevOps 工具与最佳实践 - DevOps 知识中心 精通 DevOps 工具与最佳实践 - DevOps 知识中心

本地用户 vs 集中式认证：为 Linux 环境选择正确的设置

探讨在 Linux 环境中，使用本地 `/etc/passwd` 用户管理与基于 LDAP 或 Active Directory 的集中式认证之间的关键抉择。本指南详细介绍了两种方案的优缺点、可扩展性挑战及安全影响。学习何时选择本地简单性，何时选择目录服务提供的强制一致性，包括 SSSD 的作用。

本地用户 vs 集中式认证：为 Linux 环境选择正确的设置

Linux 认证最初只是一个小问题。一台服务器，一个管理员，一个本地账户。然后出现了第二台服务器。接着，一个承包商需要临时访问权限。再后来，有人离开了公司。此时，问题不再是“我能否用 useradd 添加用户？”，而是你是否能证明谁拥有访问权限、能否快速移除访问权限，以及能否在多台机器上保持权限一致性。

本地用户和集中式认证各有其适用场景。对于隔离系统，本地账户简单可靠。一旦 Linux 服务器成为共享基础设施，通过 LDAP、Active Directory、FreeIPA 或类似目录服务实现的集中式认证通常是更合适的选择。

理解本地认证（/etc/passwd 模型）

本地用户管理是处理独立 Linux 机器上用户账户的默认且最简单的方法。所有用户和组信息都直接存储在本地文件系统中。

本地认证的工作原理

用户凭据、用户 ID（UID）、组 ID（GID）、主目录和默认 shell 在特定的系统文件中管理：

  • /etc/passwd：存储用户账户信息，如用户名、UID、主 GID、主目录和 shell。在现代系统上，它通常不存储密码哈希。
  • /etc/shadow：存储加密的密码哈希和密码老化信息（此文件仅 root 可读）。
  • /etc/group：存储组信息。

本地认证的优点

  1. 简单快速：对于一两台机器来说，设置极其容易。添加用户只需使用 useradd 等工具或手动编辑文件（尽管推荐使用工具）。
  2. 离线可用性：即使网络断开或中央认证服务器不可达，用户也能登录。
  3. 无外部依赖：无需额外的基础设施、专用服务器或复杂的网络配置。

本地认证的缺点

  1. 可扩展性问题：在拥有数十或数百台服务器的环境中，保持一致性变得困难。如果一个用户需要访问 20 台服务器，除非你自动化这个过程，否则他们可能需要 20 个账户。
  2. 安全风险：撤销访问权限需要逐个登录到每一台受影响的机器。遗漏一台服务器就会导致未授权账户保持活动状态。
  3. UID/GID 不一致：在多系统间手动管理 UID 常常导致冲突，从而在共享文件系统（如 NFS）时引发权限问题。

UID 问题很容易被低估。Linux 文件所有权以数字 ID 而非名称存储。如果 alice 在一台服务器上是 UID 1001，而 bob 在另一台服务器上也是 UID 1001，那么根据查看位置的不同，共享存储可能会显示文件属于错误的人。这在实验室中令人烦恼，在生产环境中则很危险。

实践示例：添加本地用户

要在本地添加一个名为 analyst1 的新用户：

sudo useradd -m -s /bin/bash analyst1
sudo passwd analyst1
# 根据提示设置密码

理解集中式认证

集中式认证将验证用户身份的责任委托给一个专用的、可通过网络访问的服务。当用户尝试登录 Linux 机器时，该机器会向中央目录服务器查询以进行验证。

关键的集中式技术

在 Linux 环境中，两种主要技术主导着集中式认证领域：

  1. LDAP（轻量级目录访问协议）：一种目录访问协议，通常通过 OpenLDAP、389 目录服务器或作为更大身份平台的一部分来实现。它很灵活，但原始的 LDAP 环境需要仔细设计模式、TLS、复制和访问控制。
  2. Active Directory（AD）：微软的目录服务。Linux 机器通常使用 Kerberos 进行认证，并使用 SSSD 或 Winbind 进行身份查找和组映射，从而与 AD 集成。
  3. FreeIPA/IdM：一个专注于 Linux 的身份平台，结合了 LDAP、Kerberos、DNS、证书和策略管理。当环境主要是 Linux 且你尚未依赖 AD 时，值得考虑。

集中式认证的优点

  1. 单一事实来源：用户的创建、修改和删除在一个地方完成，确保所有连接系统上的即时一致性。
  2. 可扩展性：比手动管理的本地账户可扩展性好得多。虽然仍有运维工作，但用户生命周期管理是集中进行的。
  3. 增强的安全性和合规性：访问撤销可以在一个地方广泛生效，具体取决于缓存设置和服务行为。集中式系统也更自然地与 MFA、密码策略、基于组的访问和审计流程集成。
  4. UID/GID 一致性：集中式系统集中管理 POSIX 属性（UID、GID、主目录），消除了使用共享存储时的冲突。

集中式认证的缺点

  1. 网络依赖性：如果目录服务器或网络连接失败，仅依赖集中式凭据的用户可能无法登录（可通过缓存缓解，见下文 SSSD）。
  2. 复杂性：初始设置需要专用基础设施、网络配置和专门的客户端软件（如 SSSD 或 Kerberos 库）。
  3. 初始成本：虽然 LDAP 可以是开源的，但设置和维护一个健壮的 AD 环境涉及许可和专业知识。

选择正确的策略：环境规模与需求

最佳选择在很大程度上取决于组织的规模、复杂性和安全要求。

特性 本地认证 (/etc/passwd) 集中式认证 (LDAP/AD)
环境规模 少量独立系统 共享集群、团队或企业环境
管理开销 高（每台服务器维护） 低（单一控制点）
安全策略执行 难以保持一致性 优秀（全局策略）
离线访问 优秀 需要缓存（例如 SSSD）
初始设置难度 非常低 高

何时使用本地认证

本地认证适用于：

  • 小型实验室或个人工作站：只有一两个受信任的个人需要访问的环境。
  • 隔离系统：无法或不宜与目录服务器建立网络连接的空气隔离机器或物联网设备。
  • 临时堡垒主机：短暂使用的系统，部署完整的目录集成堆栈显得大材小用。

何时实施集中式认证

集中式认证通常是以下情况的更好选择：

  • 企业环境：用户需要访问多台服务器、网络共享或服务的任何环境。
  • 合规需求：需要审计或严格合规的环境，要求一致的访问控制和审计跟踪。
  • 大规模部署：当入职和离职需要快速、可重复且可审计时。

没有神奇的服务器数量可以适用于所有人。实验室中一台管理员管理的五台服务器可以使用本地用户。三台持有受监管数据的生产服务器可能立即需要集中控制。驱动因素不仅仅是规模，还有风险、人员流动、合规性、共享存储以及访问变更的频率。

实施集中式认证：关键工具

对于许多与 AD、LDAP 或 FreeIPA 集成的现代 Linux 系统，sssd（系统安全服务守护进程）是常见的客户端。较旧的工具如 nss_ldap 和 pam_ldap 在某些环境中仍然存在，但 SSSD 通常是缓存和提供者集成的更好默认选择。

SSSD 的作用

SSSD 充当本地系统服务与远程目录提供者（LDAP 或 AD）之间的桥梁。其关键特性包括：

  1. 缓存：SSSD 在本地缓存认证数据。如果与目录服务器的连接丢失，最近登录过的用户仍可在配置的时间段内进行本地认证，从而解决了离线访问的缺点。
  2. PAM/NSS 集成：它与可插拔认证模块（PAM）和名称服务交换机（NSS）无缝集成，允许标准 Linux 命令（login、ssh）透明地处理远程账户。

实践示例：SSSD 配置片段（概念性）

与 Active Directory 集成通常涉及使用 realm 或 adcli 等工具加入域，然后让 SSSD 处理身份和认证。实际配置取决于域策略、DNS、TLS、访问规则和发行版默认值。这个简化的片段仅显示大致结构：

# /etc/sssd/sssd.conf 用于 AD 集成的片段
[domain/example.com]
cache_credentials = True
ldap_search_base = dc=example,dc=com

[sssd]
services = nss, pam
domains = example.com

不要将一个小片段复制到生产环境并期望它完整。SSSD 需要 /etc/sssd/sssd.conf 的正确文件权限、正常工作的 DNS、Kerberos 的时间同步以及特定于提供者的设置。在推广到整个集群之前，请使用非管理员账户测试登录。

混合设置很常见

即使集中式认证是标准，大多数 Linux 系统仍然保留一些本地账户。root 账户存在。云镜像可能有一个本地引导用户。当身份提供者不可达时，可能需要紧急访问账户。

这没问题，但本地例外需要纪律：

  • 保持本地人类账户数量少。
  • 在适当的情况下使用 SSH 密钥或锁定密码。
  • 定期审计本地账户。
  • 记录紧急访问的使用情况，并在使用后轮换凭据。
  • 避免给每个管理员在每台服务器上分配一个独立的、未管理的本地账户。

一种常见的模式是：正常管理使用集中式登录，基于目录组的 sudo 规则，以及一个严格控制紧急路径。这为你提供了日常的可审计性，同时不会在身份服务中断时使恢复变得不可能。

决定成功的操作细节

集中式认证最常因一些乏味的原因而失败：DNS、时间、证书和缓存。

Kerberos 对时间偏差敏感。如果服务器时钟漂移，即使密码正确，登录也可能失败。使用 NTP 或 chrony 并进行监控。

目录查找依赖于 DNS。如果 Linux 客户端无法可靠地找到域控制器或 LDAP 服务器，认证会感觉不稳定。硬编码单个服务器可能在维护日之前有效。请使用你的目录服务推荐的发现机制。

TLS 对 LDAP 很重要。在没有适当传输安全性的情况下发送凭据或目录数据是一个坏习惯，尤其是在你不完全控制的网络上。验证证书，而不是禁用检查来“让它工作”。

缓存需要有意识的策略。SSSD 可以允许最近认证过的用户在中断期间登录，这很有用。但较长的缓存生命周期可能会延迟撤销。较短的缓存生命周期可以改善控制，但会使中断更痛苦。根据环境的风险进行选择。

用户管理的最佳实践

无论你选择哪条路径，都要遵循这些最佳实践：

  • 避免使用 Root：永远不要使用本地 root 账户进行日常管理任务。使用集中式账户和 sudo 机制。
  • 定期审计：如果使用本地账户，定期审计 /etc/passwd 和 /etc/shadow 以查找未授权或过时的条目。
  • 最小权限原则：确保只授予用户履行其角色所需的最低权限。集中式系统通过组成员身份使这更容易执行。
  • UID 标准化：如果必须同时使用本地账户和集中式账户，确保本地 UID 不与目录用户使用的范围重叠。确切范围因发行版和身份设置而异，因此请记录你的本地约定。

迁移建议

如果你正在从本地用户迁移到集中式认证，不要一次性切换所有服务器。从非关键主机开始。确认用户可以通过 id username 解析，组正确显示，sudo 规则有效，SSH 登录按预期工作，并且缓存登录符合策略。

然后处理文件所有权。如果本地 UID 与目录 UID 不同，文件可能需要更改所有权。共享主目录和 NFS 挂载需要特别小心。在进行批量 chown 更改之前进行备份，并使用真实用户工作流程进行测试。

最后，在目录路径正常工作后，删除或锁定过时的本地账户。让两个系统永久保持活动状态可能会消除你试图获得的许多安全优势。

最终检查

当机器真正独立、访问很少更改且影响范围很小时，本地用户是最佳选择。当人员、服务器和权限变更频繁到手动账户管理成为一种风险时，集中式认证更好。保留本地紧急访问，但使正常路径集中化、可审计且基于组。这是大多数团队可以在不丢失谁可以登录何处的跟踪的情况下操作的设置。