Како свет постаје све више вођен подацима, безбедно руковање корисничким подацима је критичније него икад.
Као програмери, наши послови су већ довољно тешки: бављење веома сложеним и крхким системима са вишеструким тачкама квара, док ми претварамо покретне људске жеље у корисничко сучеље и позадину. Додатак задатку је ново и суштинско разматрање: безбедност података. И то са добрим разлогом: ми као клијенти смо бесни ако наши подаци буду злоупотребљени (тако да је поштено да нашим корисницима пружимо безбедно и пријатно искуство), а владе и предузећа то захтевају ради усаглашености.
Преглед садржаја
Сигурност података као преношење
Оно што отежава безбедност је то што она има неколико слојева и постаје ствар свачија-одговорност-ничија-одговорност. У савременом клауд тиму, више тимова директно контролише улаз/излаз података: програмери, администратори базе података, сисадмини (ДевОпс људи, ако желите), привилеговани бек-оффице корисници, итд. Ове улоге/тимови могу брзо затворити очи и размишљати о безбедности података као о проблему других. Ипак, реалност је да они имају своје светове о којима треба да воде рачуна јер администратор базе података не може да контролише безбедносну страну апликације, ДевОпс особа не може да уради апсолутно ништа у вези са приступом позадинској канцеларији и тако даље.
Програмери и безбедност података
Све што је речено, програмери имају највећу површину приступа када су у питању подаци: они праве сваки део апликације; повезују се на разне позадинске услуге; токени за приступ трајекту напред-назад; имају цео кластер базе података за читање/писање на њихову команду; апликације које пишу имају неоспоран приступ свим деловима система (на пример, Дјанго апликација у продукцији има све привилегије да избаци или обрише целу С3 колекцију у последњих десет година) и тако даље. Као резултат тога, највећа шанса за аљкавост или надзор у смислу безбедности постоји на нивоу изворног кода и директна је одговорност програмера.
Сада, безбедност података је зечја рупа без дна, и нема шансе да чак и загребем површину у једном посту. Међутим, желим да покријем основну терминологију коју програмери морају да знају да би своје апликације заштитиле. Замислите то као сигурност података апликације 101.
Хајде да почнемо!
Хеширање
Ако желите веома ригорозну дефиницију, увек постоји Википедиа, али једноставним речима, хеширање је процес претварања података у други облик, где су информације нечитљиве. На пример, коришћењем добро познатог (и веома несигурног) процеса Басе64 кодирање, стринг „Да ли је моја тајна сигурна код тебе?“ може се конвертовати („хеширати“) у „СКСМгбКскгц2ВјцмВ0ИХНхЗмУгд2л0аЦБ5б3У/“. Ако почнете да пишете свој лични дневник у Басе64 формату, на пример, нема шансе да ваша породица прочита ваше тајне (осим ако не знају како да декодирају из Басе64)!
Ова идеја шифровања података се користи када се чувају лозинке, бројеви кредитних картица, итд., у веб апликацијама (у ствари, требало би да се користи у свим врстама апликација). Идеја је, наравно, да у случају повреде података, нападач не би требало да буде у могућности да користи лозинке, бројеве кредитних картица, итд., да направи стварну штету. За извођење овог хеширања користе се веома робусни и софистицирани алгоритми; нешто попут Басе64 ће бити шала и сваки нападач ће га одмах разбити.
Хеширање лозинке користи криптографску технику познату као једносмерно хеширање, што значи да иако је могуће шифровати податке, није могуће да их дешифрујете. Како онда апликација зна да је то ваша лозинка када се пријавите? Па, користи исти процес и пореди шифровану форму онога што сте управо унели као лозинку са шифрованом формом ускладиштеном у бази података; ако се поклапају, дозвољено вам је да се пријавите!
Док смо већ на теми хеша, ево нечег занимљивог. Ако икада преузмете софтвер или датотеке са Интернета, можда вам је речено да проверите датотеке пре него што их употребите. На пример, ако желите да преузмете Убунту Линук ИСО, страница за преузимање ће вам показати опцију да потврдите преузимање; ако кликнете на њега, отвориће се искачући прозор:
Искачући прозор вам говори да покренете команду, која ће у суштини хеширати целу датотеку коју сте управо преузели и упоредити резултат са хеш стрингом који видите на страници за преузимање: 5фдебц435дед46ае99136ца875афц6ф05бде217бе7дд018е1841924ф6б71д. Ова конверзија се врши помоћу СХА256 алгоритамчије помињање можете видети у завршним деловима наредбе: схасум -а 256 –цхецк.
Идеја је да ако је хеш произведен вашим чеком другачији, то значи да се неко умешао у ваше преузимање и уместо тога вам дао компромитовану датотеку.
Нека позната имена која ћете чути у домену хеширања лозинки су МД5 (несигурна и сада нефункционална), СХА-1 и СХА-2 (породице алгоритама, чији је члан СХА-256, као и СХА-512), СЦРИПТ, БЦРИПТ итд.
Сољење
Све врсте обезбеђења су игре мачке и миша: лопов учи тренутни систем и долази до новог крека, који се примећује, а произвођачи брава побољшавају своју игру, и тако даље и тако даље. Криптографија није изузетак. Док је претварање хешева назад у лозинке постало немогуће, нападачи су током времена развили софистициране технике које комбинују интелигентно нагађање са чистом рачунарском снагом; као резултат, девет пута од десет, они могу предвидети тачну лозинку, с обзиром на само хеш.
„Господин. Румпелстилтскин, претпостављам?!“
Као резултат тога, развила се техника сољења. Све што то значи је да ће се хеш израчунавање лозинке (или било ког податка) обавити на основу комбинације две ствари: самих података, као и новог насумичног низа који нападач не може да погоди. Дакле, са сољењем, ако желимо да хеширамо лозинку суперман009, прво бисмо изабрали насумични стринг као „сол“, рецимо, бЦКЦ6З2ЛлбАскј77, а затим бисмо извршили хеш израчунавање на суперман009-бЦКЦ6З2ЛлбАскј77. Добијени хеш ће одступити од уобичајених структура које производи алгоритам, значајно смањујући обим за интелигентни обрнути инжењеринг или нагађања.
И хеширање и сољење су невероватно компликовани домени и стално се развијају. Дакле, као програмер апликација, никада се не бисмо директно бавили њима. Али много би нам помогло када бисмо ово знали и могли да доносимо боље одлуке. На пример, ако одржавате стари ПХП оквир и случајно видите да користи МД5 хешове за лозинке, знате да је време да убаците другу библиотеку лозинки у процес креирања корисничког налога.
Кључеви
Често бисте наишли на термин „кључеви“ у контексту шифровања. До сада смо покривали хеширање лозинки или једносмерну енкрипцију, где податке конвертујемо неповратно и уништавамо оригинални образац. Ово је лоша идеја за свакодневну практичну употребу – документ написан и послат е-поштом тако безбедно да се никада не може прочитати није од користи! Дакле, желимо да шифрујемо податке тако да желимо да информације буду отворене код пошиљаоца и примаоца, али док се преносе или док се чувају, треба да буду нечитљиве.
За ово, концепт „кључа“ постоји у криптографији. Управо тако звучи: кључ од браве. Особа која поседује информације шифрује их користећи неку тајну која се зове кључ. Осим ако прималац/нападач нема овај кључ, немогуће је дешифровати податке, ма колико софистицирани били њихови алгоритми.
Ротирајући тастери
Док кључеви омогућавају и поуздано шифровање, они носе ризике које имају лозинке: када неко сазна кључ, цела игра је покренута. Замислите сценарио у коме неко хакује неки део сервиса као што је ГитХуб (чак и на неколико секунди) и може да дође до кода старог 20 година. Унутар кода такође проналазе криптографске кључеве који се користе за шифровање података компаније (ужасна пракса да се кључеви чувају заједно са изворним кодом, али бисте се изненадили колико се то често дешава!). Ако се компанија није потрудила да промени своје кључеве (баш као и лозинке), исти кључ се може користити за стварање хаос.
Као резултат тога, пракса честог мењања кључева је еволуирала. Ово се зове ротација кључева и ако користите било ког угледног добављача ПааС-а у облаку, требало би да буде доступна као аутоматизована услуга.
Кредит за слику: АВС
На пример, АВС има наменску услугу за овај позив АВС Кеи Манагемент Сервице (КМС). Аутоматизована услуга вам штеди муке са променом и дистрибуцијом кључева међу свим серверима и ових дана је једноставна када су у питању велике примене.
Криптографија јавног кључа
Ако вас сав претходни разговор о шифровању и кључевима чини да мислите да је то веома гломазно, у праву сте. Чување кључева и њихово прослеђивање тако да само прималац може да види податке наилази на логистичке проблеме који не би омогућили да просперира данашња сигурна комуникација. Али све захваљујући криптографији са јавним кључем, можемо безбедно да комуницирамо или да купујемо на мрежи.
Ова врста криптографије била је велики математички напредак и то је једини разлог зашто се интернет не распада у страху и неповерењу. Тхе детаљи алгоритма су замршени и веома математички, тако да то овде могу само концептуално објаснити.
Кредит за слику: Тхе Елецтрониц Фронтиер Фоундатион
Криптографија јавног кључа се ослања на употребу два кључа за обраду информација. Један од кључева се зове Приватни кључ и требало би да остане приватан код вас и никада се ни са ким не дели; други се зове јавни кључ (одакле долази назив методе) и требало би да буде јавно објављен. Ако вам шаљем податке, прво морам да добијем ваш јавни кључ и да шифрујем податке и да вам их пошаљем; на свом крају, можете дешифровати податке користећи комбинацију приватног и јавног кључа. Све док случајно не откријете свој приватни кључ, могу да вам пошаљем шифроване податке које само ви можете да отворите.
Лепота система је у томе што не морам да знам ваш приватни кључ, а свако ко пресретне поруку не може ништа да уради да је прочита иако има ваш јавни кључ. Ако се питате како је то уопште могуће, најкраћи и најнетехничкији одговор долази из својстава множења простих бројева:
За рачунаре је тешко да растављају велике просте бројеве на факторе. Дакле, ако је оригинални кључ веома велики, можете бити сигурни да се порука не може дешифровати чак ни за хиљаде година.
Сигурност транспортног слоја (ТЛС)
Сада знате како функционише криптографија јавног кључа. Овај механизам (познавање јавног кључа примаоца и слање података шифрованих помоћу њега) је оно што стоји иза све популарности ХТТПС-а и оно што узрокује да Цхроме каже: „Ова локација је безбедна.“ Оно што се дешава је да сервер и претраживач шифрују ХТТП саобраћај (запамтите, веб странице су веома дуги низови текста које прегледачи могу да тумаче) са јавним кључевима један другог, што резултира безбедним ХТТП-ом (ХТТПС).
Заслуге слике: Мозилла Интересантно је приметити да се шифровање не дешава на транспортном слоју као таквом; тхе ОСИ модел не говори ништа о шифровању података. Једноставно, апликација (у овом случају, претраживач) шифрује податке пре него што их преда транспортном слоју, који их касније одлаже на одредиште, где се дешифрују. Међутим, процес укључује транспортни слој, и на крају дана, све то резултира безбедним транспортом података, тако да се лабав термин „безбедност транспортног” слоја задржао.
Можда ћете чак наићи на термин Сецуре Соцкет Лаиер (ССЛ) у неким случајевима. То је исти концепт као и ТЛС, само што је ССЛ настао много раније и сада је уклоњен у корист ТЛС-а.
Потпуно шифровање диска
Понекад су безбедносне потребе толико интензивне да се ништа не може препустити случају. На пример, државни сервери на којима се чувају сви биометријски подаци неке земље не могу да се обезбеде и покрећу као обични сервери апликација јер је ризик превелик. За ове потребе није довољно да подаци буду шифровани само када се преносе; мора бити шифрован и када је у мировању. За ово се користи потпуна енкрипција диска за шифровање целог чврстог диска како би се осигурало да подаци буду сигурни чак и када су физички пробијени.
Важно је напоменути да се комплетно шифровање диска мора обавити на нивоу хардвера. То је зато што ако шифрујемо цео диск, оперативни систем је такође шифрован и не може да се покрене када се машина покрене. Дакле, хардвер мора да разуме да је садржај диска шифрован и мора да изврши дешифровање у ходу док прослеђује захтеване блокове диска оперативном систему. Због овог додатног посла који се обавља, Фулл Диск Енцриптион доводи до споријег читања/писања, што програмери таквих система морају имати на уму.
Енкрипција од краја до краја
Са текућим ноћним морама о приватности и безбедности великих друштвених мрежа ових дана, нико није свестан појма „шифровање од краја до краја“, чак и ако немају никакве везе са прављењем или одржавањем апликација.
Раније смо видели како Фулл Диск Енцриптион пружа врхунску стратегију отпорну на метке, али за свакодневне кориснике то није згодно. Мислим, замислите да Фацебоок жели да телефонски подаци које генерише и чува у вашем телефону буду сигурни, али не може имати приступ шифровању целог телефона и закључавању свега осталог у том процесу.
Из тог разлога, ове компаније су започеле енкрипцију од краја до краја, што значи да се подаци шифрују када их апликација креира, чува или преноси. Другим речима, чак и када подаци стигну до примаоца, они су у потпуности шифровани и доступни су само преко телефона примаоца.
Кредит за слику: Гоогле
Имајте на уму да енд-то-енд (Е2Е) енкрипција не носи никакве математичке гаранције као криптографија јавног кључа; то је само стандардно шифровање где се кључ чува у предузећу, а ваше поруке су безбедне онолико колико предузеће одлучи.
Закључак 👩🏫
Вероватно сте већ чули за већину ових термина. Можда чак и сви они. Ако јесте, охрабрио бих вас да поново погледате своје разумевање ових концепата, као и да извршите процену колико их озбиљно схватате. Запамтите, безбедност података апликација је рат који морате да добијете сваки пут (а не само једном), јер је чак и једно кршење довољно да уништи читаве индустрије, каријере, па чак и животе!