I denne artikkelen går vi gjennom av konseptene i Azure Information Protection, hva de heter og hva det betyr og inneholder.

Det kan virke som at de fleste gjennomganger man får av Azure Information Protection viser et enkelt oppsett som gir noen etiketter i Office og så er de ferdige. Dette gir en rask innføring og de fleste forstår at AIP kan hjelpe oss med å klassifisere og beskytte innhold, men ofte forklares det lite om hva som egentlig ligger bak.

Det kan virke forvirrende i begynnelsen, men med denne artikkelen vil vi forsøke å forklare litt mer.

I denne artikkelen dekker vi blant annet Policies, Scoped Policies, Labels og Protection, som alle er bestanddeler i AIP. I tillegg går vi også litt inn på templates.

Policies – regler

Regler, eller policies, menes det overordnede regelsettet som inneholder alt annet. Klassifiseringsetiketter, brukerinnstillinger, beskyttelse med mer.

Reglene inneholder som nevnt et sett med klassifiseringsetiketter. Hver av disse etikettene har sine egenskaper, som f.eks vannmerke, topptekst, bunntekst), og de kan om ønsket kobles til beskyttelse.

Når vi har aktivert AIP i portalen, som for tiden er aktivert som standard), blir én enkelt regel aktivert. Dette er den globale regelsettet som er aktivt for alle brukere. Dette inneholder klassfiseringsetikettene som ligger inne som standard, med predefinerte innstillinger og noen beskyttelsesmaler.

Både de predefinerte klassifiseringsetikettene og innstillingene endrer seg noe over tid, og avhengig av tidspunktet for når du aktiverte AIP, kan det være forskjellige innstillinger.

Fra februar 2018 vil AIP være aktivert automatisk for alle som etablerer en tenant. Om du har opprettet en tenant før denne datoen, må AIP aktiveres manuelt.

Det globale regelsettet for disse vil konfigurere AIP-basert kryptering for følgende underetiketter:

• Confidential / All Employees
• Confidential / Recipients Only
• Highly Confidential / All Employees
• Highly Confidential / Recipients Only

Standardetikettene er nå:

Scoped Policies

Enkelte er fornøyd med å bruke Azure Information Protection med “out of the box”-funksjonalitet, og er fornøyd med å klassifisere data, koble til en eller flere av de predefinerte malene med beskyttelse og bruker dette uten større endringer.

Andre igjen vil kanskje ha forskjellige beskyttelser og klassifiseringsetiketter for spesifikke brukere/grupper. Her kommer Scoped Policies inn i bildet.

I motsetning til den globale regelen er dette regler som retter seg mot de spesifiserte gruppene/brukerne. Dette betyr ikke at de brukerne slutter å få den globale regelen – denne kommer i tillegg.

Når en bruker er konfigurert for mer en én regel, så er det den siste regelinnstillingen som aktiveres.

I hvilke scenarioer kan vi trenge Scoped policies? For eksempel kan det være smart for avdelinger som jobber med ekstra sensitiv informasjon. Ofte bruker vi HR som eksempel. Vi vil gjerne at de skal ha en standardbeskyttelse på alt innhold de lager, og eposter de sender. De jobber gjerne med informasjon som ikke resten av organisasjonen bør se.

Etiketter / klassifiseringsetiketter

Dette er altså det som på godt norsk heter Labels. Etiketter er det vi benytter oss av for å merke/klassifisere innhold, og da gjerne ut ifra sensitivitetsnivået.

Vi kan gi innholdet et sett av egenskaper som visuelle merker, vannmerker, beskyttelse, rettigheter m.m., slik når man velger en etikett så påføres innholdet de egenskapene man har konfigurert.

Man har etiketter på overordnet nivå, og det finnes underetiketter. Det kan for eksempel være en overordnet etikett som heter “konfidensielt”, og en underetikett som heter “konfidensielt markedsføring”.

Det er greit å huske på at når man har underetiketter vil ikke brukerne lenger kunne velge den overordnede. Den blir omgjort til en nedtrekksmeny. Derfor lager vi gjerne en ny underetikett med samme egenskaper som den opprinnelige hadde.

Beskyttelse

Her kommer krypteringen inn, altså Protection. Dette er det vi kalte Rights Management Service (RMS) før i tiden, men dette begrepet har nesten forsvunnet helt.

Beskyttelse er ikke lenger så knyttet til maler (RMS-maler), men vi velger beskyttelsen når vi oppretter eller redigerer en etikett/klassifiseringsetikett.

Vi kan velge mellom de følgende tre:

1. Sett rettigheter.
   Her kan vi manuelt spesifisere rettigheter, hvor lenge innholdet skal være tilgjengelig og mer til Azure AD-objekter. Det er ingen mulighet til å gi noe basert på lokale AD-brukere.
2. Sett brukerdefinerte rettigheter. 
   Her kan vi velge enten fra å enten bruke “Do not forward”-regelen, som er ekstremt rigid og gjør innholdet om til Read Only (ingen endring, ikke videresende, ikke skrive ut, ikke ta screenshot etc), eller vi kan gi brukerne mulighet til å manuelt spesifisere rettigheter i Office-filer og filutforsker.
3. Velg en predefinert mal
   Her kan vi velge fra malene som allerede ligger inne og endre innstillingene om ønsket.

Maler – templates

Maler er et sett med beskyttelsesregler som spesifiserer hvilke restriksjoner som skal brukes. Det være seg hvilke brukere, hvilke rettigheter, hvor lenge de skal ha tilgang etc.

Malene blir da et ferdig utgangspunkt som du kan bruke som de er, og deretter kan man koble en klassifiseringsetikett mot disse. En mal kan beskytte innholdet slik at det blir skrivebeskyttet, mens en annen kan sørge for at det krypteres, slik at kun mottaker kan lese innholdet.

Om vi ønsker at en av klassifiseringsetikettene våre skal beskytte innholdet kan vi velge å bruke de predefinerte malene som opprettes automatisk (confidential – read only), til å spesifisere hvilken beskyttelse og hvilke rettigheter innholdet skal ha.

Om vi skal ha ulike etiketter som skal beskytte innholdet på forskjellig vis, kommer vi ikke langt med å bruke disse. I det vi kobler på en predefinert mal, får vi nemlig opp følgende melding:

“Template successfully converted to a label. You can now edit the settings.”

Logisk, ikke sant? Det vil rett og slett si at den beskyttelsesmalen vi bruker ikke lenger er tilgjengelig for andre etiketter så lenge vi bruker den her. Om vi tar den bort fra etiketten så er den tilgjengelig for andre etiketter igjen. Om du ønsker å opprette flere maler, så gjøres dette i Powershell og ikke i portalen.

Dette har tilsynelatende ført til litt forvirring. Jeg har blitt spurt om hvorfor malene plutselig mangler fra portalen etter at folk har lekt seg litt med innstillingene. Dersom du ikke ser standardmalene i Azure Information Protection – Global Policy-fanen, er det fordi de er endret til en etikett eller koblet til en klassifiseringsetikett.

De eksisterer fremdeles som maler, men i portalen ser du dem kun som en del av en etikett som har beskyttelse. Du har lite trolig slettet hele malen, siden dette kun er mulig via Powershell, og ikke i portalen.

Dersom du av en eller annen grunn skulle ønske å slette en mal – sørg for at den ikke er i bruk og kjør “Remove- AadrmTemplate”.

Det er altså greit å vite at i det du konverterer eller kobler en mal til en etikett, så kan den ikke lenger brukes av andre etiketter. I tillegg så er den altså ikke synlig i Protection templates-seksjonen.

Så hvordan lager du nye maler? Vel, en ny mal opprettes i det du lager en etikett med beskyttelse Azure Cloud Key:

Disse blir ikke synlige i listen over predefinerte Protection templates slik de de predifinerte er:

Disse kan dermed ikke brukes på flere etiketter. Om du senere fjerner beskyttelsen er disse innstillingene borte. For flere eksempler, se .

Jeg håper dette ga et litt bedre overblikk over bestanddelene i Azure Information Protection, og hvordan disse henger sammen.