Применение правил защиты от потери данных для оценки сообщенийHow DLP rules are applied to evaluate messages

Можно настроить правила конфиденциальной информации в политиках предотвращения (DLP) потери данных Microsoft Exchange для выявления определенных данных в сообщениях электронной почты. В этом разделе помогут понять, как применяются следующие правила и способ оценки сообщений. Можно избежать нарушения рабочего процесса для пользователей электронной почты и достижения высокой точности с вашей обнаружения защиты от потери данных, если вы знаете способа применения правила. В качестве примера используем правила сведения о банковской карты, предоставляемыми корпорацией Майкрософт. При активации правила транспорта или политики предотвращения потери данных, агент правил транспорта Exchange сравнивает все сообщения, которые пользователи отправляют наборы правил, созданные вами.You can set up sensitive information rules within your Microsoft Exchange data loss prevention (DLP) policies to detect very specific data in email messages. This topic will help you understand how these rules are applied and how messages are evaluated. You can avoid workflow disruptions for your email users and achieve a high degree of accuracy with your DLP detections if you know how your rules are enforced. Let's use the Microsoft-supplied credit card information rule as an example. When you activate a transport rule or DLP policy, the Exchange transport rules agent compares all messages that your users send with the rule sets that you create.

Необходимо точно сформулировать условияGet precise about your needs

Предположим, что вам нужно работать с сведения о банковской карты в сообщениях. Действия, выполняемые после его обнаружения не темы в этом разделе, но можно подробнее об этом в поток обработки почты действия правил в Exchange Online. В большинстве точно по мере возможности необходимо убедитесь, что обнаруженных в сообщении действительно данных кредитной карты и не другое действие, которое может быть допустимым использования групп чисел, просто иметь вид данных кредитной карты. Например код резервирования или идентификационный номер транспортного средства. Для этого, давайте следует определить, что указанные ниже следует рассматривать как данные о банковской карте.Suppose you need to act on credit card information in messages. The actions you take once it is found are not the subject of this topic, but you can learn more about that in Mail flow rule actions in Exchange Online. With as most certainty as possible, you need to ensure that what is detected in a message is truly credit card data and not something else that could be a legitimate use of groups of numbers that merely resemble credit card data; for example, a reservation code or a vehicle identification number. To meet this need, let's make it clear that the following information should be classified as a credit card.

** Margie's Travel** Margie's Travel,

Сведения о обновленные данные о банковской карте для Spencer было получено.I have received updated credit card information for Spencer.

Иван ПетровSpencer Badillo

Visa: 4111 1111 1111 1111Visa: 4111 1111 1111 1111

Действительно до: 2/2012Expires: 2/2012

Обновите свой профиль командировок.Please update his travel profile. **

Также следует определить, что следующие сведения не следует рассматривать как данные о банковской карте.Let's also make it clear that the following information should not be classified as a credit card.

** Коридор Алекс,** Hi Alex,

Я ожидаю, что находится в Гавайи слишком. Код резервирования является 1234 1234 1234 1234 и буду существует 3/2012 г.I expect to be in Hawaii too. My booking code is 1234 1234 1234 1234 and I'll be there on 3/2012.

Согласно указаниям, Лайза **Regards, Lisa **

В следующем фрагменте XML показано, как потребности, представленное ранее в настоящее время определены в правиле конфиденциальной информации, которая предоставляется вместе с Exchange и внедренное в одной из встроенных шаблонов политики защиты от потери данных.The following XML snippet shows how the needs expressed earlier are currently defined in a sensitive information rule that is provided with Exchange and it is embedded within one of the supplied DLP policy templates.

<Entity id="50842eb7-edc8-4019-85dd-5a5c1f2bb085" patternsProximity="300" recommendedConfidence="85">
      <Pattern confidenceLevel="85">
        <IdMatch idRef="Func_credit_card" />
        <Any minMatches="1">
          <Match idRef="Keyword_cc_verification" />
          <Match idRef="Keyword_cc_name" />
          <Match idRef="Func_expiration_date" />
        </Any>
      </Pattern>
    </Entity>

Сравнение по шаблону в нашем решенииPattern-matching in your solution

Показанное выше определение правила XML содержит сравнение с шаблоном. Это повышает вероятность определения только достоверной информации, а нечеткая информация не будет определена. Дополнительные сведения о схеме XML для правил DLP и шаблонов см. в разделе Define Your Own DLP Templates and Information Types.The XML rule definition shown earlier includes pattern-matching, which improves the likelihood that the rule will detect only the important information and not detect vague, related information. For more information about the XML schema for DLP rules and templates, see Define Your Own DLP Templates and Information Types.

В правиле для обнаружения сведений о банковских картах есть раздел кода XML для шаблонов, включающий сравнение основного идентификатора и некоторые дополнительные подтверждающие свидетельства. Все три требования поясняются здесь:In the credit card rule, there is a section of XML code for patterns, which includes a primary identifier match and some additional corroborative evidence. All three of these requirements are explained here:

  1. <IdMatch idRef="Func_credit_card" />— Для этого необходимо соответствие функции, под названием кредитной карты, который задается во внутренней сети. Эта функция включает в себя ряд проверок следующим образом:<IdMatch idRef="Func_credit_card" /> — This requires a match of a function, titled credit card, that is internally defined. This function includes a couple of validations as follows:

  2. Она сравнивает регулярное выражение, — в данном случае, 16 цифр, — которое также может содержать определенные отклонения, например, разделитель-пробел (в этом случае сравнение сработает для 4111 1111 1111 1111) или разделитель-дефис (в этом случае сравнение сработает для 4111-1111-1111-1111).It matches a regular expression—in this instance for 16 digits—that could also include variations like a space delimiter so that it also matches 4111 1111 1111 1111 or a hyphen delimiter so that it also matches 4111-1111-1111-1111.

  3. Он применяет алгоритм контрольной суммой Lhun от 16-разрядное число Луна высокой степенью сходства с этот номер кредитной карты.It evaluates the Lhun's checksum algorithm against the 16-digit number in order to ensure the likelihood of this being a credit card number is high.

  4. Требуется обязательное совпадение, после которого проверяется подтверждающее свидетельство.It requires a mandatory match, after which corroborative evidence is evaluated.

  5. <Any minMatches="1">— В этом разделе указывает, что требуется наличие по крайней мере один из следующих элементов свидетельства.<Any minMatches="1"> — This section indicates that the presence of at least one of the following items of evidence is required.

  6. Подтверждающее свидетельство может быть совпадением с любым их трех следующих элементов:The corroborative evidence can be a match of one of these three:

    <Match idRef="Keyword_cc_verification" />

    <Match idRef="Keyword_cc_name" />

    <Match idRef="Func_expiration_date" />

    Эти три элемента представляют собой просто список ключевых слов для банковских карт, названия банковских карт, а также наличие даты срока действия. Дата срока действия определяется и проверяется в другой функции.These three simply mean a list of keywords for credit cards, the names of the credit cards, or an expiration date is required. The expiration date is defined and evaluated internally as another function.

Процесс проверки содержимого с помощью правилThe process of evaluating content against rules

Здесь пять этапов представляют действия, которые принимает Exchange для сравнения правило с сообщений электронной почты. Для этого примера правила кредитной карты выполняются следующие действия.The five steps here represent actions that Exchange takes to compare your rule with email messages. For our credit card rule example, the following steps are taken.

ЭтапStep ДействиеAction
1. Получение содержимого1. Get Content
Иван ПетровSpencer Badillo
Visa: 4111 1111 1111 1111Visa: 4111 1111 1111 1111
Действительно до: 2/2012Expires: 2/2012
2. Анализ регулярных выражений2. Regular Expression Analysis
4111 1111 1111 1111 -> обнаружено 16-разрядное число4111 1111 1111 1111 -> a 16-digit number is detected
3. Функциональный анализ3. Function Analysis
4111 1111 1111 1111 -> совпадает с контрольной суммой4111 1111 1111 1111 -> matches checksum
1234 1234 1234 1234 -> не совпадает с1234 1234 1234 1234 -> doesn't match
4. Дополнительное подтверждение4. Additional Evidence
— Это ключевое слово Visa рядом с номером. — Это регулярное выражение для даты (2/2012) близко к числу.Keyword Visa is near the number. A regular expression for a date (2/2012) is near the number.
5. Заключение5. Verdict
Нет регулярного выражения, совпадающего с контрольной суммой. Дополнительное подтверждение повышает надежность.There is a regular expression that matches a checksum. Additional evidence increases confidence.

Правило настроено корпорацией Майкрософт таким образом, чтобы подтверждающие свидетельства, такие как ключевые слова, обязательно входили в содержимое электронного сообщения, чтобы это правило срабатывало. Поэтому следующее электронное сообщение не будет определено как содержащее данные банковской карты:The way this rule is set up by Microsoft makes it mandatory that corroborating evidence such as keywords are a part of the email message content in order to match the rule. So the following email content would not be detected as containing a credit card:

** Margie's Travel** Margie's Travel,

Обновленные сведения о Spencer было получено.I have received updated information for Spencer.

Иван ПетровSpencer Badillo

4111 1111 1111 11114111 1111 1111 1111

Обновите свой профиль командировок.Please update his travel profile. **

Можно использовать настраиваемое правило, определяющее шаблон без дополнительных свидетельств, как показано в следующем примере. Это правило обнаруживает сообщения только с номером банковской карты, без подтверждающих свидетельств.You can use a custom rule that defines a pattern without extra evidence, as shown in the next example. This would detect messages with only credit card number and no corroborating evidence.

      <Pattern confidenceLevel="85">
         <IdMatch idRef="Func_credit_card" />
      </Pattern>
    </Entity>

Иллюстрация карты в этой статье могут быть расширены с другими правилами конфиденциальной информации. Чтобы просмотреть полный список правил, поддерживаемого программой Microsoft Exchange, используйте командлет Get-ClassificationRuleCollection в командной консоли Exchange следующим образом:The illustration of credit cards in this article can be extended to other sensitive information rules as well. To see the complete list of the Microsoft-supplied rules in Exchange, use the Get-ClassificationRuleCollection cmdlet in the Exchange Management Shell in the following manner:

$rule_collection = Get-ClassificationRuleCollection
$rule_collection[0].SerializedClassificationRuleCollection | Set-Content oob_classifications.xml -Encoding byte

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

Защита от потери данныхData loss prevention

Правила потока обработки почты (правила транспорта) в Exchange OnlineMail flow rules (transport rules) in Exchange Online

Командная консоль ExchangeExchange Management Shell

Exchange Online PowerShellExchange Online PowerShell