under de senaste åren World wide web har upplevt en exponentiell tillväxt av hackare, malwares, ransomwares och andra skadliga program eller parter som ständigt försöker hitta ett sätt att stjäla våra personuppgifter: med tanke på detta scenario, det säger sig självt att säkra dina data blev en av de viktigaste uppgifterna som vi bör prioritera, oavsett vilken roll som vi brukar spela. Det allmänna (och brådskande) behovet av att förhindra obehörig åtkomst till personlig, känslig och/eller på annat sätt kritisk information är något som bör erkännas av alla – slutanvändare, serviceägare, serveradministratörer och så vidare: skillnaderna är mest relaterade till vad vi behöver skydda och hur vi ska göra det.

naturligtvis är handlingen att välja rätt sätt att skydda våra data ofta efter en väl genomförd riskbedömning följt upp av en kostnads-nyttoanalys, vilket är ett bra sätt att hjälpa oss att hitta lämpliga tekniska och organisatoriska åtgärder för att genomföra i vårt specifika scenario. Detta är också det rätta sättet att agera enligt den allmänna dataskyddsförordningen (GDPR), som anges i Art. 32 – säkerhet för behandling:

med beaktande av den senaste tekniken, kostnaderna för genomförandet och behandlingens art, omfattning, sammanhang och ändamål samt risken för varierande sannolikhet och svårighetsgrad för fysiska personers rättigheter och friheter ska den registeransvarige och registerföraren genomföra lämpliga tekniska och organisatoriska åtgärder för att säkerställa en säkerhetsnivå som är lämplig för risken

här är en lista över de vanligaste tekniska och organisatoriska åtgärderna för att säkerställa skyddet och säkerheten för uppgifterna idag:

  • åtkomstkontroll: Skydda all fysisk åtkomst till din server, klient och/eller datarum med nycklar, chipkort, väggar, skåp, larm och liknande.
  • minimering: se till att alla behöriga parter endast kan få tillgång till data som är specifikt relaterade till deras specifika uppgifter och/eller tillstånd utan att få se något annat.
  • integritet: skydda dina data från oavsiktlig förlust, förstörelse eller skada med lämpliga motåtgärder (brand – /översvämningssensorer, katastrofåterställning och liknande).
  • pseudonymisering: Ersätt användarrelaterade data med slumpmässiga, anonyma textblock, så att ägaren fortfarande kan behålla posterna (för statistiska ändamål) och samtidigt ta bort dem från all personlig information.
  • kryptering i transit: se till att data alltid överförs med starka krypteringsstandarder (SSL/TLS-certifikat) och genom säkra anslutningar: detta gäller även alla typer av webbplatser och webbaserade tjänster som innehåller formulär, inloggningsskärmar, uppladdnings-/nedladdningsfunktioner och så vidare.
  • kryptering i vila: Skydda dina lokala datalagringsenheter (inklusive de som används av servrar och stationära & mobila klienter) med en stark krypteringsstandard i vila; se till att data som lagras i SaaS och molnbaserade tjänster också är krypterade i vila.
  • Sekretess: förhindra obehörig eller olaglig behandling genom att implementera begrepp som separering av problem & separering av uppgifter, verkställighet av lösenordspolicyer och så vidare.
  • återvinningsbarhet: Se till att alla relevanta data är föremål för regelbundna säkerhetskopior och också se till att regelbundet kontrollera dem för att säkerställa att data kan lyckas hämtas.
  • utvärdering: skicka hela systemet till regelbundna tekniska granskningar, tredjepartsrevisioner, anta en effektiv uppsättning säkerhetsindikatorer och så vidare.

i det här inlägget kommer vi att prata om två av dessa tekniska åtgärder: kryptering i transit och kryptering i vila, lämnar de andra ämnena för ytterligare artiklar.

Inledning: de tre stadierna av digitala Data

det första vi bör göra är att räkna upp hur många” stater ” digitala data faktiskt kan ha, och se till att förstå var och en av dem:

  • i vila: detta är det ursprungliga tillståndet för alla digitala data: på mycket korta termer indikerar detta data som lagras någonstans utan att användas av och/eller överföras till någon (inklusive programvara, tredje part, människor och så vidare). Från lokala hårddiskar till nätverksanslutna förråd, från USB-pendrives till mobila enheter, från systemmappar till databasservrar, är något fysiskt och logiskt lagringssystem, enhet eller enhet tänkt att användas för att innehålla data i vila… åtminstone ett tag.
  • i transit: även känd som”i rörelse”. Detta är i förhållande till de data som överförs någonstans till någon annanstans. Det är värt att notera att begreppet ”dataöverföring” kan ske mellan valfritt antal parter, inte begränsa till bara två (avsändaren och en mottagare): när vi till exempel överför en fil från vår stationära dator till vår bärbara dator med vårt LAN, utför vi i princip en dataöverföring som involverar en enda part (USA); omvänt, när vi skickar in en transaktion till en distribuerad databas, till exempel en blockchain, genomför vi en dataöverföring mellan en obestämd mängd parter (hela blockchain-noderna).
  • vid användning: när data inte bara lagras passivt på en hårddisk eller externt lagringsmedium, men bearbetas av en eller flera applikationer – och därför i färd med att genereras, ses, uppdateras, bifogas, raderas och så vidare – det är avsett att vara ”i bruk”. Det säger sig självt att data som används är mottagliga för olika typer av hot, beroende på var det finns i systemet och vem som kan komma åt och/eller använda det. Krypteringen av data som används är dock ganska svår att dra av, eftersom det sannolikt skulle lamslå, hindra eller krascha applikationen som faktiskt har åtkomst till den: just därför är det bästa sättet att skydda data som används att se till att applikationen tar hand om sådant jobb genom att anta de säkraste utvecklings-och implementeringsmönstren inom källkoden.

summan av de tre uttalandena som förklaras ovan kallas ”de tre stadierna av Digital Data”: nu när vi har kärnan i dem är vi redo att dyka djupt in i krypteringsämnena.

datakryptering i vila

från definitionen av” i vila ” ovan kan vi lätt förstå hur denna typ av data vanligtvis är i ett stabilt tillstånd: det reser inte inom systemet eller nätverket, och det påverkas inte av någon applikation eller tredje part. Det är något som har nått en destination, åtminstone tillfälligt.

anledningar att använda den

varför ska vi till och med kryptera dessa data då? Tja, det finns ett antal goda skäl för att göra det: låt oss ta en titt på de viktigaste.

fysisk stöld

om vår enhet blir stulen kommer krypteringen i vila att förhindra att tjuven omedelbart kan komma åt våra data. Säker, det kan fortfarande försöka att dekryptera den med brute-force eller andra krypterings sprickbildning metoder, men detta är något som kommer att ta en rimlig tid: vi bör definitivt kunna dra bort adeguate motåtgärder innan det händer, till exempel: ändra kontoinformation han skulle kunna se eller något använda via befintliga webbläsare lösenord chefer, inloggnings cookies, e-postklienter konton och så vidare; spåra vår enhet och / eller utfärda en ”radera alla data” med hjälp av våra Google eller Apple remote device management-tjänster; och så vidare.

logisk stöld

om vår dator, webbplats eller e-postkonto hackas av en skadlig användare eller programvara, kommer krypteringen i vila att göra att gärningsmannen inte kan komma åt våra data – även när den blir stulen eller nedladdad: det är i princip samma scenario med fysisk stöld, förutom att det är mycket mer subtilt eftersom de flesta användare (eller administratörer) inte ens kommer att vara medvetna om det.

här är en annan bra chans att komma ihåg de fantastiska ord yttrade av John T. Chambers, tidigare VD för Cisco, Inc.:

det finns två typer av företag: de som har hackats och de som inte vet att de har hackats.

med tanke på det nuvarande läget på internet idag och överflödet av malwares och mätbara hackningsförsök kan samma uttalande sägas för alla slutanvändare som har en webbaktiverad enhet: 100% garanterad.

mänskliga fel

än mindre de fysiska och/eller logiska stölderna, det finns många andra scenarier där datakryptering i vila kan vara en livräddare: till exempel, om vi förlorade vår smartphone (och någon hittar det); eller om vi gör ett misstag när vi tilldelar behörigheter, beviljar obehöriga användare (eller kunder) tillgång till filer/mappar/data som de inte borde kunna se; eller om vi glömmer vår lokala dator eller e-postlösenord i vanlig syn, vilket gör att alla som inte känner för att respektera vår integritet kan ta en titt på våra saker; och listan kan fortsätta ett tag.

Hur kan det hjälpa oss

för att sammanfatta allt detta kunde vi svara på våra tidigare frågor med en enda rad genom att säga att kryptering av våra vilodata kan hjälpa oss att bättre hantera ett eventuellt dataintrång.

det hjälper oss inte att förhindra att det händer – vilket för det mesta är en uppgift för brandväggar, Antivirus, god praxis och säkerhetsprotokoll – men kommer definitivt att ge oss chansen (och tiden) att ställa in lämpliga motåtgärder, förhoppningsvis minimera den totala skadan som görs av eventuell läcka.

hur man implementerar det

implementera ett datakryptering i vila säkerhetsprotokoll kan vara antingen enkelt eller svårt, beroende på följande faktorer:

  • vilka fysiska och logiska datakällor/lager vi vill (eller har) för att skydda: fysiska källor inkluderar Hårddiskar, NAS-element, smartphones, USB-pendrives och så vidare, medan logiska källor inkluderar lokala eller fjärrdatabaser, molnbaserade tillgångar, virtualiserade enheter och så vidare;
  • vem behöver ha tillgång till dessa data: människor (lokala eller fjärranvändare eller andra tredje parter som ansluter till oss), mänsklig driven programvara (som MS Word) eller automatiska processer eller tjänster (som en nattlig säkerhetskopieringsuppgift);
  • hur mycket vi är villiga att offra när det gäller övergripande prestanda och/eller enkel åtkomst för att öka säkerheten: kan vi be alla våra lokala (och fjärranslutna) användare att dekryptera dessa data innan de kan komma åt dem? Ska vi använda ett lösenord, en fysisk token eller en OTP-kod? Kan vi göra krypteringen tillräckligt transparent för att inte hindra våra externa användare och även låta våra mjukvaruappar och verktyg hantera krypterad data när de behöver hantera den?

lyckligtvis är dessa faktorer välkända av de flesta krypteringsverktyg i vila, som har utformats för att skydda våra data utan att äventyra den övergripande funktionaliteten i vår miljö:

  • om vi vill kryptera fysiska (eller logiska) hårddiskar kan vi använda fantastiska mjukvaruverktyg som VeraCrypt (100% gratis) eller AxCrypt (gratis version tillgänglig);
  • om vi behöver skydda våra USB-pendrives kan vi antingen använda de ovan nämnda verktygen eller köpa en hårdvarukrypterad Flash-enhet som implementerar fingeravtrycksbaserade eller lösenordsbaserade upplåsningsmekanismer (från 20~30 dollar);
  • om vi vill kryptera data som lagras i ett databashanteringssystem, tillhandahåller de flesta DBMS som finns tillgängliga idag inbyggda krypteringstekniker (InnoDB tablespace encryption för MySQL och MariaDB, Transparent Data Encryption för MSSQL och så vidare);
  • om vi letar efter ett sätt att säkert lagra våra e-postmeddelanden kan vi enkelt anta en säker e-postkrypteringsstandard som S/MIME eller PGP (båda är gratis): även om dessa protokoll oftast är relaterade till kryptering under transitering, eftersom de skyddar data som oftast är avsedda att överföras till avlägsna parter, används de faktiskt ofta för att utföra en kryptering på klientsidan, vilket innebär att de skyddar e-postmeddelandena medan de fortfarande är i vila. Naturligtvis, eftersom dessa meddelanden sannolikt kommer att skickas, måste våra destinationer också anta samma standard för att kunna läsa dem.

datakryptering i transit

som namnet antyder bör data i transit ses ungefär som en överföringsström: ett bra exempel på data i transit är en typisk webbsida som vi får från internet när vi surfar på webben. Här är vad som händer under huven i ett nötskal:

  1. vi skickar en HTTP-begäran (eller HTTPS) till servern som är värd för webbplatsen vi besöker.
  2. webbservern accepterar vår begäran, bearbetar den genom att hitta det (statiska eller dynamiska) innehållet vi har bett om och skickar det sedan till oss som ett HTTP (eller HTTPS) svar över en given TCP-port (vanligtvis 80 för HTTP och 443 för HTTPS).
  3. vår klient, vanligtvis en webbläsare som Google Chrome, Firefox eller Edge, tar emot HTTP(S) – svaret, lagrar det på sin interna cache och visar det för oss.

som vi kan se finns det tydligt en datatrasmission som pågår mellan servern och klienten: under den trasmissionen blir de begärda uppgifterna (webbsidan HTML-kod) ett flöde som går igenom minst fem olika tillstånd:

  1. det börjar vid vila (serverlagring),
  2. ändras sedan till in-use (webbserverminne),
  3. sedan till in-transit (med HyperText Transfer Protocol på en given TCP-port),
  4. sedan igen till in-use (webbläsare),
  5. och slutligen till at-rest (klientcache).

anledningar att använda den

Låt oss nu ta för givet att både servern och klienten har implementerat en stark nivå av datakryptering i vila: det betyder att det första och det femte tillståndet är internt säkert, eftersom alla intrångsförsök skulle göras mot krypterad data. Det tredje tillståndet-där data överförs – kan dock krypteras eller inte, beroende på vilket protokoll servern och klienten faktiskt använder för att överföra data.

här är vad som vanligtvis händer under huven när HTTP-protokollet används:

Encryption in-transit och Encryption at-rest - Definitions and Best Practices

som vi kan se är säkerhetsproblemet ganska uppenbart: när webbservern behandlar den inkommande begäran och transparent dekrypterar den begärda data, är kanalen som används för att överföra den till webbklienten (HTTP) inte krypterad: därför kan alla kränkande parter som lyckas dra av en lämplig attack (se nedan) ha omedelbar tillgång till våra okrypterade data.

Hur kan det hjälpa oss

om du är nyfiken på vilken typ av attacker som kan användas mot ett okrypterat TCP-baserat överföringsprotokoll som HTTP, här är ett par Hot du borde vara medveten om:

  • avlyssning: en nätverkslagerattack som fokuserar på att fånga små paket från nätverket som överförs av andra datorer och läsa datainnehållet på jakt efter någon typ av information (Mer info här).
  • Man-i-mitten: en manipuleringsbaserad attack där angriparen i hemlighet vidarebefordrar och / eller ändrar kommunikationen mellan två parter för att få dem att tro att de kommunicerar direkt med varandra (mer info här).

att implementera korrekta krypteringsprotokoll för transitering för att säkra våra kritiska dataöverföringsändpunkter kommer definitivt att hjälpa oss att förhindra denna typ av hot.

hur man implementerar det

att implementera ett effektivt krypteringsmönster i transit handlar mest om att hålla sig till en känd serie rekommendationer och bästa praxis när man utformar den faktiska dataöverföringen: vilka protokoll som ska användas (inte), vilken programvara som ska (inte) anta, och så vidare. Till exempel:

  • när sändningsenheten kan nås via webbgränssnitt, bör webbtrafik endast överföras via Secure Sockets Layer (SSL) med starka säkerhetsprotokoll som Transport Layer Security (TLS): detta gäller alla webbplatser och / eller WAN-nåbar tjänst, inklusive e-postservrar och liknande. Från och med idag är det bästa (och enklaste) sättet att implementera TLS-säkerhet och implementera krypteringen i transit för vilken webbplats som helst genom att erhålla ett SSL/TLS HTTPS-certifikat: de kan antingen köpas från registrerade CA-myndigheter (Comodo, GlobalSign, GoDaddy, DigiCert och deras enorma återförsäljare/delsäljarlista) eller automatiskt genereras genom en självsigneringsprocess, som vi kortfattat förklarade i det här inlägget. Även om självsignerade certifikat kommer att ge samma krypteringsnivå för sina CA-signerade motsvarigheter, kommer de i allmänhet inte att lita på användarna eftersom deras webbläsarklienter inte kommer att kunna verifiera utfärdarens identitet (du) och flagga din webbplats som ”otillförlitlig”: av just denna anledning bör de endast användas på icke-produktion (eller icke-offentligt tillgänglig) server/tjänster.
  • Alla data som överförs via e-post bör säkras med hjälp av kryptografiskt starka e-postkrypteringsverktyg som S/MIME eller PGP, som vi redan täckte när vi pratade om datakryptering i vila: även om dessa protokoll utför sin kryptering på klientnivå (och därför i vila), är de också bra för att skydda det asynkrona transitflödet i ett e-postmeddelande.
  • alla binära data ska krypteras med hjälp av lämpliga filkrypteringsverktyg innan de bifogas e-post och/eller överförs på något annat sätt. De flesta komprimeringsprotokoll, inklusive ZIP, RAR och 7Z, stöder en anständig nivå av lösenordsskyddad kryptering nuförtiden: att använda dem är ofta ett bra sätt att lägga till en extra säkerhetsnivå och minska bilagans storlek samtidigt
  • icke-webböverföring av text och/eller binär data bör också krypteras via applikationsnivåkryptering, med hänsyn till följande scenarier:
    • om programdatabasen finns utanför programservern ska anslutningen mellan databasen och programmet krypteras med FIPS-kompatibla kryptografiska algoritmer.
    • när programnivåkryptering inte är tillgänglig, implementera nätverksnivåkryptering som IPSec eller SSH-tunnling och/eller se till att själva överföringen utförs med hjälp av auktoriserade enheter som arbetar inom skyddade undernät med starka brandväggskontroller (VPN och liknande).

följande tabell visar några exempel på de osäkra nätverksprotokoll du bör undvika och deras säkra motsvarigheter du bör använda istället:

Transfer Type What to avoid (insecure) What to use (secure)
Web Access HTTP HTTPS
E-Mail Servers POP3, SMTP, IMAP POP3S, IMAPS, SMTPS
File Transfer FTP, RCP FTPS, SFTP, SCP, WebDAV over HTTPS
Remote Shell telnet SSH2
Remote Desktop VNC radmin, RDP

end-to-End-kryptering

kryptering i transit är verkligen användbart, men det har en stor begränsning: det garanterar inte att data kommer att krypteras vid startpunkten och kommer inte att dekrypteras förrän den används. Med andra ord kan våra data fortfarande föregås av tillfälliga och / eller skadliga avlyssnare, inklusive Internetleverantörer, kommunikationstjänstleverantörer och vem som helst som kan komma åt de kryptografiska nycklarna som behövs för att dekryptera data under transitering.

att övervinna sådan begränsning är möjlig tack vare End-to-End – kryptering (E2EE), ett kommunikationsparadigm där endast de kommunicerande slutpartierna – till exempel användarna-kan dekryptera och därför läsa meddelandena. End-to-end krypterad data krypteras innan den överförs och kommer att förbli krypterad tills den tas emot av slutpartiet.

anledningar att använda den

för att bättre förstå hur end-to-end-kryptering superseeds in-transit-kryptering när det gäller motståndskraft mot avlyssnare, låt oss föreställa oss följande scenarier.

  1. Antag att en tredje part lyckas plantera sitt eget rotcertifikat på en betrodd certifikatmyndighet: en sådan åtgärd kan teoretiskt utföras av en statlig aktör, en polistjänst eller till och med en skadlig/skadad operatör av en certifikatmyndighet. Den som kan göra detta kan framgångsrikt driva en man-i-mitten-attack på själva TLS-anslutningen, avlyssna konversationen och eventuellt till och med manipulera den. End-to-end krypterad data är naturligt motståndskraftig mot denna typ av attack, eftersom krypteringen inte utförs på servernivå.
  2. End-to-end-kryptering kan också öka skyddsnivån bland användarprocesserna som skapas av ett operativsystem. Kommer du ihåg de senaste CPU-bristerna som heter SPECTRE Och MELTDOWN? Båda tillät en skadlig tredje part (till exempel en skurkprocess) att läsa minnesdata utan att ha behörighet att göra det. End-to-end-kryptering kan undvika ett sådant scenario så länge krypteringen utförs mellan användarprocessen (i motsats till kärnan), vilket förhindrar att okrypterad data läggs i minnet.

hur det kan hjälpa oss

end-to-end-kryptering är den säkraste kommunikationsformen som kan användas idag, eftersom det säkerställer att bara du och personen du kommunicerar med kan läsa vad som skickas, och ingen däremellan, inte ens den tjänst som faktiskt utför överföringen mellan kamrater. Olika end-to-end-krypteringsimplementeringar är redan effektiva på de flesta meddelandeprogram och tjänster (inklusive Whatsapp, LINE, Telegram och liknande). I en typisk ”kommunikationsapp” – scenarier är meddelandena säkrade med ett lås, och endast avsändaren och mottagaren har den specialnyckel som behövs för att låsa upp och läsa dem: för extra skydd skickas varje meddelande automatiskt med sitt eget unika lås och nyckel.

hur man implementerar det

End-to-end-kryptering kan användas för att skydda allt: från chattmeddelanden, filer, foton, sensoriska data på IoT-enheter, permanenta eller tillfälliga data. Vi kan välja vilka data vi vill end-to-end kryptera. Vi kanske till exempel vill behålla godartad information relaterad till en chattapp (som tidsstämplar) i klartext men kryptera meddelandets innehåll från början till slut.

  • varje användare har en privat & offentlig nyckel som programvaran måste generera på användarnas enhet vid registrering eller nästa gång de loggar in.
  • användarens offentliga nyckel publiceras på en offentlig plats (till exempel en REST-baserad nyckelhanteringstjänst): detta krävs för att användarna ska hitta varandras offentliga nycklar och kunna kryptera data till varandra.
  • användarens privata nyckel förblir på användarens enhet, skyddad av operativsystemets inbyggda nyckelbutik (eller andra säkra butiker).
  • innan du skickar ett chattmeddelande eller delar ett dokument krypterar appen innehållet med mottagarens offentliga nyckel (klientsidan).

slutsats

vår resa genom de olika krypteringsparadigmerna är klar: vi hoppas verkligen att denna översikt hjälper användare och systemadministratörer att öka sin medvetenhet om de olika typerna av kryptering som finns tillgängliga idag.

Lämna ett svar

Din e-postadress kommer inte publiceras.

lg