i de seneste par år har internettet oplevet en eksponentiel vækst af hackere, ondskabsfuldheder, løsepenge og andre ondsindede programmer eller parter, der konstant forsøger at finde en måde at stjæle vores personlige data på: i betragtning af dette scenario siger det sig selv, at sikring af dine data blev en af de vigtigste opgaver, som vi bør prioritere, uanset hvilken rolle vi normalt spiller. Det generelle (og presserende) behov for at forhindre uautoriseret adgang til personlige, følsomme og/eller på anden måde kritiske informationer er noget, der bør anerkendes af alle – slutbrugere, serviceejere, serveradministratorer og så videre: forskellene er for det meste relateret til, hvad vi har brug for at beskytte, og hvordan vi skal gøre det.

det er overflødigt at sige, at handlingen med at vælge den rigtige måde at beskytte vores data ofte følger efter en veludført risikovurdering efterfulgt af en cost-benefit-analyse, som er en god tilgang til at hjælpe os med at finde de passende tekniske og organisatoriske foranstaltninger, der skal implementeres i vores specifikke scenario. Dette er også den rigtige måde at handle i henhold til den generelle databeskyttelsesforordning (GDPR), som angivet i Art. 32-sikkerhed for behandling:

under hensyntagen til det aktuelle tekniske niveau, implementeringsomkostningerne og arten, omfanget, konteksten og formålene med behandlingen samt risikoen for varierende sandsynlighed og alvor for fysiske personers rettigheder og frihedsrettigheder gennemfører den dataansvarlige og databehandleren passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til risikoen

her er en liste over de mest almindelige tekniske og organisatoriske foranstaltninger for at sikre beskyttelsen og sikkerheden af dataene i dag:

  • adgangskontrol: Beskyt al fysisk adgang til din server, klient og/eller datarum med nøgler, chipkort, vægge, skabe, alarmer og lignende.
  • minimering: sørg for, at alle autoriserede parter kun kan få adgang til de data, der specifikt er relateret til deres specifikke opgaver og/eller autorisation uden at få lov til at se noget andet.
  • integritet: Beskyt dine data mod utilsigtet tab, ødelæggelse eller skade ved hjælp af passende modforanstaltninger (brand – /oversvømmelsessensorer, katastrofegendannelse og lignende).
  • pseudonymisering: Udskift brugerrelaterede data med tilfældige, anonyme tekstblokke, så ejeren stadig kan beholde posterne (til statistiske formål) og samtidig fjerne dem fra personlige oplysninger.
  • kryptering i transit: sørg for, at dataene altid overføres ved hjælp af stærke krypteringsstandarder (SSL/TLS-certifikater) og gennem sikre forbindelser: dette gælder også for enhver form for hjemmeside og internetbaseret service, der indeholder formularer, login-skærme, upload/Hent-funktioner og så videre.
  • kryptering i hvile: Beskyt dine lokale datalagringsenheder (inklusive dem, der bruges af servere og desktop & mobile klienter) med en stærk at-rest-krypteringsstandard; sørg for, at de data, der er gemt i SaaS og skybaserede tjenester, også krypteres at-rest.
  • fortrolighed: forhindre uautoriseret eller ulovlig behandling ved at implementere begreber som adskillelse af bekymringer & adskillelse af pligter, håndhævelse af adgangskodepolitikker og så videre.
  • genvindelighed: Sørg for, at alle relevante data er underlagt regelmæssige sikkerhedskopier, og sørg også for regelmæssigt at kontrollere dem for at sikre, at dataene kan hentes.
  • evaluering: Indsend hele systemet til regelmæssige tekniske anmeldelser, tredjepartsrevisioner, vedtage et effektivt sæt sikkerhedsindikatorer og så videre.

i dette indlæg skal vi tale om to af disse tekniske foranstaltninger: kryptering i transit og kryptering i hvile, hvilket efterlader de andre emner til yderligere artikler.

Indledning: de tre faser af digitale Data

den første ting, vi skal gøre, er at opregne, hvor mange “stater” digitale data faktisk kan have, og sørg for at forstå hver enkelt af dem:

  • i hvile: dette er den oprindelige tilstand for alle digitale data: på meget korte vilkår angiver dette de data, der er gemt et sted uden at blive brugt af og/eller overført til nogen (inklusive programmer, tredjeparter, mennesker osv.). Fra lokale harddiske til netværksbundne lagre, fra USB pendrives til mobile enheder, fra systemmapper til databaseservere, er ethvert fysisk og logisk lagringssystem, enhed eller enhed beregnet til at blive brugt til at indeholde data i hvile… i det mindste et stykke tid.
  • i transit: også kendt som “i bevægelse”. Dette er i forhold til de data, der overføres et sted til et andet sted. Det er værd at bemærke, at begrebet “dataoverførsel” kan finde sted mellem et hvilket som helst antal parter, ikke begrænset til kun to (afsenderen og en modtager): for eksempel, når vi overfører en fil fra vores stationære PC til vores bærbare computer ved hjælp af vores LAN, udfører vi dybest set en dataoverførsel, der involverer en enkelt part (os); omvendt, når vi sender en transaktion til en distribueret database, såsom en blockchain, håndhæver vi en dataoverførsel mellem et ubestemt antal parter (hele blockchain-knudepunkterne).
  • i brug: når dataene ikke kun gemmes passivt på en harddisk eller et eksternt lagringsmedie, men behandles af en eller flere applikationer – og derfor i færd med at blive genereret, set, opdateret, tilføjet, slettet osv. – er det meningen at være “i brug”. Det siger sig selv, at data i brug er modtagelige for forskellige former for trusler, afhængigt af hvor det er i systemet, og hvem der er i stand til at få adgang til og/eller bruge det. Imidlertid, kryptering af data i brug er temmelig vanskeligt at trække ud, da det sandsynligvis ville lamme, hindre eller gå ned den applikation, der faktisk får adgang til den: netop af denne grund, den bedste måde at beskytte de anvendte data på er at sikre, at applikationen tager sig af et sådant job ved at vedtage de mest sikre udviklings-og implementeringsmønstre inden for dens kildekode.

summen af de tre udsagn, der er forklaret ovenfor, kaldes “de tre faser af digitale Data”: Nu hvor vi fik kernen i dem, er vi klar til at dykke dybt ned i krypteringsemnerne.

datakryptering i hvile

fra definitionen af “i hvile” ovenfor kan vi let forstå, hvordan denne type data typisk er i en stabil tilstand: den rejser ikke inden for systemet eller netværket, og den handles ikke af nogen applikation eller tredjepart. Det er noget, der har nået en destination, i det mindste midlertidigt.

grunde til at bruge det

hvorfor skal vi endda kryptere disse data? Nå, der er en række gode grunde til at gøre det: lad os se på de mest betydningsfulde.

fysisk tyveri

hvis vores enhed bliver stjålet, vil krypteringen i hvile forhindre tyven i straks at få adgang til vores data. Jo da, det kan stadig forsøge at dekryptere det ved hjælp af brute-force eller andre krypteringsmetoder, men dette er noget, der vil tage en rimelig tid: vi bør bestemt være i stand til at trække adeguate-modforanstaltningerne ud, før det sker, såsom: ændring af kontooplysninger, som han muligvis kan se eller noget bruge via eksisterende adgangskodeadministratorer, login-cookies, e-mail-klienters konti og så videre; spore vores enhed og / eller udstede en “Slet alle data” ved hjælp af vores Google eller Apple remote device management services; og så videre.

logisk tyveri

hvis vores PC, hjemmeside eller e-mail-konto bliver hacket af en ondsindet bruger eller et program, vil kryptering i hvile gøre gerningsmanden ude af stand til at få adgang til vores data – selv når stjålet eller hentet: det er dybest set det samme scenario af fysisk tyveri, bortset fra det er måde mere subtil, fordi de fleste brugere (eller administratorer) vil ikke engang være klar over det.

her er en anden god chance for at huske de fantastiske ord udtalt af John T. Chambers, tidligere administrerende direktør for Cisco, Inc.:

der er to typer virksomheder: dem, der er blevet hacket, og dem, der ikke ved, at de er blevet hacket.

i betragtning af den aktuelle tilstand på internettet i dag og den overdrevne overflod af ondskab og målbare hackingforsøg, kan den samme erklæring siges for enhver slutbruger, der besidder en internetaktiveret enhed: 100% garanteret.

menneskelige fejl

endsige de fysiske og / eller logiske tyverier, der er mange andre scenarier, hvor datakryptering i hvile kunne være en livredder: for eksempel, hvis vi mistede vores smartphone (og nogen finder den); eller hvis vi laver en fejl, mens vi tildeler tilladelser, giver uautoriserede brugere (eller kunder) adgang til filer/mapper/data, de ikke burde være i stand til at se; eller hvis vi glemmer vores lokale pc-eller e-mail-adgangskode i almindeligt syn, hvilket giver alle, der ikke har lyst til at respektere vores privatliv, mulighed for at se på vores ting; og listen kunne fortsætte et stykke tid.

Hvordan kan det hjælpe os

for at opsummere alt det, kunne vi besvare vores tidligere spørgsmål med en enkelt linje ved at sige, at kryptering af vores hviledata kunne hjælpe os med bedre at håndtere et muligt databrud.

det hjælper os ikke med at forhindre, at det sker – hvilket for det meste er en opgave for brandvægge, antivirusser, god praksis og sikkerhedsprotokoller – men vil helt sikkert give os chancen (og tiden) til at opsætte de passende modforanstaltninger, forhåbentlig minimere den samlede skade, der er forårsaget af enhver mulig lækage.

Sådan implementeres det

implementering af en datakryptering ved hvile-sikkerhedsprotokol kan være enten let eller svært, afhængigt af følgende faktorer:

  • hvilke fysiske og logiske datakilder / lagre vi ønsker (eller har) at beskytte: fysiske kilder inkluderer Harddiske, NAS-elementer, smartphones, USB pendrives osv., mens logiske kilder inkluderer lokale eller eksterne databaser, skybaserede aktiver, virtualiserede enheder og så videre;
  • hvem skal have adgang til disse data: MS ord) eller automatiske processer eller tjenester (såsom en natlig backup opgave);
  • hvor meget vi er villige til at ofre med hensyn til den samlede ydeevne og/eller nem adgang for at øge sikkerheden: kan vi bede alle vores lokale (og eksterne) brugere om at dekryptere disse data, før de kan få adgang til dem? Skal vi bruge en adgangskode, et fysisk token eller en OTP-kode? Kan vi gøre krypteringen gennemsigtig nok til ikke at hindre vores eksterne brugere og også til at tillade vores apps og værktøjer til at håndtere de krypterede data, når de skal håndtere det?

heldigvis er disse faktorer velkendte af de fleste at-rest krypteringsværktøjer, som er designet til at beskytte vores data uden at gå på kompromis med den overordnede funktionalitet i vores miljø:

  • hvis vi ønsker at kryptere fysiske (eller logiske) harddiske, kan vi bruge fantastiske programværktøjer som VeraCrypt (100% gratis) eller Accrypt (gratis version tilgængelig);
  • hvis vi har brug for at beskytte vores USB-pendrives, kan vi enten bruge de førnævnte værktøjer eller købe et maskinkrypteret flashdrev, der implementerer fingeraftryksbaserede eller adgangskodebaserede oplåsningsmekanismer (startende fra 20~30 bukke);
  • hvis vi gerne vil kryptere de data, der er gemt i et databasestyringssystem, leverer de fleste af de tilgængelige DBMS i dag native krypteringsteknikker (InnoDB tablespace-kryptering til;
  • hvis vi leder efter en måde at gemme vores e-mail-meddelelser sikkert på, kan vi let vedtage en sikker e-mail-krypteringsstandard som S/MIME eller PGP (begge er gratis): selvom disse protokoller for det meste er relateret til kryptering under transit, da de beskytter data, der for det meste er beregnet til at blive overført til eksterne parter, bruges de faktisk ofte til at udføre en kryptering på klientsiden, hvilket betyder, at de beskytter e-mail-meddelelserne, mens de stadig er i ro. Det er overflødigt at sige, da disse meddelelser sandsynligvis vil blive sendt, skal vores destination(er) også vedtage den samme standard for at kunne læse dem.

datakryptering i transit

som navnet antyder, skal data i transit ses meget som en transmissionsstrøm: et godt eksempel på data i transit er en typisk hjemmeside, vi modtager fra internettet, når vi surfer på nettet. Her er hvad der sker under hætten i et nøddeskal:

  1. vi sender en HTTP (eller HTTPS) anmodning til serveren hosting hjemmesiden vi besøger.
  2. serveren accepterer vores anmodning, behandler den ved at finde det (statiske eller dynamiske) indhold, vi har bedt om, og sender det derefter til os som et HTTP (eller HTTPS) svar over en given TCP-port (normalt 80 for HTTP og 443 for HTTPS).
  3. vores klient, som regel en Google Chrome, modtager HTTP(S) svaret, gemmer det på sin interne cache og viser det til os.

som vi kan se, er der klart en datatrasmission mellem serveren og klienten: under denne trasmission bliver de ønskede data (HTML-koden på hjemmesiden) en strøm, der går gennem mindst fem forskellige tilstande:

  1. det starter ved-rest (serverlagring),
  2. derefter ændres til i brug (internetserverhukommelse),
  3. derefter til i transit (ved hjælp af Hypertekstoverførselsprotokollen på en given TCP-port),
  4. derefter igen til i brug (internetserverhukommelse),
  5. og endelig til at-rest (klientcache).

grunde til at bruge det

lad os nu tage for givet, at både serveren og klienten har implementeret et stærkt niveau af datakryptering i hvile: det betyder, at den første og den femte tilstand er internt sikker, fordi ethvert indbrudsforsøg ville blive gjort mod krypterede data. Den tredje stat – hvor dataene er i transit-kan dog være krypteret eller ej, afhængigt af den protokol, serveren og klienten faktisk bruger til at overføre dataene.

her er hvad der normalt sker under hætten, når HTTP-protokollen bruges:

kryptering i transit og kryptering i hvile-definitioner og bedste praksis

som vi kan se, er sikkerhedsproblemet ganske tydeligt: når internetserveren behandler den indgående anmodning og gennemsigtigt dekrypterer de anmodede data, er den kanal, der bruges til at overføre den til internetklienten (HTTP), ikke krypteret: derfor kan enhver krænkende part, der med succes formår at trække et passende angreb (se nedenfor), have øjeblikkelig adgang til vores ukrypterede data .

Hvordan kan det hjælpe os

hvis du er nysgerrig efter, hvilken slags angreb der kan bruges mod en ukrypteret TCP-baseret transmissionsprotokol som HTTP, her er et par trusler, du skal være opmærksom på:

  • aflytning: et netværkslagangreb, der fokuserer på at fange små pakker fra netværket, der transmitteres af andre computere og læse dataindholdet på jagt efter enhver form for information (Mere info her).
  • mand i midten: et manipulationsbaseret angreb, hvor angriberen hemmeligt relæer og/eller ændrer kommunikationen mellem to parter for at få dem til at tro, at de kommunikerer direkte med hinanden (mere info her).

implementering af korrekte krypteringsprotokoller under transit for at sikre vores kritiske dataoverførselsendepunkter vil helt sikkert hjælpe os med at forhindre denne slags trusler.

Sådan implementeres det

implementering af et effektivt krypteringsmønster under transit er for det meste et spørgsmål om at holde sig til en bredt kendt række anbefalinger og bedste praksis, mens man designer den faktiske dataoverførsel: hvilke protokoller der skal (ikke) bruges, hvilket program der skal (ikke) vedtages osv. For eksempel:

  • når den transmitterende enhed er tilgængelig via internetgrænseflade, bør internettrafik kun overføres via Secure Sockets Layer (SSL) ved hjælp af stærke sikkerhedsprotokoller såsom Transport Layer Security (TLS): dette gælder for enhver hjemmeside og / eller service, der kan nås, herunder e-mail-servere og lignende. Fra i dag er den bedste (og nemmeste) måde at implementere TLS-sikkerhed og implementere kryptering i transit for enhver hjemmeside ved at opnå et SSL/TLS HTTPS-certifikat: de kan enten købes hos registrerede ca-myndigheder (Comodo, GlobalSign, GoDaddy, DigiCert og deres enorme forhandlere/subsellers liste) eller automatisk genereret gennem en selvsigneringsproces, som vi kort forklarede i dette indlæg. Selvom selvsignerede certifikater giver det samme krypteringsniveau for deres CA-signerede kolleger, vil de generelt ikke være tillid til af brugerne, da deres bro.ser-klienter ikke vil være i stand til at verificere god tro på udstederens identitet (dig) og markere din hjemmeside som “usikker”: netop af denne grund bør de kun bruges på ikke-produktion (eller ikke-offentligt tilgængelige) server/tjenester.
  • alle data, der overføres via e-mail, skal sikres ved hjælp af kryptografisk stærke e-mail-krypteringsværktøjer som S/MIME eller PGP, som vi allerede dækkede, da vi talte om datakryptering i hvile: selvom disse protokoller udfører deres kryptering på klientniveau (og derfor i hvile), er de også gode til at beskytte den asynkrone transitstrøm af en e-mail-besked.
  • alle binære data skal krypteres ved hjælp af korrekte filkrypteringsværktøjer, før de vedhæftes til e-mail og/eller overføres på anden måde. De fleste komprimeringsprotokoller, inklusive lynlås, RAR og 7C, understøtter et anstændigt niveau af adgangskodebeskyttet kryptering i dag: brug af dem er ofte en fantastisk måde at tilføje et ekstra sikkerhedsniveau og reducere vedhæftningsstørrelsen på samme tid
  • ikke-internetoverførsel af tekst og/eller binære data skal også krypteres via applikationsniveaukryptering under hensyntagen til følgende scenarier:
    • hvis applikationsdatabasen befinder sig uden for applikationsserveren, skal forbindelsen mellem databasen og applikationen krypteres ved hjælp af FIPS-kompatible kryptografiske algoritmer.
    • når applikationsniveaukryptering ikke er tilgængelig, skal du implementere netværksniveaukryptering såsom IPSec eller SSH-tunneling og/eller sikre, at selve transmissionen udføres ved hjælp af autoriserede enheder, der fungerer inden for beskyttede undernet med stærke brandvægskontroller (VPN og lignende).

følgende tabel viser nogle eksempler på de usikre netværksprotokoller, du skal undgå, og deres sikre kolleger, du skal bruge 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

end-to-end kryptering

kryptering i transit er virkelig nyttigt, men det har en stor begrænsning: det garanterer ikke, at dataene krypteres ved udgangspunktet og ikke dekrypteres, før de er i brug. Med andre ord kan vores data stadig være forudgået af lejlighedsvise og / eller ondsindede aflyttere, herunder internetudbydere, kommunikationstjenesteudbydere og hvem der kunne få adgang til de kryptografiske nøgler, der var nødvendige for at dekryptere dataene under transit.

det er muligt at overvinde en sådan begrænsning takket være Ende-til-ende – kryptering (E2EE), et kommunikationsparadigme, hvor kun de kommunikerende slutpartier – for eksempel brugerne-kan dekryptere og derfor læse meddelelserne. End-to-end krypterede data krypteres, før de overføres og forbliver krypterede, indtil de modtages af slutpartiet.

grunde til at bruge det

for bedre at forstå, hvordan end-to-end kryptering superseeds in-transit kryptering med hensyn til modstandsdygtighed over for aflyttere, lad os forestille os følgende scenarier.

  1. Antag, at en tredjepart formår at plante deres eget rodcertifikat på en betroet certifikatmyndighed: en sådan handling kunne teoretisk udføres af en statsaktør, en polititjeneste eller endda en ondsindet/ødelagt operatør af en certifikatmyndighed. Enhver, der er i stand til at gøre dette, kunne med succes drive et Man-in-the-middle-angreb på selve TLS-forbindelsen, aflytte samtalen og muligvis endda manipulere med den. End-to-end krypterede data er naturligt modstandsdygtige over for denne form for angreb, fordi krypteringen ikke udføres på serverniveau.
  2. end-to-end-kryptering kan også øge beskyttelsesniveauet blandt de brugerprocesser, der er skabt af et operativsystem. Kan du huske de seneste CPU fejl kaldet SPECTRE og nedsmeltning? Begge tillod en ondsindet tredjepart (såsom en useriøs proces) at læse hukommelsesdata uden at være autoriseret til at gøre det. Ende-til-ende-kryptering kan undgå et sådant scenario, så længe krypteringen udføres mellem brugerprocessen (i modsætning til kernen), hvilket forhindrer, at ukrypterede data sættes i hukommelsen.

hvordan det kan hjælpe os

end-to-end kryptering er den mest sikre form for kommunikation, der kan bruges i dag, da det sikrer, at kun dig og den person, du kommunikerer med, kan læse, hvad der sendes, og ingen imellem, ikke engang den service, der rent faktisk udfører transmissionen mellem jævnaldrende. Forskellige ende-til-ende kryptering implementeringer er allerede effektive på de fleste messaging apps og tjenester (herunder. I en typisk “kommunikationsapp” – scenarie er meddelelserne sikret med en lås, og kun afsenderen og modtageren har den specielle nøgle, der er nødvendig for at låse op og læse dem: for ekstra beskyttelse sendes hver besked automatisk med sin egen unikke lås og nøgle.

Sådan implementeres det

end-to-end-kryptering kan bruges til at beskytte alt: fra chatbeskeder, filer, fotos, sensoriske data på IoT-enheder, permanente eller midlertidige data. Vi kan vælge, hvilke data vi vil ende-til-ende kryptere. For eksempel vil vi måske beholde godartede oplysninger relateret til en ChatApp (som tidsstempler) i almindelig tekst, men end-to-end krypterer meddelelsesindholdet.

  • hver bruger har en privat & offentlig nøgle, som programmet skal generere på brugerens enhed Ved tilmelding eller næste gang de logger ind.
  • brugerens offentlige nøgle offentliggøres på et offentligt sted (såsom en REST-baseret nøgleadministrationstjeneste): dette er nødvendigt for, at brugerne kan finde hinandens offentlige nøgler og være i stand til at kryptere data til hinanden.
  • brugerens private nøgle forbliver på brugerens enhed, beskyttet af operativsystemets native key store (eller andre sikre butikker).
  • før du sender en chatbesked eller deler et dokument, krypterer appen indholdet ved hjælp af modtagerens offentlige nøgle (klientsiden).

konklusion

vores rejse gennem de forskellige krypteringsparadigmer er afsluttet: Vi håber inderligt, at denne oversigt vil hjælpe brugere og systemadministratorer med at øge deres bevidsthed om de forskellige typer kryptering, der er tilgængelige i dag.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.

lg