你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

数据分类建议

项目
05/01/2024

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

SE：03	对涉及数据处理的所有工作负载数据和系统进行分类并一致地应用敏感度标签。使用分类影响工作负载设计、实现和安全优先级。

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

定义

术语	定义
分类	按敏感度级别、信息类型、合规性要求和组织提供的其他条件对工作负载资产进行分类的过程。
元数据	用于将分类应用于资产的实现。
分类	使用商定的结构来组织分类数据的系统。通常，数据分类的分层描述。它具有指示分类条件的命名实体。

关键设计策略

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

需要数据发现才能找到数据。如果没有这一知识，大多数设计都采用中间方法，这可能满足安全要求，也可能不符合安全要求。数据可能受到过度保护，导致成本和性能效率低下。或者它可能不够保护，这增加了攻击面。

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

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

了解组织定义的分类

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

一般来说，分类或定义分类没有通用标准。这是由组织保护数据的动机推动的。分类可能会捕获合规性要求、工作负载用户承诺的功能或业务需求驱动的其他条件。

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

敏感性	信息类型	合规性范围
公共、常规、机密、高度机密、机密、最高机密、敏感	财务、信用卡、姓名、联系信息、凭据、银行、网络、SSN、健康字段、出生日期、知识产权、个人数据	HIPAA、PCI、CCPA、SOX、RTB

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

定义分类范围

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

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

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

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

清点数据存储

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

定义范围

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

根据分类标签进行设计

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

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

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

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

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

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

它还会影响数据生命周期管理操作，例如数据保留和解除授权计划。

应用用于查询的分类

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

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

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

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

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

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

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

最终，分类必须通过中心团队汇总到组织。从他们那里获取有关预期报表结构的输入。此外，利用集中式工具和流程，使组织保持一致，同时降低运营成本。

Azure 便利化

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

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

示例

此示例基于在安全基线 (SE：01 ) 中建立的信息技术 (IT) 环境。下面的示例图显示了对数据进行分类的数据存储。

存储在数据库和磁盘上的数据只能由少数用户（如管理员、数据库管理员）访问。然后，普通用户或客户的最终客户端通常只能访问公开给 Internet 的层，例如应用程序或跳转盒。
应用程序与磁盘上存储的数据库或数据通信，例如对象存储或文件服务器。
在某些情况下，数据可能存储在本地环境和公有云中。两者都需要一致地分类。
在操作员用例中，远程管理员需要在云或运行工作负载的虚拟机上访问跳转盒。应根据数据分类标签授予访问权限。
数据通过虚拟机移动到后端数据库，在整个遍历点中，应以相同级别的保密性处理数据。
工作负载将数据直接存储在虚拟机磁盘中。这些磁盘属于分类范围。
在混合环境中，不同的角色可以通过不同的机制访问本地工作负载，以连接到不同的数据存储技术或数据库。必须根据分类标签授予访问权限。
本地服务器连接到需要分类和保护的重要数据，例如文件服务器、对象存储和不同类型的数据库，例如关系数据库、无 SQL 数据库和数据仓库。
Microsoft Purview 合规性提供了一种对文件和电子邮件进行分类的解决方案。
Microsoft Defender for Cloud 提供了一种解决方案，可帮助公司跟踪环境中的合规性，包括上面这些案例中提到的许多用于存储数据的服务。

后续步骤

请参阅完整的一组建议。

安全清单

数据分类建议