DLP 規則如何套用至評估郵件How DLP rules are applied to evaluate messages

您可以設定敏感資訊規則在 Microsoft Exchange 資料外洩防護 (DLP) 原則內的電子郵件中偵測非常特定的資料。本主題可協助您了解如何套用這些規則和訊息的評估方式。您可以避免電子郵件使用者的工作流程干擾並達成高程度的正確性 DLP 偵測如果您知道如何強制執行規則。我們使用 Microsoft 提供信用卡資訊規則範例。當您啟用傳輸規則或 DLP 原則時,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 的旅行** Margie's Travel,

我已接收 Spencer 更新的信用卡的資訊。I have received updated credit card information for Spencer.

Spencer BadilloSpencer 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、** 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.

將 Lisa * *Regards, Lisa **

下列 XML 片段會示範如何在與 Exchange 所提供的機密資訊規則中目前定義表示先前的需求和內嵌內其中一個提供的 DLP 原則範本。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 規則定義包含了模式比對,可改善規則只偵測到重要資訊而未偵測到相關模糊資訊的可能性。如需 DLP 規則與範例之 XML 架構的詳細資訊,請參閱Define Your Own DLP Templates and Information TypesThe 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 BadilloSpencer 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. Verdict5. Verdict
有符合總和檢查碼的規則運算式。額外的證據可增加信賴。There is a regular expression that matches a checksum. Additional evidence increases confidence.

Microsoft 設定的這個規則規定,電子郵件內容必須出現佐證性證據 (例如關鍵字),才能符合此規則。因此,下列電子郵件內容不會被偵測為包含信用卡: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 的旅行** Margie's Travel,

我已接收的 Spencer 更新的資訊。I have received updated information for Spencer.

Spencer BadilloSpencer 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>

其他敏感資訊規則可延伸的信用卡本文中的圖例。若要 Exchange 中查看 Microsoft 提供之規則的完整清單,請使用Get-classificationrulecollection cmdlet 在 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 Online 中的郵件流程規則 (傳輸規則)Mail flow rules (transport rules) in Exchange Online

Exchange 管理命令介面Exchange Management Shell

Exchange Online PowerShellExchange Online PowerShell