viime vuosina world wide web on kokenut räjähdysmäisen kasvun hakkerien, malwaresin, lunnaiden ja muiden haittaohjelmien tai tahojen keskuudessa, jotka yrittävät jatkuvasti löytää tavan varastaa henkilötietojamme: tämän skenaarion vuoksi on sanomattakin selvää, että tietojesi turvaamisesta tuli yksi tärkeimmistä tehtävistä, jotka meidän tulisi priorisoida, riippumatta siitä, mikä rooli meillä yleensä on. Yleinen (ja kiireellinen) tarve estää luvattoman pääsyn henkilökohtaisiin, arkaluonteisiin ja/tai muuten kriittisiin tietoihin on jotain, joka kaikkien – loppukäyttäjien, palvelun omistajien, palvelinten ylläpitäjien ja niin edelleen-olisi tunnustettava: erot liittyvät enimmäkseen siihen, mitä meidän on suojattava ja miten meidän pitäisi tehdä se.

on sanomattakin selvää, että oikean tavan valinta tietojemme suojaamiseksi on usein seurausta hyvin toteutetusta riskinarvioinnista, jota seuraa kustannus-hyötyanalyysi, mikä on erinomainen lähestymistapa, joka auttaa meitä löytämään sopivat TEKNISET ja organisatoriset toimenpiteet, jotka voimme toteuttaa erityisessä skenaariossamme. Tämä on myös oikea tapa toimia yleisen tietosuoja-asetuksen (GDPR) mukaisesti, kuten artiklassa 32-käsittelyn turvallisuus:

ottaen huomioon tekniikan nykytilanne, täytäntöönpanokustannukset, käsittelyn luonne, laajuus, asiayhteys ja tarkoitukset sekä luonnollisten henkilöiden oikeuksiin ja vapauksiin kohdistuva riski, jonka todennäköisyys ja vakavuus vaihtelevat, rekisterinpitäjän ja henkilötietojen käsittelijän on toteutettava asianmukaiset tekniset ja organisatoriset toimenpiteet varmistaakseen riskin mukaisen turvallisuustason

tässä on luettelo yleisimmistä teknisistä ja organisatorisista toimenpiteistä tietojen suojelun ja turvallisuuden varmistamiseksi nykyään:

  • kulunvalvonta: Suojaa kaikki fyysinen pääsy palvelimeesi, asiakkaaseesi ja/tai datahuoneisiisi avaimilla, sirukorteilla, seinillä, kaapeilla, hälytyksillä ja muilla vastaavilla.
  • minimointi: varmista, että kaikki valtuutetut osapuolet pääsevät käsiksi vain heidän erityistehtäviinsä ja/tai valtuutuksiinsa liittyviin tietoihin ilman, että heidän sallitaan nähdä mitään muuta.
  • eheys: Suojaa tietosi vahingossa tapahtuvalta häviämiseltä, tuhoutumiselta tai vahingoittumiselta käyttämällä asianmukaisia vastatoimia (palo – /tulvaantureita, katastrofien palautumista ja vastaavia).
  • Pseudonymisointi: Korvaa käyttäjään liittyvät tiedot satunnaisilla, nimettömillä tekstilohkoilla, jotta omistaja voi edelleen säilyttää merkinnät (tilastotarkoituksiin) ja samalla poistaa ne kaikista henkilökohtaisista tiedoista.
  • salaus kauttakulussa: varmista, että tiedot lähetetään aina käyttämällä vahvoja kauttakulun aikaisia salausstandardeja (SSL/TLS-varmenteet) ja suojattujen yhteyksien kautta: tämä koskee myös mitä tahansa verkkosivustoa ja verkkopohjaista palvelua, joka sisältää lomakkeita, kirjautumisnäyttöjä, lataus-/latausominaisuuksia ja niin edelleen.
  • salaus levossa: Suojaa paikalliset tiedontallennusyksiköt (mukaan lukien palvelimien ja pöytäkoneiden & matkapuhelinasiakkaiden käyttämät) vahvalla at-rest-salausstandardilla; varmista, että SaaS-ja pilvipalveluihin tallennetut tiedot salataan myös at-rest-salauksella.
  • luottamuksellisuus: estä luvaton tai laiton käsittely toteuttamalla käsitteitä, kuten huolien erottaminen & tehtävien erottaminen, salasanakäytäntöjen noudattaminen ja niin edelleen.
  • hyödynnettävyys: Varmista, että kaikki asiaankuuluvat tiedot ovat säännöllisiä varmuuskopioita ja myös muista säännöllisesti tarkistaa ne sen varmistamiseksi, että tiedot voidaan onnistuneesti hakea.
  • arviointi: koko järjestelmän toimittaminen säännöllisiin teknisiin tarkastuksiin, kolmansien osapuolten tarkastuksiin, tehokkaiden turvallisuusindikaattoreiden käyttöönottoon ja niin edelleen.

tässä viestissä aiomme puhua kahdesta näistä teknisistä toimenpiteistä: salaus kauttakulussa ja salaus levossa, jättäen muut aiheet myöhempiin artikkeleihin.

Johdanto: digitaalisen tiedon kolme vaihetta

ensimmäinen asia, joka meidän pitäisi tehdä, on luetella, kuinka monta ”valtiota” digitaalisella datalla voi todellisuudessa olla, ja muista ymmärtää jokainen niistä:

  • levossa: tämä on minkä tahansa digitaalisen tiedon alkutila: hyvin lyhyesti sanottuna tämä tarkoittaa tietoja, jotka tallennetaan jonnekin ilman, että niitä käytetään ja/tai siirretään kenellekään (mukaan lukien ohjelmistot, kolmannet osapuolet, ihmiset ja niin edelleen). Paikallisista kiintolevyistä verkkoon liitettyihin varastoihin, USB pendriveistä mobiililaitteisiin, järjestelmäkansioista tietokantapalvelimiin, mihin tahansa fyysiseen ja loogiseen tallennusjärjestelmään, yksikköön tai laitteeseen on tarkoitus käyttää tietoja levossa… ainakin jonkin aikaa.
  • in transit: tunnetaan myös nimellä ”in motion”. Tämä on suhteessa dataan, joka siirretään jonnekin muualle. On syytä huomata, että käsite ”tiedonsiirto” voi tapahtua minkä tahansa osapuolen välillä, ei rajoitu vain kaksi (lähettäjä ja vastaanottaja): esimerkiksi, kun siirrämme tiedoston meidän pöytätietokone kannettavaan tietokoneeseen käyttämällä lähiverkon, olemme periaatteessa suorittaa tiedonsiirto, johon yhden osapuolen (us); kääntäen, kun lähetät liiketoimen jaetun tietokannan, kuten blockchain, olemme valvoa tiedonsiirto välillä epämääräinen määrä osapuolia (koko blockchain solmut).
  • käytössä: aina kun Tietoja ei vain tallenneta passiivisesti kiintolevylle tai ulkoiselle tallennusvälineelle, vaan niitä käsitellään yhdellä tai useammalla sovelluksella – ja siksi parhaillaan luodaan, katsellaan, päivitetään, liitetään, poistetaan ja niin edelleen – se on tarkoitettu ”käyttöön”. On sanomattakin selvää, että käytössä oleva tieto on altis erilaisille uhkille riippuen siitä, missä se on järjestelmässä ja kuka voi käyttää sitä ja/tai käyttää sitä. Kuitenkin, salaus tietojen käytössä on melko vaikea vetää pois, koska se todennäköisesti lamauttaa, estää tai kaataa sovelluksen, joka on tosiasiallisesti käyttää sitä: juuri tästä syystä, paras tapa suojata tietoja käytössä on varmistaa, että sovellus hoitaa tällaisen työn hyväksymällä turvallisin kehitys-ja toteutusmallit sen lähdekoodi.

edellä selitettyjen kolmen väittämän summaa kutsutaan ”digitaalisen tiedon kolmeksi vaiheeksi”: nyt kun saimme niiden ytimen, olemme valmiita sukeltamaan syvälle salausaiheisiin.

tiedon salaus levossa

edellä esitetystä ”levossa” – määritelmästä voimme helposti ymmärtää, miten tällainen tieto on tyypillisesti vakaassa tilassa: se ei kulje järjestelmässä tai verkossa, eikä siihen vaikuta mikään sovellus tai kolmas osapuoli. Se on jotain, joka on saavuttanut määränpään, ainakin väliaikaisesti.

syitä käyttää sitä

miksi niitä tietoja sitten edes salattaisiin? Siihen on useita hyviä syitä: Tarkastellaanpa niistä merkittävimpiä.

fyysinen varkaus

jos laitteemme varastetaan, salaus estää varasta pääsemästä välittömästi tietoihimme. Toki, se voi vielä yrittää purkaa sen käyttämällä brute-force tai muita salauksen murtamisen menetelmiä, mutta tämä on jotain, joka vie kohtuullisen paljon aikaa: meidän pitäisi ehdottomasti pystyä vetämään pois adeguate vastatoimet ennen kuin se tapahtuu, kuten: muuttamalla tilin tiedot hän voi nähdä tai jonkin verran käyttää nykyisten selainten salasananhallinta, kirjautumisevästeet, sähköpostiohjelmien tilit ja niin edelleen; seurata laitteen ja / tai antaa ”poistaa kaikki tiedot” käyttämällä Googlen tai Applen etälaitehallintapalvelut; ja niin edelleen.

looginen varkaus

jos haitallinen käyttäjä tai ohjelmisto hakkeroi PC -, verkkosivusto-tai sähköpostitilimme, salaus estää rikoksentekijän pääsyn tietoihimme – vaikka se varastettaisiin tai ladattaisiin: kyseessä on periaatteessa sama fyysisen varkauden skenaario, paitsi että se on paljon hienovaraisempi, koska useimmat käyttäjät (tai ylläpitäjät) eivät edes huomaa sitä.

tässä on jälleen hyvä tilaisuus muistaa John T. Chambers, Ciscon entinen toimitusjohtaja.:

on kahdenlaisia yrityksiä: niitä, jotka on hakkeroitu, ja niitä, jotka eivät tiedä, että ne on hakkeroitu.

kun otetaan huomioon Internetin nykytila nykyään sekä malwaresin ja mitattavissa olevien hakkerointiyritysten liiallinen runsaus, samaa voidaan sanoa jokaisesta loppukäyttäjästä, jolla on web-yhteensopiva laite: 100% takuu.

inhimilliset virheet

puhumattakaan fyysisistä ja / tai loogisista varkauksista, on olemassa paljon muita skenaarioita, joissa tietojen salaus levossa voisi olla hengenpelastaja: esimerkiksi, jos menetimme älypuhelimemme (ja joku löytää sen); tai jos teemme virheen, kun määritämme käyttöoikeuksia, myöntämällä luvattomille käyttäjille (tai asiakkaille) pääsyn tiedostoihin/kansioihin/tietoihin, joita heidän ei pitäisi voida nähdä; tai jos unohdamme paikallisen tietokoneen tai sähköpostin salasanan näkyvillä, jolloin kuka tahansa, joka ei halua kunnioittaa yksityisyyttämme, voi katsoa tavaroitamme; ja lista voi jatkua jonkin aikaa.

miten se voi auttaa meitä

tiivistämään kaiken tuon, voisimme vastata aiempiin kysymyksiimme yhdellä rivillä sanomalla, että lepotietojemme salaaminen voisi auttaa meitä paremmin käsittelemään mahdollista tietomurtoa.

se ei auta meitä estämään tätä – mikä on lähinnä palomuurien, virusvirusten, hyvien käytäntöjen ja turvaprotokollien tehtävä – mutta antaa meille ehdottomasti mahdollisuuden (ja ajan) toteuttaa asianmukaiset vastatoimet, toivottavasti minimoiden mahdollisen vuodon aiheuttamat kokonaisvahingot.

kuinka se toteutetaan

tietojen salauksen toteuttaminen lepoturvaprotokolla saattaa olla joko helppoa tai vaikeaa, riippuen seuraavista tekijöistä:

  • mitä fyysisiä ja loogisia tietolähteitä / varastoja haluamme (tai meillä on) suojella: fyysisiä lähteitä ovat kiintolevyt, NAS-elementit, älypuhelimet, USB pendrives ja niin edelleen, kun taas loogisia lähteitä ovat paikalliset tai etätietokannat, pilvipohjaiset varat, virtualisoidut laitteet ja niin edelleen;
  • kenellä on oltava pääsy näihin tietoihin: ihmiset (paikalliset tai etäkäyttäjät tai muut meihin yhteydessä olevat kolmannet osapuolet), ihmislähtöiset ohjelmistot (kuten MS Word) tai automaattiset prosessit tai palvelut (kuten yöllinen varmuuskopiointitehtävä);
  • kuinka paljon olemme valmiita uhraamaan yleisen suorituskyvyn ja/tai helppokäyttöisyyden suhteen turvallisuuden lisäämiseksi: voimmeko pyytää kaikkia paikallisia (ja etäkäyttäjiä) purkamaan näiden tietojen salauksen ennen kuin voimme käyttää niitä? Pitäisikö käyttää salasanaa, fyysistä tunnusta tai OTP-koodia? Voimmeko tehdä salauksesta riittävän läpinäkyvän, jotta se ei estä ulkopuolisia käyttäjiämme ja jotta ohjelmistosovelluksemme ja työkalumme voivat käsitellä salattua tietoa aina, kun heidän täytyy käsitellä sitä?

onneksi nämä tekijät tunnetaan useimmista levon salaustyökaluista, jotka on suunniteltu suojaamaan tietojamme vaarantamatta ympäristön yleistä toimivuutta:

  • jos haluamme salata fyysisiä (tai loogisia) kiintolevyjä, Voimme käyttää hienoja ohjelmistotyökaluja, kuten VeraCrypt (100% ilmainen) tai AxCrypt (ilmainen versio saatavilla);
  • jos meidän on suojattava USB-pendrivejämme, voimme joko käyttää edellä mainittuja työkaluja tai ostaa laitteistosalatun muistitikun, joka toteuttaa sormenjälkipohjaisia tai salasanapohjaisia avausmekanismeja (alkaen 20~30 taalaa);
  • jos haluamme salata tietokannan hallintajärjestelmään tallennetut tiedot, useimmat nykyisin saatavilla olevat DBMS: t tarjoavat natiiveja salaustekniikoita (InnoDB tablespace-salaus MySQL: lle ja MariaDB: lle, läpinäkyvä tietojen salaus MSSQL: lle ja niin edelleen);
  • jos etsimme tapaa säilyttää sähköpostiviestimme turvallisesti, voimme helposti ottaa käyttöön turvallisen sähköpostin salausstandardin, kuten S/MIME tai PGP (molemmat ovat ilmaisia): vaikka nämä protokollat liittyvät useimmiten kauttakulun aikaiseen salaukseen, koska ne suojaavat tietoja, jotka on useimmiten tarkoitettu siirrettäviksi etäosapuolille, itse asiassa niitä käytetään yleisesti asiakaspuolen salaukseen, mikä tarkoittaa, että ne suojaavat sähköpostiviestejä niiden ollessa vielä levossa. Sanomattakin on selvää, että koska nämä viestit todennäköisesti lähetetään, myös kohteemme on omaksuttava sama standardi voidakseen lukea ne.

tietojen salaus kauttakulussa

kuten nimestä käy ilmi, kauttakulussa olevaa tietoa olisi tarkasteltava paljon kuin siirtovirtaa: hyvä esimerkki kauttakulussa käytettävästä datasta on tyypillinen web-sivu, jonka saamme internetistä aina, kun surffaamme verkossa. Tässä mitä tapahtuu konepellin alla pähkinänkuoressa:

  1. lähetämme HTTP (tai HTTPS) – pyynnön palvelimelle, joka isännöi vierailemaamme verkkosivustoa.
  2. WWW-palvelin hyväksyy pyyntömme, käsittelee sen löytämällä pyytämämme (staattisen tai dynaamisen) sisällön ja lähettää sen sitten meille HTTP (tai HTTPS) – vastauksena tietyn TCP-portin kautta (yleensä 80 HTTP: lle ja 443 HTTPS: lle).
  3. asiakkaamme, yleensä verkkoselain, kuten Google Chrome, Firefox tai Edge, vastaanottaa HTTP(S) – vastauksen, tallentaa sen sisäiseen välimuistiinsa ja näyttää sen meille.

kuten voimme nähdä, palvelimen ja asiakkaan välillä on selvästi datarastasmissio: tämän trasmission aikana pyydetystä datasta (web-sivun HTML-koodi) tulee virtaus, joka kulkee vähintään viiden eri valtion läpi:

  1. se alkaa levossa (palvelimen tallennustila),
  2. sen jälkeen muutokset käytössä (WWW-palvelimen muisti),
  3. sen jälkeen siirryttäessä (hypertekstin siirtoprotokollaa käyttäen tietyssä TCP-portissa),
  4. sen jälkeen uudelleen käytössä olevaan (verkkoselain),
  5. ja lopuksi lepoon (asiakkaan välimuisti).

syitä käyttää sitä

nyt pidetään itsestäänselvyytenä, että sekä palvelin että asiakas ovat toteuttaneet vahvan tiedon salauksen levossa: tämä tarkoittaa, että ensimmäinen ja viides tila ovat sisäisesti turvallisia, koska kaikki murtoyritykset tehtäisiin salattua tietoa vastaan. Kolmas tila-jossa tiedot ovat siirron aikana – saattaa kuitenkin olla salattu tai ei, riippuen protokollasta, jota palvelin ja asiakas todellisuudessa käyttävät tietojen siirtämiseen.

näin yleensä tapahtuu hupun alla, kun HTTP-protokollaa käytetään:

salaus kauttakulussa ja salaus muualla-määritelmät ja parhaat käytännöt

kuten näemme, tietoturvaongelma on varsin ilmeinen: kun WWW-palvelin käsittelee saapuvan pyynnön ja purkaa pyydetyn tiedon läpinäkyvästi, kanava, jota käytetään sen siirtämiseen verkkoasiakkaalle (HTTP), ei ole salattu: näin ollen kuka tahansa rikkonut osapuoli, joka onnistuu suorittamaan sopivan hyökkäyksen (katso alla), voi saada välittömästi käyttöönsä salaamattomat tietomme..

miten se voi auttaa meitä

jos olet utelias tietämään, millaisia hyökkäyksiä voidaan käyttää salaamatonta TCP-pohjaista lähetysprotokollaa, kuten HTTP, vastaan, tässä pari uhkaa, joista sinun tulisi olla tietoinen:

  • salakuuntelu: verkkokerroksen hyökkäys, joka keskittyy muiden tietokoneiden välittämien pienten pakettien kaappaamiseen verkosta ja tietosisällön lukemiseen kaikenlaisten tietojen etsimisessä (lisätietoja täällä).
  • Keskinen: peukalointipohjainen hyökkäys, jossa hyökkääjä salaa välittää ja / tai muuttaa kahden osapuolen välistä viestintää saadakseen heidät uskomaan, että he kommunikoivat suoraan keskenään (lisätietoja täällä).

kunnollisten salausprotokollien käyttöönotto kriittisten tiedonsiirron päätepisteiden turvaamiseksi auttaa meitä varmasti ehkäisemään tällaisia uhkia.

miten se pannaan täytäntöön

tehokkaan salauksen toteuttaminen kauttakulun aikana edellyttää useimmiten pitäytymistä laajalti tunnetuissa suosituksissa ja parhaissa käytännöissä varsinaista tiedonsiirtoa suunniteltaessa: mitä protokollia käytetään (ei), mitä ohjelmistoja ei (ei) oteta käyttöön ja niin edelleen. Esimerkiksi:

  • aina kun lähettävä laite on saavutettavissa web-käyttöliittymän kautta, verkkoliikennettä tulisi siirtää vain SSL (Secure Sockets Layer) – järjestelmän kautta käyttäen vahvoja suojausprotokollia, kuten Transport Layer Security (TLS)- protokollaa.: tämä koskee mitä tahansa verkkosivustoa ja / tai WAN-tavoitettavissa olevaa palvelua, mukaan lukien sähköpostipalvelimet ja tykkäykset. Kuten tänään, paras (ja helpoin) tapa toteuttaa TLS turvallisuus ja toteuttaa salaus kauttakulun tahansa verkkosivuilla on hankkimalla SSL/TLS HTTPS-varmenne: ne voi joko ostaa rekisteröity CA viranomaisilta (Comodo, GlobalSign, GoDaddy, DigiCert ja niiden valtava jälleenmyyjien/subsellers luettelo) tai automaattisesti luotu kautta itse allekirjoitusprosessin, kuten lyhyesti selitettiin tässä viestissä. Vaikka itse allekirjoitetut varmenteet myöntävät saman salaustason kuin CA-allekirjoitetut kollegansa, käyttäjät eivät yleensä luota niihin, koska heidän selainasiakkaansa eivät pysty todentamaan liikkeeseenlaskijan henkilöllisyyden (Sinä) vilpittömyyttä, jolloin verkkosivustosi on ”epäluotettava”: juuri tästä syystä niitä tulisi käyttää vain ei-tuotannollisilla (tai ei-julkisesti saatavilla olevilla) palvelimilla/palveluilla.
  • kaikki sähköpostin välityksellä lähetetyt tiedot olisi suojattava käyttämällä Kryptografisesti vahvoja sähköpostin salaustyökaluja, kuten S/MIME tai PGP, joita käsittelimme jo silloin, kun puhuimme tietojen salauksesta levossa: vaikka nämä protokollat suorittavat salauksensa asiakastasolla (ja siten levossa), ne ovat myös loistavia suojaamaan sähköpostiviestin asynkronista kauttakulkuvirtaa.
  • kaikki binääritiedot tulee salata asianmukaisilla tiedostojen salaustyökaluilla ennen kuin ne liitetään sähköpostiin ja/tai lähetetään muulla tavoin. Useimmat pakkausprotokollat, mukaan lukien ZIP, RAR ja 7Z, tukevat nykyään kunnollista salasanasuojattua salausta: niiden käyttäminen on usein hyvä tapa lisätä lisäturvaa ja pienentää liitetiedoston kokoa samalla
  • tekstin ja/tai binääridatan muu kuin web-siirto tulisi salata myös sovellustason salauksella, ottaen huomioon seuraavat skenaariot:
    • jos sovellustietokanta sijaitsee sovelluspalvelimen ulkopuolella, tietokannan ja sovelluksen välinen yhteys on salattava käyttämällä FIPS-yhteensopivia salausalgoritmeja.
    • aina kun sovellustason salausta ei ole saatavilla, toteuta verkkotason salaus, kuten IPSec tai SSH-tunnelointi, ja/tai varmista, että itse lähetys suoritetaan valtuutetuilla laitteilla, jotka toimivat suojatuissa aliverkoissa, joissa on vahva palomuuriohjaus (VPN ja tykkäykset).

seuraavassa taulukossa on joitakin esimerkkejä turvattomista verkkoprotokollista, joita sinun tulisi välttää, ja niiden suojatuista vastineista, joita sinun tulisi käyttää sen sijaan:

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

päästä päähän-salaus

salaus kauttakulussa on todella hyödyllinen, mutta sillä on suuri rajoitus: se ei takaa, että tiedot salataan alkupisteessään eikä salausta pureta ennen kuin se on käytössä. Toisin sanoen tietojamme saattavat edelleenkin käyttää satunnaiset ja/tai haitalliset salakuuntelijat, mukaan lukien internet-palveluntarjoajat, viestintäpalvelujen tarjoajat ja kuka tahansa, joka voi käyttää salauksen purkamiseen tarvittavia salausavaimia kuljetuksen aikana.

tällaisen rajoituksen ylittäminen on mahdollista päästä päähän-salauksen (E2EE) ansiosta, viestintäparadigman, jossa vain kommunikoivat osapuolet-esimerkiksi käyttäjät – voivat purkaa salauksen ja siten lukea viestit. Päästä päähän salattu tieto salataan ennen sen lähettämistä ja pysyy salattuna, kunnes loppupuolue vastaanottaa sen.

syitä käyttää sitä

ymmärtääksemme paremmin, miten päästä päähän-salaus ylittää kauttakulkusalaisuuden salakuuntelijoiden sietokyvyn, kuvitellaan seuraavat skenaariot.

  1. Oletetaan, että kolmas osapuoli onnistuu sijoittamaan oman juurivarmenteensa luotetulle varmenneviranomaiselle: tällaisen toiminnan voisi teoriassa suorittaa valtion toimija, poliisiviranomainen tai jopa varmenneviranomaisen pahansuopa/korruptoitunut toimija. Kuka tahansa, joka pystyy tähän, voisi onnistuneesti toteuttaa itse TLS-liittymää vastaan man-in-the-middle-hyökkäyksen, salakuunnella keskustelua ja mahdollisesti jopa peukaloida sitä. Päästä päähän salattu data on natiivisti vastustuskykyinen tällaiselle hyökkäykselle, koska salausta ei suoriteta palvelintasolla.
  2. päästä päähän-salauksella voidaan myös nostaa suojaustasoa käyttöjärjestelmän synnyttämien käyttäjäprosessien joukossa. Muistatko viimeisimmät suorittimen viat nimeltä SPECTRE ja MELTDOWN? Molemmat sallivat haitallisen kolmannen osapuolen (kuten rogue-prosessin) lukea muistitietoja ilman lupaa tehdä niin. Päästä päähän-salaus voisi välttää tällaisen skenaarion niin kauan kuin salaus suoritetaan käyttäjäprosessin välillä (toisin kuin ydin), mikä estää salaamattoman tiedon tallentamisen muistiin.

miten se voi auttaa meitä

päästä päähän-salaus on turvallisin viestintämuoto, jota voidaan käyttää nykyään, koska se varmistaa, että vain sinä ja henkilö, jonka kanssa kommunikoit, voivat lukea mitä lähetetään, eikä kukaan välissä, ei edes palvelu, joka todella suorittaa lähetyksen vertaistensa välillä. Erilaiset päästä päähän-salaustoteutukset ovat jo tehokkaita useimmissa viestisovelluksissa ja palveluissa (mukaan lukien Whatsapp, LINE, Telegram ja tykkäykset). Tyypillisissä ”viestintäsovelluksissa” viestit on suojattu lukolla, ja vain lähettäjällä ja vastaanottajalla on erityinen avain, jota tarvitaan niiden avaamiseen ja lukemiseen: lisäsuojauksen vuoksi jokainen viesti lähetetään automaattisesti omalla ainutlaatuisella lukolla ja avaimella.

miten se toteutetaan

päästä päähän-salauksella voidaan suojata mitä tahansa: chat-viesteiltä, tiedostoilta, valokuvilta, IoT-laitteiden aistidatalta, pysyvältä tai tilapäiseltä datalta. Voimme valita, mitä tietoja haluamme päästä päähän-salata. Voimme esimerkiksi haluta säilyttää chat-sovellukseen liittyvät hyvänlaatuiset tiedot (kuten aikaleimat) selkotekstissä, mutta päästä päähän salata viestin sisällön.

  • jokaisella käyttäjällä on yksityinen & julkinen avain, joka ohjelmiston on luotava käyttäjän laitteeseen kirjautuessa tai seuraavan kerran kirjautuessa.
  • käyttäjän julkinen avain julkaistaan julkiseen paikkaan (kuten LEPOPOHJAISEEN avainten hallintapalveluun): tätä tarvitaan, jotta käyttäjät löytävät toistensa julkiset avaimet ja pystyvät salaamaan tiedot toisilleen.
  • käyttäjän yksityinen avain pysyy käyttäjän laitteessa, suojattuna käyttöjärjestelmän natiiviavainkaupassa (tai muissa suojatuissa myymälöissä).
  • ennen chat-viestin lähettämistä tai asiakirjan jakamista sovellus salaa sisällön vastaanottajan julkisella avaimella (asiakaspuoli).

johtopäätös

matkamme erilaisten salausparadigmojen läpi on täydellinen: Toivomme vilpittömästi, että tämä yleiskatsaus auttaa käyttäjiä ja järjestelmän ylläpitäjiä lisäämään tietoisuuttaan nykyisistä salaustyypeistä.

Vastaa

Sähköpostiosoitettasi ei julkaista.

lg