跳到主内容
Autional 徽标
Compliance10 分钟#政府#信创#SM 算法

政务信息化身份:等保三级 + SM 算法 + 信创适配

合规声明:本文所述的技术能力——SM 算法、等保三级、信创适配——为 Autional 平台的设计目标,不构成等保测评认证或信创产品认证。政务系统的最终合规责任由系统运营者根据具体项目要求承担。SM 算法的合规使用须遵循国家密码管理局的最新规范。

政务信息化的特殊性

政务信息化建设有一个常被外部忽视的特点:它不是从「零」开始做选择,而是在一个强约束的技术框架内寻找最优解。

这个框架由三个因素定义:

  1. 等保 2.0 定义了安全等级与保护要求——政务系统通常定级在三级及以上
  2. 《密码法》+ SM 标准 规定了必须使用的密码算法——SM2(非对称)、SM3(哈希)、SM4(对称)
  3. 信创目录 限定了可采用的硬件架构、操作系统与基础软件

再加上内网部署、离线运行、涉密信息保护等政务场景的特殊要求,共同构成了一个与互联网 SaaS 开发截然不同的技术环境。

等保三级:政务系统的安全基线

等保 2.0 把信息系统安全等级划分为五级。三级(安全标记保护级)是大多数政务系统的最低要求。相比二级,三级的核心差异在于:

强制访问控制(MAC):在自主访问控制(DAC)——即由用户自行决定谁可以访问自己的数据——之外,系统还要基于安全标记强制执行访问规则。

安全标记:主体(用户)与客体(数据)都必须绑定安全标记,访问决策基于标记比对。

形式化安全策略模型:访问控制策略必须有形式化描述与严格实现。

对身份系统而言,这意味着:

  • 每个用户必须绑定安全级别标记
  • 每条数据必须绑定密级标记(公开 / 内部 / 秘密 / 机密 / 绝密)
  • 访问决策基于 Bell-LaPadula 模型(不下读、不上写)或等效实现

Autional 为此提供了增强的访问控制:

  • 用户安全级别标记通过 RBAC 角色属性实现
  • 资源安全标记通过数据库元数据字段实现
  • 访问决策在 identity-service 的权限校验引擎中强制执行

等保对身份鉴别的具体要求

身份鉴别:

  • 唯一标识 + 复杂度策略 + 定期更换
  • 两种或两种以上组合的鉴别技术(口令 + 证书/生物特征/USB Key)
  • 登录失败锁定 + 会话超时

访问控制:

  • 知必所需的权限分配(最小权限原则)
  • 删除/重命名默认账号
  • 及时清理过期/多余账号
  • 主体客体安全标记

安全审计:

  • 审计范围覆盖所有用户与安全事件
  • 审计记录包含日期、时间、类型、主体标识、客体标识与事件结果
  • 审计记录受保护,防止未授权的修改与删除

通信保密性:

  • 通信过程中对鉴别信息加密传输
  • 采用密码技术保证通信数据的完整性与保密性

Autional 对这些要求的覆盖:

等保要求 Autional 实现
两种以上鉴别方式 口令 + SM2 证书 + TOTP,或口令 + USB Key(FIDO2)
强制访问控制 RBAC + 安全标记绑定
安全审计 audit-service 哈希链 + 防篡改存储
通信加密 TLS 1.3(SM2/SM4 密码套件)+ mTLS
会话安全 session-service 空闲/绝对超时 + 设备绑定

SM 算法:身份系统中的密码改造

2020 年 1 月 1 日起施行的《密码法》第二十七条明确规定:「法律、行政法规和国家有关规定要求使用商用密码进行保护的关键信息基础设施,其运营者应当使用商用密码进行保护。」

对政务系统而言,这意味着必须使用国家密码管理局认可的商用密码算法(即用 SM 算法替代国际算法):

flowchart TD
    SM2["SM2 — 替代 RSA / ECDSA"] --> U2["JWT 签名、密钥协商、SM2 证书体系"]
    SM3["SM3 — 替代 SHA-256"] --> U3["口令加盐哈希、数据完整性、哈希链校验"]
    SM4["SM4 — 替代 AES"] --> U4["传输加密、字段级存储加密、配置加密"]

图 1:SM 算法替换对照——SM2 接手 RSA/ECDSA,SM3 接手 SHA-256,SM4 接手 AES,以及它们各自在身份系统里的落点。

SM2:椭圆曲线公钥密码算法

SM2 替代 RSA 与 ECDSA,应用于:

  • 数字签名:JWT 令牌签名、API 请求签名、数据完整性签名
  • 密钥协商:TLS 握手过程中的密钥交换
  • 证书体系:基于 SM2 的 PKI 体系

在 Autional 中,SM2 的应用场景包括:

  • identity-service 的 JWT 签名:使用 SM2 签名替代 HS256/RS256
  • mfa-service 的 Passkey:利用 SM2 的签名机制实现免密认证
  • 服务间通信:通过 SM2 证书实现双向认证

SM3:密码杂凑算法

SM3 替代 SHA-256,应用于:

  • 口令哈希:用户口令的加盐哈希存储
  • 数据完整性:文件/记录的数字摘要
  • 区块链/哈希链:audit-service 的哈希链校验

SM4:分组密码算法

SM4 替代 AES,应用于:

  • 数据传输加密:TLS 中的数据加密
  • 数据存储加密:数据库中的字段级加密
  • 配置文件加密:密钥等敏感配置的加密存储

SM 算法迁移的挑战与技术解法

从国际算法(RSA/AES/SHA)迁移到 SM 算法是一项系统性工程挑战:

挑战一:算法性能差异。由于椭圆曲线参数与协议细节的不同,SM2 签名比 ECDSA 慢 2-3 倍。解法:Autional 在生成 JWT 时进行批量预签名,并池化身份令牌以供复用。

挑战二:密码库依赖。Go 标准库不包含 SM 算法,需要 tjfoc/gmsm 或 emmansun/gmsm 等第三方库——这些库的维护者与成熟度都需要评估。Autional 使用经过独立安全审计的 SM 库版本,并做持续的 CI 验证。

挑战三:TLS 适配。标准 TLS 握手使用 ECDHE + RSA/AES,而 SM TLS 应使用 ECDHE + SM2/SM4。但 SM TLS 的实现规范(GM/T 0024《SSL VPN 技术规范》)与国际 TLS 1.3 并不完全兼容。Autional 采用双协议栈方案:内网通信使用 SM TLS,外网通信使用标准 TLS 1.3。

信创适配:从「跑得起来」到「用得顺手」

信创(信息技术应用创新)旨在实现关键技术与产品的自主可控,这直接影响部署环境的选择:

  • CPU 架构:x86 → ARM(鲲鹏、飞腾)/ LoongArch(龙芯)
  • 操作系统:Windows → 麒麟 / 统信 UOS
  • 数据库:SQL Server/Oracle → DM(达梦)/ 人大金仓 / GaussDB
flowchart LR
    X["x86"] --> K["ARM — 鲲鹏、飞腾 / LoongArch — 龙芯"]
    W["Windows"] --> U["麒麟 / 统信 UOS"]
    D["SQL Server / Oracle"] --> M["DM — 达梦 / 人大金仓 / GaussDB"]
    S["MinIO / S3"] --> O["杉岩 / XSKY 等国产对象存储"]
    R["Redis"] --> G["Garnet / Tendis 等兼容实现"]
    Q["RabbitMQ"] --> RQ["RocketMQ / 国产 Pulsar"]

图 2:信创替代映射——从 CPU、操作系统、数据库,到存储、缓存、消息队列,每一层都有一条国产化替换路径。

对 Autional 而言,信创适配的核心工作包括:

编译适配

Go 1.25 原生支持 Linux ARM64,可直接交叉编译:

GOOS=linux GOARCH=arm64 go build -o identity-service-linux-arm64 ./cmd/server

数据库适配

Autional 通过 infra-client/gorm 的工厂模式支持数据库驱动切换。适配达梦数据库只需:

  1. 引入达梦的 GORM 驱动
  2. 配置数据库连接串
  3. 验证 AutoMigrate 输出的 SQL 语法兼容性

存储适配

  • 文件存储:从 MinIO/S3 切换到国产对象存储(如杉岩、XSKY)
  • 缓存:从 Redis 切换到兼容 Redis 协议的国产缓存(如 Garnet、Tendis)

中间件适配

  • 消息队列:从 RabbitMQ 切换到 RocketMQ 或国产 Pulsar 发行版
  • API 网关:保留 gateway-service,但底层通信切换为 SM TLS

内网部署与离线运行

许多政务系统要求完全离线运行(不连接互联网),这对身份系统提出了独特挑战:

Passkey 与生物识别:FIDO2/WebAuthn 的通行密钥通常依赖平台同步服务(如 iCloud Keychain)实现跨设备同步。离线环境需要替代方案:

  • 使用基于 SM2 的硬件密钥(类似 USB Token),通过 USB/NFC 连接
  • 完全本地化的人脸识别,不依赖云端 API

软件更新:离线环境中的软件更新必须通过安全的离线介质(如加密光盘、带签名的 U 盘)。Autional 需要提供离线补丁包校验与安装机制。

时间同步:JWT 令牌、TOTP 验证码、会话超时都依赖准确的时间。离线环境必须通过本地 NTP 服务器或 GPS 授时确保时间一致性。

结语

为政务系统构建身份认证,是一项「戴着镣铐跳舞」的工程挑战——要在等保法规、SM 标准与信创目录的多重约束下,构建既安全又实用的身份基础设施。

Autional 通过完整的 SM 算法支持(SM2/SM3/SM4)、多 CPU 架构的编译适配、国产数据库与中间件对接、离线部署能力,以及增强的审计与访问控制,为政务信息化建设提供开箱即用的身份方案——无需「从零造轮子」。

相关阅读

准备好给应用加上身份层了吗?

Autional 提供认证、组织、访问控制、审计与开发者 API —— 面向 AI 生成应用的身份层。