Kombinert virkning av flere datapolicyer
Som leier- eller miljøadministrator kan du opprette flere enn en datapolicy og bruke den på samme miljø. Ved utforming og kjøretid evalueres alle policyer som gjelder for miljøet der appen eller flyten finnes, sammen for å avgjøre om ressursen er i samsvar med eller bryter med datapolicyene.
Blokkert klassifiseringsinnvirkning på tvers av flere policyer
Hvis en policy (leier- eller miljønivå) som gjelder for et miljø, merker en kobling som blokkert, kan ingen apper eller flyter bruke denne koblingen i miljøet. Det spiller ingen rolle om andre policyer klassifiserer denne koblingen som Bedrift eller Ikke-bedrift, fordi Blokkert er den mest begrensende klassifiseringen for koblingen, og derfor er Blokkert alltid det endelige resultatet av flere policyevalueringer.
Innvirkning av klassifiseringen Bedrift / Ikke-bedrift på tvers av flere policyer
Sammenlignet med å evaluere virkningen av Blokkert klassifisering, er det mer komplekst å evaluere virkningen av Bedrift eller Ikke-bedrift på tvers av flere policyer. Du kan klassifisere en gitt kobling, for eksempel SharePoint, som Forretning i policy A og som Ikke-forretning i policy B. Det som er viktig, er hvilke andre SharePoint-koblinger som er gruppert med på tvers av policy A og policy B.
Vær oppmerksom på at den mest restriktive gruppen blir endelig forhåndsdefinert når alle policyer som gjelder for et miljø, evalueres sammen. Vurder et eksempel på tre policyer (A, B og C) på tvers av ti koblinger (SharePoint, Twitter, Salesforce, Facebook, Face API, Microsoft 365 Outlook, Basecamp 3, Adobe Sign, Azure Blob Storage og Box). Disse koblingene klassifiseres som Forretning eller Ikke-Forretning, slik de er representert av to kategorier hver på tvers av de tre policyene (-E1- og -E2- for policy A, -E3- og -E4- for policy B, og -E5- og -E6- for policy C).
Retningslinjer A
Kategori | Klassifisering | Koblinger |
---|---|---|
-E1- | Forretning | SharePoint, Twitter, Salesforce, Microsoft 365 Outlook, Basecamp 3 |
-E2- | Ikke-forretningsmessig | Facebook, Face API, Adobe Sign, Azure Blob Storage, Box |
Retningslinjer B
Kategori | Klassifisering | Koblinger |
---|---|---|
-E3- | Forretning | SharePoint, Facebook, Face API, Microsoft 365 Outlook, Basecamp 3 |
-E4- | Ikke-forretningsmessig | Twitter, Salesforce, Adobe Sign, Azure Blob Storage, Box |
Retningslinjer C
Kategori | Klassifisering | Koblinger |
---|---|---|
-E5- | Forretning | Facebook, Face API, Twitter, Salesforce, Microsoft 365 Outlook |
-E6- | Ikke-forretningsmessig | SharePoint, Adobe Sign, Azure Blob Storage, Box, Basecamp 3 |
Når alle tre policyer brukes sammen med det samme miljøet, er resultatet fragmentering av koblinger i åtte (23 = 8) grupper, slik det vises nedenfor. Bare koblinger i samme gruppe (av åtte mulige kombinasjoner) kan brukes i en gitt app eller flyt.
Konsolidert gruppering
Kategorier | Gruppe | Koblinger |
---|---|---|
-E1-, -E3-, -E5- | Gruppe 1 | Microsoft 365 Outlook |
-E1-, -E3-, -E6- | Gruppe 2 | SharePoint, Basecamp 3 |
-E1-, -E4-, -E5- | Gruppe 3 | Twitter, Salesforce |
-E1-, -E4-, -E6- | Gruppe 4 | NULL |
-E2-, -E3-, -E5- | Gruppe 5 | Facebook, Face API |
-E2-, -E3-, -E6- | Gruppe 6 | NULL |
-E2-, -E4-, -E5- | Gruppe 7 | NULL |
-E2-, -E4-, -E6- | Gruppe 8 | Adobe Sign, Azure Blob Storage, Box |
Kort sagt kan en app eller flyt bare bruke koblinger fra disse enkeltgruppene på et gitt tidspunkt, og den kan ikke blande kontakter mellom de åtte ulike gruppene. Vær oppmerksom på at flere datapolicyer som brukes i et miljø, kan fragmentere koblingsområdet på en komplisert måte i eksemplene ovenfor. Vi anbefaler derfor på det sterkeste at du bruker et minimum antall datapolicyer for et gitt miljø.