3. 密钥存储安全审计：文件系统、数据库、硬件安全模块

密钥存储是密码体系的地基。地基没打好，上面的加密、签名、认证全是虚的。我这些年做过的审计项目里，密钥存储出问题的比例真不低——有些甚至算不上漏洞，就是赤裸裸的“把钥匙挂在大门上”。

咱们这一节拆成三种典型场景来讲：文件系统、数据库、硬件安全模块（HSM）。每一种的威胁模型和安全要求都不一样，审计手段也必须跟着变。

3.1 文件系统存储审计

文件系统是最常见也最容易出问题的密钥存放方式。很多开发团队图省事，直接把私钥或对称密钥写在配置文件里，甚至塞到 Git 仓库。

举个例子，我审计过一个支付网关项目。运维人员把 RSA 私钥放在/etc/ssl/private/下，权限设成了644。我问他们为什么这么做？回答是“方便备份脚本读取”。你看，为了方便备份，把整个系统的加密信任根暴露给了所有进程。

# 审计检查命令示例
find / -name "*.key" -o -name "*.pem" -o -name "id_rsa" 2>/dev/null | while read f; do
    ls -la "$f"
    # 检查是否使用了加密的密钥格式（PKCS#8 可加密）
    openssl pkey -in "$f" -check -noout 2>&1 | grep -E "(unable|error)" && echo "⚠ 密钥文件有异常"
done

3.2 数据库存储审计

把密钥存在数据库里，这本身不一定是坏事。关键在于你怎么存、谁可以读、表结构是否做了隔离。

我见过两种典型错误：

1. 明文存储——直接一个VARCHAR(4096)字段，放的是 PEM 格式私钥。任何能 SELECT 这张表的人就等于拿到了密钥。
2. 硬编码加密密钥——虽然存的是密文，但解密密钥写在应用程序的配置里或者环境变量里。这种“用一个密钥保护另一个密钥”的做法，如果加密密钥本身保护不好，那层加密就是心理安慰。

我建议的做法是：密钥表单独建一个 schema（比如security.key_store），仅允许一个专用的存储过程 get_key_by_alias 去访问。应用程序只能调用这个函数，不能直接 SELECT 表。这样可以利用数据库的存储过程权限机制再做一层隔离。

3.3 硬件安全模块（HSM）审计

HSM 是三种方案里最安全的——前提是你配置对了。HSM 最大的坑在于“管理口和安全口没有严格隔离”。说白了，HSM 本身有管理功能（初始化、备份、密钥导入导出），如果这些管理端口暴露在应用网段或者互联网上，攻击者可以直接远程操作 HSM。

我记得有一次审计一家金融公司，他们用了某品牌的 HSM 作为根证书签名密钥的存储。我检查网络拓扑时发现，HSM 的管理网口连接在了一个交换机上，而且该交换机同时接了运维人员的办公网。问他们为什么这样设计？回答是“调试方便”。最后我建议他们至少做 VLAN 隔离，并且给管理端口绑定白名单 IP。

审计 HSM 时我重点看四个点：

1. 网络隔离：管理口只允许从专用管理终端访问，应用口只允许加密操作（签名、解密），不能同时开放。
2. 密钥导出策略：确认 HSM 的密钥政策是否允许exportable。如果允许，必须有备份密钥的双重认证流程。
3. HA 配置：两台 HSM 做集群时，密钥如何同步？是否使用了安全通道？我曾经看到一台主 HSM 挂掉后，备用 HSM 因为同步策略设置不当，竟然用了未加密的网络复制密钥。
4. 物理安全：HSM 的机柜锁了吗？机柜监控摄像头覆盖了吗？我见过 HSM 直接放在敞开式机架上的——有人插个 USB 就能做本地备份。

3.4 三种存储方式的审计优先级

嗯，这里做一个快速对比，方便你在不同场景下分配审计精力。