Dataräddning | Blogg | Ibas Ontrack | E-post och GDPR

Nu när GDPR är aktivt, kämpar fortfarande vissa företag med att anpassa sin IT efter de nya reglerna. Eftersom GDPR täcker så många områden inom datasäkerhet och orsaker bakom dataläckage, påverkas nästan alla IT-processer av den nya europeiska lagen. De flesta förändringarna är ganska självklara, dock inte alla.

En av åtgärderna som måste vidtas är att kryptera e-postmeddelanden som innehåller personlig information om klienter, kunder, anställda och övriga. Paragraf 25 i GDPR kräver ett dataskydd som är ”inbyggt och som är standard” i verksamhetens alla (IT-) processer för varor och tjänster. Lagen är tänkt att skydda personuppgifter och förhindra dataläckage. Därför hävdar många advokater att den nya lagen i praktiken kräver att alla e-postmeddelanden krypteras som standard. Trots att man ännu inte riktigt vet om det verkligen är så, kan det vara klokt att – om du inte redan gör det – tänka över konsekvenserna.

Kom ihåg: ett e-postmeddelande är som ett vykort. När du skickar ett mail kan vissa andra människor se innehållet om de vill. Det kan till exempel röra sig om företagets dataadministratör eller internetleverantören. Därför anses det enligt GDPR olagligt att skicka e-post med personlig eller känslig information utan att först kryptera den.

E-postkryptering är inte så vanligt som det borde vara. Detta beror på att det inte är helt enkelt. För närvarande finns det två sätt att välja mellan:

1. Krypterad överföring

Krypterad överföring innebär att mailen krypteras när den skickas (överförs) från en server till en annan. Med den här metoden skickas mailen genom en krypterad tunnel. Mailen krypteras när de lämnar en server och dekrypteras när de når den andra servern. Mailen är inte krypterad när den lagras på servern. När man sänder krypterade mail via Internet kan man till exempel använda POP3S kommunikationsprotokoll med Transport Layer Security (TLS) nätverksprotokoll. Det är det nya namnet för Secure Sockets Layer (SSL) som redan använts under ett antal år.

TLS tillsammans med POP3S skapar därmed en krypteringstunnel – även kallat site-to-site-kryptering eller end-to-end-kryptering, som passar när man ansluter två servrar direkt mot varandra. De flesta företag har dock inte så nära samarbete att de kopplar ihop sina e-post-servrar. Oftast ligger det någon annan server på vägen som mailen måste passera. Därför behövs det andra lösningar… som…

2. Kryptera innehållet

När man krypterar innehållet krypteras själva e-postmeddelandet istället för nätverkstunneln som det skickas genom. Idag är den vanligaste standarden för kryptering av innehållet antingen S/MIME (Secure/Multipurpose Internet Mail Extensions) eller PGP.

S/MIME kan exempelvis implementeras i din MS Exchange Server. S/MIME baseras på asymmetrisk kryptering och fungerar med hjälp av ett par matematiska nycklar. Dessa är de offentliga och privata nycklarna. Ett e-postmeddelande krypteras med mottagarens (inte avsändarens) offentliga nyckel och dekrypteras med en privat nyckel.

Även om S/MIME-tekniken inte är lätt att förklara, ska jag försöka göra det så enkelt som möjligt: När någon implementerar S/MIME i en MS Exchange Server skapas ett certifikat som innehåller användarens signatur och offentliga nyckel. Avsändaren intygar sin identitet genom att skicka sin signatur till en annan användare (användare "B"). Mottagaren får avsändarens offentliga nyckel och kan därmed i sin tur skicka krypterade e-postmeddelanden tillbaka. När användare B nästa gång vill skicka ett krypterat mail till användare A, märker användare A:s e-postklient att mailet kommer från en säker och känd avsändare. E-postklienten söker efter den privata nyckeln i avsändarens e-postklient och dekrypterar snabbt e-postmeddelandet.

Samma procedur gäller för PGP. Det baseras också på ett utbyte av offentliga och privata nycklar för kryptering och dekryptering av e-post. Du genererar ett nyckelpar – en nyckel som krypterar mailet (den offentliga nyckeln) och den andra som dekrypterar mailet (den privata nyckeln). Du delar din offentliga nyckel med alla som du vill ska kunna skicka krypterade mail till dig. När du väl fått ett krypterat mail från en känd källa, kommer din e-postklient att dekryptera mailet. Det är så det fungerar. Det kan dock vara ganska tidskrävande och svårt att implementera PGP. Ett exempel på hur detta kan göras hittar du här.

Nu för tiden när företag använder sig av krypterad e-post använder de S/MIME i sin MS Exchange eller någon annan e-posttjänst. Privatpersoner använder kryptering med hjälp av PGP, som exempelvis GnuPG eller någon annan typ av öppen källkod.

Faran med krypterad e-post

Som vi nämnde innebär användning av krypterad överföring som exempelvis TLS att såväl meddelanden som bilagor sparas okrypterade på både sändarens och mottagarens (och e-postklientens) servrar. Skulle det bli fel på e-postservern, till exempel krångel med hårddisken eller systemfel orsakat av en användare, kan dataräddare, som de från Ontrack Data Recovery, utan större svårighet återställa både filsystem och e-post.

Med innehållskryptering kan det däremot – oavsett om det är S/MIME, PGP eller en gatewaylösning – ibland vara svårt att återställa den krypterade e-posten.

Både de offentliga och privata nycklarna måste finnas tillgängliga för att e-posten ska kunna återställas. Om dessa nycklar (för de privata nycklarna handlar det egentligen om ett certifikat) inte finns tillgängliga, då finns det inte en chans att återställa innehållet i mailen.

Eftersom den minsta symmetriska nyckellängden (eller nyckelstorleken) för PGP är 128 Bit, skulle det ta 1,44 miljarder år att knäcka den. För 256-Bitarsnycklar är det ännu svårare. De flesta kryptoexperter hävdar att inte ens staters säkerhetstjänster med sina superdatorer klarar av att dekryptera sådana nycklar.

Därför bör du alltid spara och lagra dina krypteringsnycklar, certifikat och dekrypteringslösenord skiljt från e-postservern eller datorn. Vid en eventuell dataförlust kan dataräddarna använda dessa efter att de återställt den krypterade primärdatan.

Picture copyright: qimono/pixabay.com

CC0 license

https://pixabay.com/en/club-auction-law-symbol-judge-2492011/