Et av de vanligste diskusjonsområdene med Purview handler om bruken av følsomhetsetiketter. Hvilke etiketter skal vi ha? Hvordan skal de konfigureres? Skal etikettene påføre kryptering? I tillegg, hvordan kan vi bruke etiketter som betingelser for de andre løsningene i Purview, som forhindring av datatap (DLP) og administrasjon av datasikkerhetsstatus for kunstig intelligens (DSPM for AI)?
En vanlig tilnærming har vært å definere et sett etiketter, gi brukerne litt opplæring, og så satse på at de pliktoppfyllende merker sine e-poster og dokumenter med korrekte etiketter. Men sannsynligheten er stor for at de fleste vil overse etikettene, og at virksomheten ikke over tid får et økt sikkerhetsnivå. Så hva kan vi gjøre med det?
La oss utforske Microsoft Secure by default with Microsoft Purview – en blueprint for hvordan en virksomhet raskt og effektivt kan beskytte sine data med løsningene i Purview. Blueprinten bygger på prinsippet om Secure by default, som innebærer at sikkerhetsinnstillinger og beskyttelsestiltak skal være aktivert som standard, i stedet for å være valgfrie funksjoner som må slås på i etterkant. Målet er å sikre at all data blir klassifisert og beskyttet automatisk, uten å måtte stole på manuell innsats fra de ansatte.
Fase 1 – Foundational
I den første fasen oppretter vi følsomhetsetiketter som brukerne kan ta i bruk for å merke e-poster og dokumenter. Vi definerer en standard etikett for nye e-poster og dokumenter, og vi lærer brukerne hvordan de skal endre etiketter. For å forhindre datalekkasje oppretter vi også policy for hindring av datatap (DLP).
Følsomhetsetiketter
Vi starter med å opprette følsomhetsetiketter:
| Etikettnavn | Beskrivelse | Konfigurasjon |
| Offentlig | Data som kan deles med alle. | Omfang: e-poster og filer Innholdsmerking: nei Automatisk merking: nei DLP: nei |
| Generell | Data som ikke er ment å dele med alle, men som kan deles med eksterne ved behov. | Omfang: e-poster, filer og områder Innholdsmerking: nei Tilgangskontroll: nei Automatisk merking: nei DLP: blokker tilgang for alle som kun har lenken |
| Konfidensiell \ Alle ansatte | Konfidensiell data som krever beskyttelse, og som gir alle ansatte tilgang til innholdet. | Omfang: e-poster, filer og områder Innholdsmerking: ja Tilgangskontroll: alle ansatte er medforfattere Automatisk merking: nei DLP: blokker tilgang for alle som kun har lenken, blokker eksterne |
| Konfidensiell \ Spesifikke personer | Konfidensiell data som kan deles med betrodde interne og eksterne personer. Mottakerne kan dele dataene videre. | Omfang: e-poster, filer og områder Tilgangskontroll: bruker definerer selv tilganger Automatisk merking: nei Innholdsmerking: «Klassifisert som konfidensielt» DLP: blokker tilgang for alle som kun har lenken, blokker eksterne |
| Konfidensiell \ Internt unntak | Konfidensiell data som ikke trenger å krypteres. Bruk dette alternativet med forsiktighet og kun med forretningsmessig begrunnelse. | Omfang: e-poster, filer og områder Tilgangskontroll: nei Automatisk merking: nei Innholdsmerking: «Klassifisert som konfidensielt» DLP: blokker tilgang for alle som kun har lenken, blokker eksterne |
| Strengt konfidensiell \ Alle ansatte | Strengt konfidensiell data som krever beskyttelse, men som gir alle ansatte tilgang til innholdet. Mottakerne kan ikke dele dataene videre. | Omfang: e-poster, filer og områder Tilgangskontroll: alle ansatte er medforfattere Automatisk merking: ja Innholdsmerking: «Klassifisert som strengt konfidensielt» DLP: blokker tilgang for alle som kun har lenken, blokker eksterne |
| Strengt konfidensiell \ Spesifikke personer | Strengt konfidensiell data som kan deles med betrodde interne og eksterne personer. | Omfang: e-poster, filer og områder Tilgangskontroll: bruker definerer selv tilganger Automatisk merking: nei Innholdsmerking: «Klassifisert som strengt konfidensielt» DLP: blokker tilgang for alle som kun har lenken, blokker eksterne |
| Strengt konfidensiell \ Internt unntak | Strengt konfidensiell data som ikke trenger å krypteres. Bruk dette alternativet med forsiktighet og kun med forretningsmessig begrunnelse. | Omfang: e-poster, filer og områder Tilgangskontroll: nei Automatisk merking: nei Innholdsmerking: «Klassifisert som strengt konfidensielt» DLP: blokker tilgang for alle som kun har lenken, blokker eksterne |
Her ser vi hvordan brukerne kan velge etikettene i sine M365 applikasjoner:
For å sikre Secure by default konfigurasjon, så setter vi som standard etiketten Konfidensiell \ Alle ansatte for nye filer og dokumenter, og etiketten Generell for nye e-poster.
Delbare lenker i SharePoint og OneDrive
Delbare lenker i SharePoint og OneDrive bør begrenses til «Personer i din organisasjon», noe som redusere risikoen for utilsiktet datalekkasje. Det gjøres i SharePoint Admin Center.
Brukeropplæring
Vi har satt standard etikett til for nye e-poster og dokumenter til Konfidensiell \ Alle ansatte. Brukeropplæringen bør derfor fokusere på hvordan brukerne skal håndtere unntak fra denne etiketten, for eksempel dersom en bruker har behov for å samarbeide med eksterne. Brukerne må da velge en passende etikett, som for eksempel Konfidensiell \ Internt unntak, og må samtidig begrunne endringen. Poenget er å sikre at unntak kun gjøres når det er nødvendig og forsvarlig.
Hindring av datatap (DLP)
Til slutt oppretter vi policyer for hindring av datatap (DLP), så vi blokkerer for deling av konfidensielle eller strengt konfidensielle data med eksterne.
Fase 2 – Managed
Mens vi i første fase fokuserte på å sikre nye og oppdaterte data (ved at e-poster og dokumenter automatisk ble merket med etiketter), så skal vi i andre fase fokusere på å beskytte den eksisterende dataen. Fokus er på den mest sensitive dataen som er lagret i prioriterte områder.
Følsomhetsetiketter på SharePointområder
Identifiser alle SharePointområdene i SharePoint Admin Center. Sett passende etiketter på de enkelte områdene, spesielt alle områder som inneholder sensitiv eller konfidensiell data. Med andre ord, dersom et SharePointområde inneholder veldig sensitive dokumenter, så bør etiketten Strengt konfidensiell \ Alle ansatte settes på dette området. Husk at for å kunne sette etiketter på SharePointområder, så må vi først publisere etikettene til Entra ID, deretter utvide omfanget på selve etikettene til Grupper og områder.
Automatisk merking av data i M365
Opprett policy for automatisk merking av prioriterte områder (server-side autolabelling og client-side autolabelling), for eksempel basert på definerte sensitive informasjonstyper.
Hindring av datatap for data som ikke er merket med etiketter
Etterhvert som nye og eksterende e-poster og dokumenter blir merket med etiketter, så vil omfanget av ikke-merkede e-poster og dokumenter blir tilsvarende mindre. Da gir det mening å blokkere for deling av data som ikke er merket. Det gjør vi selvfølgelig med policy for håndtering av datatap (DLP). Pass på at denne policyen omfatter aktiviteter på endepunktene, som at brukerne laster dokumenter opp til nettbaserte lagringsområder (som Dropbox). Brukerne må da åpne filene og påføre en etikett før opplasting er mulig.
Adaptiv beskyttelse
Administrasjon av innsiderisiko (IRM) forsyner administratorer med analyse og kontroll basert på brukeratferd, og kan i Secure by default-sammenheng brukes til å oppdage når brukere forsøker å nedgradere etiketter, laste ned, skjule eller eksfiltrere sensitivt innhold. Vi aktiverer adaptiv beskyttelse i IRM.
Her kan vi definere hvilke handlinger som skal utløse varsler, og hvor terskelen går. Med adaptiv beskyttelse kan DLP-policyene styrkes dynamisk basert på brukerens risikonivå – for eksempel kan en policy som standard tillate deling av Generell-merkede dokumenter for en bruker, men blokkere samme handling for en annen bruker som er forbundet med høy risiko.
Fase 3 – Optimized
I den andre fasen fokuserte vi på å beskytte den mest sensitive informasjonen. I den tredje fasen utvider vi beskyttelsen til å omfatte all informasjon i M365-miljøet og på brukernes endepunkter.
Automatisk merking av data på brukernes endepunkter
For å sikre at også data lagret på brukernes endepunkter blir merket, så må vi opprette policy for automatisk merking (client-side autolabelling). Vi kan for eksempel basere merkingen på sensitive informasjonstyper.
Automatisk merking av all lagret data
I denne fasen ønsker vi å utvide den automatiske merkingen (server-side autolabelling) til hele SharePoint- og OneDrivemiljøet. I motsetning til fase to, hvor vi merket data på utvalgte områder, så brukes det nå bredt og basert på flere betingelser – som dokumentnavn, egenskaper, størrelse og delingsstatus. Simulering gir mulighet til å justere regelsett før faktisk utrulling, noe som reduserer risikoen for feilmerking og forbedrer presisjonen.
Avanserte klassifikatorer
Purview støtter flere metoder for å klassifisere data, for eksempel opplærbare klassifiserere og behovsbetinget klassifisering, som bruker maskinlæring for å gjenkjenne dokumentmønstre (som økonomiske eller juridiske dokumenter). I tillegg kan vi ta i bruk EDM-klassifiserere, som bruker verdier fra virksomhetens data til å gjenkjenne treff i stedet for generiske mønstre. Vi ønsker å ta i bruk disse for å redusere falske positiver.
Fase 4 – Strategic
I den siste fasen utvider vi databeskyttelsen til å favne om data utenfor M365-miljøet, og etablerer et forvaltningsregime som kontinuerlig følger opp bruken av etiketter og policyer.
Gjennomgang av etikettbruk og risikoatferd
Nå som vi har etablert tiltak for manuell og automatisk merking av data, og vi bruker dette som betingelser for de øvrige løsningene i Purview, så må vi med jevne mellomrom gjennomgå hvordan den faktiske bruken er. Intensjonen er å identifisere avvik og risikoatferd som undergraver prinsippet om Secure by default. Purview har et sett med rapporter og analyseverktøy som bidrar til å få oversikt.
Sikker samhandling med eksterne
Dersom virksomheten samarbeider tett med en ekstern virksomhet/partner, eller opererer med flere tenanter, så bør etiketter som påfører kryptering konfigureres til å gi tilgang fra flere domener – for eksempel @skranten.no + @eksternpartner.no. Slike etiketter brukes typisk for Konfidensiell eller Svært konfidensiell data, og muliggjør datadeling og samhandling uten å svekke beskyttelsen.
Merking av lokale filområder og SharePointområder
Selv om følsomhetsetiketter kan brukes på lokale filservere og SharePoint Server, anbefales det i Secure by default blueprinten å sette riktige standardinnstillinger i SharePoint Online, migrere all data dit, og la automatisk merking skje ved opplasting. Dette gir en mer effektiv og konsistent beskyttelse. Men, all den tid virksomheten ønsker å ha lokale servere, så bør også merkingen omfatte data på disse serverne.
Data i Azure SQL og utenfor Microsoft 365
Visste du at følsomhetsetiketter også kan brukes til å beskytte data utenfor Microsoft 365, inkludert kilder som Azure SQL Database, Azure Blob Storage, Azure Data Lake Storage Gen2 og Amazon S3? Administratorer kan i Purview sette opp etiketter, automatisk merking og beskyttelsestiltak på tvers av hele infrastrukturen.
Policyer kan for eksempel hindre utilsiktet tilgang ved å bruke prinsippet deny all except, for eksempel i lagringskontoer som inneholder mer sensitivt innhold enn forventet. For Azure SQL kan tilgangen til kolonner begrenses dersom innholdet merkes som sensitivt, og det er støtte for finmasket kontroll over hvem som skal ha tilgang til hvilke data.
Forvaltningsregime
Til slutt må vi sikre at alle de tiltakene vi har gjennomført blir forvaltet. Vi må med andre ord etablere et forvaltningsregime. Det sikrer kontroll over tid, og reduserer følgelig risiko for at ting sklir ut.
- Alle SharePointområder bør ha minst to eiere.
- Inaktive områder bør fjernes med bruk av policyer.
- Eiere må jevnlig gjennomgå sine områder og sikre at de fortsatt er i bruk, og er korrekt konfigurert.
- Bruk SharePoint Advanced Management for å gjennomføre tilgangsrevisjoner, særlig for områder med mye deling eller bred tilgang.
Avsluttende betraktninger
Microsoft hevder selv at de følsomhetsetikettene som er definert i blueprinten, er nært det de selv bruker. Etikettene er ment å fange opp veldig mange brukercaser, men kan oppleves som overveldende for virksomheter som ikke har jobbet med dette før. For mange etiketter kan forvirre brukerne, og erfaringsmessig er det utfordringer å la brukerne selv definere tilganger til sine dokumenter (i dette tilfellet gjelder det etikettene merket Spesifikke personer).
I tillegg må vi huske at offentlige virksomheter må følge arkivloven, og det er en skikkelig dårlig ide å arkivere e-poster og dokumenter som er kryptert med etiketter. Mange offentlige virksomheter velger derfor å ikke påføre kryptering med etikettene, og heller bruke policyer for hindring av datatap (DLP) som kompenserende tiltak.
Så har vi lisensene. Noen av tiltakene er riktignok mulig å gjennomføre med Enterprise E3 lisenser (som at brukerne manuelt påfører etiketter på e-postene og dokumentene). Men, for å gjennomføre alle tiltakene må brukerne ha Enterprise E5 lisenser (alternativt E5 Compliance lisenser).
Security by default blueprinten uansett nyttig for å forstå hvordan en virksomhet kan eller bør ta i bruk følsomhetsetiketter. Virksomheter som ønsker å beskytte sine data med etiketter, kan derfor dra veksel på fasene og tiltakene som vi har gjennomgått. Lokale tilpasninger må til uansett, og det er helt greit. Det er viktigere å komme i gang enn å vente. Prinsippet om Secure by default handler nettopp om å etablere et sikkert utgangspunkt, og så forbedre underveis.
