az elmúlt néhány évben a world wide web tapasztalt exponenciális növekedés a hackerek, malwares, váltságdíjas és más rosszindulatú szoftverek vagy felek, amely folyamatosan próbál találni a módját, hogy ellopják a személyes adatok: mivel ez a forgatókönyv, magától értetődik, hogy az adatok védelme lett az egyik legfontosabb feladat, hogy meg kell prioritást, függetlenül attól, hogy a szerep, amit általában játszanak. A személyes, érzékeny és/vagy más módon kritikus információkhoz való jogosulatlan hozzáférés megakadályozásának általános (és sürgős) szükségességét mindenkinek el kell ismernie – végfelhasználóknak, szolgáltatástulajdonosoknak, szerveradminisztrátoroknak és így tovább: a különbségek leginkább azzal kapcsolatosak, hogy mit kell védenünk és hogyan kell ezt tennünk.

mondanom sem kell, hogy az adataink védelmének megfelelő módjának kiválasztása gyakran egy jól végrehajtott kockázatértékelést követ, amelyet költség-haszon elemzés követ, ami nagyszerű megközelítés, amely segít megtalálni a megfelelő technikai és szervezeti intézkedéseket, amelyeket konkrét forgatókönyvünkben végre kell hajtani. Ez az Általános Adatvédelmi Rendelet (GDPR) szerinti cselekvés megfelelő módja is, amint azt a 32. cikk – Az adatkezelés biztonsága:

figyelembe véve a technika állását, a megvalósítás költségeit, az adatkezelés jellegét, hatókörét, körülményeit és céljait, valamint a természetes személyek jogaira és szabadságaira vonatkozó változó valószínűségű és súlyosságú kockázatot, az adatkezelő és az adatfeldolgozó megfelelő technikai és szervezési intézkedéseket hajt végre a kockázatnak megfelelő biztonsági szint biztosítása érdekében

az alábbiakban felsoroljuk azokat a leggyakoribb technikai és szervezési intézkedéseket, amelyek napjainkban az adatok védelmét és biztonságát garantálják:

  • hozzáférés-vezérlés: Védje az összes fizikai hozzáférést a szerverhez, az ügyfélhez és/vagy az adatszobákhoz kulcsokkal, chipkártyákkal, falakkal, szekrényekkel, riasztókkal és hasonlókkal.
  • minimalizálás: annak biztosítása, hogy az összes felhatalmazott fél csak a konkrét feladataikhoz és/vagy felhatalmazásukhoz kapcsolódó adatokhoz férhessen hozzá anélkül, hogy bármi mást látna.
  • integritás: Védje adatait a véletlen elvesztéstől, megsemmisüléstől vagy sérüléstől megfelelő ellenintézkedésekkel (tűz/árvíz érzékelők, katasztrófa utáni helyreállítás és hasonlók).
  • Álnevesítés: Cserélje ki a felhasználóval kapcsolatos adatokat véletlenszerű, névtelen szövegblokkokkal, hogy a tulajdonos továbbra is megőrizhesse a bejegyzéseket (statisztikai célokra), és ugyanakkor eltávolítsa őket minden személyes adatból.
  • tranzit titkosítás: győződjön meg arról, hogy az adatokat mindig erős tranzit titkosítási szabványokkal (SSL/TLS tanúsítványok) és biztonságos kapcsolatokon keresztül továbbítják: ez vonatkozik minden olyan weboldalra és webalapú szolgáltatásra is, amely űrlapokat, bejelentkezési képernyőket, feltöltési/letöltési képességeket stb.tartalmaz.
  • titkosítás nyugalmi állapotban: Védje helyi adattároló egységeit (beleértve a szerverek és az asztali & mobil kliensek által használtakat is) erős nyugalmi titkosítási szabványokkal; gondoskodjon arról, hogy a SaaS-ban és a felhőalapú szolgáltatásokban tárolt adatok nyugalmi állapotban is titkosítva legyenek.
  • titoktartás: megakadályozza a jogosulatlan vagy jogellenes feldolgozást olyan fogalmak végrehajtásával, mint például az aggodalmak szétválasztása & a feladatok szétválasztása, a jelszószabályok érvényesítése stb.
  • Visszanyerhetőség: Győződjön meg arról, hogy az összes releváns adat rendszeres biztonsági mentésnek van kitéve, és győződjön meg róla, hogy rendszeresen ellenőrzi őket annak biztosítása érdekében, hogy az adatok sikeresen visszakereshetők legyenek.
  • értékelés: Küldje el az egész rendszert rendszeres műszaki felülvizsgálatoknak, harmadik féltől származó ellenőrzéseknek, hatékony biztonsági mutatók elfogadásának stb.

ebben a bejegyzésben két technikai intézkedésről fogunk beszélni: a titkosítás tranzitban és a titkosítás nyugalomban, a többi témát további cikkekre hagyva.

Bevezetés: a digitális adatok három szakasza

az első dolog, amit meg kell tennünk, hogy felsoroljuk, hogy hány” állapot ” lehet a digitális adatoknak, és győződjön meg róla, hogy mindegyiket megérti:

  • nyugalomban: ez a digitális adatok kezdeti állapota: nagyon rövid távon ez azt jelzi, hogy az adatokat valahol tárolják anélkül, hogy bárki felhasználná és/vagy továbbítaná (beleértve a szoftvereket, harmadik feleket, embereket stb.). A helyi merevlemezektől a hálózathoz csatlakoztatott Tárolókig, az USB pendrive-októl a mobil eszközökig, a rendszermappáktól az adatbázis-kiszolgálókig minden fizikai és logikai tárolórendszert, egységet vagy eszközt arra szánnak, hogy nyugalmi állapotban lévő adatokat tároljon… legalább egy ideig.
  • tranzitban: más néven “mozgásban”. Ez viszonylagos az adatokhoz, amelyeket valahova máshova továbbítanak. Érdemes megjegyezni, hogy az “adatátvitel” fogalma tetszőleges számú fél között történhet, nem korlátozva csak kettőre (a feladóra és a vevőre): például, amikor egy fájlt asztali számítógépünkről laptopunkra továbbítunk a LAN-on keresztül, alapvetően egy adatátvitelt hajtunk végre egyetlen fél (USA) bevonásával; fordítva, amikor tranzakciót küldünk el egy elosztott adatbázisba, például egy blokkláncba, határozatlan mennyiségű fél (a teljes blokklánc-csomópont) közötti adatátvitelt hajtunk végre.
  • használatban: amikor az adatokat nem csak passzívan tárolják egy merevlemezen vagy külső adathordozón, hanem egy vagy több alkalmazás feldolgozza – és ezért generálják, megtekintik, frissítik, hozzáfűzik, törlik stb.–, akkor “használatban van”. Magától értetődik, hogy a használatban lévő adatok különböző típusú fenyegetéseknek vannak kitéve, attól függően, hogy hol vannak a rendszerben, és ki tudja elérni és/vagy használni. A használatban lévő adatok titkosítása azonban meglehetősen nehézkes, mivel nagy valószínűséggel megbénítaná, akadályozná vagy összeomlaná a ténylegesen hozzáférő alkalmazást: éppen ezért a használatban lévő adatok védelmének legjobb módja annak biztosítása, hogy az alkalmazás a forráskódján belül a legbiztonságosabb fejlesztési és végrehajtási minták elfogadásával gondoskodjon erről a feladatról.

a fenti három állítás összegét “a digitális adatok három szakaszának” nevezzük: most, hogy megkaptuk ezek lényegét, készen állunk arra, hogy mélyen belemerüljünk a titkosítási témákba.

adattitkosítás nyugalmi állapotban

a “nyugalmi állapotban” fenti meghatározásából könnyen megérthetjük, hogy az ilyen típusú adatok jellemzően stabil állapotban vannak: nem a rendszeren vagy a hálózaton belül utaznak, és semmilyen alkalmazás vagy harmadik fél nem cselekszik rájuk. Ez valami, ami elérte a rendeltetési helyet, legalábbis ideiglenesen.

használatának okai

akkor miért kellene titkosítanunk ezeket az adatokat? Nos, ennek számos jó oka van: vessünk egy pillantást a legjelentősebbekre.

fizikai lopás

ha eszközünket ellopják, a nyugalmi titkosítás megakadályozza, hogy a tolvaj azonnal hozzáférjen az adatainkhoz. Biztos, akkor is próbálja visszafejteni azt a brute-force vagy más titkosítás-repedés módszerek, de ez valami, hogy lesz egy ésszerű mennyiségű időt: mi feltétlenül képesnek kell lennie arra, hogy húzza le a adeguate ellenintézkedéseket, mielőtt ez megtörténik, mint például: megváltoztatása a fiók info lehet, hogy képes látni, vagy némileg használja a meglévő böngészők jelszókezelők, bejelentkezési cookie-k, e-mail kliensek számlák és így tovább; Kövesse nyomon az eszközünket és / vagy adjon ki egy “minden adat törlése” parancsot a Google vagy az Apple távoli eszközkezelő szolgáltatásainkon keresztül; és így tovább.

logikai lopás

ha PC-nket, weboldalunkat vagy e-mail fiókunkat egy rosszindulatú felhasználó vagy szoftver feltöri, a titkosítás nyugalmi állapotában az elkövető nem tud hozzáférni az adatainkhoz – még akkor sem, ha ellopják vagy letöltik: alapvetően ugyanaz a fizikai lopás forgatókönyve, kivéve, hogy sokkal finomabb, mert a legtöbb felhasználó (vagy rendszergazda) nem is fog tudni róla.

itt van még egy jó esély arra, hogy emlékezzünk John T. félelmetes szavaira. Chambers, a Cisco, Inc. korábbi vezérigazgatója.:

kétféle vállalat létezik: azok, amelyeket feltörtek, és azok, akik nem tudják, hogy feltörték őket.

figyelembe véve az internet jelenlegi állapotát, valamint a rosszindulatú programok és mérhető hackelési kísérletek túlzott bőségét, ugyanez mondható el minden olyan végfelhasználóról, aki rendelkezik webes eszközzel: 100%-ban garantált.

emberi hibák

nem beszélve a fizikai és / vagy logikai lopásokról, sok más forgatókönyv létezik, ahol az adatok titkosítása nyugalmi állapotban életmentő lehet: például, ha elvesztettük az okostelefonunkat (és valaki megtalálja); vagy ha hibát követünk el, amikor engedélyeket osztunk ki, jogosulatlan felhasználóknak (vagy ügyfeleknek) hozzáférést biztosítunk olyan fájlokhoz/mappákhoz/adatokhoz, amelyeket nem szabadna látniuk; vagy ha elfelejtjük a helyi PC-nket vagy e-mail jelszavunkat, így bárki, aki nem érzi tiszteletben a magánéletünket, megnézheti a dolgainkat; és a lista egy ideig folytatódhat.

hogyan segíthet nekünk

mindezek összefoglalása érdekében egyetlen sorral válaszolhatnánk korábbi kérdéseinkre, mondván, hogy a nyugalmi adatok titkosítása segíthet abban, hogy jobban kezeljük az esetleges Adatsértéseket.

ez nem segít megakadályozni, hogy ez megtörténjen – ami leginkább a tűzfalak, antivírusok, jó gyakorlatok és biztonsági protokollok feladata–, de mindenképpen lehetőséget (és időt) ad arra, hogy beállítsuk a megfelelő ellenintézkedéseket, remélhetőleg minimalizálva az esetleges szivárgás által okozott általános károkat.

hogyan kell végrehajtani

a nyugalmi állapotban lévő adattitkosítási biztonsági protokoll végrehajtása egyszerű vagy nehéz lehet, A következő tényezőktől függően:

  • mely fizikai és logikai adatforrásokat / tárolókat szeretnénk (vagy van) megvédeni: a fizikai források közé tartoznak a merevlemezek,NAS elemek, okostelefonok, USB pendrive-ok stb., míg a logikai források közé tartoznak a helyi vagy távoli adatbázisok, felhőalapú eszközök, virtualizált eszközök stb.;
  • kinek kell hozzáférnie ezekhez az adatokhoz: emberi lények (helyi vagy távoli felhasználók vagy más, hozzánk csatlakozó harmadik felek), ember által vezérelt szoftverek (például MS Word) vagy automatikus folyamatok vagy szolgáltatások (például éjszakai biztonsági mentési feladat);
  • mennyit hajlandóak feláldozni az általános teljesítmény és/vagy a könnyű hozzáférés érdekében a biztonság növelése érdekében: megkérhetjük-e az összes helyi (és távoli) felhasználónkat, hogy dekódolják ezeket az adatokat, mielőtt hozzáférhetnének hozzájuk? Használjunk jelszót, fizikai tokent vagy OTP kódot? Tudjuk, hogy a titkosítás átlátható ahhoz, hogy ne akadályozzák a külső felhasználók, valamint lehetővé teszi a szoftver alkalmazások és eszközök kezelni a titkosított adatokat, amikor csak kell foglalkozni vele?

szerencsére ezeket a tényezőket a legtöbb nyugalmi titkosító eszköz jól ismeri, amelyeket úgy terveztek, hogy adatainkat megvédjék anélkül, hogy veszélyeztetnék környezetünk általános funkcionalitását:

  • ha fizikai (vagy logikai) merevlemez-meghajtókat akarunk titkosítani, nagyszerű szoftvereszközöket használhatunk, mint például a VeraCrypt (100% ingyenes) vagy az AxCrypt (ingyenes verzió elérhető);
  • ha meg kell védenünk USB pendrive-jainkat, használhatjuk a fent említett eszközöket, vagy vásárolhatunk hardveresen titkosított Flash meghajtót, amely ujjlenyomat-vagy jelszó-alapú feloldási mechanizmusokat valósít meg (20~30 dollártól kezdve);
  • ha az adatbázis-kezelő rendszerben tárolt adatokat szeretnénk titkosítani, a ma elérhető DBMS-ek többsége natív titkosítási technikákat biztosít (InnoDB táblaterület titkosítás a MySQL és a MariaDB számára, átlátszó adattitkosítás az MSSQL számára stb.);
  • ha az E-Mail üzeneteink biztonságos tárolásának módját keressük, könnyen elfogadhatunk egy biztonságos e-mail titkosítási szabványt, mint például az S/MIME vagy a PGP (mindkettő ingyenes): bár ezek a protokollok többnyire a tranzit titkosításhoz kapcsolódnak, mivel védik az adatokat, amelyeket többnyire távoli feleknek továbbítanak, valójában általában kliens oldali titkosításra használják őket, ami azt jelenti, hogy védik az e-mail üzeneteket, miközben még nyugalomban vannak. Mondanom sem kell, hogy mivel ezeket az üzeneteket nagy valószínűséggel elküldjük, rendeltetési helyünknek is ugyanazt a szabványt kell elfogadnia, hogy el tudja olvasni őket.

adatátvitel közbeni adattitkosítás

ahogy a neve is mutatja, az adatátvitelt úgy kell tekinteni, mint egy átviteli adatfolyamot: a tranzitadatok nagyszerű példája egy tipikus weboldal, amelyet az internetről kapunk, amikor az interneten böngészünk. Dióhéjban ez történik a motorháztető alatt:

  1. HTTP (vagy HTTPS) kérést küldünk a meglátogatott webhelyet tároló szervernek.
  2. a webszerver elfogadja a kérésünket, feldolgozza a kért (statikus vagy dinamikus) tartalom megkeresésével, majd HTTP (vagy HTTPS) válaszként elküldi nekünk egy adott TCP porton keresztül (általában 80 HTTP és 443 HTTPS esetén).
  3. ügyfelünk, általában egy webböngésző, mint például a Google Chrome, Firefox vagy Edge, megkapja a HTTP(S) választ, tárolja a belső gyorsítótárában, és megmutatja nekünk.

mint látható, egyértelműen adattranszmisszió folyik a szerver és a kliens között: a trasmission során a kért adatok (a weboldal HTML-kódja) áramlássá válnak, amely legalább öt különböző állapoton megy keresztül:

  1. a rendszer nyugalmi állapotban indul (szerver tároló),
  2. , majd használat közbeni (webszerver memória),
  3. , majd tranzit (hipertext átviteli protokollt használva egy adott TCP porton),
  4. , majd ismét használat közbeni (webböngésző),
  5. és végül nyugalmi állapotban (kliens gyorsítótár).

használatának okai

most vegyük biztosra, hogy mind a szerver, mind az ügyfél erős szintű adattitkosítást hajtott végre nyugalmi állapotban: ez azt jelenti, hogy az első és az ötödik állapot belsőleg biztonságos, mert bármilyen behatolási kísérlet a titkosított adatok ellen történne. Azonban a harmadik állapot-ahol az adatok tranzitban vannak – lehet titkosítva vagy sem, attól függően, hogy a szerver és a kliens milyen protokollt használ az adatok továbbítására.

a HTTP protokoll használatakor általában a motorháztető alatt történik:

tranzit titkosítás és nyugalmi titkosítás-meghatározások és bevált gyakorlatok

amint láthatjuk, a biztonsági probléma meglehetősen nyilvánvaló: amikor a webszerver feldolgozza a bejövő kérést, és átlátható módon visszafejti a kért adatokat, a webes klienshez (HTTP) történő átvitelhez használt csatorna nincs titkosítva: ezért bármely jogsértő fél, akinek sikerül sikeresen végrehajtania egy megfelelő támadást (lásd alább), azonnal hozzáférhet a titkosítatlan adatainkhoz.

hogyan segíthet nekünk

ha kíváncsi arra, hogy milyen típusú támadásokat lehet használni egy titkosítatlan TCP-alapú átviteli protokoll, például a HTTP ellen, itt van néhány fenyegetés, amelyet tudnia kell:

  • lehallgatás: hálózati réteg támadás, amely arra összpontosít, hogy más számítógépek által továbbított kis csomagokat rögzítsen a hálózatról, és bármilyen típusú információ keresése céljából elolvassa az adattartalmat (További információ itt).
  • ember a közepén: manipuláláson alapuló támadás, ahol a támadó titokban továbbítja és/vagy megváltoztatja a két fél közötti kommunikációt, hogy elhitesse velük, hogy közvetlenül kommunikálnak egymással (További információ itt).

a megfelelő titkosítási tranzit protokollok végrehajtása a kritikus adatátviteli végpontok biztonsága érdekében mindenképpen segít megelőzni az ilyen típusú fenyegetéseket.

hogyan kell végrehajtani

a hatékony titkosítási tranzitminta végrehajtása többnyire a széles körben ismert ajánlások és bevált gyakorlatok sorozatának betartása a tényleges adatátvitel megtervezése során: mely protokollokat (nem) kell használni, mely szoftvereket (nem) kell elfogadni stb. Például:

  • amikor az Adóeszköz webes felületen keresztül elérhető, a webes forgalmat csak a Secure Sockets Layer (SSL) rendszeren keresztül szabad továbbítani erős biztonsági protokollok, például a Transport Layer Security (TLS)használatával: ez vonatkozik minden weboldalra és / vagy WAN-re elérhető szolgáltatásra, beleértve az e-mail szervereket és a lájkokat. A mai naptól kezdve a legjobb (és legegyszerűbb) módja a TLS biztonság megvalósításának és a titkosítás megvalósításának bármely webhelyen az SSL/TLS HTTPS tanúsítvány megszerzésével: ezek megvásárolhatók a regisztrált CA hatóságoktól (Comodo, GlobalSign, GoDaddy, DigiCert és hatalmas viszonteladók/alértékesítők listája), vagy automatikusan generálhatók egy önaláírási folyamaton keresztül, amint azt röviden kifejtettük ebben a bejegyzésben. Bár az önaláírt tanúsítványok ugyanazt a titkosítási szintet biztosítják, mint a CA-aláírással rendelkező társaik, a felhasználók általában nem bíznak bennük, mivel böngésző ügyfeleik nem tudják ellenőrizni a kibocsátó személyazonosságának (Ön) jóhiszeműségét, és az Ön webhelyét “nem megbízhatónak” jelölik: éppen ezért ezeket csak nem termelési (vagy nem nyilvánosan hozzáférhető) szervereken/szolgáltatásokon szabad használni.
  • az e-mailen keresztül továbbított adatokat kriptográfiailag erős e-mail titkosítási eszközökkel kell biztosítani, mint például az S/MIME vagy a PGP, amelyekről már beszéltünk, amikor a nyugalmi adatok titkosításáról beszéltünk: bár ezek a protokollok titkosításukat kliens szinten (és ezért nyugalmi állapotban) végzik, kiválóan védik az e-mail üzenetek aszinkron tranzitfolyamát is.
  • minden bináris adatot megfelelő fájltitkosító eszközökkel kell titkosítani, mielőtt e-mailhez csatolnánk és/vagy bármilyen más módon továbbítanánk. A legtöbb tömörítési protokoll, köztük a ZIP, a RAR és a 7Z, manapság támogatja a jelszóval védett titkosítás megfelelő szintjét: ezek használata gyakran nagyszerű módja annak, hogy további biztonsági szintet adjon hozzá, és csökkentse a melléklet méretét egyidejűleg
  • a szöveg és/vagy bináris adatok nem webes továbbítását alkalmazásszintű titkosítással is titkosítani kell, figyelembe véve a következő forgatókönyveket:
    • ha az alkalmazásadatbázis az alkalmazáskiszolgálón kívül található, az adatbázis és az alkalmazás közötti kapcsolatot FIPS-kompatibilis kriptográfiai algoritmusokkal kell titkosítani.
    • ha az alkalmazásszintű titkosítás nem érhető el, hajtson végre hálózati szintű titkosítást, például IPSec vagy SSH alagutat, és/vagy gondoskodjon arról, hogy maga az átvitel az erős tűzfalvezérlésű védett alhálózatokon (VPN és hasonlók) működő engedélyezett eszközökkel történjen.

az alábbi táblázat néhány példát mutat be a nem biztonságos hálózati protokollokra, amelyeket el kell kerülnie, valamint a biztonságos megfelelőiket, amelyeket ehelyett használnia kell:

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

végpontok közötti titkosítás

a tranzit titkosítás valóban hasznos, de van egy jelentős korlátja: nem garantálja, hogy az adatok a kiindulási ponton titkosítva lesznek, és nem lesznek visszafejtve, amíg használatba nem kerülnek. Más szavakkal, adatainkat még mindig megelőzhetik alkalmi és / vagy rosszindulatú lehallgatók, beleértve az internetszolgáltatókat, a kommunikációs szolgáltatókat és azokat, akik hozzáférhetnek az adatok dekódolásához szükséges kriptográfiai kulcsokhoz szállítás közben.

az ilyen korlátozás leküzdése a végpontok közötti titkosításnak (E2EE) köszönhetően lehetséges, egy olyan kommunikációs paradigmának köszönhetően, ahol csak a kommunikáló végfelek-például a felhasználók-képesek dekódolni és ezért olvasni az üzeneteket. A végpontok közötti titkosított adatok titkosítva vannak, mielőtt továbbítanák őket, és titkosítva maradnak, amíg a végső fél meg nem kapja őket.

használatának okai

annak érdekében, hogy jobban megértsük, hogyan végpontok közötti titkosítás a tranzit titkosítás a lehallgatókkal szembeni ellenálló képesség szempontjából, képzeljük el a következő forgatókönyveket.

  1. tegyük fel, hogy egy harmadik félnek sikerül telepítenie saját gyökértanúsítványát egy megbízható tanúsító hatóságra: ezt elméletileg végrehajthatja egy állami szereplő, egy rendőrség vagy akár egy tanúsító hatóság rosszindulatú/sérült üzemeltetője. Bárki, aki képes erre, sikeresen működtet egy ember-in-the-middle támadást maga a TLS kapcsolat ellen, lehallgatva a beszélgetést, sőt esetleg manipulálva is. A végpontok közötti titkosított adatok natív módon ellenállnak az ilyen típusú támadásoknak, mivel a titkosítást nem szerver szinten hajtják végre.
  2. a végpontok közötti titkosítás növelheti az operációs rendszer által létrehozott felhasználói folyamatok védelmi szintjét is. Emlékszel a SPECTRE és MELTDOWN nevű CPU hibákra? Mindkettő lehetővé tette egy rosszindulatú harmadik félnek (például egy szélhámos folyamatnak) a memóriaadatok olvasását anélkül, hogy erre felhatalmazást kaptak volna. A végpontok közötti titkosítás elkerülheti az ilyen forgatókönyveket, amíg a titkosítást a felhasználói folyamatok között hajtják végre (szemben a kernellel), ezáltal megakadályozva a titkosítatlan adatok memóriába helyezését.

hogyan segíthet nekünk

a végpontok közötti titkosítás a legbiztonságosabb kommunikációs forma, amelyet manapság lehet használni, mivel biztosítja, hogy csak Ön és az a személy, akivel kommunikál, olvassa el az elküldötteket, és senki sem közte, még az a szolgáltatás sem, amely ténylegesen végrehajtja az átvitelt társaik között. Különböző end-to-end titkosítási implementációk már hatékonyak a legtöbb üzenetküldő alkalmazásban és szolgáltatásban (beleértve a Whatsapp-ot, a LINE-t, a Telegramot és a lájkokat). Egy tipikus “kommunikációs alkalmazás” esetén az üzenetek zárral vannak rögzítve, és csak a feladó és a címzett rendelkezik a feloldáshoz és az olvasáshoz szükséges speciális kulccsal: a fokozott védelem érdekében minden üzenet automatikusan elküldésre kerül saját egyedi zárral és kulccsal.

hogyan kell végrehajtani

a végpontok közötti titkosítás bármit megvédhet: a csevegőüzenetektől, fájloktól, fényképektől, az IoT eszközök érzékszervi adataitól, az állandó vagy ideiglenes adatoktól. Kiválaszthatjuk, hogy milyen adatokat akarunk titkosítani. Előfordulhat például, hogy egy csevegőalkalmazással kapcsolatos jóindulatú információkat (például időbélyegeket) egyszerű szövegben szeretnénk megőrizni, de az üzenet tartalmát végpontok között titkosítani.

  • minden felhasználónak van egy privát & nyilvános kulcsa, amelyet a szoftvernek létre kell hoznia a Felhasználó eszközén a regisztrációkor vagy a következő bejelentkezéskor.
  • a felhasználó nyilvános kulcsa nyilvános helyen kerül közzétételre (például REST-alapú kulcskezelő szolgáltatás): Erre azért van szükség, hogy a felhasználók megtalálják egymás nyilvános kulcsait, és képesek legyenek egymás adatainak titkosítására.
  • a felhasználó privát kulcsa a Felhasználó eszközén marad, amelyet az operációs rendszer natív kulcstárolója (vagy más biztonságos tároló) véd.
  • csevegőüzenet küldése vagy Dokumentum megosztása előtt az alkalmazás titkosítja a tartalmat a címzett nyilvános kulcsával (ügyféloldali).

következtetés

utunk a különböző titkosítási paradigmákon keresztül befejeződött: őszintén reméljük, hogy ez az áttekintés segít a felhasználóknak és a rendszergazdáknak, hogy növeljék tudatosságukat a ma elérhető különféle titkosítási típusokkal kapcsolatban.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.

lg