这是本节的多页打印视图。点击此处打印.

安全合规

身份认证、访问控制、加密通信、审计日志，满足等保三级与 SOC2 合规要求。

1: 本地 CA
2: 七层安全模型
3: 访问控制

Pigsty 的安全理念

默认安全：开箱即用的安全配置，无需额外设置即可获得基本保护。

渐进配置：企业级用户可根据需求，通过配置逐步增强安全措施。

纵深防御：多层安全机制，即使某一层被突破，仍有其他层保护。

最小权限：只授予用户完成任务所需的最低权限，降低风险。

概览

加密备份一应俱全，只要硬件与密钥安全，您无需操心数据库的安全性。

Pigsty 针对高标准，严要求的企业级场景设计，采用业界领先的安全最佳实践保护您的数据安全（机密性/完整性/可用性），默认配置下的安全性便足以满足绝大多数场景下的合规要求。

Pigsty 会创建自签名的 CA （或使用您提供的 CA）签发证书，加密网络通信。需要保护的敏感管理页面与API端点都受到密码保护。数据库备份使用 AES 算法加密，数据库密码使用 scram-sha-256 算法加密，并提供插件强制执行密码强度策略。 Pigsty 提供了一套开箱即用，简单易用，便于扩展的 ACL 模型，提供读/写/管理/ETL 的权限区分，并带有遵循最小权限原则的 HBA 规则集，通过多重防护确保系统机密性。

Pigsty 默认启用数据库校验和避免静默数据腐坏，通过从库副本提供坏块兜底。提供 CRIT 数据零丢失配置模板，使用 watchdog 确保为高可用 Fencing 兜底。您可以通过 audit 插件审计数据库操作，系统与数据库日志全部收集备查，以满足合规要求。

Pigsty 正确配置 SELinux 与防火墙配置，并遵循最小权限原则设计操作系统用户组与文件权限，确保系统安全基线符合合规要求。而且在 Etcd，MinIO 等附属可选组件上的安全上也毫不妥协，etcd 与 minio 均使用 RBAC 模型与 TLS 加密通信，确保系统整体安全性。

只要您遵循安全性最佳实践，内网部署并合理配置安全组与防火墙，合理配置的系统通过各种合规检查毫无问题。

默认安全配置

Pigsty 默认启用以下安全特性：

特性	默认配置	说明
密码加密	`scram-sha-256`	PostgreSQL 最安全的密码哈希算法
SSL 支持	启用	客户端可选择使用 SSL 加密连接
本地 CA	自动生成	自签名 CA 签发服务器证书
HBA 分层	按来源控制	不同来源使用不同认证强度
角色系统	四层权限	只读/读写/管理员/离线
数据校验	启用	检测存储层数据损坏
审计日志	启用	记录连接和慢查询

可增强配置

通过额外配置可启用更高安全级别：

特性	配置方式	安全等级
密码强度检查	启用 `passwordcheck` 扩展	等保三级
强制 SSL	HBA 使用 `hostssl`	等保三级
客户端证书	HBA 使用 `cert` 认证	金融级
备份加密	配置 `cipher_type`	合规要求
防火墙	配置 `node_firewall_mode`	基础设施

如果您只有一分钟，请记住这张图：

flowchart TB
    subgraph L1["🌐 第 1 层：网络安全"]
        L1A["防火墙 + SSL/TLS 加密 + HAProxy 代理"]
        L1B["谁能连进来？连接是否加密？"]
    end

    subgraph L2["🔑 第 2 层：身份认证"]
        L2A["HBA 规则 + SCRAM-SHA-256 密码 + 证书认证"]
        L2B["你是谁？怎么证明？"]
    end

    subgraph L3["👤 第 3 层：访问控制"]
        L3A["角色系统 + 对象权限 + 数据库隔离"]
        L3B["你能做什么？能访问哪些数据？"]
    end

    subgraph L4["🔒 第 4 层：数据安全"]
        L4A["数据校验 + 备份加密 + 审计日志"]
        L4B["数据完整吗？操作有记录吗？"]
    end

    L1 --> L2 --> L3 --> L4

核心价值：开箱即用的企业级安全配置，默认启用最佳实践，额外配置可达等保三级与 SOC 2 合规要求。

本章内容

章节	说明	核心问题
安全概述	安全能力总览与检查清单	整体安全架构是怎样的？
身份认证	HBA 规则、密码策略、证书认证	如何验证用户身份？
访问控制	角色系统、权限模型、数据库隔离	如何控制用户权限？
加密通信	SSL/TLS、本地 CA、证书管理	如何保护数据传输？
合规清单	等保三级与 SOC2 详细对照	如何满足合规要求？

为什么安全很重要？

数据泄露的代价

flowchart LR
    Breach["💥 数据泄露"]

    subgraph Direct["💰 直接损失"]
        D1["监管罚款<br/>GDPR 可达全球营收 4%"]
        D2["法律诉讼费用"]
        D3["客户赔偿"]
    end

    subgraph Indirect["📉 间接损失"]
        I1["品牌声誉受损"]
        I2["客户信任丧失"]
        I3["业务中断"]
    end

    subgraph Compliance["⚠️ 合规风险"]
        C1["等保三级：责任追究"]
        C2["SOC 2：认证撤销"]
        C3["行业准入：被禁止经营"]
    end

    Breach --> Direct
    Breach --> Indirect
    Breach --> Compliance

默认用户与密码

Pigsty 默认创建以下系统用户：

用户	用途	默认密码	部署后操作
`postgres`	系统超级用户	无密码（仅本地）	保持无密码
`dbuser_dba`	管理员用户	`DBUser.DBA`	必须修改
`dbuser_monitor`	监控用户	`DBUser.Monitor`	必须修改
`replicator`	复制用户	`DBUser.Replicator`	必须修改

# pigsty.yml - 修改默认密码
pg_admin_password: 'YourSecurePassword123!'
pg_monitor_password: 'AnotherSecurePass456!'
pg_replication_password: 'ReplicationPass789!'

⚠️ 重要：生产环境部署后，请立即修改这些默认密码！

角色与权限系统

Pigsty 提供开箱即用的四层角色系统：

flowchart TB
    subgraph Admin["🔴 dbrole_admin（管理员）"]
        A1["继承 dbrole_readwrite"]
        A2["可以创建/删除/修改对象 DDL"]
        A3["适用于：业务管理员、需要建表的应用"]
    end

    subgraph RW["🟡 dbrole_readwrite（读写）"]
        RW1["继承 dbrole_readonly"]
        RW2["可以 INSERT/UPDATE/DELETE"]
        RW3["适用于：生产业务账号"]
    end

    subgraph RO["🟢 dbrole_readonly（只读）"]
        RO1["可以 SELECT 所有表"]
        RO2["适用于：报表查询、数据分析"]
    end

    subgraph Offline["🔵 dbrole_offline（离线）"]
        OFF1["只能访问离线实例"]
        OFF2["适用于：ETL、个人分析、慢查询"]
    end

    Admin --> |继承| RW
    RW --> |继承| RO

创建业务用户

pg_users:
  # 只读用户 - 用于报表查询
  - name: dbuser_report
    password: ReportUser123
    roles: [dbrole_readonly]
    pgbouncer: true

  # 读写用户 - 用于生产业务
  - name: dbuser_app
    password: AppUser456
    roles: [dbrole_readwrite]
    pgbouncer: true

  # 管理员用户 - 用于 DDL 操作
  - name: dbuser_admin
    password: AdminUser789
    roles: [dbrole_admin]
    pgbouncer: true

HBA 访问控制

HBA（Host-Based Authentication）控制"谁可以从哪里连接"：

flowchart LR
    subgraph Sources["连接来源"]
        S1["🏠 本地 Socket"]
        S2["💻 localhost"]
        S3["🏢 内网 CIDR"]
        S4["🛡️ 管理节点"]
        S5["🌐 外网"]
    end

    subgraph Auth["认证方式"]
        A1["ident/peer<br/>OS 用户映射，最安全"]
        A2["scram-sha-256<br/>密码认证"]
        A3["scram-sha-256 + SSL<br/>强制 SSL"]
    end

    S1 --> A1
    S2 --> A2
    S3 --> A2
    S4 --> A3
    S5 --> A3

    Note["📋 规则按顺序匹配<br/>第一条匹配的规则生效"]

自定义 HBA 规则

pg_hba_rules:
  # 允许应用服务器从内网连接
  - {user: dbuser_app, db: mydb, addr: '10.10.10.0/24', auth: scram-sha-256}

  # 强制某些用户使用 SSL
  - {user: admin, db: all, addr: world, auth: ssl}

  # 要求证书认证（最高安全级别）
  - {user: secure_user, db: all, addr: world, auth: cert}

加密通信

SSL/TLS 架构

sequenceDiagram
    participant Client as 🖥️ 客户端
    participant Server as 🐘 PostgreSQL

    Client->>Server: 1. ClientHello
    Server->>Client: 2. ServerHello
    Server->>Client: 3. 服务器证书
    Client->>Server: 4. 客户端密钥
    Client->>Server: 5. 加密通道建立
    Server->>Client: 5. 加密通道建立

    rect rgb(200, 255, 200)
        Note over Client,Server: 🔒 加密数据传输
        Client->>Server: 6. 应用数据（加密）
        Server->>Client: 6. 应用数据（加密）
    end

    Note over Client,Server: ✅ 防止窃听 ✅ 防止篡改 ✅ 验证服务器身份

本地 CA

Pigsty 自动生成本地 CA 并签发证书：

/etc/pki/
├── ca.crt              # CA 证书（公开）
├── ca.key              # CA 私钥（保密！）
└── server.crt/key      # 服务器证书/私钥

⚠️ 重要：请安全备份 ca.key，丢失后需要重新签发所有证书！

合规对照

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

安全要求	Pigsty 默认	可配置达到	说明
身份鉴别唯一性	✅	✅	每个用户唯一标识
口令复杂度	⚠️	✅	启用 passwordcheck
口令定期更换	⚠️	✅	需要运维流程
双因素认证	⚠️	✅	证书 + 密码
访问控制	✅	✅	HBA + 角色系统
最小权限原则	✅	✅	四层角色模型
通信加密	✅	✅	SSL/TLS
审计日志	✅	✅	连接日志 + 慢查询
数据完整性	✅	✅	数据校验和
备份恢复	✅	✅	pgBackRest

SOC 2 Type II

控制点	Pigsty 支持	说明
CC6.1 逻辑访问控制	✅	HBA + 角色系统
CC6.6 传输加密	✅	SSL/TLS
CC7.2 系统监控	✅	Prometheus + Grafana
CC9.1 业务连续性	✅	高可用 + PITR
A1.2 数据恢复	✅	pgBackRest 备份

图例：✅ 默认满足 · ⚠️ 需要额外配置

安全检查清单

部署前

准备强密码（使用密码管理器生成）
规划网络分区（内网/外网 CIDR）
确定 SSL 策略（自签名/外部 CA）

部署后（必做）

修改所有默认密码
验证 HBA 规则符合预期
测试 SSL 连接正常
配置认证失败告警
安全备份 CA 私钥

定期维护

审计用户权限
检查过期账户
更新证书（如需要）
检查审计日志

快速配置示例

生产环境安全配置

# pigsty.yml - 生产环境安全配置示例
all:
  vars:
    # 修改默认密码（必须！）
    pg_admin_password: 'SecureDBAPassword2024!'
    pg_monitor_password: 'SecureMonitorPass2024!'
    pg_replication_password: 'SecureReplPass2024!'

    # 启用密码强度检查
    pg_libs: 'passwordcheck, pg_stat_statements, auto_explain'

    # 自定义 HBA 规则
    pg_hba_rules:
      # 应用服务器
      - {user: app, db: appdb, addr: '10.10.10.0/24', auth: scram-sha-256}
      # 管理员强制 SSL
      - {user: dbuser_dba, db: all, addr: world, auth: ssl}

金融级安全配置

# 金融级配置 - 启用证书认证
pg_hba_rules:
  # 交易系统使用证书认证
  - {user: trade_user, db: trade, addr: world, auth: cert}
  # 其他系统使用 SSL + 密码
  - {user: all, db: all, addr: world, auth: ssl}

# 启用备份加密
pgbackrest_repo:
  minio:
    cipher_type: aes-256-cbc
    cipher_pass: 'YourBackupEncryptionKey'

接下来

深入了解安全配置的细节：

👁️ 安全概述：整体安全架构与检查清单
🔑 身份认证：HBA 规则与密码策略
👤 访问控制：角色系统与权限模型
🔐 加密通信：SSL/TLS 与证书管理
✅ 合规清单：等保三级与 SOC2 详细对照

1 - 本地 CA

Pigsty 带有一套自签名的 CA 公私钥基础设施，用于签发 SSL 证书，加密网络通信流量。

Pigsty 部署默认启用了一些安全最佳实践：使用 SSL 加密网络流量，使用 HTTPS 加密 Web 界面。

为了实现这一功能，Pigsty 内置了本地自签名的 CA ，用于签发 SSL 证书，加密网络通信流量。

在默认情况下，SSL 与 HTTPS 是启用，但不强制使用的。对于有着较高安全要求的环境，您可以强制使用 SSL 与 HTTPS。

本地CA

Pigsty 默认会在初始化时，在 ADMIN节点 本机 Pigsty 源码目录（~/pigsty）中生成一个自签名的 CA。当您需要使用 SSL，HTTPS，数字签名，签发数据库客户端证书，高级安全特性时，可以使用此 CA。

每一套 Pigsty 部署使用的 CA 都是唯一的，不同的 Pigsty 部署之间的 CA 是不相互信任的。

本地 CA 由两个文件组成，默认放置于 files/pki/ca 目录中：

ca.crt：自签名的 CA 根证书，应当分发安装至到所有纳管节点，用于证书验证。
ca.key：CA 私钥，用于签发证书，验证 CA 身份，应当妥善保管，避免泄漏！

请保护好CA私钥文件

请妥善保管 CA 私钥文件，不要遗失，不要泄漏。我们建议您在完成 Pigsty 安装后及时备份此文件。

使用现有CA

如果您本身已经有 CA 公私钥基础设施，Pigsty 也可以配置为使用现有 CA 。

在执行部署前，将您的 CA 公钥与私钥文件放置于 files/pki/ca 目录中即可，并使用以下名称。

files/pki/ca/ca.key     # 核心的 CA 私钥文件，必须存在，如果不存在，默认会重新随机生成一个
files/pki/ca/ca.crt     # 如果没有证书文件，Pigsty会自动重新从 CA 私钥生成新的根证书文件

当 Pigsty 执行 deploy.yml 与 infra.yml 剧本进行安装时，如果发现 files/pki/ca 目录中的 ca.key 私钥文件存在，则会使用已有的 CA 。ca.crt 文件可以从 ca.key 私钥文件生成，所以如果没有证书文件，Pigsty 会自动重新从 CA 私钥生成新的根证书文件。

使用现有CA时请注意

您可以将 ca_method 参数配置为 copy，确保 Pigsty 找不到本地 CA 时报错中止，而不是自行重新生成新的自签名 CA。

信任CA

在 Pigsty 安装过程中，ca.crt 会在 node.yml 剧本的 node_ca 任务中，被分发至所有节点上的 /etc/pki/ca.crt 路径下。

EL系操作系统与 Debian系操作系统默认信任的 CA 根证书路径不同，因此分发的路径与更新的方式也不同。

rm -rf /etc/pki/ca-trust/source/anchors/ca.crt
ln -s /etc/pki/ca.crt /etc/pki/ca-trust/source/anchors/ca.crt
/bin/update-ca-trust

rm -rf /usr/local/share/ca-certificates/ca.crt
ln -s /etc/pki/ca.crt /usr/local/share/ca-certificates/ca.crt
/usr/sbin/update-ca-certificates

Pigsty 默认会为基础设施节点上的 Web 系统使用的域名签发 HTTPS 证书，您可以 HTTPS 访问 Pigsty 的 Web 系统。如果您希望在客户端电脑上浏览器访问时不要弹出“不受信任的 CA 证书”信息，可以将 ca.crt 分发至客户端电脑的信任证书目录中。

您可以双击 ca.crt 文件将其加入系统钥匙串，例如在 MacOS 系统中，需要打开“钥匙串访问” 搜索 pigsty-ca 然后“信任”此根证书

查看证书内容

使用以下命令，可以查阅 Pigsty CA 证书的内容

openssl x509 -text -in /etc/pki/ca.crt

本地 CA 根证书内容样例

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            50:29:e3:60:96:93:f4:85:14:fe:44:81:73:b5:e1:09:2a:a8:5c:0a
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=pigsty, OU=ca, CN=pigsty-ca
        Validity
            Not Before: Feb  7 00:56:27 2023 GMT
            Not After : Jan 14 00:56:27 2123 GMT
        Subject: O=pigsty, OU=ca, CN=pigsty-ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:c1:41:74:4f:28:c3:3c:2b:13:a2:37:05:87:31:
                    ....
                    e6:bd:69:a5:5b:e3:b4:c0:65:09:6e:84:14:e9:eb:
                    90:f7:61
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
                DNS:pigsty-ca
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:1
            X509v3 Subject Key Identifier: 
                C5:F6:23:CE:BA:F3:96:F6:4B:48:A5:B1:CD:D4:FA:2B:BD:6F:A6:9C
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        89:9d:21:35:59:6b:2c:9b:c7:6d:26:5b:a9:49:80:93:81:18:
        ....
        9e:dd:87:88:0d:c4:29:9e
-----BEGIN CERTIFICATE-----
...
cXyWAYcvfPae3YeIDcQpng==
-----END CERTIFICATE-----

签发证书

如果您希望通过客户端证书认证，那么可以使用本地 CA 与 cert.yml 剧本手工签发PostgreSQL 客户端证书。

将证书的 CN 字段设置为数据库用户名即可：

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

签发的证书会默认生成在 files/pki/misc/<cn>.{key,crt} 路径下。

2 - 七层安全模型

Pigsty 如何在七个安全层次上提供纵深防御，从物理安全到用户安全。

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

概览

物理安全

物理访问失守，则其他层形同虚设。

物理安全是最基础的一层，涉及机房门禁、监控、环境控制、设备防盗、电力保障等。Pigsty 作为软件解决方案，在物理层面提供以下保护机制：

数据校验和

启用数据校验和可以检测存储层的静默数据损坏（如磁盘坏块、内存错误、固件 Bug）：

pg_checksum: true  # v3.5+ 默认启用

原理：PostgreSQL 在每个数据页写入时计算校验和，读取时验证。发现损坏时报错而非返回错误数据。

兜底机制：从库副本提供坏块兜底，主库数据页损坏时可从从库恢复。

透明数据加密

对于有合规要求的场景，可使用 PGTDE（PostgreSQL Transparent Data Encryption）扩展：

pg_extensions:
  - pg_tde  # 透明数据加密扩展

效果：数据在磁盘上以加密形式存储，即使物理介质被盗也无法读取数据。

网络安全

控制数据包层面的访问和过滤。

防火墙

Pigsty 支持节点级防火墙配置，控制哪些端口对外开放：

node_firewall_mode: zone       # off | none | zone
node_firewall_intranet:        # 内网 CIDR（信任区域）
  - 10.0.0.0/8
  - 172.16.0.0/12
  - 192.168.0.0/16
node_firewall_public_port:     # 公网开放端口
  - 22    # SSH
  - 80    # HTTP
  - 443   # HTTPS

三种模式：

模式	说明	适用场景
`off`	不配置防火墙（默认）	开发环境、已有安全组
`none`	禁用 firewalld	使用外部防火墙
`zone`	区域模式：内网信任，公网受限	生产环境推荐

SSL/TLS 加密

Pigsty 在多个层次提供 SSL/TLS 加密：

组件	参数	默认值	说明
PostgreSQL	HBA `auth`	`pwd`	支持 `ssl`（强制）、`cert`（证书）
Pgbouncer	`pgbouncer_sslmode`	`disable`	可选 `require` / `verify-full`
Patroni	`patroni_ssl_enabled`	`false`	REST API 加密
Nginx	`nginx_sslmode`	`enable`	可选 `enforce`（强制 HTTPS）
MinIO	默认启用	启用	使用本地 CA 证书
etcd	默认启用	启用	TLS 加密通信

安全加固配置：

patroni_ssl_enabled: true    # 启用 Patroni SSL
pgbouncer_sslmode: require   # 强制 Pgbouncer SSL
nginx_sslmode: enforce       # 强制 HTTPS

本地 CA 证书基础设施

Pigsty 自动生成本地 CA 并签发证书，无需购买商业证书：

files/pki/ca/
├── ca.crt              # CA 证书（公开，分发到所有节点）
└── ca.key              # CA 私钥（⚠️ 保密！安全备份！）

/etc/pki/               # 节点上的证书目录
├── ca.crt              # CA 证书
├── server.crt          # 服务器证书
└── server.key          # 服务器私钥

⚠️ 重要：请安全备份 ca.key，丢失后需要重新签发所有证书！

边界安全

处理内外网交界处的安全策略。

HAProxy 安全

HAProxy 作为数据库流量的统一入口，提供以下安全功能：

haproxy_admin_password: 'StrongPassword123'  # 管理界面密码

安全特性：

健康检查与流量控制，避免脑裂
连接限制与速率限制
管理界面密码保护

Nginx 安全

Nginx 作为 Web 服务的统一网关，提供：

nginx_sslmode: enforce  # 强制 HTTPS
infra_portal:           # 配置各组件域名
  grafana: { domain: g.pigsty.cc }
  alertmanager: { domain: a.pigsty.cc }

安全特性：

统一的 HTTPS 入口，便于审计
反向代理保护后端服务
可集成外部认证（OAuth、LDAP）

主机安全

操作系统加固、补丁管理、最小化安装。

SELinux 配置

Pigsty 正确配置 SELinux 策略，确保 PostgreSQL 等服务正常运行：

node_selinux_mode: permissive  # disabled | permissive | enforcing

模式	说明	适用场景
`disabled`	完全禁用	开发环境
`permissive`	宽容模式（记录但不阻止）	生产环境推荐
`enforcing`	强制模式	高安全要求环境

操作系统加固

Pigsty 遵循最小权限原则设计：

文件权限：敏感文件（如 CA 私钥）权限严格控制
用户组：PostgreSQL、etcd 等服务使用专用用户运行
管理员配置：

node_admin_username: dba        # 管理员用户名
node_admin_sudo: nopasswd       # sudo 策略

系统更新

保持关键安全组件更新：

openssh：SSH 服务
ca-certificates：系统根证书
openssl：加密库

应用安全

数据库配置、认证授权、输入验证。

密码策略

密码加密算法

pg_pwd_enc: scram-sha-256  # 最安全的密码哈希算法

算法	安全性	兼容性	说明
`scram-sha-256`	⭐⭐⭐	PostgreSQL 10+	推荐，默认值
`md5`	⭐	所有版本	仅用于老旧客户端

密码强度检查

启用 passwordcheck 扩展强制密码复杂度：

pg_libs: '$libdir/passwordcheck, pg_stat_statements, auto_explain'
pg_extensions:
  - passwordcheck  # 强制密码复杂度
  - credcheck      # 额外的密码检查

密码过期

pg_users:
  - { name: dbuser_app, password: 'SecurePass123', expire_in: 365 }  # 1年后过期

HBA 规则

HBA（Host-Based Authentication）控制"谁可以从哪里连接，使用什么方式认证"：

pg_default_hba_rules:
  - {user: '${dbsu}'     ,db: all         ,addr: local     ,auth: ident ,title: 'dbsu local via ident'}
  - {user: '${dbsu}'     ,db: replication ,addr: local     ,auth: ident ,title: 'dbsu repl via ident'}
  - {user: '${repl}'     ,db: replication ,addr: localhost ,auth: pwd   ,title: 'repl via localhost'}
  - {user: '${repl}'     ,db: replication ,addr: intra     ,auth: pwd   ,title: 'repl from intranet'}
  - {user: '${repl}'     ,db: postgres    ,addr: intra     ,auth: pwd   ,title: 'repl from intranet'}
  - {user: '${monitor}'  ,db: all         ,addr: localhost ,auth: pwd   ,title: 'monitor via localhost'}
  - {user: '${monitor}'  ,db: all         ,addr: infra     ,auth: pwd   ,title: 'monitor from infra'}
  - {user: '${admin}'    ,db: all         ,addr: infra     ,auth: ssl   ,title: 'admin from infra'}
  - {user: '${admin}'    ,db: all         ,addr: world     ,auth: ssl   ,title: 'admin from world'}
  - {user: '+dbrole_readonly',db: all     ,addr: localhost ,auth: pwd   ,title: 'read from localhost'}
  - {user: '+dbrole_readonly',db: all     ,addr: intra     ,auth: pwd   ,title: 'read from intranet'}
  - {user: '+dbrole_offline' ,db: all     ,addr: intra     ,auth: pwd   ,title: 'offline from intranet'}

认证方式：

别名	说明	安全等级
`ident/peer`	OS 用户映射	⭐⭐⭐ 仅本地
`pwd`	密码认证（scram-sha-256）	⭐⭐
`ssl`	强制 SSL + 密码	⭐⭐⭐
`cert`	客户端证书认证	⭐⭐⭐⭐ 最高
`deny`	拒绝访问	-

监听地址

限制 PostgreSQL 监听的网络接口：

pg_listen: '${ip},${vip},${lo}'  # 仅监听特定 IP，而非 0.0.0.0

数据安全

加密、备份、审计、完整性保护。

备份加密

pgBackRest 支持 AES-256 加密备份：

pgbackrest_repo:
  minio:
    cipher_type: aes-256-cbc           # AES-256-CBC 加密
    cipher_pass: 'pgBR.${pg_cluster}'  # 使用集群名作为密码一部分

效果：备份文件在存储中以加密形式保存，即使存储被入侵也无法读取数据。

审计日志

PostgreSQL 审计扩展

pg_extensions:
  - pgaudit           # SQL 审计日志
  - pgauditlogtofile  # 审计日志写入文件
  - pg_auth_mon       # 认证监控
  - pg_auditor        # 审计辅助

连接日志

# 在 pg_parameters 中配置
log_connections: on        # 记录连接建立
log_disconnections: on     # 记录连接断开

慢查询日志

log_min_duration_statement: 1000  # 记录 >1s 的查询

时间点恢复（PITR）

Pigsty 默认配置 pgBackRest 支持时间点恢复：

pgbackrest_enabled: true
pgbackrest_repo:
  local:                           # 本地备份
    path: /pg/backup
    retention_full: 2
  minio:                           # 远程备份
    path: /pgbackrest
    retention_full_type: time
    retention_full: 14             # 保留 14 天

用户安全

身份认证、权限管理、行为审计。

四角色模型

Pigsty 提供开箱即用的四层权限角色：

flowchart TB
    subgraph Admin["🔴 dbrole_admin（管理员）"]
        A1["继承 dbrole_readwrite"]
        A2["可以 CREATE/DROP/ALTER（DDL）"]
        A3["适用于：业务管理员、建表应用"]
    end
    subgraph RW["🟡 dbrole_readwrite（读写）"]
        RW1["继承 dbrole_readonly"]
        RW2["可以 INSERT/UPDATE/DELETE"]
        RW3["适用于：生产业务账号"]
    end
    subgraph RO["🟢 dbrole_readonly（只读）"]
        RO1["可以 SELECT 所有表"]
        RO2["适用于：报表查询、数据分析"]
    end
    subgraph Offline["🔵 dbrole_offline（离线）"]
        OFF1["只能访问离线实例"]
        OFF2["适用于：ETL、慢查询、个人分析"]
    end

    Admin --> |继承| RW
    RW --> |继承| RO

创建业务用户：

pg_users:
  - { name: dbuser_report, password: 'ReportPass123', roles: [dbrole_readonly] }
  - { name: dbuser_app, password: 'AppPass456', roles: [dbrole_readwrite] }
  - { name: dbuser_admin, password: 'AdminPass789', roles: [dbrole_admin] }

默认用户与密码

用户	默认密码	用途	部署后操作
`postgres`	无密码（仅本地）	系统超级用户	保持无密码
`dbuser_dba`	`DBUser.DBA`	管理员用户	必须修改
`dbuser_monitor`	`DBUser.Monitor`	监控用户	必须修改
`replicator`	`DBUser.Replicator`	复制用户	必须修改

自动生成强密码：

./configure -g  # 自动生成随机强密码

证书认证

最高安全级别，要求客户端提供有效证书：

pg_hba_rules:
  - {user: admin, db: all, addr: world, auth: cert}  # 管理员使用证书认证

ETCD 与 MinIO 安全

附属组件同样采用 RBAC 模型与 TLS 加密：

# ETCD
etcd_root_password: 'Etcd.Root.Strong'  # 必须修改

# MinIO
minio_access_key: minioadmin
minio_secret_key: 'S3User.MinIO.Strong'  # 必须修改
minio_users:
  - { access_key: pgbackrest, secret_key: 'Min10.bAckup', policy: readwrite }
  - { access_key: dba, secret_key: 'S3User.DBA.Strong', policy: consoleAdmin }

Watchdog 防护

防止脑裂，确保故障切换时主库强制关机：

patroni_watchdog_mode: required  # off | automatic | required

效果：当 Patroni 进程异常时，watchdog 强制重启节点，避免双主脑裂。

合规对照

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

安全要求	Pigsty 默认	可配置达到	实现方式
身份鉴别唯一性	✅	✅	用户名唯一标识
口令复杂度	⚠️	✅	`passwordcheck` 扩展
口令定期更换	⚠️	✅	`expire_in` 属性
双因素认证	⚠️	✅	证书 + 密码 (`auth: cert`)
访问控制	✅	✅	HBA + 四层角色模型
最小权限原则	✅	✅	`dbrole_readonly/readwrite/admin`
通信加密	✅	✅	SSL/TLS
审计日志	✅	✅	`pgaudit` + 连接日志
数据完整性	✅	✅	`pg_checksum: true`
备份恢复	✅	✅	pgBackRest + PITR

SOC 2 Type II

控制点	Pigsty 支持	实现方式
CC6.1 逻辑访问控制	✅	HBA + RBAC
CC6.6 传输加密	✅	SSL/TLS（可强制）
CC7.2 系统监控	✅	Prometheus + Grafana
CC9.1 业务连续性	✅	高可用 + PITR
A1.2 数据恢复	✅	pgBackRest 备份

图例：✅ 默认满足 · ⚠️ 需要额外配置

安全检查清单

部署前

准备强密码（使用 ./configure -g 自动生成）
规划网络分区（内网/外网 CIDR）
确定 SSL 策略（自签名 CA 或外部 CA）
确定是否启用防火墙

部署后（必做）

修改所有默认密码
验证 HBA 规则符合预期
测试 SSL 连接正常
配置认证失败告警
安全备份 CA 私钥

增强安全（可选）

启用 passwordcheck 扩展
强制 SSL（pgbouncer_sslmode: require）
启用证书认证（auth: cert）
启用 pgaudit 审计日志
启用备份加密
启用 Patroni SSL
启用 watchdog
配置防火墙规则
启用 SELinux 强制模式

接下来

深入了解安全配置的细节：

👤 访问控制：角色系统与权限模型
🔐 加密通信：SSL/TLS 与证书管理

3 - 访问控制

Pigsty 提供了标准的安全实践：密码与证书认证，开箱即用的权限模型，SSL加密网络流量，加密远程冷备份等。

Pigsty 提供了一套开箱即用的，基于角色系统和权限系统的访问控制模型。

权限控制很重要，但很多用户做不好。因此 Pigsty 提供了一套开箱即用的精简访问控制模型，为您的集群安全性提供一个兜底。

角色系统

Pigsty 默认的角色系统包含四个默认角色和四个默认用户：

角色名称	属性	所属	描述
`dbrole_readonly`	`NOLOGIN`		角色：全局只读访问
`dbrole_readwrite`	`NOLOGIN`	dbrole_readonly	角色：全局读写访问
`dbrole_admin`	`NOLOGIN`	pg_monitor,dbrole_readwrite	角色：管理员/对象创建
`dbrole_offline`	`NOLOGIN`		角色：受限的只读访问
`postgres`	`SUPERUSER`		系统超级用户
`replicator`	`REPLICATION`	pg_monitor,dbrole_readonly	系统复制用户
`dbuser_dba`	`SUPERUSER`	dbrole_admin	pgsql 管理用户
`dbuser_monitor`		pg_monitor	pgsql 监控用户

这些角色与用户的详细定义如下所示：

pg_default_roles:                 # 全局默认的角色与系统用户
  - { name: dbrole_readonly  ,login: false ,comment: role for global read-only access     }
  - { name: dbrole_offline   ,login: false ,comment: role for restricted read-only access }
  - { name: dbrole_readwrite ,login: false ,roles: [dbrole_readonly] ,comment: role for global read-write access }
  - { name: dbrole_admin     ,login: false ,roles: [pg_monitor, dbrole_readwrite] ,comment: role for object creation }
  - { name: postgres     ,superuser: true  ,comment: system superuser }
  - { name: replicator ,replication: true  ,roles: [pg_monitor, dbrole_readonly] ,comment: system replicator }
  - { name: dbuser_dba   ,superuser: true  ,roles: [dbrole_admin]  ,pgbouncer: true ,pool_mode: session, pool_connlimit: 16 ,comment: pgsql admin user }
  - { name: dbuser_monitor ,roles: [pg_monitor] ,pgbouncer: true ,parameters: {log_min_duration_statement: 1000 } ,pool_mode: session ,pool_connlimit: 8 ,comment: pgsql monitor user }

默认角色

Pigsty 中有四个默认角色：

业务只读 (dbrole_readonly): 用于全局只读访问的角色。如果别的业务想要此库只读访问权限，可以使用此角色。
业务读写 (dbrole_readwrite): 用于全局读写访问的角色，主属业务使用的生产账号应当具有数据库读写权限
业务管理员 (dbrole_admin): 拥有DDL权限的角色，通常用于业务管理员，或者需要在应用中建表的场景（比如各种业务软件）
离线只读访问 (dbrole_offline): 受限的只读访问角色（只能访问 offline 实例，通常是个人用户，ETL工具账号）

默认角色在 pg_default_roles 中定义，除非您确实知道自己在干什么，建议不要更改默认角色的名称。

- { name: dbrole_readonly  , login: false , comment: role for global read-only access  }                            # 生产环境的只读角色
- { name: dbrole_offline ,   login: false , comment: role for restricted read-only access (offline instance) }      # 受限的只读角色
- { name: dbrole_readwrite , login: false , roles: [dbrole_readonly], comment: role for global read-write access }  # 生产环境的读写角色
- { name: dbrole_admin , login: false , roles: [pg_monitor, dbrole_readwrite] , comment: role for object creation } # 生产环境的 DDL 更改角色

默认用户

Pigsty 也有四个默认用户（系统用户）：

超级用户 (postgres)，集群的所有者和创建者，与操作系统 dbsu 名称相同。
复制用户 (replicator)，用于主-从复制的系统用户。
监控用户 (dbuser_monitor)，用于监控数据库和连接池指标的用户。
管理用户 (dbuser_dba)，执行日常操作和数据库更改的管理员用户。

这4个默认用户的用户名/密码通过4对专用参数进行定义，并在很多地方引用：

pg_dbsu：操作系统 dbsu 名称，默认为 postgres，最好不要更改它
pg_dbsu_password：dbsu 密码，默认为空字符串意味着不设置 dbsu 密码，最好不要设置。
pg_replication_username：postgres 复制用户名，默认为 replicator
pg_replication_password：postgres 复制密码，默认为 DBUser.Replicator
pg_admin_username：postgres 管理员用户名，默认为 dbuser_dba
pg_admin_password：postgres 管理员密码的明文，默认为 DBUser.DBA
pg_monitor_username：postgres 监控用户名，默认为 dbuser_monitor
pg_monitor_password：postgres 监控密码，默认为 DBUser.Monitor

在生产部署中记得更改这些密码，不要使用默认值！

pg_dbsu: postgres                             # 数据库超级用户名，这个用户名建议不要修改。
pg_dbsu_password: ''                          # 数据库超级用户密码，这个密码建议留空！禁止dbsu密码登陆。
pg_replication_username: replicator           # 系统复制用户名
pg_replication_password: DBUser.Replicator    # 系统复制密码，请务必修改此密码！
pg_monitor_username: dbuser_monitor           # 系统监控用户名
pg_monitor_password: DBUser.Monitor           # 系统监控密码，请务必修改此密码！
pg_admin_username: dbuser_dba                 # 系统管理用户名
pg_admin_password: DBUser.DBA                 # 系统管理密码，请务必修改此密码！

如果您修改默认用户的参数，在 pg_default_roles 中修改相应的角色定义即可：

- { name: postgres     ,superuser: true                                          ,comment: system superuser }
- { name: replicator ,replication: true  ,roles: [pg_monitor, dbrole_readonly]   ,comment: system replicator }
- { name: dbuser_dba   ,superuser: true  ,roles: [dbrole_admin]  ,pgbouncer: true ,pool_mode: session, pool_connlimit: 16 , comment: pgsql admin user }
- { name: dbuser_monitor   ,roles: [pg_monitor, dbrole_readonly] ,pgbouncer: true ,parameters: {log_min_duration_statement: 1000 } ,pool_mode: session ,pool_connlimit: 8 ,comment: pgsql monitor user }

权限系统

Pigsty 拥有一套开箱即用的权限模型，该模型与默认角色一起配合工作。

所有用户都可以访问所有模式。
只读用户（dbrole_readonly）可以从所有表中读取数据。（SELECT，EXECUTE）
读写用户（dbrole_readwrite）可以向所有表中写入数据并运行 DML。（INSERT，UPDATE，DELETE）。
管理员用户（dbrole_admin）可以创建对象并运行 DDL（CREATE，USAGE，TRUNCATE，REFERENCES，TRIGGER）。
离线用户（dbrole_offline）类似只读用户，但访问受到限制，只允许访问离线实例（pg_role = 'offline' 或 pg_offline_query = true）
由管理员用户创建的对象将具有正确的权限。
所有数据库上都配置了默认权限，包括模板数据库。
数据库连接权限由数据库定义管理。
默认撤销PUBLIC在数据库和public模式下的CREATE权限。

对象权限

数据库中新建对象的默认权限由参数 pg_default_privileges 所控制：

- GRANT USAGE      ON SCHEMAS   TO dbrole_readonly
- GRANT SELECT     ON TABLES    TO dbrole_readonly
- GRANT SELECT     ON SEQUENCES TO dbrole_readonly
- GRANT EXECUTE    ON FUNCTIONS TO dbrole_readonly
- GRANT USAGE      ON SCHEMAS   TO dbrole_offline
- GRANT SELECT     ON TABLES    TO dbrole_offline
- GRANT SELECT     ON SEQUENCES TO dbrole_offline
- GRANT EXECUTE    ON FUNCTIONS TO dbrole_offline
- GRANT INSERT     ON TABLES    TO dbrole_readwrite
- GRANT UPDATE     ON TABLES    TO dbrole_readwrite
- GRANT DELETE     ON TABLES    TO dbrole_readwrite
- GRANT USAGE      ON SEQUENCES TO dbrole_readwrite
- GRANT UPDATE     ON SEQUENCES TO dbrole_readwrite
- GRANT TRUNCATE   ON TABLES    TO dbrole_admin
- GRANT REFERENCES ON TABLES    TO dbrole_admin
- GRANT TRIGGER    ON TABLES    TO dbrole_admin
- GRANT CREATE     ON SCHEMAS   TO dbrole_admin

由管理员新创建的对象，默认将会上述权限。使用 \ddp+ 可以查看这些默认权限：

类型	访问权限
函数	=X
	dbrole_readonly=X
	dbrole_offline=X
	dbrole_admin=X
模式	dbrole_readonly=U
	dbrole_offline=U
	dbrole_admin=UC
序列号	dbrole_readonly=r
	dbrole_offline=r
	dbrole_readwrite=wU
	dbrole_admin=rwU
表	dbrole_readonly=r
	dbrole_offline=r
	dbrole_readwrite=awd
	dbrole_admin=arwdDxt

默认权限

SQL 语句 ALTER DEFAULT PRIVILEGES 允许您设置将来创建的对象的权限。它不会影响已经存在对象的权限，也不会影响非管理员用户创建的对象。

在 Pigsty 中，默认权限针对三个角色进行定义：

{% for priv in pg_default_privileges %}
ALTER DEFAULT PRIVILEGES FOR ROLE {{ pg_dbsu }} {{ priv }};
{% endfor %}

{% for priv in pg_default_privileges %}
ALTER DEFAULT PRIVILEGES FOR ROLE {{ pg_admin_username }} {{ priv }};
{% endfor %}

-- 对于其他业务管理员而言，它们应当在执行 DDL 前执行 SET ROLE dbrole_admin，从而使用对应的默认权限配置。
{% for priv in pg_default_privileges %}
ALTER DEFAULT PRIVILEGES FOR ROLE "dbrole_admin" {{ priv }};
{% endfor %}

这些内容将会被 PG集群初始化模板 pg-init-template.sql 所使用，在集群初始化的过程中渲染并输出至 /pg/tmp/pg-init-template.sql。该命令会在 template1 与 postgres 数据库中执行，新创建的数据库会通过模板 template1 继承这些默认权限配置。

也就是说，为了维持正确的对象权限，您必须用管理员用户来执行 DDL，它们可以是：

{{ pg_dbsu }}，默认为 postgres
{{ pg_admin_username }}，默认为 dbuser_dba
授予了 dbrole_admin 角色的业务管理员用户（通过 SET ROLE 切换为 dbrole_admin 身份）。

使用 postgres 作为全局对象所有者是明智的。如果您希望以业务管理员用户身份创建对象，创建之前必须使用 SET ROLE dbrole_admin 来维护正确的权限。

当然，您也可以在数据库中通过 ALTER DEFAULT PRIVILEGE FOR ROLE <some_biz_admin> XXX 来显式对业务管理员授予默认权限。

数据库权限

在 Pigsty 中，数据库（Database）层面的权限在数据库定义中被涵盖。

数据库有三个级别的权限：CONNECT、CREATE、TEMP，以及一个特殊的’权限’：OWNERSHIP。

- name: meta         # 必选，`name` 是数据库定义中唯一的必选字段
  owner: postgres    # 可选，数据库所有者，默认为 postgres
  allowconn: true    # 可选，是否允许连接，默认为 true。显式设置 false 将完全禁止连接到此数据库
  revokeconn: false  # 可选，撤销公共连接权限。默认为 false，设置为 true 时，属主和管理员之外用户的 CONNECT 权限会被回收

如果 owner 参数存在，它作为数据库属主，替代默认的 {{ pg_dbsu }}（通常也就是postgres）
如果 revokeconn 为 false，所有用户都有数据库的 CONNECT 权限，这是默认的行为。
如果显式设置了 revokeconn 为 true：
- 数据库的 CONNECT 权限将从 PUBLIC 中撤销：普通用户无法连接上此数据库
- CONNECT 权限将被显式授予 {{ pg_replication_username }}、{{ pg_monitor_username }} 和 {{ pg_admin_username }}
- CONNECT 权限将 GRANT OPTION 被授予数据库属主，数据库属主用户可以自行授权其他用户连接权限。
revokeconn 选项可用于在同一个集群间隔离跨数据库访问，您可以为每个数据库创建不同的业务用户作为属主，并为它们设置 revokeconn 选项。

示例：数据库隔离

pg-infra:
  hosts:
    10.10.10.40: { pg_seq: 1, pg_role: primary }
    10.10.10.41: { pg_seq: 2, pg_role: replica , pg_offline_query: true }
  vars:
    pg_cluster: pg-infra
    pg_users:
      - { name: dbuser_confluence, password: mc2iohos , pgbouncer: true, roles: [ dbrole_admin ] }
      - { name: dbuser_gitlab, password: sdf23g22sfdd , pgbouncer: true, roles: [ dbrole_readwrite ] }
      - { name: dbuser_jira, password: sdpijfsfdsfdfs , pgbouncer: true, roles: [ dbrole_admin ] }
    pg_databases:
      - { name: confluence , revokeconn: true, owner: dbuser_confluence , connlimit: 100 }
      - { name: gitlab , revokeconn: true, owner: dbuser_gitlab, connlimit: 100 }
      - { name: jira , revokeconn: true, owner: dbuser_jira , connlimit: 100 }

CREATE权限

出于安全考虑，Pigsty 默认从 PUBLIC 撤销数据库上的 CREATE 权限，从 PostgreSQL 15 开始这也是默认行为。

数据库属主总是可以根据实际需要，来自行调整 CREATE 权限。