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

Ця стаття пропонує систему прийняття рішень для вибору між Azure Event Hubs та локальним Apache Kafka для оборонних навантажень, охоплює конкретні наслідки для відповідності та архітектури кожного варіанту, описує гібридну модель, що використовує обидві платформи для різних рівнів класифікації, та пояснює шлях міграції між ними при зміні вимог.

Чому рішення щодо платформи потокової обробки має значення в обороні

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

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

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

Azure Event Hubs: керована потокова обробка для навантажень GovCloud

Сумісний з Kafka API та нульове управління кластером

Рівні Azure Event Hubs Premium та Dedicated надають кінцеву точку протоколу, сумісного з Kafka. Виробники та споживачі, побудовані на основі клієнтської бібліотеки Apache Kafka, підключаються до простору імен Event Hubs, змінивши два значення конфігурації: bootstrap.servers вказує на <namespace>.servicebus.usgovcloudapi.net:9093 у Azure Government, а sasl.mechanism встановлюється на PLAIN з обліковими даними рядка підключення або на токен Azure Active Directory за допомогою механізму OAuth bearer. Жодних змін у коді, специфічному для Kafka, не потрібно. API сумісний з клієнтськими бібліотеками Kafka 1.0 і вище.

Операційний наслідок полягає в тому, що нікому у вашій команді не потрібно управляти підготовкою брокерів, конфігурацією кворуму контролерів, ротацією TLS-сертифікатів для кластера, сховищами облікових даних SCRAM або масштабуванням ємності. Одиниці пропускної здатності масштабуються на вимогу. Доступність підкріплена угодою про рівень обслуговування. Геозбитковість — це параметр конфігурації, а не проєкт багатоплощадкового розгортання.

Авторизація FedRAMP High, IL4 та IL5

Azure Event Hubs у Azure Government має авторизацію FedRAMP High. Рівень Dedicated, що забезпечує однотенантну інфраструктуру, підтримує рівні впливу IL4 та IL5 відповідно до матриці доступності сервісів Azure Government. Шифрування з ключами, керованими замовником, доступне через Azure Key Vault Managed HSM, задовольняючи вимогу AES-256 для даних у стані спокою, яку несуть навантаження IL5. Дані, що обробляються та зберігаються в Event Hubs Dedicated у Azure Government, не виходять за межі державної хмари.

Для програм, чия стеля класифікації — CONFIDENTIAL або FOUO, або навантажень SECRET із затвердженою точкою хмарного доступу, Event Hubs Dedicated у Azure Government часто є найшвидшим шляхом до відповідної інфраструктури потокової обробки. Інфраструктура брокерів охоплена пакетом авторизації FedRAMP від Microsoft, зменшуючи поверхню, яку ваша команда повинна документувати та захищати в плані безпеки системи.

Обмеження API та їх значення для оборонних застосунків

Event Hubs не реалізує повний Kafka API. Транзакції та семантика «рівно один раз» між кількома темами не підтримуються на рівні брокера. API управління ACL через AdminClient відсутні — контроль доступу здійснюється на рівні Azure RBAC (ролі Data Sender та Data Receiver на рівні простору імен або сутності), а не через власні ACL Kafka. Офсети груп споживачів управляються сервісом і не піддаються прямій маніпуляції через Kafka offset commit API так само, як у самостійно розгорнутому кластері.

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

Локальний Kafka: можливість ізольованої мережі та повний контроль класифікації

Єдиний життєздатний шлях для жорстких вимог до ізольованої мережі

Будь-яка програма з мандатом на роботу без зовнішнього мережевого підключення — чи то з міркувань фізичної безпеки, оперативної безпеки або акредитації — має лише одну життєздатну платформу потокової обробки: самостійно розгорнутий Kafka на локальній інфраструктурі. Не існує еквівалентного керованого сервісу, що функціонує без доступу до Інтернету. Azure Event Hubs, незалежно від його рівня відповідності, потребує підключення до площини управління Azure Government для підготовки ресурсів, ротації токенів SAS та прийому викликів API управління.

Локальний Kafka у режимі KRaft, розгорнутий без мережевих інтерфейсів, маршрутизованих за межі анклаву, задовольняє жорстку вимогу до ізольованої мережі. Всі залежності — JVM, бінарні файли Kafka, образи контейнерів, TLS-сертифікати — попередньо підготовлені локально до відключення мережі. Кластер потім працює безстроково без вихідного підключення. Детальний огляд шаблонів підготовки образів контейнерів та розгортання в ізольованих мережах наведено в статті про шаблони розгортання в ізольованих мережах для оборонних навантажень.

Режим KRaft та автономна робота кластера

Kafka 3.3 представила режим KRaft як заміну управлінню метаданими на основі ZooKeeper. Для оборонних розгортань KRaft є правильним стандартом для кожного нового кластера. Окремий ансамбль ZooKeeper додає три або більше додаткових вузлів, окремий домен відмов, окрему поверхню конфігурації та додатковий процес для патчування та захисту. KRaft консолідує управління кворумом контролерів у самому процесі брокера Kafka за допомогою журналу консенсусу на основі Raft.

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

Операційне навантаження та наслідки для кадрового забезпечення

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

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

Матриця рішень

Таблиця нижче відображає ключові фактори розгортання та відповідний вибір платформи.

Фактор Azure Event Hubs Локальний Kafka
Потрібна жорстка ізольована мережа Не підходить Повністю підтримується
FedRAMP High / IL4/IL5 Успадковується від Azure Gov Відповідальність оператора
Стеля класифікації даних IL5 / FOUO (GovCloud) SECRET / TS (ізольована мережа)
Необхідна операційна спроможність Мінімальна (керований сервіс) Висока (повні операції кластера)
Управління кластером Відсутнє (повністю керований) Повне (TLS, KRaft, патчі)
Еластичність пропускної здатності Еластична (одиниці пропускної здатності) Ручне масштабування брокерів
Повна поверхня Kafka API Часткова (без транзакцій) Повна

Гібридна архітектура: рівнева потокова обробка за рівнем класифікації

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

Практична відповідь — це багаторівнева архітектура: Azure Event Hubs у Azure Government обробляє рівень UNCLASSIFIED та FOUO, де авторизація FedRAMP High охоплює вимогу відповідності, а кероване масштабування справляється зі змінними швидкостями прийому. Локальний Kafka за ізольованим анклавом обробляє рівень SECRET та TS, де жодна зовнішня мережева залежність неприйнятна. Два рівні не з'єднані безпосередньо.

Рішення міждоменної передачі на межі рівнів

Там, де знижені або публічні дані повинні переходити із засекреченого рівня до незасекреченого — наприклад, знезаражений звіт про позицію, отриманий із засекреченого зведеного треку SECRET, — сертифіковане рішення міждоменної передачі (CDS) забезпечує межу. CDS перевіряє вихідні дані відповідно до визначеної політики вмісту, видаляє позначки класифікації та чутливі поля та вивільняє результат до незасекреченого простору імен Event Hubs. Прямого мережевого шляху між двома середовищами Kafka не існує. CDS є єдиним каналом, а його потоки даних задокументовані в плані безпеки системи та перевірені під час акредитації.

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

Шлях міграції: від Event Hubs до локального Kafka

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

Що змінюється під час міграції

На боці виробника та споживача змінюються три значення конфігурації. По-перше, bootstrap.servers переміщується з кінцевої точки простору імен Event Hubs на внутрішню адресу локального кластера Kafka. По-друге, security.protocol та sasl.mechanism змінюються з SASL_SSL із PLAIN на SASL_SSL із SCRAM-SHA-512. По-третє, конфігурація truststore змінюється з публічного ланцюжка сертифікатів сервісу Azure на внутрішній CA-сертифікат для локального кластера. Ідентифікатори груп споживачів, назви тем та вся логіка прикладного рівня залишаються без змін.

На боці інфраструктури локальний кластер Kafka повинен бути підготовлений, захищений та протестований із репрезентативним навантаженням перед переключенням виробників. Конфігурація тем — кількість партицій, коефіцієнти реплікації, політики збереження — має бути відтворена з простору імен Event Hubs у локальному кластері. Офсети груп споживачів з Event Hubs не можуть бути перенесені безпосередньо; плануйте вікно переключення, під час якого споживачі повторно обробляють з початку вікна збереження або з відомої контрольної точки.

Контрольний список перед міграцією

Перш ніж виконати переключення, переконайтеся, що локальний кластер пройшов перевірку безпеки: TLS 1.3 перевірено на всіх слухачах через openssl s_client, аудит ACL завершено за допомогою kafka-acls.sh --list, порти брокерів підтверджено недоступними ззовні анклаву через мережеве сканування, та всі облікові дані SCRAM сервісних облікових записів зберігаються у системі управління секретами з налаштованою ротацією. Задокументуйте процедуру переключення в посібнику та виконайте пробний запуск із непродуктивними навантаженнями перед міграцією засекречених потоків даних. Щодо засобів управління мережею з нульовою довірою, які мають охоплювати рівень Kafka, дивіться статтю про архітектуру нульової довіри для військових мереж.

Corvus.Quantum: двохрежимна потокова обробка для засекречених оборонних програм

Corvus.Quantum — це захищена платформа потокової обробки подій для оборонної сфери, що підтримує обидва режими розгортання, описані в цій статті. У розгортаннях GovCloud вона інтегрується з Azure Event Hubs Dedicated за допомогою ключів, керованих замовником, та автентифікації Azure Active Directory, забезпечуючи попередньо налаштований стек виробника та споживача з постквантовим шифруванням на прикладному рівні. У ізольованих розгортаннях вона працює на автономному кластері Kafka у режимі KRaft з TLS 1.3, SCRAM-SHA-512 та зашифрованим сховищем LUKS для брокерів — все попередньо захищено та перевірено для засекречених середовищ.

Платформа розгорнута в оперативних умовах для обробки оборонних даних у реальному часі, обробляючи тисячі подій на секунду з наскрізною затримкою менше 100 мс. Вона додає інкапсуляцію ключів CRYSTALS-Kyber та шифрування корисного навантаження AES-256-GCM на прикладному рівні, захищаючи вміст повідомлень від поточного перехоплення та майбутнього квантового дешифрування — вимога для даних сенсорів та ISR з тривалим часом чутливості.

Для програм, що вирішують питання вибору між Event Hubs та локальним Kafka, Corvus.Quantum усуває необхідність створення та підтримки окремих захищених конфігурацій для кожного режиму розгортання. Той самий застосунок підключається до будь-якого бекенду через той самий рівень абстракції, а шлях міграції між режимами не потребує змін у коді застосунку. Коли вимоги класифікації вашої програми змінюються, інфраструктура потокової обробки змінюється разом із ними.

Пов'язані статті

Corvus.Quantum забезпечує готову до виробництва платформу потокової обробки для оборонної сфери, що працює на Azure Event Hubs у GovCloud або на самостійно розгорнутому Kafka за ізольованою мережею — попередньо захищену, із постквантовим шифруванням та перевірену в активних оперативних розгортаннях. Якщо вашій програмі потрібна потокова обробка засекречених даних з високою пропускною здатністю без місяців роботи з безпеки, поговоріть з нашою командою.

Дізнатися більше про Corvus.Quantum →