安全的目标：保护，但不妨碍合法使用
数据安全包括安全策略和过程的规划、建立与执行，为数据资产提供正确的身份验证、授权、访问和审计。它的需求来自利益相关方的隐私期望、政府法规、行业合同、组织的专有数据，以及业务对合法访问的需要。安全不是把数据锁死，而是在正确的时间让正确的人以正确的方式使用数据。
- 三项目标：支持适当访问、防止不当访问、满足合规与利益相关方要求
- 六条原则：协同合作、企业统筹、主动管理、明确责任、元数据驱动、减少接触
- 安全能力本身是资产：可信的信息系统能促进交易、建立客户信心
- 安全必须企业级统筹；各业务单元各自为政会推高成本并制造保护缺口
脆弱性、威胁与风险
脆弱性是系统自身的弱点，如未打补丁、弱口令、配置错误；威胁是可能利用弱点的潜在行动，可能来自外部攻击者，也可能来自内部人员的疏忽或恶意；风险是损失的可能性及其后果。风险优先级要综合发生概率、损害规模、修复成本和攻击者意图，由利益相关方通过正式流程确定。
- 分类分级是安全工作的起点：不知道敏感数据在哪里，就无法有效保护
- 非生产环境往往比生产环境更脆弱；生产数据应尽量不流出生产环境
- 企业数据模型是定位敏感数据的关键工具
- 安全元数据（分类、合规敏感度）应随数据在企业内流动
| 类别 | 特征 | 示例 |
|---|---|---|
| 关键风险数据（CRD） | 直接财务价值高，滥用会伤害个人并重创组织 | 身份证号、银行卡、医疗记录、完整客户档案 |
| 高风险数据（HRD） | 构成竞争优势，泄露造成财务与法律损失 | 定价策略、核心配方、并购计划 |
| 中等风险数据（MRD） | 非公开但价值有限，泄露产生负面影响 | 内部流程文档、非敏感运营指标 |
用户权限内所有数据中的最高密级，决定该用户整体的安全等级。
4A 与访问控制
数据安全过程可概括为 4A：访问（Access）、审计（Audit）、验证（Authentication）、授权（Authorization），再加上权限（Entitlement）。访问控制系统在每次登录时检查授权令牌；权限则是某次授权决定向用户开放的所有数据元素的总和。授权前必须清点该权限会暴露的全部数据。
- 角色分配、变更、回收要有正式请求、审批、跟踪与归档
- 离职、转岗、项目结束都应触发权限回收
- 视图、行级/列级安全、脱敏都可以在数据库层强制安全边界
- 大型组织通常设 CISO；缺少专职安全人员时，数据管理者必须参与安全治理
| 要素 | 含义 | 落地手段 |
|---|---|---|
| 访问 Access | 授权用户能及时连接并使用系统 | 账户、角色、访问路径 |
| 审计 Audit | 审查安全操作与用户活动是否符合制度 | 日志、定期审计、第三方审计 |
| 验证 Authentication | 确认登录者身份属实 | 密码、令牌、生物特征、多因素 |
| 授权 Authorization | 授予与角色相适应的数据视图 | 角色模型、属性/策略授权 |
| 权限 Entitlement | 一次授权暴露的全部数据元素 | 数据清单、最小权限、定期复核 |
监控分主动与被动：主动监控实时发现并阻断可疑活动，被动监控定期快照并与基线比较。
加密与脱敏：降低数据可用性而不丢失含义
加密把明文转换为不可读的代码；脱敏则改变数据外观，使数据仍可用于测试、分析或展示，但不再暴露真实个体。两者常配合使用：静态脱敏用于生产到非生产的数据流转，动态脱敏用于生产环境下的按需展示。
- 脱敏不是匿名化的同义词；多源组合仍可能重新识别个体
- 加密密钥必须与数据分开存储，并有独立的授权与轮换机制
- 生产数据进入开发/测试环境前，应优先采用不落地脱敏
| 方法 | 密钥结构 | 典型用途 |
|---|---|---|
| 哈希 | 单向，不可解密 | 完整性校验、口令存储、身份验证 |
| 对称加密 | 同一密钥加解密 | 大批量数据存储与传输（AES 等） |
| 非对称加密 | 公钥加密、私钥解密 | 密钥交换、跨组织安全传输（RSA 等） |
DES 已不安全；哈希用于口令时应加盐并使用足够强度的算法。
| 类型 | 特点 | 常见方法 |
|---|---|---|
| 静态脱敏（不落地） | 源到目标移动过程中脱敏，不留中间明文 | 替换、混排、随机化、键值脱敏 |
| 静态脱敏（落地） | 在源位置直接覆盖，风险较高 | 需先确认有安全副本与可回退方案 |
| 动态脱敏 | 不改变底层数据，按用户改变展示 | 掩码、按角色显示部分字段、表达式脱敏 |
时间/数值变异可在保留趋势的同时降低可识别性；键值脱敏要保证唯一且可重复，以维持测试数据的一致性。
安全工作怎么开展
安全没有放之四海而皆准的实施方法，监管关注结果而非手段。组织需要证明自己的控制措施达到或超过了法规要求，并持续监控和度量。
- 识别需求：梳理业务需求、监管要求、合同义务与行业标准，建立法规—策略—控制—数据域的映射
- 制定制度：企业安全制度、IT 安全制度、数据安全制度分层，明确可审计的行为要求
- 定义细则：把制度落成标准、参数、流程和技术强制措施（如密码策略、审批流）
- 评估风险：识别敏感数据资产、位置、与业务流程的交互，评估内外部威胁与现有控制差距
- 实施控制：账户生命周期、角色管理、分类分级、访问控制、加密脱敏、日志监控
- 监控与审计：主动/被动监控、异常告警、定期权限复核、第三方审计
- 事件响应：检测、遏制、根除、恢复、复盘，并按法规要求通报
治理与度量
安全治理明确角色、责任与监管链，确保业务、IT、数据管理、法务和审计协同。度量既要看风险结果，也要看控制执行情况，避免只统计「装了多少工具」。
- 数据管理专员负责密级判定，安全团队负责技术实施与基础设施保护
- 制度要定期复审，适应法规、业务与技术变化
- 安全事件复盘要区分根因、控制失效点与改进项，并跟踪闭环
| 维度 | 指标示例 |
|---|---|
| 风险结果 | 安全事件数、数据泄露量、监管处罚、平均发现与响应时间 |
| 控制执行 | 补丁覆盖率、权限复核完成率、加密覆盖率、脱敏覆盖率 |
| 人员与流程 | 安全培训完成率、钓鱼演练失败率、制度例外数量 |
| 审计 | 审计发现数、整改关闭率、重复发现问题数 |
指标应与风险偏好对齐；高风险领域可以接受更严格的目标，低风险领域避免过度控制。