S tím, jak se svět stále více řídí daty, je bezpečné zacházení s uživatelskými daty důležitější než kdy jindy.
Jako vývojáři jsou naše práce již dost těžké: vypořádat se s vysoce složitými a křehkými systémy s mnoha body selhání, zatímco převádíme poletující lidská přání do uživatelských rozhraní a backendů. K tomuto úkolu se přidává nová a zásadní úvaha: bezpečnost dat. A to z dobrého důvodu: my jako zákazníci jsme rozzuřeni, pokud jsou naše data zneužita (takže je spravedlivé, že našim uživatelům poskytujeme bezpečný a příjemný zážitek), a vlády a podniky to vyžadují, aby byly v souladu.
Table of Contents
Zabezpečení dat jako neúspěch
Zabezpečení je těžší, protože má několik vrstev a stává se věcí, za kterou nese odpovědnost každý. V moderním cloudovém týmu více týmů přímo řídí vstup/výstup dat: vývojáři, správci databází, sysadmins (lidé z DevOps, chcete-li), privilegovaní uživatelé back-office a tak dále. Tyto role/týmy mohou rychle zavřít oči a považovat zabezpečení dat za problém ostatních. Realita je však taková, že mají své vlastní světy, o které se musí postarat, protože správce databáze nemůže ovládat zabezpečení aplikace, osoba DevOps nemůže dělat absolutně nic s přístupem do back office a tak dále.
Vývojáři a bezpečnost dat
Vše, co bylo řečeno, vývojáři mají největší plochu přístupu, pokud jde o data: vytvářejí každou část aplikace; připojují se k různým backendovým službám; žetony přístupu k trajektu tam a zpět; mají celý databázový cluster ke čtení/zápisu na jejich příkaz; aplikace, které píší, mají nezpochybnitelný přístup ke všem částem systému (například produkční aplikace Django má všechna oprávnění vypsat nebo vymazat celou kolekci S3 za posledních deset let) a tak dále. Výsledkem je, že největší šance na nedbalost nebo přehlédnutí z hlediska zabezpečení existuje na úrovni zdrojového kódu a je přímou odpovědností vývojáře.
Zabezpečení dat je nyní bezedná králičí nora a neexistuje způsob, jak bych mohl poškrábat povrch v jediném příspěvku. Chci však pokrýt základní terminologii, kterou musí vývojáři znát, aby udrželi své aplikace v bezpečí. Představte si to jako App Data Security 101.
Začněme!
Hašování
Pokud chcete velmi přesnou definici, vždy existuje Wikipedie, ale zjednodušeně řečeno, hashování je proces převodu dat do jiné formy, kde jsou informace nečitelné. Například pomocí známého (a velmi nejistého) procesu Base64 kódování, řetězec „Je moje tajemství u vás v bezpečí?“ lze převést („hašovat“) na „SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/“. Pokud si například začnete psát svůj osobní deník ve formátu Base64, vaše rodina nemůže číst vaše tajemství (pokud neví, jak je dekódovat z Base64)!
Tato myšlenka zakódování dat se používá při ukládání hesel, čísel kreditních karet atd. ve webových aplikacích (ve skutečnosti by se měla používat ve všech typech aplikací). Myšlenka je samozřejmě taková, že v případě úniku dat by útočník neměl být schopen použít hesla, čísla kreditních karet atd. ke skutečnému poškození. K provádění tohoto hašování se používají vysoce robustní a sofistikované algoritmy; něco jako Base64 bude vtip a každý útočník to okamžitě rozbije.
Hašování hesel používá kryptografickou techniku známou jako jednosměrné hašování, což znamená, že i když je možné data zakódovat, není možné je dekódovat. Jak potom aplikace při přihlášení pozná, že je to vaše heslo? No, používá stejný proces a porovnává zakódovanou formu toho, co jste právě zadali jako heslo, se zakódovanou formou uloženou v databázi; pokud se shodují, můžete se přihlásit!
Když už jsme u tématu hashů, tady je něco zajímavého. Pokud jste někdy stáhli software nebo soubory z internetu, možná vám bylo řečeno, abyste je před použitím ověřili. Pokud si například chcete stáhnout ISO Ubuntu Linux, stránka stahování vám zobrazí možnost ověření vašeho stažení; pokud na něj kliknete, otevře se vyskakovací okno:
Vyskakovací okno vám řekne, abyste spustili příkaz, který v podstatě zahašuje celý soubor, který jste právě stáhli, a porovná výsledek s hashovacím řetězcem, který vidíte na stránce stahování: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f571db46 Tato konverze se provádí pomocí Algoritmus SHA256jehož zmínku můžete vidět v závěrečných částech příkazu: shasum -a 256 –check.
Myšlenka je taková, že pokud je hash vytvořený vaší kontrolou jiný, znamená to, že se někdo vměšoval do vašeho stahování a místo toho vám dodal kompromitovaný soubor.
Některá známá jména, která uslyšíte v doméně hašování hesel, jsou MD5 (nezabezpečené a nyní nefunkční), SHA-1 a SHA-2 (rodiny algoritmů, kterých je SHA-256 členem, stejně jako SHA-512), SCRYPT, BCRYPT atd.
Solení
Všechny typy zabezpečení jsou hra na kočku a myš: zloděj se naučí současný systém a přijde s novým crackem, kterého si všimnou, a výrobci zámků vylepší svou hru a tak dále a tak dále. Kryptografie není výjimkou. Zatímco převádění hashů zpět na hesla se stalo nemožným, útočníci postupem času vyvinuli sofistikované techniky, které kombinují inteligentní odhady s naprostým výpočetním výkonem; výsledkem je, že devětkrát z deseti dokážou předpovědět správné heslo, pouze s pomocí hash.
„Pan. Rumpelstiltskin, předpokládám?!“
V důsledku toho se vyvinula technika solení. Znamená to pouze, že výpočet hash hesla (nebo jakýchkoli dat) bude proveden na základě kombinace dvou věcí: samotných dat a také nového náhodného řetězce, který útočník nemůže uhodnout. Pokud tedy chceme při saltingu zahašovat heslo superman009, nejprve bychom jako „sůl“ vybrali náhodný řetězec, řekněme bCQC6Z2LlbAsqj77a pak provedli výpočet hash na superman009-bCQC6Z2LlbAsqj77. Výsledný hash se bude odchylovat od obvyklých struktur vytvořených algoritmem, čímž se výrazně sníží prostor pro inteligentní reverzní inženýrství nebo hádání.
Hašování i solení jsou neuvěřitelně komplikované domény a neustále se vyvíjejí. Takže jako vývojáři aplikací bychom s nimi nikdy nejednali přímo. Ale velmi by nám pomohlo, kdybychom to věděli a mohli se lépe rozhodovat. Pokud například udržujete starý framework PHP a náhodou zjistíte, že pro hesla používá hash MD5, víte, že je čas vložit do procesu vytváření uživatelského účtu další knihovnu hesel.
Klíče
S pojmem „klíče“ byste se často setkali v souvislosti se šifrováním. Doposud jsme se zabývali hashováním hesel nebo jednosměrným šifrováním, kdy data nenávratně převedeme a původní podobu zničíme. Pro každodenní praktické použití je to špatný nápad – dokument napsaný a zaslaný e-mailem tak bezpečně, že jej nelze nikdy přečíst, je k ničemu! Chceme tedy šifrovat data tak, že chceme, aby informace byly otevřené u odesílatele a příjemce, ale během přenosu nebo ukládání by měly být nečitelné.
Za tímto účelem v kryptografii existuje koncept „klíče“. Přesně tak to zní: klíč od zámku. Osoba, která informace vlastní, je zašifruje pomocí nějakého tajemství zvaného klíč. Pokud příjemce/útočník nemá tento klíč, není možné dešifrovat data, bez ohledu na to, jak sofistikované mohou být jejich algoritmy.
Otočné klávesy
Klíče sice šifrování umožňují a jsou spolehlivé, ale nesou rizika, která mají hesla: jakmile někdo zná klíč, celá hra je v provozu. Představte si scénář, ve kterém někdo hackne nějakou část služby jako GitHub (i když na pár sekund) a může získat kód starý 20 let. Uvnitř kódu najdou také kryptografické klíče používané k šifrování firemních dat (strašná praxe ukládat klíče spolu se zdrojovým kódem, ale divili byste se, jak často se to stává!). Pokud se společnost neobtěžovala změnit své klíče (stejně jako hesla), lze stejný klíč použít k rozpoutání zmatku.
V důsledku toho se praxe časté výměny klíčů vyvinula. Tomu se říká střídání klíčů a pokud používáte jakéhokoli seriózního poskytovatele cloudového PaaS, mělo by to být dostupné jako automatizovaná služba.
Obrazový kredit: AWS
Například AWS má pro to vyhrazenou službu s názvem Služba správy klíčů AWS (KMS). Automatizovaná služba vám ušetří námahu se změnou a distribucí klíčů mezi všechny servery a je v dnešní době samozřejmostí, pokud jde o velká nasazení.
Kryptografie veřejného klíče
Pokud vás všechny předchozí řeči o šifrování a klíčích nutí myslet si, že je to velmi těžkopádné, máte pravdu. Uchovávání klíčů v bezpečí a jejich předávání tak, aby data viděl pouze příjemce, naráží na logistické problémy, které by dnešní zabezpečené komunikaci neumožnily prosperovat. Ale to vše díky kryptografii s veřejným klíčem můžeme bezpečně komunikovat nebo nakupovat online.
Tento typ kryptografie byl velkým matematickým průlomem a je to jediný důvod, proč se internet nerozpadá ve strachu a nedůvěře. The podrobnosti o algoritmu jsou složité a vysoce matematické, takže to zde mohu vysvětlit pouze koncepčně.
Obrazový kredit: The Electronic Frontier Foundation
Šifrování veřejného klíče se opírá o použití dvou klíčů ke zpracování informací. Jeden z klíčů se nazývá Soukromý klíč a předpokládá se, že zůstane soukromý a nikdy nebude s nikým sdílen; druhý se nazývá Public Key (odkud pochází název metody) a má být zveřejněn. Pokud vám posílám data, musím nejprve získat váš veřejný klíč, zašifrovat data a poslat vám je; na vašem konci můžete dešifrovat data pomocí kombinace soukromého a veřejného klíče. Pokud náhodou neprozradíte svůj soukromý klíč, mohu vám poslat zašifrovaná data, která můžete otevřít pouze vy.
Krása systému spočívá v tom, že nepotřebuji znát váš soukromý klíč a kdokoli, kdo zachytí zprávu, nemůže nic udělat, aby si ji přečetl, i když má váš veřejný klíč. Pokud se ptáte, jak je to vůbec možné, nejkratší a nejnetechnickější odpověď pochází z vlastností násobení prvočísel:
Pro počítače je těžké faktorizovat velká prvočísla. Pokud je tedy původní klíč velmi velký, můžete si být jisti, že zprávu nelze dešifrovat ani za tisíce let.
Transport Layer Security (TLS)
Nyní víte, jak funguje kryptografie s veřejným klíčem. Tento mechanismus (znát veřejný klíč příjemce a posílat mu pomocí něj zašifrovaná data) je to, co stojí za veškerou popularitou HTTPS a je to, co způsobuje, že Chrome říká: „Tento web je bezpečný.“ Dochází k tomu, že server a prohlížeč šifrují HTTP provoz (pamatujte, že webové stránky jsou velmi dlouhé řetězce textu, které prohlížeče dokážou interpretovat) pomocí svých veřejných klíčů, což vede k zabezpečenému HTTP (HTTPS).
Obrazový kredit: MozillaJe zajímavé poznamenat, že k šifrování nedochází na transportní vrstvě jako takové; a OSI model neříká nic o šifrování dat. Jde jen o to, že data jsou zašifrována aplikací (v tomto případě prohlížečem), než jsou předána transportní vrstvě, která je později odloží na místo určení, kde jsou dešifrována. Tento proces však zahrnuje transportní vrstvu a na konci dne to vše vede k bezpečnému přenosu dat, takže volný termín „transportní“ vrstva zabezpečení zůstal.
V některých případech se dokonce můžete setkat s pojmem Secure Socket Layer (SSL). Je to stejný koncept jako TLS, kromě toho, že SSL vzniklo mnohem dříve a nyní je zrušeno ve prospěch TLS.
Úplné šifrování disku
Někdy jsou potřeby zabezpečení tak intenzivní, že nelze nic ponechat náhodě. Například vládní servery, kde jsou uložena všechna biometrická data země, nelze zřídit a provozovat jako běžné aplikační servery, protože riziko je příliš vysoké. Pro tyto potřeby nestačí, aby byla data šifrována pouze při přenosu; musí být zašifrován i v klidu. K tomuto účelu se používá úplné šifrování disku k zašifrování celého pevného disku, aby byla zajištěna bezpečnost dat i při fyzickém narušení.
Je důležité si uvědomit, že úplné šifrování disku musí být provedeno na hardwarové úrovni. Pokud totiž zašifrujeme celý disk, zašifruje se i operační systém a při startu stroje se nespustí. Hardware tedy musí chápat, že obsah disku je zašifrován a musí provádět dešifrování za běhu, když předává požadované bloky disku operačnímu systému. Kvůli této práci navíc má Full Disk Encryption za následek pomalejší čtení/zápis, což musí mít vývojáři takových systémů na paměti.
End-to-End šifrování
S neustálými nočními můrami velkých sociálních sítí v oblasti soukromí a bezpečnosti si v dnešní době nikdo neuvědomuje pojem „šifrování end-to-end“, i když nemá nic společného s vytvářením nebo údržbou aplikací.
Již dříve jsme viděli, jak Full Disk Encryption poskytuje dokonalou neprůstřelnou strategii, ale pro běžného uživatele to není pohodlné. Chci říct, představte si, že Facebook chce, aby data telefonu, která generuje a ukládá ve vašem telefonu, byla v bezpečí, ale nemůže mít přístup k zašifrování celého telefonu a uzamknutí všeho ostatního v tomto procesu.
Z tohoto důvodu tyto společnosti zahájily šifrování typu end-to-end, což znamená, že data jsou šifrována, když je aplikace vytváří, ukládá nebo přenáší. Jinými slovy, i když se data dostanou k příjemci, jsou plně zašifrována a jsou přístupná pouze z telefonu příjemce.
Kredit obrázku: Google
Všimněte si, že šifrování End-to-End (E2E) nenese žádné matematické záruky jako šifrování veřejného klíče; je to jen standardní šifrování, kde je klíč uložen u firmy a vaše zprávy jsou tak bezpečné, jak se firma rozhodne.
Závěr 👩🏫
O většině těchto termínů jste již pravděpodobně slyšeli. Možná dokonce všechny. Pokud ano, doporučuji vám, abyste přehodnotili své chápání těchto pojmů a také provedli hodnocení toho, jak vážně je berete. Pamatujte, že zabezpečení dat aplikací je válka, kterou musíte vyhrát pokaždé (a ne jen jednou), protože i jediné narušení stačí ke zničení celého odvětví, kariéry a dokonce i životů!