Loader

Що нульова довіра означає для Kubernetes?

Ключові моменти
· Нульова довіра – це модель безпеки, яка викликала багато галасу, але, незважаючи на маркетинговий шум, вона має конкретну та безпосередню цінність для організацій, які піклуються про безпеку.
· За своєю суттю, нульова довіра перекладає авторизацію від “перевірки один раз на периметрі” до “перевірки скрізь і завжди”.
· Для цього нульова довіра вимагає переосмислення поняття ідентифікації та відмови від ідентифікації на основі розташування, наприклад, IP-адреси.
· Користувачі Kubernetes мають явну перевагу при реалізації нульової довіри на мережевому рівні завдяки сіткам сервісів на базі sidecar, які забезпечують автентифікацію та авторизацію на гранульованому рівні, не вимагаючи змін у додатках.
· Хоча сервісні сітки можуть допомогти, безпека Kubernetes залишається складною та тонкою темою, яка потребує розуміння кількох рівнів стека.

Нульова довіра – це потужна модель безпеки, яка знаходиться на передньому краї найсучасніших методів забезпечення безпеки. Це також термін, навколо якого багато галасу та ажіотажу, що ускладнює розуміння його суті. То що ж таке нульова довіра, і що саме вона означає для Kubernetes? У цій статті ми розглянемо, що таке нульова довіра з інженерної точки зору, і створимо базову основу для розуміння наслідків як для операторів Kubernetes, так і для команд безпеки.

Вступ
Якщо ви розробляєте сучасне хмарне програмне забезпечення, будь то Kubernetes або щось інше, ви напевно чули про термін “нульова довіра”. Модель безпеки з нульовою довірою стала настільки важливою, що федеральний уряд США звернув на неї увагу: Білий дім нещодавно випустив меморандум із викладом федеральної стратегії нульової довіри, згідно з якою всі федеральні агенції США повинні відповідати певним стандартам безпеки з нульовою довірою до кінця 2024 фінансового року; Міністерство оборони створило еталонну архітектуру нульової довіри; а Агентство національної безпеки опублікувало посібник зі зміцнення Kubernetes, в якому описані найкращі практики безпеки з нульовою довірою в Kubernetes.

Завдяки такому галасу “нульова довіра”, безумовно, привернула до себе пильну увагу маркетингу. Але, незважаючи на шум, нульова довіра – це не просто порожній термін, а втілення деяких глибоких і перетворюючих ідей майбутньої безпеки. Отже, що таке нульова довіра і чому вона раптом стала такою важливою? І що означає нульова довіра для користувачів Kubernetes?

Що таке нульова довіра?
Як і слід було очікувати, нульова довіра в основі пов’язана з довірою. Це модель для вирішення одного з основних питань безпеки: чи дозволено X доступ до Y? Іншими словами, чи довіряємо ми X доступ до Y?

Звичайно, “нуль” у нульовій довірі – це деяке перебільшення. Для того, щоб програмне забезпечення працювало, очевидно, що щось має довіряти чомусь іншому. Таким чином, нульова довіра – це не так повне усунення довіри, скільки скорочення її до необхідного мінімуму (відомий принцип найменших привілеїв) та забезпечення її дотримання на кожному етапі.

Це може бути цілком логічним. Але, як і у випадку з багатьма новими ідеями в галузі технологій, найкращий спосіб зрозуміти нульову довіру – це зрозуміти, на що вона є реакцією. Нульова довіра – це відмова від ідеї, що безпеки периметра достатньо. У моделі захисту периметра ви створюєте “тверду оболонку” навколо вразливих компонентів. Наприклад, навколо вашого центру обробки даних може бути встановлений брандмауер, завдання якого – не допустити проникнення поганого трафіку та порушників. Ця модель, яка іноді називається “замковим підходом”, має інтуїтивний сенс: стіни замку існують для того, щоб не допустити проникнення поганих гравців. Якщо ви знаходитесь всередині замку, значить, за визначенням, ви гарний гравець.
Модель нульової довіри стверджує, що безпеки по периметру недостатньо. Відповідно до моделі нульової довіри, навіть у межах периметра безпеки ви повинні розглядати користувачів, системи та мережевий трафік як недовірені.

В еталонній архітектурі Міністерства оборони це добре сформульовано:

“Жоден суб’єкт, система, мережа чи служба, що працюють поза чи всередині периметра безпеки, не заслуговують на довіру. Натомість ми повинні перевіряти все і вся, що намагається отримати доступ. Це кардинальна зміна парадигми у філософії захисту нашої інфраструктури, мереж та даних: від одноразової перевірки на периметрі до постійної перевірки кожного користувача, пристрою, програми та транзакції”.

Звичайно, нульова довіра не означає відкидання брандмауерів – глибока оборона є важливим компонентом будь-якої стратегії безпеки. Це також не означає, що ми можемо ігнорувати всі інші важливі компоненти безпеки, такі як реєстрація подій та управління ланцюжками постачання. Нульова довіра просто вимагає, щоб ми перенесли перевірку довіри з “один раз на периметрі” на “щоразу, скрізь”.

Однак, щоб зробити це правильно, нам необхідно переосмислити деякі фундаментальні припущення про те, що означає “довіра” і як ми її фіксуємо.

Ідентичність
Одним із найбезпосередніших наслідків нульової довіри є те, що вона змінює наше уявлення про ідентичність і те, як ми присвоюємо її, особливо системну ідентичність.

У моделі периметра ваше місцезнаходження фактично є вашою особистістю. Якщо ви знаходитесь всередині брандмауера, вам довіряють, якщо за його межами-ні. Таким чином, системи на основі периметра можуть дозволяти доступ до важливих систем на основі таких речей, як IP-адреса клієнта.

У світі нульової довіри цього недостатньо. Ваша IP-адреса вказує лише на місце розташування і, таким чином, більше не є достатньою для визначення того, чи довіряють вам доступ до певного ресурсу. Натомість нам потрібна інша форма ідентифікації: прив’язка до робочого навантаження, користувача або системи якимось внутрішнім чином. І ця ідентичність має бути перевірена якимось способом, який сам собою не вимагає довіри до мережі.

Це важлива вимога з багатьма наслідками. Системи, що забезпечують мережеву безпеку, але покладаються на ідентифікатори, такі як IP-адреси, наприклад, IPSec або Wireguard, не є достатніми для нульової довіри.

Політика
Озброївшись новою моделлю ідентифікації, нам тепер потрібен спосіб визначення типу доступу, який має кожна особа. В описаному вище підході до периметра зазвичай надається повний доступ до конфіденційного ресурсу для низки IP-адрес. Наприклад, ми можемо налаштувати фільтрацію IP-адрес, щоб гарантувати, що лише IP-адреси зсередини брандмауера дозволять доступ до конфіденційної служби. При нульовій довірі натомість необхідно забезпечити мінімально необхідний рівень доступу. Доступ до ресурсу має бути максимально обмеженим, заснованим на ідентифікації та будь-яких інших значущих чинниках.

Хоча код нашої програми міг би сам приймати такі рішення про авторизацію, ми зазвичай натомість фіксуємо їх за допомогою певної форми політики, зазначеної поза додатком. Наявність явної політики дозволяє нам проводити аудит та змінювати доступ без зміни коду програми.

Для досягнення цілей нульової довіри ці політики можуть бути дуже складними. У нас може бути політика, яка обмежує доступ до служби лише тими викликаючими службами, яким необхідно отримати доступ до неї (тобто, використовуючи ідентифікатор робочого навантаження з обох сторін). Ми можемо розширити цю можливість та дозволити доступ лише до певних інтерфейсів (HTTP-маршрути, методи gRPC) цієї служби. Ми можемо зробити це ще ретельніше і обмежити доступ на основі ідентифікації користувача, відповідального за запит. Метою у всіх випадках є найменший привілей – доступ до систем і даних повинен надаватися лише у разі нагальної потреби.

Виконання
Нарешті, нульова довіра вимагає, щоб ми виконували аутентифікацію (підтвердження особистості) та авторизацію (підтвердження того, що політика дозволяє дію) на максимально можливому гранулярному рівні. Кожна система, що надає доступ до даних або обчислень, повинна забезпечувати дотримання меж безпеки, починаючи з периметра та закінчуючи окремими компонентами.

Як і у випадку з політикою, це забезпечення примусового виконання в ідеалі здійснюється однаково у всьому стеку. Замість того, щоб кожен компонент використовував свій власний код виконання, використання єдиного рівня виконання дозволяє проводити аудит та відокремлювати проблеми розробників програм від проблем операторів та команд безпеки.

Нульова довіра для Kubernetes
Зіткнувшись із необхідністю переосмислити ідентифікацію з найперших принципів, представити довіру у вигляді політик довільної виразності та забезпечити нашу інфраструктуру новими примусовими механізмами на кожному рівні, цілком природно зазнати моменту паніки. І я вже казав, що ми маємо зробити це до 2024 фінансового року?

Хорошою новиною є те, що принаймні для користувачів Kubernetes деякі аспекти прийняття нульової довіри значно спрощуються. При всіх своїх недоліках та складностях Kubernetes – це платформа з чітко вираженою сферою застосування, добре визначеною моделлю безпеки та чіткими механізмами розширення. Це робить її плідною територією для реалізації нульової довіри.

Одним із найбільш прямих способів вирішення проблеми мереж нульової довіри в Kubernetes є сітка сервісів. Сервісна сітка використовує переваги потужної концепції Kubernetes “sidecar”, в якій контейнери платформи можуть бути динамічно вставлені під час розгортання поруч із контейнерами додатків як форма пізнього зв’язування операційної функціональності.

Сервісні сітки використовують цей підхід sidecar для додавання проксі в капсули додатків під час виконання та підключення цих проксі для обробки всього вхідного та вихідного трафіку. Це дозволяє сервісній сітці надавати функції, відокремлені від коду програми. Такий поділ проблем між програмою та платформою є ключовим. для ціннісної пропозиції сервісної сітки: звичайно, ці функції можуть бути реалізовані безпосередньо в додатку, але, розділивши їх, ми дозволяємо командам безпеки та розробникам проводити ітерації незалежно одна від одної, працюючи при цьому над загальною метою – безпечним, але повнофункціональним додатком.

Оскільки сервісна сітка за умовчанням обробляє мережеву взаємодію з додатком та від нього, вона має всі можливості для вирішення проблем нульової довіри:
1. Ідентифікація робочого навантаження може бути отримана з ідентифікатора капсули Kubernetes, а не з її IP-адреси.
2. Аутентифікація може бути здійснена шляхом обгортання сполук у взаємний TLS, варіант TLS, в якому особистість перевіряється на обох сторонах з’єднання криптографічного доказу.
3. Політика авторизації може бути виражена в термінах Kubernetes, наприклад, за допомогою користувацьких визначень ресурсів (CRD), що робить політику явною та відокремленою від програми.
4. Найголовніше, що забезпечення дотримання правил складає рівні окремих капсул рівномірно по всьому стеку. Кожна капсула виконує свою власну автентифікацію та авторизацію, що означає, що мережі ніколи не довіряють.

Разом вони забезпечують більшість наших цілей нульової довіри (принаймні для кластерів Kubernetes!). У нас є ідентифікація робочого навантаження, а не мережна ідентифікація; примусове застосування на гранульованому рівні – на рівні кластера; а також послідовний та одноманітний спосіб застосування аутентифікації та авторизації у всьому нашому стеку, без зміни програми.

У межах базової структури різні реалізації сервісної сітки забезпечують різні компроміси. Наприклад, Linkerd – це сітка сервісів з відкритим вихідним кодом та випускний проект Cloud Native Computing Foundation, який забезпечує реалізацію, орієнтовану в першу чергу на простоту, отримуючи ідентифікацію робочого навантаження безпосередньо з Kubernetes ServiceAccounts, щоб забезпечити “нульову конфігурацію”, включений за замовчуванням взаємний TLS. Аналогічним чином мікропроксі Linkerd на базі Rust забезпечують мінімалістичну реалізацію нульової довіри.

Звичайно, просте додавання сервісної сітки до кластера не є панацеєю. Після встановлення необхідно взяти на себе роботу з визначення, оновлення та оцінки політик авторизації. Оператори кластера повинні уважно стежити за тим, щоб усі новостворені капсулибули пов’язані зі своїм компонентом sidecar. І, звичайно, сама сервісна сітка повинна обслуговуватися, контролюватись та оновлюватись, як і будь-яке програмне забезпечення на кластері. Однак, панацея чи ні, сервісна сітка забезпечує перехід від стандартного незашифрованого, неавтентифікованого трафіку в кластері до стандартного зашифрованого, аутентифікованого трафіку з надійними ідентифікаторами робочих навантажень та багатою системою авторизації – це великий крок до нульової довіри.

Висновок
Нульова довіра – це потужна модель безпеки, що знаходиться на передньому краї сучасної безпеки. Якщо ви зможете прорватися крізь рекламний шум навколо неї, то побачите деякі глибокі і важливі переваги прийняття нульової довіри. І хоча нульова довіра вимагає деяких радикальних змін основних ідей, таких як ідентифікація, користувачі Kubernetes, принаймні, мають великі переваги, якщо вони зможуть прийняти сервісну сітку і перейти від суто периметральної мережевої безпеки до “безперервної перевірки кожного користувача, пристрою, програми та транзакції”.

З питань проведення індивідуальної демонстрації, пілотного тестування рішення Algosec і організації партнерських тренінгів звертайтеся, будь ласка: info.ua@oberig-it.com, +38 093 801 04 41.

Джерело: https://bit.ly/3SKRpQb