Det krävs näst intill att man bosatt sig på månen utan internet access för att ha undgått de nya lagkraven inom EU som träder i kraft den 25 maj 2018.
Lagar runt GDPR – General Data Protection Regulation – som definierar reglerna för all form av behandling av information som direkt eller indirekt kan knytas till en person

Utmaningen som alla myndigheter, företag och organisationer står inför handlar till stor del av att identifiera all information som innefattas av dessa regler och sedan säkerhetsställa att denna information är skyddad. Personuppgifter som lagras och framför allt delas måste bland annat kunna redovisas.

Azure Information Protection fyller en viktig roll då den uppfyller följande:

• Kryptering av information
• Klassificering av information
• Spårbarhet av information över vem den har delats med, var och när
• Möjlighet att återkalla och begränsa tillgång till information oavsett var den lagrats/delats
• …identifiera om och när ovanstående skall appliceras

Då vi (våra användare) idag skapar, hanterar och lagrar information precis överallt är GDPR en tuff utmaning.  Med hjälp av condition/regel -baserad applicering direkt i Office kan vi dock komma en bra bit på väg. Genom att identifiera alla dokument som skapas/sparas innehållande exempelvis svenskt personnummer kan vi antingen föreslå användaren eller påtvinga – ett skydd av informationen.  Motsvarande kan även konfigureras i vårat mailflöde med hjälp av DLP-regler i Exchange som på så sätt identifierar e-post och dess bifogade Office filer och utför åtgärder som antingen blockerar mailet, eller säkerhetsställer att det är krypterat innan det går iväg till en mottagare.

Detta resulterar i att vi fångar upp den större delen av alla dokument som skapas/sparas med personuppgifter som innefattas av den nya GDPR lagen

Här följer ett exempel:
I det här fallet är en regel i Azure Information Protection satt att leta efter ett eller flera svenska personnummer och då upplysa användaren vilket skydd som bör appliceras.

Med den här regeln behöver användaren trycka på ”Change now”. Alternativet hade varit att påtvinga skyddet med automatik av regeln.

Resultatet blir i det här exemplet att själva dokumentet kommer krypteras, det kommer klassificeras som ”Secret” som dels redovisas för alla användare inom organisationen via Azure Information Protection listen, samt i själva dokumentet med en visuell märkning som appliceras med automatik. Detta upplyser den användaren som har rätt att konsumera dokumentet om dess känslighet oavsett delning utanför organisationen.

Dokumentets kryptering ger möjligheten att spåra all nyttjande av dokumentet oavsett var det sedan har delats eller lagrats. Vid behov kan även all tillgång återkallas och dokumentet blir oläsbart för alla utom den som faktiskt skapade dokumentet/applicerade skyddet.

I mitt exempel väljer jag även att blockera epost innehållande personnummer med ett meddelande till slutanvändaren som upplyser användaren om att skicka den här typen av information i ett skyddat dokument istället.
Detta beror på att dagens Tracking portal för Azure Information Protection (än så länge) inte stödjer att spåra eller återkalla epost meddelanden eller dokument som skyddats av Exchange.

Användaren kan dock välja att skicka epost-meddelandet med hjälp av “override” vilket då kommer applicera samma skydd med automatik. Ett larm genereras av Exchange som ger oss information om när detta skett vilket vi behöver för att enkelt kunna spåra informationen via Azure Information Protections centrala loggar och på så sätt följa vem som tar del av den.

Om användaren inte väljer ”override” utan skickar mailet ändå blockeras detta och användaren får i detta exempel reda på anledningen till blockeringen och en anvisning över vad som bör göras

Identifiera svenskt personnummer

Azure Information Protection har ett antal fördefinierade utryck att söka efter men här saknas idag svenskt personnummer och begränsas än så länge till amerikanska social security numbers m.fl.

Vi behöver därför manuellt skapa en regel som identifierar ett svenskt personnummer. Min kollega Tom Aafloen har här definierat ett så kallat regular expression med målsättning att identifiera formatet av ett svenskt personnummer med så hög träffsäkerhet som möjligt.
I det här fallet används ett format för att säkerhetsställa att det bland annat enbart är 12 månader på ett år och max 31 dagar på en månad med mera

Format
[Valbart millennium, 19 el 20][år][månad][dag][möjligt bindesträck][3 siffror][följt av 1 siffra för checksumman]

Regular Expression
^(((20)((0[0-9])|(1[0-1])))|(([1][^0-8])?\d{2}))((0[1-9])|1[0-2])((0[1-9])|(2[0-9])|(3[01]))[-+]?\d{4}[,.]?

Exchange Online har där emot ett fördefinierat ”condition” som kan definieras för svenskt personnummer (Sweden National ID).

Följande är den regel som identifierar, blockerar och underrättar användaren om vad som gäller när information skyddad under GDPR skall skickas via E-post