中通服-从数据安全审计检查，到看懂企业数据安全技术体系

一、为什么开始整理这篇 Blog

从实际数据安全检查项出发，拆解企业数据安全管理要求背后的技术实现。

之前参与数据安全检查工作时，手里拿到的通常是一张很长的检查表。

表里面可能有几十甚至上百个检查项，例如：

• 是否建立数据全生命周期安全管理制度
• 是否建立个人用户数据保护机制
• 是否建立关键岗位人员权限台账
• 系统是否采用多因素认证
• 运维账号和审计账号是否分离
• 是否存在高权限账号管理机制
• 敏感数据是否进行脱敏展示
• 数据存储和传输是否进行加密
• 是否开展操作日志审计
• 是否开展数据库审计
• 是否建立数据销毁机制
• 是否对数据流转、外部提供等场景进行管理

刚开始看这些内容时，很容易把它理解成一堆制度检查项。

但实际检查过程中会发现，一个检查项往往对应的不只是制度，而是一套具体的技术能力。

例如：

“系统是否采用多因素认证？”

继续往下拆，就会涉及：

身份认证 → MFA → OTP/短信验证码 → 登录策略 → 暴力破解防护 → 账号锁定

再比如：

“运维账号和审计账号是否分离？”

实际上对应：

账号体系 → RBAC（基于角色的访问控制） → 权限控制 → 职责分离 → PAM（管理和保护拥有高级权限的账户） → 堡垒机 → 操作审计

因此，这张审计表对我来说，更像是一张企业数据安全技术体系的入口地图。

二、从审计表看数据安全到底在管什么

结合实际检查内容，可以把数据安全控制大致拆成下面几个方向：

数据安全 │ ├── 1. 数据资产 │ ├── 数据发现 │ ├── 数据资产梳理 │ ├── 数据分类分级 │ └── 数据流转 │ ├── 2. 身份与权限 │ ├── 身份认证 │ ├── MFA │ ├── IAM / 4A │ ├── RBAC │ ├── 最小权限 │ └── 职责分离 │ ├── 3. 高权限安全 │ ├── 运维账号 │ ├── 特权账号 │ ├── PAM │ ├── 堡垒机 │ └── 高风险操作控制 │ ├── 4. 数据保护 │ ├── 数据脱敏 │ ├── 数据加密 │ ├── 去标识化 │ └── 数据销毁 │ ├── 5. 数据访问与流转安全 │ ├── API安全 │ ├── 数据传输 │ ├── 外部提供 │ └── 数据暴露面 │ └── 6. 安全审计 ├── 操作日志 ├── 数据库审计 ├── 高风险操作审计 └── 安全事件追溯

所以，数据安全并不是单独的一项技术，而是围绕数据从产生、存储、使用、传输到销毁的全过程建立控制。

三、数据资产：安全首先要知道“有什么数据”

审计表中有大量内容实际上都建立在一个前提上：

企业首先要知道自己有哪些数据，以及这些数据在哪里。

例如个人用户数据检查中，需要梳理：

• 数据类型
• 数据数量
• 数据级别
• 处理方式
• 使用目的
• 使用范围
• 流转路径
• 访问人员
• 所属系统

这对应到技术侧，就是：

1. 数据资产梳理

需要知道：

系统 ↓ 数据库 ↓ 表 ↓ 字段 ↓ 数据

例如一个 CRM 系统：

CRM ├── customer │ ├── id │ ├── name │ ├── phone │ └── address │ └── order ├── order_id ├── customer_id └── amount

安全人员需要进一步回答：

哪些字段属于个人信息？

哪些属于敏感数据？

哪些数据需要重点保护？

这就是我后来接触到的数据资产梳理、数据发现以及数据分类分级。

四、身份认证：你到底是谁？

审计表中涉及系统登录认证、密码策略、短信验证码、OTP、多因素认证等检查项。

这些内容背后的核心问题其实非常简单：

系统如何确认“登录的人就是这个账号的合法使用者”？

最基础的是：

用户名 + 密码

进一步可以增加：

密码 + 短信验证码 / OTP

形成多因素认证。

这里需要区分几个概念：

身份认证 Authentication

解决：

你是谁？

授权 Authorization

解决：

你能做什么？

审计 Audit

解决：

你做了什么？

这三个概念是后面理解 IAM、4A、RBAC、堡垒机等技术的基础。

五、4A / IAM：把账号、认证、权限和审计统一起来

在实际检查中，经常会遇到账号权限、统一认证、运维账号等问题。

进一步往技术上拆，可以理解为：

用户 ↓ 身份管理 ↓ 统一认证 ↓ 权限控制 ↓ 访问资源 ↓ 操作审计

传统企业环境中，经常会通过4A等统一管理体系实现：

• Account：账号管理
• Authentication：认证管理
• Authorization：授权管理
• Audit：审计管理

而 IAM（Identity and Access Management）则更偏向于企业身份与访问管理体系。

这让我开始把“账号权限检查”从简单的台账核对，逐渐理解为：

身份 → 认证 → 授权 → 访问 → 审计

的一整套技术链路。

六、RBAC：为什么不同的人权限不一样？

审计表中多次出现：

• 权限台账
• 最小权限
• 岗位权限
• 管理员权限
• 运维人员权限
• 审计人员权限

这背后对应一个非常基础的技术模型：

RBAC：基于角色的访问控制

例如：

用户 ↓ 角色 ↓ 权限 ↓ 资源

假设系统有：

普通员工 运维人员 数据库管理员 安全审计员 系统管理员

不同角色拥有不同权限。

例如：

这就是最小权限原则在系统中的一种具体实现方式。

七、职责分离：为什么运维人员不能同时负责审计？

审计表中有一个非常典型的检查项：

系统运维账号和审计账号不得由同一人持有。

这其实不是简单的账号检查，而是一个很典型的职责分离问题。

如果一个人同时拥有：

操作权限 + 审计权限

那么理论上就存在：自己审计自己的问题。

自己操作 ↓ 自己修改 ↓ 自己审计

所以安全控制通常希望形成：

操作人员 ↓ 执行操作 审计人员 ↓ 独立审计

这也是为什么企业安全体系中经常需要区分：

管理、操作、审计三个角色。

八、PAM / 堡垒机：真正控制“高权限操作”

当检查对象从普通用户变成：

• root
• 数据库管理员
• 系统管理员
• 网络管理员
• 运维人员

安全要求会进一步提高。

这时候就会涉及：

PAM（Privileged Access Management）

即特权访问管理。

核心思想是：

对高权限账号进行更加严格的身份认证、授权、访问控制和操作审计。

典型链路：

运维人员 ↓ 身份认证 ↓ 堡垒机 ↓ 权限审批 ↓ 目标服务器 ↓ 数据库 / 应用系统 ↓ 操作日志

例如一个数据库管理员需要执行高风险 SQL：

DELETE FROM xxx WHERE ...

安全体系应该能够回答：

• 谁执行的？
• 什么时间执行的？
• 访问了哪台数据库？
• 执行了什么命令？
• 是否经过审批？
• 是否属于授权范围？
• 操作结果是什么？

这就是特权访问控制 + 操作审计。

九、数据脱敏：不是“不让看”，而是“让你看该看的”

审计表中涉及用户敏感信息脱敏展示。

例如手机号：

13812345678

在普通业务页面中可能展示为：

138****5678

身份证号：

110101199001011234

可以展示为：

110101********1234

这就是典型的数据脱敏。

常见方式包括：

静态脱敏

对数据复制出来后进行脱敏。

例如：

生产数据库 ↓ 测试数据库 ↓ 脱敏 ↓ 测试环境

避免生产个人信息直接进入测试环境。

动态脱敏

数据本身不一定发生变化，而是在展示时根据用户权限决定显示内容。

例如：

普通员工 → 138****5678 管理员 → 13812345678

所以数据脱敏实际上和权限控制是关联的。

十、数据加密：即使拿到了数据，也不能直接使用

审计表中的个人数据保护要求涉及数据加密。

这里可以进一步拆成：

1. 传输加密

例如：

HTTP ↓ HTTPS / TLS

主要解决：

数据在网络传输过程中被窃听或篡改的问题。

2. 存储加密

例如：

数据库 ↓ 敏感字段加密

即使数据库文件或者存储介质泄露，也不能直接得到明文数据。

3. 密码保护

这里需要特别区分：

密码通常不是“加密保存”，而是进行密码哈希处理。

例如：

用户密码 ↓ 密码哈希 ↓ 数据库

MD5 这类传统哈希算法已经不适合作为现代密码存储方案。

这也是我在实际工作中逐渐发现的一个问题：

审计表写的是“密码安全”，真正落到技术上以后，还要继续看具体采用什么算法、参数和实现方式。

十一、API安全：数据不一定从页面泄露

现在很多业务系统并不是直接操作数据库，而是：

浏览器 / APP ↓ API ↓ 后端服务 ↓ 数据库

因此，检查数据安全时不能只看数据库。

还需要关注 API。

例如：

GET /user/10001

如果用户把：

10001

改成：

10002

就能够访问其他用户数据，就可能涉及越权访问。

因此 API 安全需要关注：

• 身份认证
• 权限校验
• 对象级授权
• 参数校验
• 接口访问控制
• 敏感数据返回
• 接口日志
• 访问频率控制

这也是我后来学习 Web/API 安全时发现，数据安全和应用安全实际上存在很强的交叉。

十二、日志审计：安全控制必须能够留下证据

审计表中有大量关于操作日志、数据库审计、关键岗位人员操作审计的检查内容。

这类检查背后的核心问题是：

发生了什么，能不能查出来？

例如：

谁 ↓ 什么时间 ↓ 从哪里 ↓ 访问什么系统 ↓ 执行什么操作 ↓ 操作了什么数据 ↓ 结果如何

所以日志至少需要具备一定的：

• 操作主体
• 操作时间
• 操作对象
• 操作内容
• 来源地址
• 操作结果

十三、数据库审计：进一步看到“数据层发生了什么”

应用日志只能看到：

用户修改了客户信息

数据库审计则可能进一步看到：

UPDATE customer SET phone = '138xxxx5678' WHERE id = 10001;

因此数据库审计更靠近数据本身。

可以简单理解为：

应用层日志 ↓ 谁访问了什么功能 数据库审计 ↓ 谁对什么数据执行了什么操作

这也是为什么数据库权限、数据库账号、数据库审计经常成为数据安全检查的重要内容。

十四、数据流转：数据离开系统之后去了哪里？

数据安全并不止于数据库内部。

实际业务中数据可能经历：

业务系统 ↓ 接口 ↓ 数据平台 ↓ 数据仓库 ↓ 第三方系统 ↓ 外部机构

因此还需要关注：

• 数据从哪里来
• 数据流向哪里
• 谁可以访问
• 是否经过审批
• 是否存在外部提供
• 是否进行脱敏
• 是否进行加密传输
• 是否留下审计记录

这也是数据安全中的一个重要概念：

数据流转安全。

十五、数据销毁：数据生命周期最后一个环节

如果数据已经不再需要，安全管理不能停留在：

“业务不用了。”

而应该继续考虑：

数据产生 ↓ 存储 ↓ 使用 ↓ 共享 / 传输 ↓ 归档 ↓ 删除 / 销毁

数据销毁需要考虑：

• 数据库记录删除
• 文件删除
• 存储介质处理
• 备份数据
• 副本数据
• 日志中的残留数据

因此，“删除数据”并不一定等于“数据已经彻底消失”。

十六、把整张审计表串起来

重新看这张审计表，可以发现它实际上对应了一条比较完整的数据安全控制链路：

数据资产 ↓ 数据发现 / 分类分级 ↓ 明确数据的重要程度 ↓ 身份认证 ↓ 权限控制 ↓ 最小权限 ↓ 高权限管理 ↓ 数据脱敏 / 加密 ↓ 数据访问 / API / 数据流转 ↓ 日志审计 ↓ 数据库审计 ↓ 异常发现 ↓ 事件响应 ↓ 数据销毁

因此，数据安全检查并不是简单地：

“有没有制度、有没有材料。”

真正往技术层面继续追，就会变成：

数据在哪里 → 谁能访问 → 如何认证 → 能做什么 → 如何保护 → 如何传输 → 做了什么 → 如何审计 → 出问题怎么办。

十七、从这张审计表中，我重点建立的技术知识体系

结合实际检查经历，我把后续需要掌握的数据安全技术拆成几个方向：

这也是我理解数据安全技术的一条学习路径：

数据 ↓ 数据库 ↓ 网络 ↓ 身份认证 ↓ 权限控制 ↓ API ↓ 加密 ↓ 日志审计 ↓ 安全运营

十八、从“检查人”到“理解技术”

这张表对我最大的价值，并不是让我记住了多少个检查项。

而是让我开始尝试把：

检查要求 → 安全目标 → 技术控制 → 实际验证 → 审计证据

对应起来。

例如：

检查项： 是否进行多因素认证 ↓ 安全目标： 防止账号密码泄露后被直接登录 ↓ 技术控制： MFA / OTP / 短信验证码 ↓ 实际验证： 登录测试、认证流程检查 ↓ 审计证据： 系统配置、登录日志、认证记录

再例如：

检查项： 运维账号和审计账号是否分离 ↓ 安全目标： 避免操作人员自行修改或规避审计 ↓ 技术控制： RBAC / SoD / PAM / 堡垒机 ↓ 实际验证： 账号权限、角色配置、操作日志 ↓ 审计证据： 权限清单、审批记录、审计日志

这也是我从数据安全检查工作中逐渐形成的一种思考方式：

看到一个合规要求，不只停留在“有没有”，而是继续追问“为什么需要、技术上怎么实现、实际怎么验证”。

结语

数据安全检查表表面上是一张审计清单，但如果把每一个检查项继续向下拆解，就可以看到企业数据安全背后的技术体系。

从数据资产，到身份认证；从权限控制，到特权访问；从脱敏加密，到 API 和数据库；再到日志审计和安全运营，这些技术最终都是在解决几个核心问题：

数据在哪里？

谁可以访问？

可以访问什么？

访问过程中如何保护？

发生异常后能不能发现和追溯？

对数据安全从业者来说，理解这些检查项背后的技术实现，比单纯记住检查条款本身更重要