mongodb 8.0 默认仍支持 scram，但 ldap 身份验证已被明确弃用，tls 1.0 彻底禁用；需强制使用 scram-sha-256、强密码策略、关闭 localhost bypass、绑定可信 ip，并优先采用 x.509 或 oidc/aws-iam（限特定部署）等安全机制。
MongoDB 8.0 默认仍支持 SCRAM，但关键变化在于：LDAP 身份验证已被明确标记为弃用，且 TLS 1.0 已彻底禁用。强化身份认证安全，核心不是“加功能”，而是“堵漏洞 + 选机制 + 控传播”。
SCRAM 用户密码必须强制使用强哈希策略
SCRAM 是默认机制，但 db.createUser() 创建用户时若未显式指定 digestPassword: true（默认为 true），或密码本身过短/无复杂度，会显著降低抗暴力破解能力。
- 创建用户时务必确保密码长度 ≥12 位，含大小写字母、数字、符号
- 避免在
db.createUser()中设置digestPassword: false—— 这会导致明文 hash 存储，绕过 SCRAM 安全设计 - 定期轮换密码：用
db.changeUserPassword()替代直接修改系统表，否则可能破坏 SCRAM salt 和 iteration 计数 - 注意：SCRAM-SHA-256 是 MongoDB 4.0+ 的实际默认，不支持旧版 SCRAM-SHA-1；若驱动或客户端硬编码 SHA-1，连接将失败
必须关闭 localhost bypass 并绑定可信 IP
即使启用了访问控制，mongod 默认绑定 localhost 时仍允许免认证的本地 Unix socket 或 127.0.0.1 连接 —— 这不是后门，但极易被共驻进程滥用。
- 在配置文件中显式设置
net.bindIp，禁止使用0.0.0.0或通配符；生产环境只写内网 DNS 名或具体 IP 段（如10.10.0.0/16） - 确认
net.port未暴露在公网防火墙规则中；Linux 上可用iptables -L -n | grep 27017快速核验 - 若用容器部署，
bindIp不能设为0.0.0.0，而应配合 host network 或 service mesh 的 mTLS 控制入向流量
OIDC 和 AWS-IAM 仅限特定部署形态，别误配
MongoDB 8.0 的 OIDC 和 AWS-IAM 身份验证虽已支持，但它们**不适用于自管理单节点或普通副本集**，只在 Atlas M10+ 或 Enterprise 分片集群中完整生效。
- 在自管理部署中启用
security.authenticationMechanisms: ["OIDC"]会导致启动失败，并报错OIDC authentication requires MongoDB Enterprise and a valid IdP configuration - AWS-IAM 要求实例运行在 EC2 上，且需配置 IAM role + 正确的
awsAccessKeyId/awsSecretAccessKey环境变量，本地测试无法模拟 - OIDC 配置依赖外部 IdP（如 Okta、Azure AD）返回的 JWT claim 映射到 MongoDB 角色，映射规则出错会导致
Unauthorized而非Authentication failed，排查更隐蔽
X.509 是生产环境最稳妥的替代方案
当 LDAP 被弃用、SCRAM 不足以满足合规审计要求时，X.509 是目前唯一被 MongoDB 官方持续强化、且同时支持 Community 和 Enterprise 的替代路径。
- 证书必须由受信 CA 签发（自签名 CA 可接受，但需在所有客户端和服务器上部署
CAFile） -
net.tls.CAFile和net.tls.certificateKeyFile路径权限必须为600，否则 mongod 拒绝启动 - 客户端证书的
subjectCN 或 SAN 必须与 MongoDB 用户名完全一致（例如证书 CN=app-reader → 用户名必须是app-reader，且在admin库中存在） - 注意：X.509 用户创建时需指定
roles，但不能用db.auth()登录 —— 必须通过驱动传入证书，mongosh --tls --tlsCertificateKeyFile才生效
真正容易被忽略的是：所有身份验证机制都依赖 TLS 加密通道成立。哪怕开了 SCRAM，若没配 net.tls.mode: requireTLS，凭证仍以明文在链路上传输。别只盯着认证逻辑，先守住 TLS 这道底。
