第一章:Dify企业版私有化部署安全合规总览
Dify企业版私有化部署严格遵循等保2.0三级、GDPR及《个人信息保护法》等国内外主流安全合规框架,所有组件默认启用最小权限原则、传输加密与静态数据加密机制。部署环境完全隔离于公网,敏感配置(如数据库凭证、密钥管理服务地址)通过Kubernetes Secret或HashiCorp Vault注入,杜绝硬编码风险。
核心安全控制域
- 网络层:强制启用双向TLS(mTLS)通信,API网关与后端服务间使用SPIFFE身份认证
- 数据层:PostgreSQL启用了透明数据加密(TDE),向量数据库(如Qdrant)配置AES-256磁盘级加密
- 审计层:所有用户操作日志实时写入独立Syslog服务器,保留周期≥180天,支持SIEM系统对接
合规基线检查工具调用
执行以下命令可一键生成符合ISO/IEC 27001附录A条款的部署合规报告:
# 运行内置合规扫描器(需在dify-enterprise容器内执行)
docker exec -it dify-enterprise \
/opt/dify/tools/compliance-audit.sh \
--standard iso27001 \
--output /tmp/audit-report.json
该脚本自动检测容器运行时策略、Pod安全策略(PSP)、RBAC权限收敛度及敏感端口暴露状态,并输出结构化JSON报告供第三方审计平台导入。
关键配置项对照表
| 合规要求 | 默认启用状态 | 配置路径 |
|---|
| 会话令牌有效期≤30分钟 | 启用 | env.DIFY_SESSION_EXPIRE_MINUTES=30 |
| 密码复杂度策略(8位+大小写字母+数字+符号) | 启用 | auth.password_policy.enabled=true |
| API密钥轮换周期≤90天 | 启用 | api_key.rotation_days=90 |
零信任访问模型
graph LR
A[用户设备] -->|1. 设备证书校验| B(API网关)
B -->|2. JWT身份断言验证| C[应用服务]
C -->|3. 动态RBAC策略引擎| D[数据服务]
第二章:网络层与传输加密加固
2.1 基于国密SM4的API网关加密通道构建(理论:SM4算法特性与GCM模式选型;实践:Nginx+OpenSSL国密模块编译与TLS1.3-SM4双向握手配置)
SM4-GCM核心优势
SM4为32轮非线性迭代分组密码,密钥与分组长度均为128位;GCM模式提供认证加密(AEAD),兼具机密性、完整性与高性能。相较CBC模式,GCM天然支持并行计算,且无需填充,在TLS 1.3中成为SM4首选操作模式。
Nginx启用SM4-TLS1.3双向认证
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_128_GCM_SHA256:SM4-GCM-SHA256;
ssl_certificate /etc/nginx/certs/gw.sm4.crt;
ssl_certificate_key /etc/nginx/certs/gw.sm4.key;
ssl_verify_client on;
ssl_trusted_certificate /etc/nginx/certs/ca.sm4.crt;
该配置强制仅协商TLS 1.3,并优先选用国密套件
SM4-GCM-SHA256;
ssl_verify_client on启用客户端证书校验,实现双向身份认证。
国密套件兼容性对比
| 套件 | 算法组合 | TLS 1.3支持 | 国密合规性 |
|---|
| TLS_AES_128_GCM_SHA256 | AES-128-GCM + SHA256 | ✓ | ✗ |
| SM4-GCM-SHA256 | SM4-GCM + SHA256 | ✓ | ✓ |
2.2 私有K8s集群Ingress流量审计与TLS终止策略(理论:mTLS在AI服务链路中的信任边界划分;实践:Istio Gateway + cert-manager集成国密CA签发SM2证书)
mTLS信任边界的三层划分
在AI服务链路中,mTLS将信任边界划分为:接入层(外部不可信)、调度层(可信但需隔离)、模型服务层(高敏域)。各层间通过双向证书校验实现细粒度访问控制。
Istio Gateway配置SM2证书
apiVersion: networking.istio.io/v1beta1
kind: Gateway
spec:
servers:
- port: {number: 443, name: https, protocol: HTTPS}
tls:
mode: SIMPLE
privateKey: /etc/istio/ingress-certs/tls.key # SM2私钥(PEM格式,含OID 1.2.156.10197.1.501)
serverCertificate: /etc/istio/ingress-certs/tls.crt # 国密CA签发的SM2证书链
该配置启用国密算法栈的TLS终止,cert-manager通过CustomResource
ClusterIssuer对接支持SM2的国密CA,自动轮换证书。
证书签发流程对比
| 维度 | 国际RSA PKI | 国密SM2 PKI |
|---|
| 签名算法OID | 1.2.840.113549.1.1.11 | 1.2.156.10197.1.501 |
| 密钥长度 | 2048/4096 bit | 256 bit(等效RSA 3072) |
2.3 零信任网络分段设计:Dify组件间微隔离策略(理论:服务网格东西向流量最小权限原则;实践:Calico NetworkPolicy定义Worker/Orchestrator/API-Server三域通信白名单)
最小权限通信模型
零信任要求每个组件仅能访问其业务必需的对端服务与端口。在 Dify 架构中,Worker 节点仅需调用 Orchestrator 的任务调度接口(TCP/8081),而 Orchestrator 仅可访问 API-Server 的 REST 端点(TCP/8000)及 Redis 缓存(TCP/6379)。
Calico 白名单策略示例
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: allow-worker-to-orchestrator
spec:
selector: app == 'dify-worker'
types: ['Egress']
egress:
- action: Allow
protocol: TCP
destination:
selector: app == 'dify-orchestrator'
ports:
- 8081
该策略限制 Worker 出向流量仅允许访问 Orchestrator 的 8081 端口,拒绝所有其他 IP、端口及协议,落实东西向最小权限。
三域通信矩阵
| 源域 | 目标域 | 允许端口 | 协议 |
|---|
| Worker | Orchestrator | 8081 | TCP |
| Orchestrator | API-Server | 8000 | TCP |
| Orchestrator | Redis | 6379 | TCP |
2.4 敏感数据传输脱敏网关集成(理论:动态字段级脱敏与上下文感知规则引擎;实践:Envoy WASM Filter注入SM4-GCM加密逻辑处理LLM Prompt/Response)
动态脱敏策略执行流
请求经 Envoy 入口后,WASM Filter 加载上下文感知规则引擎,实时解析 HTTP Header、URL Path 及 JSON Body 结构,识别 `user_id`、`id_card`、`prompt_text` 等敏感字段路径。
SM4-GCM 加密逻辑注入
#[no_mangle]
pub extern "C" fn proxy_on_request_headers() -> Status {
let body = get_http_body();
let mut json = parse_json(&body);
if let Some(prompt) = json.get_mut("prompt") {
let cipher = sm4_gcm_encrypt(prompt.as_str().unwrap(), &KEY, &NONCE);
*prompt = json!(base64::encode(cipher));
}
Status::Ok
}
该 Rust WASM 函数在请求头阶段触发,对 LLM 输入 prompt 执行 SM4-GCM 认证加密(128-bit 密钥、96-bit 随机 nonce),输出 Base64 编码密文,确保传输机密性与完整性。
规则引擎匹配示意
| 上下文条件 | 脱敏动作 | 适用场景 |
|---|
| Content-Type: application/json && path=/v1/chat/completions | SM4-GCM 加密 prompt/response 字段 | 大模型 API 流量 |
| Header: X-Auth-Role=admin | 保留原始 id_card 字段 | 高权限审计通道 |
2.5 网络策略自动化验证与红蓝对抗测试(理论:基于Cilium Tetragon的eBPF运行时策略可观测性;实践:编写YAML策略基线并执行chaos-mesh注入DNS劫持场景验证加密兜底机制)
eBPF策略可观测性闭环
Cilium Tetragon通过eBPF探针实时捕获网络连接、DNS解析及TLS握手事件,将策略执行日志以结构化JSON流输出至可观测平台。
DNS劫持验证策略基线
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
name: tls-fallback-enforce
spec:
endpointSelector: {}
egress:
- toPorts:
- ports:
- port: "443"
protocol: TCP
- toFQDNs:
- matchName: "*.internal"
- toFQDNs:
- matchPattern: "*"
rules:
dns:
- matchName: "malicious.example.com"
该策略强制所有出向流量经443端口TLS加密,并对未知FQDN启用DNS白名单兜底。`matchPattern: "*"` 触发Tetragon告警,驱动红队注入chaos-mesh DNS劫持故障。
验证流程关键指标
| 指标 | 预期值 | 采集方式 |
|---|
| TLS握手成功率 | ≥99.5% | Tetragon trace_event: tls_handshake |
| 非法DNS解析拦截率 | 100% | Cilium policy verdict logs |
第三章:身份认证与访问控制体系
3.1 SPIFFE/SPIRE联邦身份架构落地(理论:SVID生命周期管理与跨云身份联邦模型;实践:SPIRE Server高可用部署+Dify Agent节点自动注册与Workload Attestation)
SVID生命周期关键阶段
- 颁发:SPIRE Server基于attestation策略签发短期X.509 SVID
- 轮换:默认每1小时自动续期,最小TTL可设为5分钟
- 吊销:通过JWT-SVID的jti声明与SPIRE Server实时校验状态
跨云联邦信任链
| 云环境 | Trust Domain | 上游CA |
|---|
| AWS EKS | spiffe://aws.example.com | spiffe://global.example.com |
| Azure AKS | spiffe://azure.example.com | spiffe://global.example.com |
Dify Agent自动注册配置
node_resolver:
plugin: "k8s">
config:
cluster_name: "dify-prod"
namespace: "dify-agents"
label_selector: "app=dify-agent,spire-auto-register=true"
该配置启用Kubernetes原生attestation,SPIRE Agent通过Pod标签自动发现并注册Dify工作负载;
label_selector确保仅注册带标识的可信Agent实例,
cluster_name用于生成唯一SPIFFE ID前缀。
3.2 Dify多租户RBAC与SPIFFE Identity Mapping(理论:SPIFFE ID到企业AD组的声明映射机制;实践:Keycloak Identity Provider配置SPIFFE JWT解析器并同步至Dify Permission Service)
SPIFFE Identity 声明映射原理
SPIFFE ID(如
spiffe://example.org/ns/finance/sa/dify-prod)通过 JWT 的
spiffe.io/spiffeid 和
groups 声明,携带企业 AD 组上下文。Dify Permission Service 依赖该声明实现租户隔离与 RBAC 策略绑定。
Keycloak SPIFFE JWT 解析器配置
{
"name": "spiffe-jwt-mapper",
"protocol": "openid-connect",
"protocolMapper": "oidc-usermodel-attribute-mapper",
"config": {
"user.attribute": "spiffe_groups",
"claim.name": "groups",
"jsonType.label": "String"
}
}
该配置将 JWT 中的
groups 数组提取为 Keycloak 用户属性
spiffe_groups,供后续同步服务消费。
AD组同步至Dify权限服务
- Keycloak 通过 REST API 向 Dify Permission Service 推送用户 SPIFFE ID 与解析后的 AD 组列表
- Dify 根据
spiffe://domain.org/ns/{tenant}/... 自动推导租户上下文
| SPIFFE ID 示例 | 映射租户 | 同步AD组 |
|---|
spiffe://corp.com/ns/hr/sa/dify-staging | hr | ad-group-hr-approvers |
3.3 API密钥与服务账户的国密签名鉴权(理论:SM2非对称签名在Service-to-Service调用中的不可抵赖性;实践:Dify Connector SDK集成GMSSL实现HTTP Header X-SM2-Signature验签)
不可抵赖性的密码学根基
SM2签名基于椭圆曲线离散对数难题,私钥签名、公钥验签,天然保障调用方身份绑定与行为留痕。服务间通信中,签名附于请求头,接收方可独立验证来源且无法被发送方否认。
验签流程关键步骤
- 提取请求头
X-SM2-Signature 中的 Base64 编码签名值 - 拼接待签名原文:HTTP 方法 + 路径 + 时间戳(
X-Timestamp)+ 请求体 SHA256 摘要 - 使用服务注册时预置的调用方 SM2 公钥执行验签
Dify Connector SDK 集成示例
// GMSSL 验签核心逻辑(Go 实现)
sigBytes, _ := base64.StdEncoding.DecodeString(r.Header.Get("X-SM2-Signature"))
raw := []byte(fmt.Sprintf("%s%s%s%s", r.Method, r.URL.Path, r.Header.Get("X-Timestamp"), bodyHash))
ok := gmssl.VerifySM2(pubKeyPEM, raw, sigBytes)
该代码调用 GMSSL 库的
VerifySM2 函数,输入为 PEM 格式公钥、待验原文和原始签名字节;返回布尔值表示验签是否通过,确保服务端可零信任校验每个跨服务请求。
签名字段对照表
| Header 字段 | 作用 | 生成约束 |
|---|
| X-Timestamp | 请求时间戳(毫秒级) | 需在 5 分钟窗口内有效 |
| X-SM2-Signature | SM2 签名 Base64 编码 | 签名原文含方法、路径、时间戳及 body 摘要 |
第四章:数据静态保护与密钥治理
4.1 PostgreSQL透明数据加密(TDE)国密适配(理论:SM4-XTS模式在块设备层与数据库层的协同加密原理;实践:pgcrypto扩展源码级改造支持SM4并配置pg_tde插件)
SM4-XTS协同加密模型
SM4-XTS在块设备层负责扇区级加解密,数据库层通过pg_tde拦截Buffer I/O路径,确保页头校验与密钥派生一致。二者共享统一密钥管理服务(KMS),采用双密钥派生:主密钥经SM3-HMAC生成XTS-Key1/Key2。
pgcrypto SM4支持改造关键点
- 在
src/include/cryptohash.h中新增CRYPTO_ALGO_SM4_XTS枚举 - 扩展
pgcrypto/px.c注册SM4-XTS算法句柄,调用OpenSSL 3.0+国密引擎
SM4-XTS加解密核心逻辑
/* sm4_xts_encrypt() —— pgcrypto/src/cryptohash/sm4_xts.c */
int sm4_xts_encrypt(const uint8 *key, size_t keylen,
const uint8 *iv, size_t ivlen,
const uint8 *src, uint8 *dst, size_t len) {
EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
// 使用国密标准OID: 1.2.156.10197.1.104.1(SM4-XTS)
EVP_EncryptInit_ex(ctx, EVP_sm4_xts(), NULL, key, iv);
EVP_EncryptUpdate(ctx, dst, &outl, src, len);
EVP_EncryptFinal_ex(ctx, dst + outl, &finl);
EVP_CIPHER_CTX_free(ctx);
return outl + finl;
}
该函数严格遵循GM/T 0002-2019 XTS-AES扩展规范,将IV映射为扇区号×16字节Tweak值,确保同一密钥下不同数据页产生唯一密文。参数
keylen必须为64字节(SM4双密钥各32字节),
iv长度固定为16字节。
4.2 向量数据库敏感字段加密存储(理论:嵌入向量与元数据分离加密模型;实践:Qdrant自定义Payload加密Filter + SM4-CBC密钥轮转策略)
加密架构设计原则
向量本身不承载可识别身份的语义,但Payload中的用户ID、手机号等元数据具备强敏感性。因此采用「向量明文存储 + Payload密文封装」双轨模型,确保检索效率与合规性兼得。
SM4-CBC密钥轮转实现
// 使用AES-like接口适配SM4,keyVersion嵌入IV前缀
func encryptPayload(payload map[string]interface{}, keyVersion uint32) ([]byte, error) {
iv := make([]byte, 16)
binary.BigEndian.PutUint32(iv[:4], keyVersion) // 前4字节为版本号
block, _ := sm4.NewCipher(getKeyByVersion(keyVersion))
mode := cipher.NewCBCEncrypter(block, iv)
// ... PKCS#7填充与加密逻辑
}
该实现将密钥版本写入IV头部,使解密端可动态加载对应密钥,支持按月轮转且无需全量重索引。
Qdrant Filter兼容性适配
- 注册自定义Filter:拦截
payload字段读写路径 - 加密后Payload以Base64编码存入
encrypted_payload字段 - 原始字段仅保留非敏感键(如
doc_type)用于过滤
4.3 密钥生命周期全链路审计(理论:HSM-backed密钥分发与FIPS 140-2 Level 3合规路径;实践:Vault Transit Engine集成国产密码机,配置SM4密钥策略与审计日志对接SIEM)
国产密码机集成关键配置
mount "transit" {
path = "transit-sm4"
options = {
type = "transit"
backend = "transit"
}
}
key "sm4-app-key" {
type = "symmetric"
derivation = true
convergent_encryption = true
exportable = false
deletion_allowed = false
min_decryption_version = 1
min_encryption_version = 1
allowed_operations = ["encrypt", "decrypt", "generate", "rewrap"]
key_usage = "SM4-CBC"
}
该配置启用Vault Transit Engine的国密支持模式,
key_usage = "SM4-CBC" 显式声明算法套件,
exportable = false 强制密钥驻留于HSM边界内,满足FIPS 140-2 Level 3物理防篡改要求。
审计日志结构化输出
| 字段 | 说明 | SIEM映射 |
|---|
| operation | encrypt/decrypt/rewrap | event.action |
| key_id | SM4密钥唯一标识符 | cloud.resource.id |
| hsm_serial | 密码机硬件序列号 | device.serial_number |
4.4 敏感配置项国密信封加密(理论:KMS信封加密在K8s ConfigMap/Secret中的轻量级实现;实践:Dify Operator自动注入SM4密钥封装逻辑,解密注入容器环境变量)
信封加密核心流程
国密信封加密采用“数据密钥(DEK)+ 主密钥(KEK)”双层保护:SM4加密敏感配置生成密文,KEK(如HSM托管的SM2私钥)加密DEK。K8s Secret仅存储加密后的DEK与密文,运行时由Sidecar或Operator动态解密。
Dify Operator注入逻辑
// 在Pod MutatingWebhook中注入解密initContainer
initContainers:
- name: sm4-decryptor
image: registry.example.com/dify-sm4-decryptor:v1.2
env:
- name: KMS_ENDPOINT
value: "https://kms.gov.cn/api/v1"
- name: SM2_KEY_ID
value: "sm2-key-2024-prod"
volumeMounts:
- name: encrypted-config
mountPath: /encrypted
- name: decrypted-env
mountPath: /env
该initContainer调用国密KMS服务,使用集群预置SM2密钥解封DEK,再用DEK解密SM4密文,并将明文写入
/env卷供主容器读取。
安全对比表
| 方案 | 密钥管理 | K8s资源暴露面 |
|---|
| 原生Secret明文 | 无 | 全量敏感值 |
| 国密信封加密 | HSM/SM2 KEK托管 | 仅加密DEK+密文 |
第五章:安全门验收清单与等保2.0三级对标说明
核心验收项与等保三级映射关系
以下为安全门(即Web应用防火墙WAF+API网关融合防护节点)在等保2.0三级系统中必须验证的8项关键能力,已按“技术要求—测评方法—实测证据”三列对齐:
| 技术要求 | 测评方法 | 实测证据 |
|---|
| 具备SQL注入、XSS、命令执行等OWASP Top 10攻击实时阻断能力 | 使用sqlmap -u "https://api.example.com/user?id=1" --batch --level=5 --risk=3 | WAF日志显示Rule ID 942100触发,HTTP 403响应,且原始请求未到达后端Nginx |
典型配置校验代码片段
# Nginx + ModSecurity v3.3 集成验证配置(需启用SecRuleEngine On)
SecRule ARGS "@rx \b(SELECT|UNION|INSERT)\b" \
"id:1001,phase:2,deny,status:403,msg:'SQLi Detected',logdata:'%{MATCHED_VAR}'"
日志审计合规要点
- 所有拦截/放行事件必须记录客户端IP、URI、User-Agent、匹配规则ID、时间戳(精确到毫秒)
- 日志须通过syslog转发至SIEM平台(如Splunk),保留周期≥180天
- 禁止记录敏感字段明文(如password、id_card),需在WAF层做字段脱敏(正则替换)
等保三级专项验证案例
某政务云API网关于2023年11月接受等保测评时,因未开启“HTTP协议合规性检查”(RFC 7230)被开具高风险项。整改后启用ModSecurity SecRule REQUEST_PROTOCOL "^HTTP/1\.1$",成功拦截HTTP/0.9畸形请求,并在测评报告中提供连续72小时审计日志截图为证。