i de siste årene har world wide web opplevd en eksponentiell vekst av hackere, malwares, ransomwares og annen skadelig programvare eller parter som hele tiden prøver å finne en måte å stjele våre personlige data på: gitt dette scenariet sier det seg selv at sikring av dataene dine ble en av de viktigste oppgavene vi bør prioritere, uavhengig av hvilken rolle vi vanligvis spiller. Det generelle (og presserende) behovet for å forhindre uautorisert tilgang til personlig, sensitiv og / eller på annen måte kritisk informasjon er noe som bør anerkjennes av alle – sluttbrukere, tjenesteeiere, serveradministratorer og så videre: forskjellene er for det meste relatert til hva vi trenger å beskytte og hvordan vi skal gjøre det.

det Er unødvendig Å si at det å velge riktig måte å beskytte dataene våre på, ofte følger av en godt utført risikovurdering fulgt opp av en kostnad-nytte-analyse, som er en god tilnærming for å hjelpe oss med å finne de riktige tekniske og organisatoriske tiltakene som skal implementeres i vårt spesifikke scenario. Dette er også den riktige måten å handle i Henhold TIL General Data Protection Regulation (GDPR), som angitt I Artikkel 32-Sikkerhet For Behandling:

idet det Tas hensyn til det nyeste innen teknologi, gjennomføringskostnader og behandlingens art, omfang, kontekst og formål, samt risikoen for varierende sannsynlighet og alvorlighetsgrad for fysiske personers rettigheter og friheter, skal den behandlingsansvarlige og databehandleren iverksette hensiktsmessige tekniske og organisatoriske tiltak for å sikre et sikkerhetsnivå som er passende for risikoen

her er en liste over de vanligste tekniske og organisatoriske tiltakene for å sikre beskyttelse og sikkerhet av dataene i dag:

  • Adgangskontroll: Beskytt all fysisk tilgang til server, klient og / eller datarom med nøkler, chipkort, vegger, skap, alarmer og lignende.
  • Minimering: Sørg for at alle autoriserte parter kun har tilgang til dataene som er spesifikt relatert til deres spesifikke oppgaver og / eller autorisasjon uten å få lov til å se noe annet.
  • Integritet: Beskytt dataene dine mot utilsiktet tap, ødeleggelse eller skade ved hjelp av passende mottiltak(brann – / flomsensorer, Katastrofegjenoppretting og lignende).
  • Pseudonymisering: Erstatt brukerrelaterte data med tilfeldige, anonyme tekstblokker, slik at eieren fortsatt vil kunne beholde oppføringene (for statistiske formål) og samtidig fjerne dem fra personlig informasjon.
  • Kryptering under overføring: Sikre at dataene alltid overføres ved hjelp av sterke krypteringsstandarder under overføring (SSL/TLS-sertifikater) og gjennom sikre tilkoblinger: dette gjelder også alle typer nettsteder og nettbaserte tjenester som inneholder skjemaer, innloggingsskjermer, opplastings – /nedlastingsfunksjoner og så videre.
  • Kryptering ved hvile: Beskytt de lokale datalagringsenhetene dine (inkludert de som brukes av servere og mobile klienter & på skrivebordet) med en sterk krypteringsstandard for hvile; sørg for at dataene som er lagret I SaaS og skybaserte tjenester, også krypteres i hvilemodus.
  • Konfidensialitet: Forhindre uautorisert eller ulovlig behandling ved å implementere konsepter som adskillelse av bekymringer & adskillelse av plikter, håndheving av passordpolicyer og så videre.
  • Gjenvinnbarhet: Sørg for at alle relevante data er gjenstand for regelmessige sikkerhetskopier, og sørg også for å sjekke dem regelmessig for å sikre at dataene kan hentes vellykket.
  • Evaluering: Send hele systemet til vanlige tekniske vurderinger, tredjepartsrevisjoner, vedta et effektivt sett med sikkerhetsindikatorer og så videre.

I dette innlegget skal vi snakke om to av disse tekniske tiltakene: Kryptering i transitt og Kryptering i hvile, og la de andre emnene for ytterligere artikler.

Innledning: De Tre Stadiene Av Digitale Data

det første vi bør gjøre er å oppregne hvor mange» stater » digitale data faktisk kan ha, og sørg for å forstå hver enkelt av dem:

  • i ro: dette er den opprinnelige tilstanden til alle digitale data: i svært korte termer indikerer dette dataene som er lagret et sted uten å bli brukt av og/eller overført til noen(inkludert programvare, tredjeparter, mennesker og så videre). Fra lokale Harddisker Til Nettverkstilkoblede Lagre, FRA USB pendrives til mobile enheter, fra systemmapper til databaseservere, er ethvert fysisk og logisk lagringssystem, enhet eller enhet ment å brukes til å inneholde data i ro… i hvert fall for en stund.
  • i transitt: også kjent som «i bevegelse». Dette er i forhold til dataene som overføres et sted til et annet sted. Det er verdt å merke seg at begrepet «dataoverføring» kan skje mellom en rekke parter, ikke begrense til bare to (avsender og mottaker): for eksempel, når vi overfører en fil fra vår stasjonære PC til vår bærbare DATAMASKIN ved HJELP av VÅRT LAN, utfører vi i utgangspunktet en dataoverføring som involverer en enkelt part (usa); omvendt, når vi sender inn en transaksjon til en distribuert database, for eksempel en blockchain, håndhever vi en dataoverføring mellom et ubestemt antall parter (hele blockchain noder).
  • i bruk: når dataene ikke bare lagres passivt på en harddisk eller eksternt lagringsmedium, men behandles av ett eller flere applikasjoner – og derfor i ferd med å bli generert, vist, oppdatert, lagt til, slettet og så videre – er det ment å være «i bruk». Det sier seg selv at data i bruk er utsatt for ulike typer trusler, avhengig av hvor det er i systemet og hvem som kan få tilgang til og/eller bruke det. Imidlertid er kryptering av data i bruk ganske vanskelig å trekke av, siden det mest sannsynlig vil kreme, hindre eller krasje applikasjonen som faktisk får tilgang til den: av denne grunn er den beste måten å beskytte dataene i bruk, å sikre at applikasjonen vil ta seg av en slik jobb ved å vedta de sikreste utviklings-og implementeringsmønstrene innenfor kildekoden.

summen av de tre uttalelsene som er forklart ovenfor kalles «De Tre Stadiene Av Digitale Data»: nå som vi fikk kjernen av dem, er vi klare til å dykke dypt inn i krypteringsemnene.

Datakryptering i hvilemodus

fra definisjonen av «hvilemodus» gitt ovenfor kan vi lett forstå hvordan denne typen data vanligvis er i stabil tilstand: den beveger seg ikke i systemet eller nettverket, og den blir ikke påvirket av noen applikasjon eller tredjepart. Det er noe som har nådd et mål, i hvert fall midlertidig.

Grunner til å bruke den

Hvorfor skal vi selv kryptere disse dataene da? Vel, det er en rekke gode grunner til å gjøre det: la oss ta en titt på de viktigste.

Fysisk tyveri

hvis enheten vår blir stjålet, vil krypteringen i ro forhindre at tyven umiddelbart får tilgang til dataene våre. Sikker, det kan fortsatt prøve å dekryptere den ved hjelp av brute-force eller andre krypterings sprengning metoder, men dette er noe som vil ta en rimelig tid: vi bør definitivt være i stand til å trekke av adeguate mottiltak før det skjer, for eksempel: endre kontoinformasjon han kan være i stand til å se eller noe bruk via eksisterende nettlesere passord ledere, login cookies, e-postklienter kontoer og så videre; spore enheten vår og / eller utstede en «slett alle data» ved Hjelp Av Google eller Apple remote device management services; og så videre.

Logisk tyveri

hvis VÅR PC, nettside eller e-postkonto blir hacket av en ondsinnet bruker eller programvare, vil krypteringen i ro gjøre lovbryteren ute av stand til å få tilgang til dataene våre – selv når de er stjålet eller lastet ned: det er i utgangspunktet det samme scenariet for fysisk tyveri, bortsett fra at det er mye mer subtilt fordi de fleste brukere (eller administratorer) ikke engang vil være klar over det.

her er en annen god sjanse til å huske de fantastiske ordene uttalt Av John T. Chambers, TIDLIGERE ADMINISTRERENDE DIREKTØR I Cisco, Inc.:

det finnes to typer selskaper: de som har blitt hacket, og de som ikke vet at de har blitt hacket.

Med Tanke på den nåværende tilstanden på internett i dag og over-overflod av malwares og målbare hackingforsøk, kan den samme setningen sies for enhver sluttbruker som har en web-aktivert enhet: 100% guarranteed.

Menneskelige feil

enn si de fysiske og/eller logiske tyveriene, det er mange andre scenarier der datakryptering i ro kan være en livredder: for eksempel, hvis vi mistet smarttelefonen vår (og noen finner den); eller hvis vi gjør en feil mens vi tilordner tillatelser, gir uautoriserte brukere (eller kunder) tilgang til filer/mapper / data de ikke burde kunne se; eller hvis vi glemmer vårt lokale PC-eller e-postpassord i vanlig syn, slik at alle som ikke har lyst til å respektere personvernet vårt, kan se på tingene våre; og listen kan fortsette en stund.

Hvordan kan det hjelpe oss

for å oppsummere alt dette, kan vi svare på våre tidligere spørsmål med en enkelt linje ved å si at kryptering av våre hviledata kan hjelpe oss med å bedre håndtere et Mulig Datainnbrudd.

Det vil ikke hjelpe oss med å forhindre at det skjer – som for det meste er en oppgave for brannmurer, antivirus, god praksis og sikkerhetsprotokoller – men vil definitivt gi oss sjansen (og tiden) til å sette opp de riktige mottiltakene, forhåpentligvis minimere den generelle skaden som er gjort av en mulig lekkasje.

hvordan implementere det

Implementering Av En Datakryptering i hvilesikkerhetsprotokoll kan være enten lett eller vanskelig, avhengig av følgende faktorer:

  • hvilke fysiske og logiske datakilder/lagre vi ønsker (eller har) å beskytte: fysiske kilder inkluderer Harddisker, nas-elementer, smarttelefoner, USB-pendrives og så videre, mens logiske kilder inkluderer lokale eller eksterne databaser, skybaserte eiendeler, virtualiserte enheter og så videre;
  • hvem må ha tilgang til disse dataene: mennesker (lokale eller eksterne brukere eller andre tredjeparter som kobler til oss), menneskedrevet programvare (FOR EKSEMPEL MS Word) eller automatiske prosesser eller tjenester (for eksempel en nattlig sikkerhetskopieringsoppgave);
  • hvor mye vi er villige til å ofre når det gjelder generell ytelse og/eller enkel tilgang for å øke sikkerheten: kan vi be alle våre lokale (og eksterne) brukere om å dekryptere disse dataene før de kan få tilgang til dem? Skal vi bruke et passord, et fysisk token eller EN OTP-kode? Kan vi gjøre krypteringen gjennomsiktig nok til ikke å hindre våre eksterne brukere, og også å la våre programvareapper og verktøy håndtere de krypterte dataene når de trenger å håndtere det?

Heldigvis er disse faktorene godt kjent av de fleste krypteringsverktøy i hvilemodus, som er designet for å beskytte dataene våre uten å gå på kompromiss med miljøets generelle funksjonalitet:

  • hvis vi vil kryptere fysiske (eller logiske) Harddisker, kan vi bruke gode programvareverktøy Som VeraCrypt (100% gratis) eller AxCrypt (gratis versjon tilgjengelig);
  • hvis VI trenger å beskytte VÅRE USB pendrives, kan vi enten bruke de nevnte verktøyene eller kjøpe en maskinvarekryptert Flash-Stasjon som implementerer fingeravtrykksbaserte eller passordbaserte opplåsingsmekanismer (starter fra 20~30 bucks);
  • hvis vi ønsker å kryptere dataene som er lagret i Et Databasebehandlingssystem, gir de fleste DBMS som er tilgjengelige i dag innfødte krypteringsteknikker (InnoDB tablespace kryptering For MySQL og MariaDB, Gjennomsiktig Datakryptering FOR MSSQL og så videre);
  • hvis vi leter etter en måte å sikkert lagre Våre e-postmeldinger på, kan vi enkelt vedta en sikker e-postkrypteringsstandard som S/MIME eller PGP (begge er gratis): selv om disse protokollene for det meste er relatert til kryptering i transitt, siden de beskytter data som hovedsakelig er ment å bli overført til eksterne parter, blir de faktisk ofte brukt til å utføre en kryptering på klientsiden, noe som betyr at de beskytter e-postmeldingene mens de fortsatt er i ro. Unødvendig å si, siden disse meldingene mest sannsynlig vil bli sendt, må destinasjonene våre også vedta samme standard for å kunne lese dem.

Datakryptering i transitt

som navnet antyder, bør data i transitt sees som en overføringsstrøm: et godt eksempel på data i transitt er en typisk nettside vi mottar fra internett når vi surfer på nettet. Her er hva som skjer under hetten i et nøtteskall:

  1. VI sender EN HTTP (ELLER HTTPS) forespørsel til serveren som er vert for nettstedet vi besøker.
  2. webserveren godtar forespørselen vår, behandler den ved å finne det (statiske eller dynamiske) innholdet vi har bedt om, og sender det til OSS som ET HTTP (ELLER HTTPS) – svar over en gitt TCP-port(vanligvis 80 FOR HTTP og 443 FOR HTTPS).
  3. vår klient, vanligvis en nettleser Som Google Chrome, Firefox eller Edge, mottar HTTP(s) – svaret, lagrer DET på sin interne cache og viser det til oss.

som vi kan se, er det tydelig en datatransmission som skjer mellom serveren og klienten: under den trasmisjonen blir de forespurte dataene (html-koden for nettsiden) en flyt som går gjennom minst fem forskjellige tilstander:

  1. den starter at-rest (serverlagring),
  2. endres deretter til in-use (webserverminne),
  3. deretter til in-transit (Ved Hjelp Av HyperText Transfer Protocol på en gitt tcp-port),
  4. så igjen til in-use (nettleser),
  5. og til slutt til at-rest (klientbuffer).

Grunner til å bruke den

nå, la Oss ta for gitt at både serveren og klienten har implementert et sterkt nivå av datakryptering i ro: dette betyr at den første og den femte staten er internt trygge, fordi noen inntrengingsforsøk ville bli gjort mot krypterte data. Den tredje staten – hvor dataene er i transitt-kan imidlertid være kryptert eller ikke, avhengig av protokollen serveren og klienten faktisk bruker til å overføre dataene.

her er det som vanligvis skjer under hetten når HTTP-protokollen brukes:

Kryptering i transitt Og Kryptering i hviledefinisjoner Og Beste Praksis

som vi kan se, er sikkerhetsproblemet ganske tydelig: når webserveren behandler den innkommende forespørselen og transparent dekrypterer de forespurte dataene, er kanalen som brukes til å overføre den til webklienten (HTTP) ikke kryptert: derfor kan enhver fornærmende part som klarer å lykkes med å trekke av et passende angrep (se nedenfor) ha umiddelbar tilgang til våre ukrypterte data.

Hvordan kan det hjelpe oss

hvis du er nysgjerrig på hvilken type angrep som kan brukes mot en ukryptert TCP-basert overføringsprotokoll SOM HTTP, er det et par trusler du bør være oppmerksom PÅ:

  • Avlytting: et nettverk lag angrep som fokuserer på å fange små pakker fra nettverket overføres av andre datamaskiner og lese datainnhold på jakt etter alle typer informasjon (mer info her).
  • Mann I Midten: et manipuleringsbasert angrep hvor angriperen i hemmelighet releer og / eller endrer kommunikasjonen mellom to parter for å få dem til å tro at de kommuniserer direkte med hverandre (mer info her).

Implementering av riktig kryptering i transittprotokoller for å sikre våre kritiske dataoverføringsendepunkter, vil definitivt hjelpe oss med å forhindre slike trusler.

hvordan implementere det

Implementering av et effektivt krypteringsmønster i transitt er for det meste et spørsmål om å holde seg til en bredt kjent serie anbefalinger og beste praksis mens du utformer den faktiske dataoverføringen: hvilke protokoller som skal (ikke) brukes, hvilken programvare som skal (ikke) adoptere, og så videre. For eksempel:

  • når senderenheten er tilgjengelig via webgrensesnitt, bør webtrafikk bare overføres Over Secure Sockets Layer (SSL) ved hjelp av sterke sikkerhetsprotokoller som Transport Layer Security (Tls): dette gjelder alle nettsteder og / eller WAN-tilgjengelig tjeneste, inkludert e-postservere og lignende. Fra og med i dag er den beste (og enkleste) måten å implementere TLS-sikkerhet på og implementere kryptering i transitt for et hvilket som helst nettsted, ved å skaffe ET SSL / TLS HTTPS-sertifikat: de kan enten kjøpes fra registrerte CA-myndigheter (Comodo, GlobalSign, GoDaddy, Digicert og deres store forhandlerliste) eller automatisk generert gjennom en selvsigneringsprosess, som vi kort forklart i dette innlegget. Selv om selvsignerte sertifikater vil gi samme krypteringsnivå som SINE CA-signerte kolleger, vil de vanligvis ikke være klarert av brukerne, da nettleserklienter ikke vil kunne bekrefte utstederens identitet (deg), og flagge nettstedet ditt som «uklarert»: av denne grunn bør de bare brukes på ikke-produksjons (eller ikke-offentlig tilgjengelig) server / tjenester.
  • alle data som overføres via e – post, bør sikres ved hjelp av kryptografisk sterke e-krypteringsverktøy som S / MIME eller PGP, som vi allerede dekket da vi snakket om datakryptering i hvilemodus: selv om disse protokollene utfører kryptering på klientnivå (og derfor i hvilemodus), er de også gode for å beskytte den asynkrone transittstrømmen av en e-postmelding.
  • alle binære data skal krypteres ved hjelp av riktig filkrypteringsverktøy før de legges ved e-post og/eller overføres på annen måte. De fleste komprimeringsprotokoller, inkludert ZIP, RAR OG 7Z, støtter et anstendig nivå av passordbeskyttet kryptering i dag: bruk av dem er ofte en fin måte å legge til et ekstra sikkerhetsnivå og redusere vedleggsstørrelsen samtidig
  • Ikke-weboverføring av tekst og / eller binære data bør også krypteres via kryptering på applikasjonsnivå, med følgende scenarier i betraktning:
    • hvis programdatabasen ligger utenfor programserveren, skal forbindelsen mellom databasen og programmet krypteres ved HJELP AV fips-kompatible kryptografiske algoritmer.
    • når kryptering på programnivå ikke er tilgjengelig, implementer kryptering på nettverksnivå som IPSec eller SSH-tunneling, og / eller sørg for at selve overføringen utføres ved hjelp av autoriserte enheter som opererer innenfor beskyttede delnett med sterke brannmurkontroller (VPN og lignende).

tabellen nedenfor viser noen eksempler på de usikre nettverksprotokollene du bør unngå, og deres sikre kolleger du bør bruke i stedet:

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

Ende-Til-Ende-Kryptering

Kryptering i transitt er veldig nyttig, Men Det har en stor begrensning: det garanterer ikke at dataene blir kryptert ved startpunktet og vil ikke dekrypteres før den er i bruk. Med andre ord, våre data kan fortsatt være predated av sporadiske og / eller ondsinnede tyvlyttere, inkludert internett-leverandører, kommunikasjonstjenesteleverandører og hvem som kunne få tilgang til kryptografiske nøkler som trengs for å dekryptere dataene under transitt.

Å Overvinne en slik begrensning er mulig takket Være Ende-Til-Ende-Kryptering (E2EE), et kommunikasjonsparadigme der bare de kommuniserende sluttpartene – for eksempel brukerne – kan dekryptere og derfor lese meldingene. Ende-til-ende-krypterte data krypteres før de overføres og forblir kryptert til de mottas av sluttparten.

Grunner til å bruke det

for bedre å forstå hvordan ende-til-ende-kryptering superseeds in-transit kryptering i form av elastisitet til tyvlyttere, la oss forestille oss følgende scenarier.

  1. Anta at en tredjepart klarer å plante sitt eget rotsertifikat på en klarert sertifiseringsinstans: slik handling kan teoretisk utføres av en statlig aktør, en polititjeneste eller til og med en ondsinnet/ødelagt operatør av En Sertifiseringsinstans. Alle som er i stand til å gjøre dette, kan med hell operere et man-in-the-middle-angrep på tls-forbindelsen selv, avlytting på samtalen og muligens til og med tukle med det. Ende-til-ende-krypterte data er opprinnelig motstandsdyktig mot denne typen angrep, fordi krypteringen ikke utføres på servernivå.
  2. Ende-til-ende-kryptering kan også øke beskyttelsesnivået blant brukerprosessene som oppstår av et operativsystem. Husker du DE siste CPU-feilene SOM HETER SPECTRE og MELTDOWN? Begge tillot en ondsinnet tredjepart (for eksempel en rogue prosess) å lese minnedata uten å være autorisert til å gjøre det. Ende-til-ende-kryptering kan unngå et slikt scenario så lenge krypteringen utføres mellom brukerprosessen (i motsetning til kjernen), og dermed forhindre at ukrypterte data blir satt i minnet.

Hvordan Det kan hjelpe oss

Ende-til-ende-kryptering Er Den sikreste formen for kommunikasjon som kan brukes i dag, da det sikrer at bare du og personen du kommuniserer med, kan lese hva som sendes, og ingen i mellom, ikke engang tjenesten som faktisk utfører overføringen mellom jevnaldrende. Ulike ende-til-ende kryptering implementeringer er allerede effektive på de fleste meldingsprogrammer og tjenester(inkludert Whatsapp, LINE, Telegram og lignende). I et typisk «kommunikasjonsapp» – scenario er meldingene sikret med en lås, og bare avsender og mottaker har den spesielle nøkkelen som trengs for å låse opp og lese dem: for ekstra beskyttelse sendes hver melding automatisk med sin egen unike lås og nøkkel.

slik implementerer du det

Ende-til-ende-kryptering kan brukes til å beskytte alt: fra chatmeldinger, filer, bilder, sensoriske data på iot-enheter, permanente eller midlertidige data. Vi kan velge hvilke data vi vil ende-til-ende kryptere. For eksempel vil vi kanskje beholde godartet informasjon relatert til en chat-app (som tidsstempler) i ren tekst, men ende-til-ende krypterer meldingsinnholdet.

  • hver bruker har en privat & offentlig nøkkel som programvaren må generere på brukerens enhet ved registrering eller neste gang de logger inn.
  • brukerens offentlige nøkkel publiseres på et offentlig sted (FOR EKSEMPEL EN REST-basert nøkkeladministrasjonstjeneste): dette kreves for at brukerne skal finne hverandres offentlige nøkler og kunne kryptere data til hverandre.
  • brukerens private nøkkel forblir på brukerens enhet, beskyttet av operativsystemets native key store(eller andre sikre butikker).
  • før du sender en chatmelding eller deler et dokument, krypterer appen innholdet ved hjelp av mottakerens offentlige nøkkel (klientside).

Konklusjon

vår reise gjennom de ulike krypteringsparadigmene er fullført: vi håper at denne oversikten vil hjelpe brukere og systemadministratorer til å øke bevisstheten om de ulike krypteringstypene som er tilgjengelige i dag.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.

lg