安全合规

• 1: 七层安全模型
• 2: 身份认证
• 3: 访问控制
• 4: 加密通信与本地 CA
• 5: 数据安全
• 6: 合规清单

1 - 七层安全模型

安全不是一道墙，而是一座城。Pigsty 采用纵深防御策略，在七个层次上构建多重保护，即使某一层被突破，仍有其他层提供保护。

这种分层思路解决三类核心风险：

• 边界被突破：降低“单点失守导致全盘失守”的概率。
• 内部滥用：即使内部账号被盗，也能通过最小权限限制破坏范围。
• 不可预期故障：硬件、软件、人为错误都能被“多层兜底”。

概览

L1 物理与介质安全

物理层失守时，唯一的对抗手段是数据本身的自我保护。

解决的问题

• 硬件故障导致静默数据损坏
• 介质被盗导致数据泄露

Pigsty 支持

• 数据校验和：默认开启 pg_checksum: true，可发现坏块/内存错误导致的数据损坏。
• 可选透明加密：通过 pg_tde 等扩展实现数据静态加密，防止介质泄露。

L2 网络安全

控制“谁能接触到服务”，降低攻击面。

解决的问题

• 未授权网络访问
• 明文传输被窃听/篡改

Pigsty 支持

• 防火墙分区：node_firewall_mode 可启用 zone，内网信任、公网受限。
• 监听收敛：pg_listen 可限制监听地址，避免全网暴露。
• TLS 能力：HBA 支持 ssl/cert，保证连接加密与身份校验。

L3 边界安全

“统一入口”是可审计、可控制、可封禁的基础。

解决的问题

• 多入口难以管控
• 外部系统无处统一加固

Pigsty 支持

• HAProxy 入口：数据库流量统一入口，便于封禁/限流/切换。
• Nginx 网关：基础设施服务统一 HTTPS 入口（nginx_sslmode）。
• 集中管理口令：HAProxy 管理口令、Grafana 管理口令统一在配置中声明。

L4 主机安全

数据库安全的地基：最小权限、访问隔离、系统加固。

解决的问题

• 主机被入侵导致全盘失守
• 管理权限过度扩散

Pigsty 支持

• SELinux 模式：node_selinux_mode 可切换 enforcing 强制模式。
• 最小权限管理员：node_admin_sudo 支持 limit 限制 sudo 命令集。
• 敏感文件权限：CA 私钥目录默认 0700，私钥文件 0600。

L5 应用安全

认证是所有数据库安全的“第一道闸门”。

解决的问题

• 弱密码或明文认证导致账号泄露
• 错误放行导致越权访问

Pigsty 支持

• HBA 分层控制：默认规则按来源与角色分层，管理员外网访问必须 ssl。
• SCRAM 密码哈希：pg_pwd_enc: scram-sha-256 默认启用。
• 密码强度检查：passwordcheck/credcheck 可启用，阻止弱口令。
• 证书认证：auth: cert 支持客户端证书认证。

L6 数据安全

保障数据在“可用、可恢复、可追责”。

解决的问题

• 人为误操作与逻辑错误
• 黑客入侵后数据被篡改或删除

Pigsty 支持

• pgBackRest 备份：默认启用，支持本地与 MinIO 仓库。
• 备份加密：MinIO 仓库支持 AES-256-CBC（cipher_type）。
• PITR 恢复：结合归档可恢复到任意时间点。
• 审计日志：模板启用 DDL/连接/慢查询日志，可选 pgaudit。

L7 用户安全

最小权限不是口号，而是默认行为。

解决的问题

• 业务账号拥有过高权限
• 数据库之间相互“穿透”

Pigsty 支持

• 四层 RBAC：dbrole_readonly/readwrite/admin/offline。
• 默认权限策略：对象创建即自动授予正确权限。
• 数据库隔离：revokeconn: true 可隔离跨库访问。
• 公共权限收敛：撤销 public 模式 CREATE 权限。

安全加固路径

Pigsty 提供安全增强模板：conf/ha/safe.yml。它将常见加固项集中封装：

• 强制 SSL、证书认证
• 密码强度与过期策略
• 连接与断开日志
• 防火墙与 SELinux 加固

这条路径可以作为“从默认到合规”的快速升级方案。

接下来

• 🔑 身份认证：HBA 规则与密码策略
• 👤 访问控制：角色系统与权限模型
• 🔐 加密通信：TLS 与证书管理
• 🔒 数据安全：备份与加密
• ✅ 合规清单：等保与 SOC2 对照

2 - 身份认证

身份认证解决三个核心问题：

• 你是谁：身份是否唯一可识别？
• 你怎么证明：密码/证书是否足够安全？
• 你从哪里来：来源是否受控？

Pigsty 使用 HBA 规则 + 密码/证书 完成身份认证，并以 SCRAM 为默认密码哈希方案。

认证链路

flowchart LR
  C[客户端] --> HBA[HBA 规则]
  HBA --> A1[密码 SCRAM]
  HBA --> A2[证书认证]
  HBA --> A3[本地 ident/peer]
  A1 --> RBAC[角色与权限]
  A2 --> RBAC
  A3 --> RBAC

HBA 决定“谁能从哪里来”，认证方式决定“如何证明身份”。

HBA 分层模型

Pigsty 默认 HBA 规则已经分层：

• 本地使用 ident/peer，最安全。
• 内网使用 scram 密码认证。
• 外网管理员必须走 ssl。

这解决了“同一个用户在不同来源使用不同认证强度”的问题。

HBA 规则的关键能力

• 顺序优先：支持 order 排序，数值越小优先级越高。
• 地址别名：local / localhost / intra / world 等。
• 角色条件：primary/replica/offline 可精细化控制。

密码认证

默认密码哈希算法：

pg_pwd_enc: scram-sha-256

解决的问题

• 明文密码存储风险
• 弱哈希被离线破解

兼容性

如需兼容老客户端可使用 md5，但会降低安全性。

密码强度与轮换

Pigsty 支持启用密码强度检查扩展：

pg_libs: '$libdir/passwordcheck, pg_stat_statements, auto_explain'
pg_extensions: [ passwordcheck, credcheck ]

通过 expire_in 控制账号过期时间：

pg_users:
  - { name: dbuser_app, password: 'StrongPwd', expire_in: 365 }

解决的问题

• 弱口令与口令复用
• 长期不轮换的账号风险

证书认证

证书认证解决“密码被钓鱼/被拷贝”的风险。

• HBA auth: cert 要求客户端证书。
• 证书 CN 通常对应数据库用户名。
• Pigsty 内置 cert.yml 用于签发客户端证书。

PgBouncer 认证

PgBouncer 使用独立 HBA 规则与 TLS 设置：

pgbouncer_sslmode: disable   # 默认关闭，可设为 require/verify-full
pgb_default_hba_rules: [...] # 独立规则

这解决了“连接池入口与数据库入口不同步”的问题。

默认账号与风险

生产环境必须修改默认密码。

安全建议

• 对外入口全部启用 ssl/cert。
• 内网用户使用 scram，避免 md5。
• 启用 passwordcheck 强制复杂度。
• 定期轮换口令（expire_in）。

接下来

• 👤 访问控制：角色与权限模型
• 🔐 加密通信：TLS 与证书管理
• ✅ 合规清单：等保与 SOC2 对照

3 - 访问控制

访问控制解决两个核心问题：

• 你能做什么：读/写/DDL 的权限边界
• 你能访问哪些数据：跨库、跨模式的隔离边界

Pigsty 通过 RBAC 角色体系 + 默认权限策略 将“最小权限”落实为默认行为。

四层角色模型

flowchart TB
    subgraph Admin["dbrole_admin（管理员）"]
        A1["可执行 DDL / CREATE / ALTER"]
        A2["继承 dbrole_readwrite"]
    end
    subgraph RW["dbrole_readwrite（读写）"]
        RW1["可 INSERT/UPDATE/DELETE"]
        RW2["继承 dbrole_readonly"]
    end
    subgraph RO["dbrole_readonly（只读）"]
        RO1["可 SELECT 所有表"]
    end
    subgraph Offline["dbrole_offline（离线）"]
        OFF1["仅离线实例可用"]
    end

    Admin --> RW --> RO

解决的问题

• 生产账号天然拥有过高权限
• DDL 与 DML 不分离导致误操作风险

默认角色与系统用户

Pigsty 默认提供四个角色与四个系统用户（来自源码默认值）：

这套默认角色可以覆盖绝大多数业务场景。

默认权限策略

Pigsty 在初始化时写入默认权限（pg_default_privileges），确保新建对象自动具备合理权限。

解决的问题

• 新建对象未授权导致应用不可用
• 误授权给 PUBLIC 导致全库暴露

思路

• 只读角色：SELECT/EXECUTE
• 读写角色：INSERT/UPDATE/DELETE
• 管理员角色：DDL 权限

对象所有权与 DDL 规范

默认权限仅对“管理员角色创建的对象”自动生效。

这意味着：

• 必须使用 dbuser_dba/postgres 执行 DDL
• 或业务管理员先 SET ROLE dbrole_admin

否则新对象会脱离默认权限体系，破坏最小权限原则。

数据库隔离

数据库级别支持 revokeconn，可做到跨库隔离：

pg_databases:
  - { name: appdb, owner: dbuser_app, revokeconn: true }

解决的问题

• 一个账号可以“穿透”访问所有数据库
• 多租户数据库缺乏边界

公共权限收敛

Pigsty 初始化时撤销 public 模式的 CREATE 权限：

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

解决的问题

• 非授权用户随意创建对象
• “影子表/影子函数”带来的安全风险

离线角色的作用

dbrole_offline 只能访问离线实例（pg_role=offline 或 pg_offline_query=true）。

解决的问题

• ETL/分析任务影响生产性能
• 个人账号在主库执行高危查询

最佳实践

• 业务账号默认使用 dbrole_readwrite 或 dbrole_readonly。
• 生产 DDL 必须经由管理员角色。
• 多租户业务启用 revokeconn 隔离。
• 报表/ETL 使用 dbrole_offline。

接下来

• 🔑 身份认证：HBA 规则与密码策略
• 🔐 加密通信：TLS 与证书管理
• ✅ 合规清单：等保与 SOC2 对照

4 - 加密通信与本地 CA

加密通信解决三个问题：

• 窃听：防止明文流量被监听
• 篡改：防止中间人修改数据
• 冒充：防止服务端/客户端被伪造

Pigsty 通过 本地 CA + TLS 为数据库与基础设施组件提供统一的信任根。

本地 CA 的作用

Pigsty 默认会在管理节点生成自签 CA：

files/pki/ca/ca.key   # CA 私钥（必须严格保护）
files/pki/ca/ca.crt   # CA 根证书（可分发）

源码默认值：

• ca_create: true：找不到 CA 时自动生成。
• ca_cn: pigsty-ca：CA 证书 CN 固定为 pigsty-ca。
• 根证书有效期约 100 年（自签）。
• 由 CA 签发的服务器/客户端证书有效期 cert_validity: 7300d（20 年）。

证书覆盖范围

本地 CA 会签发多种组件证书，统一信任链：

解决的问题：不同组件自建证书会产生信任碎片，统一 CA 可以一次分发，多处复用。

信任分发

Pigsty 安装时会将 ca.crt 分发到所有节点并加入系统信任：

• 证书路径：/etc/pki/ca.crt
• EL 系列：/etc/pki/ca-trust/source/anchors/
• Debian/Ubuntu：/usr/local/share/ca-certificates/

这样可以让系统内的客户端自动信任 Pigsty 签发的证书。

使用外部 CA

如果你已有企业 CA，可以直接替换：

files/pki/ca/ca.key
files/pki/ca/ca.crt

建议设置：

ca_create: false

解决的问题：防止系统误生成新的自签 CA，导致证书信任链混乱。

客户端证书认证

证书认证可以替代或增强密码认证：

• 避免密码被钓鱼或泄露
• 证书可绑定设备与账号

Pigsty 自带 cert.yml 用于签发客户端证书：

./cert.yml -e cn=dbuser_dba
./cert.yml -e cn=dbuser_monitor

默认生成在：

files/pki/misc/<cn>.key
files/pki/misc/<cn>.crt

密钥保护与轮换

• CA 私钥默认 0600 权限，并在 0700 目录中保存。
• 一旦 CA 私钥泄露，必须重新生成 CA 并重签所有证书。
• 建议在重大升级或密钥泄露事件后进行证书轮换。

接下来

• 🔑 身份认证：HBA 与证书认证
• 👤 访问控制：角色与权限模型
• ✅ 合规清单：合规要求与证据准备

5 - 数据安全

数据安全关注三件事：完整性、可恢复性、保密性。Pigsty 在默认配置中已启用关键能力，并支持按需加固。

数据完整性

解决的问题

• 磁盘坏块、内存错误导致的静默损坏
• 意外写入导致的数据污染

Pigsty 支持

• 数据校验和：默认 pg_checksum: true，初始化时启用 data-checksums。
• 副本兜底：主库坏块可从从库恢复（与 HA 配合使用）。

可恢复性（备份与 PITR）

解决的问题

• 误删误改
• 灾难性故障导致数据丢失

Pigsty 支持

• pgBackRest 默认启用：pgbackrest_enabled: true。
• 本地仓库：默认保留 2 份完整备份。
• 远程仓库：可接入 MinIO，支持对象存储与多副本。
• PITR：结合 WAL 归档进行任意时间点恢复。

数据保密性

解决的问题

• 备份被窃导致数据外泄
• 介质被盗导致明文数据泄露

Pigsty 支持

• 备份加密：MinIO 仓库支持 AES-256-CBC（cipher_type）。
• 透明加密（可选）：通过 pg_tde 等扩展实现数据静态加密。
• 密钥隔离：建议将 cipher_pass 与 CA 私钥分离管理。

审计与可追溯

解决的问题

• 无法追责与还原操作
• 合规审计缺少证据

Pigsty 支持

• 日志收集：模板默认启用 logging_collector。
• DDL 审计：log_statement: ddl。
• 慢查询：log_min_duration_statement。
• 连接日志：log_connections（PG18+）。
• 审计扩展：pgaudit、pgauditlogtofile 可选。

加固建议

• 对远程备份强制加密与专用密钥。
• 定期演练 PITR，验证恢复链路。
• 对关键业务启用 pgaudit。
• 结合 高可用 形成“备份 + 副本”双层兜底。

接下来

• 🔐 加密通信：证书管理与 TLS
• ✅ 合规清单：审计与合规要求
• ⏰ 备份恢复：PITR 机制与实践

6 - 合规清单

合规不是“开关”，而是 配置 + 流程 + 证据 的组合：

• 配置：安全能力是否启用（HBA/TLS/审计/备份）
• 流程：是否有权限管理、变更、备份演练等制度
• 证据：日志、配置快照、备份报告、监控告警

本页以 SOC2 与等保三级为切入点，说明 Pigsty 的安全能力与合规映射。

默认凭证清单（必须修改）

来自源码默认值：

生产环境必须修改。

证据准备（建议）

SOC2 视角（示例映射）

SOC2 的核心是 安全、可用性、机密性。以下为常见控制点的概念映射：

以上为概念映射，实际 SOC2 需要配合组织制度与审计证据。

等保三级（GB/T 22239-2019）映射

等保三级关注“身份鉴别、访问控制、审计、数据安全、通信安全、主机安全、网络边界”等。以下为核心控制点与 Pigsty 能力的对应关系：

提示：等保三级不仅是技术问题，还需要完善的制度与运维流程支撑。

合规加固配置片段

# 强制 SSL / 证书
pg_hba_rules:
  - { user: '+dbrole_readonly', db: all, addr: intra, auth: ssl }
  - { user: dbuser_dba, db: all, addr: world, auth: cert }

# 密码强度
pg_libs: '$libdir/passwordcheck, pg_stat_statements, auto_explain'
pg_extensions: [ passwordcheck, credcheck ]

# PgBouncer / Patroni TLS
pgbouncer_sslmode: require
patroni_ssl_enabled: true

# 操作系统安全
node_firewall_mode: zone
node_selinux_mode: enforcing

合规检查清单

部署前

• 网络分区与可信 CIDR 明确
• 证书策略确定（自签/企业 CA）
• 账号权限分级方案明确

部署后（必做）

• 修改所有默认密码
• 验证 HBA 规则符合预期
• 启用并验证 TLS
• 配置审计与日志留存策略

定期维护

• 权限审计与账号清理
• 证书轮换
• 备份恢复演练

接下来

• 🔑 身份认证：HBA 与密码策略
• 🔒 数据安全：备份与加密
• ♾️ 高可用：业务连续性