你现在必须实施的五个关键 MongoDB 安全配置
通过身份验证、最小权限角色、网络绑定、TLS 和审计日志检查来保护 MongoDB。
您现在必须实施的五项关键 MongoDB 安全配置
MongoDB 安全问题通常始于一个简单的错误:数据库在不该监听的地方监听,接受不该接受的用户,或者在没有加密的情况下发送流量。您的 MongoDB 配置需要明确的身份验证、细粒度的角色、私有网络暴露、TLS 以及有用的审计记录。
本指南展示了五项生产环境检查,可减少未经授权访问的机会,并使可疑活动更易于调查。
1. 启用强制访问控制和强身份验证
首先确保授权已启用。如果没有授权,能够访问服务器的客户端可能能够根据部署的启动和配置方式读取或更改数据。
如何启用身份验证
身份验证通常通过配置文件 (mongod.conf) 或启动时的命令行标志启用。
配置文件 (/etc/mongod.conf):
# /etc/mongod.conf 片段
security:
authorization: enabled
命令行:
mongod --auth --dbpath /var/lib/mongodb
创建管理员用户
在启用授权之前创建第一个管理用户,或者在初始设置期间使用 MongoDB 的 localhost 异常。创建第一个用户后,重新启动并启用授权,并使用命名帐户进行所有访问。
示例:通过 mongosh 创建 root 用户
首先,连接到数据库(如果已经在没有身份验证的情况下运行,或者使用 localhost 异常):
use admin
db.createUser(
{
user: "mongoAdmin",
pwd: passwordPrompt(), // 安全地提示输入密码
roles: [ { role: "root", db: "admin" } ]
}
)
警告: 始终使用存储在密钥管理器中的强密码。切勿在脚本或配置文件中硬编码敏感凭据。
2. 实施细粒度的基于角色的访问控制 (RBAC)
启用身份验证后,下一步是建立最小权限原则 (PoLP)。这意味着每个用户、应用程序和服务帐户只应拥有执行其所需任务所需的最低权限。
避免对应用程序连接使用 root 或 readWriteAnyDatabase 角色。相反,应定义自定义角色,授予对特定数据库或集合的特定权限。
实用的 RBAC 步骤
- 定义自定义角色: 如果内置角色(
read、readWrite)不足,请创建具有细粒度访问操作(例如,仅对特定集合进行insert和find)的角色。 - 分离应用程序用户: 为不同的应用程序层创建专用用户(例如,后端的
app_rw,分析用的reporting_ro)。 - 限制外部工具访问: 确保管理工具仅在绝对必要时使用特权帐户连接。
示例:为特定数据库创建只读用户
use users_db
db.createUser(
{
user: "reporting_svc",
pwd: passwordPrompt(),
roles: [ { role: "read", db: "users_db" } ] // 仅对 users_db 的读取访问权限
}
)
3. 配置严格的网络绑定和防火墙
网络配置是数据库的边界防御。许多打包的 MongoDB 安装默认绑定到 localhost,但容器镜像、自定义命令行和复制的配置文件可能会暴露 0.0.0.0。始终验证有效的 bindIp,而不是假设默认值是安全的。
限制 bindIp
主要的安全措施是在配置文件中定义 bindIp 设置。这明确告诉 MongoDB 它应该监听哪些 IP 地址或主机名。
配置文件 (/etc/mongod.conf):
# 要绑定的 IP 或主机名列表
# 使用 127.0.0.1 仅限本地访问
# 使用内部 IP 仅限来自应用服务器的访问
net:
port: 27017
bindIp: 127.0.0.1, 10.0.1.5, localhost
实施外部防火墙(安全组)
除了 bindIp(限制 MongoDB 进程)之外,您还必须使用外部防火墙(如 iptables、AWS 安全组或 Azure 网络安全组)在流量到达服务器之前对其进行过滤。
最佳实践: 仅允许来自您的应用服务器、负载均衡器和管理跳板机的 MongoDB 端口(默认 27017)的入站流量。
4. 强制传输中数据加密 (TLS)
客户端、shell、驱动程序和 MongoDB 之间传输的数据应使用传输层安全性 (TLS) 进行加密。通过未加密的连接发送凭据、查询和结果会使数据面临窃听和中间人攻击的风险。
MongoDB 支持用于加密流量和可选客户端证书验证的原生 TLS 配置。
启用 TLS
要启用加密,您必须生成或获取有效的 TLS 证书,并在配置文件中指定其位置。
配置文件 (/etc/mongod.conf):
net:
tls:
mode: requireTLS
# 组合证书和密钥文件的路径
certificateKeyFile: /etc/ssl/mongodb.pem
# 证书颁发机构文件的路径(用于客户端验证)
CAFile: /etc/ssl/ca.pem
使用 TLS 的客户端连接
一旦服务器要求 TLS,所有客户端必须使用适当的安全标志进行连接:
mongosh "mongodb://[email protected]/admin?authSource=admin" --tls --tlsCAFile /path/to/ca.pem
提示: 在生产环境中使用
mode: requireTLS以确保所有连接都是安全的。preferTLS模式通常仅在迁移或测试期间使用。
5. 启用审计并监控活动日志
即使有强大的访问控制和加密,安全威胁也可能来自受损的内部帐户或权限提升。启用全面的审计可以提供操作的历史记录,这对于合规性、取证分析和检测可疑行为至关重要。
MongoDB 的审计功能可以记录管理操作、身份验证尝试、授权失败和选定的数据操作。可用性取决于您的 MongoDB 版本或平台;例如,审计在 MongoDB Enterprise 和 MongoDB Atlas 中可用,而自管理的 Community 部署需要其他日志记录和监控方法。
审计配置
审计通过配置文件中的 auditLog 部分进行配置。您可以指定目标(文件、syslog、控制台)和过滤条件。
配置文件 (/etc/mongod.conf):
auditLog:
destination: file
path: /var/log/mongodb/audit.log
format: JSON
# 重点关注关键安全事件,如身份验证和管理更改
filter: '{ atype: { $in: [ "authenticate", "authCheck", "createCollection", "createUser", "dropDatabase" ] } }'
基本监控关注领域
- 失败的身份验证尝试: 突然激增表明可能存在暴力破解攻击。
- 用户/角色创建/删除: 所有权限更改必须记录和审查。
- 数据库或集合删除: 需要对破坏性操作立即发出警报。
将 MongoDB 审计日志与集中式日志管理系统(如 Splunk、Elastic Stack 或 Datadog)集成,以进行警报和保留。
要点
在每次 MongoDB 部署中检查这五项控制措施:授权已启用,应用程序用户具有细粒度角色,bindIp 和防火墙限制网络访问,客户端需要 TLS,以及安全事件流入您的监控系统。这些检查不能替代备份、修补或密钥轮换,但它们首先弥补了最常见的配置漏洞。