在不少在线实验环境里，MongoDB 这套数据库安全实验是很多人的第一道坎：前面增删改查跑得挺顺，一到“开启认证”“建用户”“配角色”就开始卡壳，报错信息还特别吝啬，只有一句 Authentication failed，让人摸不着头脑。这篇就把 MongoDB 数据库安全这件事从头到尾拆开讲一遍，从认证开关的原理、SCRAM 密码存储机制、内置角色的选型逻辑，到配置文件逐行拆解、最小权限落地、TLS 与内部认证、备份交接，最后再给一份我自己踩坑攒出来的报错速查表。不管你是刚接触 MongoDB 的新手，还是带过几届实验、想把这套东西讲透的老手，下面这些内容都能直接拿去用。
1. 这门实验在练什么：先把“安全”拆成能动手的三件事
1.1 为什么一上来就讲认证，而不是继续讲增删改查
很多人第一次做数据库安全实验时会有个疑问：语法还没学全，怎么就讲起权限了。这个顺序其实是对的。MongoDB 装完之后默认是完全开放的——监听本地回环、不开认证、任何人都能连上去建库删库。你在本地折腾当然无所谓，但只要这台机器暴露在局域网里，几分钟内就可能被扫到，数据被清空、留下勒索信息的案例在圈内流传过不止一次。所以实验的第一课不是“怎么用”，而是“怎么不让别人用”。
从这个角度看，安全实验的核心其实是三件事：证明你是谁（认证 Authentication）、规定你能干什么（授权 Authorization）、限制你从哪儿来、路上安不安全（网络与传输）。这三件事在 MongoDB 里对应着完全不同的配置位置和命令，混在一起学很容易乱。我建议在动手之前先在纸上把这三层画出来，后面每配一个参数，都知道自己落在哪一层上。
还有一点值得说清楚：MongoDB 的认证和授权是分开的两个开关，security.authorization: enabled打开的是授权，而认证是它的前置条件。这个概念混淆是新手最常见的误区之一——很多人以为开了这个开关就等于“加了密码”，结果连上去发现还是能操作，只是报错变成了“not authorized”，一脸茫然。
1.2 实验环境里真正要验收的三个结果
抛开实验指导书上那些步骤编号，一套 MongoDB 安全配置做完，能用三个结果来验收自己到底有没有做对。第一个结果是：未认证的连接不能执行任何数据操作，随便敲一条db.users.find()应该被拒绝，而不是返回空数组。第二个结果是：不同账号看到的边界不一样，业务账号只能碰自己那个库，碰别的库应该直接报权限错误。第三个结果是：管理员账号能管用户但读不到业务数据，这一点最容易被忽略，也是最能体现“最小权限”思想的地方。
第三个结果值得多说两句。很多人的做法是建一个root角色的大号，然后用这个号干所有事情。在实验环境里这样最省事，但在真实项目里这是标准的反面教材——一旦这个账号的密码泄露，攻击者拿到的是整个实例的控制权。合理的做法是至少拆成两个号：一个只管用户和角色（userAdminAnyDatabase），一个管集群运维（clusterAdmin），业务库各自有独立的读写账号。这个拆分在实验里可能只值两分，但在工程上能救命。
至于操作系统的防火墙、云上的安全组、数据库前面的网关，这些属于环境层面的东西，实验里通常不会涉及，但心里要有数：MongoDB 自身的认证是最后一道门，不是唯一一道门。
1.3 动手前需要准备的环境清单
实验环境一般会预装好 MongoDB，但如果你打算在本地复现一遍，需要准备的东西不多：一个 Linux 或者 macOS 环境（Windows 也能做，路径写法略有差异）、MongoDB 6.0 以上的版本、一个能改配置文件的权限、以及mongosh这个新版 shell。我强烈建议用mongosh而不是老的mongo，因为 5.0 之后老 shell 已经被移除，很多老教程里的命令在新版本上直接跑不通，这也是新手最容易踩的第一个坑。
配置文件的位置各家发行版不太一样，常见的三个路径是/etc/mongod.conf、/etc/mongodb.conf、以及自己编译安装时的自定义路径。启动方式也分 systemd 管理的服务和手动mongod --config启动两种。我个人的习惯是手动启动，参数看得见、日志打得直、出问题好排查，实验阶段强烈推荐这种方式。
还有一件事提前说：改配置文件之前先备份一份。这不是客套话，YAML 对缩进极其敏感，一个 Tab 用错位置，服务直接起不来，而且报错信息往往指向别处，能让人折腾半小时。备份一下，两秒钟的事。
2. 认证开关与配置文件：从“谁都能连”到“凭证入场”
2.1authorization: enabled到底改变了什么
把这一行配置加进去、重启服务之后，MongoDB 的内部行为会发生一个根本性变化：每一条命令在执行前都会先检查当前连接的认证状态和角色权限。没认证的连接只能执行极少数命令，比如ping、hello、buildInfo这类无害的握手命令，任何涉及数据的操作都会被拦下来。
这里有个非常关键的机制叫localhost exception（本地回环例外）：当实例里一个用户都没有的时候，从本机回环地址连进来的连接被允许创建第一个用户。这个设计的用意很实际——你不可能在没有用户的情况下先认证再建用户，那是个死循环。但这个例外只在“零用户”状态下生效，一旦你建了第一个用户，它就永久关闭了。
我在带人做实验时见过太多人栽在这一步：配置里开了authorization: enabled，重启，然后发现自己连不上了，也不知道怎么建第一个用户。原因往往是他们之前已经建过用户，或者数据目录里残留了旧的admin.system.users。遇到这种情况，最直接的办法是先把authorization改回disabled，重启，建好管理员，再改回来。别硬扛。
authorization的可选值其实有三个：enabled、disabled，以及 MongoDB 早期版本的enabled之外还有authentication之类的历史写法，新版本统一用enabled就好。切值之后必须重启mongod，不能热加载，这一点和某些关系型数据库不一样。
2.2mongod.conf逐段拆解与参数取舍
配置文件不长，但每一段都有它的道理。下面这份是我在实验和测试环境里用得最多的一份模板，注释我写在旁边：
systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true storage: dbPath: /var/lib/mongo journal: enabled: true net: port: 27017 bindIp: 127.0.0.1 security: authorization: enabledsystemLog这一段看着不起眼，但它决定了你出问题时能不能看到线索。destination: file配上logAppend: true保证日志追加而不是覆盖，排查认证失败时，日志里会明确写出“Authentication failed”以及是哪个用户、哪个库、哪条命令触发的，比客户端那句干巴巴的报错有用得多。
storage.dbPath是数据目录，注意权限——mongod进程的运行用户必须对这个目录有读写权限，否则启动直接失败。很多人从别处拷贝了一份数据目录过来，权限不对，服务起不来，还以为是配置写错了。
net.port默认 27017，实验里用默认值最省事。net.bindIp是重中之重，默认只绑127.0.0.1，意味着只有本机能连。如果你需要别的机器连进来，得改成0.0.0.0或者具体的网卡 IP，但这一步要格外谨慎——在开认证之前改 bindIp，等于把大门敞开。正确顺序永远是：先开认证、建好账号，再放开监听地址。这个顺序搞反，是安全事故的经典成因。
security.authorization前面讲过了。这里补一句：如果你还要做副本集，security段里还得加keyFile或者clusterAuthMode，这属于进阶内容，第 4 节会展开。
2.3 密码在库里长什么样：SCRAM 机制拆解
这部分很多人做实验时是跳过的，但它恰恰是理解“为什么改了密码老连接还通”这类问题的钥匙。MongoDB 从 3.0 开始默认用 SCRAM 做认证，4.0 之后同时支持 SCRAM-SHA-1 和 SCRAM-SHA-256 两种摘要算法。
SCRAM 的核心思想是服务端不存明文密码，也不存密码的简单哈希，而是存一组可以验证客户端但无法反推密码的凭证。以 SCRAM-SHA-256 为例，用户文档里存的是salt（盐）、iterationCount（迭代次数，MongoDB 默认 15000）、storedKey和serverKey四个字段。认证时客户端和服务器通过一串挑战-响应的交互，各自算出结果比对，全程密码本身不落地、不传输。
你可以用下面这个命令亲眼看看存的是什么：
use admin db.system.users.find({ user: "dbAdmin" }, { credentials: 1, roles: 1 })你会看到credentials里是一堆 base64 字符串，看不到任何明文。这个认知很实用：如果你在两台机器之间迁移用户，直接拷贝system.users文档是可行的（凭证可以复用），但如果换了认证机制，就得重新设密码。
还有一个坑值得提前说：同一个用户可以同时拥有 SCRAM-SHA-1 和 SCRAM-SHA-256 两套凭证，这取决于创建用户时是否指定了mechanisms参数。老客户端只支持 SHA-1，新客户端优先走 SHA-256，混用环境里如果只保留了 SHA-256 凭证，老驱动就会认证失败。排查“同样的密码，一个工具能连一个不能连”时，先往这个方向想。
3. 用户与角色：最小权限原则怎么落成具体命令
3.1 内置角色速查与选型思路
MongoDB 的内置角色有几十个，全部背下来没必要，但常用的那十来个必须心里有数。我把实验和日常运维里最常打交道的列在下面，按“能干什么”而不是“叫什么”来记会更牢：
| 角色名 | 作用域 | 实际能干什么 | 典型用途 |
|---|---|---|---|
read | 单库 | 只读该库所有集合 | 报表、审计读取 |
readWrite | 单库 | 读写该库所有集合 | 业务应用账号 |
dbAdmin | 单库 | 建索引、看统计、改集合选项 | 库级运维 |
userAdmin | 单库 | 管理该库的用户与角色 | 库级账号管理 |
userAdminAnyDatabase | 全局 | 管理所有库的用户 | 管理员账号 |
readAnyDatabase | 全局 | 读所有库 | 跨库分析 |
clusterAdmin | 全局 | 副本集、分片、节点管理 | 集群运维 |
root | 全局 | 所有权限 | 仅在完全可控环境使用 |
选角色的第一个原则是：能落到单库就不给全局。业务账号一律用readWrite绑在具体库上，不要图省事给readWriteAnyDatabase。第二个原则是读写分离，很多业务其实只需要读，给个read就够了，写权限应该是有明确需求才授予。第三个原则是管理权和数据权分离，管用户的号不应该有读数据的权限，这个分离在实验评分里不一定体现，但在真实审计里是硬要求。
还有两个容易被忽略的角色值得提一句：backup和restore。做备份的账号只要这两个就够了，不需要给它root。很多人配备份脚本时图省事直接用管理员账号，脚本一旦泄露，风险成倍放大。
3.2 建管理员、建业务账号的完整实操
创建一个具备用户管理能力的管理员，命令本身很短，但参数背后有讲究：
use admin db.createUser({ user: "accountAdmin", pwd: "Str0ng_Passw0rd#2024", roles: [ { role: "userAdminAnyDatabase", db: "admin" }, { role: "clusterMonitor", db: "admin" } ], mechanisms: ["SCRAM-SHA-256"] })几个细节。use admin必须写，因为用户信息是跟着库走的，admin库下的用户是全局可见的，其他库的用户只在该库内有效。roles数组里的db字段也必须写，虽然看着冗余，但它是角色作用域的一部分。mechanisms指定只用 SHA-256 更安全，前提是你的客户端都支持。
业务账号的创建方式略有不同：
use appdb db.createUser({ user: "app_rw", pwd: "Another_Str0ng#2024", roles: [ { role: "readWrite", db: "appdb" } ] })注意这里是先use appdb，用户就建在appdb库里。这就引出一个必须记住的规则：连接时要用--authenticationDatabase指定用户所在的库。如果app_rw建在appdb里，你却在连接时指定authSource=admin，那必然认证失败，而且报错信息不会告诉你原因。这是新手报错率最高的一条，我在第 6 节会单独展开。
改密码和删用户也很常用：
db.changeUserPassword("app_rw", "New_Str0ng#2025") db.dropUser("app_rw")改完密码后，已有的连接不会立刻失效，这点和某些数据库不同，要留意。
3.3 自定义角色：把权限切到集合级
内置角色的粒度是“库”，遇到更细的需求就得上自定义角色。比如某个服务只需要读orders这一个集合的find操作，其他一概不给：
use appdb db.createRole({ role: "readOrdersOnly", privileges: [ { resource: { db: "appdb", collection: "orders" }, actions: ["find"] } ], roles: [] })privileges里的resource可以是具体的db + collection，也可以是{ db: "appdb", collection: "" }表示整个库，或者{ cluster: true }表示集群级资源。actions是最细的操作粒度，常见的有find、insert、update、remove、createIndex、listCollections等。这里有个坑：只给find是不够的，客户端在查询前往往会先调listCollections或者listIndexes，不给的话行为会显得很怪。我一般的做法是find加上listCollections一起给。
角色建完之后挂到用户上：
db.grantRolesToUser("app_rw", [{ role: "readOrdersOnly", db: "appdb" }])想撤销用db.revokeRolesFromUser()，想查当前用户有啥用db.getUser("app_rw")。自定义角色的一个好处是可复用，同一个角色可以挂到多个用户上，权限调整时改角色就行，不用一个个改用户，这在账号多的环境里能省很多事。
4. 网络与传输层加固：连接从哪来、路上安不安全
4.1bindIp与端口：先把入口收窄
认证解决的是“你是谁”，但一个只监听内网地址的实例，被攻击面本身就小了一大截。bindIp支持多个地址，用逗号分隔：
net: bindIp: 127.0.0.1,10.0.0.21 port: 27017这样本机连得上，内网某台固定机器也连得上，其他来源一律连不进来。这比开0.0.0.0再靠防火墙兜底要稳妥，因为防火墙规则可能被人手一抖改掉，bindIp写在配置文件里更不容易误改。
端口这块，改默认 27017 到别的值能减少被自动化扫描命中的概率，但这属于降低噪音，不属于安全保障，别把它当成主要手段。真正有效的还是认证加网络隔离。如果你的运维流程允许，我建议把端口改成一个高位端口并且写进配置管理，运维侧统一口径，避免不同环境不一致带来的沟通成本。
还有一个容易被忘的点：MongoDB 除了主端口，副本集和分片还会用到额外的通信端口。如果你只放开了 27017，集群模式下的节点间通信会莫名其妙地失败，排查起来很费时间。做实验时通常是单节点，感受不到这个坑，但心里要有数。
4.2 传输加密与keyFile内部认证
数据在网络上传的时候是明文还是密文，由 TLS 决定。MongoDB 的 TLS 配置集中在net.tls段：
net: tls: mode: requireTLS certificateKeyFile: /etc/ssl/mongodb/server.pem CAFile: /etc/ssl/mongodb/ca.pem allowConnectionsWithoutCertificates: falsemode有三个值：disabled、allowTLS、preferTLS、requireTLS，生产环境直接用requireTLS，逼着所有连接都走加密。certificateKeyFile是服务端证书加私钥的合并文件，CAFile是签发证书的根证书。allowConnectionsWithoutCertificates设成false表示强制客户端也带证书，这叫双向 TLS，安全性最高，但客户端配置成本也最高。实验环境里通常只做单向 TLS 就够了。
证书的自签流程大致是：先生成 CA 私钥和自签 CA 证书，再用 CA 给服务端证书签名，最后把服务端证书和私钥合并成一个 pem 文件。整个过程十几条命令，细节容易出错的地方是证书的 CN 或 SAN 必须和客户端连接时用的主机名匹配，不匹配的话会报证书校验失败，而这个报错的字面意思往往看不出是名字对不上。
keyFile是另一个层面的东西，它是副本集成员之间互相认证用的共享密钥文件，不是给客户端用的。生成方式很简单：
openssl rand -base64 756 > /etc/mongodb/keyfile chmod 400 /etc/mongodb/keyfile权限必须是 400 或者 600，宽了mongod会拒绝启动。然后配置里加security.keyFile: /etc/mongodb/keyfile。注意开了keyFile之后，authorization会自动被启用，不需要再单独写，这一点很多人不知道，会重复配置。
4.3 副本集场景下的额外注意点
单机实验很少涉及副本集，但一旦涉及，安全的复杂度是翻倍的。除了上面说的keyFile，还要注意几件事：成员的bindIp必须能让其他成员访问到；每个成员的配置里replSetName必须一致；初始化副本集时用的那个连接必须是已认证的；以及rs.initiate()之后要等状态变成PRIMARY才能建库。
有个很典型的实验场景：三节点副本集，keyFile配好了，但某个节点一直起不来，日志里报 “Bad key file”。原因几乎总是权限不对，或者文件内容被编辑器加了换行。用openssl rand生成的是单行 base64，如果手动拷贝时不小心折行了，解析就失败。我一般的做法是生成后cat一遍确认是单行，再chmod 400。
另外，副本集里创建用户只需要在主节点操作，会自动同步到从节点。但如果主从切换了，你用原来的连接串可能会连到新的主节点，认证信息是一致的，不影响使用，只是要注意应用侧的连接串要写成副本集形式，别写死单节点地址。
5. 一次完整演练：从裸库到带权限的可用环境
5.1 环境准备与配置落地
假设手上是一台干净的环境，目标是搭一个“本地可连、开了认证、有独立业务账号”的实例。第一步先确认mongod的版本和配置文件路径：
mongod --version ls -l /etc/mongod.conf确认之后，把配置文件改成下面这个样子（以手动启动为例）：
systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true storage: dbPath: /var/lib/mongo net: port: 27017 bindIp: 127.0.0.1先不要加security.authorization，先用无认证模式启动，把管理员建出来。启动命令：
mongod --config /etc/mongod.conf --fork--fork让进程后台运行，实验环境里方便。启动后用mongosh连上去，验证一下确实是通的：
mongosh --host 127.0.0.1 --port 27017能进去说明基础配置没问题，接下来才是安全部分。
5.2 建库建用户与连接验证
在无认证状态下，用 localhost exception 建第一个管理员：
use admin db.createUser({ user: "accountAdmin", pwd: "Str0ng_Passw0rd#2024", roles: [{ role: "userAdminAnyDatabase", db: "admin" }] })建完立刻验证一下能不能认证：
db.auth("accountAdmin", "Str0ng_Passw0rd#2024")返回{ ok: 1 }就对了。这时候退出 shell，改配置文件加上security.authorization: enabled，重启：
mongod --config /etc/mongod.conf --shutdown mongod --config /etc/mongod.conf --fork重启后再连，先试一个未认证的操作，确认被拒绝：
mongosh --host 127.0.0.1 --port 27017进去后敲show dbs，如果报 “command listDatabases requires authentication”，说明认证开关生效了。然后带上账号连：
mongosh --host 127.0.0.1 --port 27017 \ -u accountAdmin -p 'Str0ng_Passw0rd#2024' \ --authenticationDatabase admin进去之后建业务库和业务账号：
use appdb db.createUser({ user: "app_rw", pwd: "Another_Str0ng#2024", roles: [{ role: "readWrite", db: "appdb" }] })再单独测业务账号：
mongosh "mongodb://app_rw:Another_Str0ng%232024@127.0.0.1:27017/appdb?authSource=appdb"注意密码里的#在 URI 里要转义成%23，这是个非常常见的坑，很多人复制粘贴后连接失败，排查半天以为是账号问题，其实是 URI 编码没处理。用-p参数传密码就没这个烦恼。
最后做边界验证：用app_rw去读admin库，应该报 “not authorized on admin to execute command”。这一步过了，说明最小权限真的生效了。
5.3 备份恢复与账号交接
安全做完了还得考虑数据怎么搬。带认证的实例做备份，连接串里必须带上认证信息：
mongodump \ --uri="mongodb://backup_user:Backup_Pass%232024@127.0.0.1:27017/?authSource=admin" \ --out=/backup/20240601backup_user应该有backup角色，restore用来恢复。恢复命令同理：
mongorestore \ --uri="mongodb://restore_user:Restore_Pass%232024@127.0.0.1:27017/?authSource=admin" \ /backup/20240601这里有个细节：mongodump默认只导数据不导用户，要导用户得加--dumpDbUsersAndRoles。很多人在迁移时发现用户没了，就是因为漏了这个参数。但反过来说，不带用户导出反而是更安全的做法，账号应该在新环境里重新创建，避免把旧的凭证带过去。
账号交接这件事在实验里体现不出来，但工程上很重要。我一般的做法是给每个账号建一个“归属说明”，写清楚谁申请的、给哪个服务用、什么时候该删。没有这个清单，半年后账号就成了无人认领的僵尸账号，权限还留在那儿，这是审计里最常见的扣分项。
6. 报错实录：认证、权限、连接三类问题的排查路径
6.1 认证类：Authentication failed的六种成因
这条报错是 MongoDB 安全实验里出现频率最高的，但它本身不告诉你是哪儿错了，得按可能性从高到低排查。我整理了一下自己的排查顺序：
| 可能原因 | 判断方法 | 解决方式 |
|---|---|---|
authSource指错了库 | 确认用户建在哪个库 | 连接参数改成用户所在的库 |
| 密码里的特殊字符没转义 | 用-p手动输入试试 | URI 里做百分号编码 |
| 用户根本不存在 | db.getUser("xxx") | 重新创建 |
| 认证机制不匹配 | 检查mechanisms字段 | 补上对应的 SCRAM 凭证 |
| 连到了别的实例 | db.runCommand({ping:1})看版本 | 确认端口和主机 |
| 密码确实错了 | 换管理员账号改一次密码 | db.changeUserPassword |
排在第一位的永远是authSource。原因前面说过，用户信息是跟着库走的，admin库的用户全局可见，业务库的用户只在业务库内有效。连接时不写authSource，驱动默认会去连的那个库找用户，找不到就报认证失败。这个错在新手身上能占到七成。
对应地，我建议在实验里养成一个习惯：建完用户立刻写一条完整的连接串记录在旁边，包括用户名、库、端口。等后面报错时，对照着看，比凭记忆靠谱得多。
6.2 权限类：not authorized的定位方法
认证过了但操作被拒，报错一般是 “not authorized on xxx to execute command yyy”。这条信息其实挺友好，它明确告诉你是哪个库、哪条命令。定位方法就一步：查当前用户的角色。
db.runCommand({ connectionStatus: 1 })这个命令会返回当前连接用的是什么账号、认证在哪个库、拥有哪些角色。看着角色列表，对照第 3 节那张表，就知道缺什么了。缺读给read，缺写给readWrite，缺建索引用dbAdmin。
有一种情况特别隐蔽：用户有两个角色，但一个是read、一个是自定义的find角色，你以为权限叠加了，实际上只要有一个角色覆盖就够，问题是某些命令需要特定角色组合，比如listCollections在某些版本里需要dbAdmin或者显式授予。遇到明明有权限却报错的情况，可以临时用管理员账号执行同一条命令验证一下，确认是权限问题而非命令本身语法问题。
顺带说一句，MongoDB 的权限检查是按命令粒度的，不是按集合粒度。有些命令比如aggregate带$lookup跨集合查询，权限判定会比较复杂，遇到怪问题不要硬猜，去日志里看具体是哪条命令被拒，日志里写得比客户端清楚。
6.3 连接类：连不上的排查顺序
连接被拒的报错通常是ECONNREFUSED，这个反而好排查，因为它说明 TCP 层就没通，跟认证无关。排查顺序固定：先看进程在不在，再看端口通不通，最后看监听地址对不对。
ps -ef | grep mongod ss -lntp | grep 27017如果进程在但端口没监听，看日志，八成是配置文件语法错误或者数据目录权限问题。如果端口在监听但连不上，看bindIp是不是只绑了127.0.0.1而你在从另一台机器连。如果这些都正常还是连不上，考虑防火墙和安全组。
还有一类是“能连上但很快断开”，这通常是 TLS 配置不当导致的握手失败。日志里会有 TLS 相关的报错，关键词是ssl handshake或者certificate。这种情况优先检查证书有效期、CN 是否匹配、CA 是否正确加载。
按这个顺序走，绝大多数连接问题五分钟内能定位。最怕的是一上来就改配置，把原本能用的环境改坏了，问题反而更复杂。
7. 实验做完之后，把这些习惯带出去
一套实验跑完，真正的收获不是那几条命令，而是几个能迁移到任何环境里的习惯。第一个习惯是改配置前先备份、改完先看日志，这个动作在任何数据库、任何中间件上都成立，养成之后能省掉大量“改坏了回不去”的窘境。第二个习惯是先开认证再放开监听，这个顺序一旦颠倒，暴露窗口期就是真实的风险。第三个习惯是账号按用途拆、按最小权限给，宁可多建两个账号，也别图省事给root。
最后分享一个我自己一直在用的小技巧：每配完一套环境，写一份十行以内的“环境说明”，记录版本、端口、配置文件路径、管理员账号所在库、业务账号清单。这份东西在实验里用不上，但在真实运维里，它能让你在半年后重新接手时五分钟内进入状态，也能让同事在你休假时接得住。安全这件事，一半靠配置，一半靠可交接的文档。
