1.3 端口端点与安全基线

1.3 端口端点与安全基线

本节摘要：部署完成后，攻击面也随之而来：Web UI、HTTP API、Agent 网关、监控面板，每一个监听的端口都是一扇门。本节先给端点清单——谁监听在哪、给谁用、该不该对外（默认端口一律以官方文档为准，其中 Agent Gateway 的路径 /api/agent/v1 为官方口径）；再落地五条安全基线：首次登录立刻改默认口令、API key 与 token 权限最小化（交易所 key 只开交易禁提币、平台 token 只读优先）、绝不向公网裸暴露任何服务端口、防火墙与访问控制清单、以及一切真实资金操作前先走测试网。最后预告平台的应急开关体系（文档口径为四重，名称以官方文档为准，第 10、11 章展开），并附一份可复跑的基线自查脚本与常见问题排查。这一节几乎不谈功能，却是全章分量最重的一节。

学习目标

• 列出部署后的主要端点并判断各自的暴露等级。
• 完成首次登录后的口令与密钥整改。
• 给交易所 API key 与平台 token 分别落地最小权限配置。
• 按清单完成防火墙与访问控制收敛。
• 说清「测试网先行」与 paper 长期观察的纪律含义。

一、端点清单与暴露等级

（端口数值随版本可能调整，动手前以官方文档与你的 .env 实际配置为准；表中「绝不对外」两行没有例外。）

自检方法（示意）：在另一台机器上逐端口探测，凡是能从非本机连通的端口，都要能回答「这个暴露是刻意的吗」——答不上来的，收回去。

远程访问的正确与错误路径，一图看全：

一次远程访问的推荐路径（示意）

  你 ──▶ 公网 ──▶ TLS 转发层（认证 + 白名单） ──▶ 内网 ──▶ Web UI / API
                        │
                        └──▶ 不放行任何直连：数据库、队列、面板一律绕行转发层

  反模式：你 ──▶ 公网 ──▶ 宿主机端口映射 ──▶ Web UI（无 TLS、无白名单、无审计）
​

两条路径差的不只是「安全性」三个字：转发层是唯一入口，意味着认证、限速、审计都有统一的落点；端口直连则把每一项责任都摊给每个服务自己——多数服务并不擅长这件事。

二、基线一：首次登录改密

部署完成后的第一件事，是把所有默认口令清零：Web UI 初始管理员口令、.env 里的数据库口令、Redis 口令、Grafana 口令。原则：口令只出现在两个地方——密码管理器和 .env 文件；不出现在聊天记录、笔记截图和代码仓库里。改完后把 .env 的读取权限收紧到运行用户（示意：chmod 600 .env）。

三、基线二：API key 与 token 最小权限

系统里有两类凭据，最小权限的落法不同：

平台侧的作用域 token 机制（官方口径）为分级权限提供了载体，Agent 网关的接入细节在第 10 章展开；交易所侧的权限裁剪从接入第一天就要做，不要等到实盘前夜。经验法则：权限的默认值是只读，每多开一项都单独问一次「不开会怎样」。

权限与审批的原理层，推荐延伸《Harness 工程：从零打造智能体运行环境》第 05 章《权限与审批门》——同样的最小权限思想，在交易系统里对应的筹码是真金白银。

四、基线三与四：不裸暴露，收敛防火墙

不向公网裸暴露：需要远程访问时，走内网穿透或带 TLS 的转发层（如 nginx 做 TLS 终结），并叠加认证与来源白名单；「用端口映射直接把 Web UI 甩到公网」是绝对反模式——交易系统的一个会话劫持等于资金操作权旁落。

防火墙与访问控制清单（自检打勾式）：

把清单变成可复跑的脚本（示意实现，输出待办而不是替你打勾）：

# baseline_check.py —— 安全基线八项自查（纯标准库，输出待办清单）
CHECKS = [
    ("默认口令清零", ["Web UI 管理员", "PostgreSQL", "Redis", "Grafana"]),
    ("数据库与队列不出内网", ["非本机端口探测", "端口映射复查"]),
    ("远程访问走 TLS 转发层", ["转发层配置", "证书有效期"]),
    ("来源白名单", ["放行清单成文"]),
    ("交易所 key 权限裁剪", ["禁提币", "测试网先行"]),
    ("平台 token 分级", ["只读默认", "按用途发放"]),
    (".env 权限收紧", ["仅运行用户可读"]),
    ("监控面板同样设防", ["Grafana 改密", "不裸暴露"]),
]

def audit(done_flags):
    # done_flags: 与 CHECKS 等长的布尔列表，True 表示该项已完成
    pending = [f"[ ] {item}（子项：{'、'.join(subs)}）"
               for (item, subs), done in zip(CHECKS, done_flags) if not done]
    return pending or ["基线达标：转入定期复检周期"]

if __name__ == "__main__":
    for line in audit([True, True, False, False, True, True, True, False]):
        print(line)        # 示意：输出三项待办，对应尚未完成的基线项
​

脚本的价值在于「复跑」：每次系统变更（加服务、改配置、换机器）之后重跑一遍，待办清单为空才算变更完成——安全基线的本质是复检制度，不是一次性作业。

五、基线五：测试网先行与 paper 纪律

涉及真实交易所的一切操作，顺序永远是：测试网（交易所提供的模拟环境）──▶ paper（平台 signal-only 虚拟账户）──▶ 极小资金的观察期 ──▶ 再谈常规规模。前三步 respectively 验证的是：接入正确性、策略行为一致性、执行链路完整性。跳步的代价不是「慢」，是把本可在第 0 步发现的配置错误，用真金白银在第 3 步复现。

配套的应急手段：平台提供多重应急开关用于紧急停机与切断（文档口径为四重，具体名称与触发方式以官方文档为准），第 10 章讲 Agent 场景下的使用、第 11 章讲运维场景下的演练。部署完成后，建议立刻确认一次「我知不知道怎么一键停」——知不知道按钮在哪，比有没有按钮更重要。

六、常见问题与排查

本节要点回顾

• 端点五类：Web UI/API、Agent 网关、数据库、队列、监控；后三类绝不对外。
• 五条基线：改密、key 最小权限（禁提币、测试网先行）、不裸暴露、防火墙清单、测试网与 paper 纪律。
• 交易所 key 与平台 token 是两类凭据，裁剪方式不同，默认值都是只读。
• 应急开关文档口径为四重；部署后先确认「一键停」在哪里。
• 安全基线不是一次性动作，是每次变更后的复检项。
• 基线八项可脚本化复跑：变更后待办清零，才算变更完成。

部署与安全基线就绪，你现在拥有一套「健康但陌生」的系统。第 2 章拆开它的 v5 架构：六个进程各自的边界、为什么 HTTP API 不拥有长循环、以及一次下单在进程之间的完整旅行。