Оскільки світ стає все більш і більше керованим даними, безпечне поводження з даними користувачів є більш важливим, ніж будь-коли.
Наша робота як розробників і так досить важка: ми маємо справу з дуже складними та крихкими системами з багатьма точками збоїв, а ми перетворюємо мінливі людські побажання в інтерфейси користувача та серверні модулі. Щоб додати до цього завдання, виникає важливий аспект: безпека даних. І з поважної причини: ми, клієнти, розлючені, якщо наші дані зловживають (тому це справедливо, ми надаємо нашим користувачам безпечний і приємний досвід), а уряди та підприємства вимагають цього для відповідності.
Безпека даних як перекладання відповідальності
Що ускладнює безпеку, так це те, що вона має кілька рівнів і перетворюється на відповідальність кожного. У сучасній хмарній команді кілька команд безпосередньо контролюють вхід/вихід даних: розробники, адміністратори баз даних, системні адміністратори (люди DevOps, якщо хочете), привілейовані користувачі бек-офісу тощо. Ці ролі/команди можуть швидко закрити очі і вважати безпеку даних проблемою інших. Тим не менш, реальність така, що вони мають свої власні світи, про які потрібно піклуватися, оскільки адміністратор бази даних не може контролювати безпеку програм, спеціаліст DevOps не може зробити абсолютно нічого щодо доступу до бек-офісу тощо.
Розробники та безпека даних
Загалом, розробники мають найбільший доступ до даних: вони створюють кожну частину програми; вони підключаються до різних серверних служб; жетони доступу на пором туди й назад; вони мають весь кластер бази даних для читання/запису за своєю командою; програми, які вони пишуть, мають беззаперечний доступ до всіх частин системи (наприклад, програма Django у виробництві має всі привілеї, щоб дампувати або стерти всю колекцію S3 за останні десять років) і так далі. Як наслідок, найвища ймовірність неохайності або недогляду з точки зору безпеки існує на рівні вихідного коду, і це пряма відповідальність розробника.
Тепер безпека даних — це бездонна кроляча нора, і я не можу навіть подряпати поверхню в одній публікації. Однак я хочу розглянути основну термінологію, яку розробники повинні знати, щоб забезпечити безпеку своїх програм. Подумайте про це як про безпеку даних програми 101.
Давайте розпочнемо!
Хешування
Якщо вам потрібне дуже точне визначення, воно завжди є Вікіпедія, але простою мовою, хешування – це процес перетворення даних в іншу форму, де інформацію неможливо прочитати. Наприклад, використовуючи добре відомий (і дуже небезпечний) процес Кодування 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 (KMS). Автоматизована служба позбавляє вас від клопоту зі зміною та розподілом ключів між усіма серверами, і в наш час є простою справою, коли справа стосується великих розгортань.
Криптографія з відкритим ключем
Якщо всі попередні розмови про шифрування та ключі змушують вас думати, що це дуже громіздко, ви маєте рацію. Зберігання ключів у безпеці та їх передача таким чином, щоб лише одержувач міг бачити дані, стикається з логістичними проблемами, які не дозволили б процвітати сьогоднішньому безпечному зв’язку. Але все завдяки криптографії з відкритим ключем ми можемо безпечно спілкуватися або робити покупки онлайн.
Цей тип криптографії був великим математичним проривом, і це єдина причина, чому Інтернет не розвалюється через страх і недовіру. The деталі алгоритму є складними та дуже математичними, тому я можу пояснити це лише концептуально.
Кредит зображення: The Electronic Frontier Foundation
Криптографія з відкритим ключем базується на використанні двох ключів для обробки інформації. Один із ключів називається Private Key, і він має залишатися приватним для вас і ніколи нікому не надаватися; інший називається відкритим ключем (звідки походить назва методу) і має бути опублікованим. Якщо я надсилаю вам дані, мені спочатку потрібно отримати ваш відкритий ключ, зашифрувати дані та надіслати їх вам; зі свого боку ви можете розшифрувати дані за допомогою комбінації закритого та відкритого ключів. Якщо ви випадково не розкриєте свій закритий ключ, я можу надіслати вам зашифровані дані, які можете відкрити лише ви.
Принадність системи полягає в тому, що мені не потрібно знати ваш закритий ключ, і будь-хто, хто перехопить повідомлення, не зможе нічого зробити, щоб прочитати його, навіть якщо він має ваш відкритий ключ. Якщо вам цікаво, як це взагалі можливо, найкоротша і найбільш нетехнічна відповідь походить від властивостей множення простих чисел:
Комп’ютерам важко розкласти великі прості числа на множники. Отже, якщо вихідний ключ дуже великий, ви можете бути впевнені, що повідомлення не можна буде розшифрувати навіть через тисячі років.
Безпека транспортного рівня (TLS)
Тепер ви знаєте, як працює криптографія з відкритим ключем. Цей механізм (знання відкритого ключа одержувача та надсилання йому зашифрованих даних) є причиною всієї популярності HTTPS і змушує Chrome говорити: «Цей сайт безпечний». Що відбувається, так це те, що сервер і браузер шифрують трафік HTTP (пам’ятайте, веб-сторінки – це дуже довгі рядки тексту, які браузери можуть інтерпретувати) за допомогою відкритих ключів один одного, що призводить до захищеного HTTP (HTTPS).
Автор зображення: Mozilla Цікаво відзначити, що шифрування не відбувається на транспортному рівні як такому; в Модель OSI нічого не говорить про шифрування даних. Просто дані шифруються програмою (у цьому випадку браузером) перед тим, як вони передаються на транспортний рівень, який згодом надсилає їх у пункт призначення, де вони розшифровуються. Однак цей процес включає транспортний рівень, і, зрештою, все це призводить до безпечного транспортування даних, тому вільний термін безпеки «транспортного» рівня затримався.
У деяких випадках ви навіть можете зустріти термін Secure Socket Layer (SSL). Це та сама концепція, що й TLS, за винятком того, що SSL виник набагато раніше, а тепер відступає на користь TLS.
Повне шифрування диска
Іноді потреби в безпеці настільки гострі, що нічого не можна залишити напризволяще. Наприклад, урядові сервери, на яких зберігаються всі біометричні дані країни, не можуть бути підготовлені та працювати як звичайні сервери додатків, оскільки ризик надто високий. Для цих потреб недостатньо, щоб дані були зашифровані лише під час передачі; він також повинен бути зашифрований у стані спокою. Для цього використовується повне шифрування диска для шифрування всього жорсткого диска, щоб гарантувати безпеку даних навіть у разі фізичного зламу.
Важливо зазначити, що повне шифрування диска має виконуватися на апаратному рівні. Це тому, що якщо ми зашифруємо весь диск, операційна система також буде зашифрована і не зможе працювати під час запуску машини. Таким чином, апаратне забезпечення має розуміти, що вміст диска зашифровано, і має виконувати дешифрування на льоту, коли воно передає запитані дискові блоки до операційної системи. Через цю додаткову роботу Full Disk Encryption призводить до повільнішого читання/запису, про що слід пам’ятати розробникам таких систем.
Наскрізне шифрування
У зв’язку з безперервними кошмарами конфіденційності та безпеки у великих соціальних мережах сьогодні ніхто не знає про термін «наскрізне шифрування», навіть якщо вони не мають нічого спільного зі створенням або підтримкою програм.
Ми бачили раніше, як Full Disk Encryption забезпечує найкращу стратегію куленепробивності, але для звичайного користувача це незручно. Я маю на увазі, уявіть, що Facebook хоче, щоб телефонні дані, які він генерує та зберігає у вашому телефоні, були безпечними, але він не може мати доступ до шифрування всього вашого телефону та блокування всього іншого в процесі.
З цієї причини ці компанії запровадили наскрізне шифрування, що означає, що дані шифруються, коли вони створюються, зберігаються або передаються програмою. Іншими словами, навіть коли дані досягають одержувача, вони повністю зашифровані й доступні лише на телефоні одержувача.
Кредит зображення: Google
Зауважте, що наскрізне шифрування (E2E) не забезпечує жодних математичних гарантій, як криптографія з відкритим ключем; це просто стандартне шифрування, де ключ зберігається в компанії, а ваші повідомлення є настільки безпечними, наскільки вирішить компанія.
Висновок 👩🏫
Ви, мабуть, уже чули про більшість цих термінів. Можливо, навіть усі. Якщо так, я б заохотив вас переглянути своє розуміння цих концепцій, а також оцінити, наскільки серйозно ви їх сприймаєте. Пам’ятайте, що безпека даних додатків — це війна, яку потрібно вигравати щоразу (і не лише раз), оскільки навіть одного пролому достатньо, щоб знищити цілі галузі, кар’єри та навіть життя!