У сучасному світі, де дані відіграють ключову роль, забезпечення їхньої безпеки стає надзвичайно важливим завданням.
Робота розробників і без того нелегка, адже їм доводиться мати справу зі складними системами, що часто дають збої, перетворюючи людські побажання на зручні інтерфейси та серверні рішення. До цього додається ще один важливий аспект – захист даних. Це важливо з кількох причин: по-перше, користувачі роздратовані, коли їхні дані використовуються неналежним чином (і це справедливо, адже ми прагнемо надати їм безпечний та позитивний досвід), а по-друге, уряди та організації вимагають відповідності стандартам безпеки.
Безпека даних: колективна відповідальність
Складність забезпечення безпеки полягає в її багаторівневості та колективній відповідальності. У сучасній хмарній інфраструктурі за обробку даних відповідає ціла низка команд: розробники, адміністратори баз даних, системні адміністратори (DevOps-інженери) та інші користувачі з привілейованим доступом. Кожна з цих ролей може схилятися до того, що безпека даних – це не їхня відповідальність. Проте, кожна команда повинна дбати про свій власний «світ». Наприклад, адміністратор бази даних не може впливати на безпеку додатків, а DevOps-інженер – на доступ до бек-офісу.
Роль розробників у захисті даних
Найбільший доступ до даних зазвичай мають розробники: вони створюють кожен компонент програмного забезпечення, підключаються до різних серверних сервісів, обробляють токени доступу, мають повний доступ до баз даних для читання та запису, а їхні додатки мають необмежений доступ до усіх частин системи. Наприклад, додаток Django у виробничому середовищі може мати права на видалення всієї колекції даних з S3 за останні десять років. Тому, саме на рівні вихідного коду найімовірніші помилки або недогляди в питаннях безпеки, і це пряма відповідальність розробника.
Безпека даних – це дуже широка тема, і в рамках однієї статті неможливо розглянути всі її аспекти. Однак, я хочу ознайомити вас з основною термінологією, яку необхідно знати розробникам для забезпечення безпеки своїх програм. Розглянемо це як основи безпеки даних для розробників.
Отже, почнемо!
Хешування
Точне визначення ви завжди можете знайти у Вікіпедії, але простими словами, хешування – це процес перетворення даних у іншу форму, де вихідну інформацію неможливо прочитати. Наприклад, за допомогою відомого (і вкрай ненадійного) способу кодування Base64, рядок «Чи мій секрет у безпеці з тобою?» можна перетворити («хешувати») на «SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/». Якщо ви будете вести свій щоденник у форматі Base64, то ваші близькі не зможуть прочитати ваші таємниці (якщо вони не вміють розкодовувати з Base64)!
Ідея шифрування даних використовується під час зберігання паролів, номерів кредитних карток тощо у веб-додатках (і це має використовуватись у всіх видах програм). Суть полягає в тому, що у разі витоку даних зловмисники не зможуть використовувати паролі, номери кредитних карток та інше для завдавання шкоди. Для хешування застосовуються надійні та складні алгоритми. Щось на зразок Base64 буде лише жартом і буде швидко зламане будь-яким зловмисником.
Хешування паролів використовує криптографічну техніку, яка називається одностороннім хешуванням. Це означає, що дані можна зашифрувати, але неможливо розшифрувати назад. Як тоді програма дізнається, що це ваш пароль, коли ви входите? Вона використовує той самий процес і порівнює зашифровану форму вашого введеного пароля із зашифрованою формою, що зберігається в базі даних. Якщо вони збігаються, вам дозволено увійти!
Поки ми говоримо про хеші, ось ще дещо цікаве. Якщо ви коли-небудь завантажували програмне забезпечення чи файли з інтернету, вас, можливо, просили перевірити їх перед використанням. Наприклад, при завантаженні Ubuntu Linux ISO на сторінці завантаження є можливість перевірити завантаження. При натисканні відкриється вікно:
У спливаючому вікні буде показано команду, яка хешує весь завантажений вами файл і порівнює результат із хеш-рядком, вказаним на сторінці завантаження: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Це перетворення виконується за допомогою алгоритму SHA256, про який йдеться у кінці команди: shasum -a 256 –check.
Суть перевірки полягає в тому, що якщо згенерований вами хеш відрізняється, це означає, що хтось втрутився у ваше завантаження і надав вам скомпрометований файл.
З відомих назв, які ви можете почути у контексті хешування паролів, можна виділити 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 Electronic Frontier Foundation
Криптографія з відкритим ключем ґрунтується на використанні двох ключів для обробки інформації. Один із ключів називається закритим (Private Key) і має залишатися у вас і ніколи нікому не передаватися. Інший називається відкритим ключем (звідки походить назва методу) і має бути опублікованим. Якщо я надсилаю вам дані, мені потрібно спочатку отримати ваш відкритий ключ, зашифрувати дані та надіслати їх вам. Зі свого боку, ви можете розшифрувати дані, використовуючи комбінацію закритого та відкритого ключів. Якщо ви не розголосите свій закритий ключ, то я зможу надіслати вам зашифровані дані, які зможете відкрити лише ви.
Перевага системи полягає в тому, що мені не потрібно знати ваш закритий ключ, і будь-хто, хто перехопить повідомлення, не зможе нічого зробити, щоб прочитати його, навіть маючи ваш відкритий ключ. Якщо вам цікаво, як це взагалі можливо, найпростіша та нетехнічна відповідь походить від властивостей множення простих чисел:
Комп’ютерам важко розкладати великі прості числа на множники. Отже, якщо вихідний ключ дуже великий, ви можете бути впевнені, що повідомлення не можна буде розшифрувати навіть через тисячі років.
Безпека транспортного рівня (TLS)
Тепер, коли ви знаєте, як працює криптографія з відкритим ключем, ви розумієте, чому HTTPS настільки поширений і чому Chrome показує повідомлення: «Цей сайт безпечний». Сервер і браузер шифрують трафік HTTP (пам’ятайте, веб-сторінки – це дуже довгі текстові рядки, які браузери можуть інтерпретувати) за допомогою відкритих ключів один одного, що створює безпечне HTTP (HTTPS).
Зображення: Mozilla
Важливо зазначити, що шифрування не відбувається на транспортному рівні; у моделі OSI немає вимог до шифрування даних. Просто дані шифруються програмою (у цьому випадку браузером) перед тим, як вони передаються на транспортний рівень, який потім надсилає їх до місця призначення, де вони розшифровуються. Проте, цей процес включає транспортний рівень, і, зрештою, все це призводить до безпечного транспортування даних, тому термін “безпека транспортного рівня” є цілком слушним.
У деяких випадках ви можете зустріти термін Secure Socket Layer (SSL). Це та сама концепція, що й TLS, за винятком того, що SSL з’явився раніше і поступово відходить на користь TLS.
Повне шифрування диска
Іноді вимоги безпеки настільки високі, що не можна нічого залишати напризволяще. Наприклад, урядові сервери, на яких зберігаються всі біометричні дані країни, не можуть бути підготовлені та працювати як звичайні сервери додатків, оскільки ризик є дуже високим. У таких випадках недостатньо, щоб дані були зашифровані лише під час передачі, вони також мають бути зашифровані і в стані спокою. Для цього використовується повне шифрування диска, щоб гарантувати безпеку даних навіть у випадку фізичного злому.
Важливо зазначити, що повне шифрування диска має виконуватися на апаратному рівні. Це пояснюється тим, що якщо ми зашифруємо весь диск, то операційна система також буде зашифрованою і не зможе працювати під час запуску комп’ютера. Таким чином, апаратне забезпечення повинно розуміти, що вміст диска зашифрований, і має виконувати розшифрування на льоту, коли воно передає запитані блоки даних до операційної системи. Через ці додаткові операції повне шифрування диска уповільнює процеси читання та запису, що потрібно пам’ятати розробникам таких систем.
Наскрізне шифрування
У зв’язку з постійними скандалами щодо конфіденційності та безпеки у великих соціальних мережах, сьогодні багато хто знайомий з терміном “наскрізне шифрування”, навіть якщо вони не мають нічого спільного з розробкою та підтримкою програмного забезпечення.
Ми вже розглянули, як повне шифрування диска забезпечує надійну стратегію захисту, але це не дуже зручно для звичайних користувачів. Наприклад, Facebook хоче, щоб дані, які створюються та зберігаються на вашому телефоні, були безпечними, але він не може отримати доступ до шифрування всього вашого телефону.
З цієї причини ці компанії запровадили наскрізне шифрування, що означає, що дані шифруються під час їх створення, зберігання або передачі програмою. Іншими словами, навіть коли дані доходять до одержувача, вони залишаються повністю зашифрованими та доступними лише на телефоні одержувача.
Зображення: Google
Зауважте, що наскрізне шифрування (E2E) не надає математичних гарантій, як криптографія з відкритим ключем; це лише стандартне шифрування, де ключ зберігається в компанії, а ваші повідомлення є настільки безпечними, наскільки компанія вирішить.
Висновок 👩🏫
Ви, напевно, вже чули про більшість із цих термінів. Можливо, навіть про всі. Якщо так, я б порадив вам переглянути своє розуміння цих концепцій і оцінити, наскільки серйозно ви їх сприймаєте. Пам’ятайте, що безпека даних додатків – це війна, яку потрібно вигравати щоразу (а не лише раз), адже навіть один пролом може зруйнувати цілі галузі, кар’єри і навіть життя!