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

Exchange 2013
 

Применимо к:Exchange Online, Exchange Server 2013

Последнее изменение раздела:2016-07-28

В этом разделе описываются методы сопоставления шаблонов и свидетельств с XML-файлами политики предотвращения потери данных, который предназначен для хранения вашего собственного пакета правил с описанием типов конфиденциальной информации. После создания XML-документа правильного формата вы можете импортировать его при помощи Центра администрирования Exchange или в консоли управления Exchange, чтобы создать свое DLP-решение на основе Microsoft Exchange Server 2013. Чтобы применять методы, описанные здесь, нужен уже созданный XML-файл DLP. Дополнительные сведения о шаблонах DLP и XML-файлах см. в разделе Определение собственных шаблонов DLP и типов сведений.

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

<?xml version="1.0" encoding="utf-8"?>
<Rules packageId="...">
        ...
<Entity id="...">
  <Pattern confidenceLevel="85">
             <IdMatch idRef="FormattedSSN" />
             <Match idRef="USDate" />
             <Match idRef="USAddress" />
  </Pattern>
</Entity>
        ...
         <Keyword id="FormattedSSN "> ... </Keyword>
         <Regex id=" USDate "> ... </Regex>
         <Regex id="USAddress"> ... </Regex>
        ...

</Rules>

Общее требование к правилам — поиск соответствий ведется на основании выражений с последовательностями известных ключевых слов. Это достигается с помощью элемента Keyword. Элемент Keyword имеет атрибут «id», используемый как образец в соответствующих правилах Entity и Affinity. На один элемент Keyword можно ссылаться в нескольких правилах Entity и Affinity.

Поиск можно выполнять на основе точного соответствия или сопоставления слов. В первом случае используется алгоритм поиска текста на указанном языке с учетом регистра. Во втором используется алгоритм сравнения на основе границы между словами. Термины для поиска могут включить в определение Keyword с помощью вложенного элемента Term.

СоветСовет.
Для лучшей эффективности и производительности используйте стиль сопоставления через регулярное выражение на постоянной основе. Используйте сопоставление через регулярное выражение только в тех случаях, когда сопоставлений на постоянной основе недостаточно и требуется гибкость регулярных выражений.
<Keyword id="Word_Example">
    <Group matchStyle="word">
       <Term>card verification</Term>
       <Term>cvn</Term>
       <Term>cid</Term>
       <Term>cvc2</Term>
       <Term>cvv2</Term>
       <Term>pin block</Term>
       <Term>security code</Term>
    </Group>
</Keyword>
...
<Keyword id="String_Example">
    <Group matchStyle="string">
       <Term>card</Term>
       <Term>pin</Term>
       <Term>security</Term>
    </Group>
</Keyword>

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

СоветСовет.
Для лучшей эффективности и производительности используйте стиль сопоставления через регулярное выражение на постоянной основе. Используйте сопоставление через регулярное выражение только в тех случаях, когда сопоставлений на постоянной основе недостаточно и требуется гибкость регулярных выражений.

 

Символ Смысл

c

Однократное вхождение символа-литерала "c", если это не один из специальных символов.

^

Соответствует началу строки.

.

Соответствует любому символу, отличному от символа новой строки.

$

Соответствует концу строки.

|

Логическое "или" для выражений.

()

Группировка подвыражений.

[]

Определяет класс символов.

*

Соответствует предшествующему выражению ноль и более раз.

+

Соответствует предшествующему выражению один и более раз.

?

Соответствует предшествующему выражению ноль или один раз.

{n}

Соответствует предыдущему выражению n раз.

{n,}

Соответствует предыдущему выражению не менее n раз.

{n, m}

Соответствует предыдущему выражению не менее n и не более m раз.

\d

Соответствует цифре.

\D

Соответствует символу, отличному от цифры.

\w

Соответствует буквам, включая знак подчеркивания.

\W

Соответствует символу, отличному от буквы.

\s

Соответствует символу пробела (\t, \n, \r или \f).

\S

Соответствует символу, отличному от пробела.

\t

Знак табуляции.

\n

Новая строка.

\r

Возврат каретки.

\f

Перевод страницы.

\м

Escape-символ m, где m — один из перечисленных выше метасимволов: ^, ., $, |, (), [], *, +, ?, \ или /.

Элемент Regex имеет атрибут "id", используемый как образец в соответствующих правилах Entity и Affinity. На один элемент Regex можно ссылаться в нескольких правилах Entity и Affinity. Выражение Regex определяется как значение элемента Regex.

<Regex id="CCRegex">
     \bcc\#\s|\bcc\#\:\s
</Regex>
...
<Regex id="ItinFormatted">
    (?:^|[\s\,\:])(?:9\d{2})[- ](?:[78]\d[-  
     ]\d{4})(?:$|[\s\,]|\.\s)
</Regex>
...
<Regex id="NorthCarolinaDriversLicenseNumber">
    (^|\s|\:)(\d{1,8})($|\s|\.\s)
</Regex>

Распространенный способ повышения точности сопоставления — определить семантику между несколькими элементами Match, например, потребовав, что должно произойти одно или несколько соответствий. Элемент Any позволяет определить логику на основе нескольким соответствий. Элемент Any может быть использован в качестве дочернего элемента Pattern. Он содержит один или несколько дочерних элементов Match и определяет логику соответствия между ними. Ниже даны примеры XML-кода для элементов Any со всеми совпадениями, логикой отрицания и точным подсчетом совпадений.

Можно использовать дополнительный атрибут minMatches (default = 1), чтобы определить минимальное число элементов Match, которые должны срабатывать для регистрации совпадения. Также можно использовать дополнительный атрибут maxMatches (по умолчанию — количество дочерних элементов Match) для определения максимального количества элементов Match, которые должны срабатывать для регистрации совпадения. Эти условия комбинируются с использованием логических операторов в зависимости от использования атрибутов maxMatches и minMatches, что дает возможность использовать следующую семантику:

  • Соответствие всем дочерним элементам Match

    Отсутствие соответствия каким-либо дочерним элементам Match

    Соответствие точному подмножеству дочерних элементов Match

<Any minMatches="3" maxMatches="3">
    <Match idRef="USDate" />
    <Match idRef="USAddress" />
    <Match idRef="Name" />
</Any>
<Any maxMatches="0">
    <Match idRef="USDate" />
    <Match idRef="USAddress" />
    <Match idRef="Name" />
</Any>

<Any minMatches="1" maxMatches="1">
    <Match idRef="USDate" />
    <Match idRef="USAddress" />
    <Match idRef="Name" />
</Any>

Для правил сущностей другой вариант повышения надежности — определение нескольких элементов Pattern с возрастающим числом подкрепляющих свидетельств. Это достигается с помощью атрибутов maxMatches и minMatches для элементов Any, что позволяет создавать независимые шаблоны с растущим уровнем достоверности, основанным на росте числа подкрепляющих свидетельств. Например:

  • если найдена одна часть подтверждающего свидетельства: уровень доверия — 65 %

  • если найдено две части: уровень доверия — 75%

  • если найдено три части: уровень доверия — 85%

<Entity id="..." patternsProximity="300" >
    <Pattern confidenceLevel="65">
        <IdMatch idRef="UnformattedSSN" />
        <Any maxMatches="1">
            <Match idRef="USDate" />
            <Match idRef="USAddress" />
            <Match idRef="Name" />
        </Any>
    </Pattern>
    <Pattern confidenceLevel="75">
        <IdMatch idRef="UnformattedSSN" />
        <Any minMatches="2" maxMatches="2">
            <Match idRef="USDate" />
            <Match idRef="USAddress" />
            <Match idRef="Name" />
        </Any>
    </Pattern>
    <Pattern confidenceLevel="85">
        <IdMatch idRef="UnformattedSSN" />
        <Any minMatches="3">
            <Match idRef="USDate" />
            <Match idRef="USAddress" />
            <Match idRef="Name" />
        </Any>
    </Pattern>
</Entity>

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

  1. Regex совпадает с форматированным SSN (и он соответствует действующему диапазону SSN).

  2. Есть подкрепляющие доказательства   Рядом найдено нечто подобное:

    1. Ключевое слово {Social Security, Soc Sec, SSN, SSNS, SSN#, SS#, SSID}

    2. Текст, представляющий адрес в США

    3. Текст, представляющий дату

    4. Текст, представляющий имя

Далее нужно перевести описание в представление схемы правил:

<Entity id="a44669fe-0d48-453d-a9b1-2cc83f2cba77"
         patternsProximity="300" RecommendedConfidence="85">
    <Pattern confidenceLevel="85">
      <IdMatch idRef="FormattedSSN" />
      <Any minMatches="1">
          <Match idRef="SSNKeywords" />
          <Match idRef="USDate" />
          <Match idRef="USAddress" />
          <Match idRef="Name" />
      </Any>
    </Pattern>
</Entity>
 
Показ: