1.1. 监管关注的是安全的结果，而非实现安全的手段

1.2. 组织应设计自己的安全控制措施，并证明这些措施已达到或超过了法律法规的严格要求

2.1. 区分业务需求、外部监管限制和应用软件产品的规则很重要

2.2. 业务需求

2.2.1. 在组织内实施数据安全的第一步是全面了解组织的业务需求

2.2.2. 通过分析业务规则和流程，确定安全接触点

2.3. 监管要求

2.3.1. 当今全球环境瞬息万变，组织需遵从的法律法规愈来愈多

3.1. 组织在制定数据安全制度时应基于自己的业务和法规要求

3.2. 制度是所选行动过程的陈述以及为达成目标所期望行为的顶层描述

3.3. 制定安全制度需要IT安全管理员、安全架构师、数据治理委员会、数据管理专员、内部和外部审计团队以及法律部门之间的协作

3.4. 企业安全制度

3.4.1. 员工访问设施和其他资产的全局策略、电子邮件标准和策略、基于职位或职务的安全访问级别以及安全漏洞报告策略

3.5. IT安全制度

3.5.1. 目录结构标准、密码策略和身份管理框架

3.6. 数据安全制度

3.6.1. 单个应用程序、数据库角色、用户组和信息敏感性的类别

3.7. 安全制度应便于供应商、消费者和其他利益相关方可以轻松访问，应在公司局域网或类似协作门户上被提供和维护

3.8. 应定期重新评估数据安全制度、过程和活动，在所有利益相关方的数据安全要求之间取得尽可能的平衡

3.9. 制度提供行为准则，但并不能列出所有可能的意外情况

4.1. 细则是对制度的补充，并提供有关如何满足制度意图的其他详细信息

4.2. 定义数据保密等级

4.2.1. 保密等级分类是重要的元数据特征，用于指导用户如何获得访问权限

4.2.2. 每个组织都应创建或采用满足其业务需求的分级方案

4.2.3. 任何分级方案都应清晰易行，它将包含从最低到最高的一系列密级

4.3. 定义数据监管类别

4.3.1. 法规要求是信息安全的延伸

4.3.2. 需要采取其他措施，以对监管要求进行有效管理

4.3.3. 安全分级和监管分类的一项关键原则是，大多数信息可以聚合，从而使其具有更高或更低的敏感性

4.3.3.1. 开发人员需要知道聚合如何影响整体安全分级和监管类别

4.3.4. 分类分级的工作成果是一组经正式批准的安全分级和监管类别，以及从中央存储库中获得此类元数据的流程，以便业务和技术员工了解他们所处理、传送和授权信息的敏感性

4.4. 定义安全角色

4.4.1. 数据访问控制可根据需要在单个用户级或组织级中进行管理

4.4.2. 逐个用户账户授予和更新访问权限需要大量的冗余工作

4.4.3. 角色组使得安全管理员能够按角色定义权限，并通过在适当角色组中注册用户实现权限授予

4.4.4. 在用户和角色管理中的挑战之一是数据一致性

4.4.4.1. 为避免数据完整性问题，需要对用户身份数据和角色组成员身份集中管理，这也是有效访问控制数据质量的要求

4.4.4.2. 安全管理员创建、修改和删除用户账户和角色组以及对组分类和成员资格的变更应得到批准

4.4.4.3. 应通过变更管理系统跟踪变更

4.4.5. 网格（从数据开始）

4.4.6. 层次结构（从用户开始）

4.4.7. 角色分配矩阵

4.4.7.1. 基于数据机密性、法规和用户功能，矩阵可用于映射数据的访问角色

4.4.7.2. 公共用户角色可以访问公开级别中列出的所有数据，不受任何法规约束

4.4.8. 角色分配层次结构

4.4.8.1. 在工作组或业务单元级别构建组定义

5.1. 安全风险包括可能危及网络和/或数据库的因素

5.2. 识别风险的第一步是确定敏感数据的存储位置，以及这些数据需要哪些保护措施

5.3. 存储或传送的数据敏感性

5.4. 保护数据的要求

5.5. 现有的安全保护措施

5.6. 记录调查结果以此为将来的评价创建基线

5.7. 记录文档也可能是隐私法规遵从的要求

6.1. 数据安全策略的实施和管理主要由安全管理员负责，与数据管理专员和技术团队协作

6.2. 控制和规程（至少）应涵盖

6.2.1. 用户如何获取和终止对系统和/或应用程序的访问权限

6.2.2. 如何为用户分配角色并从角色中去除

6.2.3. 如何监控权限级别

6.2.4. 如何处理和监控访问变更请求

6.2.5. 如何根据机密性和适用法规对数据进行分类

6.2.6. 检测到数据泄露后如何处理

6.3. 对允许原始用户授权的要求要进行记录，以便在条件不再适用时取消授权

6.4. 流程

6.4.1. 根据用于跟踪所有用户权限请求的变更管理系统，验证分配的权限

6.4.2. 需要工作流审批流程或签名的纸质表单，来对每个变更请求记录和归档

6.4.3. 包括取消授权流程，对工作状态或部门不再适合继续拥有某些访问权限的人取消授权

6.5. 对用户和组授权的所有初始授权和后续变更，必须经由某些管理层级别的正式请求、跟踪和批准

6.6. 分配密级

6.6.1. 根据组织的分类方案，数据管理专员负责评估和确定适当的数据密级

6.6.2. 文件和报告的分类应基于文件中发现的任何信息的最高密级

6.6.3. 分类为最不机密的信息产品（如一般受众）无须标签

6.6.3.1. 假定任何未标记的产品都是面向一般受众的

6.6.4. 文件作者和信息产品设计人员负责评估、正确分类和标记每个文档以及每个数据库（包括关系表、列和用户权限视图）的适当密级

6.6.5. 在大型组织中，大部分安全分类和保护工作由专门的信息安全组织负责

6.6.6. 信息安全部门乐于由数据管理专员负责这些分类，他们通常负责实施及网络的物理保护

6.7. 分配监管类别

6.7.1. 组织应创建或采用能确保满足法规遵从要求的分类方案

6.7.2. 分类方案为响应内部和外部审计提供了基础

6.8. 管理和维护数据安全

6.8.1. 一旦所有需求、制度和过程都到位，则主要任务是确保不会发生安全漏洞

6.8.2. 控制数据可用性/以数据为中心的安全性

6.8.2.1. 控制数据可用性需要管理用户权限，以及对在技术上基于权限的访问控制的结构（数据脱敏、视图创建等）进行管理

6.8.2.2. 定义授权和授予授权需要数据清单、对数据需求仔细分析以及每个用户权利中公开的数据文档

6.8.2.3. 高度敏感信息通常与非敏感信息混合在一起

6.8.2.4. 企业数据模型对于识别和定位敏感数据至关重要

6.8.2.5. 即使数据无意暴露，利用数据脱敏也可以保护数据

6.8.2.6. 关系数据库视图可用于强制执行数据安全级别

6.8.2.6.1. 视图可以基于数据值限制对某些行的访问，或对某些列的限制访问，从而限制对机密/受监管字段的访问

6.8.3. 监控用户身份验证和访问行为

6.8.3.1. 监控用户身份验证和访问行为

6.8.3.2. 监视身份验证和访问行为提供了有关谁正在连接和访问信息资产的信息

6.8.3.3. 监控还有助于发现值得调查的异常、意外或可疑的交易

6.8.3.4. 弥补了数据安全规划、设计和实现方面的缺陷

6.8.3.5. 要根据业务和法规要求进行仔细分析，以决定需要监控什么、监控多长时间以及决定在警报发生时要采取哪些行动

6.8.3.6. 监控涉及多种活动，可具体到某些数据集、用户或角色。监控可用于验证数据完整性、配置或核心元数据。监控可在系统内实现，也可以跨依赖的异构系统实现

6.8.3.7. 监控可自动或手动执行，也可通过自动化和监督相结合的方式来执行

6.8.3.8. 敏感或异常数据库事务的自动记录应该是任何数据库部署的一部分

6.8.3.9. 缺乏自动化监控意味着严重的风险

6.8.3.9.1. 监管风险(Regulatory Risk)

6.8.3.9.1.1. 数据库审计机制薄弱的组织将越来越多地发现他们与政府的监管要求相悖

6.8.3.9.2. 检测和恢复风险(Detection and Recovery Risk)

6.8.3.9.2.1. 审计机制代表最后一道防线

6.8.3.9.2.2. 如果攻击者绕过其他防御，则审计数据可以在事后识别是否存在违规行为

6.8.3.9.2.3. 审计数据还可作为系统修复指南或将违规关联到特定用户

6.8.3.9.3. 管理和审计职责风险(Administrative and Audit Duties Risk)

6.8.3.9.3.1. 具有数据库服务器管理访问权限的用户（无论该访问权限是合法还是恶意获得的），都可以关闭审计以隐藏欺诈活动

6.8.3.9.3.2. 在理想的情况下，审计职责应独立于DBA和数据库服务器平台支持人员

6.8.3.9.4. 依赖于不适当的本地审计工具的风险(Risk of Reliance on Inadequate Native Audit Tools)

6.8.3.9.4.1. 数据库软件平台通常集成基本审计功能，但它们往往受到很多限制或部署的阻碍

6.8.3.10. 为了降低风险，可以部署实施基于网络的审计设备

6.8.3.10.1. 高性能(High Performance)

6.8.3.10.1.1. 基于网络的审计设备可以在线运行，对数据库性能的影响很小

6.8.3.10.2. 职责分离(Separation of Auties)

6.8.3.10.2.1. 基于网络的审计设备应独立于DBA运行，从而能够恰当地将审计职责与管理职责分开

6.8.3.10.3. 精细事务跟踪(Granular Transaction Tracking)

6.8.3.10.3.1. 支持高级欺诈检测、取证和恢复

6.8.3.10.3.2. 日志包括源应用程序名称、完整查询文本、查询响应属性、源操作系统、时间和源名称等详细信息

6.9. 管理安全制度遵从性

6.9.1. 管理安全制度合规性包括确保遵循制度并有效维护控制的日常活动

6.9.2. 管理还包括提供满足新需求的建议

6.9.3. 在通常情况下，数据管理专员将与信息安全和公司法律顾问协作，使运营制度和技术控制保持一致

6.9.4. 管理法规遵从性

6.9.4.1. 衡量授权细则和程序的合规性

6.9.4.2. 确保所有数据需求都是可衡量的，因此也是可审计的（如“小心”等表述是无法衡量的）

6.9.4.3. 使用标准工具和流程保护存储和运行中的受监管数据

6.9.4.4. 发现潜在不合规问题以及存在违反法规遵从性的情况时，使用上报程序和通知机制

6.9.4.5. 合规性控制需要审计跟踪

6.9.4.5.1. 没有审计跟踪，就没有合规的证据

6.9.4.5.2. 应设计控制措施以确保其是可审计的

6.9.4.6. 组织必须能够证明所有指定的用户都参加了培训

6.9.5. 审计数据安全和合规活动

6.9.5.1. 应确保对数据安全和法规制度遵从情况进行连续性的定期内部审计

6.9.5.2. 当颁布新的数据法规或现有法规发生变化时，必须重新审视合规性控制本身，并定期回顾确保控制的有效性

6.9.5.3. 审计工作可以从内部或外部开展。在任何情况下，审计师必须独立于审计中涉及的数据和/或流程，以避免任何利益冲突，并确保审计活动和审计结果的完整性

6.9.5.4. 审计不是为了发现错误

6.9.5.5. 审计的目标是为管理层和数据治理委员提供客观、公正的评估以及合理、实用的建议

6.9.5.6. 评估制度和细则，确保明确定义合规控制并满足法规要求

6.9.5.7. 分析实施程序和用户授权实践，确保符合监管目标、制度、细则和预期结果

6.9.5.8. 评估授权标准和规程是否充分且符合技术要求

6.9.5.9. 当发现存在违规或潜在违规时，评估所要执行的上报程序和通知机制

6.9.5.10. 审查外包和外部供应商合同、数据共享协议以及合规义务，确保业务合作伙伴履行义务及组织履行其保护受监管数据的法律义务

6.9.5.11. 评估组织内安全实践成熟度，并向高级管理层和其他利益相关方报告“监管合规状态”

6.9.5.12. 推荐的合规制度变革和运营合规改进

6.9.5.13. 数据安全性审计不能替代数据安全管理

6.9.5.13.1. 审计是客观地评估管理是否达到目标的支持过程