第三节 密码改造环境准备：系统、依赖、网络与权限
环境准备这事，说复杂也复杂，说简单也简单。我见过不少项目，改造方案写得漂漂亮亮，结果一到现场，操作系统版本不对、依赖库缺胳膊少腿、防火墙把通信端口全堵死了——得，全得从头折腾。
所以这节，咱们把环境准备的四个核心维度掰开揉碎聊清楚。说白了，就是告诉你：机房那台机器上到底要装什么、配什么、开什么、放什么。
3.1 操作系统选型与基线检查
操作系统是地基。地基歪了，上面再怎么加固也没用。我个人习惯在动手前，先明确两个事情：生产环境用的是什么发行版？内核版本是否满足密码模块的要求？
我曾经碰到过一个项目，客户提供的服务器装的是 CentOS 6，而 SM2/SM3/SM4 的底层库（比如 GmSSL）已经不再支持这个老旧内核。折腾了两天才发现是内核太老，连 AES-NI 指令集都跑不全。最后不得不花时间做系统迁移。
| 操作系统 | 推荐版本 | 内核要求 | 备注 |
|---|---|---|---|
| CentOS / RHEL | 7.9+ / 8.4+ | 3.10.0-1160+ | 7 版即将 EOL，建议迁移到 8/9 |
| Ubuntu | 20.04 LTS / 22.04 LTS | 5.4+ | 推荐 22.04，软件源更新 |
| openEuler | 22.03 LTS SP2 | 5.10+ | 信创环境首选 |
| KylinOS | V10 SP1 | 4.19+ | 军工、政务网常见 |
嗯，这里要注意：别只看大版本号。我建议至少做以下三项基线检查：
- glibc 版本：2.17 以上（ldd --version 查看）
- OpenSSL 版本：如果是自编译密码库，OpenSSL 1.1.1 或 3.0+ 更稳妥
- 内核模块支持：lsmod | grep crypt 看看有没有 crypto 相关模块
# 快速检查脚本（我自己的小工具）
cat /etc/os-release
uname -r
ldd --version | head -1
openssl version
lsmod | grep crypto3.2 依赖库安装与版本锁定
密码改造最头疼的事之一，就是依赖库冲突。你想想看，业务系统用 OpenSSL 1.0.2，密码模块要求 OpenSSL 1.1.1，两个库装在同一台机器上，环境变量一乱，编译时就报 undefined symbol。
我推荐的做法是：用独立目录安装密码库，不污染系统默认路径。 说白了，就是把 GmSSL、libp11、SoftHSM 这些库，编译到 /opt/crypto/lib 下，然后通过 LD_LIBRARY_PATH 控制加载顺序。
- GmSSL（国密算法库） >= 3.1.0
- OpenSSL（兼容层） >= 1.1.1
- libp11（PKCS#11 接口） >= 0.4.12
- SoftHSM（软件 HSM 模拟器） >= 2.6.1
- pkg-config（编译时自动查找库路径）
# 我的标准安装流程（以 GmSSL 为例）
tar -zxf GmSSL-3.1.0.tar.gz
cd GmSSL-3.1.0
mkdir -p /opt/crypto/gmssl
./config --prefix=/opt/crypto/gmssl
make -j$(nproc)
make install
# 设置环境变量
export PATH=/opt/crypto/gmssl/bin:$PATH
export LD_LIBRARY_PATH=/opt/crypto/gmssl/lib:$LD_LIBRARY_PATH千万别一股脑把密码模块扔进 /usr/lib64。我见过一次生产事故，就是系统升级时 yum 自动覆盖了 OpenSSL，导致密码服务启动失败。用独立路径，回滚也方便，只需要改一下环境变量就行。
3.3 网络环境梳理与端口规划
密码改造往往不是单机操作。前端业务服务器、密钥管理服务器、HSM 设备、数据库——它们之间不是 HTTP 就是国密 TLS。网络不通，一切白搭。
为什么我每次做环境准备了先画网络拓扑？因为防火墙策略申请太慢了。一次申请好几个端口，等审批就得一两天，你想想看，提前梳理清楚能省多少事。
端口规划这块，我的经验是遵循最小必要原则。别图省事全开，也别为了安全啥都不开。下面是常见端口清单：
| 方向 | 端口 | 协议 | 用途 | 安全建议 |
|---|---|---|---|---|
| 应用 ↔ 密码服务 | 8443 / 9443 | HTTPS / GM-TLS | 国密签名、验签、加密、解密 | 双向证书认证 |
| 密码服务 ↔ HSM | 2345 | TCP（专有协议） | PKCS#11 接口调用 | 仅限本机或内网 VLAN |
| 密码服务 ↔ 数据库 | 3306 / 5432 | TCP | 密钥存储、审计日志 | 加密通道，账户最小权限 |
| 运维管理 | 22 / 3389 | SSH / RDP | 服务器管理 | 堡垒机跳板 + 密钥登录 |
| 监控探针 | 9100 | HTTP | Prometheus 指标采集 | 内网访问，不暴露公网 |
我习惯在部署前先跑一遍端口连通性测试，不用专门写脚本，一个 netcat 就行：
nc -zv 10.0.1.100 8443
# 如果返回 "succeeded!" 说明端口通了3.4 权限要求与账号最小化原则
权限这东西，太紧容易误事，太松容易出事。我见过有项目直接给 root 跑密码服务——万一被入侵，整个密钥库就全丢了。正确做法是：建一个专门的服务账号，只给它需要的权限。
举个例子，我用 cryptoapp 这个用户来运行密码模块。它的家目录就是 /opt/crypto，里面放着二进制、配置、密钥文件。那它需要哪些权限呢？
- 读权限：/opt/crypto/lib 下的所有动态库
- 写权限：/var/crypto/log 日志目录
- 执行权限：/opt/crypto/bin 下的可执行文件
- 设备权限：如果需要调用硬件 HSM，需要加入 hsm 用户组
- 文件系统权限：/opt/crypto 目录属主为 cryptoapp，权限 750
- 进程权限：密码服务不以 root 启动，监听端口 1024 以上（比如 8443）
- sudo 权限：禁止密码服务账号有 sudo 权限
- SELinux / AppArmor 策略：如果系统开启，需要配置允许密码模块访问特定端口和硬件
- 审计权限：密码服务进程能写 /var/log/crypto，但不能删其他日志
有一次部署密码网关，忘记检查 SELinux 策略。结果服务启动后，bind 端口 8443 一直在报 Permission denied。折腾了半天，才在 /var/log/audit/audit.log 里发现是 SELinux 禁止 httpd_t 类型进程监听非标准端口。后来加了一条策略规则才解决。所以——排查问题时别忘了看 audit 日志。
3.5 环境验证清单（部署前必过）
好了，上面说了操作系统、依赖库、网络、权限四个维度。那到底怎么验证环境是不是准备好了？我习惯用一个五步检查法，每步都落地成脚本或命令：
| 步骤 | 检查项 | 命令 / 方法 | 预期结果 |
|---|---|---|---|
| 1 | 操作系统基线 | uname -r && cat /etc/os-release | 内核 ≥ 3.10，发行版符合要求 |
| 2 | 依赖库完整性 | ldconfig -p | grep gmssl | 出现 libgmssl.so |
| 3 | 端口连通性 | ss -tlnp | grep 8443 | 密码服务监听在 8443 |
| 4 | 权限隔离性 | ps aux | grep crypto | 进程属主为 cryptoapp，非 root |
| 5 | 国密功能测试 | gmssl sm2keygen -out key.pem | 生成 SM2 密钥对无报错 |
嗯，这五步跑通了，环境就算基本就绪了。你想想看，与其在部署时被各种环境问题卡住，不如提前把坑填平。毕竟——密码改造的核心是"改造"，不是"调试环境"。