数据分类的体系结构策略

适用于 Azure Well-Architected Framework 安全清单建议：

本指南介绍数据分类的建议。 大多数工作负荷存储各种类型的数据。 并非所有数据都同样敏感。 数据分类有助于根据数据的敏感度级别、信息类型和符合性范围对数据进行分类，以便可以应用正确的保护级别。 保护包括访问控制、不同信息类型的保留策略等。 虽然基于数据分类的实际安全控制不适用于本文，但它提供了根据组织设置的上述条件对数据进行分类的建议。

定义

数据分类是一项关键练习，通常推动构建记录系统及其功能。 分类还有助于正确调整安全保证的大小，并帮助会审团队在事件响应期间发现。 设计过程的先决条件是清楚地了解数据是否应被视为机密、受限、公共或任何其他敏感度分类。 确定存储数据的位置也很重要，因为数据可能分布在多个环境中。

数据发现是查找数据所必需的。 如果没有这种知识，大多数设计都采用中间方法，这种方法可能或可能不符合安全要求。 数据可以过度保护，从而导致成本和性能低下。 或者它可能不够受保护，这增加了攻击面。

数据分类通常是一个繁琐的练习。 有一些工具可用于发现数据资产并建议分类。 但不只是依靠工具。 有一个过程，团队成员勤奋地做练习。 然后，使用工具自动执行这一作。

除了这些最佳做法，请参阅 创建设计良好的数据分类框架。

了解组织定义的分类

分类 是数据分类的分层描述。 它具有指示分类条件的命名实体。

一般情况下，分类或定义分类没有通用标准。 它是由组织保护数据的动机推动的。 分类可能会捕获符合性要求、为工作负荷用户承诺的功能，或由业务需求驱动的其他标准。

下面是敏感度级别、信息类型和符合性范围的一些示例分类标签。

作为工作负荷所有者，依靠组织为你提供定义完善的分类。 所有工作负荷角色都必须对敏感度级别的结构、名词和定义有共同的理解。 不要定义自己的分类系统。

定义分类范围

大多数组织都有一组不同的标签。

明确确定每个敏感度级别的数据资产和组件在范围内和范围外。 你应该对结果有一个明确的目标。 目标可能是更快速的会审、加速灾难恢复或监管审核。 当你清楚地了解目标时，它可确保正确调整分类工作的大小。

从这些简单的问题开始，并根据系统复杂性根据需要进行扩展：

• 数据和信息类型的起源是什么？
• 基于访问的预期限制是什么？ 例如，它是公共信息数据、法规或其他预期用例吗？
• 数据占用量是多少？ 数据存储在何处？ 应保留数据多长时间？
• 体系结构的哪些组件与数据交互？
• 数据如何通过系统移动？
• 审核报告中需要哪些信息？
• 是否需要对预生产数据进行分类？

清点数据存储

如果有现有系统，请清点范围内的所有数据存储和组件。 另一方面，如果要设计新系统，请创建体系结构的数据流维度，并按分类定义进行初始分类。 分类适用于整个系统。 它与对配置机密和非机密进行分类明显不同。

定义范围

定义范围时，请进行精细和显式。 假设数据存储是表格系统。 你想要在表级别甚至表中的列对敏感度进行分类。 此外，请务必将分类扩展到可能与数据相关的非数据存储组件或具有处理数据的一部分。 例如，是否对高度敏感的数据存储的备份进行分类？ 如果要缓存用户敏感数据，则缓存数据存储在范围内吗？ 如果使用分析数据存储，聚合数据是如何分类的？

根据分类标签进行设计

分类应影响体系结构决策。 最明显的区域是分段策略，应考虑不同的分类标签。

例如，标签会影响流量隔离边界。 可能存在需要端到端传输层安全性（TLS）的关键流，而其他数据包可以通过 HTTP 发送。 如果存在通过消息代理传输的消息，则可能需要对某些消息进行签名。

对于静态数据，级别会影响加密选项。 可以选择通过双重加密保护高度敏感数据。 不同的应用程序机密甚至可能需要通过不同的保护级别进行控制。 你可能能够证明在硬件安全模块（HSM）存储中存储机密是正当的，该模块提供更高的限制。 合规性标签还决定正确的保护标准。 例如，PCI-DSS 标准要求使用 FIPS 140-2 级别 3 保护，该保护仅适用于 HSM。 在其他情况下，其他机密可能可以存储在常规机密管理存储中。

如果需要保护正在使用的数据，可能需要在体系结构中合并机密计算。

分类信息应随数据一起移动，因为它在系统 之间和工作负荷的组件之间转换。 标记为机密的数据应由与之交互的所有组件视为机密数据。 例如，请务必通过从任何类型的应用程序日志中删除或模糊处理这些数据来保护个人数据。

分类会影响报表的设计 方式，即应公开数据的方式。 例如，根据信息类型标签，是否需要根据信息类型标签应用数据掩码算法进行模糊处理？ 哪些角色应该能够查看原始数据与掩码数据？ 如果报告有任何合规性要求，数据如何映射到法规和标准？ 了解这一点后，可以更轻松地演示符合特定要求并为审核员生成报告。

它还会影响数据生命周期管理作，例如数据保留和停用计划。

应用分类进行查询

可通过多种方式将分类标签应用于标识的数据。 将分类架构与元数据结合使用是指示标签的最常用方法。 通过架构实现标准化可确保报告准确、最大程度地减少变体的可能性，并避免创建自定义查询。 生成自动检查以捕获无效条目。

可以手动、以编程方式应用标签，也可以使用这两者的组合。 体系结构设计过程应包括架构的设计。 无论是现有系统还是正在生成新系统，在应用标签时，在键/值对中保持一致性。

请记住，并非所有数据都可以明确分类。 明确决定如何在报告中表示无法分类的数据。

实际实现取决于资源类型。 某些 Azure 资源具有内置的分类系统。 例如，Azure SQL Server 具有分类引擎，支持动态掩码，并且可以基于元数据生成报表。 Azure 服务总线支持包括可以附加元数据的消息架构。 设计实现时，评估平台支持的功能并利用这些功能。 确保用于分类的元数据是隔离的，并独立于数据存储进行存储。

还有专门的分类工具可以自动检测和应用标签。 这些工具连接到数据源。 Microsoft Purview 具有自动发现功能。 还有提供类似功能的第三方工具。 应通过手动验证来验证发现过程。

定期查看数据分类。 应将分类维护内置到作中，否则过时的元数据可能会导致已确定的目标和符合性问题产生错误的结果。

权衡：注意工具的成本权衡。 分类工具需要训练，而且可能比较复杂。

归根结底，分类必须通过中心团队汇总到组织。 获取有关预期报表结构的输入。 此外，利用集中式工具和流程进行组织协调，并减轻运营成本。

Azure 便利化

Microsoft Purview 将 Azure Purview 和 Microsoft Purview 解决方案统一，以便在整个组织中提供数据资产的可见性。 有关详细信息，请参阅 什么是 purview Microsoft？

Azure SQL 数据库、Azure SQL 托管实例和 Azure Synapse Analytics 提供内置分类功能。 使用这些工具可发现、分类、标记和报告数据库中的敏感数据。 有关详细信息，请参阅 数据发现和分类。

Example

此示例基于 安全基线（SE：01）中建立的信息技术（IT）环境。 下面的示例图显示了数据分类位置的数据存储。

1. 只有少数用户（例如管理员、数据库管理员）才能访问存储在数据库和磁盘上的数据。 然后，通常普通用户或客户的最终客户端只能访问向 Internet 公开的层，例如应用程序或跳转框。

2. 应用程序与磁盘上存储的数据库或数据（例如对象存储或文件服务器）通信。

3. 在某些情况下，数据可能存储在本地环境和公有云中。 两者都需要一致地分类。

4. 在操作员用例中，远程管理员需要在云或运行工作负荷的虚拟机上访问跳转框。 应根据数据分类标签授予访问权限。

5. 数据通过虚拟机移动到后端数据库，数据应在整个遍历点中使用相同的机密级别进行处理。

6. 工作负荷直接将数据存储在虚拟机磁盘中。 这些磁盘在分类范围内。

7. 在混合环境中，不同的角色可以通过不同的机制访问本地工作负荷，以连接到不同的数据存储技术或数据库。 必须根据分类标签授予访问权限。

8. 本地服务器连接到需要分类和保护的重要数据，例如文件服务器、对象存储和不同类型的数据库，例如关系数据库、no-SQL 和数据仓库。

9. Microsoft Purview 合规性提供了对文件和电子邮件进行分类的解决方案。

10. Microsoft Defender for Cloud 提供了一种解决方案，可帮助公司跟踪环境中的合规性，包括用于存储数据的许多服务，如上述情况中所述。

相关链接

• 数据分类和敏感度标签分类 - Microsoft服务保障
• 创建设计良好的数据分类框架 - Microsoft服务保障

后续步骤

请参阅完整的建议集。