I en verden som stadig blir mer datastyrt, har sikker håndtering av brukerdata blitt viktigere enn noen gang før.
Som utviklere har vi allerede en krevende jobb: å administrere svært komplekse og sårbare systemer med mange potensielle feilkilder, samtidig som vi oversetter menneskelige ønsker til brukervennlige grensesnitt og backends. Nå er det kommet en ny, viktig utfordring: datasikkerhet. Og det av god grunn: vi som brukere blir rasende om dataene våre misbrukes (så det er bare rettferdig å tilby brukerne våre en sikker og god opplevelse), og både myndigheter og virksomheter krever det for å overholde lover og regler.
Datasikkerhet – et delt ansvar
Det som gjør sikkerhet komplisert, er at den har mange lag og lett blir en sak der alles ansvar blir ingen sitt ansvar. I et moderne skymiljø er det flere team som direkte kontrollerer inn- og utdata: utviklere, databaseadministratorer, systemadministratorer (DevOps-folk om du vil), privilegerte backoffice-brukere osv. Disse rollene/teamene kan lett lukke øynene og se på datasikkerhet som et problem for andre. Realiteten er imidlertid at hver av dem har sine egne ansvarsområder, da en databaseadministrator ikke kan kontrollere sikkerheten på applikasjonssiden, en DevOps-person kan ikke gjøre noe med backoffice-tilgangen og så videre.
Utviklere og datasikkerhet
Når det er sagt, har utviklere det største ansvarsområdet når det gjelder tilgang til data: de bygger alle deler av applikasjonen; de kobler seg til ulike backend-tjenester; de håndterer tilgangstokens; de har hele databaseklyngen tilgjengelig for lese-/skriveoperasjoner; appene de skriver har ubegrenset tilgang til alle deler av systemet (for eksempel har en Django-app i produksjon alle rettigheter til å slette eller dumpe hele S3-samlingen fra de siste ti årene) og så videre. Som et resultat er den største risikoen for feil og forsømmelser knyttet til sikkerhet på kildekodenivå, og dette er utviklernes direkte ansvar.
Datasikkerhet er et omfattende tema, og det er umulig å dekke alt i et enkelt innlegg. Derfor vil jeg i stedet fokusere på den grunnleggende terminologien som utviklere må kjenne til for å sikre applikasjonene sine. Se på dette som et grunnkurs i applikasjonsdatasikkerhet.
La oss begynne!
Hashing
For en presis definisjon, kan du alltid sjekke Wikipedia, men enkelt forklart er hashing prosessen med å konvertere data til en annen, uleselig form. For eksempel kan strengen «Er min hemmelighet trygg hos deg?» konverteres («hashet») til «SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/» ved hjelp av den velkjente (og svært usikre) Base64-kodingen. Hvis du begynner å skrive dagboken din i Base64-format, er det ingen mulighet for at familien din kan lese hemmelighetene dine (med mindre de vet hvordan de skal dekode fra Base64)!
Denne ideen om å kryptere data brukes når du lagrer passord, kredittkortnummer osv. i nettapplikasjoner (og egentlig bør det brukes i alle typer apper). Tanken er selvsagt at i tilfelle datainnbrudd, skal ikke angriperen kunne bruke passordene, kredittkortnumrene osv. til å gjøre faktisk skade. Det brukes svært robuste og avanserte algoritmer for å utføre denne hasingen; noe som Base64 ville være en vits og ville bli brutt umiddelbart av enhver angriper.
Passordhashing bruker en kryptografisk teknikk som kalles enveishashing, noe som betyr at selv om det er mulig å kryptere dataene, er det ikke mulig å dekryptere dem. Så hvordan vet appen at det er ditt passord når du logger deg på? Jo, den bruker den samme prosessen og sammenligner den krypterte formen av det du nettopp skrev inn som passord med den krypterte formen som er lagret i databasen. Hvis de samsvarer, får du logge inn!
Mens vi er inne på temaet hashing, her er noe interessant. Hvis du noen gang laster ned programvare eller filer fra Internett, har du kanskje 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 et popup-vindu:
Popup-vinduet ber deg om å kjøre en kommando, som i hovedsak hasher hele filen du nettopp lastet ned og sammenligner resultatet med hash-strengen du ser på nedlastingssiden: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e18419246f71d. Denne konverteringen utføres ved hjelp av SHA256-algoritmen, som du kan se referert til i de siste delene av kommandoen: shasum -a 256 -check.
Tanken er at hvis hashen som genereres ved sjekken din er annerledes, betyr det at noen har tuklet med nedlastingen din og gitt deg en kompromittert fil i stedet.
Noen kjente navn du vil høre i passordhashing-domenet er MD5 (usikker og nå avskaffet), SHA-1 og SHA-2 (familier av algoritmer, der SHA-256 er et medlem, det samme er SHA-512), SCRYPT, BCRYPT osv.
Salting
All sikkerhet er en katt-og-mus-lek: tyven lærer seg det nåværende systemet og finner en ny svakhet, som blir oppdaget, og låsesmedene forbedrer sitt spill, og så videre. Kryptografi er ikke noe unntak. Mens det har blitt umulig å konvertere hasher tilbake til passord, har angripere over tid utviklet avanserte teknikker som kombinerer smart gjetning med ren regnekraft. Som et resultat, kan de i ni av ti tilfeller gjette det riktige passordet, bare ved å ha hashen.
«Herr Rumpelstiltskin, antar jeg?!»
Derfor har teknikken med 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, og en ny, tilfeldig streng som angriperen ikke kan gjette. Så, med salting, hvis vi ønsker å hashe passordet superman009, vil vi først velge en tilfeldig streng som et «salt», for eksempel bCQC6Z2LlbAsqj77, og deretter utføre hash-beregningen på superman009-bCQC6Z2LlbAsqj77. Den resulterende hashen vil avvike fra de vanlige strukturene som algoritmen produserer, noe som reduserer muligheten for intelligent omvendt utvikling eller gjetning betydelig.
Både hashing og salting er utrolig komplekse områder som stadig utvikler seg. Som applikasjonsutvikler vil vi aldri forholde oss direkte til dem. Men det vil hjelpe oss mye å kjenne til disse konseptene for å ta bedre avgjørelser. 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 å innføre et nytt passordbibliotek i prosessen for opprettelse av brukerkontoer.
Nøkler
Du vil ofte støte på begrepet «nøkler» i forbindelse med kryptering. Så langt har vi dekket passordhashing eller enveiskryptering, der 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! Derfor vil vi kryptere data slik at informasjonen skal være tilgjengelig for avsender og mottaker, men være uleselig under overføring eller lagring.
For dette finnes 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, forvrenger den ved å bruke en hemmelighet som kalles en nøkkel. Med mindre mottakeren/angriperen har denne nøkkelen, er det umulig å dekryptere dataene, uansett hvor avanserte algoritmene deres måtte være.
Nøkkelrotasjon
Selv om nøkler muliggjør pålitelig kryptering, har de samme risiko som passord: når noen kjenner nøkkelen, er spillet over. Se for deg et scenario der noen hacker en del av en tjeneste som GitHub (selv om det bare er for noen sekunder) og får tak i 20 år gammel kode. Inne i koden finner de også de kryptografiske nøklene som brukes til å kryptere selskapets data (en forferdelig praksis å lagre nøkler sammen med kildekoden, men du vil bli overrasket over hvor ofte dette skjer!). Hvis selskapet ikke har gjort seg bryet med å endre nøklene (akkurat som passord), kan den samme nøkkelen brukes til å gjøre stor skade.
Som et resultat har praksisen med å bytte nøkler ofte utviklet seg. Dette kalles nøkkelrotasjon, og hvis du bruker en anerkjent 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 det er et opplagt valg for store utplasseringer i dag.
Offentlig nøkkelkryptografi
Hvis alt det forrige snakket om kryptering og nøkler virker tungvint, har du rett. Å oppbevare nøkler trygt og gi dem slik at bare mottakeren kan se dataene, gir logistiske problemer som ikke ville ha gjort dagens sikre kommunikasjon mulig. Men takket være kryptografi med offentlig nøkkel, kan vi trygt kommunisere eller foreta kjøp på nettet.
Denne typen kryptografi var et stort matematisk gjennombrudd, og det er grunnen til at Internett ikke faller fra hverandre i frykt og mistillit. Detaljene i algoritmen er kompliserte og svært matematiske, så jeg kan bare forklare det konseptuelt her.
Bildekreditt: The Electronic Frontier Foundation
Kryptografi med offentlig nøkkel er avhengig av bruk av to nøkler for å behandle informasjon. En av nøklene kalles Privat nøkkel og skal holdes privat og aldri deles med noen; den andre heter Offentlig nøkkel (der navnet på metoden kommer fra) og er ment å publiseres offentlig. Hvis jeg sender data til deg, må jeg først hente din offentlige nøkkel og kryptere dataene før jeg sender dem til deg. Til slutt kan du dekryptere dataene ved å bruke din private nøkkel og den offentlige nøkkelen i kombinasjon. Så lenge du ikke avslører din private nøkkel ved et uhell, 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 avlytter meldingen kan ikke lese den selv om de har din offentlige nøkkel. Hvis du lurer på hvordan dette er mulig i det hele tatt, er det korteste og mest ikke-tekniske svaret knyttet til egenskapene ved 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 det tar tusenvis av år.
Transport Layer Security (TLS)
Nå vet du hvordan offentlig nøkkelkryptografi fungerer. Denne mekanismen (å kjenne mottakerens offentlige nøkkel og sende dem data kryptert med den) er det som ligger bak all HTTPS-popularitet 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; OSI-modellen sier ingenting om kryptering av data. Det er bare at data krypteres av applikasjonen (i dette tilfellet nettleseren) før de overføres til transportlaget, som senere leverer dem til destinasjonen, hvor de dekrypteres. Prosessen involverer imidlertid transportlaget, og til syvende og sist resulterer det i sikker transport av data, så det løse begrepet «transportlags»-sikkerhet har blitt etablert.
Du kan også støte på begrepet Secure Socket Layer (SSL) i noen tilfeller. Det er det samme konseptet som TLS, bortsett fra at SSL oppsto mye tidligere og nå fases ut til fordel for TLS.
Full diskkryptering
Noen ganger er sikkerhetsbehovene så store at ingenting kan overlates til tilfeldighetene. For eksempel kan offentlige servere der all biometrisk data for et land er lagret, ikke settes opp og kjøres som vanlige applikasjonsservere, da risikoen er for høy. For disse behovene er det ikke nok at data kun krypteres under overføring; de må også være krypterte når de lagres. For dette brukes full diskkryptering for å kryptere hele harddisken for å sikre at dataene er beskyttet selv om de blir fysisk kompromittert.
Det er viktig å merke seg at full diskkryptering må gjøres på maskinvarenivå. Dette er fordi hvis vi krypterer hele disken, er også operativsystemet kryptert og kan ikke kjøre når maskinen starter. Derfor må maskinvaren forstå at diskinnholdet er kryptert, og må dekryptere innholdet fortløpende når den sender forespurte diskblokker til operativsystemet. På grunn av dette ekstra arbeidet som gjøres, resulterer full diskkryptering i tregere lese-/skrivehastigheter, noe utviklere av slike systemer må huske på.
Ende-til-ende-kryptering
Med de pågående personvern- og sikkerhetsmarerittene knyttet til store sosiale nettverk i dag, er ingen uvitende om begrepet «ende-til-ende-kryptering», selv om de ikke har noe med utvikling eller vedlikehold av applikasjoner å gjøre.
Vi har tidligere sett hvordan full diskkryptering gir den ultimate skuddsikre strategien, men for den vanlige brukeren er det ikke praktisk. Tenk deg for eksempel at Facebook ønsker at telefondataene de genererer og lagrer på telefonen din skal være sikre, men de kan ikke ha tilgang til å kryptere hele telefonen og utelukke alt annet i prosessen.
Av denne grunn har disse selskapene begynt å bruke ende-til-ende-kryptering, som betyr at data krypteres når de opprettes, lagres eller overføres av appen. Med andre ord, selv når dataene når mottakeren, er de fullstendig krypterte og kun tilgjengelige for mottakerens telefon.
Bildekreditt: Google
Merk at ende-til-ende (E2E)-kryptering ikke har noen matematiske garantier som offentlig nøkkelkryptografi har; det er bare standard kryptering der nøkkelen lagres hos selskapet, og meldingene dine er så sikre som selskapet 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 å revurdere din forståelse av disse konseptene, samt evaluere hvor seriøst du tar dem. Husk at applikasjonsdatasikkerhet er en krig du må vinne hver gang (og ikke bare en gang), siden selv et enkelt brudd er nok til å ødelegge hele bransjer, karrierer og til og med liv!