Создание пользовательского типа конфиденциальной информации с помощью PowerShell

  • Статья

В этой статье показано, как создать файл пакета правил XML, который определяет настраиваемые типы конфиденциальной информации. В этой статье описывается настраиваемый тип конфиденциальной информации, который идентифицирует идентификатор сотрудника. Вы можете использовать пример XML, приведенный в этой статье, в качестве отправной точки для собственного XML-файла.

Дополнительные сведения о типах конфиденциальной информации см. в статье Сведения о типах конфиденциальной информации.

После создания ПРАВИЛЬНО сформированного XML-файла его можно отправить в Microsoft 365 с помощью PowerShell. Затем вы можете использовать настраиваемый тип конфиденциальной информации в политиках. Вы можете проверить его эффективность в обнаружении конфиденциальной информации, как вы планировали.

Примечание.

Если вам не нужен точный элемент управления, который предоставляет PowerShell, можно создать пользовательские типы конфиденциальной информации в Портал соответствия требованиям Microsoft Purview. Дополнительные сведения см. в статье Создание пользовательского типа конфиденциальной информации.

Совет

Если вы не являетесь клиентом E5, используйте 90-дневную пробную версию решений Microsoft Purview, чтобы узнать, как дополнительные возможности Purview могут помочь вашей организации управлять безопасностью данных и соответствием требованиям. Начните сейчас, перейдя в центр пробных версий на портале соответствия требованиям Microsoft Purview. Сведения о регистрации и условиях пробной версии.

Отказ от ответственности

служба поддержки Майкрософт не может помочь вам создать определения, соответствующие содержимому.

Для разработки, тестирования и отладки с сопоставлением пользовательского содержимого необходимо использовать собственные внутренние ИТ-ресурсы или консультационные услуги, такие как Консультационные службы Майкрософт (MCS). служба поддержки Майкрософт инженеры могут предоставить ограниченную поддержку этой функции, но они не могут гарантировать, что пользовательские предложения по соответствоватию содержимого полностью соответствуют вашим потребностям.

MCS может предоставлять регулярные выражения для тестирования. Они также могут помочь в устранении неполадок существующего шаблона regEx, который не работает должным образом с одним конкретным примером содержимого.

Сведения о потенциальных проблемах с проверкой см . в этой статье.

Дополнительные сведения о модуле Boost.RegEx (прежнее название — RegEx++), который используется для обработки текста, см. на странице Boost.Regex 5.1.3.

Примечание.

Если вы используете символ амперсанда (&) как часть ключевое слово в пользовательском типе конфиденциальной информации, необходимо добавить дополнительный термин с пробелами вокруг символа. Например, используйте notL&PL & P.

Пример XML-файла пакета правил

Ниже приведен пример XML пакета правил, который мы создадим в этой статье. Элементы и атрибуты описаны в следующих разделах.

<?xml version="1.0" encoding="UTF-16"?>
<RulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
<RulePack id="DAD86A92-AB18-43BB-AB35-96F7C594ADAA">
  <Version build="0" major="1" minor="0" revision="0"/>
  <Publisher id="619DD8C3-7B80-4998-A312-4DF0402BAC04"/>
  <Details defaultLangCode="en-us">
    <LocalizedDetails langcode="en-us">
      <PublisherName>Contoso</PublisherName>
      <Name>Employee ID Custom Rule Pack</Name>
      <Description>
      This rule package contains the custom Employee ID entity.
      </Description>
    </LocalizedDetails>
  </Details>
</RulePack>
<Rules>
<!-- Employee ID -->
  <Entity id="E1CC861E-3FE9-4A58-82DF-4BD259EAB378" patternsProximity="300" recommendedConfidence="75">
    <Pattern confidenceLevel="65">
      <IdMatch idRef="Regex_employee_id"/>
    </Pattern>
    <Pattern confidenceLevel="75">
      <IdMatch idRef="Regex_employee_id"/>
      <Match idRef="Func_us_date"/>
    </Pattern>
    <Pattern confidenceLevel="85">
      <IdMatch idRef="Regex_employee_id"/>
      <Match idRef="Func_us_date"/>
      <Any minMatches="1">
        <Match idRef="Keyword_badge" minCount="2"/>
        <Match idRef="Keyword_employee"/>
      </Any>
      <Any minMatches="0" maxMatches="0">
        <Match idRef="Keyword_false_positives_local"/>
        <Match idRef="Keyword_false_positives_intl"/>
      </Any>
    </Pattern>
  </Entity>
  <Regex id="Regex_employee_id">(\s)(\d{9})(\s)</Regex>
  <Keyword id="Keyword_employee">
    <Group matchStyle="word">
      <Term>Identification</Term>
      <Term>Contoso Employee</Term>
    </Group>
  </Keyword>
  <Keyword id="Keyword_badge">
    <Group matchStyle="string">
      <Term>card</Term>
      <Term>badge</Term>
      <Term caseSensitive="true">ID</Term>
    </Group>
  </Keyword>
  <Keyword id="Keyword_false_positives_local">
    <Group matchStyle="word">
      <Term>credit card</Term>
      <Term>national ID</Term>
    </Group>
  </Keyword>
  <Keyword id="Keyword_false_positives_intl">
    <Group matchStyle="word">
      <Term>identity card</Term>
      <Term>national ID</Term>
      <Term>EU debit card</Term>
    </Group>
  </Keyword>
  <LocalizedStrings>
    <Resource idRef="E1CC861E-3FE9-4A58-82DF-4BD259EAB378">
      <Name default="true" langcode="en-us">Employee ID</Name>
      <Description default="true" langcode="en-us">
      A custom classification for detecting Employee IDs.
      </Description>
      <Description default="false" langcode="de-de">
      Description for German locale.
      </Description>
    </Resource>
  </LocalizedStrings>
</Rules>
</RulePackage>

Каковы ваши основные требования? [Элементы Rule, Entity, Pattern]

Важно понимать базовую структуру XML-схемы для правила. Ваше понимание структуры помогает пользовательскому типу конфиденциальной информации определить правильное содержимое.

Правило определяет одну или несколько сущностей (также известных как типы конфиденциальной информации). Каждая сущность определяет один или несколько шаблонов. Шаблон — это то, что ищет политика при оценке содержимого (например, электронной почты и документов).

В разметке XML "правила" означают шаблоны, определяющие тип конфиденциальной информации. Не связывайте ссылки на правила в этой статье с "условиями" или "действиями", которые являются общими в других функциях Майкрософт.

Простейший сценарий: объект с одним шаблоном

Вот простой сценарий. Вы хотите, чтобы политика определила содержимое, содержащее девятизначные идентификаторы сотрудников, которые используются в вашей организации. Шаблон ссылается на регулярное выражение в правиле, которое идентифицирует девятизначные числа. Любое содержимое, содержащее девятизначное число, удовлетворяет шаблону.

Схема сущности с одним шаблоном.

Но этот шаблон может идентифицировать любое девятизначное число, включая более длинные или другие типы девятизначных чисел, которые не являются идентификаторами сотрудников. Этот тип нежелательного совпадения называется ложноположительным результатом.

Более распространенный сценарий: объект с несколькими шаблонами

Из-за возможности ложноположительных результатов обычно используется несколько шаблонов для определения сущности. Несколько шаблонов предоставляют подтверждающие доказательства для целевой сущности. Например, дополнительные ключевые слова, даты или другой текст могут помочь определить исходную сущность (например, девятизначный номер сотрудника).

Например, чтобы повысить вероятность идентификации содержимого, содержащего идентификатор сотрудника, можно определить другие шаблоны для поиска:

  • Шаблон, определяющий дату найма.
  • Шаблон, определяющий дату найма и "идентификатор сотрудника" ключевое слово.

Схема сущности с несколькими шаблонами.

Для совпадений с несколькими шаблонами следует учитывать важные моменты.

  • Шаблоны, требующие наличия дополнительных признаков, имеют более высокий уровень доверия. В зависимости от уровня достоверности можно выполнить следующие действия:

    • Используйте более строгие действия (например, блокировать содержимое) с более высоким уровнем достоверности.
    • Используйте менее строгие действия (например, отправку уведомлений) с более низким уровнем достоверности.

  • Вспомогательные IdMatch элементы и Match ссылаются на regExes и ключевые слова, которые фактически являются дочерними элементами Rule элемента, а не .Pattern СсылкиPattern на вспомогательные элементы, но они включены в .Rule Это означает, что на одно определение вспомогательного элемента, например регулярное выражение или список ключевое слово, можно ссылаться с помощью нескольких сущностей и шаблонов.

Какую сущность необходимо идентифицировать? [Элемент Entity, атрибут ID]

Сущность — это тип конфиденциальной информации, например номер кредита карта, имеющий четко определенный шаблон. У каждой сущности есть уникальный идентификатор GUID.

Присваивание объекту имени и создание GUID для него

  1. В выбранном редакторе Rules XML добавьте элементы и Entity .
  2. Добавьте комментарий, содержащий имя пользовательской сущности, например идентификатор сотрудника. Позже вы добавите имя сущности в раздел локализованных строк, и это имя появится в Центре администрирования при создании политики.
  3. Создайте уникальный GUID для сущности. Например, в Windows PowerShell можно выполнить команду [guid]::NewGuid(). Позже вы также добавите GUID в раздел локализованных строк сущности.

Разметка XML с элементами Rules и Entity.

Какой шаблон вы хотите сопоставить? [Элемент Pattern, Элемент IdMatch, Элемент Regex]

Шаблон содержит список того, что ищет тип конфиденциальной информации. Шаблон может включать RegExes, ключевые слова и встроенные функции. Функции выполняют такие задачи, как выполнение регулярных выражений для поиска дат или адресов. Типы конфиденциальных данных могут использовать несколько шаблонов с уникальными уровнями вероятности.

На следующей схеме все шаблоны ссылались на одно регулярное выражение. Этот regEx ищет девятизначное число (\d{9}) , окруженное пробелом (\s) ... (\s). Элемент IdMatch ссылается на это регулярное выражение и является общим требованием для всех шаблонов, которые ищут сущность Employee ID. IdMatch — это идентификатор, который шаблон пытается сопоставить. Элемент Pattern должен содержать только один IdMatch элемент.

Разметка XML, показывающая несколько элементов Pattern, ссылающихся на один элемент Regex.

Совпадение шаблона возвращает количество и уровень достоверности, которые можно использовать в условиях в политике. При добавлении условия для обнаружения типа конфиденциальной информации в политику можно изменить количество и уровень достоверности, как показано на следующей схеме. Уровень достоверности (также называемый точностью соответствия) объясняется далее в этой статье.

Параметры количества экземпляров и точности соответствия.

Регулярные выражения являются мощными, поэтому существуют проблемы, о которых необходимо знать. Например, регулярные выражения, определяющие слишком много содержимого, могут повлиять на производительность. Дополнительные сведения об этих проблемах см. в разделе Потенциальные проблемы проверки , о которых следует знать далее в этой статье.

Требовать дополнительных доказательств? [Элемент Match, атрибут minCount]

В дополнение к IdMatchшаблону можно использовать Match элемент для требования дополнительных подтверждающих доказательств, таких как ключевое слово, regEx, date или address.

Может Pattern включать несколько Match элементов:

  • Непосредственно в элементе Pattern .
  • Объединяется с помощью Any элемента .

Match элементы соединяются с неявным оператором AND. Иными словами, все Match элементы должны быть удовлетворены для сопоставления шаблона.

Элемент можно использовать для Any введения операторов AND или OR. Элемент Any описан далее в этой статье.

Можно использовать необязательный minCount атрибут, чтобы указать, сколько экземпляров совпадения необходимо найти для каждого Match элемента. Например, можно указать, что шаблон удовлетворяется только при обнаружении по крайней мере двух ключевых слов из списка ключевое слово.

Разметка XML с элементом Match с атрибутом minOccurs.

Ключевые слова [элементы Keyword, Group и Term, атрибуты matchStyle и caseSensitive]

Как упоминалось ранее, для идентификации конфиденциальной информации часто требуются дополнительные ключевые слова в качестве подтверждающих доказательств. Например, помимо сопоставления девятизначного числа, можно искать такие слова, как "карта", "эмблема" или "идентификатор", используя элемент keyword. Элемент Keyword имеет ID атрибут, на который могут ссылаться несколько Match элементов в нескольких шаблонах или сущностях.

Ключевые слова включаются в список Term элементов в элементе Group . Элемент Group имеет matchStyle атрибут с двумя возможными значениями:

  • matchStyle="word": совпадение слов идентифицирует целые слова, окруженные пробелами или другими разделителями. Вы всегда должны использовать слово , если вам не нужно сопоставлять части слов или слов в азиатских языках.

  • matchStyle="string": сопоставление строк идентифицирует строки независимо от того, что они окружены. Например, "ID" соответствует как "bid", так и "idea". Используйте string только в том случае, если вам нужно соответствовать азиатским словам или если ключевое слово могут быть включены в другие строки.

Наконец, можно использовать caseSensitive атрибут Term элемента, чтобы указать, что содержимое должно точно соответствовать ключевое слово, включая строчные и прописные буквы.

Разметка XML, показывающая элементы Match, ссылающиеся на ключевые слова.

Регулярные выражения [элемент Regex]

В этом примере сущность employee ID уже использует IdMatch элемент для ссылки на регулярное выражение для шаблона: девятизначное число, окруженное пробелом. Кроме того, шаблон может использовать Match элемент для ссылки на дополнительный Regex элемент для идентификации подтверждающих доказательств, таких как пятизначный или девятизначный номер в формате почтового индекса США.

Дополнительные шаблоны, например даты или адреса [встроенные функции]

Типы конфиденциальной информации также могут использовать встроенные функции для выявления подтверждающих доказательств. Например, дата в США, дата ЕС, дата окончания срока действия или адрес США. Microsoft 365 не поддерживает отправку собственных пользовательских функций. Но при создании пользовательского типа конфиденциальной информации сущность может ссылаться на встроенные функции.

Например, значок идентификатора сотрудника содержит дату найма, поэтому эта пользовательская сущность может использовать встроенную Func_us_date функцию для идентификации даты в формате, обычно используемом в США.

Дополнительные сведения см. в разделе Функции типов конфиденциальной информации.

Разметка XML, показывающая элемент Match, ссылающийся на встроенную функцию.

Различные сочетания признаков [элемент Any, атрибуты minMatches и maxMatches]

В элементе Pattern все IdMatch элементы и Match соединяются с неявным оператором AND. Другими словами, все совпадения должны быть удовлетворены, прежде чем шаблон может быть удовлетворен.

Вы можете создать более гибкую логику сопоставления, используя элемент для группировки AnyMatch элементов. Например, можно использовать Any элемент для сопоставления всех, ни одного или точного подмножества его дочерних Match элементов.

Элемент Any имеет необязательные minMatches атрибуты и maxMatches , которые можно использовать, чтобы определить, сколько дочерних Match элементов должно быть удовлетворено, прежде чем шаблон будет сопоставлен. Эти атрибуты определяют количествоMatch элементов, а не число экземпляров доказательств, найденных для совпадений. Чтобы определить минимальное количество экземпляров для определенного совпадения, например два ключевых слова из списка, используйте minCount атрибут для Match элемента (см. выше).

Совпадение для хотя бы одного дочернего элемента Match

Чтобы требовать только минимальное количество Match элементов, можно использовать minMatches атрибут . Фактически эти Match элементы объединяются с неявным оператором OR. Этот Any элемент удовлетворяется, если найдена дата в формате США или ключевое слово из любого списка.

<Any minMatches="1" >
     <Match idRef="Func_us_date" />
     <Match idRef="Keyword_employee" />
     <Match idRef="Keyword_badge" />
</Any>

Точное соответствие подмножеству любых дочерних элементов Match

Чтобы требовать точное количество Match элементов, задайте minMatches для и одно и maxMatches то же значение. Этот Any элемент удовлетворяется только в том случае, если найдена ровно одна дата или ключевое слово. Если есть еще какие-либо совпадения, шаблон не совпадает.

<Any minMatches="1" maxMatches="1" >
     <Match idRef="Func_us_date" />
     <Match idRef="Keyword_employee" />
     <Match idRef="Keyword_badge" />
</Any>

Не соответствует ни одному из дочерних элементов Match

Если вы хотите требовать отсутствию конкретных доказательств для удовлетворения шаблона, можно задать как minMatches, так и maxMatches значение 0. Это может быть полезно, если у вас есть список ключевое слово или другие доказательства, которые, скорее всего, указывают на ложноположительный результат.

Например, сущность идентификатора сотрудника ищет ключевое слово "карта", так как она может ссылаться на "id карта". Однако если карта отображается только во фразе "кредит карта", то "карта" в этом содержимом вряд ли будет означать "идентификатор карта". Таким образом, вы можете добавить "кредитную карта" в качестве ключевое слово в список терминов, которые вы хотите исключить из соответствия шаблону.

<Any minMatches="0" maxMatches="0" >
    <Match idRef="Keyword_false_positives_local" />
    <Match idRef="Keyword_false_positives_intl" />
</Any>

Сопоставление нескольких уникальных терминов

Если вы хотите сопоставить несколько уникальных терминов, используйте параметр uniqueResults , присвойте значение true, как показано в следующем примере:

<Pattern confidenceLevel="75">
    <IdMatch idRef="Salary_Revision_terms" />
    <Match idRef=" Salary_Revision_ID " minCount="3" uniqueResults="true" />
</Pattern>

В этом примере определен шаблон для исправления заработной платы с использованием не менее трех уникальных совпадений.

Насколько близко к сущности должны быть другие доказательства? [атрибут patternsProximity]

Тип конфиденциальной информации ищет шаблон, представляющий идентификатор сотрудника, и в рамках этого шаблона он также ищет подтверждающие доказательства, такие как ключевое слово, например идентификатор. Имеет смысл, что чем ближе эти доказательства, тем более вероятно, что шаблон будет фактическим идентификатором сотрудника. Вы можете определить, насколько близко должно быть другое свидетельство в шаблоне к сущности, используя обязательный атрибут patternsProximity элемента Entity.

Разметка XML, показывающая атрибут patternsProximity.

Для каждого шаблона в сущности значение атрибута patternsProximity определяет расстояние (в символах Юникода) от расположения IdMatch для всех остальных совпадений, указанных для этого шаблона. Окно близости с помощью расположения элемента IdMatch привязывается к окну по левую и правую сторону элемента IdMatch.

Схема окна близкого взаимодействия.

В приведенном ниже примере показано, как окно близкого взаимодействия влияет на сопоставление шаблонов, где элементу IdMatch для пользовательской сущности идентификатора сотрудника требуется по крайней мере одно подтверждение соответствия ключевое слово или даты. Совпадает только идентификатор ID1, так как для идентификаторов ID2 и ID3 в окне близкого взаимодействия не найдены либо частичные подтверждающие доказательства.

Схема подтверждающих доказательств и окна близкого взаимодействия.

Для электронной почты текст сообщения и каждое вложение обрабатываются как отдельные элементы. Это означает, что окно близкого взаимодействия не выходит за пределы конца каждого из этих элементов. Для каждого элемента (вложения или текста) в этом элементе должны находиться как свидетельство idMatch, так и подтверждение.

Какие уровни доверия подходят для различных шаблонов? [атрибут confidenceLevel, рекомендуемый атрибутConfidence]

Чем больше доказательств, необходимых шаблону, тем больше уверенности в том, что при сопоставлении шаблона была обнаружена фактическая сущность (например, идентификатор сотрудника). Например, вы больше уверены в шаблоне, который требует девятизначного номера идентификатора, даты найма и ключевое слово в непосредственной близости, чем в шаблоне, который требует только девятизначного идентификатора.

У элемента Pattern есть обязательный атрибут confidenceLevel. Значение confidenceLevel (значение 65/75/85, указывающее низкий,средний/высокий уровень достоверности) можно представить как уникальный идентификатор для каждого шаблона в сущности. После того как вы добавите свой пользовательский тип конфиденциальной информации и создадите политику, вы сможете ссылаться на эти уровни доверия в условиях создаваемых вами правил.

Разметка XML с элементами Pattern с разными значениями атрибута confidenceLevel.

Помимо атрибута confidenceLevel, у каждого элемента Pattern имеется также атрибут recommendedConfidence. Его можно рассматривать как уровень доверия по умолчанию для данного правила. Если вы создаете правило в политике, если вы не указываете уровень доверия для используемого правила, это правило соответствует рекомендуемму уровню достоверности для сущности. Обратите внимание, что атрибут recommendedConfidence является обязательным для каждого идентификатора сущности в пакете правил. Если он отсутствует, вы не сможете сохранить политики, использующие тип конфиденциальной информации.

Вы хотите поддерживать другие языки в пользовательском интерфейсе портала соответствия требованиям? [Элемент LocalizedStrings]

Если ваша команда по соответствию требованиям использует Портал соответствия требованиям Microsoft Purview для создания политик в разных языковых стандартах и на разных языках, вы можете предоставить локализованные версии имени и описания настраиваемого типа конфиденциальной информации. При работе с Microsoft 365 на поддерживаемом вами языке члены вашей группы соответствия требованиям будут видеть локализованные имена в пользовательском интерфейсе.

Настройка количества экземпляров и точности соответствия.

Элемент Rules должен содержать элемент LocalizedStrings, который содержит элемент Resource, который ссылается на GUID пользовательской сущности. В свою очередь, каждый элемент Resource содержит один или несколько элементов Name и Description, каждый из которых использует langcode атрибут для предоставления локализованной строки для определенного языка.

Разметка XML, показывающая содержимое элемента LocalizedStrings.

Обратите внимание, что локализованные строки определяют только способ отображения пользовательского типа конфиденциальных данных в пользовательском интерфейсе центра соответствия требованиям. Вам не удастся использовать локализованные строки для предоставления различных локализованных версий списка ключевых слов или регулярного выражения.

Еще одна разметка пакета правил [GUID RulePack]

Наконец, в начале каждого элемента RulePackage содержатся некоторые общие сведения, которые необходимо заполнить. Вы можете использовать следующую разметку в качестве шаблона и заменить ". . Заполнители ." с вашими собственными сведениями.

Самое главное, необходимо создать GUID для RulePack. Ранее вы создали GUID для сущности; это второй ИДЕНТИФИКАТОР GUID для RulePack. Существует несколько способов создания GUID, но вы можете легко это сделать в PowerShell, введя [guid]::NewGuid().

Элемент Version также важен. При первой отправке пакета правил Microsoft 365 отмечает номер версии. Позже, если вы обновите пакет правил и отправите новую версию, обязательно обновите номер версии, иначе Microsoft 365 не развернет пакет правил.

<?xml version="1.0" encoding="utf-16"?>
<RulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
  <RulePack id=". . .">
    <Version major="1" minor="0" build="0" revision="0" />
    <Publisher id=". . ." />
    <Details defaultLangCode=". . .">
      <LocalizedDetails langcode=" . . . ">
         <PublisherName>. . .</PublisherName>
         <Name>. . .</Name>
         <Description>. . .</Description>
      </LocalizedDetails>
    </Details>
  </RulePack>

 <Rules>
  . . .
 </Rules>
</RulePackage>

По завершении этих действий элемент RulePack должен выглядеть, как показано ниже.

Разметка XML с элементом RulePack.

Валидаторы

Microsoft 365 предоставляет обработчики функций для часто используемых SIT в качестве проверяющих элементов. Вот их список.

Список доступных в настоящее время проверяющих элементов

  • Func_credit_card
  • Func_ssn
  • Func_unformatted_ssn
  • Func_randomized_formatted_ssn
  • Func_randomized_unformatted_ssn
  • Func_aba_routing
  • Func_south_africa_identification_number
  • Func_brazil_cpf
  • Func_iban
  • Func_brazil_cnpj
  • Func_swedish_national_identifier
  • Func_india_aadhaar
  • Func_uk_nhs_number
  • Func_Turkish_National_Id
  • Func_australian_tax_file_number
  • Func_usa_uk_passport
  • Func_canadian_sin
  • Func_formatted_itin
  • Func_unformatted_itin
  • Func_dea_number_v2
  • Func_dea_number
  • Func_japanese_my_number_personal
  • Func_japanese_my_number_corporate

Это позволяет определить собственные регулярные выражения и проверить их. Чтобы использовать проверяющие элементы, определите собственный regEx и используйте Validator свойство , чтобы добавить обработчик функций по своему выбору. После определения вы можете использовать этот regEx в SIT.

В приведенном ниже примере регулярное выражение — Regex_credit_card_AdditionalDelimiters определяется для Credit карта, который затем проверяется с помощью функции контрольной суммы для кредитных карта с помощью Func_credit_card в качестве проверяющего элемента.

<Regex id="Regex_credit_card_AdditionalDelimiters" validators="Func_credit_card"> (?:^|[\s,;\:\(\)\[\]"'])([0-9]{4}[ -_][0-9]{4}[ -_][0-9]{4}[ -_][0-9]{4})(?:$|[\s,;\:\(\)\[\]"'])</Regex>
<Entity id="675634eb7-edc8-4019-85dd-5a5c1f2bb085" patternsProximity="300" recommendedConfidence="85">
<Pattern confidenceLevel="85">
<IdMatch idRef="Regex_credit_card_AdditionalDelimiters" />
<Any minMatches="1">
<Match idRef="Keyword_cc_verification" />
<Match idRef="Keyword_cc_name" />
<Match idRef="Func_expiration_date" />
</Any>
</Pattern>
</Entity>

Microsoft 365 предоставляет два универсальных проверяющих элемента

Проверяющий элемент контрольной суммы

В этом примере определяется проверяющий элемент контрольной суммы для идентификатора сотрудника для проверки regEx для EmployeeID.

<Validators id="EmployeeIDChecksumValidator">
<Validator type="Checksum">
<Param name="Weights">2, 2, 2, 2, 2, 1</Param>
<Param name="Mod">28</Param>
<Param name="CheckDigit">2</Param> <!-- Check 2nd digit -->
<Param name="AllowAlphabets">1</Param> <!— 0 if no Alphabets -->
</Validator>
</Validators>
<Regex id="Regex_EmployeeID" validators="ChecksumValidator">(\d{5}[A-Z])</Regex>
<Entity id="675634eb7-edc8-4019-85dd-5a5c1f2bb085" patternsProximity="300" recommendedConfidence="85">
<Pattern confidenceLevel="85">
<IdMatch idRef="Regex_EmployeeID"/>
</Pattern>
</Entity>

Проверяющий элемент даты

В этом примере для части регулярного выражения определяется проверяющий элемент даты, который является date.

<Validators id="date_validator_1"> <Validator type="DateSimple"> <Param name="Pattern">DDMMYYYY</Param> <!—supported patterns DDMMYYYY, MMDDYYYY, YYYYDDMM, YYYYMMDD, DDMMYYYY, DDMMYY, MMDDYY, YYDDMM, YYMMDD --> </Validator> </Validators>
<Regex id="date_regex_1" validators="date_validator_1">\d{8}</Regex>

Изменения для Exchange Online

Ранее вы могли использовать Exchange Online PowerShell для импорта собственных типов конфиденциальной информации для защиты от потери данных. Теперь пользовательские типы конфиденциальной информации можно использовать как в Центре администрирования Exchange]"https://go.microsoft.com/fwlink/p/?linkid=2059104" ;), так и в Портал соответствия требованиям Microsoft Purview. В рамках этого улучшения следует использовать PowerShell для обеспечения соответствия требованиям безопасности & для импорта пользовательских типов конфиденциальной информации. Их больше нельзя импортировать из Exchange Online PowerShell. Пользовательские типы конфиденциальной информации будут работать так же, как раньше, но изменения, внесенные в них в центре соответствия требования, могут быть отражены в центре администрирования Exchange не сразу, а в течение часа.

Обратите внимание, что для отправки пакета правил в центре соответствия требованиям можно использовать командлет New-DlpSensitiveInformationTypeRulePackage. (Ранее в Центре администрирования Exchange использовался командлет ClassificationRuleCollection.)

Отправка пакета правил

Чтобы отправить пакет правил, выполните указанные ниже действия.

  1. Сохраните правило в виде XML-файла с кодировкой Юникод.

  2. Подключение к PowerShell безопасности и соответствия требованиям

  3. Используйте указанный ниже синтаксис.

    New-DlpSensitiveInformationTypeRulePackage -FileData ([System.IO.File]::ReadAllBytes('PathToUnicodeXMLFile'))

    В этом примере выполняется отправка XML-файла с кодировкой Юникод под названием MyNewRulePack.xml из папки C:\My Documents.

    New-DlpSensitiveInformationTypeRulePackage -FileData ([System.IO.File]::ReadAllBytes('C:\My Documents\MyNewRulePack.xml'))

    Дополнительные сведения о синтаксисе и параметрах см. в статье New-DlpSensitiveInformationTypeRulePackage.

    Примечание.

    Максимальное количество поддерживаемых пакетов правил — 10, но каждый пакет может содержать определение нескольких типов конфиденциальной информации.

  4. Чтобы убедиться, что вы успешно создали новый тип конфиденциальной информации, выполните любое из указанных ниже действий.

    • Выполните командлет Get-DlpSensitiveInformationTypeRulePackage, чтобы проверить наличие нового пакета правил:

      Get-DlpSensitiveInformationTypeRulePackage

    • Выполните командлет Get-DlpSensitiveInformationType, чтобы проверить наличие типа конфиденциальных данных:

      Get-DlpSensitiveInformationType

      Для пользовательских типов конфиденциальных данных значение свойства Publisher будет отличаться от "Корпорация Майкрософт".

    • Замените <Name> значением Name типа конфиденциальных данных (например, Employee ID) и выполните командлет Get-DlpSensitiveInformationType:

      Get-DlpSensitiveInformationType -Identity "<Name>"

Проблемы, которые могут возникнуть при проверке

При отправке XML-файла пакета правил система проверяет XML-код и проверяет наличие известных неправильных шаблонов и очевидных проблем с производительностью. Ниже приведены некоторые известные проблемы, на наличие которых проверяет проверка — регулярное выражение:

  • Утверждения lookbehind в регулярном выражении должны иметь только фиксированную длину. Утверждения переменной длины приведут к ошибкам.

    Например, "(?<=^|\s|_)" не пройдет проверку. Первый шаблон (^) имеет нулевую длину, а следующие два шаблона (\s и _) имеют длину одного. Альтернативный способ записи этого регулярного выражения — "(?:^|(?<=\s|_))".

  • Не может начинаться или заканчиваться с переменным , |который соответствует всем, так как он считается пустым совпадением.

    Например, |a или b| не пройдет проверку.

  • Не может начинаться или заканчиваться шаблоном .{0,m} , который не имеет функционального назначения и только ухудшает производительность.

    Например, .{0,50}ASDF или ASDF.{0,50} не пройдет проверку.

  • Не может иметь .{0,m} или .{1,m} в группах и не может иметь .\* или .+ в группах.

    Например, (.{0,50000}) не пройдет проверку.

  • Не может содержать символы с повторителями {0,m} или {1,m} в группах.

    Например, (a\*) не пройдет проверку.

  • Не может начинаться или заканчиваться на .{1,m}; вместо этого используйте ..

    Например, .{1,m}asdf не пройдет проверку. Вместо этого используйте .asdf.

  • Не может иметь неограниченный ретранслятор (например, * или +) в группе.

    Например, (xx)\* и (xx)+ не пройдет проверку.

  • Длина ключевых слов не должна превышать 50 символов. Если в группе есть ключевое слово, которое превышает это значение, рекомендуется создать группу терминов в виде словаря ключевых слов и ссылаться на его GUID в структуре XML в рамках объекта для поиска совпадения Match или idMatch в файле.

  • Каждый настраиваемый тип конфиденциальной информации не должен превышать 2048 ключевых слов.

  • Максимальный размер словарей ключевых слов в одном клиенте составляет 480 КБ в соответствии с ограничениями схемы AD. При создании настраиваемых типов конфиденциальной информации ссылайтесь на один и тот же словарь столько раз, сколько необходимо. Начните с создания настраиваемых списков ключевых слов в типе конфиденциальной информации и используйте словари ключевых слов, если в списке ключевых слов их больше чем 2048 или если длина ключевого слова превышает 50 символов.

  • В клиенте разрешено использовать не более 50 типов конфиденциальной информации на основе словаря ключевых слов.

  • Убедитесь, что каждая сущность элемента содержит атрибут recommendedConfidence.

  • При использовании командлета PowerShell максимальный возвращаемый размер десериализованных данных составляет около 1 мегабайта. Это влияет на размер XML-файла пакета правил. Не следует превышать рекомендуемый лимит максимального размера загруженного файла (770 мегабайт) для получения стабильных результатов без ошибок при обработке.

  • Для структуры XML не требуются символы форматирования, такие как пробелы, вкладки или записи возврата каретки или записи канала строк. Обратите внимание на это при оптимизации места для загрузки. Такие инструменты, как Microsoft Visual Code, предоставляют функции линии связи для сжатия XML-файла.

Если в пользовательском типе конфиденциальных данных имеется проблема, которая может снизить производительность, этот тип не будет отправлен, и, возможно, будет отображено одно из указанных ниже сообщений об ошибке.

  • Generic quantifiers which match more content than expected (e.g., '+', '*')

  • Lookaround assertions

  • Complex grouping in conjunction with general quantifiers

Повторный обход контента для обнаружения конфиденциальных данных

Microsoft 365 использует поисковую программу-обходчик для выявления и классификации конфиденциальной информации в контенте сайта. Повторный обход контента на сайтах SharePoint Online и OneDrive для бизнеса выполняется автоматически при каждом обновлении содержимого. Но для выявления во всем имеющемся контенте элементов, относящихся к новому пользовательскому типу конфиденциальной информации, необходимо заново выполнить его обход.

В Microsoft 365 вы не можете вручную запросить повторную сборку всей организации, но вы можете вручную запросить повторное создание семейства веб-сайтов, списка или библиотеки. Дополнительные сведения см . в статье Обход и повторная индексация сайта, библиотеки или списка вручную.

Справка: определение схемы XML пакета правил

Вы можете скопировать эту разметку, сохранить ее в виде XSD-файла и использовать для проверки XML-файла пакета правил.

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:mce="http://schemas.microsoft.com/office/2011/mce"
           targetNamespace="http://schemas.microsoft.com/office/2011/mce"
           xmlns:xs="https://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified"
           attributeFormDefault="unqualified"
           id="RulePackageSchema">
  <!-- Use include if this schema has the same target namespace as the schema being referenced, otherwise use import -->
  <xs:element name="RulePackage" type="mce:RulePackageType"/>
  <xs:simpleType name="LangType">
    <xs:union memberTypes="xs:language">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:enumeration value=""/>
        </xs:restriction>
      </xs:simpleType>
    </xs:union>
  </xs:simpleType>
  <xs:simpleType name="GuidType" final="#all">
    <xs:restriction base="xs:token">
      <xs:pattern value="[0-9a-fA-F]{8}\-([0-9a-fA-F]{4}\-){3}[0-9a-fA-F]{12}"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="RulePackageType">
    <xs:sequence>
      <xs:element name="RulePack" type="mce:RulePackType"/>
      <xs:element name="Rules" type="mce:RulesType">
        <xs:key name="UniqueRuleId">
          <xs:selector xpath="mce:Entity|mce:Affinity|mce:Version/mce:Entity|mce:Version/mce:Affinity"/>
          <xs:field xpath="@id"/>
        </xs:key>
        <xs:key name="UniqueProcessorId">
          <xs:selector xpath="mce:Regex|mce:Keyword|mce:Fingerprint"></xs:selector>
          <xs:field xpath="@id"/>
        </xs:key>
        <xs:key name="UniqueResourceIdRef">
          <xs:selector xpath="mce:LocalizedStrings/mce:Resource"/>
          <xs:field xpath="@idRef"/>
        </xs:key>
        <xs:keyref name="ReferencedRuleMustExist" refer="mce:UniqueRuleId">
          <xs:selector xpath="mce:LocalizedStrings/mce:Resource"/>
          <xs:field xpath="@idRef"/>
        </xs:keyref>
        <xs:keyref name="RuleMustHaveResource" refer="mce:UniqueResourceIdRef">
          <xs:selector xpath="mce:Entity|mce:Affinity|mce:Version/mce:Entity|mce:Version/mce:Affinity"/>
          <xs:field xpath="@id"/>
        </xs:keyref>
      </xs:element>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="RulePackType">
    <xs:sequence>
      <xs:element name="Version" type="mce:VersionType"/>
      <xs:element name="Publisher" type="mce:PublisherType"/>
      <xs:element name="Details" type="mce:DetailsType">
        <xs:key name="UniqueLangCodeInLocalizedDetails">
          <xs:selector xpath="mce:LocalizedDetails"/>
          <xs:field xpath="@langcode"/>
        </xs:key>
        <xs:keyref name="DefaultLangCodeMustExist" refer="mce:UniqueLangCodeInLocalizedDetails">
          <xs:selector xpath="."/>
          <xs:field xpath="@defaultLangCode"/>
        </xs:keyref>
      </xs:element>
      <xs:element name="Encryption" type="mce:EncryptionType" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>
    <xs:attribute name="id" type="mce:GuidType" use="required"/>
  </xs:complexType>
  <xs:complexType name="VersionType">
    <xs:attribute name="major" type="xs:unsignedShort" use="required"/>
    <xs:attribute name="minor" type="xs:unsignedShort" use="required"/>
    <xs:attribute name="build" type="xs:unsignedShort" use="required"/>
    <xs:attribute name="revision" type="xs:unsignedShort" use="required"/>
  </xs:complexType>
  <xs:complexType name="PublisherType">
    <xs:attribute name="id" type="mce:GuidType" use="required"/>
  </xs:complexType>
  <xs:complexType name="LocalizedDetailsType">
    <xs:sequence>
      <xs:element name="PublisherName" type="mce:NameType"/>
      <xs:element name="Name" type="mce:RulePackNameType"/>
      <xs:element name="Description" type="mce:OptionalNameType"/>
    </xs:sequence>
    <xs:attribute name="langcode" type="mce:LangType" use="required"/>
  </xs:complexType>
  <xs:complexType name="DetailsType">
    <xs:sequence>
      <xs:element name="LocalizedDetails" type="mce:LocalizedDetailsType" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="defaultLangCode" type="mce:LangType" use="required"/>
  </xs:complexType>
  <xs:complexType name="EncryptionType">
    <xs:sequence>
      <xs:element name="Key" type="xs:normalizedString"/>
      <xs:element name="IV" type="xs:normalizedString"/>
    </xs:sequence>
  </xs:complexType>
  <xs:simpleType name="RulePackNameType">
    <xs:restriction base="xs:token">
      <xs:minLength value="1"/>
      <xs:maxLength value="64"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="NameType">
    <xs:restriction base="xs:normalizedString">
      <xs:minLength value="1"/>
      <xs:maxLength value="256"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="OptionalNameType">
    <xs:restriction base="xs:normalizedString">
      <xs:minLength value="0"/>
      <xs:maxLength value="256"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="RestrictedTermType">
    <xs:restriction base="xs:string">
      <xs:minLength value="1"/>
      <xs:maxLength value="100"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="RulesType">
    <xs:sequence>
      <xs:choice maxOccurs="unbounded">
        <xs:element name="Entity" type="mce:EntityType"/>
        <xs:element name="Affinity" type="mce:AffinityType"/>
        <xs:element name="Version" type="mce:VersionedRuleType"/>
      </xs:choice>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element name="Regex" type="mce:RegexType"/>
        <xs:element name="Keyword" type="mce:KeywordType"/>
        <xs:element name="Fingerprint" type="mce:FingerprintType"/>
        <xs:element name="ExtendedKeyword" type="mce:ExtendedKeywordType"/>
      </xs:choice>
      <xs:element name="LocalizedStrings" type="mce:LocalizedStringsType"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="EntityType">
    <xs:sequence>
      <xs:element name="Pattern" type="mce:PatternType" maxOccurs="unbounded"/>
      <xs:element name="Version" type="mce:VersionedPatternType" minOccurs="0" maxOccurs="unbounded" />
    </xs:sequence>
    <xs:attribute name="id" type="mce:GuidType" use="required"/>
    <xs:attribute name="patternsProximity" type="mce:ProximityType" use="required"/>
    <xs:attribute name="recommendedConfidence" type="mce:ProbabilityType"/>
    <xs:attribute name="workload" type="mce:WorkloadType"/>
  </xs:complexType>
  <xs:complexType name="PatternType">
    <xs:sequence>
      <xs:element name="IdMatch" type="mce:IdMatchType"/>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element name="Match" type="mce:MatchType"/>
        <xs:element name="Any" type="mce:AnyType"/>
      </xs:choice>
    </xs:sequence>
    <xs:attribute name="confidenceLevel" type="mce:ProbabilityType" use="required"/>
  </xs:complexType>
  <xs:complexType name="AffinityType">
    <xs:sequence>
      <xs:element name="Evidence" type="mce:EvidenceType" maxOccurs="unbounded"/>
      <xs:element name="Version" type="mce:VersionedEvidenceType" minOccurs="0" maxOccurs="unbounded" />
    </xs:sequence>
    <xs:attribute name="id" type="mce:GuidType" use="required"/>
    <xs:attribute name="evidencesProximity" type="mce:ProximityType" use="required"/>
    <xs:attribute name="thresholdConfidenceLevel" type="mce:ProbabilityType" use="required"/>
    <xs:attribute name="workload" type="mce:WorkloadType"/>
  </xs:complexType>
  <xs:complexType name="EvidenceType">
    <xs:sequence>
      <xs:choice maxOccurs="unbounded">
        <xs:element name="Match" type="mce:MatchType"/>
        <xs:element name="Any" type="mce:AnyType"/>
      </xs:choice>
    </xs:sequence>
    <xs:attribute name="confidenceLevel" type="mce:ProbabilityType" use="required"/>
  </xs:complexType>
  <xs:complexType name="IdMatchType">
    <xs:attribute name="idRef" type="xs:string" use="required"/>
  </xs:complexType>
  <xs:complexType name="MatchType">
    <xs:attribute name="idRef" type="xs:string" use="required"/>
    <xs:attribute name="minCount" type="xs:positiveInteger" use="optional"/>
    <xs:attribute name="uniqueResults" type="xs:boolean" use="optional"/>
  </xs:complexType>
  <xs:complexType name="AnyType">
    <xs:sequence>
      <xs:choice maxOccurs="unbounded">
        <xs:element name="Match" type="mce:MatchType"/>
        <xs:element name="Any" type="mce:AnyType"/>
      </xs:choice>
    </xs:sequence>
    <xs:attribute name="minMatches" type="xs:nonNegativeInteger" default="1"/>
    <xs:attribute name="maxMatches" type="xs:nonNegativeInteger" use="optional"/>
  </xs:complexType>
  <xs:simpleType name="ProximityType">
    <xs:union>
      <xs:simpleType>
        <xs:restriction base='xs:string'>
          <xs:enumeration value="unlimited"/>
        </xs:restriction>
      </xs:simpleType>
      <xs:simpleType>
        <xs:restriction base="xs:positiveInteger">
          <xs:minInclusive value="1"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:union>
  </xs:simpleType>
  <xs:simpleType name="ProbabilityType">
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="1"/>
      <xs:maxInclusive value="100"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="WorkloadType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Exchange"/>
      <xs:enumeration value="Outlook"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="EngineVersionType">
    <xs:restriction base="xs:token">
      <xs:pattern value="^\d{2}\.01?\.\d{3,4}\.\d{1,3}$"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="VersionedRuleType">
    <xs:choice maxOccurs="unbounded">
      <xs:element name="Entity" type="mce:EntityType"/>
      <xs:element name="Affinity" type="mce:AffinityType"/>
    </xs:choice>
    <xs:attribute name="minEngineVersion" type="mce:EngineVersionType" use="required" />
  </xs:complexType>
  <xs:complexType name="VersionedPatternType">
    <xs:sequence>
      <xs:element name="Pattern" type="mce:PatternType" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="minEngineVersion" type="mce:EngineVersionType" use="required" />
  </xs:complexType>
  <xs:complexType name="VersionedEvidenceType">
    <xs:sequence>
      <xs:element name="Evidence" type="mce:EvidenceType" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="minEngineVersion" type="mce:EngineVersionType" use="required" />
  </xs:complexType>
  <xs:simpleType name="FingerprintValueType">
    <xs:restriction base="xs:string">
      <xs:minLength value="2732"/>
      <xs:maxLength value="2732"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="FingerprintType">
    <xs:simpleContent>
      <xs:extension base="mce:FingerprintValueType">
        <xs:attribute name="id" type="xs:token" use="required"/>
        <xs:attribute name="threshold" type="mce:ProbabilityType" use="required"/>
        <xs:attribute name="shingleCount" type="xs:positiveInteger" use="required"/>
        <xs:attribute name="description" type="xs:string" use="optional"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="RegexType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:token" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="KeywordType">
    <xs:sequence>
      <xs:element name="Group" type="mce:GroupType" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:token" use="required"/>
  </xs:complexType>
  <xs:complexType name="GroupType">
    <xs:sequence>
      <xs:choice>
        <xs:element name="Term" type="mce:TermType" maxOccurs="unbounded"/>
      </xs:choice>
    </xs:sequence>
    <xs:attribute name="matchStyle" default="word">
      <xs:simpleType>
        <xs:restriction base="xs:NMTOKEN">
          <xs:enumeration value="word"/>
          <xs:enumeration value="string"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="TermType">
    <xs:simpleContent>
      <xs:extension base="mce:RestrictedTermType">
        <xs:attribute name="caseSensitive" type="xs:boolean" default="false"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="ExtendedKeywordType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:token" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="LocalizedStringsType">
    <xs:sequence>
      <xs:element name="Resource" type="mce:ResourceType" maxOccurs="unbounded">
      <xs:key name="UniqueLangCodeUsedInNamePerResource">
        <xs:selector xpath="mce:Name"/>
        <xs:field xpath="@langcode"/>
      </xs:key>
      <xs:key name="UniqueLangCodeUsedInDescriptionPerResource">
        <xs:selector xpath="mce:Description"/>
        <xs:field xpath="@langcode"/>
      </xs:key>
    </xs:element>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="ResourceType">
    <xs:sequence>
      <xs:element name="Name" type="mce:ResourceNameType" maxOccurs="unbounded"/>
      <xs:element name="Description" type="mce:DescriptionType" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="idRef" type="mce:GuidType" use="required"/>
  </xs:complexType>
  <xs:complexType name="ResourceNameType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="default" type="xs:boolean" default="false"/>
        <xs:attribute name="langcode" type="mce:LangType" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="DescriptionType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="default" type="xs:boolean" default="false"/>
        <xs:attribute name="langcode" type="mce:LangType" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:schema>

Дополнительные сведения