安全合规

数据库通常是信息系统中最敏感的组件：它保存着最有价值的数据，也因此是攻击与故障后果最严重的地方。 数据库安全并不是某个可以一键开启的功能，而是一系列问题的答案之和：谁能连进来？连进来能做什么？流量会不会被窃听？操作有没有留痕？数据坏了、丢了、被删了，还能不能恢复？

Pigsty 把这些问题的答案沉淀为一套 开箱即用的安全基线，并用 声明式配置 的方式加以管理： HBA 规则、角色与权限、证书与加密、备份与审计策略，全部以 参数 的形式在 配置清单 中声明，由幂等剧本渲染落地。

这种 安全即代码（Security as Code）的做法本身就是一项重要的安全实践：安全策略可以被版本控制、评审与回溯，配置清单为多实例环境提供统一基线。 当审计者问“谁能访问这个数据库”时，可以先从一份可读的 YAML 声明出发，再用实际生成的 HBA 与数据库授权验证它是否已经生效。

安全即代码

在传统运维中，安全配置散落在各个角落：某台服务器上的 pg_hba.conf，某位 DBA 手工执行过的 GRANT 语句，某次应急时临时放开的防火墙规则。 时间一长，文档与实际状态容易出现偏差，也很难快速确认各实例正在使用哪一版规则。

Pigsty 的做法不同：安全策略是集群定义的一部分，与集群的其他属性写在一起。

pg-meta:
  hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } }
  vars:
    pg_cluster: pg-meta
    pg_users:                     # 谁可以登录：账号、角色与过期时间
      - { name: dbuser_app ,password: '<独立随机口令>' ,roles: [dbrole_readwrite] ,expire_in: 365 }
    pg_databases:                 # 数据库及其隔离策略
      - { name: app ,owner: dbuser_app ,revokeconn: true }
    pg_hba_rules:                 # 谁能从哪里、以何种方式连接
      - { user: dbuser_app ,db: app ,addr: 10.1.0.0/16 ,auth: ssl ,order: 50 ,title: 'app access via ssl' }

用户、权限、HBA 规则以声明的方式描述，剧本负责把它们幂等地应用到集群的每个实例上： 新加入的实例可以沿用同一套策略，git 提交历史也可以记录安全配置的变更。手工执行的 GRANT、运行时参数修改和节点文件变更仍可能造成漂移，因此生产环境还需要定期核对实际状态。

默认安全基线

合理的默认值可以减少遗漏。以下能力在 Pigsty 默认配置下即处于启用状态：

有所取舍的加固项

默认配置面向运行在受信内网中的部署，一部分安全能力需要显式启用 —— 它们或有性能与兼容性代价，或需要用户提供额外的决策：

• 默认配置与示例模板包含 文档公开的默认密码，方便快速上手与本地测试。生产部署应先用 ./configure -g 随机化其支持的凭据，再检查 pgBackRest 加密口令、ha/safe 中的 MinIO 用户和自定义值。
• Patroni REST API 与 PgBouncer 的 TLS 默认未启用（patroni_ssl_enabled、pgbouncer_sslmode），可以使用已经签发的证书显式开启。
• 密码强度检查（passwordcheck）与 审计扩展（pgaudit）默认未启用；使用前应确认软件包可用，再完成预加载与策略配置。
• SELinux 默认处于 permissive 模式；演示配置的防火墙额外放行了 5432 端口，生产环境应当移除。
• 本地备份仓库默认 不加密；MinIO 备份仓库默认启用 AES-256 加密，但需要修改默认加密口令。

安全加固模板 ha/safe 将 TLS、证书认证、密码检查和备份加密等配置组合在一起， 并配合面向一致性优先业务的 CRIT 参数模板 给出一份可直接修改的示例。模板中的公开凭据、审计扩展与故障模型仍需逐项确认。 完整的升级路径见 安全模型。

本章内容

相关话题

概念层之外，以下页面提供操作层面的安全内容：

• 🔰 安全建议：单机快速上手场景的最小加固动作
• 🛡️ 安全考量：生产部署的安全加固检查清单
• 📄 ha/safe 模板：安全加固配置模板完整参考
• 🔑 HBA 规则：PGSQL 模块 HBA 配置详解
• 👤 访问控制：角色与权限参数参考
• ♾️ 高可用：业务连续性保障
• ⏰ 时间点恢复：PITR 原理与灾难恢复；操作见 PGSQL 备份恢复