Apache Kafka для оборони: архітектура захищеного обміну повідомленнями в реальному часі

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

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

Чому потокова передача подій підходить для оборонних архітектур

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

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

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

Основна архітектура Kafka для секретних середовищ

Топологія брокерів

Промисловий секретний кластер Kafka вимагає мінімум трьох вузлів брокерів для підтримки коефіцієнта реплікації три та параметра min.insync.replicas рівного двом. Ця конфігурація витримує втрату одного брокера без втрати даних або помилок виробника. Для високодоступних секретних розгортань п'ять брокерів — розподілених принаймні по трьох фізичних стійках або зонах доступності — забезпечують кращу відмовостійкість з запасом для поступових оновлень.

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

Партиціонування тем за рівнем таємності

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

Перший підхід використовує єдиний кластер з ізоляцією ACL на рівні тем. Теми мають простір імен за рівнем таємності: ts.sensor.uav-telemetry для телеметрії найвищого рівня таємності, s.c2.position-reports для даних C2 рівня SECRET, c.logistics.supply-events для конфіденційної логістики. Кожному обліковому запису служби надається право запису та читання лише тем, що відповідають його рівню допуску. Цей підхід зменшує операційну складність, але вимагає впевненості у виконанні ACL Kafka та ретельної сегментації мережі, щоб самі процеси брокерів не були шляхом для бокового переміщення.

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

Зберігання та кількість партицій

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

Рішення щодо політики зберігання мають бути задокументованими та обґрунтованими. Телеметрія датчиків, що аналізується майже в реальному часі, зазвичай потребує лише 24–72 годин зберігання, перш ніж її можна перемістити на холодне сховище або видалити. Журнали подій C2, необхідні для розгляду після виконання завдань, мають зберігатися 30–90 днів у гарячому рівні, після чого їх слід експортувати у зашифрований незмінний архів. Не покладайтеся лише на Kafka як на довгострокове сховище аудиту — це шина подій, а не архівна база даних.

Шифрування при передачі: TLS 1.3 та SASL SCRAM

Секретні середовища вимагають шифрування на кожному шляху передачі даних. Для Kafka це означає два окремих засоби контролю: транспортне шифрування та автентифікація клієнта.

Конфігурація TLS 1.3

Налаштуйте кожен слухач Kafka — включаючи зв'язок між брокерами — за допомогою TLS 1.3. У server.properties:

listeners=SASL_SSL://0.0.0.0:9093
advertised.listeners=SASL_SSL://broker-1.internal:9093
ssl.protocol=TLSv1.3
ssl.enabled.protocols=TLSv1.3
ssl.keystore.location=/etc/kafka/ssl/broker.keystore.jks
ssl.keystore.password=${KEYSTORE_PASSWORD}
ssl.truststore.location=/etc/kafka/ssl/ca.truststore.jks
ssl.truststore.password=${TRUSTSTORE_PASSWORD}
ssl.client.auth=required

Параметр ssl.client.auth=required забезпечує взаємний TLS (mTLS): кожен клієнт, що підключається, повинен надати сертифікат, підписаний вашим внутрішнім центром сертифікації. Це гарантує, що лише відомі, підготовлені системи можуть підключатися до кластера — вимога в будь-якому секретному анклаві. Не використовуйте requested або none у секретних середовищах.

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

SASL SCRAM-SHA-512

Поверх mTLS використовуйте SASL SCRAM-SHA-512 для автентифікації на рівні користувача. Це прив'язує іменовану ідентичність — наприклад, обліковий запис служби для конкретного застосунку — до TLS-з'єднання, дозволяючи деталізоване виконання ACL на основі імені принципала, а не лише суб'єкта сертифіката.

sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
security.inter.broker.protocol=SASL_SSL

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

Шифрування у стані спокою: AES-256 та засоби контролю рівня сховища

Kafka не шифрує власноруч дані, записані у свої сегменти журналу. Шифрування у стані спокою є відповідальністю рівня сховища. Для розгортань на bare-metal або віртуальних машинах використовуйте LUKS (Linux Unified Key Setup) з AES-256 у режимі XTS на блочних пристроях, що містять log.dirs Kafka. Для розгортань на Kubernetes надавайте ресурси StorageClass, що підтримуються зашифрованими томами — у Azure Government використовуйте шифрування на стороні сервера з ключами, керованими клієнтом (SSE-CMK) на Azure Disk. Локальні еквіваленти включають NetApp з дисками NSE або програмний LUKS на стандартних NVMe.

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

Розгортання Kafka в ізольованих мережах за допомогою режиму KRaft

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

Режим KRaft та робота без ZooKeeper

Використовуйте Kafka 3.6 або новішу версію з увімкненим режимом KRaft. Кластер вимагає кворуму контролерів — зазвичай три вузли контролера, які можуть бути розміщені разом з брокерами у розгортаннях від трьох до п'яти вузлів. Кожному вузлу призначається node.id і значення process.roles рівне controller, broker або обидва.

Завантажте кластер за допомогою kafka-storage.sh format, щоб згенерувати UUID кластера і записати початковий журнал метаданих. Цей крок має виконуватися на кожному вузлі з однаковим UUID перед запуском будь-якого процесу брокера. В ізольованому середовищі згенеруйте UUID на одному вузлі, скопіюйте його на інші, потім запустіть format на кожному.

CLUSTER_ID=$(kafka-storage.sh random-uuid)
kafka-storage.sh format -t $CLUSTER_ID -c /etc/kafka/server.properties

Внутрішній DNS та управління сертифікатами

Налаштуйте advertised.listeners для використання повних доменних імен, що розпізнаються в межах анклаву — або через внутрішній DNS-сервер, або через /etc/hosts на кожному хості, який підключатиметься до кластера. Використання IP-адрес безпосередньо в advertised.listeners працює, але ускладнює управління сертифікатами, оскільки SAN сертифіката мають перераховувати кожну IP-адресу.

Запустіть автономний кореневий CA за допомогою step-ca або CFSSL — обидва не мають зовнішніх залежностей під час роботи. Генеруйте сертифікати брокерів з SAN, що охоплює ім'я хоста брокера. Розповсюджуйте кореневий сертифікат CA у трастове сховище кожного клієнта. Встановлюйте терміни дії сертифікатів відповідно до графіка повторної акредитації та ведіть реєстр сертифікатів, щоб поновлення не спричиняли несподіваних перебоїв.

Управління образами контейнерів та артефактами

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

Azure Event Hubs як сумісна з Kafka альтернатива

Не кожне оборонне навантаження вимагає повністю відключеного, самокерованого кластера. Для програм, що працюють у межах GovCloud — Azure Government, IL4 або IL5 — рівні Azure Event Hubs Premium та Dedicated надають сумісний з Kafka ендпоінт, який приймає стандартних виробників і споживачів Kafka без змін у коді. Поверхня протоколу сумісна з клієнтськими бібліотеками Kafka 1.0 і новіших версій.

Event Hubs в Azure Government задовольняє авторизацію FedRAMP High і, для рівня Dedicated, підтримує ключі, керовані клієнтом, через Azure Key Vault Managed HSM, забезпечуючи засіб контролю шифрування AES-256 у стані спокою, якого вимагають секретні навантаження. Операційна перевага значна: без підготовки брокерів, без ротації сертифікатів для самого кластера, вбудована географічна надмірність та SLA-гарантована доступність.

Компроміс очевидний: Event Hubs не підтримує повну поверхню API Kafka (без транзакцій, без семантики рівно-одного-разу між темами на рівні брокера, без власної моделі ACL поза RBAC рівня простору імен). А для навантажень, що мають бути повністю ізольовані — без з'єднання з будь-якою зовнішньою мережею — Event Hubs не є варіантом. Для таких програм самостійно розгорнуті кластери KRaft залишаються єдиним прийнятним рішенням.

Інтеграція нульової довіри для споживачів Kafka

Модель ACL Kafka є необхідним, але недостатнім засобом контролю безпеки у середовищі нульової довіри. Кожна служба-споживач має автентифікуватися за допомогою короткострокових облікових даних, виданих вашим постачальником ідентичності під час запуску поду або процесу, а не довгострокового статичного пароля. Механізм секретів Kafka у Vault може динамічно видавати короткострокові облікові дані SCRAM з автоматичним відкликанням після закінчення терміну дії. У поєднанні з клієнтськими сертифікатами mTLS, що ротуються за графіком, це гарантує, що скомпрометовані облікові дані служби мають обмежене операційне вікно для зловмисника.

Застосовуйте мережеві політики на рівні Kubernetes або брандмауера, щоб лише поди з правильними мітками могли досягати портів брокерів Kafka. Власні ACL Kafka мають бути другою лінією захисту, а не першою. Для повного розгляду архітектури нульової довіри, застосованої до оборонних мереж, дивіться статтю про архітектуру нульової довіри для військових мереж.

Corvus.Quantum: потокова передача на основі Kafka з постквантовим шифруванням

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

Крім шифрування, Corvus.Quantum надає попередньо загартовану конфігурацію брокера для секретних розгортань: шаблони кластерів у режимі KRaft, автоматизація сертифікатів TLS 1.3 з використанням вбудованого екземпляра step-ca, ротація облікових даних SCRAM, інтегрована з HashiCorp Vault, та шаблони ACL тем з урахуванням рівня таємності. Платформа перевірена у середовищах без інтернет-з'єднання, обробляючи тисячі подій від датчиків на секунду з наскрізною затримкою менше 100 мс.

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

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

• Архітектура нульової довіри для військових мереж
• Шаблони розгортання в ізольованих мережах для оборонних навантажень
• Постквантова криптографія та відповідність CNSA 2.0 для оборони