Тъй като светът става все повече и повече управляван от данни, сигурното боравене с потребителските данни е по-важно от всякога.
Като разработчици работата ни вече е достатъчно трудна: да се занимаваме с много сложни и крехки системи с множество точки на повреда, докато превеждаме прелитащите човешки желания в потребителски интерфейси и бекенд. Добавянето към задачата е нововъзникващо и съществено съображение: сигурност на данните. И за добра причина: ние като клиенти се ядосваме, ако данните ни бъдат злоупотребени (така че е справедливо да дадем на потребителите си сигурно и приятно изживяване), а правителствата и предприятията го изискват за съответствие.
Съдържание
Сигурността на данните като прехвърляне на парите
Това, което прави сигурността по-трудна е, че тя има няколко слоя и се превръща в нещото, че отговорността на всички е отговорност на никого. В модерен облачен екип множество екипи директно контролират входа/изхода на данни: разработчици, администратори на бази данни, системни администратори (хората на DevOps, ако искате), привилегировани потребители на бек-офиса и т.н. Тези роли/екипи могат бързо да затворят очи и да мислят за сигурността на данните като за проблем на другите. И все пак реалността е, че те имат свои собствени светове, за които да се грижат, тъй като администраторът на база данни не може да контролира частта на сигурността на приложението, човек от DevOps не може да направи абсолютно нищо за достъпа до бек офиса и т.н.
Разработчици и сигурност на данните
Всичко казано дотук, разработчиците имат най-голямата повърхност за достъп, когато става въпрос за данни: те изграждат всяка част от приложението; те се свързват с различни бекенд услуги; жетоните за достъп до ферибота напред и назад; те имат целия клъстер на базата данни, от който да четат/записват по своя команда; приложенията, които пишат, имат безспорен достъп до всички части на системата (например, приложение на Django в производство има всички привилегии да изхвърли или изтрие цялата колекция S3 от последните десет години) и т.н. В резултат на това най-големият шанс за небрежност или пропуск по отношение на сигурността съществува на ниво изходен код и е пряка отговорност на разработчика.
Сега сигурността на данните е бездънна заешка дупка и няма начин дори да надраскам повърхността с една публикация. Искам обаче да покрия основната терминология, която разработчиците трябва да знаят, за да запазят своите приложения сигурни. Мислете за това като за сигурност на данните на приложението 101.
Да започваме!
Хеширане
Ако искате много строго определение, винаги има Уикипедия, но с прости думи, хеширането е процес на преобразуване на данни в друга форма, където информацията е нечетима. Например, използвайки добре познатия (и много несигурен) процес на Base64 кодиране, низът „Тайната ми в безопасност ли е при теб?“ може да се преобразува („хеширан“) в „SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/“. Ако започнете да пишете личния си дневник във формат Base64, например, няма начин семейството ви да прочете вашите тайни (освен ако не знаят как да декодират от Base64)!
Тази идея за кодиране на данните се използва при съхраняване на пароли, номера на кредитни карти и т.н. в уеб приложения (всъщност трябва да се използва във всички типове приложения). Идеята, разбира се, е, че в случай на пробив в данните, нападателят не трябва да може да използва паролите, номерата на кредитни карти и т.н., за да нанесе реални щети. За извършване на това хеширане се използват изключително стабилни и сложни алгоритми; нещо като Base64 ще бъде шега и ще бъде разбито моментално от всеки нападател.
Хеширането на пароли използва криптографска техника, известна като еднопосочно хеширане, което означава, че въпреки че е възможно данните да се кодират, не е възможно да се дешифрират. Тогава как приложението разбира, че това е вашата парола, когато влезете? Е, той използва същия процес и сравнява разбърканата форма на това, което току-що сте въвели като парола, с разбърканата форма, съхранена в базата данни; ако съвпадат, имате право да влезете!
Докато сме на темата за хешовете, ето нещо интересно. Ако някога изтеглите софтуер или файлове от интернет, може да са ви казали да проверите файловете, преди да ги използвате. Например, ако искате да изтеглите Ubuntu Linux ISO, страницата за изтегляне ще ви покаже опция за потвърждение на вашето изтегляне; ако щракнете върху него, ще се отвори изскачащ прозорец:
Изскачащият прозорец ви казва да изпълните команда, която по същество ще хешира целия файл, който току-що сте изтеглили, и ще сравни резултата с хеш низа, който виждате на страницата за изтегляне: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Това преобразуване се извършва с помощта на SHA256 алгоритъмспоменаването на което можете да видите в последните части на командата: shasum -a 256 –проверка.
Идеята е, че ако хешът, получен чрез вашата проверка, е различен, това означава, че някой се е намесил във вашето изтегляне и вместо това ви е предоставил компрометиран файл.
Някои познати имена, които ще чуете в областта на хеширането на пароли, са MD5 (несигурен и вече несъществуващ), SHA-1 и SHA-2 (семейства от алгоритми, на които SHA-256 е член, както и SHA-512), SCRYPT, BCRYPT и др.
Осоляване
Всички видове сигурност са игра на котка и мишка: крадецът научава текущата система и измисля нов крак, който се забелязва, а производителите на брави подобряват играта си и така нататък, и така нататък. Криптографията не е изключение. Докато преобразуването на хешовете обратно в пароли стана невъзможно, хакерите с течение на времето са разработили сложни техники, които комбинират интелигентни предположения с чиста изчислителна мощност; в резултат на това, девет пъти от десет, те могат да предвидят правилната парола, като се има предвид само хешът.
„Г-н. Румпелщилцхен, предполагам?!“
В резултат на това се е развила техниката на осоляване. Всичко това означава, че изчислението на хеша на парола (или каквито и да е данни) ще бъде направено въз основа на комбинация от две неща: самите данни, както и нов произволен низ, който атакуващият не може да отгатне. И така, с солирането, ако искаме да хешираме паролата superman009, първо ще изберем произволен низ като „сол“, да речем, bCQC6Z2LlbAsqj77 и след това ще извършим хеш изчислението на superman009-bCQC6Z2LlbAsqj77. Полученият хеш ще се отклонява от обичайните структури, произведени от алгоритъма, значително намалявайки възможностите за интелигентно обратно инженерство или предположения.
Хеширането и осоляването са невероятно сложни области и непрекъснато се развиват. Така че, като разработчик на приложения, ние никога не бихме се занимавали директно с тях. Но би ни помогнало много, ако ги знаем и можем да вземаме по-добри решения. Например, ако поддържате стара PHP рамка и случайно видите, че тя използва MD5 хешове за пароли, знаете, че е време да вмъкнете друга библиотека с пароли в процеса на създаване на потребителски акаунт.
Ключове
Често ще срещнете термина „ключове“ в контекста на криптирането. Досега разглеждахме хеширане на пароли или еднопосочно криптиране, при което преобразуваме данните необратимо и унищожаваме оригиналната форма. Това е лоша идея за ежедневна практическа употреба – документ, написан и изпратен по имейл толкова сигурно, че никога не може да бъде прочетен, е безполезен! По този начин искаме да шифроваме данни, така че да искаме информацията да бъде отворена за изпращача и получателя, но докато се прехвърля или докато се съхранява, тя трябва да бъде нечетлива.
За това понятието „ключ“ съществува в криптографията. Точно така звучи: ключът към ключалката. Човекът, който притежава информацията, я кодира с помощта на някаква тайна, наречена ключ. Освен ако получателят/атакуващият не разполага с този ключ, е невъзможно да се дешифрират данните, без значение колко сложни могат да бъдат техните алгоритми.
Въртящи се ключове
Докато ключовете правят криптирането възможно и надеждно, те носят рисковете, които носят паролите: щом някой знае ключа, цялата игра е готова. Представете си сценарий, при който някой хаква част от услуга като GitHub (дори и за няколко секунди) и може да се сдобие с код на 20 години. Вътре в кода те намират и криптографските ключове, използвани за криптиране на данните на компанията (ужасна практика да се съхраняват ключове заедно с изходния код, но ще се изненадате колко често се случва това!). Ако компанията не си е направила труда да смени своите ключове (точно като паролите), същият ключ може да се използва, за да сее хаос.
В резултат на това се е развила практиката за честа смяна на ключовете. Това се нарича ротация на ключове и ако използвате уважаван облачен доставчик на PaaS, той трябва да е достъпен като автоматизирана услуга.
Кредит за изображение: AWS
Например AWS има специална услуга за това, наречена AWS Key Management Service (KMS). Автоматизираната услуга ви спестява неудобството по смяната и разпределянето на ключове между всички сървъри и е безпроблемна работа в наши дни, когато става въпрос за големи внедрявания.
Криптография с публичен ключ
Ако всички предишни разговори за криптиране и ключове ви карат да мислите, че е много тромаво, вие сте прави. Пазенето на ключовете в безопасност и предаването им, така че само получателят да може да види данните, се сблъсква с логистични проблеми, които не биха позволили днешните сигурни комуникации да просперират. Но благодарение на криптографията с публичен ключ можем безопасно да комуникираме или да правим покупки онлайн.
Този тип криптография беше голям математически пробив и това е единствената причина интернет да не се разпада от страх и недоверие. The подробности за алгоритъма са сложни и силно математически, така че мога да го обясня само концептуално тук.
Кредит за изображение: The Electronic Frontier Foundation
Криптографията с публичен ключ разчита на използването на два ключа за обработка на информация. Един от ключовете се нарича Private Key и трябва да остане личен за вас и никога да не се споделя с никого; другият се нарича Public Key (откъдето идва и името на метода) и трябва да бъде публикуван публично. Ако ви изпращам данни, първо трябва да получа вашия публичен ключ и да криптирам данните и да ви ги изпратя; от своя страна можете да дешифрирате данните, като използвате комбинацията от частен ключ и публичен ключ. Стига да не разкриете случайно личния си ключ, мога да ви изпратя криптирани данни, които само вие можете да отворите.
Красотата на системата е, че не е необходимо да знам личния ви ключ и всеки, който прихване съобщението, не може да направи нищо, за да го прочете, въпреки че има вашия публичен ключ. Ако се чудите как това изобщо е възможно, най-краткият и нетехнически отговор идва от свойствата на умножението на прости числа:
За компютрите е трудно да разлагат на фактори големи прости числа. Така че, ако оригиналният ключ е много голям, можете да сте сигурни, че съобщението не може да бъде декриптирано дори след хиляди години.
Сигурност на транспортния слой (TLS)
Вече знаете как работи криптографията с публичен ключ. Този механизъм (познаване на публичния ключ на получателя и изпращане на данни, криптирани с него) е това, което стои зад цялата популярност на HTTPS и е това, което кара Chrome да казва: „Този сайт е защитен“. Това, което се случва е, че сървърът и браузърът шифроват HTTP трафик (не забравяйте, че уеб страниците са много дълги текстови низове, които браузърите могат да интерпретират) с публичните ключове на другия, което води до защитен HTTP (HTTPS).
Кредит на изображението: Mozilla. Интересно е да се отбележи, че криптирането не се извършва на транспортния слой като такъв; на OSI модел не казва нищо за криптиране на данни. Просто данните се криптират от приложението (в този случай браузъра), преди да бъдат предадени на транспортния слой, който по-късно ги пуска на местоназначението, където се дешифрират. Процесът обаче включва транспортния слой и в крайна сметка всичко това води до сигурно пренасяне на данни, така че свободният термин за сигурност на транспортния слой е останал.
В някои случаи може дори да срещнете термина Secure Socket Layer (SSL). Това е същата концепция като TLS, с изключение на това, че SSL е възникнал много по-рано и сега е заменен в полза на TLS.
Пълно дисково криптиране
Понякога нуждите от сигурност са толкова големи, че нищо не може да бъде оставено на случайността. Например правителствените сървъри, където се съхраняват всички биометрични данни за дадена държава, не могат да бъдат осигурени и да работят като нормални сървъри за приложения, тъй като рискът е твърде висок. За тези нужди не е достатъчно данните да бъдат криптирани само когато се прехвърлят; трябва да бъде криптиран и когато е в покой. За тази цел се използва пълно криптиране на диска за криптиране на целия твърд диск, за да се гарантира, че данните са защитени дори когато са физически пробити.
Важно е да се отбележи, че пълното криптиране на диска трябва да се извърши на хардуерно ниво. Това е така, защото ако криптираме целия диск, операционната система също е криптирана и не може да работи, когато машината стартира. Така че хардуерът трябва да разбере, че съдържанието на диска е криптирано и трябва да извърши декриптиране в движение, докато предава исканите дискови блокове към операционната система. Поради тази допълнителна работа, която се извършва, пълното дисково шифроване води до по-бавно четене/запис, което трябва да се има предвид от разработчиците на такива системи.
Криптиране от край до край
С продължаващите кошмари за поверителността и сигурността на големите социални мрежи в наши дни, никой не е наясно с термина „шифроване от край до край“, дори и да няма нищо общо с създаването или поддържането на приложения.
Видяхме по-рано как пълното шифроване на диска осигурява най-добрата бронеустойчива стратегия, но за обикновения потребител това не е удобно. Искам да кажа, представете си, че Facebook иска телефонните данни, които генерира и съхранява в телефона ви, да бъдат защитени, но не може да има достъп до криптиране на целия ви телефон и да заключва всичко останало в процеса.
Поради тази причина тези компании са започнали криптиране от край до край, което означава, че данните се криптират, когато се създават, съхраняват или прехвърлят от приложението. С други думи, дори когато данните достигнат до получателя, те са напълно криптирани и са достъпни само от телефона на получателя.
Кредит за изображение: Google
Имайте предвид, че криптирането от край до край (E2E) не носи никакви математически гаранции, както криптографията с публичен ключ; това е просто стандартно криптиране, при което ключът се съхранява в бизнеса и вашите съобщения са толкова безопасни, колкото бизнесът реши.
Заключение 👩🏫
Вероятно вече сте чували за повечето от тези термини. Може би дори всичките. Ако е така, бих ви насърчил да преразгледате разбирането си за тези концепции, както и да извършите оценка на това колко сериозно ги приемате. Не забравяйте, че сигурността на данните на приложението е война, която трябва да печелите всеки път (а не само веднъж), тъй като дори един пробив е достатъчен, за да унищожи цели индустрии, кариери и дори животи!