I takt med att världen blir mer och mer datadriven är säker hantering av användardata viktigare än någonsin.
Som utvecklare är våra jobb redan tillräckligt svåra: att hantera mycket komplexa och ömtåliga system med flera felpunkter samtidigt som vi översätter svängande mänskliga önskemål till användargränssnitt och backends. Att lägga till uppgiften är ett framväxande och viktigt övervägande: datasäkerhet. Och av goda skäl: vi som kunder blir arga om vår data missbrukas (så det är bara rättvist att vi ger våra användare en säker och njutbar upplevelse), och regeringar och företag kräver det för efterlevnad.
Innehållsförteckning
Datasäkerhet som att lösa pengar
Det som gör säkerheten svårare är att den har flera lager och blir det som är allas-ansvar-är-ingens-ansvar. I ett modernt molnteam kontrollerar flera team direkt ingången/utgången av data: utvecklare, databasadministratörer, sysadmins (DevOps-folk, om du så vill), privilegierade backoffice-användare och så vidare. Dessa roller/team kan snabbt blunda och tänka på datasäkerhet som de andras problem. Ändå är verkligheten att de har sina egna världar att ta hand om eftersom en databasadministratör inte kan kontrollera appsidan av säkerheten, en DevOps-person kan absolut ingenting göra åt backoffice-åtkomsten och så vidare.
Utvecklare och datasäkerhet
Allt som sagt, utvecklare har den största åtkomstytan när det kommer till data: de bygger varje del av appen; de ansluter till olika backend-tjänster; färjans tillträdespoletter fram och tillbaka; de har hela databasklustret att läsa/skriva från på deras kommando; apparna de skriver har obestridd tillgång till alla delar av systemet (till exempel har en Django-app i produktion alla privilegier att dumpa eller radera hela S3-samlingen från de senaste tio åren) och så vidare. Som ett resultat av detta finns den högsta chansen för slarv eller förbiseende vad gäller säkerhet på källkodsnivå och är utvecklarens direkta ansvar.
Nu är datasäkerhet ett bottenlöst kaninhål, och det finns inget sätt att jag ens kan skrapa ytan i ett enda inlägg. Jag vill dock täcka den väsentliga terminologin som utvecklare måste känna till för att hålla sina appar säkra. Se det som App Data Security 101.
Låt oss börja!
Hashing
Om du vill ha en mycket rigorös definition finns det alltid Wikipedia, men enkelt uttryckt är hash processen att konvertera data till en annan form, där informationen är oläsbar. Till exempel att använda den välkända (och mycket osäkra) processen med Base64-kodning, strängen ”Är min hemlighet säker hos dig?” kan konverteras (”hashat”) till ”SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/”. Om du till exempel börjar skriva din personliga dagbok i Base64-format, kan din familj inte läsa dina hemligheter (såvida de inte vet hur man avkodar från Base64)!
Den här idén att förvränga data används vid lagring av lösenord, kreditkortsnummer, etc. i webbappar (egentligen borde den användas i alla typer av appar). Tanken är förstås att i händelse av ett dataintrång ska angriparen inte kunna använda lösenorden, kreditkortsnumren etc. för att göra faktisk skada. Mycket robusta och sofistikerade algoritmer används för att utföra denna hash; något som Base64 kommer att vara ett skämt och kommer att brytas omedelbart av alla angripare.
Lösenordshashing använder en kryptografisk teknik som kallas envägshashing, vilket innebär att även om det är möjligt att kryptera data, är det inte möjligt att avkoda den. Hur vet då appen att det är ditt lösenord när du loggar in? Tja, den använder samma process och jämför den kodade formen av det du just angav som lösenord med den kodade formen som lagras i databasen; om de matchar får du logga in!
Medan vi är inne på ämnet hash, här är något intressant. Om du någon gång laddar ner programvara eller filer från Internet kan du ha blivit tillsagd att verifiera filerna innan du använder dem. Till exempel, om du vill ladda ner Ubuntu Linux ISO, kommer nedladdningssidan att visa dig ett alternativ för att verifiera din nedladdning; om du klickar på den öppnas en popup:
Popup-fönstret talar om för dig att köra ett kommando, som i huvudsak kommer att hasha hela filen du just laddade ner och jämföra resultatet med hashsträngen du ser på nedladdningssidan: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e18419246b5d. Denna konvertering utförs med hjälp av SHA256 algoritmvars omnämnande du kan se i de sista delarna av kommandot: shasum -a 256 –check.
Tanken är att om hashen som produceras genom din check är annorlunda betyder det att någon har blandat sig i din nedladdning och försett dig med en komprometterad fil istället.
Några välbekanta namn du kommer att höra i domänen för lösenordshashing är MD5 (osäker och nu nedlagd), SHA-1 och SHA-2 (familjer av algoritmer, där SHA-256 är medlem, liksom SHA-512), SCRYPT, BCRYPT, etc.
Saltning
Alla typer av säkerhet är ett katt-och-råtta-spel: tjuven lär sig det nuvarande systemet och kommer med en ny spricka, som uppmärksammas, och låstillverkarna förbättrar sitt spel, och så vidare och så vidare. Kryptografi är inget undantag. Även om det har blivit omöjligt att konvertera hash till lösenord, har angripare över tid utvecklat sofistikerade tekniker som kombinerar intelligent gissning med ren beräkningskraft; som ett resultat, nio gånger tio gånger, kan de förutsäga det korrekta lösenordet, givet bara hash.
”Herr. Rumpelstiltskinn, antar jag?!”
Som ett resultat har tekniken för saltning utvecklats. Allt det betyder är att hashberäkningen av ett lösenord (eller vilken data som helst) kommer att göras baserat på en kombination av två saker: själva data, samt en ny slumpmässig sträng som angriparen inte kan gissa. Så, med saltning, om vi vill hasha lösenordet superman009, skulle vi först välja en slumpmässig sträng som ”salt”, säg, bCQC6Z2LlbAsqj77 och sedan utföra hashberäkningen på superman009-bCQC6Z2LlbAsqj77. Den resulterande hashen kommer att avvika från de vanliga strukturerna som produceras av algoritmen, vilket avsevärt minskar utrymmet för intelligent reverse engineering eller gissningar.
Både Hashing och Salting är otroligt komplicerade domäner och utvecklas ständigt. Så som applikationsutvecklare skulle vi aldrig ha att göra med dem direkt. Men det skulle hjälpa oss mycket om vi kände till dessa och kunde fatta bättre beslut. Om du till exempel underhåller ett gammalt PHP-ramverk och råkar se att det använder MD5-hashar för lösenord, vet du att det är dags att infoga ett annat lösenordsbibliotek i processen för att skapa ett användarkonto.
Nycklar
Du stöter ofta på termen ”nycklar” i samband med kryptering. Hittills har vi täckt lösenordshashing eller envägskryptering, där vi konverterar data oåterkalleligt och förstör den ursprungliga formen. Detta är en dålig idé för dagligt praktiskt bruk – ett dokument skrivet och e-postat så säkert att det aldrig kan läsas är till ingen nytta! Vi vill alltså kryptera data så att vi vill att informationen ska vara öppen hos avsändaren och mottagaren, men när den överförs eller lagras ska den vara oläsbar.
För detta finns begreppet ”nyckel” i kryptografi. Det är precis vad det låter som: nyckeln till ett lås. Personen som äger informationen förvränger den med hjälp av någon hemlighet som kallas nyckel. Om inte mottagaren/angriparen har den här nyckeln är det omöjligt att avkoda data, oavsett hur sofistikerade deras algoritmer kan vara.
Roterande tangenter
Även om nycklar gör kryptering möjlig och pålitlig, har de riskerna med lösenord: när någon väl känner till nyckeln är hela spelet uppe. Föreställ dig ett scenario där någon hackar någon del av en tjänst som GitHub (även om det är för några sekunder) och kan få tag på koden som är 20 år gammal. Inuti koden hittar de också de kryptografiska nycklarna som används för att kryptera företagets data (hemsk praxis att lagra nycklar tillsammans med källkod, men du skulle bli förvånad över hur ofta detta händer!). Om företaget inte har brytt sig om att ändra sina nycklar (precis som lösenord) kan samma nyckel användas för att skapa förödelse.
Som ett resultat har metoden att byta nycklar ofta utvecklats. Detta kallas nyckelrotation, och om du använder någon respektabel moln PaaS-leverantör bör den vara tillgänglig som en automatiserad tjänst.
Bildkredit: AWS
Till exempel har AWS en dedikerad tjänst för detta som kallas AWS Key Management Service (KMS). En automatiserad tjänst sparar dig besväret med att ändra och distribuera nycklar mellan alla servrar och är en no-brainer nuförtiden när det kommer till stora distributioner.
Public Key Kryptografi
Om allt tidigare snack om kryptering och nycklar får dig att tycka att det är väldigt krångligt så har du rätt. Att förvara nycklar och lämna dem så att endast mottagaren kan se data stöter på logistiska problem som inte skulle ha tillåtit dagens säkra kommunikation att blomstra. Men allt tack vare kryptografi med offentlig nyckel kan vi säkert kommunicera eller göra inköp online.
Denna typ av kryptografi var ett stort matematiskt genombrott, och det är den enda anledningen till att Internet inte faller samman i rädsla och misstro. De detaljer om algoritmen är invecklade och mycket matematiska, så jag kan bara förklara det konceptuellt här.
Bildkredit: The Electronic Frontier Foundation
Public Key Cryptography är beroende av användningen av två nycklar för att bearbeta information. En av nycklarna heter Privat nyckel och är tänkt att förbli privat med dig och aldrig delas med någon; den andra heter Public Key (där namnet på metoden kommer ifrån) och är tänkt att publiceras offentligt. Om jag skickar data till dig måste jag först få din publika nyckel och kryptera data och skicka den till dig; i slutet kan du dekryptera data med din privata nyckel och din publika nyckelkombination. Så länge du inte avslöjar din privata nyckel av misstag kan jag skicka krypterad data till dig som bara du kan öppna.
Det fina med systemet är att jag inte behöver känna till din privata nyckel, och alla som fångar upp meddelandet kan inte göra något för att läsa det trots att de har din publika nyckel. Om du undrar hur detta ens är möjligt, kommer det kortaste och mest icke-tekniska svaret från egenskaperna för multiplikation av primtal:
Det är svårt för datorer att faktorisera stora primtal. Så om den ursprungliga nyckeln är mycket stor kan du vara säker på att meddelandet inte kan dekrypteras ens om tusentals år.
Transport Layer Security (TLS)
Du vet nu hur Public Key Cryptography fungerar. Denna mekanism (att känna till mottagarens publika nyckel och skicka data krypterad med den) är vad som ligger bakom all HTTPS-popularitet och är det som får Chrome att säga ”Den här webbplatsen är säker.” Vad som händer är att servern och webbläsaren krypterar HTTP-trafik (kom ihåg att webbsidor är mycket långa textsträngar som webbläsare kan tolka) med varandras publika nycklar, vilket resulterar i Secure HTTP (HTTPS).
Bildkredit: MozillaDet är intressant att notera att krypteringen inte sker på transportskiktet som sådant; de OSI-modell säger ingenting om kryptering av data. Det är bara det att data krypteras av applikationen (i det här fallet webbläsaren) innan den överlämnas till Transport Layer, som senare släpper av den på sin destination, där den dekrypteras. Processen involverar dock transportskiktet, och i slutet av dagen resulterar allt i säker transport av data, så den lösa termen ”transport” lagersäkerhet har fastnat.
Du kanske till och med stöter på termen Secure Socket Layer (SSL) i vissa fall. Det är samma koncept som TLS, förutom att SSL har sitt ursprung långt tidigare och nu är solnedgången till förmån för TLS.
Full diskkryptering
Ibland är säkerhetsbehoven så intensiva att ingenting kan lämnas åt slumpen. Till exempel kan statliga servrar där all biometrisk data i ett land lagras inte tillhandahållas och köras som vanliga applikationsservrar eftersom risken är för hög. Det räcker inte för dessa behov att data endast krypteras när de överförs; den måste också krypteras när den är i vila. För detta används fullständig diskkryptering för att kryptera hela hårddisken för att säkerställa att data är säkra även när de bryter mot dem fysiskt.
Det är viktigt att notera att Full Disk Encryption måste göras på hårdvarunivå. Det beror på att om vi krypterar hela disken så är operativsystemet också krypterat och kan inte köras när maskinen startar. Så hårdvaran måste förstå att diskinnehållet är krypterat och måste utföra dekryptering i farten när den skickar begärda diskblock till operativsystemet. På grund av detta extra arbete som görs, resulterar Full Disk Encryption i långsammare läsning/skrivning, vilket måste hållas i åtanke av utvecklarna av sådana system.
End-to-end-kryptering
Med de pågående integritets- och säkerhetsmardrömmarna för stora sociala nätverk nuförtiden är ingen omedveten om termen ”end-to-end-kryptering”, även om de inte har något att göra med att skapa eller underhålla appar.
Vi såg tidigare hur Full Disk Encryption ger den ultimata skottsäkra strategin, men för den vanliga användaren är det inte bekvämt. Jag menar, föreställ dig att Facebook vill att telefondatan som den genererar och lagrar i din telefon ska vara säker, men den kan inte ha tillgång till att kryptera hela din telefon och låsa ut allt annat i processen.
Av denna anledning har dessa företag startat end-to-end-kryptering, vilket innebär att data krypteras när den skapas, lagras eller överförs av appen. Med andra ord, även när informationen når mottagaren är den helt krypterad och endast tillgänglig för mottagarens telefon.
Bildkredit: Google
Observera att end-to-end-kryptering (E2E) inte har några matematiska garantier som kryptografi med offentlig nyckel. det är bara standardkryptering där nyckeln lagras hos företaget, och dina meddelanden är så säkra som företaget bestämmer.
Slutsats 👩🏫
Du har förmodligen redan hört talas om de flesta av dessa termer. Kanske till och med alla. Om så är fallet skulle jag uppmuntra dig att se över din förståelse av dessa begrepp, samt göra en utvärdering av hur seriöst du tar dem. Kom ihåg att appdatasäkerhet är ett krig du måste vinna varje gång (och inte bara en gång), eftersom till och med ett enda brott räcker för att förstöra hela industrier, karriärer och till och med liv!