Skapa en anpassad typ av känslig information med PowerShell

I den här artikeln beskrivs hur du skapar en XML-regelpaketfil som definierar anpassade typer av känslig information. I den här artikeln beskrivs en anpassad typ av känslig information som identifierar ett anställnings-ID. Du kan använda XML-exempelfilen i den här artikeln som utgångspunkt för din egen XML-fil.

Mer information om typer av känslig information finns i Läs mer om typer av känslig information.

När du har skapat en väl utformad XML-fil kan du ladda upp den till Microsoft 365 med hjälp av PowerShell. Sedan är du redo att använda den anpassade typen av känslig information i principer. Du kan testa hur effektivt det är att identifiera den känsliga informationen som du tänkt dig.

Anteckning

Om du inte behöver den detaljerad kontroll som PowerShell tillhandahåller kan du skapa anpassade typer av känslig information i Microsoft 365 Efterlevnadscenter. Mer information finns i Skapa en anpassad typ av känslig information.

Viktig ansvarsfriskrivning

Microsoft Support kan inte hjälpa dig att skapa definitioner för innehållsmatchning.

För anpassad utveckling, testning och felsökning av innehållsmatchning måste du använda dina egna interna IT-resurser eller använda konsulttjänster, till exempel Microsoft Consulting Services (MCS). Microsofts supporttekniker kan ge begränsat stöd för den här funktionen, men de kan inte garantera att anpassade innehållsmatchningsförslag helt uppfyller dina behov.

MCS kan tillhandahålla reguljära uttryck för teständamål. De kan också hjälpa dig med felsökning av ett befintligt RegEx-mönster som inte fungerar som förväntat med ett enda särskilt innehållsexempel.

Läs Mer information finns i Möjliga verifieringsproblem som du bör känna till i den här artikeln.

Mer information om Boost.RegEx-motorn (tidigare kallad RegEx++) som används för att bearbeta texten finns i Boost.Regex 5.1.3.

Anteckning

Om du använder ett et-tecken (&) som en del av ett nyckelord i din anpassade typ av känslig information måste du lägga till ytterligare en term med blanksteg runt tecknet. Använd till exempel L & P inte L&P.

XML-exempel för regelpaket

Här är XML-exemplet för regelpaketet som vi skapar i den här artikeln. Element och attribut förklaras i avsnitten nedan.

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

Vilka är dina viktigaste krav? [elementen Rule, Entity, Pattern]

Det är viktigt att du förstår den grundläggande strukturen i XML-schemat för en regel. Din förståelse av strukturen hjälper dig att identifiera rätt innehåll med anpassad typ av känslig information.

En regel definierar en eller flera enheter (kallas även typer av känslig information). Varje entitet definierar ett eller flera mönster. Ett mönster är det som en princip söker efter när den utvärderar innehåll (till exempel e-post och dokument).

I XML-kod betyder "regler" de mönster som definierar typen av känslig information. Koppla inte referenser till regler i den här artikeln med "villkor" eller "åtgärder" som är vanliga i andra Microsoft-funktioner.

Enklaste scenariot: entitet med ett mönster

Här är ett enkelt scenario: Du vill att principen ska identifiera innehåll som innehåller niosiffriga anställnings-IDn som används i organisationen. Ett mönster refererar till det reguljära uttrycket i regeln som identifierar niosiffriga tal. Allt innehåll som innehåller ett niosiffrigt tal motsvarar mönstret.

Diagram över entitet med ett mönster.

Men det här mönstret kan identifiera niosiffriga nummer, inklusive längre tal eller andra typer av niosiffriga nummer som inte är anställnings-ID. Den här typen av oönskad matchning kallas för en falsk positiv matchning.

Ett vanligare scenario: entitet med flera mönster

På grund av risken för falska positiva resultat använder du vanligtvis fler än ett mönster för att definiera en enhet. Flera mönster ger kompletterande bevis för målenheten. Till exempel kan ytterligare nyckelord, datum eller annan text hjälpa till att identifiera den ursprungliga enheten (till exempel det niosiffriga anställningsnumret).

Om du till exempel vill öka sannolikheten att identifiera innehåll som innehåller ett anställnings-ID kan du definiera andra mönster att söka efter:

  • Ett mönster som identifierar ett anställningsdatum.
  • Ett mönster som identifierar både anställningsdatum och nyckelordet "anställnings-ID".

Diagram över entitet med flera mönster.

Det finns viktiga punkter att tänka på för flera mönstermatchning:

  • Mönster som kräver fler bevis har högre konfidensnivå. Du kan vidta följande åtgärder baserat på konfidensnivån:

    • Använd mer restriktiva åtgärder (till exempel blockera innehåll) med matchningar med högre konfidens.
    • Använd mindre restriktiva åtgärder (till exempel skicka meddelanden) med lägre förtroende-matchningar.
  • Stöd- IdMatch och Match element refererar till RegExes och nyckelord som i själva verket är Rule underordnade elementet, inte .Pattern De här stödelementen refereras till av Pattern, men ingår i Rule. Det här beteendet innebär att en enda definition av ett stödelement, till exempel ett reguljärt uttryck eller en nyckelordslista, kan refereras av flera enheter och mönster.

Vilken entitet behöver du identifiera? [Entitetselement, ID-attribut]

En entitet är en typ av känslig information, till exempel kreditkortsnummer, som har ett väldefinierat mönster. Varje entitet har ett unikt GUID som ID.

Namnge entiteten och generera dess GUID

  1. Lägg till och element i valfri Rules XML-redigerare Entity .
  2. Lägg till en kommentar som innehåller namnet på din anpassade entitet, till exempel Anställnings-ID. Senare lägger du till namnet på enheten i det lokaliserade strängavsnittet och det namnet visas i administrationscentret när du skapar en princip.
  3. Generera en unik GUID för din enhet. I Windows PowerShell kan du till exempel köra kommandot [guid]::NewGuid(). Senare lägger du också till GUID i avsnittet för lokaliserade strängar i entiteten.

XML-kod som visar elementen Regler och Entitet.

Vilket mönster vill du matcha? [elementet Pattern, elementet IdMatch, elementet Regex]

Mönstret innehåller en lista över vad typen av känslig information söker efter. Mönstret kan omfatta RegExes, nyckelord och inbyggda funktioner. Funktioner kan utföra uppgifter som att köra RegExes för att hitta datum eller adresser. Typer av känslig information kan ha flera mönster med unik konfidens.

I följande diagram refererar alla mönster till samma reguljära uttryck. RegEx söker efter ett niosiffrigt nummer omgivet (\d{9}) av tomt utrymme (\s) ... (\s). Det här reguljära uttrycket refereras till av IdMatch elementet och är ett vanligt krav för alla mönster som söker efter entitet för anställnings-ID. IdMatch är identifieraren som mönstret försöker matcha. Ett Pattern element måste ha exakt ett IdMatch element.

XML-kod som visar flera mönsterelement som refererar till ett enda Regex-element.

En nöjd mönstermatchning returnerar en antal- och konfidensnivå, som du kan använda i villkoren i principen. När du lägger till ett villkor för att identifiera en typ av känslig information i en princip kan du redigera antal och konfidensnivå enligt följande diagram. Konfidensnivån (kallas även matchningsprecision) förklaras längre fram i den här artikeln.

Alternativ för antal förekomster och matchning av precision.

Reguljära uttryck är kraftfulla verktyg, så det finns problem som du behöver känna till. En RegEx som till exempel identifierar för mycket innehåll kan påverka prestandan. Mer information om dessa problem finns i avsnittet Möjliga valideringsproblem som du bör känna till längre fram i den här artikeln.

Vill du kräva ytterligare bevis? [elementet Match, attributet minCount]

Utöver kan ett IdMatchmönster använda elementet för Match att kräva ytterligare stöd bevis, till exempel ett nyckelord, RegEx, datum eller adress.

A Pattern kan innehålla flera Match element:

  • Direkt i Pattern elementet.
  • Kombineras genom att använda Any elementet.

Match Element sammanförs av en implicit OCH-operator. Med andra ord måste alla Match element vara nöjda för att mönstret ska matchas.

Du kan använda elementet för Any att introducera operatorerna OCH eller ELLER. Elementet Any beskrivs senare i den här artikeln.

Du kan använda det valfria minCount attributet för att ange hur många instanser av en matchning som behöver hittas för varje Match element. Du kan till exempel ange att ett mönster bara är uppfyllt när minst två nyckelord från en nyckelordslista hittas.

XML-kod som visar matchningselement med attributet minOccurs.

Nyckelord [elementen Keyword, Group och Term elements, attributen matchStyle och caseSensitive]

Enligt beskrivningen tidigare kräver identifiering av känslig information ofta ytterligare nyckelord som bekräftande bevis. Förutom att matcha ett niosiffrigt tal kan du till exempel söka efter ord som "kort", "märke" eller "ID" med hjälp av Nyckelordselement. Elementet Keyword har ett attribut ID som kan refereras av flera Match element i flera mönster eller enheter.

Nyckelord ingår som en lista över element Term i ett Group element. Elementet Group har ett attribut matchStyle med två möjliga värden:

  • matchStyle="word": En ordmatchning identifierar hela ord omgivna av tomt utrymme eller andra avgränsare. Du bör alltid använda word om du inte behöver matcha delar av ord eller ord på asiatiska språk.

  • matchStyle="string": En strängmatchning identifierar strängar oavsett vad de omges av. Till exempel matchar "ID" "bud" och "idé". Använd string endast när du behöver matcha asiatiska ord eller om ditt nyckelord kan ingå i andra strängar.

Slutligen kan du använda caseSensitive attributet Term för elementet för att ange att innehållet måste matcha nyckelordet exakt, inklusive gemener och versaler.

XML-kod som visar matchning av element som refererar till nyckelord.

Reguljära uttryck [elementet Regex]

I det här exemplet använder den ID anställdas IdMatch entitet redan elementet för att referera till ett vanligt uttryck för mönstret: ett niosiffrigt tal omgivet av blanksteg. Dessutom kan ett Match mönster använda ett element Regex för att referera till ytterligare ett element för att identifiera korroativa bevis, till exempel ett femsiffrigt eller niosiffrigt tal i ett postnummer i USA.

Ytterligare mönster, till exempel datum eller adresser [inbyggda funktioner]

Typer av känslig information kan också använda inbyggda funktioner för att identifiera bekräftar bevis. Till exempel usa-datum, EU-datum, utgångsdatum eller amerikansk adress. Microsoft 365 har inte stöd för att ladda upp egna anpassade funktioner. Men när du skapar en anpassad typ av känslig information kan entiteten referera till inbyggda funktioner.

Till exempel har ett anställnings-ID-märke anställningsdatum, så att denna anpassade entitet kan använda den inbyggda Func_us_date funktionen för att identifiera ett datum i det format som ofta används i USA.

Mer information finns i Vad DLP-funktionerna letar efter.

XML-kod som visar matcha element som refererar till den inbyggda funktionen.

Olika kombinationer av bevis [elementet Any, attributen minMatches och maxMatches]

I ett Pattern element sammanförs IdMatch alla Match element och med en implicit OCH-operator. Med andra ord måste alla matchningar vara uppfyllda innan mönstret kan vara uppfyllt.

Du kan skapa mer flexibel matchningslogik genom att använda Any elementet för att gruppera Match element. Du kan till exempel använda elementet för Any att matcha alla, inga eller en exakt delmängd av dess underordnade Match element.

Elementet Any har valfria minMatches attribut och maxMatches attribut som du kan använda för att definiera hur Match många av de underordnade elementen som måste vara uppfyllda innan mönstret matchas. Attributen definierar antalet element Match , inte antalet förekomster av bevis för matchningarna. Om du vill definiera ett minsta antal instanser för en viss matchning, till exempel två nyckelord från en lista, minCount använder du attributet för ett Match element (se ovan).

Matcha minst ett underordnat Match-element

Om du bara vill kräva ett minimiantal Match element kan du använda minMatches attributet. Elementen sammanförs Match i praktiken med en implicit ELLER-operator. Det Any här elementet är nöjd om ett datum som har formaterats i USA eller ett nyckelord från någon av listan hittas.

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

Matcha en exakt delmängd av underordnade Match-element

Om du vill kräva ett exakt antal Match element anger minMatches du maxMatches och får samma värde. Det Any här elementet är bara uppfyllt om exakt ett datum eller nyckelord hittas. Om det finns fler matchningar matchas inte mönstret.

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

Matcha inget av underordnade Match-element

Om du vill kräva att specifika bevis inte får finnas för att ett mönster ska uppfyllas kan du ange värdet 0 för både minMatches och maxMatches. Det kan vara användbart om du har en nyckelordslista eller andra bevis som troligen ger en falsk positiv identifiering.

Entiteten employee ID (medarbetar-ID) letar till exempel efter nyckelordet ”card” (kort) eftersom det kan referera till ett ”ID card” (ID-kort). Men om ”card” endast förekommer i frasen ”credit card” (kreditkort) är det inte sannolikt att “card” i det här innehållet betyder “ID card”. Du kan alltså lägga till ”credit card” som ett nyckelord i en lista med termer som inte får finnas för att mönstret ska uppfyllas.

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

Matcha ett antal unika termer

Om du vill matcha ett antal unika termer använder du parametern uniqueResults inställd på true, som i följande exempel:

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

I det här exemplet definieras ett mönster för lönerevision med minst tre unika matchningar.

Hur nära entiteten måste det andra beviset vara? [attributet patternsProximity]

Din typ av känslig information letar efter ett mönster som representerar ett medarbetar-ID, och som en del i mönstret letar den även efter samarbetsbevis, till exempel ett nyckelord som ”ID”. Det är logiskt att ju närmare detta bevis är, desto troligare är det att mönstret är ett faktiskt medarbetar-ID. Du kan ange hur nära andra bevis i mönstret måste vara i förhållande till entiteten med hjälp av det obligatoriska attributet patternsProximity i elementet Entity.

XML-kod som visar mönsterProximity-attributet.

För varje mönster i entiteten definierar värdet för attributet patternsProximity avståndet (i Unicode-tecken) från platsen för IdMatch för alla andra Match-element som angetts för mönstret. Närhetsfönstret är förankrat vid IdMatch-platsen, och fortsätter till vänster och höger om IdMatch.

Diagram över närhetsfönstret.

Exemplet nedan visar hur närhetsfönstret påverkar mönstermatchningen där elementet IdMatch för den anpassade entiteten medarbetar-ID kräver minst en samarbetsmatchning av nyckelord eller datum. Endast ID1 matchar eftersom inget eller bara delvisa samarbetsbevis hittas för ID2 och ID3 inom närhetsfönstret.

Diagram över bekräftande bevis och närhetsfönster.

Observera att för e-post behandlas meddelandetexten och varje bifogad fil som separata objekt. Det innebär att närhetsfönstret inte sträcker sig utanför var och en av dessa objekt. Både idMatch och samarbetsbevis måste finnas i varje objekt (bifogad fil eller brödtext).

Vad är rätt konfidensnivåer för olika mönster? [attributet confidenceLevel, attributet recommendedConfidence]

Ju mer bevis ett mönster kräver, desto större blir konfidensen att en faktisk entitet (till exempel ett medarbetar-ID) har identifierats när mönstret matchas. Du har till exempel mer konfidens i ett mönster som kräver ett niosiffrigt ID-nummer, anställningsdatum och nyckelord i närheten än i ett mönster som endast kräver ett niosiffrigt ID-nummer.

Pattern-elementet har ett obligatoriskt confidenceLevel-attribut. Du kan tänka på värdet för confidenceLevel (ett heltal mellan 1 och 100) som ett unikt ID för varje mönster i en entitet – mönster i en entitet måste ha olika konfidensnivåer, som du tilldelar. Det exakta värdet för heltalet spelar ingen roll. Välj bara ett värde som är logiskt för ditt efterlevnadsteam. När du har laddat upp din anpassade typ av känslig information och sedan skapar en princip kan du referera till dessa konfidensnivåer i villkoren i den regel som du skapar.

XML-kod som visar Mönsterelement med olika värden för confidenceLevel-attribut.

Utöver confidenceLevel för varje mönster har entiteten också ett recommendedConfidence-attribut. Det rekommenderade konfidensattributet kan ses som standardkonfidensnivå för regeln. Om du inte anger en konfidensnivå för en regel när du skapar regeln i en princip utförs matchningen av regeln baserat på den rekommenderade konfidensnivån för entiteten. Observera att attributet recommendedConfidence är obligatoriskt för varje entitets-ID i regelpaketet. Om det saknas kan du inte spara principer som använder typen av känslig information.

Vill du använda andra språk i användargränssnittet i efterlevnadscentret? [elementet LocalizedStrings]

Om ditt efterlevnadsteam använder Microsoft 365 Efterlevnadscenter för att skapa principer på olika språk kan du tillhandahålla lokaliserade versioner av namnet och beskrivningen av din anpassade typ av känslig information. När efterlevnadsteamet använder Microsoft 365 på ett språk som du stöder ser de det lokaliserade namnet i användargränssnittet.

Konfiguration av antal förekomster och matchning av korrekthet.

Elementet Rules måste innehålla ett localizedStrings-element som innehåller ett Resource-element som refererar till GUID för din anpassade entitet. I sin tur innehåller varje Resource-element ett eller flera namn- och beskrivningselement som vart och ett använder attributet langcode för att tillhandahålla en lokaliserad sträng för ett visst språk.

XML-kod som visar innehållet i localizedStrings-elementet.

Observera att de lokaliserade strängarna endast påverkar hur din anpassade typ av känslig information visas i användargränssnittet i efterlevnadscentret. Du kan inte använda lokaliserade strängar för att tillhandahålla olika lokaliserade versioner av en nyckelordslista eller ett reguljärt uttryck.

Annan regelpaketkod [RulePack GUID]

I början av varje RulePackage finns viss allmän information som du behöver fylla i. Du kan använda följande kod som mall och ersätta platshållarna ". . ." med egen information.

Det viktigaste är att du skapar ett GUID för RulePack. Ovan genererade du ett GUID för entiteten. Detta är ett andra GUID för RulePack. Det finns flera sätt att generera GUID. Ett enkelt sätt är att skriva [guid]::NewGuid() i PowerShell.

Versionselementet är också viktigt. När du laddar upp regelpaketet för första gången registrerar Microsoft 365 versionsnumret. Om du uppdaterar regelpaketet senare och laddar upp en ny version måste du uppdatera versionsnumret, annars distribuerar Microsoft 365 inte regelpaketet.

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

När allt är klart bör ditt RulePack-element se ut så här.

XML-kod som visar RulePack-elementet.

Validerare

Microsoft 365 kan använda funktionsprocessorer för vanliga SITs som validerare. Här är en lista över dem.

Lista över tillgängliga validerare

  • 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

På så sätt kan du definiera en egen RegEx och validera dem. Om du vill använda validerare definierar du din egen RegEx och Validator använder egenskapen för att lägga till valfri funktionsbehandlare. När den är definierad kan du använda denna RegEx i en SIT.

I exemplet nedan har ett vanligt uttryck - Regex_credit_card_AdditionalDelimiters definierats för kreditkort som sedan valideras med hjälp av funktionen checksumma för kreditkort genom att använda Func_credit_card som validerare.

<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 två allmänna validerare

Kontrollerasummator

I det här exemplet definieras en kontrollsumma som validerar RegEx för EmployeeID för anställnings-ID.

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

Datum giltiga

I det här exemplet definieras ett datum validator för en RegEx-del som är datum.

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

Ändringar för Exchange Online

Tidigare kanske du använde Exchange Online PowerShell för att importera anpassade typer av känslig information för DLP. Nu kan dina anpassade typer av känslig information användas i både Exchange administrationscenter och efterlevnadscentret. Som en del av den här förbättringen bör du använda Compliance Center PowerShell för att importera anpassade typer av känslig information – du kan inte importera dem från Exchange PowerShell längre. Dina anpassade typer av känslig information fortsätter att fungera som vanligt, men det kan ta upp till en timme innan ändringar av anpassade typer av känslig information som gjorts i efterlevnadscentret visas i administrationscentret för Exchange.

Observera att du kan ladda upp ett regelpaket med cmdleten New-DlpSensitiveInformationTypeRulePackage i efterlevnadscentret. (Tidigare kunde du använda cmdleten ClassificationRuleCollection i administrationscentret för Exchange.)

Ladda upp regelpaketet

Gör så här om du vill ladda upp regelpaketet:

  1. Spara det som en XML-fil med Unicode-kodning.

  2. Ansluta till Compliance Center PowerShell

  3. Använd följande syntax:

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

    I det här exemplet överförs Unicode XML-filen med namnet MyNewRulePack.xml från C:\My Documents.

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

    Se New-DlpSensitiveInformationTypeRulePackage för detaljerad information om syntax och parametrar.

    Anteckning

    Det maximala antalet regelpaket som stöds är tio, men varje paket kan innehålla en definition för flera typer av känslig information.

  4. Gör något av följande för att kontrollera att du har skapat en ny typ av känslig information:

    • Kör cmdleten Get-DlpSensitiveInformationTypeRulePackage och kontrollera att det nya regelpaketet visas:

      Get-DlpSensitiveInformationTypeRulePackage
      
    • Kör cmdleten Get-DlpSensitiveInformationType och kontrollera att typen av känslig information visas:

      Get-DlpSensitiveInformationType
      

      För anpassade typer av känslig information är egenskapsvärdet för utgivare något annat än Microsoft Corporation.

    • Ersätt <Name> med namnvärdet för typen av känslig information (till exempel: medarbetar-ID) och kör cmdleten Get-DlpSensitiveInformationType:

      Get-DlpSensitiveInformationType -Identity "<Name>"
      

Möjliga verifieringsproblem som du bör känna till

När du laddar upp din XML-fil för regelpaket verifierar systemet XML-koden och söker efter kända felaktiga mönster och tydliga prestandaproblem. Här är några kända problem som verifieringen söker efter – ett reguljärt uttryck:

  • Lookbehind assertions in the regular expression should be of fixed length only. Variabla längd bekräftelser kommer att resultera i fel.

    Valideras till "(?<=^|\s|_)" exempel inte. Det första mönstret (^) är längden noll, medan de nästa två mönstren (\s och _) har längden ett. Ett annat sätt att skriva det här reguljära uttrycket är "(?:^|(?<=\s|_))".

  • Kan inte börja eller sluta med en alternator |som matchar allt eftersom det anses vara en tom matchning.

    Till exempel eller |a valideras b| inte.

  • Kan inte börja eller sluta med ett .{0,m} mönster som inte har något funktionellt syfte och bara försämrar prestanda.

    Till exempel eller .{0,50}ASDF valideras ASDF.{0,50} inte.

  • Kan inte .{0,m} ha eller .{1,m} i grupper och kan inte ha .\* eller .+ i grupper.

    Valideras till (.{0,50000}) exempel inte.

  • Det går inte att ha ett tecken {0,m} med eller {1,m} upprepande tecken i grupper.

    Valideras till (a\*) exempel inte.

  • Kan inte börja eller sluta med .{1,m}; i stället ska du använda ..

    Valideras till .{1,m}asdf exempel inte. Använd istället .asdf.

  • Kan inte ha en obunden repeater (till exempel * eller +) i en grupp.

    Till exempel, (xx)\* och kommer (xx)+ inte att valideras.

  • Nyckelorden får vara högst 50 tecken långa. Om du ett nyckelord i en grupp som överskrider den här gränsen föreslår vi att du skapar en grupp med termer, till exempel en nyckelordsordlista och refererar till GUID för nyckelordsordlistan i XML-strukturen som en del i entiteten för Match eller idMatch i filen.

  • Varje anpassad typ av känslig information kan innehålla maximalt 2 048 nyckelord.

  • Den maximala storleken på nyckelordsordlistor i en enskild klientorganisation är 480 KB komprimerad för att uppfylla AD-schemabegränsningarna. Du kan referera till samma ordlista så många gånger som behövs när du skapar anpassade typer av känslig information. Börja med att skapa anpassade nyckelordslistor i typen av känslig information och använd nyckelordsordlistor om du har fler än 2 048 nyckelord i en nyckelordslista eller om ett nyckelord är längre än 50 tecken.

  • Högst 50 nyckelordsordlistebaserade typer av känslig information tillåts i en klientorganisation.

  • Kontrollera att varje Entity-element innehåller ett recommendedConfidence-attribut.

  • När du använder PowerShell-cmdleten finns en maximal returstorlek för deserialiserade data på ungefär 1 MB. Det här påverkar storleken på XML-filen för regelpaketet. Vi föreslår att du begränsar den uppladdade filen till högst 770 kB så att du får konsekventa resultat utan fel vid bearbetningen.

  • XML-strukturen kräver inte formateringstecken som blanksteg, tabbar eller vagnretur-/radmatningsposter. Tänk på det när du optimerar utrymme för uppladdningar. Verktyg som Microsoft Visual Code tillhandahåller kopplingslinjefunktioner för att komprimera XML-filen.

Om en anpassad typ av känslig information innehåller ett problem som kan påverka prestanda laddas den inte upp och något av följande felmeddelanden visas:

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

  • Lookaround assertions

  • Complex grouping in conjunction with general quantifiers

Du måste crawla innehållet igen för att identifiera känslig information

I Microsoft 365 används Search Crawler för att identifiera och klassificera känslig information i webbplatsinnehåll. Innehållet i SharePoint Online- och OneDrive för företag-webbplatserna crawlas igen automatiskt när det uppdateras. Men för att identifiera den nya anpassade typen av känslig information i allt befintligt innehåll måste innehållet crawlas på nytt.

I Microsoft 365 kan du manuellt begära en områlning av en hel organisation, men du kan manuellt begära en områlning för en webbplatssamling, en lista eller ett bibliotek. Mer information finns i Manuellt begära crawlning och omindexering av en webbplats, ett bibliotek eller en lista.

Referens: XML-schemadefinition för regelpaket

Du kan kopiera den här koden, spara den som en XSD-fil och använda den för att verifiera XML-filen för regelpaketet.

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

Mer information