Разработка архитектуры схемы классификации для персональных данныхArchitect a classification schema for personal data

В предыдущих статьях из этой серии рассматривалось использование типов конфиденциальной информации для определения персональных данных, подпадающих под действие регламента GDPR. Типы конфиденциальной информации — это разновидность классификации. Возможно, вам понадобится только эта классификация. Тем не менее многие организации внедряют более широкую стратегию управления данными с использованием меток. Ознакомьтесь с этой статьей, чтобы решить, нужно ли вам внедрять метки в рамках своего плана по соблюдению регламента GDPR. Если вы примете это решение, воспользуйтесь инструкциями и примерами, приведенными в настоящей статье.Previous articles in this series focus on using sensitive information types to identify personal data that is subject to GDPR. Sensitive information types are a form of classification. This might be all the classification you need. However, many organizations implement a broader data governance strategy using labels. Use this topic to decide if you also want to implement labels as part of your GDPR plan. If you do, this topic provides some guidance and examples.

Примечание. Определение схемы классификации для организации и настройка политики, меток и условий требуют тщательного планирования и подготовки. Важно понимать, что за этот процесс не отвечает ваш ИТ-отдел. При разработке соответствующей схемы классификации и применения меток для данных вашей организации обязательно сотрудничайте со своим юридическим отделом и группой по обеспечению соответствия требованиям.Note: Defining a classification schema for an organization and configuring policies, labels, and conditions requires careful planning and preparation. It is important to realize that this is not an IT driven process. Be sure to work with your legal and compliance team to develop an appropriate classification and labeling schema for your organization’s data.

Принятие решения о целесообразности использования меток в дополнение к типам конфиденциальных данныхDecide if you are using labels in addition to sensitive data types

Вы можете воспользоваться одним из двух подходов к классификации персональных данных в Office 365. Любой из них можно применить для защиты данных в соответствии с регламентом GDPR. Если вы решили использовать для классификации только типы конфиденциальной информации, можете пропустить оставшуюся часть этой статьи.You can take one of two approaches for classification in Office 365 for personal information. Either of these can be used for GDPR protection. If decide to use only sensitive information types for classification, you can skip the rest of this topic.

Выберите один из приведенных ниже вариантов.Choose one of the following options.

Вариант 1. Использование только типов конфиденциальной информации Office 365Option 1: Use only Office 365 sensitive information types

  • Типы конфиденциальной информации целесообразно использовать для определения и защиты персональных данных, которые подпадают под действие регламента GDPR и других типов нормативных требований.Sensitive information types work well to identify and protect personal data subject to GDPR and other types of regulations.

  • Этот вариант более простой, чем расширенный план по управлению данными с использованием меток.These are simpler to use if your organization doesn’t already have or plan to implement a broader data governance plan using labels.

  • Типы конфиденциальной информации используются с правилами защиты от потери данных (как и метки Office).These work with DLP rules (so do Office labels).

  • В будущем их можно будет применять с Cloud App Security для обнаружения конфиденциальной информации в других приложениях SaaS.In the future these will work with Cloud App Security so you can detect sensitive information in other SaaS apps.

Вариант 2. Использование типов конфиденциальной информации и меток OfficeOption 2: Use sensitive information types + Office labels

  • Типы конфиденциальной информации — это необходимый компонент, так как они понадобятся для автоматического применения меток к персональным данным, подпадающим под действие регламента GDPR.You’ll need sensitive information types to automatically apply labels to personal data that is subject to GDPR, so these are a prerequisite.

  • Метки Office позволяют включить персональные данные, на которые распространяется регламент GDPR, в расширенный план по управлению данными для вашей организации.Using Office labels allows you to include personal data that is subject to GDPR into a broader data governance plan for your organization.

  • В будущем метки Office будут объединены с метками Azure Information Protection для создания единой подсистемы классификации и применения меток.Later, Office labels will converge with Azure Information Protection labels into a unified classification and labeling engine.

Разработка схемы меток, включающей персональные данныеDevelop a label schema that includes personal data

Прежде чем воспользоваться техническими возможностями для применения меток и защиты, сначала определите схему классификации для своей организации. Возможно, у нее уже имеется схема классификации, что упрощает добавление персональных данных. В этой статье приведен пример схемы классификации. При необходимости вы можете использовать его в качестве отправной точки.Before using technical capabilities to apply labels and protection, first work across your organization to define a classification schema. Your organization might already have a classification schema, which makes it easier to add personal data. This topic includes an example classification schema. You can use this as a starting point, if needed.

Начало работыGetting started

Сначала выберите количество и имена меток, которые необходимо внедрить. При этом не беспокойтесь об используемых технологиях и способах применения меток. Примените эту схему в пределах всей организации, в том числе к данным, которые хранятся в локальной среде и других облачных службах.Begin by deciding on the number and names of labels to implement. Do this activity without worrying about which technology to use and how labels will be applied. Apply this schema universally throughout your organization, including data that resides on premises and in other cloud services.

РекомендацииRecommendations

Разрабатывая и внедряя политики, метки и условия, руководствуйтесь вот какими рекомендациями.When designing and implementing policies, labels and conditions, consider following these recommendations:

  • Используйте имеющуюся схему классификации (при наличии). Многие организации уже пользуются определенными разновидностями классификации данных. Тщательно проанализируйте имеющуюся схему меток и по возможности используйте ее без изменений. Использование знакомых пользователя меток повысит эффективность их принятия.Use existing classification schema (if any) — Many organizations already are using data classification in some form. Carefully evaluate the existing label schema and if possible use it as is. Using familiar labels that are recognizable to the end-user will drive adoption.

  • В начале используйте стандартные политики и метки. Все решения поставляются с набором предопределенных политик и меток. Тщательно оцените, насколько они соответствуют вашим юридическим и бизнес-требованиям, и по возможности используйте именно их, а не создавайте новые.Start with default policies and labels — All solutions come with a set of predefined policies and labels. Carefully evaluate these against the organizations legal and business requirements and consider using them instead of creating new ones.

  • Начните с малого. Вы можете создать практически неограниченное количество меток. Тем не менее большое число основных и вложенных меток отрицательно скажется на их принятии. Слишком много вариантов выбора часто приводят к невозможности выбора.Start small — There is virtually no limit to the number of labels that can be created. However, large numbers of labels and sub-labels will negatively impact the adoption. Too many choices often means no choice at all.

  • Применяйте сценарии и варианты использования. Определите варианты использования, характерные для организации и созданные на основе регламента GDPR, чтобы проверить, будет ли предполагаемая конфигурация применения меток и классификации работать на практике.Use scenarios and use cases — Identify common use cases within the organization and use scenarios derived from the GDPR to verify if the envisioned label and classification configuration will work in practice.

  • Определите целесообразность использования новой метки в каждом запросе. Действительно ли нужна новая метка для каждого сценария или варианта использования, либо достаточно ли воспользоваться уже имеющейся меткой? Сведите количество меток к минимуму, чтобы улучшить их принятие.Question every request for a new label, does every scenario or use case really need a new label or can we use what we already have? Keeping the number of labels to a minimum improves adoption.

  • Используйте вложенные метки для ключевых отделов. Некоторые отделы отличаются особыми требованиями, для которых требуются особенные метки. Определите эти метки в качестве вложенных меток. Кроме того, рассмотрите возможность использования политик с областью действия, которые применяются к группам пользователей, а не ко всей организации.Use sub-labels for key departments, some departments will have specific needs that require specific labels. Define these labels as sub-labels to an existing label and consider using scoped policies that are assigned to user groups instead of globally.

  • Рассмотрите возможность использования политик с областью действия. Политики, нацеленные на определенные подмножества пользователей, предотвращают чрезмерное количество меток. Политика с областью действия позволяет назначить роль или относящиеся к конкретному отделу метки (в том числе вложенные) сотрудникам, которые работают именно в этом отделе.Consider scoped policies, polices targeted at subsets of users will prevent "label overload". A scoped policy enables assigning role or department specific (sub-)labels to just employees that work for that specific department.

  • Используйте понятные имена меток. В качестве имен меток не рекомендуется использовать жаргонные слова, стандартные сокращения или акронимы. Целесообразно использовать понятные пользователям имена, чтобы улучшить принятие меток. Например, вместо таких меток, как PII, PCI, HIPAA, LBI, MBI и HBI, используйте имена типа "Не бизнес-данные", "Общедоступные", "Общие", "Конфиденциально" и "Строго конфиденциально".Use meaningful label names, it is recommended not to use jargon, standards or acronyms as label names. Try to use names that resonate with the end user to improve adoption. Instead of using labels like PII, PCI, HIPAA, LBI, MBI and HBI consider names like Non-Business, Public, General, Confidential and Highly Confidential.

Пример схемы классификацииExample classification schema

Имя меткиLabel name ОписаниеDescription
ПерсональныеPersonal Не бизнес-данные, предназначенные только для личного использования.Non-business data, for personal use only.
ОбщедоступныеPublic Бизнес-данные, специально подготовленные и утвержденные для предоставления широкой публике.Business data that is specifically prepared and approved for public consumption.
Данные клиентаCustomer data Бизнес-данные, содержащие личные сведения, например номера кредитных карт, банковских счетов и социального страхования.Business data that contains personal identifiable information. Examples are credit card numbers, bank account numbers, and social security numbers.
Данные о персоналеHR data Данные отдела кадров о сотрудниках Contoso, например номер сотрудника и сведения о зарплате.Human Resource data about Contoso employees, such as employee number and salary data.
КонфиденциальноConfidential Конфиденциальные бизнес-данные, предоставление которых не тем людям может нанести ущерб организации. Примеры: контракты, отчеты системы безопасности, прогнозные сводки и данные о продажах клиентам.Sensitive business data that could cause damage to the business if shared with unauthorized people. Examples include contracts, security reports, forecast summaries, and sales account data.
Строго конфиденциальноHighly confidential Строго конфиденциальные бизнес-данные, предоставление которых не тем людям может нанести ущерб организации. Примеры: информация о сотрудниках и клиентах, пароли, исходный код и финансовые отчеты, о которых объявляется заранее.Very sensitive business data that would cause damage to the business if it was shared with unauthorized people. Examples include employee and customer information, passwords, source code, and pre-announced financial reports.

Определение таксономии и условий поиска для каждой меткиDefine a taxonomy and search criteria for each label

Следующий шаг после разработки схемы классификации для вашей организации — разработать таксономию и условия поиска этих данных. Вы уже выполнили эти задачи для персональных данных, определив типы конфиденциальной информации, а также настроив или создав новые типы конфиденциальной информации для своей среды.After developing a classification schema for your organization, the next step is to develop the taxonomy and search criteria for finding this data. For personal data, you’ve already completed this work by identifying sensitive information types and also by customizing or creating new sensitive information types for your environment.

В таблице ниже приведен пример схемы, таксономии и условий поиска для организации. Метки упорядочены по уровню конфиденциальности от наименее до наиболее конфиденциальных, чтобы гарантировать назначение правильной метки данным, которые соответствуют нескольким условиям метки.The following table provides an example schema, taxonomy, and search criteria for an organization. The labels are ordered by sensitivity level from least sensitive to most sensitive to ensure that data that matches multiple label conditions is assigned the appropriate label.

Примечание. Этот пример конфигурации приведен исключительно для иллюстрации и не предназначен для использования в качестве руководства или справки по развертыванию.Note: The configuration example is provided for illustration only and is not intended as deployment guidance or reference.

Крайне важно убедиться, что ваши действия по классификации персональных данных для соответствия требованиям регламента GDPR сочетаются с целями всей организации.The important takeaway is to ensure that the work you invest to classify personal data for GDPR compliance fits together with the objectives for your entire organization.

Пример схемы, таксономии и условий поискаExample schema, taxonomy, and search criteria

МеткаLabel ТаксономияTaxonomy МетодMethod Синтаксис поискаSearch syntax
ПерсональныеPersonal Документы, к которым пользователь вручную применил метку как к персональным.Documents manually labelled personal by the end user. ВручнуюManual Документы, к которым пользователь вручную применил метку как к персональным.Documents manually labelled personal by the end user.
ОбщедоступныеPublic Документы, содержащие фразу Approved for Public Release ##/#### (без учета регистра), где # представляет собой любую цифру.Documents containing the case insensitive phrase Approved for Public Release ##/#### where # represents any digit.

KQLKQL

Регулярное выражениеRegEx

KQL — Approved for Public Release (Утверждено для общедоступного выпуска)*KQL — Approved for Public Release*

Регулярное выражение — (?i)(\bApproved for Public Release \d{2}/\d{4}\b)RegEx — (?i)(\bApproved for Public Release \d{2}/\d{4}\b)

Данные клиентаCustomer data Типы конфиденциальной информации о гражданах стран ЕС.Sensitive information types for EU citizen data. Типы конфиденциальной информацииSensitive information types
Управление персоналом — данные о сотрудникахHuman Resources — Employee Data Документы, включающие идентификатор сотрудника (с учетом регистра) в формате CONTOSO-9#####, где # представляет собой любую цифру.Documents that include the case sensitive employee id in the format CONTOSO-9##### where # represents any digit.

KQLKQL

Регулярное выражениеRegEx

KQL — CONTOSO-9*KQL — CONTOSO-9*

Регулярное выражение — (\bCONTOSO-9\d{5}\b)RegEx — (\bCONTOSO-9\d{5}\b)

Управление персоналом — данные о зарплатеHuman Resources — Salary Data Документы, включающие ключевое слово (без учета регистра) Contoso и ключевое слово (без учета регистра) Salary или CompensationDocuments that include the keyword (not case sensitive) Contoso AND either keyword (not case sensitive) Salary OR Compensation

KQLKQL

Регулярное выражениеRegEx

KQL — Contoso AND (Salary OR Compensation)KQL — Contoso AND (Salary OR Compensation)

Регулярное выражение — (\bCONTOSO-9\d{5}\b)RegEx — (\bCONTOSO-9\d{5}\b)

КонфиденциальноConfidential Документы, содержащие фразу Contoso Confidential (без учета регистра).Documents containing the phrase (not case sensitive) Contoso Confidential.

KQLKQL

Регулярное выражениеRegEx

KQL — Contoso ConfidentialKQL — Contoso Confidential

Регулярное выражение — (?i)(\bContoso Confidential\b)RegEx — (?i)(\bContoso Confidential\b)

Строго конфиденциальноHighly confidential Документы, содержащие фразу (с учетом регистра) Contoso Secret или Secret-C####, где # представляет собой любую цифру.Documents that include either pharase (case sensitive) Contoso Secret or Secret-C#### where # represents any digit.

KQLKQL

Регулярное выражениеRegEx

KQL — Contoso Secret OR Secret-C*KQL — Contoso Secret OR Secret-C*

Регулярное выражение — (?i)(\bContoso Secret\b)|(\bSecret-C\d{4}\b)RegEx — (?i)(\bContoso Secret\b)|(\bSecret-C\d{4}\b)