Ahogy a világ egyre inkább adatközpontúvá válik, a felhasználói adatok biztonságos kezelése fontosabb, mint valaha.
Fejlesztőként a dolgunk már most is elég nehéz: rendkívül összetett és törékeny, több hibaponttal rendelkező rendszerekkel foglalkozni, miközben az emberi kívánságokat felhasználói felületekre és háttérprogramokra fordítjuk. Hozzá kell tenni a feladatot egy kialakulóban lévő és alapvető szempont: az adatbiztonság. És jó okkal: mi, vásárlók, feldühödünk, ha adatainkkal visszaélnek (tehát az igazságos, hogy biztonságos és élvezetes élményt nyújtunk felhasználóinknak), a kormányok és a vállalatok pedig követelik a megfelelést.
Tartalomjegyzék
Az adatbiztonság, mint a felelősség áthárítása
Ami megnehezíti a biztonságot, az az, hogy több rétegből áll, és a mindenki felelőssége-senki felelőssége dologgá válik. Egy modern felhőcsapatban több csapat közvetlenül ellenőrzi az adatok be- és kimenését: fejlesztők, adatbázis-adminisztrátorok, rendszergazdák (ha úgy tetszik, DevOps-emberek), kiváltságos háttér-felhasználók stb. Ezek a szerepkörök/csapatok gyorsan becsukhatják a szemüket, és úgy gondolhatják, hogy az adatbiztonság a többiek problémája. Ennek ellenére a valóság az, hogy megvan a maguk világa, amelyről gondoskodniuk kell, mivel az adatbázis-adminisztrátor nem tudja ellenőrizni a biztonság alkalmazási oldalát, a DevOps-személyek semmit sem tehetnek a háttérirodai hozzáférésről stb.
Fejlesztők és adatbiztonság
Mindazonáltal a fejlesztők rendelkeznek a legnagyobb hozzáférési felülettel az adatok tekintetében: ők építik fel az alkalmazás minden részét; különféle háttérszolgáltatásokhoz csatlakoznak; a komp hozzáférési tokenek oda-vissza; parancsukra a teljes adatbázis-fürtöt olvashatják/írhatják; az általuk írt alkalmazások megkérdőjelezhetetlen hozzáféréssel rendelkeznek a rendszer minden részéhez (például egy éles Django-alkalmazás rendelkezik minden jogosultsággal ahhoz, hogy az elmúlt tíz év teljes S3-gyűjteményét kiírja vagy törölje), és így tovább. Ennek eredményeként a legnagyobb esélye annak, hogy a biztonsági gondatlanság vagy felügyelet a forráskód szintjén áll fenn, és ez a fejlesztő közvetlen felelőssége.
Márpedig az adatbiztonság egy feneketlen nyúllyuk, és semmiképpen sem tudom megkarcolni a felszínt egyetlen bejegyzésben. Szeretnék azonban kitérni azokra a lényeges terminológiákra, amelyeket a fejlesztőknek ismerniük kell alkalmazásaik biztonságának megőrzéséhez. Tekintsd úgy, mint az App Data Security 101.
Kezdjük el!
Kivonatolás
Ha nagyon szigorú definíciót akarsz, akkor mindig van Wikipédia, de leegyszerűsítve a kivonat az a folyamat, amikor az adatokat egy másik formába konvertálják, ahol az információ olvashatatlan. Például a jól ismert (és nagyon nem biztonságos) folyamat használatával Base64 kódolás, a karakterlánc „Biztonságban van veled a titkom?” konvertálható („kivonatolt”) „SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/” formátumra. Ha például elkezdi írni a személyes naplóját Base64 formátumban, akkor a családja nem tudja elolvasni a titkait (hacsak nem tudja, hogyan kell dekódolni a Base64-ből)!
Az adatok titkosításának ezt a gondolatát akkor használják, amikor jelszavakat, hitelkártyaszámokat stb. tárolnak webes alkalmazásokban (valójában minden típusú alkalmazásban használni kell). Az ötlet természetesen az, hogy adatszivárgás esetén a támadó ne tudja használni a jelszavakat, hitelkártyaszámokat stb., hogy tényleges kárt okozzon. A kivonat végrehajtásához rendkívül robusztus és kifinomult algoritmusokat használnak; valami, mint a Base64, egy vicc lesz, és minden támadó azonnal megtöri.
A jelszókivonat az egyirányú kivonatolás néven ismert kriptográfiai technikát alkalmazza, ami azt jelenti, hogy bár lehetséges az adatok kódolása, a kódolás feloldása nem lehetséges. Akkor honnan tudja az alkalmazás, hogy ez az Ön jelszava, amikor bejelentkezik? Nos, ugyanazt a folyamatot használja, és összehasonlítja a jelszóként megadott kódolt formát az adatbázisban tárolt kódolt űrlappal; ha egyeznek, be lehet lépni!
Ha már a hashek témájánál tartunk, itt van valami érdekes. Ha valaha szoftvert vagy fájlokat tölt le az internetről, előfordulhat, hogy a fájlok használata előtt ellenőrizni kellett. Például, ha szeretné letölteni az Ubuntu Linux ISO-t, a letöltési oldalon megjelenik egy lehetőség a letöltés ellenőrzésére; ha rákattint egy felugró ablak nyílik meg:
A felugró ablak azt mondja, hogy futtasson egy parancsot, amely lényegében az imént letöltött teljes fájlt kivonatolja, és az eredményt hasonlítsa össze a letöltési oldalon látható hash karakterlánccal: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924fb71d. Ezt az átalakítást a SHA256 algoritmusamelynek említése a parancs utolsó részében látható: shasum -a 256 –check.
Az ötlet az, hogy ha a csekken keresztül létrehozott hash eltérő, az azt jelenti, hogy valaki beleavatkozott a letöltésbe, és helyette egy kompromittált fájlt adott át Önnek.
Néhány ismerős név, amelyet a jelszókivonat tartományában hallani fog: MD5 (nem biztonságos és mára megszűnt), SHA-1 és SHA-2 (algoritmuscsaládok, amelyeknek az SHA-256 is tagja, akárcsak az SHA-512), SCRYPT, BCRYPT stb.
Sózás
A biztonság minden fajtája macska-egér játék: a tolvaj megtanulja a jelenlegi rendszert, és előáll egy újszerű repedéssel, amelyre felfigyelnek, a zárgyártók pedig fejlesztik a játékukat, és így tovább, és így tovább. Ez alól a kriptográfia sem kivétel. Míg a hash-ek jelszavakká való visszakonvertálása lehetetlenné vált, a támadók idővel kifinomult technikákat fejlesztettek ki, amelyek az intelligens találgatást a puszta számítási teljesítménnyel kombinálják; ennek eredményeként tíznél kilencszer meg tudják jósolni a helyes jelszót, csak a hash alapján.
„Úr. Rumpelstiltskin, gondolom?!”
Ennek eredményeként kialakult a sózás technikája. Ez annyit jelent, hogy a jelszó (vagy bármilyen adat) hash-számítása két dolog kombinációja alapján történik: maga az adat, valamint egy új véletlenszerű karakterlánc, amelyet a támadó nem tud kitalálni. Tehát a sózásnál, ha ki akarjuk hashelni a superman009 jelszót, először válasszunk ki egy véletlenszerű karakterláncot „sóként”, mondjuk a bCQC6Z2LlbAsqj77, majd végezzük el a hash számítását a superman009-bCQC6Z2LlbAsqj77-en. Az eredményül kapott hash el fog térni az algoritmus által létrehozott szokásos struktúráktól, jelentősen csökkentve az intelligens visszafejtési vagy találgatási lehetőségeket.
Mind a kivonatolás, mind a sózás hihetetlenül bonyolult terület, és folyamatosan fejlődik. Így alkalmazásfejlesztőként soha nem foglalkoztunk velük közvetlenül. De nagy segítségünkre lenne, ha tudnánk ezeket, és jobb döntéseket tudnánk hozni. Például, ha egy régi PHP keretrendszert karbantart, és azt látja, hogy az MD5 kivonatokat használ a jelszavakhoz, akkor tudja, hogy itt az ideje egy másik jelszókönyvtárat beilleszteni a felhasználói fiók létrehozási folyamatába.
Kulcsok
Gyakran találkozhat a „kulcsok” kifejezéssel a titkosítással összefüggésben. Eddig a jelszavas kivonatolásról vagy egyirányú titkosításról volt szó, ahol visszafordíthatatlanul konvertáljuk az adatokat, és megsemmisítjük az eredeti formát. Ez egy rossz ötlet a mindennapi gyakorlati használatra – az olyan biztonságosan írt és e-mailben elküldött dokumentum, hogy soha nem olvasható, nem használ! Így az adatokat úgy akarjuk titkosítani, hogy az információ nyitva legyen a feladóval és a fogadóval, de az átvitel vagy tárolás közben olvashatatlan legyen.
Ehhez létezik a „kulcs” fogalma a kriptográfiában. Pontosan így hangzik: a zár kulcsa. Az információ birtokosa egy kulcsnak nevezett titok segítségével kódolja azt. Hacsak a fogadó/támadó nem rendelkezik ezzel a kulccsal, lehetetlen az adatok kódolása, függetlenül attól, hogy milyen kifinomultak az algoritmusaik.
Forgó billentyűk
Míg a kulcsok lehetővé teszik és megbízhatóvá teszik a titkosítást, a jelszavak kockázatát hordozzák magukban: ha valaki ismeri a kulcsot, az egész játék készen áll. Képzeljünk el egy forgatókönyvet, amelyben valaki feltöri egy szolgáltatás, például a GitHub egy részét (még ha néhány másodpercre is), és megszerezheti a 20 éves kódot. A kódon belül megtalálják a cég adatainak titkosításához használt kriptográfiai kulcsokat is (borzalmas gyakorlat a kulcsokat a forráskóddal együtt tárolni, de meglepődne, milyen gyakran történik ez!). Ha a vállalat nem vette a fáradságot a kulcsok megváltoztatásával (csakúgy, mint a jelszavak), ugyanaz a kulcs felhasználható pusztításra.
Ennek eredményeként a kulcsok gyakori cseréjének gyakorlata fejlődött. Ezt hívják kulcsrotációnak, és ha bármilyen tekintélyes felhőalapú PaaS-szolgáltatót használ, akkor automatizált szolgáltatásként elérhetőnek kell lennie.
A kép jóváírása: AWS
Például az AWS-nek erre a célra egy dedikált szolgáltatása van AWS Key Management Service (KMS). Az automatizált szolgáltatás megkíméli Önt a kulcsok cseréjével és az összes kiszolgáló között való elosztásával járó fáradságtól, és manapság semmi gond, ha nagy telepítésekről van szó.
Nyilvános kulcsú kriptográfia
Ha a titkosításról és a kulcsokról szóló korábbi beszédek miatt azt gondolja, hogy ez rendkívül nehézkes, akkor igaza van. A kulcsok biztonságban tartása és átadása, hogy csak a fogadó lássa az adatokat, olyan logisztikai problémákba ütközik, amelyek nem tették volna lehetővé a mai biztonságos kommunikáció virágzását. De mindezt a nyilvános kulcsú kriptográfiának köszönhetően biztonságosan kommunikálhatunk vagy vásárolhatunk online.
Ez a fajta kriptográfia jelentős matematikai áttörést jelentett, és ez az egyetlen oka annak, hogy az Internet nem esik szét a félelemtől és a bizalmatlanságtól. Az az algoritmus részletei bonyolultak és erősen matematikaiak, ezért itt csak fogalmilag tudom elmagyarázni.
A kép jóváírása: The Electronic Frontier Foundation
A nyilvános kulcsú kriptográfia két kulcs használatán alapul az információk feldolgozásához. Az egyik kulcs neve Private Key, és állítólag magánjellegű marad, és soha nem osztják meg senkivel; a másikat Public Key-nek hívják (ahonnan a metódus neve is származik), és állítólag nyilvánosan közzé kell tenni. Ha adatokat küldök Önnek, először meg kell szereznem a nyilvános kulcsát, titkosítanom kell az adatokat, és el kell küldenem Önnek; a végén visszafejtheti az adatokat a privát kulcs és a nyilvános kulcs kombinációjával. Mindaddig, amíg véletlenül nem fedi fel a privát kulcsát, titkosított adatokat küldhetek neked, amelyeket csak te tudsz megnyitni.
A rendszer szépsége abban rejlik, hogy nem kell tudnom az Ön privát kulcsát, és bárki, aki elkapja az üzenetet, semmit sem tehet annak elolvasása érdekében, noha rendelkezik a nyilvános kulcsával. Ha azon töpreng, hogyan lehetséges ez, a legrövidebb és legnem technikaibb válasz a prímszámok szorzásának tulajdonságaiból származik:
A számítógépek számára nehéz nagy prímszámokat faktorizálni. Tehát, ha az eredeti kulcs nagyon nagy, akkor biztos lehet benne, hogy az üzenetet még több ezer év múlva sem lehet visszafejteni.
Transport Layer Security (TLS)
Most már tudja, hogyan működik a nyilvános kulcsú kriptográfia. Ez a mechanizmus (a fogadó nyilvános kulcsának ismerete és ezzel titkosított adatok elküldése) az, ami a HTTPS népszerűségének hátterében áll, és ez az oka annak, hogy a Chrome azt mondja: „Ez a webhely biztonságos”. Az történik, hogy a szerver és a böngésző egymás nyilvános kulcsaival titkosítja a HTTP-forgalmat (ne feledje, a weboldalak nagyon hosszú szövegsorok, amelyeket a böngészők értelmezni tudnak), ami a biztonságos HTTP-t (HTTPS) eredményezi.
Kép jóváírása: MozillaÉrdekes megjegyezni, hogy a titkosítás nem a szállítási rétegen megy végbe; az OSI modell semmit nem mond az adatok titkosításáról. Csupán arról van szó, hogy az adatokat az alkalmazás (jelen esetben a böngésző) titkosítja, mielőtt átadná a szállítási rétegnek, amely később leadja azokat a rendeltetési helyére, ahol visszafejtik. A folyamat azonban magában foglalja a szállítási réteget, és a nap végén mindez az adatok biztonságos szállítását eredményezi, így a laza „szállítási” réteg biztonság fogalma megmaradt.
Bizonyos esetekben még a Secure Socket Layer (SSL) kifejezéssel is találkozhat. Ez ugyanaz, mint a TLS, kivéve, hogy az SSL sokkal korábban keletkezett, és mára megszűnt a TLS javára.
Teljes lemeztitkosítás
Néha a biztonsági igények olyan intenzívek, hogy semmit sem lehet a véletlenre bízni. Például az olyan kormányzati szervereket, amelyeken egy ország összes biometrikus adata tárolják, nem lehet kiépíteni és nem futtatni úgy, mint a normál alkalmazásszervereket, mivel a kockázat túl magas. Ezekhez az igényekhez nem elég, hogy az adatok csak átvitelkor legyenek titkosítva; nyugalmi állapotban is titkosítani kell. Ehhez a teljes merevlemez titkosítását használják a teljes merevlemez titkosítására, hogy az adatok biztonsága még fizikai sérülés esetén is biztonságos legyen.
Fontos megjegyezni, hogy a teljes lemeztitkosítást hardver szinten kell végrehajtani. Ez azért van így, mert ha a teljes lemezt titkosítjuk, akkor az operációs rendszer is titkosítva lesz, és nem tud futni, amikor a gép elindul. Tehát a hardvernek meg kell értenie, hogy a lemez tartalma titkosított, és a visszafejtést menet közben kell végrehajtania, miközben átadja a kért lemezblokkokat az operációs rendszernek. Az elvégzett többletmunka miatt a Full Disk Encryption lassabb olvasást/írást eredményez, amit az ilyen rendszerek fejlesztőinek szem előtt kell tartaniuk.
Végpontok közötti titkosítás
Napjainkban a nagy közösségi hálózatok folyamatos adatvédelmi és biztonsági rémálmai miatt senki sem ismeri a „végpontok közötti titkosítás” kifejezést, még akkor sem, ha semmi köze nincs alkalmazások készítéséhez vagy karbantartásához.
Korábban láttuk, hogy a Full Disk Encryption a tökéletes golyóálló stratégiát nyújtja, de a mindennapi felhasználók számára ez nem kényelmes. Úgy értem, képzelje el, hogy a Facebook azt szeretné, ha az általa generált és a telefonon tárolt telefonadatok biztonságosak lennének, de nem férhet hozzá a teljes telefon titkosításához, és a folyamatban lévő összes többi zárolásához.
Emiatt ezek a vállalatok megkezdték a végpontok közötti titkosítást, ami azt jelenti, hogy az adatok titkosításra kerülnek, amikor azokat az alkalmazás létrehozza, tárolja vagy továbbítja. Más szóval, még akkor is, ha az adatok megérkeznek a címzetthez, azok teljesen titkosítottak, és csak a címzett telefonján érhetők el.
Kép jóváírása: Google
Vegye figyelembe, hogy a végponttól végpontig (E2E) titkosítás nem vállal semmilyen matematikai garanciát, mint a nyilvános kulcsú titkosítás; ez csak egy szabványos titkosítás, ahol a kulcsot a vállalkozásnál tárolják, és üzenetei olyan biztonságban vannak, ahogyan a vállalkozás dönt.
Következtetés 👩🏫
Valószínűleg már hallott a legtöbb ilyen kifejezésről. Talán még mindegyik. Ha igen, akkor azt javasolnám, hogy gondolja át újra a fogalmakat, és értékelje, mennyire veszi komolyan ezeket a fogalmakat. Ne feledje, hogy az alkalmazások adatbiztonsága egy háború, amelyet minden alkalommal (és nem csak egyszer) meg kell nyernie, hiszen egyetlen incidens is elegendő egész iparágak, karrierek, sőt életek tönkretételéhez!