📚 课程目录第1章课程导入与安全审计全景

1. 课程导入与安全审计全景

在开始学习 PostgreSQL 安全审计与合规治理之前，先建立一个整体认知：这门课程不是单纯讲“怎么开日志”，也不是只讲“怎么配权限”，而是围绕 PostgreSQL 数据库，把审计、合规、治理、威胁模型四条主线串成一个可落地、可验证、可追溯的安全体系。很多团队在数据库安全上投入不少，却仍然在等保测评、内控检查或安全事件复盘时说不清楚“谁在什么时间、从哪里、对哪些数据做了什么、结果如何”。本课程要解决的，正是这类“看不见、说不清、追不到”的问题。

一、四个核心术语的边界

审计（Audit）关注“记录与追溯”。在 PostgreSQL 中，审计的对象包括连接事件、DDL 变更、DML 操作、权限授予与回收、角色切换、参数修改、登录失败等。审计的核心不是日志越多越好，而是关键行为可还原：谁（数据库用户/角色）、何时（时间戳）、从哪（客户端 IP、应用标识）、做了什么（SQL 类型与对象）、结果如何（成功/失败）。

合规（Compliance）关注“满足外部或内部要求”。例如等保 2.0 中关于“安全审计”的控制项要求审计覆盖到每个用户、审计记录包含日期时间/用户/事件类型/结果、审计记录受到保护不被删除修改、审计进程受到保护。合规的本质是把监管条款翻译成数据库侧可检查、可举证的技术与管理措施。

治理（Governance）关注“持续运转的机制”。合规是一次性的达标，治理是长期的责任分工、策略制定、权限审批、审计复核、例外管理和持续改进。治理回答的是：谁有权批准一次高危操作？审计日志保存多久？谁定期复核？发现异常后如何处置？

威胁模型（Threat Model）关注“防谁、防什么、怎么防”。数据库面临的典型威胁包括：内部人员越权查询敏感数据、应用账号被窃取后批量导出、DBA 权限滥用、SQL 注入导致数据泄露、备份文件泄露、审计日志被篡改或删除。威胁模型决定了审计策略的优先级——不是所有操作都同等重要，而是围绕高价值数据和高危行为重点布防。

审计解决“看得见”，合规解决“说得清”，治理解决“管得住”，威胁模型解决“防得准”。四者缺一不可。

二、课程整体学习路径

本课程共 30 章，整体按“认知—配置—采集—分析—治理—实战”递进。第一阶段建立全景与术语体系；第二阶段深入 PostgreSQL 审计能力，包括 log_statement、log_min_duration_statement、pgaudit 扩展、角色与权限审计、行级安全与脱敏；第三阶段进入日志采集、集中存储、防篡改与保留策略；第四阶段做审计数据分析、异常检测与告警；第五阶段落到合规映射、治理流程、等保与内控举证；最后通过综合实战把前面能力串成闭环。

下面这张图给出本课程的知识全景与学习路径，帮助你在后续每一章都能定位“当前学的是哪一块、它和上下游是什么关系”。

三、审计范围与对象

PostgreSQL 的审计范围可以按“层次”理解，而不是只盯 SQL 语句。第一层是连接与身份：谁登录、从哪个 IP、使用哪个数据库、认证是否成功。第二层是权限与角色：角色创建、授权、回收、成员变更、超级用户操作。第三层是数据操作：SELECT、INSERT、UPDATE、DELETE，尤其是对敏感表的访问。第四层是结构变更：CREATE、ALTER、DROP、TRUNCATE、索引与约束变更。第五层是系统与配置：参数修改、扩展安装、备份恢复、复制配置。第六层是审计自身：日志是否完整、是否被删除或修改、保留周期是否达标。

这六层对应不同的审计手段。连接与身份主要依赖 log_connections、log_disconnections 和认证日志；数据操作与结构变更依赖 pgaudit 的 pgaudit.log 分类；系统配置依赖 log_statement = 'ddl' 或 pgaudit.log = 'ddl,role'；审计自身的保护则依赖日志集中存储、文件权限、WAL 归档与外部不可变存储。

四、一个最小可用的审计配置示例

为了让你在课程早期就有一个可运行的参照，下面给出一个示例配置。它属于教学示例，实际生产需结合性能与合规要求调整。

-- postgresql.conf 关键审计参数（示例）
logging_collector = on
log_destination = 'csvlog'
log_directory = 'log'
log_filename = 'postgresql-%Y-%m-%d.log'
log_rotation_age = 1d
log_rotation_size = 100MB
log_connections = on
log_disconnections = on
log_line_prefix = '%m [%p] %q%u@%d/%a '
log_statement = 'ddl'
log_min_duration_statement = 1000
log_checkpoints = on
log_lock_waits = on

-- 安装并启用 pgaudit（示例）
CREATE EXTENSION pgaudit;
ALTER SYSTEM SET pgaudit.log = 'write, ddl, role';
ALTER SYSTEM SET pgaudit.log_catalog = off;
ALTER SYSTEM SET pgaudit.log_parameter = on;
SELECT pg_reload_conf();

这段配置的意图是：连接与断开可追溯；DDL 全记录；执行超过 1 秒的语句记录；写操作、DDL、角色变更由 pgaudit 结构化记录；参数值一并记录，便于还原“改了什么值”。pgaudit.log_catalog = off 是为了避免系统目录查询淹没日志，这是实践中常见的降噪手段。

审计日志本身也是敏感数据。日志中可能包含参数值、SQL 文本甚至业务数据，必须限制文件权限、集中传输并防止被普通数据库用户读取或删除。

五、如何判断审计是否“有效”

有效审计不是“日志文件存在”，而是能回答具体问题。可以用下面这组判断标准自查：能否在 5 分钟内定位某张敏感表在最近 24 小时内的所有访问者？能否证明某次权限变更由谁在何时执行？能否发现同一账号在非工作时间从异常 IP 批量导出数据？能否证明审计日志在过去 180 天内未被删除或修改？如果这些问题有任何一个答不上来，说明审计链路仍有缺口。