Мікросегментація нульової довіри для оборонних мереж: політика та забезпечення

Безпека периметра будувалася навколо простого припущення: трафіку, що виникає всередині межі, можна довіряти. В оборонній мережі це припущення ніколи не було повністю слушним, а в сучасному гібридному хмарному чи багатоанклавному середовищі воно архітектурно неспроможне. Зловмисник, який скомпрометував одну кінцеву точку чи викрав облікові дані сервісу, не зупиняється на периметрі — він переміщується бічно, ескалюючи від низькоцінних робочих навантажень до цілей високої цінності. Мікросегментація в межах архітектури нульової довіри — це контроль, який обмежує бічне переміщення єдиним скомпрометованим робочим навантаженням, а не цілим анклавом. Ця стаття розглядає, як проєктувати, забезпечувати та підтримувати політику мікросегментації на основі ідентичності в оборонних мережах, з особливою увагою до робочих навантажень, розміщених у Kubernetes, надання ідентичності робочих навантажень та механізмів забезпечення east-west.

Чому контролі лише на рівні периметра зазнають невдачі в оборонних середовищах

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

Плаский east-west трафік. Усередині VLAN чи підмережі робочі навантаження зазвичай комунікують без обмежень. Скомпрометований сервер застосунків може досягти бази даних, сервісу автентифікації, системи управління ключами та кожного іншого сервісу в тій самій підмережі — не тому, що є політика, яка це дозволяє, а тому, що немає політики, яка це забороняє. Вартість бічного переміщення зловмисника всередині плаского сегмента низька.

Компрометація на основі облікових даних перетинає периметри. Брандмауери периметра перевіряють заголовки пакетів, а не ідентичність робочого навантаження. Викрадений токен службового облікового запису чи сертифікат, що був дійсний для комунікації між двома сервісами, так само дійсний для комунікації від процесу зловмисника, що працює як цей сервіс. Брандмауер дозволяє трафік, бо він надходить з правильної IP-адреси джерела. Мікросегментація з криптографічною ідентичністю робочого навантаження вирішує це: принципал політики — не IP-адреса, а криптографічно засвідчена ідентичність робочого навантаження, яку зловмисник не може видати за свою без доступу до матеріалу приватного ключа, який є ефемерним і прив'язаним до робочого навантаження.

Архітектура мікросегментації: домени довіри та межі політики

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

Для типового оборонного застосунку, розміщеного на класифікованому кластері Kubernetes, доменами довіри можуть бути:

Домени рівня класифікації. Кожен анклав класифікації — unclassified, CUI, SECRET — є окремим доменом довіри. Жодна east-west комунікація не перетинає межі класифікації в межах площини мікросегментації. Крос-доменна комунікація маршрутизується виключно через акредитоване рішення крос-доменного обміну, яке виконує перевірку вмісту та повторне маркування.

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

Карта потоків комунікації, що виникає з цієї вправи — кожне джерело домену, домен призначення, порт і протокол, що є бізнес-обґрунтованими — стає авторитетним вхідним даним для розробки політики. Будь-який потік, якого немає на карті, заборонений за замовчуванням.

Ідентичність робочого навантаження: SPIFFE/SPIRE в середовищах Kubernetes

Мікросегментація на основі ідентичності вимагає, щоб кожне робоче навантаження володіло перевіреною ідентичністю, яку площина забезпечення політики може автентифікувати. Ідентичність на основі IP-адреси недостатня в динамічних контейнерних середовищах, де поди ефемерні, а IP перероблюються. Стандарт SPIFFE (Secure Production Identity Framework For Everyone) визначає портативну криптографічну модель ідентичності робочого навантаження, яка не залежить від базової інфраструктури.

Ідентичність SPIFFE виражається як URI: spiffe://trust-domain/path. У розгортанні Kubernetes з використанням SPIRE (еталонна реалізація SPIFFE) кожен под отримує X.509 SVID (SPIFFE Verifiable Identity Document) — короткоживучий сертифікат, що містить його SPIFFE ID як Subject Alternative Name. Домен довіри відповідає кластеру Kubernetes або межі федерації. Шлях кодує простір імен Kubernetes та службовий обліковий запис, наприклад spiffe://defense.cluster/ns/analytics/sa/enrichment-worker.

Критична властивість для оборонних розгортань — короткий TTL. SVID видаються з терміном дії 1 година (або менше, налаштовується) та автоматично ротуються агентом SPIRE, що працює на кожному вузлі. Якщо сертифікат скомпрометований, вікно вразливості обмежене TTL. Приватний ключ ніколи не залишає пам'ять робочого навантаження — він не записується на диск і недоступний для інших процесів на тому самому вузлі, навіть у контексті спільного кластера Kubernetes.

Атестація вузлів у класифікованих кластерах

Атестатор вузлів SPIRE — це механізм, за допомогою якого новий вузол, що приєднується до кластера, доводить свою ідентичність, перш ніж йому буде дозволено видавати SVID робочим навантаженням. У класифікованому середовищі Kubernetes атестатор вузлів має бути обраний відповідно до моделі довіри. Для локального класифікованого обладнання атестація на основі TPM — з використанням Trusted Platform Module вузла для доведення апаратної ідентичності — є кращою моделлю. Сервер SPIRE перевіряє ключ підтвердження TPM на відповідність відомому-надійному маніфесту, перш ніж авторизувати вузол діяти як видавець SVID. Це означає, що зловмисник, який провадить неавторизований вузол, не може отримати дійсні SVID від сервера SPIRE, навіть якщо має мережевий доступ до сервера API кластера.

Забезпечення east-west: service mesh та eBPF

Надання ідентичності робочого навантаження необхідне, але недостатнє — площина забезпечення має фактично використовувати ці ідентичності для дозволу чи заборони трафіку. У захищеному середовищі Kubernetes забезпечення east-west зазвичай нашароване через три взаємодоповнюючі механізми.

Kubernetes NetworkPolicy: базовий рівень L3/L4

Ресурси Kubernetes NetworkPolicy надають декларативний спосіб вказати, які поди можуть комунікувати, використовуючи селектори міток подів та селектори просторів імен для ідентифікації джерела та призначення. Забезпечення NetworkPolicy обробляється плагіном CNI (Container Network Interface). Ключове обмеження стандартного NetworkPolicy полягає в тому, що він працює на рівні L3/L4 — він може дозволяти чи забороняти трафік між групами подів на основі IP та порту, але не може перевіряти ідентичність робочого навантаження, що встановлює з'єднання, метод HTTP, який викликається, чи вміст запиту. Для оборонної моделі мікросегментації, що вимагає криптографічної ідентичності, NetworkPolicy є необхідним базовим рівнем, але не повним контролем.

Service mesh із взаємним TLS: забезпечення L7 з усвідомленням ідентичності

Service mesh, встановлений у строгому режимі взаємного TLS, додає криптографічну перевірку ідентичності до кожного east-west з'єднання. Кожен виклик сервіс-до-сервісу автентифікується на транспортному рівні: клієнт пред'являє свій SVID, сервер пред'являє свій SVID, і кожен перевіряє іншого на відповідність пакету довіри SPIFFE. Політика авторизації service mesh потім оцінює автентифікований принципал (перевірений SPIFFE ID) на відповідність правилу політики, перш ніж дозволити запит.

Для оборонних розгортань service mesh має бути налаштований з криптографічними бібліотеками, валідованими за FIPS 140-2 або FIPS 140-3. Як Istio, так і Linkerd можуть бути скомпільовані проти BoringCrypto (валідований за FIPS) або еквівалента. Набори шифрів, узгоджені для mTLS, мають бути обмежені схваленим набором — TLS 1.3 з AES-256-GCM-SHA384 як мінімум для класифікованих середовищ. Повний перелік дозволених наборів має бути задокументований як частина базової конфігурації безпеки системи.

Забезпечення на основі eBPF: політика на рівні ядра

Забезпечення service mesh працює на рівні проксі-сайдкара, який виконується всередині мережевого простору імен контейнера. Достатньо привілейований зловмисник, який може скомпрометувати середовище виконання контейнерів чи сам под, може бути здатний обійти проксі-сайдкари. Забезпечення мережі на основі eBPF (реалізоване плагінами CNI, такими як Cilium) працює нижче середовища виконання контейнерів, на мережевому стеку ядра Linux. Програми eBPF, приєднані до хуків ядра, оцінюють мережеву політику, перш ніж пакети будуть доставлені до будь-якого процесу простору користувача — включно з проксі-сайдкаром. Робоче навантаження, яке обходить свій проксі-сайдкар, все одно не може досягти неавторизованих призначень, оскільки рівень забезпечення eBPF забороняє пакет на рівні ядра.

Комбінація NetworkPolicy + mTLS service mesh + забезпечення eBPF створює стек мікросегментації з ешелонованим захистом, де кожен рівень незалежно забезпечує політику. Збій у будь-якому окремому рівні не призводить до необмеженого бічного переміщення.

Життєвий цикл політики: розробка, тестування та підтримка правил мікросегментації

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

Політика як код. Політика мікросегментації має контролюватися версіями поряд з кодом застосунку. Кожен ресурс NetworkPolicy, AuthorizationPolicy та CiliumNetworkPolicy має жити в репозиторії розгортання застосунку. Зміни політики проходять той самий процес перегляду та схвалення, що й зміни коду — включно з оглядом безпеки для будь-якого правила, що розширює межу дозволу. Це запобігає накопиченню тимчасових винятків брандмауера поза контролем версій.

Тестування в тіньовому режимі. Перш ніж застосовувати нову чи змінену політику в режимі забезпечення, протестуйте її в тіньовому режимі (лише журналювання). І service mesh, і площина забезпечення eBPF можуть працювати в режимі аудиту, де порушення політики журналюються, але не блокуються. Запуск у тіньовому режимі протягом визначеного періоду (зазвичай від одного до двох тижнів у середовищі підготовки, що віддзеркалює шаблони виробничого трафіку) виявляє недокументовані потоки, які політика заблокувала б, перш ніж вони спричинять виробничі збої. Недокументовані потоки, виявлені в тіньовому тестуванні, мають бути переглянуті — легітимні потоки запускають додавання політики, тоді як нелегітимні потоки є доказом наявної проблеми безпеки.

Автоматизоване виявлення дрейфу політики. Телеметрія потоків service mesh (Hubble в Istio, Viz в Linkerd) надає погляд у реальному часі на весь east-west трафік. Автоматизований інструментарій, що порівнює спостережуваний трафік зі схваленою картою потоків і сповіщає про відхилення, є стандартною операційною вимогою для оборонного розгортання мікросегментації. Нові потоки, що з'являються без відповідного оновлення політики, є негайними кандидатами на сповіщення — або застосунок змінився без оновлення документації політики, або неавторизований актор генерує неочікуваний трафік.

Мікросегментація в багатоанклавних та ізольованих середовищах

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

У ізольованому класифікованому кластері сервер SPIRE має працювати повністю локально. Корінь PKI, що анкерує довіру SVID, не може покладатися на жодний зовнішній центр сертифікації. Кореневий CA та проміжні CA сервера SPIRE генеруються та управляються на ізольованих HSM (Hardware Security Modules) у межах класифікованого середовища. Списки відкликання сертифікатів та сервіси OCSP мають так само працювати в межах ізоляції — мережеві виклики до зовнішньої інфраструктури для операцій PKI не дозволені в класифікованих мережевих архітектурах.

Координація міжанклавної мікросегментації — забезпечення того, що політика, яка дозволяє потік з анклаву CUI до анклаву unclassified, віддзеркалена в наборах політик обох анклавів — є ручним та аудитованим процесом у більшості програм. Рішення крос-доменного обміну, яке посередничає міжанклавному трафіку, є авторитетним джерелом того, які потоки дозволені через межу; політики мікросегментації з обох сторін мають бути узгоджені з конфігурацією CDS та переглядатися як одне ціле під час контролю змін політики.