数据分类建议
适用于 Power Platform Well-Architected Security 检查清单建议:
东南:03 | 对数据处理涉及的所有工作负载数据和系统进行分类并一致地应用敏感度标签。 使用分类影响工作负载设计、实现和安全优先级。 |
---|
本指南介绍基于数据敏感度对数据进行分类的建议。 大多数工作负载存储各种类型的数据。并非所有数据都同样敏感。 数据分类有助于根据数据的敏感度级别、信息类型和合规性范围对数据进行分类。 这样,您可以应用适当的保护级别,例如针对不同信息类型的访问控制、保留策略等。
定义
术语 | 定义 |
---|---|
分类 | 按敏感度级别、信息类型、合规性要求和组织提供的其他条件对工作负载资产进行分类的过程。 |
元数据 | 将分类法应用于资产的实现。 |
分类 | 使用商定的结构来组织分类数据的系统。 通常,是数据分类的分层描述。 它具有指示分类条件的命名实体。 |
关键设计策略
分类还有助于正确调整安全保证的大小,并帮助会审团队在事件响应期间加速发现。 设计过程的先决条件是清楚地了解数据是否应被视为机密、受限、公共或任何其他敏感度分类。 确定存储数据的位置也很重要,因为数据可能分布在多个环境中。 了解数据存储位置后,就可以设计满足安全要求的策略。
数据分类通常是一个繁琐的任务。 有一些工具可以发现数据资产并建议分类。 但不要只依赖工具。 让团队成员勤奋地练习。 然后,使用工具在可行时自动执行。
除了这些最佳实践外,请参阅创建设计良好的数据分类框架。
了解组织定义的分类
分类法 是数据分类的分层描述。 它具有指示分类条件的命名实体。
不同的组织可能有不同的数据分类框架;然而,它们通常由三到五个级别组成,包括名称、描述和示例。 以下是一些数据分类的分类示例:
敏感度 | 信息类型 | Description |
---|---|---|
公用 | 公共营销材料,网站上提供的信息 | 可自由访问且不敏感的信息 |
内部 | 与组织相关的政策、程序或预算 | 与特定组织相关的信息 |
机密 | 商业秘密、客户数据或最终记录 | 敏感且需要保护的信息 |
高度机密 | 敏感个人身份信息(敏感 PII)、持卡人数据、受保护的健康信息 (PHI)、银行账户数据 | 高度敏感且需要最高安全级别的信息。 如果泄露或以其他方式披露,可能需要法律通知。 |
重要提示
作为工作负载所有者,您应该遵循组织已经建立的分类。 所有工作负载角色都必须对敏感度级别的结构、命名和定义有共同的了解。 不要创建自己的分类系统。
定义分类范围
大多数组织都有一套不同的标签。
对于每个敏感度级别,清楚地确定哪些数据资产和组件在级别范围内和范围外。 目标可能是更快的故障排除、更快的灾难恢复或法律审计。 清楚了解目标后,有助于正确地进行分类工作。
从这些简单的问题开始,并根据系统复杂性进行必要的扩展:
- 数据和信息类型的来源是什么?
- 基于访问权限的预期限制是什么? 例如,它是公共信息数据、法规还是其他预期用例?
- 数据占用空间有多大? 数据存储在哪里? 数据应该保留多长时间?
- 体系结构的哪些组件与数据交互?
- 数据如何通过系统移动?
- 审核报告中需要哪些信息?
- 是否需要对预生产数据进行分类?
清点数据存储
分类作为一个整体应用于系统。 清点范围内的所有数据存储和组件。 如果要设计新系统,请按分类定义进行初始分类。 考虑数据将如何在系统组件之间流动,并确保数据不会跨越数据分类界限。
考虑如何连接数据:
新数据:如果您的工作负载生成了以前未存储在任何地方的新数据(例如,从基于纸张的流程过渡时),我们建议将此数据存储在其中 Microsoft Dataverse。 然后,您可以通过 Microsoft Purview 连接和管理 Microsoft Dataverse 数据。
从现有系统读/写:如果您的工作负载需要连接到已存在的数据,则需要设计如何读取和写入现有数据库或系统。 您可以使用虚拟表,通过连接器、数据流连接到数据,或者为内部数据使用内部网关。
定义范围
定义范围时要细致明确。 假设数据存储是一个表格系统。 您想要在表级别对敏感度进行分类,甚至对表中的列进行分类。 此外,请确保将分类扩展到可能相关或参与处理数据的非数据存储组件。 例如,是否对高度敏感的数据存储的备份进行分类? 如果要缓存用户敏感数据,缓存数据存储是否在范围内? 如果使用分析数据存储,如何对聚合数据进行分类?
根据分类标签进行设计
分类应影响体系结构决策。 最明显的领域是分段策略,它应考虑不同的分类标签。
分类信息在数据在系统和 工作负载组件之间转换时应随数据一起移动。 标记为机密的数据应由与其交互的所有组件视为机密数据。 例如,确保通过从任何类型的应用程序日志中删除或模糊处理个人数据来保护个人数据。
分类会影响报表 的设计,就像数据的公开方式一样。 例如,根据信息类型标签,是否需要应用数据掩码算法进行信息类型标签的模糊处理? 哪些角色应了解原始数据与掩码数据? 如果报告有任何合规性要求,如何将数据映射到法规和标准? 有了这种理解后,可以更轻松地证明符合特定要求并为审核员生成报告。
它还会影响数据生命周期管理操作,例如数据保留和解除授权计划。
应用用于查询的分类
可通过多种方式将分类标签应用于标识的数据。 将分类架构与元数据结合使用是指示标签的最常见方法。 体系结构设计过程应包括架构的设计。
请记住,并非所有数据都可以明确分类。 明确决定如何在报告中表示无法分类的数据。
实际的实现取决于资源的类型。 Power Platform 工作负载使用的数据可能来自 Power Platform 以外的数据源。 架构应该包括来自不同数据源的数据如何在工作负载中移动,或数据可能从一个数据存储转移到另一个数据存储的详细信息,同时保持分类的完整性。
某些 Azure 资源具有内置的分类系统。 例如,Azure SQL Server 具有分类引擎,支持动态掩码,并且可以基于元数据生成报表。 Microsoft Teams、Microsoft 365 组和 SharePoint 站点可以在容器级别应用敏感度标签。 Microsoft Dataverse 与 Microsoft Purview 集成以应用数据标签。
设计实现时,请评估平台支持的功能并加以利用。 确保用于分类的元数据是隔离的,并且与数据存储分开存储。
还有一些可以自动检测和应用标签的专用分类工具。 这些工具已连接到您的数据源。 Microsoft Purview 具有自动发现功能。 还有提供类似功能的第三方工具。 应通过手动验证来验证发现过程。
定期查看数据分类。 分类维护应内置于操作中,否则过时的元数据可能会导致已确定的目标和合规性问题产生错误结果。
权衡:注意工具的成本权衡。 分类工具需要培训,并且可能很复杂。
最终,分类必须通过中心团队汇总到组织中。 从他们那里获取有关预期报表结构的输入。 此外,还可以利用集中式工具和流程,使组织保持一致,同时降低运营成本。
Power Platform 简化
分类应影响体系结构决策。
Microsoft Purview 可提供对整个组织中数据资产的可见性。 有关更多信息,请参阅了解 Microsoft Purview。
Microsoft Purview 数据地图支持自动数据发现和敏感数据分类。 Microsoft Purview 和 Microsoft Dataverse 之间的集成将帮助您更好地了解和管理业务应用程序数据资产,保护数据,并改善其风险和合规性状况。
通过该集成,您可以:
- 创建一个涵盖 Microsoft Dynamics 365、Power Platform 和 Microsoft Purview 支持的其他来源的全面、最新的数据图。
- 根据内置的系统分类或用户定义的自定义分类,对数据资产进行自动分类,以帮助识别和了解敏感数据。
- 让数据消费者能够发现有价值、值得信赖的数据。
- 帮助数据管理员和安全管理员能够管理和保持数据资产安全,减少数据泄露,并更好地保护敏感数据。
有关详细信息,请参阅在 Microsoft Purview 中连接并管理 Microsoft Dataverse。
组织遵循情况
云采用框架为中心团队提供有关如何对数据进行分类的指导,以便工作负载团队可以遵循组织分类。
有关更多信息,请参见什么是数据分类?
相关信息
安全清单
请参考整套建议。