数据库安全（TDE、列级加密、动态脱敏、审计）

• TDE 的加密数据页与密钥层级
• 对应用透明性的实现
• 性能影响与密钥管理

透明数据加密（TDE）在存储层加密数据文件（数据页/数据文件），在数据写入磁盘时加密、读入内存时解密，应用与 SQL 无需任何改动即可工作，因此"透明"。其密钥管理采用多层密钥体系：数据加密密钥（DEK）用于实际加密数据页；DEK 再由主密钥（Master Key，通常由 KMS 或外部密钥管理系统托管）加密保护。查询时数据库先解密 DEK 再解密数据页，整个过程在数据库引擎内部完成。TDE 能防止物理窃取磁盘、备份文件被盗后明文泄露，但只保护"静止数据"（at rest），不保护内存中的明文与传输中的数据。TDE 会带来一定的 CPU 加密开销，可通过硬件加速（AES-NI）缓解。

TDE 的核心价值是"透明"与"平台加密"——不侵入应用层，加密范围覆盖整个数据文件，包括备份。其安全性依赖密钥管理：主密钥丢失则数据无法恢复，因此必须做密钥托管与备份。TDE 不解决 SQL 注入、越权访问等逻辑漏洞，需与其他安全手段配合。

• 动态脱敏的实时性与角色化
• 脱敏规则的实现层面（代理/视图/数据库层）
• 动态脱敏的适用场景与局限

动态数据脱敏（Dynamic Data Masking）在"查询执行时"根据用户角色实时遮盖敏感字段，数据在存储中保持原始值，返回给不同角色的用户时显示脱敏后的值。实现方式：数据库层（如 Oracle、SQL Server 内置 MASKING、PostgreSQL 通过视图/列权限）、代理层（专业 masking 工具拦截 SQL 改写）、以及应用层（在查询结果处脱敏）。脱敏规则（如身份证号显示前 3 后 4、手机号中间 4 位打星）按角色配置，例如普通用户看到脱敏值，授权用户看到明文。动态脱敏的优点是"一份数据、按权展示"，无需复制数据，适合生产环境在线查询；局限是脱敏发生于查询路径，可能影响查询性能，且对聚合/统计类查询需要特殊处理。

动态脱敏的本质是"按角色在读取时做变形"，核心是授权的精细化与覆盖全面性（要覆盖所有查询入口，避免走旁路绕过）。它解决"越权读取"问题，但若授权用户需要明文做分析，则需配合静态脱敏副本。动态脱敏不能替代加密，因为存储仍是明文，需防数据库文件泄露。

• 静态脱敏与动态脱敏的区别
• ETL 过程中生成脱敏副本
• 测试环境数据保真与关联保持

静态脱敏（Static Data Masking）将生产数据按脱敏规则生成一份脱敏副本，通常用于测试、开发、分析等非生产环境。它发生在 ETL 或数据迁移过程中：从生产库抽取数据，按规则（打码、替换、哈希、假名化）对敏感字段脱敏，再写入测试库。与动态脱敏不同，静态脱敏是"一次处理、结果持久化"，形成可独立使用的脱敏数据集。其关键诉求是"保真度"与"关联关系保持"：脱敏后的数据要尽量保持原有分布（供测试正确性）与主外键关联（供功能测试），因此需要确定性替换（同一真实值映射到同一脱敏值）与一致性脱敏（跨表同步）。

静态脱敏的核心是"脱敏副本的可用性"与"数据安全"的平衡。它解决了"测试环境不能用真实敏感数据"的问题，但需保证脱敏后的数据仍能支撑测试逻辑（如格式、范围、分布合理）。常见做法是确定性映射（如 hash 加盐）保证一致性，并做级联脱敏维护外键关系。

• 审计对象与范围（登录、DDL、DML、敏感数据访问）
• 审计日志的字段设计
• 审计的粒度与性能权衡

数据库审计日志（Audit Log）用于记录数据库操作行为以备追溯与合规。设计要点包括审计对象与范围：登录审计（记录成功/失败登录、来源 IP、账号）、DDL 审计（建表、改表、删表等结构变更）、DML 审计（增删改查，尤其高价值敏感数据的访问）、权限审计（授权/回收操作）。审计日志字段通常包括：时间戳、用户/账号、来源 IP、客户端、数据库/表/列、SQL 语句、执行结果、影响行数、应用名等。设计上要权衡审计粒度与性能：全量审计日志量大、影响性能，通常采用"按策略有选择性审计"（如只审计敏感表、高风险操作、失败尝试），并配合采样与异步收集。

审计日志的核心是"可追溯、可取证、满足合规（等保、SOX 等）"。设计时要明确"审计什么、记哪些字段、存多久、如何防篡改"。过度审计会拖垮性能，过少则漏检，因此需按风险分级配置策略，并保证审计日志本身的安全（只写不可改、独立存储）。

• 敏感数据发现的方法（正则、字典、机器学习）
• 敏感数据分级
• 与脱敏/加密的衔接

敏感数据的发现与分类是脱敏与加密的前提，因为"不知道哪些数据敏感、敏感程度如何"，就无法确定保护范围、脱敏规则与加密级别。发现方法包括：正则表达式（身份证、手机号、邮箱等模式）、字典匹配（列名/字段名如 name、id_card、phone）、机器学习（用分类模型识别文本中是否含敏感信息，适合非结构化数据）。分级则是把数据按敏感程度分为高/中/低或公开/内部/机密等，级别决定保护策略（如最高级加密+脱敏，中等级脱敏，低等级仅权限控制）。发现与分类的结果（敏感字段清单、分级标签）回流到脱敏/加密组件，指导其选择脱敏算法、加密字段与授权策略。

脱敏与加密的"范围"由发现与分类决定。若发现不全，会遗漏敏感数据导致泄露；若分类不准，会过度保护降低效率或保护不足。因此发现与分类是安全治理的起点，需结合正则、字典与 ML 多种手段，并持续扫描（增量发现新增敏感字段）。

• 各类脱敏算法（遮蔽、替换、哈希、令牌化）的特点
• 保真度与可逆性的取舍
• 测试环境保持关联关系的选型

脱敏算法在保真度（数据是否保持原样分布/可用）与可逆性（能否还原）上取舍不同。遮蔽（Masking）：把部分字符替换为 *，简单但破坏格式与可用性，适合展示场景。替换（Substitution）：用字典/随机值替换，保留格式但可能破坏分布与关联。哈希（Hashing）：对值做哈希（可加盐），此方式的优点是基于哈希的同一值映射一致，能保持"等值关联"，但通常不可逆（保真度低、无法还原）。令牌化（Tokenization）：把敏感值替换为令牌（token），令牌与真实值映射表由安全组件保管，可逆且保真度高，适合需要还原或跨系统关联的场景。测试环境需保持关联关系时，应选择"确定性 + 一致"的算法，如加盐哈希（确定性，同一值映射同一结果，保持外键关联）或令牌化（通过映射表保持关联且可还原），并做级联脱敏保证跨表主外键一致。

选型的关键是明确"脱敏后数据要做什么"。若仅去标识并保持等值关联（测试 join），用确定性哈希/令牌化；若需完全还原（如生产脱敏副本回退），用令牌化；若仅展示，用遮蔽。保真度与可逆性往往不可兼得，需按业务场景权衡。

• TDE 只保护数据文件，其他泄露面（备份、WAL/binlog、审计日志）
• 全链路加密的范围
• 密钥托管与轮换设计

仅启用 TDE 不够，因为 TDE 只加密数据文件，而备份文件（备份集）、WAL/binlog（日志中可能含未加密的明文数据与变更）、审计日志（可能记录敏感 SQL 与值）同样是泄露面——攻击者拿到这些文件仍可还原明文。因此要做全链路加密：备份文件加密（备份时加密）、日志加密（WAL/binlog 加密或对敏感数据写日志前脱敏）、审计日志加密存储、网络传输加密（TLS）。密钥托管设计：采用分层密钥体系，数据加密密钥（DEK）由主密钥（KEK）在 KMS 中加密保管，主密钥保存在外部 KMS/HSM，确保持久可用与可轮换；密钥丢失需有恢复机制（密钥备份、托管面），并定期轮换降低泄露风险。

TDE 是"数据面加密"的起点而非终点。全链路加密要覆盖"文件、备份、日志、传输"所有静态与传输路径。密钥管理是安全核心：主密钥存 KMS/HSM、分权管理、定期轮换、脱敏与加密分离，避免单点密钥泄露导致全盘明文。

• 参数化查询（预编译）作为根本防护
• 输入验证与白名单
• 最小权限与 WAF 协同

SQL 注入的防护是多层纵深。参数化查询（Prepared Statement / 占位符）是根本防护：把 SQL 结构（静态部分）与参数值分离，参数永远作为数据绑定，不参与拼接，从而杜绝注入——这是首选。输入验证：对用户输入做白名单校验（长度、类型、字符集），从源头过滤非法内容。最小权限原则：数据库账号只授予其业务所需的最小权限（如应用账号只读、只允许特定表），即使注入成功也降低危害。WAF（Web 应用防火墙）协同：在应用前置拦截明显恶意请求（如 SQL 关键字、报错探测），作为第一道防线，但 WAF 只是辅助，不能代替参数化。此外还应关闭错误信息泄露、隐藏数据库版本等。

参数化查询从"语义上"杜绝注入，是最可靠的防线；输入验证与 WAF 是补充。最小权限把"一旦被攻破"的损失降到最低。纵深防御要求各层协同，任何单层都不能完全依赖。

• 各合规标准对数据库安全的核心要求
• 数据保护、审计、脱敏、加密的要求
• 落地差异

各合规标准对数据库安全有相应要求。GDPR（欧盟）：要求对个人数据（PII）做保护，包括加密/假名化、数据最小化、数据主体权利（访问/删除）与数据泄露通知，要求能识别并保护个人数据。等保 2.0（中国）：对等级保护对象提出安全通用要求，包括身份鉴别、访问控制、安全审计（日志留存）、数据完整性/保密性、数据备份恢复等，对不同等级（如三级）有明确审计与加密要求。PCI DSS（支付卡行业）：要求持卡人数据加密存储与传输、访问控制、日志审计、定期漏洞扫描与安全评估，应用最小特权。HIPAA（美国医疗）：要求保护受保护健康信息（PHI），包括加密、访问控制、审计、数据完整性、应急计划等。共同点是"加密、访问控制、审计日志、脱敏、备份恢复"。

合规要求的核心是把"数据安全"制度化：识别敏感数据、加密与脱敏、权限最小化、审计可追溯、备份可靠。落地时需把合规要求转化为具体的数据库安全策略（加密范围、审计粒度、保留期），并建立对照检查与取证能力。

• KMS 的安全存储（HSM、分权、托管面）
• 密钥轮换机制
• 密钥丢失与恢复

密钥管理（KMS）的核心是安全存储与轮换。安全存储：主密钥存放在专用 KMS/HSM（硬件安全模块）中，密钥不出口证明（明文密钥不出现在数据库或应用），通过分权（多管理者、密钥拆分）与审批流程防止单点泄露；数据库的 DEK 由 KMS 中的主密钥加密后在其内部使用。密钥轮换：周期性更换密钥（主密钥/DEK），轮换时用新密钥重新加密数据（或分层加密使 DEK 轮换无需重加密全部数据——只需用新主密钥包裹 DEK），并保留历史密钥用于解密旧数据。密钥丢失与恢复：必须提前做密钥托管与备份（如 KMS 的密钥托管、多副本），否则密钥丢失将导致数据永久无法解密；同时设计密钥泄露的紧急吊销与重加密流程。

密钥管理的矛盾是"安全性"与"可用性"：密钥要防泄露，但也不能丢失。分层密钥（DEK 由主密钥包裹）让轮换更高效——轮换主密钥只需重新包裹 DEK，不必重加密数据。KMS/HSM 保证密钥不出域，是安全存储的基石。

• 零信任的核心思想（永不信任、持续验证）
• mTLS 与证书认证
• 持续验证与最小权限

零信任架构的核心是"永不信任、始终验证"，对每个访问请求都做身份验证与授权，不因网络位置而默认信任。数据库安全下的落地：mTLS（双向 TLS）：客户端与数据库服务端互相出示证书验证身份，确保网络层身份可信，防止中间人攻击与伪装；证书认证：数据库账号与证书绑定（如 PostgreSQL 的 clientcert、MySQL 的 SSL 证书），替代弱口令；持续验证：不仅建连时验证，还要持续监测访问行为（会话、请求频率、数据量），对异常访问实时处置（阻断、降权）；配合最小权限与动态授权（基于上下文如设备、时间、风险评分动态放行）。

零信任把"网络内即可信"变为"逐请求验证"。"身份"（证书/账号）+"行为"（持续监测）+"最小权限"是核心。mTLS 解决传输层身份，证书认证解决强身份，持续验证解决"合法身份做非法行为"的检测，三者结合降低被攻破后的横向移动风险。

• pgAudit 的加载与配置
• 审计对象与策略（ddl、write、read、function）
• 审计日志的查看与使用

pgAudit 是 PostgreSQL 的审计扩展，通过安装扩展并在 postgresql.conf 中加载实现。配置步骤：在 shared_preload_libraries 中加入 pgAudit，重启；创建扩展 CREATE EXTENSION pgaudit;；设置 pgaudit.log 参数控制审计内容（如 write、read、ddl、function、role、misc 等），可用 pgaudit.log 组合多个类别；pgaudit.log_relation 记录表级访问、pgaudit.log_statement_once 控制是否每条语句只记一次、pgaudit.role 将审计绑定到某个角色。审计事件写入 PostgreSQL 日志（errorlog），记录用户、语句、语句类型、对象等。还可以通过 pgaudit.log_client 输出到客户端。使用 pgaudit 可针对不同角色/库设置不同策略。

pgAudit 的核心是"按类别配置审计策略"，灵活且粒度可控。它把审计内容写入日志，需配合日志收集（如日志轮转、采集到集中平台）使用。配置时应注意：审计会带来日志量与性能开销，需按需选择类别。

• 三类脱敏方案的实现位置
• 各自的优缺点与适用场景
• 选型考虑

动态脱敏有三种实现位置。代理层脱敏：在应用与数据库之间加一层代理（专业脱敏/网关），拦截 SQL 并改写后返回脱敏结果，对应用与数据库透明，集中管理、便于统一策略，但引入代理层性能开销与单点风险。视图脱敏：在数据库层用视图（或列级权限/MASKING）对敏感字段做遮蔽，应用查询视图，天然贴近数据库、延迟低，但改造复杂（需改写查询指向视图）、对所有应用统一（不易按角色细分）。应用层脱敏：在应用代码查询结果处脱敏，灵活可控、可结合业务规则，但每个应用都要实现，易遗漏、难统一。选型要权衡统一性、侵入性、性能与改造成本。

代理层适合"统一策略、多系统接入"（如企业级数据安全平台）；视图适合"数据库内简单遮蔽、延迟敏感"；应用层适合"业务规则复杂、改造可控"。实际常组合使用，并保证脱敏覆盖所有查询入口以避免旁路。

• 列级加密与 TDE 的加密粒度
• 查询能力差异（可搜索性、索引）
• 性能差异

列级加密（应用层/代理层）只加密指定列，且通常由应用或代理在写入前加密、读取后解密，TDE 则对整个数据文件加密。差异在查询能力与性能：列级加密由于数据在库内是密文，普通索引、范围查询、排序、聚合无法直接在密文上执行，往往无法使用索引（除非用确定性加密 + 保序加密等特殊方案），查询能力受限。TDE 在内存解密后才执行查询，对 SQL 功能与索引完全透明，查询能力不受影响。性能上：列级加密在应用/代理侧做加解密，占用应用 CPU，且无法利用索引导致查询慢；TDE 在数据库内部解密，利用 AES-NI 硬件加速，对查询性能影响小，但加密整个数据文件带来存储与 IO 开销。列级加密粒度更细（只加密关键列），但功能受限；TDE 粒度粗但功能完整。

选型逻辑：若需要"对敏感列做细粒度加密且数据量小、查询简单"，列级加密合适；若需要"对全库透明保护且保持查询能力"，选择 TDE。列级加密的可搜索性差是核心短板，需用确定性加密/保序加密做折中，但要权衡其安全性。

• 敏感数据发现的多种手段（正则、字典、ML）
• 部署方式（抽样、离线或在线）
• 分类结果回流到权限系统

敏感数据发现的闭环包括"扫描发现 -> 分类定级 -> 回流权限 -> 保护策略 -> 持续监测"。手段：正则（模式匹配）、字典（字段名/值匹配）、ML（内容分类），三者结合提高准确率。部署方式：可用抽样（对大表做抽样扫描降低开销）、离线（批处理扫描全库，适合定期全量）、在线（流式/增量扫描，对新写入数据实时识别）。分类结果（敏感字段清单与分级）回流到权限系统：自动调度权限策略——对敏感字段收紧访问、设置脱敏/加密、触发审计，并把分级标签同步到数据资产目录，形成"发现即保护"的闭环。同时持续监测新增敏感数据，保持清单更新。

闭环的关键是"发现结果驱动安全策略"，而非仅停留在扫描报告。抽样/离线/在线三种方式结合（离线全量 + 在线增量 + 抽样高效）保证覆盖与效率。分类结果回流到权限系统，让敏感字段的访问自动受控，实现自动化治理。

• 数据库防火墙的工作方式
• 基于 SQL 语法解析与策略匹配
• 实时防护能力与局限

数据库防火墙（Database Firewall）位于应用与数据库之间（代理或旁路部署），对经过的 SQL 语句做实时解析与策略判断，拦截违规访问。它基于 SQL 语法解析/词法分析，把语句规范化（去除注释、格式化），再与预定义策略（白名单/黑名单、规则、基线）匹配，如识别高危操作（DROP、TRUNCATE、无 WHERE 的 DELETE）、脱敏、注入特征、越权访问、异常批量导出等，命中规则即阻断或告警。它还能做行为基线（正常 SQL 模式）检测异常。优点是实时、对应用透明、集中防护；局限是可能误拦正常复杂 SQL、影响性能、且无法防止应用层逻辑漏洞。

数据库防火墙的核心是"SQL 语义理解 + 策略匹配"，把防护前置到数据库访问路径。它由解析引擎（SQL 规范化）与策略引擎（规则/基线）构成。作为纵深防御的一环，它协同于参数化、权限、审计，但不应替代这些基础防护。

• 审计日志的采集方式
• 存储与检索
• 等保对审计的要求

SQL 审计的落地包括采集、存储与合规。采集：通过数据库原生审计（如 pgAudit、MySQL audit plugin）、代理（如 cdc/代理网关）、或应用埋点，把 SQL 操作、登录、DDL 等事件采集上来，并带上时间、账号、IP、对象、语句等字段。存储：审计日志量大，需集中存储（日志平台/对象存储），常做分区、压缩、索引便于检索，并保证只写不可改（防篡改）以利取证。合规（等保 2.0）：等保要求对重要操作进行审计，日志留存期满足要求（一般不少于 6 个月），审计覆盖登录、增删改查、权限变更等，并支持查询与追溯。落地时需按等级配置审计策略并保证留存与防篡改。

审计的难点是"多而全、存得下、查得到、改不了"。采集要覆盖所有入口防旁路，存储要压缩分区并防篡改，留存期要满足等保（≥6 个月）等合规要求，并支持按时间/账号/对象检索取证。

• 过度授权检测
• 最小权限原则落地
• 权限治理闭环

数据库账号的权限审计（过度授权检测）用于发现账号拥有超出其职责的权限（过度授权），如普通账号拥有 DBA、可访问所有表、可 DROP 等。检测方法：扫描账号与其权限的映射，对比"职责所需权限"基线，识别高风险授权（如 DBA、拥有者、可访问敏感表的账号过多、权限长期未回收）。最小权限落地：按角色授予最小必要权限（如只读、只写特定表、只允许特定 schema），用角色分层管理权限，定期复查与回收（季度/年度权限 review），对离职/转岗账号及时禁用，并把权限与脱敏、审计联动（敏感字段收紧授权）。落地还需权限变更审批与审计留痕。

权限治理的核心是"最小权限 + 定期治理"。过度授权是数据泄露与横向移动的高危因素。通过权限基线、角色化的最小授权、定期审查与回收，把"该有的权限"与"已有的权限"对齐。权限变更要有审批与审计，形成闭环。

• 审计日志的分区与压缩
• 检索优化
• 保留期与合规冲突的归档策略

审计日志数据量大时，需做分区、压缩与检索优化。分区：按时间（如按天/月）分区，便于按时间范围裁剪与清理旧分区；压缩：对日志做压缩存储（如列式压缩、gzip），降低存储成本；检索：为常用检索字段（时间、账号、IP、对象、操作类型）建索引，或用搜索引擎/日志平台（如 ELK、ClickHouse）做全文检索与聚合分析。保留期与合规要求冲突时：合规要求留存期较长（如等保 ≥6 个月），而热存储成本高，可做分层归档——近期日志放热存储（快速检索），历史日志归档到冷存储/对象存储（低成本、可导出），保留期到后可合规销毁并出具销毁记录。归档时保证可检索（按需导入）与防篡改。

审计日志的挑战是"量大、要存、要查、要合规"。技术方案是分区+压缩+索引/检索平台，管理方案是热冷分层归档与到期销毁。归档需满足合规可追溯，同时控制成本，销毁要有记录供审计。