5.3 安全性：认证、授权与 TLS

5.3 安全性：认证、授权与 TLS

本节摘要：消息系统的安全由三层防线构成：认证确认"你是谁"，授权决定"你能动什么"，传输加密保证"路上没人能看"。本节按层给出加固清单，复盘一次内网明文被嗅探的真实事故，并纠正"内网不需要加密"的侥幸心理。

整理进行到安全层。此前章节为了演示方便，连接字符串里用户名密码全用默认账户、明文传输——生产化整理要把这些"演示债"一次还清。

三层防线逐层落地

第一层，认证。目标：让每个连接可实名、可追踪、可吊销。落地清单四条：删除或禁用默认来宾账户（4.1 节的核对项在此闭环）；按应用实名建账户，一应用一账户；密码进密钥管理系统而非配置文件明文；启用登录失败限制，堵暴力猜解。做了这四条，4.2 节连接列表里的每个连接都能指认到具体应用——安全与可观测在这里是同一件事。

第二层，授权。目标：最小权限。RabbitMQ 的权限模型是"vhost 加三段正则"（配置、写、读），4.2 节已经演示过。本节补上规模化时的两条纪律：权限随资源命名规范走——第 2 章的命名纪律让正则可以写得很精确（如 orders\..*），命名混乱的系统权限必然只能写成 .*，这等于没有授权；定期审计——用命令导出全部权限快照，比对预期矩阵：

rabbitmqctl list_permissions -p /orders
# 预期输出：
# orders_svc	.*	.*	.*
# monitor_ro	^$	^$	.*

rabbitmqctl list_user_permissions orders_svc
# 预期输出：
# /orders	.*	.*	.*
​

输出里出现意料之外的用户或过宽的正则，就是审计发现。审计还有一层常被忽略的对象：管理操作的留痕。rabbitmqctl 的每次用户与权限变更、管理界面上的资源改动，都应进入集中日志——"上季度谁把只读账号的权限放大了"这类问题，没有留痕就永远悬案。第三层，传输加密。TLS 给连接套上加密与身份校验，防嗅探防中间人。启用需要证书三件套（CA 证书、服务端证书、私钥）与监听配置：

listeners.ssl.default = 5671
ssl_options.cacertfile = /certs/ca.pem
ssl_options.certfile   = /certs/server.pem
ssl_options.keyfile    = /certs/server.key
ssl_options.verify     = verify_peer
ssl_options.fail_if_no_peer_cert = true
​

verify_peer 加 fail_if_no_peer_cert 的组合启用双向认证：客户端也要出示证书。内部系统推荐双向认证——客户端身份由证书保证，密码认证退居二线。客户端侧相应地用证书与 CA 参数连接，验证环节见下文演练。

完整演练：一次内网嗅探事故的复盘与修复

背景：某公司安全部门例行渗透测试，在办公网段抓到了 RabbitMQ 的明文流量——队列名、消息体里的用户手机号一览无余。业务团队的辩护是经典句式："都在内网，加什么密。"渗透报告的回复更经典：攻击者一旦进入内网（占比最高的真实入侵路径），明文流量就是自助餐厅。

操作：整改分三步。第一步，服务端启用 TLS 监听（配置如上），证书由公司 CA 签发。第二步，客户端改用加密端口与证书：

import pika, ssl

ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ssl_context.load_verify_locations("ca.pem")        # 校验服务端证书链
ssl_context.load_cert_chain("client.pem", "client.key")  # 出示客户端证书

connection = pika.BlockingConnection(
    pika.ConnectionParameters(
        host="mq.internal", port=5671,
        ssl_options=pika.SSLOptions(ssl_context)))
channel = connection.channel()
print("TLS 连接建立，密码学身份确认完成")
​

第三步，收口：关闭 5672 明文监听，所有客户端迁移到 5671——只加新端口不关旧端口，加密等于没做。

结果：渗透复测抓不到明文流量，连接身份全部可核验。解读：这次整改最大的收获是认清一个事实：加密改的是连接层，代码几乎零改动——所谓"上 TLS 成本高"，绝大多数成本在证书管理与客户端灰度发布，一次性的工程活。迁移期用双端口并行的灰度策略，两周可以完成全量切换。

变式一：验证中间人拦截——客户端不装 CA 直接连，握手失败并报证书校验错误，说明 verify_peer 在真的工作。变式二：管理界面同样要走 HTTPS，管理插件支持 TLS 配置，别把 5672 关了却给 15672 留着明文后门。

三层防线的纵深关系，一张图收拢：

图 14 安全纵深：三层防线各挡什么

这张图的排布刻意从外到内：先在网络层挡掉大多数攻击者，再在身份层确认来者是谁，最后在权限层限定它能碰什么。评审存储系统的安全设计时，按这三行逐层问"这一关挡住了什么、失守后下一关怎么兜"，比逐个检查配置项更能暴露结构性缺口。

安全清单总表

把三层防线收成一张可勾选的表，评审时逐行过：

⚠️ 常见坑：把安全寄托在"端口没暴露"上。端口扫描只是最浅的探测，服务发现机制、配置中心泄露、内网横向移动都能摸到端口。纵深防御的意义就在于此：端口、认证、授权、加密，一层失守还有下一层。

本节要点回顾

• 三层防线：认证认身份、授权限边界、TLS 护传输，层层独立设防；
• 实名账户：一应用一账户是可观测与可吊销的共同前提；
• 权限两纪律：命名规范撑起精确正则，定期审计兜住配置漂移；
• TLS 低估错觉：代码近乎零改动，成本集中在证书管理与灰度；
• 纵深防御：单层失守不是灾难，只有全裸才是。

门关好了。下一节上发动机：性能优化的方法论、参数清单与两个真实调优案例。