Erstellen eines benutzerdefinierten vertraulichen Informationstyps mit PowerShell

  • Artikel

In diesem Artikel erfahren Sie, wie Sie eine XML-Regelpaketdatei erstellen, die benutzerdefinierte Typen vertraulicher Informationen definiert. In diesem Artikel wird ein benutzerdefinierter vertraulicher Informationstyp beschrieben, der eine Mitarbeiter-ID identifiziert. Sie können das XML-Beispiel in diesem Artikel als Ausgangspunkt für Ihre eigene XML-Datei verwenden.

Weitere Informationen zu vertraulichen Informationstypen finden Sie unter Informationen zu Typen vertraulicher Informationen.

Nachdem Sie eine wohlgeformte XML-Datei erstellt haben, können Sie sie mithilfe von PowerShell in Microsoft 365 hochladen. Anschließend können Sie Ihren benutzerdefinierten Typ vertraulicher Informationen in Richtlinien verwenden. Sie können ihre Wirksamkeit bei der Erkennung der vertraulichen Informationen nach Ihren Absichten testen.

Hinweis

Wenn Sie das von PowerShell bereitgestellte differenzierte Steuerelement nicht benötigen, können Sie im Microsoft Purview-Complianceportal benutzerdefinierte Typen vertraulicher Informationen erstellen. Weitere Informationen finden Sie unter Erstellen eines benutzerdefinierten vertraulichen Informationstyps.

Tipp

Wenn Sie kein E5-Kunde sind, verwenden Sie die 90-tägige Testversion von Microsoft Purview-Lösungen, um zu erfahren, wie zusätzliche Purview-Funktionen Ihre Organisation bei der Verwaltung von Datensicherheits- und Complianceanforderungen unterstützen können. Starten Sie jetzt im Testhub für Microsoft Purview-Complianceportal. Erfahren Sie mehr über Anmelde- und Testbedingungen.

Wichtiger Haftungsausschluss

Microsoft-Support können Sie nicht beim Erstellen von Inhaltsabgleichsdefinitionen unterstützen.

Für die Entwicklung, Das Testen und Debuggen von benutzerdefinierten Inhalten müssen Sie Ihre eigenen internen IT-Ressourcen verwenden oder Beratungsdienste wie Microsoft Consulting Services (MCS) verwenden. Microsoft-Support-Techniker können eingeschränkte Unterstützung für dieses Feature bereitstellen, aber sie können nicht garantieren, dass benutzerdefinierte Vorschläge zum Abgleich von Inhalten Ihren Anforderungen vollständig entsprechen.

MCS kann reguläre Ausdrücke zu Testzwecken bereitstellen. Sie können auch Unterstützung bei der Problembehandlung eines vorhandenen RegEx-Musters bieten, das mit einem einzelnen spezifischen Inhaltsbeispiel nicht wie erwartet funktioniert.

Weitere Informationen finden Sie in diesem Artikel unter Mögliche Validierungsprobleme .

Weitere Informationen über die Boost.RegEx-Engine (ehemals RegEx++), die für die Verarbeitung des Textes verwendet wird, finden Sie unter Boost.Regex 5.1.3.

Hinweis

Wenn Sie ein kaufmännisches und -zeichen (&) als Teil einer Schlüsselwort (keyword) in Ihrem benutzerdefinierten Typ vertraulicher Informationen verwenden, müssen Sie einen zusätzlichen Ausdruck mit Leerzeichen um das Zeichen hinzufügen. Verwenden Sie L & P z. B. notL&P.

Beispiel-XML für ein Regelpaket

Hier sehen Sie die Beispiel-XML des Regelpakets, das wir in diesem Artikel erstellen. Elemente und Attribute werden in den folgenden Abschnitten erläutert.

<?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>

Was sind Ihre wichtigsten Anforderungen? [Regel, Entität, Musterelemente]

Es ist wichtig, dass Sie die grundlegende Struktur des XML-Schemas für eine Regel verstehen. Ihr Verständnis der Struktur hilft Ihrem benutzerdefinierten Typ vertraulicher Informationen, den richtigen Inhalt zu identifizieren.

Eine Regel definiert eine oder mehrere Entitäten (auch als Typen vertraulicher Informationen bezeichnet). Jede Entität definiert ein oder mehrere Muster. Eine Richtlinie sucht nach einem Muster, wenn sie Inhalte (z. B. E-Mails und Dokumente) auswertet.

Im XML-Markup sind "Regeln" die Muster, die den Typ vertraulicher Informationen definieren. Ordnen Sie keine Verweise auf Regeln in diesem Artikel "Bedingungen" oder "Aktionen" zu, die in anderen Microsoft-Features üblich sind.

Einfachstes Szenario: Entität mit einem Muster

Hier ist ein einfaches Szenario: Sie möchten, dass Ihre Richtlinie Inhalte identifiziert, die neunstellige Mitarbeiter-IDs enthalten, die in Ihrem organization verwendet werden. Ein Muster bezieht sich auf den regulären Ausdruck in der Regel, der neunstellige Zahlen identifiziert. Alle Inhalte, die eine neunstellige Zahl enthalten, entsprechen dem Muster.

Diagramm der Entität mit einem Muster.

Dieses Muster kann jedoch jede neunstellige Zahl identifizieren, einschließlich längerer Zahlen oder anderer Typen von neunstelligen Zahlen, die keine Mitarbeiter-IDs sind. Diese Art unerwünschter Übereinstimmungen wird als falsch positives Ergebnis bezeichnet.

Häufigeres Szenario: Entität mit mehreren Mustern

Aufgrund der Möglichen für falsch positive Ergebnisse verwenden Sie in der Regel mehr als ein Muster, um eine Entität zu definieren. Mehrere Muster liefern unterstützende Beweise für die Zielentität. Beispielsweise können zusätzliche Schlüsselwörter, Datumsangaben oder anderer Text zur Identifizierung der ursprünglichen Entität beitragen (z. B. die neunstellige Mitarbeiternummer).

Um beispielsweise die Wahrscheinlichkeit zu erhöhen, dass Inhalte identifiziert werden, die eine Mitarbeiter-ID enthalten, können Sie andere Muster definieren, nach denen Sie suchen müssen:

  • Ein Muster, das ein Einstellungsdatum identifiziert.
  • Ein Muster, das sowohl ein Einstellungsdatum als auch die "Mitarbeiter-ID" Schlüsselwort (keyword).

Diagramm der Entität mit mehreren Mustern.

Bei Übereinstimmungen mit mehreren Mustern sind wichtige Punkte zu berücksichtigen:

  • Muster, die mehr Nachweise erfordern, weisen ein höheres Konfidenzniveau auf. Basierend auf dem Konfidenzniveau können Sie die folgenden Aktionen ausführen:

    • Verwenden Sie restriktivere Aktionen (z. B. Blockieren von Inhalten) mit Übereinstimmungen mit höherer Zuverlässigkeit.
    • Verwenden Sie weniger restriktive Aktionen (z. B. Senden von Benachrichtigungen) mit Übereinstimmungen mit geringerer Zuverlässigkeit.

  • Die unterstützenden IdMatch Elemente und Match verweisen auf RegExes und Schlüsselwörter, die eigentlich untergeordnete Elemente des Rule Elements sind, nicht auf Pattern. DiePattern verweisen auf unterstützende Elemente, aber sie sind in enthalten Rule. Dieses Verhalten bedeutet, dass auf eine einzelne Definition eines unterstützenden Elements, z. B. ein regulärer Ausdruck oder eine Schlüsselwort (keyword) Liste, von mehreren Entitäten und Mustern verwiesen werden kann.

Welche Entität müssen Sie identifizieren? [Entity-Element, ID-Attribut]

Eine Entität ist ein vertraulicher Informationstyp, z. B. eine Gutschrift Karte Zahl, die ein klar definiertes Muster aufweist. Jede Entität verfügt über eine eindeutige GUID als ID.

Benennen der Entität und Generieren der GUID

  1. Fügen Sie im XML-Editor Ihrer Wahl die Rules Elemente und Entity hinzu.
  2. Fügen Sie einen Kommentar hinzu, der den Namen Ihrer benutzerdefinierten Entität enthält, z. B. Mitarbeiter-ID. Später fügen Sie den Entitätsnamen zum Abschnitt lokalisierte Zeichenfolgen hinzu, und dieser Name wird im Admin Center angezeigt, wenn Sie eine Richtlinie erstellen.
  3. Generieren Sie eine eindeutige GUID für Ihre Entität. In Windows PowerShell können Sie beispielsweise den Befehl [guid]::NewGuid()ausführen. Später fügen Sie die GUID auch dem Abschnitt mit lokalisierten Zeichenfolgen der Entität hinzu.

XML-Markup mit Regel- und Entitätselementen.

Welches Muster soll übereinstimmen? [Pattern-Element, IdMatch-Element, RegEx-Element]

Das Muster enthält die Liste, wonach der Typ vertraulicher Informationen sucht. Das Muster kann RegExes, Schlüsselwörter und integrierte Funktionen enthalten. Funktionen führen Aufgaben wie das Ausführen von RegExes aus, um Datumsangaben oder Adressen zu finden. Vertrauliche Informationstypen können mehrere Muster mit eindeutigen Angaben zur Vertrauenswürdigkeit aufweisen.

Im folgenden Diagramm verweisen alle Muster auf denselben regulären Ausdruck. Dieser RegEx sucht nach einer neunstelligen Zahl (\d{9}) , die von Leerzeichen (\s) ... (\s)umgeben ist. Das IdMatch -Element verweist auf diesen regulären Ausdruck, und es ist die allgemeine Anforderung für alle Muster, die nach der Entität Employee ID suchen. IdMatch ist der Bezeichner, den das Muster abgleichen soll. Ein Pattern Element muss genau ein IdMatch Element aufweisen.

XML-Markup mit mehreren Pattern-Elementen, die auf ein einzelnes Regex-Element verweisen.

Eine erfüllte Musterüberstimmung gibt eine Anzahl und ein Konfidenzniveau zurück, die Sie in den Bedingungen in Ihrer Richtlinie verwenden können. Wenn Sie einer Richtlinie eine Bedingung zum Erkennen eines vertraulichen Informationstyps hinzufügen, können Sie die Anzahl und die Zuverlässigkeitsstufe wie im folgenden Diagramm dargestellt bearbeiten. Das Konfidenzniveau (auch als Übereinstimmungsgenauigkeit bezeichnet) wird weiter unten in diesem Artikel erläutert.

Optionen für die Instanzanzahl und Übereinstimmungsgenauigkeit.

Reguläre Ausdrücke sind leistungsstark, daher gibt es Probleme, die Sie kennen müssen. Beispielsweise kann sich eine RegEx, die zu viele Inhalte identifiziert, auf die Leistung auswirken. Weitere Informationen zu diesen Problemen finden Sie weiter unten in diesem Artikel im Abschnitt Mögliche Validierungsprobleme, die sie beachten müssen .

Möchten Sie zusätzliche Beweise anfordern? [Match-Element, minCount-Attribut]

Zusätzlich zu IdMatchkann ein Muster das Match -Element verwenden, um zusätzliche unterstützende Beweise wie Schlüsselwort (keyword), RegEx, Datum oder Adresse zu erfordern.

Ein Pattern kann mehrere Match Elemente enthalten:

  • Direkt im Pattern -Element.
  • Kombiniert mithilfe des Any -Elements.

Match -Elemente werden mit einem impliziten AND-Operator verknüpft. Anders ausgedrückt: Alle Match Elemente müssen erfüllt sein, damit das Muster abgeglichen werden kann.

Sie können das Any -Element verwenden, um AND- oder OR-Operatoren einzuführen. Das Any -Element wird weiter unten in diesem Artikel beschrieben.

Sie können das optionale minCount Attribut verwenden, um anzugeben, wie viele Instanzen einer Übereinstimmung für jedes Match Element gefunden werden müssen. Sie können beispielsweise angeben, dass ein Muster nur erfüllt wird, wenn mindestens zwei Schlüsselwörter aus einer Schlüsselwort (keyword) Liste gefunden werden.

XML-Markup mit Match-Element mit minOccurs-Attribut.

Stichwörter [Elemente „Keyword“, „Group“ und „Term“, matchStyle- und caseSensitive-Attribute]

Wie bereits beschrieben, erfordert die Identifizierung vertraulicher Informationen häufig zusätzliche Schlüsselwörter als bestätigende Beweise. Zusätzlich zum Abgleich einer neunstelligen Zahl können Sie beispielsweise mit dem Keyword-Element nach Wörtern wie "Karte", "Badge" oder "ID" suchen. Das Keyword Element verfügt über ein ID Attribut, auf das von mehreren Match Elementen in mehreren Mustern oder Entitäten verwiesen werden kann.

Schlüsselwörter werden als Liste von Term Elementen in einem Group -Element eingeschlossen. Das Group -Element verfügt über ein matchStyle -Attribut mit zwei möglichen Werten:

  • matchStyle="word": Eine Wortversprechung identifiziert ganze Wörter, die von Leerzeichen oder anderen Trennzeichen umgeben sind. Sie sollten immer Wort verwenden, es sei denn, Sie müssen Teile von Wörtern oder Wörtern in asiatischen Sprachen abgleichen.

  • matchStyle="string": Eine Zeichenfolgenübereinstimmung identifiziert Zeichenfolgen, unabhängig davon, wovon sie umgeben sind. Beispielsweise entspricht "ID" sowohl "bid" als auch "idea". Verwenden Sie string nur, wenn Sie asiatische Wörter abgleichen müssen oder wenn Ihre Schlüsselwort (keyword) möglicherweise in anderen Zeichenfolgen enthalten ist.

Schließlich können Sie das caseSensitive -Attribut des Term -Elements verwenden, um anzugeben, dass der Inhalt genau mit dem Schlüsselwort (keyword) übereinstimmen muss, einschließlich Klein- und Großbuchstaben.

XML-Markup mit Übereinstimmungselementen, die auf Schlüsselwörter verweisen.

Reguläre Ausdrücke [Element „Regex“]

In diesem Beispiel verwendet die Mitarbeiterentität ID das IdMatch Element bereits, um auf einen regulären Ausdruck für das Muster zu verweisen: eine neunstellige Zahl, die von Leerzeichen umgeben ist. Darüber hinaus kann ein Muster ein Match -Element verwenden, um auf ein zusätzliches Regex Element zu verweisen, um bestätigende Beweise zu identifizieren, z. B. eine fünfstellige oder neunstellige Zahl im Format einer US-Postleitzahl.

Zusätzliche Muster wie Datumsangaben oder Adressen [integrierte Funktionen]

Vertrauliche Informationstypen können auch integrierte Funktionen verwenden, um bestätigende Beweise zu identifizieren. Beispiel: US-Datum, EU-Datum, Ablaufdatum oder US-Adresse. Microsoft 365 unterstützt das Hochladen Ihrer eigenen benutzerdefinierten Funktionen nicht. Wenn Sie jedoch einen benutzerdefinierten vertraulichen Informationstyp erstellen, kann Ihre Entität auf integrierte Funktionen verweisen.

Beispielsweise weist ein Mitarbeiter-ID-Badge ein Einstellungsdatum auf, sodass diese benutzerdefinierte Entität die integrierte Func_us_date Funktion verwenden kann, um ein Datum in dem Format zu identifizieren, das in den USA häufig verwendet wird.

Weitere Informationen finden Sie unter Funktionen des Typs vertraulicher Informationen.

XML-Markup mit Match-Element, das auf die integrierte Funktion verweist.

Verschiedene Kombinationen von Nachweisen [Element „Any“, minMatches- und maxMatches-Attribute]

In einem Pattern -Element werden alle IdMatch - und Match -Elemente mit einem impliziten AND-Operator verknüpft. Anders ausgedrückt: Alle Übereinstimmungen müssen erfüllt sein, bevor das Muster erfüllt werden kann.

Sie können flexiblere Abgleichslogik erstellen, indem Sie das -Element zum Gruppieren Match von Any Elementen verwenden. Beispielsweise können Sie das Any -Element verwenden, um alle, keine oder eine genaue Teilmenge seiner untergeordneten Match Elemente abzugleichen.

Das Any Element verfügt über optionale minMatches Attribute und maxMatches , mit denen Sie definieren können, wie viele der untergeordneten Match Elemente erfüllt werden müssen, bevor das Muster abgeglichen wird. Diese Attribute definieren die Anzahl der Match Elemente, nicht die Anzahl von Beweisinstanzen, die für die Übereinstimmungen gefunden wurden. Um eine Mindestanzahl von Instanzen für eine bestimmte Übereinstimmung zu definieren, z. B. zwei Schlüsselwörter aus einer Liste, verwenden Sie das minCount -Attribut für ein Match Element (siehe oben).

Übereinstimmung mit mindestens einem untergeordneten "Match"-Element

Um nur eine Mindestanzahl von Match Elementen zu erfordern, können Sie das minMatches -Attribut verwenden. Tatsächlich werden diese Match Elemente mit einem impliziten OR-Operator verknüpft. Dieses Any Element ist erfüllt, wenn ein Datum im US-Format oder ein Schlüsselwort (keyword) aus einer der Listen gefunden wird.

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

Übereinstimmung mit einer genauen Untermenge beliebiger untergeordneter Match-Elemente

Um eine genaue Anzahl von Match Elementen zu erfordern, legen Sie und maxMatches auf den gleichen Wert festminMatches. Dieses Any Element ist nur erfüllt, wenn genau ein Datum oder Schlüsselwort (keyword) gefunden wird. Wenn weitere Übereinstimmungen vorhanden sind, wird das Muster nicht abgeglichen.

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

Übereinstimmung mit keinem untergeordneten "Match"-Element

Wenn Sie das Fehlen bestimmter Beweise für die Erfüllung eines Musters verlangen möchten, können Sie sowohl minMatches als auch maxMatches auf 0 festlegen. Dies kann nützlich sein, wenn Sie über eine Schlüsselwort (keyword) Liste oder andere Beweise verfügen, die wahrscheinlich auf ein falsch positives Ergebnis hindeuten.

Beispielsweise sucht die Mitarbeiter-ID-Entität nach dem Schlüsselwort (keyword) "Karte", da sie auf eine "ID Karte" verweisen kann. Wenn Karte jedoch nur im Ausdruck "credit Karte" vorkommt, bedeutet "Karte" in diesem Inhalt unwahrscheinlicherweise "ID Karte". Sie können also "Guthaben Karte" als Schlüsselwort (keyword) zu einer Liste von Begriffen hinzufügen, die Sie von der Erfüllung des Musters ausschließen möchten.

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

Übereinstimmung mit mehreren eindeutigen Begriffen

Wenn Sie mehrere eindeutige Begriffe abgleichen möchten, verwenden Sie den parameter uniqueResults , der auf true festgelegt ist, wie im folgenden Beispiel gezeigt:

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

In diesem Beispiel ist ein Muster für die Gehaltsrevision mit mindestens drei eindeutigen Übereinstimmungen definiert.

Wie nah an der Entität muss der andere Beweis sein? [patternsProximity-Attribut]

Ihr vertraulicher Informationstyp sucht nach einem Muster, das eine Mitarbeiter-ID darstellt, und als Teil dieses Musters sucht er auch nach bestätigenden Beweisen wie einem Schlüsselwort (keyword) wie "ID". Es ist sinnvoll, dass je näher dieser Beweis ist, desto wahrscheinlicher ist es, dass das Muster eine tatsächliche Mitarbeiter-ID ist. Mithilfe des erforderlichen patternsProximity-Attributs des Entity-Elements können Sie bestimmen, wie nah andere Nachweise im Muster der Entität sein müssen.

XML-Markup mit patternsProximity-Attribut.

Für jedes Muster in der Entität definiert der Attributwert patternsProximity den Abstand (in Unicode-Zeichen) vom IdMatch-Speicherort für alle anderen Übereinstimmungen, die für dieses Muster angegeben sind. Das Näherungsfenster wird von der IdMatch-Position verankert, wobei das Fenster links und rechts von "IdMatch" erweitert wird.

Diagramm des Näherungsfensters.

Das folgende Beispiel veranschaulicht, wie sich das Näherungsfenster auf den Musterabgleich auswirkt, wobei das IdMatch-Element für die benutzerdefinierte Entität der Mitarbeiter-ID mindestens eine bestätigende Übereinstimmung mit Schlüsselwort (keyword) oder Datum erfordert. Nur ID1 stimmt überein, da für ID2 und ID3 im Näherungsfenster kein oder nur teilweise bestätigender Beweis gefunden wird.

Diagramm des Bestätigungsbeweis- und Näherungsfensters.

Bei E-Mails werden der Nachrichtentext und jede Anlage als separate Elemente behandelt. Dies bedeutet, dass das Näherungsfenster nicht über das Ende jedes dieser Elemente hinausgeht. Für jedes Element (Anlage oder Text) müssen sich sowohl der idMatch- als auch der bestätigende Beweis in diesem Element befinden.

Was sind die richtigen Konfidenzniveaus für verschiedene Muster? [confidenceLevel-Attribut, recommendedConfidence-Attribut]

Je mehr Beweise für ein Muster erforderlich sind, desto mehr Vertrauen haben Sie, dass eine tatsächliche Entität (z. B. Mitarbeiter-ID) identifiziert wurde, wenn das Muster abgeglichen wird. Beispielsweise haben Sie mehr Vertrauen in ein Muster, das eine neunstellige ID-Nummer, ein Einstellungsdatum und Schlüsselwort (keyword) in unmittelbarer Nähe erfordert, als in einem Muster, das nur eine neunstellige ID-Nummer erfordert.

Das Element "Pattern" weist ein erforderliches Attribut "confidenceLevel" auf. Sie können sich den Wert von confidenceLevel (ein Wert zwischen 65/75/85, der die Konfidenzstufen Niedrig/Mittel/Hoch angibt) als eindeutige ID für jedes Muster in einer Entität vorstellen. Nachdem Sie den benutzerdefinierten vertraulichen Informationstyp hochgeladen und anschließend eine Richtlinie erstellt haben, können Sie in den Bedingungen der von Ihnen erstellten Regeln auf diese Konfidenzniveaus verweisen.

XML-Markup mit Pattern-Elementen mit unterschiedlichen Werten für das ConfidenceLevel-Attribut.

Zusätzlich zu "confidenceLevel" für jedes Muster weist "Entity" ein Attribut "recommendedConfidence" auf. Dieses Attribut für die empfohlene Konfidenz kann man sich als das Standardkonfidenzniveau für die Regel vorstellen. Wenn Sie beim Erstellen einer Regel in einer Richtlinie kein Konfidenzniveau für die zu verwendende Regel angeben, wird diese Regel basierend auf dem empfohlenen Konfidenzniveau für die Entität abgeglichen. Beachten Sie, dass das recommendedConfidence-Attribut für jede Entitäts-ID im Regelpaket obligatorisch ist. Wenn sie fehlt, können Sie keine Richtlinien speichern, die den Vertraulichen Informationstyp verwenden.

Möchten Sie andere Sprachen auf der Benutzeroberfläche des Complianceportals unterstützen? [LocalizedStrings-Element]

Wenn Ihr Complianceteam die Microsoft Purview-Complianceportal verwendet, um Richtlinien in verschiedenen Gebietsschemas und sprachen zu erstellen, können Sie lokalisierte Versionen des Namens und der Beschreibung Ihres benutzerdefinierten vertraulichen Informationstyps bereitstellen. Wenn Ihr Complianceteam Microsoft 365 in einer von Ihnen unterstützten Sprache verwendet, wird der lokalisierte Name auf der Benutzeroberfläche angezeigt.

Konfiguration der Instanzanzahl und Übereinstimmungsgenauigkeit.

Das Rules-Element muss ein LocalizedStrings-Element enthalten, das ein Resource-Element enthält, das auf die GUID Ihrer benutzerdefinierten Entität verweist. Jedes Resource-Element enthält wiederum ein oder mehrere Name- und Description-Elemente, die jeweils das langcode -Attribut verwenden, um eine lokalisierte Zeichenfolge für eine bestimmte Sprache bereitzustellen.

XML-Markup, das den Inhalt des LocalizedStrings-Elements anzeigt.

Beachten Sie, dass Sie lokalisierte Zeichenfolgen nur für die Anzeige Ihres benutzerdefinierten vertraulichen Informationstyps auf der Benutzeroberfläche des Compliance Centers verwenden. Sie können lokalisierte Zeichenfolgen nicht verwenden, um verschiedene lokalisierte Versionen einer Schlüsselwortliste oder eines regulären Ausdrucks bereitzustellen.

Sonstige Regelpaket-Markups [RulePack-GUID]

Schließlich enthält der Anfang jedes RulePackage einige allgemeine Informationen, die Sie ausfüllen müssen. Sie können das folgende Markup als Vorlage verwenden und "" ersetzen. . ." Platzhalter mit Ihren eigenen Informationen.

Am wichtigsten ist, dass Sie eine GUID für das RulePack generieren müssen. Zuvor haben Sie eine GUID für die Entität generiert. Dies ist eine zweite GUID für das RulePack. GUIDs können auf verschiedene Arten generiert werden, besonders einfach ist es aber in PowerShell. Dort müssen Sie nur [guid]::NewGuid() eingeben.

Das Version-Element ist ebenfalls wichtig. Wenn Sie Ihr Regelpaket zum ersten Mal hochladen, notiert Microsoft 365 die Versionsnummer. Wenn Sie später das Regelpaket aktualisieren und eine neue Version hochladen, stellen Sie sicher, dass Sie die Versionsnummer aktualisieren. Andernfalls stellt Microsoft 365 das Regelpaket nicht bereit.

<?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>

Wenn es fertig ist, sollte das RulePack-Element wie folgt aussehen.

XML-Markup mit RulePack-Element.

Validators

Microsoft 365 macht Funktionsprozessoren für häufig verwendete SITs als Validierungssteuerelemente verfügbar. Hier ist eine Liste von ihnen.

Liste der derzeit verfügbaren Validierungssteuerelemente

  • 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

Dadurch haben Sie die Möglichkeit, Ihre eigene RegEx zu definieren und zu überprüfen. Um Validierungssteuerelemente zu verwenden, definieren Sie Ihre eigene RegEx-Funktion, und verwenden Sie die Validator -Eigenschaft, um den Funktionsprozessor Ihrer Wahl hinzuzufügen. Nach der Definition können Sie diesen RegEx in einem SIT verwenden.

Im folgenden Beispiel wird ein regulärer Ausdruck - Regex_credit_card_AdditionalDelimiters für Credit Karte definiert, der dann mithilfe der Prüfsummenfunktion für kreditwürdige Karte überprüft wird, indem Func_credit_card als Validierungssteuerelement verwendet wird.

<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 bietet zwei generische Validierungssteuerelemente.

Prüfsummen-Validierungssteuerelement

In diesem Beispiel wird ein Prüfsummen-Validierungssteuerelement für die Mitarbeiter-ID definiert, um die RegEx für EmployeeID zu überprüfen.

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

Datumsüberprüfung

In diesem Beispiel wird ein Datumsüberprüfungssteuerelement für einen RegEx-Teil definiert, von dem date ist.

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

Änderungen für Exchange Online

Sie haben bisher möglicherweise Exchange Online PowerShell verwendet, um Ihre benutzerdefinierten Typen für vertrauliche Informationen für DLP zu importieren. Jetzt können Ihre benutzerdefinierten Typen vertraulicher Informationen sowohl im Exchange Admin Center]"https://go.microsoft.com/fwlink/p/?linkid=2059104") als auch im Microsoft Purview-Complianceportal verwendet werden. Im Rahmen dieser Verbesserung sollten Sie Security & Compliance PowerShell verwenden, um Ihre benutzerdefinierten Typen vertraulicher Informationen zu importieren. Sie können sie nicht mehr aus Exchange Online PowerShell importieren. Ihre benutzerdefinierten vertraulichen Informationstypen funktionieren weiterhin wie zuvor, es kann jedoch bis zu einer Stunde dauern, bis Änderungen, die Sie im Compliance Center an benutzerdefinierten vertraulichen Informationstypen vorgenommen haben, im Exchange Admin Center angezeigt werden.

Beachten Sie, dass Sie im Compliance Center das Cmdlet New-DlpSensitiveInformationTypeRulePackage verwenden, um ein Regelpaket hochzuladen. (Zuvor haben Sie im Exchange Admin Center das Cmdlet ClassificationRuleCollection verwendet.)

Hochladen des Regelpakets

Gehen Sie zum Hochladen des Regelpakets wie folgt vor:

  1. Speichern Sie es als XML-Datei mit Unicode-Codierung.

  2. Verbinden Sie sich mit Security & Compliance PowerShell

  3. Verwenden Sie die folgende Syntax:

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

    Dieses Beispiel lädt die Unicode-XML-Datei mit dem Namen „MyNewRulePack.xml“ aus C:\Dokumente“ hoch.

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

    Ausführliche Informationen zur Syntax und zu den Parametern finden Sie unter New-DlpSensitiveInformationTypeRulePackage.

    Hinweis

    Maximal werden 10 Regelpakete unterstützt, aber jedes Paket kann die Definition mehrerer Typen vertraulicher Informationen enthalten.

  4. Um sicherzustellen, dass Sie einen neuen Typ für vertrauliche Informationen erstellt haben, führen Sie einen der folgenden Schritte aus:

    • Führen Sie das Cmdlet Get-DlpSensitiveInformationTypeRulePackage aus, um zu überprüfen, ob das neue Regelpaket aufgeführt wird:

      Get-DlpSensitiveInformationTypeRulePackage

    • Führen Sie das Cmdlet Get-DlpSensitiveInformationType aus, um zu überprüfen, ob der Typ für vertrauliche Informationen aufgeführt wird:

      Get-DlpSensitiveInformationType

      Bei benutzerdefinierten Typen für vertrauliche Informationen ist der Publisher-Eigenschaftswert ein anderer als „Microsoft Corporation“.

    • Ersetzen Sie <Name> durch den Namenswert des Typs für vertrauliche Informationen (z. B. die Mitarbeiter-ID), und führen Sie das Cmdlet Get-DlpSensitiveInformationType aus:

      Get-DlpSensitiveInformationType -Identity "<Name>"

Mögliche Überprüfungsprobleme, die Sie beachten müssen

Wenn Sie die XML-Datei des Regelpakets hochladen, überprüft das System den XML-Code und sucht nach bekannten fehlerhaften Mustern und offensichtlichen Leistungsproblemen. Im Folgenden finden Sie einige bekannte Probleme, auf die die Überprüfung überprüft – einen regulären Ausdruck:

  • Lookbehind-Assertionen im regulären Ausdruck sollten nur eine feste Länge aufweisen. Assertionen variabler Länge führen zu Fehlern.

    Beispielsweise "(?<=^|\s|_)" wird die Überprüfung nicht bestanden. Das erste Muster (^) hat die Länge null, während die nächsten beiden Muster (\s und _) eine Länge von 1 haben. Eine alternative Möglichkeit zum Schreiben dieses regulären Ausdrucks ist "(?:^|(?<=\s|_))".

  • Kann nicht mit dem Alternator |beginnen oder enden, der mit allem übereinstimmt, da er als leere Übereinstimmung betrachtet wird.

    Oder wird z. B |ab| . die Überprüfung nicht bestehen.

  • Kann nicht mit einem .{0,m} Muster beginnen oder enden, das keinen funktionalen Zweck hat und nur die Leistung beeinträchtigt.

    Oder wird z. B .{0,50}ASDFASDF.{0,50} . die Überprüfung nicht bestehen.

  • .{0,m}.{1,m} Oder kann nicht in Gruppen und in Gruppen nicht oder .+ enthalten .\* sein.

    Beispielsweise (.{0,50000}) wird die Überprüfung nicht bestanden.

  • Darf keine Zeichen mit {0,m} oder {1,m} Repeatern in Gruppen haben.

    Beispielsweise (a\*) wird die Überprüfung nicht bestanden.

  • Kann nicht mit beginnen oder enden .{1,m}. Verwenden Sie .stattdessen .

    Beispielsweise .{1,m}asdf wird die Überprüfung nicht bestanden. Verwenden Sie .asdfstattdessen .

  • Es ist nicht möglich, einen ungebundenen Repeater (z * . B. oder +) für eine Gruppe zu verwenden.

    Beispielsweise (xx)\* bestehen und (xx)+ die Überprüfung nicht.

  • Schlüsselwörter dürfen aus maximal 50 Zeichen bestehen. Wenn eine Gruppe ein Schlüsselwort enthält, das diesen Wert überschreitet, besteht eine vorgeschlagene Lösung darin, die Gruppe von Begriffen als Schlüsselwörterbuch zu erstellen und auf die GUID des Schlüsselwörterbuchs innerhalb der XML-Struktur als Teil der Entität für die Übereinstimmung oder idMatch in der Datei zu verweisen.

  • Jeder benutzerdefinierte Typ vertraulicher Informationen kann maximal 2048 Schlüsselwörter enthalten.

  • Die maximale Größe von Schlüsselwortwörterbüchern in einem einzelnen Mandanten beträgt 480 KB komprimiert, um die AD-Schemagrenzwerte zu erfüllen. Verweisen Sie beim Erstellen benutzerdefinierter vertraulicher Informationstypen so oft wie nötig auf dasselbe Wörterbuch. Beginnen Sie mit dem Erstellen benutzerdefinierter Schlüsselwortlisten im vertraulichen Informationstyp und verwenden Sie Schlüsselwörterbücher, wenn Sie mehr als 2048 Schlüsselworte in einer Schlüsselwortliste haben oder ein Schlüsselwort länger als 50 Zeichen ist.

  • In einem Mandanten sind maximal 50 auf Schlüsselwörterwörterbüchern basierende Typen vertraulicher Informationen zulässig.

  • Stellen Sie sicher, dass jedes Element der Entität ein Attribut recommendedConfidence enthält.

  • Bei Verwendung des PowerShell-Cmdlets gibt es eine maximale Rückgabegröße der deserialisierten Daten von ca. 1 Megabyte. Dies wirkt sich auf die Größe der Regelpaket-XML-Datei aus. Beschränken Sie die hochgeladene Datei auf eine maximale Größe von 770 Kilobyte als ein vorgeschlagener Grenzwert, um konsistente Ergebnisse ohne Fehler bei der Verarbeitung zu erhalten.

  • Die XML-Struktur erfordert keine Formatierungszeichen wie Leerzeichen, Registerkarten oder Wagenrücklauf-/Zeilenvorschubeinträge. Beachten Sie dies beim Optimieren des Speicherplatzes bei Uploads. Tools wie Microsoft Visual Code bieten Verknüpfungslinie-Features zum Komprimieren der XML-Datei.

Wenn ein benutzerdefinierter Typ für vertrauliche Informationen ein Problem enthält, das die Leistung beeinträchtigen könnte, wird er nicht hochgeladen, und es wird möglicherweise eine der folgenden Fehlermeldungen angezeigt:

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

  • Lookaround assertions

  • Complex grouping in conjunction with general quantifiers

Neues Durchforsten des Inhalts, um die Typen für vertrauliche Informationen zu identifizieren

Microsoft 365 verwendet den Suchcrawler zum Erkennen und Klassifizieren vertraulicher Informationen in Websiteinhalten. Inhalte von SharePoint Online- und OneDrive for Business-Websites werden automatisch erneut durchforstet, sobald sie aktualisiert wurden. Um aber den neuen benutzerdefinierten vertraulichen Informationstyp in allen vorhandenen Inhalten zu identifizieren, müssen diese Inhalte erneut durchforstet werden.

In Microsoft 365 können Sie nicht manuell ein erneutes Durchforsen eines gesamten organization anfordern, aber Sie können manuell ein erneutes Durchforsen für eine Websitesammlung, Liste oder Bibliothek anfordern. Weitere Informationen finden Sie unter Manuelles Anfordern der Durchforstung und Neuindizierung einer Website, einer Bibliothek oder einer Liste.

Referenz: XML-Schemadefinition für Regelpaket

Sie können dieses Markup kopieren, als eine XSD-Datei speichern und diese zum Überprüfen der XML-Datei für das Regelpaket verwenden.

<?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>

Weitere Informationen