人大金仓 K8s 密评合规加固｜国密全链路加密 + 权限收敛容器化落地（三级密评直通版）

摘要

政务信创商用密码应用安全性评估（密评）是硬门槛，人大金仓迁到 K8s 后更是高频踩坑重灾区：密钥明文塞 Secret、数据库传输裸奔、存储不加密、权限一锅粥、审计日志可篡改，很多团队整改两三次都过不了，还容易踩「容器化场景密评要求更严」的隐形雷区。

本文基于政务三级密评实测通过的落地方案，严格对标 GM/T 0054-2018 信息系统密码应用基本要求 三级标准，从 K8s 平台层、数据库层、密钥全生命周期管理三层深度拆解，覆盖国密身份认证、SM4 透明存储加密、国密 SSL 传输加密、SM3 完整性校验、三权分立权限收敛、防篡改审计全链路，附所有可直接复制的 SQL 与 YAML 配置模板，照着做一次性通过密评。

政务选金仓，金融选达梦；MySQL 迁移选金仓，Oracle 迁移选达梦。全文无空泛理论，所有配置均经过密评机构现场验证，生产合规可用。

一、先搞懂：容器化人大金仓密评三级到底查什么

📌 核心结论：容器化不是法外之地，密评三级只会比物理机要求更严。数据库作为核心数据载体，是密码应用的重中之重，身份鉴别、传输加密、存储加密、密钥管理、安全审计五项是一票否决项。

1.1 容器化场景的额外密评风险

相比物理机部署，K8s 场景多了三类合规硬伤，也是最容易被测评机构卡的点：

边界模糊，密钥易泄露：容器共享内核、配置易扩散，密钥明文写在 ConfigMap/Secret 里，等于全员可见
生命周期短，审计易断档：Pod 重建后日志丢失，审计追溯不连续，不符合不可篡改要求
默认权限过大：默认 root 运行、默认 ServiceAccount 权限过高、网络无隔离，不符合最小权限原则

1.2 密评三级五大必查核心项

身份鉴别：基于国密算法的身份认证，禁止弱口令，支持双因素认证
传输机密性：全链路国密加密，重要数据传输过程不裸奔
存储机密性：敏感数据落盘加密，采用 SM4 等国密算法
数据完整性：重要数据、审计日志具备完整性校验能力，防篡改
密钥管理：密钥全生命周期可管可控，密钥与数据分离，符合 GM/T 0054 密钥管理要求

二、密评控制点全景映射表（测评对照用）

严格对标 GM/T 0054-2018 三级要求，逐项对应落地措施，测评时直接对照查。

密评三级控制点	K8s 平台层落地措施	人大金仓数据库层落地措施	测评权重
身份鉴别	RBAC 最小权限、ServiceAccount 身份绑定、禁止匿名访问	SM2 国密身份认证、三权分立账号、口令复杂度策略、登录失败锁定	⭐⭐⭐⭐⭐
传输机密性	TLS 国密网关、NetworkPolicy 微隔离、Service 加密访问	国密 SSL 通信、SM4 应用层消息加密、敏感字段传输加密	⭐⭐⭐⭐⭐
存储机密性	存储卷加密、Secret 加密存储、镜像加密	SM4 透明数据加密 (TDE)、敏感列级加密、备份数据加密	⭐⭐⭐⭐⭐
数据完整性	配置文件完整性校验、镜像签名	审计日志 SM3 签名、重要数据摘要校验、备份完整性校验	⭐⭐⭐⭐
密钥管理	对接国密 KMS、密钥不落地、禁止明文存储	密钥与数据分离、对接外部密钥管理系统、密钥定期轮换	⭐⭐⭐⭐⭐
安全审计	K8s 审计日志开启、集中留存 180 天	全操作审计、审计日志国密签名防篡改、独立存储留存	⭐⭐⭐⭐⭐
访问控制	NetworkPolicy 网络微隔离、SecurityContext 权限收敛	角色权限分离、列级访问控制、高危操作限制	⭐⭐⭐⭐

💡 密评高分技巧：以上控制点全部落地，补充密钥管理制度、应急方案、定期密码安全评估，基本可以稳过三级。其中密钥管理、审计防篡改、三权分立是最容易丢分的项，必须做扎实。

三、第一层：K8s 平台层密评加固（底座合规）

平台层是密评的底座，这层不合规，数据库层再加固也没用。

3.1 身份与权限：最小权限原则

数据库专用 ServiceAccount：禁止使用默认 ServiceAccount，单独创建权限最小的专用账号，关闭自动挂载 token，防止容器内越权访问 API Server。

yaml

复制代码

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kingbase-sa
  namespace: kingbase
automountServiceAccountToken: false  # 禁止自动挂载API Token

RBAC 权限收敛：仅授予数据库运维必要的最小权限，禁止集群管理员权限绑定业务账号。

3.2 网络层：微隔离 + 传输加密

NetworkPolicy 强制访问控制：默认拒绝所有入站，仅白名单放通，防止横向渗透。

yaml

复制代码

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kingbase-miping-policy
  namespace: kingbase
spec:
  podSelector:
    matchLabels:
      app: kingbase
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: business-app
    ports:
    - protocol: TCP
      port: 54321
  egress:
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

传输链路加密：应用到数据库之间走国密 SSL，跨节点流量通过国密加密网关封装，禁止明文跨节点传输。

3.3 密钥存储：告别明文 Secret

K8s 原生 Secret 只是 Base64 编码，不属于加密存储，密评不认可。必须二选一：

方案一（推荐）：对接国密密钥管理系统（KMS），数据库密钥统一由 KMS 管理，容器运行时动态拉取，密钥不落地
方案二（轻量）：使用 SealedSecret 等加密工具，Secret 落盘为密文，仅集群内解密使用

⚠️ 密评红线：绝对不能把数据库加密密钥、管理员密码明文写在 YAML、ConfigMap 里，Base64 编码不算加密。

3.4 运行时安全：收敛系统权限

数据库容器必须非 root 运行，丢弃所有多余能力，符合最小权限原则：

yaml

复制代码

securityContext:
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL
  seccompProfile:
    type: RuntimeDefault

3.5 镜像与部署合规

镜像必须经过漏洞扫描，高危漏洞清零
生产镜像必须签名验证，只允许运行经过签名的可信镜像
配置变更必须走审批流程，所有操作留痕可审计

四、第二层：人大金仓数据库层国密全链路加固

人大金仓 V9 企业版原生支持国密算法体系，完整覆盖 SM2/SM3/SM4，核心做好身份、传输、存储、完整性四件事。

4.1 身份鉴别：国密认证 + 三权分立

1. 三权分立账号体系（密评必查）

系统管理员、安全管理员、审计管理员三权分离，相互独立、相互制约。

sql

复制代码

-- 系统管理员（默认system）：负责数据库运行维护、对象管理
-- 安全管理员sso：负责权限管理、安全策略、加密配置
CREATE USER sso WITH CREATEROLE PASSWORD '符合复杂度的强口令';
-- 审计管理员auditor：负责审计规则配置、审计日志管理
CREATE USER auditor WITH LOGIN PASSWORD '符合复杂度的强口令';
GRANT ALL ON SCHEMA sysaudit TO auditor;

2. 国密 SM2 身份认证

支持基于 SM2 证书的身份认证，替代传统口令认证，满足密评强身份鉴别要求：

ini

复制代码

# kingbase.conf 追加配置
ssl = on
ssl_cert_file = 'server_sm2.crt'
ssl_key_file = 'server_sm2.key'
ssl_ca_file = 'root_sm2.crt'
ssl_ciphers = 'SM2-SM3-SM4'  # 国密算法套件

客户端使用 SM2 客户端证书连接数据库，实现双向国密身份认证。

3. 口令安全策略

sql

复制代码

-- 口令最小长度12位
ALTER SYSTEM SET password_min_length = 12;
-- 口令复杂度：大小写+数字+特殊字符三类以上
ALTER SYSTEM SET password_policy = 'medium';
-- 口令有效期90天
ALTER SYSTEM SET password_valid_days = 90;
-- 连续5次失败锁定30分钟
ALTER SYSTEM SET password_max_fail = 5;
ALTER SYSTEM SET password_lock_time = 30;

4.2 传输加密：全链路国密 SSL

数据库服务端开启国密 SSL，所有客户端连接强制走加密通道，内网抓包也看不到明文数据。

ini

复制代码

# kingbase.conf 完整传输加密配置
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_ca_file = 'root.crt'
ssl_ciphers = 'SM2-SM3-SM4'  # 强制国密套件
ssl_min_protocol_version = 'TLSv1.2'

客户端 JDBC 连接串追加ssl=true参数，强制加密连接，禁止明文访问。

4.3 存储加密：SM4 透明数据加密（TDE）

敏感数据落盘必须加密，防止硬盘物理泄露导致数据失密。人大金仓支持表空间级 SM4 透明加密，业务零改造。

1. 创建加密表空间

sql

复制代码

-- 由安全管理员操作，创建SM4加密表空间
CREATE TABLESPACE encrypt_ts
LOCATION '/opt/kingbase/data/encrypt_ts'
WITH (ENCRYPTION = SM4, KEY_ID = '密钥标识');

2. 敏感表创建到加密表空间

sql

复制代码

-- 敏感业务表建在加密表空间，落盘自动SM4加密
CREATE TABLE user_info (
  id INT PRIMARY KEY,
  id_card VARCHAR(18),
  phone VARCHAR(11),
  name VARCHAR(50)
) TABLESPACE encrypt_ts;

✅ 优势：透明加密，业务代码完全无需修改，数据写入自动加密、读取自动解密，性能损耗 < 5%。

3. 列级加密补充

极高敏感字段（身份证、手机号）可再叠加列级加密，双重防护：

sql

复制代码

-- 敏感字段SM4加密存储
CREATE TABLE user_sensitive (
  id INT PRIMARY KEY,
  id_card_enc BYTEA  -- 加密存储的身份证号
);

4.4 数据完整性：SM3 摘要校验

对重要业务数据、配置文件计算 SM3 摘要，防止被篡改：

sql

复制代码

-- 计算数据SM3摘要，用于完整性校验
SELECT sm3(敏感字段) FROM 重要表;

审计日志、备份文件必须附带 SM3 摘要，验证时比对摘要一致即可确认数据完整未篡改。

五、核心硬骨头：密钥全生命周期管理方案

密钥管理是密评三级的核心扣分点，也是最容易做不好的地方。必须严格遵循密钥与数据分离、专人管控、全生命周期可审计原则。

5.1 密钥管理三级架构

主密钥：存储在国密密码机 / KMS 中，用于加密工作密钥，永不落地
工作密钥：由主密钥加密保护，用于实际数据加密，可定期轮换
数据密钥：针对表、列的具体加密密钥，由工作密钥加密存储

5.2 全生命周期管控要求

生命周期阶段	密评三级要求	落地方式
密钥生成	真随机数生成，符合 GM/T 0005	国密 KMS / 密码机生成，禁止软件伪随机生成
密钥分发	加密传输，身份认证	SM2 加密分发，双人复核
密钥存储	硬件存储，不落地明文	KMS / 密码机硬件存储，数据库只存密钥密文
密钥使用	权限控制，操作审计	仅授权账号可调用加密接口，全操作审计
密钥更新	定期 + 事件触发轮换	每季度自动轮换，泄露时立即更换
密钥归档	加密归档，可追溯	历史密钥加密归档，双人授权访问
密钥销毁	安全销毁，不可恢复	KMS 安全销毁，所有副本同步销毁

5.3 K8s 场景适配方案

数据库启动时通过 Sidecar 从 KMS 动态拉取密钥，注入内存，不写入磁盘
Pod 销毁时自动清除内存中的密钥，不留痕迹
密钥轮换由 KMS 统一调度，数据库端热加载，无需重启实例

⚠️ 密评否决项：密钥明文存储在数据库本地、配置文件、镜像中，直接不通过。

六、审计合规：国密签名防篡改审计体系

审计日志是密评必查项，要求可追溯、不可篡改、留存 180 天以上。

6.1 审计范围全覆盖

开启全量审计，覆盖登录登出、DDL、DML、权限变更、加密操作所有关键行为：

ini

复制代码

# kingbase.conf 审计配置
sysaudit.log = on
sysaudit.log_connections = on
sysaudit.log_disconnections = on
sysaudit.log_ddl = on
sysaudit.log_dml = on
sysaudit.log_delete = on
sysaudit.log_failed_statements = on

6.2 审计日志防篡改（密评加分项）

审计日志必须具备防篡改能力，方案：

SM3 数字签名：每一条审计日志生成 SM3 摘要，日志文件整体签名，篡改即可识别
只追加不修改：审计日志文件只允许追加写入，禁止修改、删除
独立存储：审计日志独立 PVC 挂载，与数据目录分离，同步到集中日志平台双份留存
留存周期：本地留存 180 天，日志平台留存 1 年以上，满足密评追溯要求

6.3 K8s 场景审计连续性保障

审计日志独立 PVC 持久化，Pod 重建不丢失
Sidecar 实时同步到集中审计平台，单节点故障不丢日志
审计日志禁止普通账号访问，仅审计管理员可查看

七、权限深度收敛：从平台到数据库全链路最小权限

7.1 数据库端权限收敛

业务账号最小权限：仅授予必要的表增删改查权限，禁止 DBA、superuser 权限跑业务
敏感表列级权限：身份证、手机号等敏感字段，仅授权特定账号可访问
高危操作管控：DROP TABLE、TRUNCATE、ALTER SYSTEM 等高危操作，仅系统管理员可执行
IP 白名单限制：管理员账号仅允许从运维网段登录，禁止公网访问

7.2 K8s 端权限收敛

数据库 Pod 禁止挂载宿主机敏感目录
禁止特权容器、禁止权限提升
运维操作必须通过堡垒机，禁止直接 kubectl exec 进容器
所有配置变更走 GitOps 流程，留痕可审计

八、避坑红线：9 个密评常见致命错误

⚠️ 红线 1：用 Base64 编码的 Secret 存密钥，当加密用

后果：密评直接不通过，Base64 是编码不是加密，等于明文存储
整改：对接国密 KMS，密钥硬件存储，不落地明文

⚠️ 红线 2：只做存储加密，不做传输加密

后果：传输过程明文裸奔，不符合传输机密性要求
整改：全链路国密 SSL，传输、存储双加密

⚠️ 红线 3：三权分立形同虚设，一个账号走天下

后果：权限分离项直接丢分，不符合身份鉴别要求
整改：三个管理员账号独立设置，权限严格隔离，各管各的

⚠️ 红线 4：审计日志存在容器里，重启就丢

后果：审计追溯断档，不符合安全审计要求
整改：审计日志独立 PVC 持久化，集中留存 180 天以上

⚠️ 红线 5：用 AES、RSA 等非国密算法凑数

后果：密评要求使用国密算法，非国密算法不算有效密码应用
整改：全部替换为 SM2/SM3/SM4 国密算法体系

⚠️ 红线 6：密钥自己生成存在数据库里

后果：密钥管理不符合要求，数据与密钥同存等于没加密
整改：密钥与数据分离，由独立 KMS / 密码机统一管理

⚠️ 红线 7：审计日志可修改、可删除

后果：不符合审计数据完整性、不可篡改要求
整改：开启写保护、数字签名，只追加不修改删除

⚠️ 红线 8：密钥从不轮换，一套用到底

后果：不符合密钥生命周期管理要求
整改：建立密钥轮换机制，定期轮换，泄露时立即更换

⚠️ 红线 9：只做技术加固，没有管理制度

后果：密评不仅查技术，还要查管理，制度缺失同样不通过
整改：配套密码安全管理制度、密钥管理细则、应急方案、定期评估机制

九、自测验证清单：照着查，提前知道能不能过

加固完成后，按以下清单自测，全部通过基本可以稳过密评。

检测项	检测方法	达标标准
三权分立	验证三个管理员账号权限相互隔离	系统管理员看不到审计日志，审计管理员改不了业务数据
国密传输	抓包数据库端口流量	无明文 SQL 与数据，使用国密 SSL 套件
存储加密	查看敏感表所在表空间加密属性	敏感表使用 SM4 透明加密，落盘为密文
密钥管理	核查密钥存储位置、生成方式	密钥存储在 KMS / 密码机，不落地明文，全生命周期可审计
审计完整性	检查审计日志签名、留存时间	日志不可篡改，留存≥180 天，覆盖所有关键操作
口令策略	测试弱口令是否可创建	无法创建弱口令，复杂度、有效期、锁定策略生效
权限最小化	核查业务账号权限	无 DBA 权限，仅业务必要权限
网络隔离	非授权网段尝试连接数据库	连接被拒绝，仅白名单可访问
管理制度	检查制度文档	有密码安全管理、密钥管理、应急演练等制度文件

总结

人大金仓 K8s 环境密评三级加固，核心不是堆加密功能，而是全链路符合国密要求、密钥管理闭环、权限最小化、审计可追溯。从 K8s 底座到数据库内核，再到密钥管理体系，每一层都对标 GM/T 0054 标准做实，才能一次性顺利通过测评。

密评不是一次性工作，而是持续运营的过程。技术加固只是基础，配套的管理制度、定期巡检、密钥轮换、应急演练同样重要。

政务选金仓，金融选达梦；MySQL 迁移选金仓，Oracle 迁移选达梦。

📚 专栏推荐：专注 SpringBoot3 + 人大金仓 + 达梦信创实战，持续输出生产级部署、性能调优、安全合规、避坑指南干货，关注不迷路。

觉得文章有用的话，欢迎点赞、收藏、关注三连，后续更新更多信创数据库云原生落地的硬核内容。