Microsoft har kommit långt i sin resa att skydda epost och Office dokument utan att ställa några motkrav på mottagaren. Lösningen gör det enklare för våra svenska företag och myndigheter att möta de nya GDPR lagarna.

Historiskt sett har det varit stora utmaningar att nyttja Rights Management Services (RMS) för att skydda epost-meddelanden och andra filer till externa användare utanför sin egen organisation.

I ett RMS-scenario krävs följande för att kunna läsa något som är skyddat av denna lösning:

1. Ett konto som kan autentisera sig mot avsändarens Azure Active Directory (eller Active Directory i ett AD RMS scenario)
2. En applikation som stödjer RMS i form av dekryptering och applicering av de begränsade rättigheterna som definieras vid kryptering (Ex begränsa utskrift, kopiering eller vidarebefordring av epost)

Secure Email är en lösning från Microsoft som automatiskt tillämpas om någon av de två övre kraven inte uppfylls. Lösningen gör det möjligt att skydda oavsett vem mottagaren är och tillåter även att innehållet visas via en webbläsare och ställer därmed inga krav på övriga applikationer. Secure Email bygger på klassiska RMS och det som tidigare kallades för Outlook Message Encryption (OME). Med OME får mottagaren tillgång till informationen genom en inloggning mot avsändarens Office 365 –webbgränssnitt. Det här scenariot resulterar i att ingen oskyddad information lämnar avsändarens organisation.

I följande exemplet går jag igenom de senaste nyheterna inom Secure Email och mottagarens upplevelse om de uppfyller kraven eller inte:

Skydda och skicka Epost-meddelande

– Användaren kan skydda ett epostmeddelande och välja om mottagaren skall ha fulla rättigheter (Encrypt) eller om mottagaren skall vara begränsad att vidarebefordra, kopiera, skriva ut eller på annat sätt sprida innehållet (Do Not Forward).
(I nuläget finns bara alternativet ”Encrypt” via webbgränssnittet till Exchange (OWA). Funktionen kommer via AIP klienten framöver även till lokalt installerade Outlook som idag bara har ”Do not Forward”-alternativet)
Är ett Office dokument bifogat kommer även detta krypteras med motsvarande rättigheter

Alternativ 1: Mottagare som uppfyller kraven

– Mottagare som har exempelvis Office 365 och därmed både konto i Azure AD och Applikationer som förstår RMS.

Alla supporterade Office-versioner har idag inbyggt stöd för RMS.
Där emot är alternativet Encrypt en helt ny standard där stödet nyligen släpptes till Office Version 1804 (Build 9226.xxxx).

Äldre Office versioner kommer inte få stöd utan supporterar enbart Do Not Forward som funnits i snart 15 år.
Om en äldre Office/Outlook version används kommer ett epostmeddelande skyddat med Encrypt att visas på samma sätt som exemplet nedan då applikationen inte kan tolka den här RMS-rättigheten.

Alternativ 2: Mottagare som inte uppfyller kraven

Mottagare som varken har konto hos Microsoft eller applikationer som förstår RMS, i detta fall ett gmail-konto.

För att logga in mot Office 365 har en gmail-användare möjlighet att autentisera sig direkt med sitt Googlekonto då Microsoft federerar med Google och flera andra leverantörer.

Saknas den här möjligheten finns det alltid ett alternativ att istället logga in med en engångskod (OTP)

En OTP kod skickas då till samma mottagare

Efter lyckad autentisering kommer Office IRM dekryptera och visa både mailet och den bifogade Officefilen via webbläsaren

I båda alternativen är det fortfarande RMS som nyttjas för kryptering/dekryptering och i alternativ 2 tillsammans med det som kallas för Office IRM. I alternativ 1 när det är en lokalt installerad programvara som dekrypterar innehållet används det som kallas för Client-Side-decryption där RMS dekrypteringen sker lokalt. Office IRM i Alternativ 2 gör att tjänster så som Exchange, SharePoint och Office Online krypterar/dekrypterar innehållet åt användaren, så kallad Server-Side-Encryption/decryption.

Varje RMS-krypterad fil har även en okrypterad text som redovisas om applikationen inte förstår RMS. I Secure Email är detta texten som länkar till Office 365 där vi även ser att det krypterade mailet ligger bifogad. Den här texten kan även anpassas vilket jag tidigare beskrivit här https://itsakerhetsguiden.se/2017/11/17/anpassa-secure-email-fr-din-organisation/