Etter hvert som verden blir mer og mer datadrevet, er sikker håndtering av brukerdata mer kritisk enn noen gang.
Som utviklere er jobbene våre vanskelige nok allerede: å håndtere svært komplekse og skjøre systemer med flere feilpunkter, mens vi oversetter svivende menneskelige ønsker til brukergrensesnitt og backends. Å legge til oppgaven er en ny og viktig vurdering: datasikkerhet. Og av en god grunn: vi som kunder er rasende hvis dataene våre blir misbrukt (så det er bare rettferdig at vi gir brukerne våre en sikker og hyggelig opplevelse), og myndigheter og virksomheter krever det for overholdelse.
Innholdsfortegnelse
Datasikkerhet som passerer pengene
Det som gjør sikkerheten vanskeligere er at den har flere lag og blir alles-ansvar-er-ingens-ansvar-tingen. I et moderne skyteam kontrollerer flere team direkte inn-/utgang av data: utviklere, databaseadministratorer, sysadmins (DevOps-folk, om du vil), privilegerte back-office-brukere, og så videre. Disse rollene/teamene kan raskt lukke øynene og tenke på datasikkerhet som de andres problem. Realiteten er likevel at de har sine egne verdener å ta vare på ettersom en databaseadministrator ikke kan kontrollere appsiden av sikkerhet, en DevOps-person kan absolutt ikke gjøre noe med backoffice-tilgangen, og så videre.
Utviklere og datasikkerhet
Alt som er sagt, utviklere har det største tilgangsarealet når det kommer til data: de bygger alle deler av appen; de kobler til ulike backend-tjenester; fergetilgangssymbolene frem og tilbake; de har hele databaseklyngen å lese/skrive fra på deres kommando; appene de skriver har ubestridt tilgang til alle deler av systemet (for eksempel har en Django-app i produksjon alle rettighetene til å dumpe eller slette hele S3-samlingen de siste ti årene), og så videre. Som et resultat er den høyeste sjansen for slurv eller tilsyn når det gjelder sikkerhet, på kildekodenivå og er utviklerens direkte ansvar.
Nå er datasikkerhet et bunnløst kaninhull, og det er ingen måte jeg kan skrape på overflaten i et enkelt innlegg. Imidlertid vil jeg dekke den essensielle terminologien som utviklere må kjenne til for å holde appene sine sikre. Tenk på det som App Data Security 101.
La oss komme i gang!
Hashing
Hvis du vil ha en svært streng definisjon, er det alltid det Wikipedia, men på en enkel måte er hashing prosessen med å konvertere data til en annen form, hvor informasjonen er uleselig. For eksempel ved å bruke den velkjente (og veldig usikre) prosessen med Base64-koding, strengen «Er min hemmelighet trygg hos deg?» kan konverteres («hashed») til «SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/». Hvis du begynner å skrive din personlige dagbok i Base64-format, for eksempel, er det ingen måte familien din kan lese hemmelighetene dine (med mindre de vet hvordan de skal dekode fra Base64)!
Denne ideen om å kryptere dataene brukes når du lagrer passord, kredittkortnumre osv. i nettapper (egentlig bør den brukes i alle typer apper). Tanken er selvfølgelig at i tilfelle et datainnbrudd skal angriperen ikke kunne bruke passordene, kredittkortnumrene osv. for å gjøre faktisk skade. Svært robuste og sofistikerte algoritmer brukes til å utføre denne hasingen; noe sånt som Base64 vil være en spøk og vil bli brutt umiddelbart av enhver angriper.
Passordhashing bruker en kryptografisk teknikk kjent som enveis hashing, som betyr at selv om det er mulig å kryptere dataene, er det ikke mulig å dekryptere dem. Hvordan vet så appen at det er passordet ditt når du logger på? Vel, den bruker den samme prosessen og sammenligner den krypterte formen til det du nettopp skrev inn som passord med den krypterte formen som er lagret i databasen; Hvis de samsvarer, har du lov til å logge inn!
Mens vi er inne på temaet hash, her er noe interessant. Hvis du noen gang laster ned programvare eller filer fra Internett, kan det hende du har blitt bedt om å bekrefte filene før du bruker dem. For eksempel, hvis du vil laste ned Ubuntu Linux ISO, vil nedlastingssiden vise deg et alternativ for å bekrefte nedlastingen din; hvis du klikker på den, åpnes en popup:
Popup-vinduet forteller deg å kjøre en kommando, som i hovedsak kommer til å hash hele filen du nettopp lastet ned og sammenligne resultatet med hash-strengen du ser på nedlastingssiden: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e18419246f71d. Denne konverteringen utføres ved hjelp av SHA256 algoritmehvis omtale du kan se i de siste delene av kommandoen: shasum -a 256 -sjekk.
Ideen er at hvis hashen produsert gjennom sjekken din er annerledes, betyr dette at noen har blandet seg inn i nedlastingen din og gitt deg en kompromittert fil i stedet.
Noen kjente navn du vil høre i domenet for passordhashing er MD5 (usikker og nå nedlagt), SHA-1 og SHA-2 (familier av algoritmer, som SHA-256 er medlem av, det samme er SHA-512), SCRYPT, BCRYPT, etc.
Salting
Alle typer sikkerhet er et katt-og-mus-spill: tyven lærer det gjeldende systemet og kommer opp med en ny sprekk, som blir lagt merke til, og låsemakerne forbedrer spillet sitt, og så videre og så videre. Kryptografi er intet unntak. Mens konvertering av hashes tilbake til passord har blitt umulig, har angripere over tid utviklet sofistikerte teknikker som kombinerer intelligent gjetting med ren regnekraft; som et resultat, ni ganger av ti, kan de forutsi riktig passord, gitt bare hashen.
«MR. Rumpelstiltskinn, antar jeg?!»
Som et resultat har teknikken for salting utviklet seg. Alt det betyr er at hash-beregningen av et passord (eller data) vil bli gjort basert på en kombinasjon av to ting: selve dataene, samt en ny tilfeldig streng som angriperen ikke kan gjette. Så, med salting, hvis vi ønsker å hash passordet superman009, vil vi først velge en tilfeldig streng som en «salt», for eksempel bCQC6Z2LlbAsqj77 og deretter utføre hash-beregningen på superman009-bCQC6Z2LlbAsqj77. Den resulterende hasjen vil avvike fra de vanlige strukturene som produseres av algoritmen, noe som reduserer muligheten for intelligent omvendt utvikling eller gjetting betraktelig.
Både Hashing og Salting er utrolig kompliserte domener og utvikles hele tiden. Så, som applikasjonsutvikler, ville vi aldri forholde oss direkte til dem. Men det ville hjelpe oss veldig hvis vi visste disse og kunne ta bedre beslutninger. For eksempel, hvis du vedlikeholder et gammelt PHP-rammeverk og tilfeldigvis ser at det bruker MD5-hasher for passord, vet du at det er på tide å sette inn et nytt passordbibliotek i prosessen for opprettelse av brukerkontoer.
Nøkler
Du vil ofte komme over begrepet «nøkler» i forbindelse med kryptering. Så langt har vi dekket passordhashing eller enveiskryptering, hvor vi konverterer dataene irreversibelt og ødelegger den opprinnelige formen. Dette er en dårlig idé for daglig bruk – et dokument skrevet og sendt på e-post så sikkert at det aldri kan leses, er til ingen nytte! Dermed ønsker vi å kryptere data slik at vi ønsker at informasjonen skal være åpen hos avsender og mottaker, men mens den overføres eller mens den lagres, skal den være uleselig.
For dette eksisterer konseptet med en «nøkkel» i kryptografi. Det er akkurat det det høres ut som: nøkkelen til en lås. Personen som eier informasjonen forvrider den ved å bruke en hemmelighet kalt en nøkkel. Med mindre mottakeren/angriperen har denne nøkkelen, er det umulig å dekryptere dataene, uansett hvor sofistikerte algoritmene deres kan være.
Roterende taster
Mens nøkler gjør kryptering mulig og pålitelig, har de risikoen som passord gjør: når noen kjenner nøkkelen, er hele spillet oppe. Se for deg et scenario der noen hacker en del av en tjeneste som GitHub (selv om det er noen sekunder) og kan få tak i koden som er 20 år gammel. Inne i koden finner de også de kryptografiske nøklene som brukes til å kryptere selskapets data (forferdelig praksis for å lagre nøkler sammen med kildekoden, men du vil bli overrasket over hvor ofte dette skjer!). Hvis selskapet ikke har tatt seg bryet med å endre nøklene sine (akkurat som passord), kan den samme nøkkelen brukes til å herje.
Som et resultat har praksisen med å skifte nøkler ofte utviklet seg. Dette kalles nøkkelrotasjon, og hvis du bruker en respektabel sky PaaS-leverandør, bør den være tilgjengelig som en automatisert tjeneste.
Bildekreditt: AWS
For eksempel har AWS en dedikert tjeneste for dette kalt AWS Key Management Service (KMS). En automatisert tjeneste sparer deg for bryet med å endre og distribuere nøkler mellom alle serverne og er en no-brainer i disse dager når det kommer til store distribusjoner.
Offentlig nøkkelkryptering
Hvis alt det tidligere snakket om kryptering og nøkler får deg til å synes det er svært tungvint, har du rett. Å oppbevare nøkler trygt og gi dem slik at bare mottakeren kan se dataene, støter på logistiske problemer som ikke ville ha tillatt dagens sikre kommunikasjon å blomstre. Men alt takket være kryptografi med offentlig nøkkel, kan vi trygt kommunisere eller foreta kjøp online.
Denne typen kryptografi var et stort matematisk gjennombrudd, og det er den eneste grunnen til at Internett ikke faller fra hverandre i frykt og mistillit. De detaljer om algoritmen er intrikate og svært matematiske, så jeg kan bare forklare det konseptuelt her.
Bildekreditt: The Electronic Frontier Foundation
Offentlig nøkkelkryptering er avhengig av bruk av to nøkler for å behandle informasjon. En av nøklene kalles Private Key og skal forbli privat med deg og aldri deles med noen; den andre heter Public Key (hvor navnet på metoden kommer fra) og er ment å bli publisert offentlig. Hvis jeg sender data til deg, må jeg først hente den offentlige nøkkelen din og kryptere dataene og sende dem til deg. på slutten kan du dekryptere dataene ved å bruke din private nøkkel og offentlige nøkkelkombinasjon. Så lenge du ikke ved et uhell avslører din private nøkkel, kan jeg sende krypterte data til deg som bare du kan åpne.
Det fine med systemet er at jeg ikke trenger å kjenne din private nøkkel, og alle som fanger opp meldingen kan ikke gjøre noe for å lese den selv om de har den offentlige nøkkelen din. Hvis du lurer på hvordan dette i det hele tatt er mulig, kommer det korteste og mest ikke-tekniske svaret fra egenskapene til multiplikasjon av primtall:
Det er vanskelig for datamaskiner å faktorisere store primtall. Så hvis den opprinnelige nøkkelen er veldig stor, kan du være sikker på at meldingen ikke kan dekrypteres selv om tusenvis av år.
Transport Layer Security (TLS)
Du vet nå hvordan offentlig nøkkelkryptering fungerer. Denne mekanismen (å kjenne mottakerens offentlige nøkkel og sende dem data kryptert med den) er det som ligger bak all HTTPS-populariteten og er det som får Chrome til å si: «Dette nettstedet er sikkert». Det som skjer er at serveren og nettleseren krypterer HTTP-trafikk (husk at nettsider er veldig lange tekststrenger som nettlesere kan tolke) med hverandres offentlige nøkler, noe som resulterer i Secure HTTP (HTTPS).
Bildekreditt: MozillaDet er interessant å merke seg at krypteringen ikke skjer på transportlaget som sådan; de OSI-modell sier ingenting om kryptering av data. Det er bare at data blir kryptert av applikasjonen (i dette tilfellet nettleseren) før den blir overlevert til Transport Layer, som senere slipper den av på destinasjonen, hvor den dekrypteres. Prosessen involverer imidlertid transportlaget, og til syvende og sist resulterer det hele i sikker transport av data, så det løse begrepet «transport» lagsikkerhet har holdt seg fast.
Du kan til og med komme over begrepet Secure Socket Layer (SSL) i noen tilfeller. Det er det samme konseptet som TLS, bortsett fra at SSL oppsto mye før og nå er solnedgang til fordel for TLS.
Full diskkryptering
Noen ganger er sikkerhetsbehovene så intense at ingenting kan overlates til tilfeldighetene. For eksempel kan offentlige servere der alle biometriske data for et land er lagret ikke klargjøres og kjøres som vanlige applikasjonsservere da risikoen er for høy. Det er ikke nok for disse behovene at data kun krypteres når de overføres; den må også være kryptert når den er i ro. For dette brukes full diskkryptering for å kryptere hele en harddisk for å sikre at data er sikre selv når de brytes fysisk.
Det er viktig å merke seg at full diskkryptering må gjøres på maskinvarenivå. Det er slik fordi hvis vi krypterer hele disken, er operativsystemet også kryptert og kan ikke kjøre når maskinen starter. Så, maskinvaren må forstå at diskinnholdet er kryptert og må utføre dekryptering på farten når den sender forespurte diskblokker til operativsystemet. På grunn av dette ekstra arbeidet som gjøres, resulterer Full Disk Encryption i tregere lesing/skriving, noe som må huskes av utviklerne av slike systemer.
Ende-til-ende-kryptering
Med de pågående personvern- og sikkerhetsmarerittene til store sosiale nettverk i disse dager, er ingen uvitende om begrepet «ende-til-ende-kryptering», selv om de ikke har noe å gjøre med å lage eller vedlikeholde apper.
Vi så tidligere hvordan Full Disk Encryption gir den ultimate skuddsikre strategien, men for den daglige brukeren er det ikke praktisk. Jeg mener, forestill deg at Facebook vil at telefondataene den genererer og lagrer i telefonen din skal være sikre, men den kan ikke ha tilgang til å kryptere hele telefonen og låse ute alt annet i prosessen.
Av denne grunn har disse selskapene startet ende-til-ende-kryptering, som betyr at data blir kryptert når de opprettes, lagres eller overføres av appen. Med andre ord, selv når dataene når mottakeren, er de fullstendig kryptert og er kun tilgjengelig for mottakerens telefon.
Bildekreditt: Google
Merk at ende-til-ende (E2E)-kryptering ikke har noen matematiske garantier som offentlig nøkkelkryptering gjør; det er bare standard kryptering der nøkkelen lagres hos bedriften, og meldingene dine er så sikre som bedriften bestemmer.
Konklusjon 👩🏫
Du har sannsynligvis hørt om de fleste av disse begrepene allerede. Kanskje til og med alle sammen. I så fall vil jeg oppfordre deg til å revidere forståelsen din av disse konseptene, samt utføre en evaluering av hvor seriøst du tar dem. Husk at appdatasikkerhet er en krig du må vinne hver gang (og ikke bare én gang), siden selv et enkelt brudd er nok til å ødelegge hele bransjer, karrierer og til og med liv!