Наскрізне зашифроване потокове передавання для військових командних систем

Захищене потокове передавання для військового командування — це не одна проблема, а стек задач, що перетинаються і кожна з яких потребує точної інженерії. Безпілотник передає ISR-відео зі швидкістю 4–8 Мбіт/с. Масив сенсорів генерує тисячі телеметричних подій за секунду. Голосовий канал передає накази, які мають надходити протягом 200 мс, інакше зв'язок руйнується. Кожен потік має різні вимоги до затримки, надійності та рівня класифікації, але всі вони мають проходити через зашифрований конвеєр, що витримує деградацію мережі, відмову брокера та довготривалу загрозу квантових обчислень.

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

Сценарії використання, що формують вимоги

Перед затвердженням архітектури корисно чітко визначити, що конвеєр має передавати.

ISR-відео з безпілотників

Відео з повним рухом від розвідувального безпілотника — це потік із найвищою пропускною здатністю в стеку. При кодуванні H.265 один потік займає 2–8 Мбіт/с залежно від роздільної здатності та складності сцени. Зазвичай вимога до затримки — менше 500 мс наскрізно, щоб аналітики могли управляти повітряним судном у режимі, близькому до реального часу. Втрата кадрів понад 2–3% робить потік непридатним до використання, що виключає будь-який транспорт, нездатний грамотно обробляти перевантаження. Класифікація часто є «Таємно» або вище, тобто шифрування обов'язкове у стані зберігання та під час передавання.

Зашифровані голосові комунікації

IP-телефонія в тактичному контексті використовує кодек Opus на 6–32 кбіт/с з цільовою одностороньою затримкою менше 150 мс. Жорстке обмеження — джитер, а не пропускна здатність, руйнує якість голосу. Стандартний буфер джитеру — 20 мс; все, що перевищує 60 мс, потребує агресивного відтворення. Шифрування додає фіксовані накладні витрати на пакет, тому вибір шифру має значення: потокові шифри або апаратно прискорені блокові режими на кшталт AES-256-GCM утримують затримку на пакет нижче 0,1 мс на сучасному обладнанні.

Телеметрія сенсорів

Бойовий масив сенсорів — трекери позиції, радари, приймачі радіоелектронної боротьби — може генерувати десятки тисяч дрібних повідомлень за секунду. Кожне повідомлення може мати лише 200–500 байт. Сукупна пропускна здатність є помірною (5–50 Мбіт/с), але швидкість повідомлень навантажує шлях запису брокера та швидкість десеріалізації споживача. Телеметрія допускає дещо вищу затримку, ніж голос — 1–5 секунд прийнятно для більшості робочих процесів сенсорного синтезу, — але обсяг вимагає брокера, здатного справлятися з високим рівнем розподілу без блокування голови черги.

Розподіл C2-подій

Події командування та управління — завдання, ситуаційні доповіді, дозволи на ураження — мають малий обсяг, але високу цілісність. Втрата або пошкодження C2-повідомлення є оперативно небезпечним. Ці потоки вимагають семантики доставки «рівно один раз», надійної автентифікації системи-продюсера та журналу аудиту, який неможливо підробити постфактум. Вимоги до затримки варіюються: завдання може допускати 2–5 секунд доставки, тоді як аварійне скасування має досягти всіх споживачів протягом 500 мс.

Оновлення логістики та ланцюга постачання

Логістичні дані — позиції колон, рівні запасів, стан технічного обслуговування — мають нижчу чутливість, але в більшості контекстів все одно є класифікованими. Частота оновлень зазвичай становить раз на 30–300 секунд для одного активу, тобто брокер обробляє це як топік із помірною швидкістю. База споживачів широка: офіцери штабу, логістичне програмне забезпечення та автоматизовані системи поповнення запасів підписуються незалежно.

Рівні архітектури

Транспортний рівень: DTLS і TLS

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

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

У всіх випадках налаштовуйте набори шифрів так, щоб вимагати AES-256-GCM та відхиляти будь-яке узгодження нижче TLS 1.3 або DTLS 1.3. Увімкніть взаємний TLS (mTLS), щоб і продюсери, і споживачі надавали клієнтські сертифікати — це запобігає введенню даних або читанню потоків неавтентифікованим пристроєм, навіть якщо він має доступ до мережі.

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

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

Критичним архітектурним рішенням є сегментація топіків за рівнем класифікації. Змішування даних «Таємно» та «Несекретно» в одному топіку — навіть якщо обидва зашифровані — створює ризик міждоменного забруднення. Створюйте окремі топіки для кожної класифікації, забезпечуйте дотримання ACL через рівень авторизації Kafka (або RBAC Azure Event Hubs) та повністю вимикайте відкриті слухачі. Обліковий запис служби, що продукує до топіку ISR з класифікацією «Таємно», не повинен мати дозволу на читання будь-якого іншого топіку.

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

Рівень споживача: C2-дисплеї та аналітика

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

Моніторинг відставання споживача є обов'язковим. Дисплей, що відстає від живого ISR-потоку на 10 хвилин, оперативно еквівалентний відсутності потоку взагалі. Відстежуйте зміщення груп споживачів за допомогою Prometheus і Grafana (або еквівалентного локального інструментарію) та сповіщайте, коли будь-яка група перевищує налаштований поріг відставання. Для найбільш критичних споживачів налаштуйте максимальну відстань зміщення, що ініціює оперативне сповіщення до того, як позиція споживача вийде за межі вікна зберігання брокера.

Управління ключами для потокового передавання

Ефемерні ключі сесії

Кожна сесія потокового передавання використовує унікальний ключ шифрування даних (DEK), що генерується на початку сесії. DEK шифрує фактичне корисне навантаження потоку за допомогою AES-256-GCM. Сам DEK загортається ключем шифрування ключів (KEK), що зберігається у KMS з апаратним забезпеченням — Azure Key Vault з HSM, HashiCorp Vault з апаратним бекендом або локальний HSM рівня FIPS 140-3 Level 3.

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

Ротація ключів без переривання потоку

Ротація DEK під час активної сесії без втрати кадрів потребує підходу подвійного ключування. Перед інтервалом ротації KMS надає новий DEK та розповсюджує його ідентифікатор через спеціальний внутрішній топік оголошень ключів. Продюсери починають маркувати нові кадри ідентифікатором нового ключа, поки попередній залишається дійсним. Споживачі кешують обидва ключі під час налаштованого вікна перекриття — зазвичай від 30 до 60 секунд.

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

Інтервали ротації залежать від рівня класифікації та позиції щодо ризику. Розумна базова лінія — 15–60 хвилин для ISR-відео та 5–15 хвилин для C2-каналів подій. Сесії з даними «Цілком таємно» можуть ротуватися кожні 2–5 хвилин. Накладні витрати ротації визначаються затримкою звернення до KMS (зазвичай 10–50 мс), а не самою операцією шифрування.

Інтеграція постквантового захисту

Як детально описано в нашому попередньому аналізі відповідності CNSA 2.0 для оборонних систем, набір комерційних алгоритмів національної безпеки версії 2 АНБ США вимагає постквантових алгоритмів для всіх нових класифікованих систем. Для конвеєрів потокового передавання це має два конкретних наслідки.

ML-KEM для встановлення ключів

ML-KEM-768 (NIST FIPS 203, раніше CRYSTALS-Kyber) замінює або доповнює ECDH у рукостисканні, що встановлює DEK сесії. Гібридна конструкція X25519 + ML-KEM-768 забезпечує захист від класичних і квантових зловмисників у перехідний період — якщо один з алгоритмів буде зламано, ключ сесії залишається безпечним, оскільки для цього необхідно зламати обидва одночасно.

Публічний ключ ML-KEM-768 становить 1 184 байти, а шифротекст — 1 088 байт, що більше за обмін ключами ECDH, але цілком вписується в бюджет розширення TLS або заголовка власного рукостискання. На серверному процесорі 3 ГГц генерація ключа ML-KEM-768 займає приблизно 0,1 мс, а декапсуляція — 0,15 мс. Це одноразові витрати на сесію, а не на кожен кадр.

AES-256-GCM для масового шифрування

Постквантові алгоритми використовуються для встановлення ключів, а не для масового шифрування даних. AES-256-GCM з апаратним прискоренням (інструкції AES-NI, доступні на всіх сучасних серверних процесорах x86 та ARM) шифрує масові потокові дані зі швидкістю 3–10 ГБ/с на ядро. Потік ISR-відео 4 Мбіт/с потребує приблизно 0,4 Мбіт/с фактичної пропускної здатності AES після накладних витрат кодека — незначне навантаження на будь-який сучасний процесор. Накладні витрати шифрування для корисного навантаження 1 МБ становлять менше 0,1 мс.

ML-DSA для автентифікації продюсера

Кожен заголовок кадру несе цифровий підпис, що автентифікує систему-продюсер. ML-DSA-65 (NIST FIPS 204, раніше CRYSTALS-Dilithium) забезпечує постквантовий захист підпису. Підписання дайджесту повідомлення з 48 байт за допомогою ML-DSA-65 займає приблизно 0,3 мс на серверному обладнанні; верифікація — 0,2 мс. Для телеметрії з високою швидкістю пакетне підписання кореня Меркла для групи зі 100 повідомлень амортизує цю вартість до менш ніж 0,01 мс на повідомлення.

Продуктивність: реалістичний бюджет затримки

Розуміння джерел затримки є необхідним перед оптимізацією. Реалістична розбивка для ISR-відеокадру, що подорожує від сенсора безпілотника до C2-дисплея по деградованому тактичному каналу:

• RTT мережі (від безпілотника до наземної станції): 20–80 мс залежно від типу каналу (супутниковий зв'язок проти прямовидимого радіо)
• Рукостискання DTLS (амортизоване на сесію): 1–3 мс, включно з обміном ML-KEM-768
• Шифрування AES-256-GCM на кадр: <0,1 мс
• Запис до брокера Kafka + підтвердження реплікації: 2–8 мс на спільно розміщеному брокері; 15–40 мс між зонами доступності
• Отримання споживачем та пошук у кеші DEK: 0,5–2 мс
• Розшифрування AES-256-GCM на кадр: <0,1 мс
• Конвеєр рендерингу дисплея: 5–16 мс (один кадр при 60 fps)

Загальна наскрізна затримка: 30–150 мс на добре забезпеченій тактичній мережі. Компоненти шифрування — і класичні, і постквантові — становлять менше 5 мс від загального. Основні витрати — RTT мережі та затримка реплікації брокера. Оптимізація вибору шифру має незначний вплив; оптимізація розміщення брокера та вибору мережевого маршруту — суттєвий.

Для голосу відповідним числом є накладні витрати DTLS на пакет: менше 0,1 мс на кадр Opus тривалістю 20 мс, що нижче порогу сприйняття. Постквантове рукостискання — це одноразові витрати під час встановлення сесії, а не накладні витрати на пакет.

Стійкість: що відбувається, коли щось іде не так

Відмова брокера

Кластер Kafka з трьома брокерами та коефіцієнтом реплікації 3 (min.insync.replicas=2) витримує втрату будь-якого одного брокера без втрати даних і з мінімальним перериванням. Обрання лідера розділу при відмові зазвичай завершується за 5–30 секунд з налаштуваннями за замовчуванням; налаштування unclean.leader.election.enable=false та зменшення replica.lag.time.max.ms до 5000 мс тримає це вікно щільним.

Продюсери повинні налаштовувати повторні спроби з експоненційним відступом та ідемпотентний режим продюсера (enable.idempotence=true), щоб запобігти дублюванню повідомлень під час обрання лідера. Споживачі, що використовують автоматичне підтвердження, повинні вимкнути його та підтверджувати зміщення лише після успішної обробки, щоб запобігти втраті повідомлень при перезапуску споживача.

Відставання споживача

Споживач, який відстає, може зрештою вийти за межі вікна зберігання брокера, назавжди втративши повідомлення. Для ISR-відео налаштуйте строк зберігання відповідно до оперативного темпу — 4 години є розумною базовою лінією для тактичних потоків. Для C2-подій, які ніколи не можна втратити, збільште зберігання до 7–30 днів та розгляньте окремого архівного споживача, що записує до зашифрованого довгострокового сховища.

Коли споживач не може розшифрувати повідомлення — наприклад, через те, що його кеш DEK застарів, а KMS тимчасово недоступний — направляйте необроблюване повідомлення до топіку мертвих листів, а не відкидайте його тихо. Оператор може потім дослідити ситуацію та відтворити повідомлення після відновлення KMS.

Ротація ключів під час активної сесії

Ротація подвійним ключуванням, описана вище, обробляє звичайний випадок. Граничний випадок — KMS стає недоступним під час ротації. Правильна поведінка — подовжити дійсність поточного DEK до відновлення доступності KMS — а не повертатися до незашифрованого передавання. Налаштуйте максимальний вік ключа, після якого продюсер призупиняє потік, а не продовжує з простроченим ключем. Це навмисний оперативний компроміс: коротке переривання потоку є кращим за передавання без шифрування по класифікованому каналу.

Шаблони розгортання

Хмарне розгортання: Azure Event Hubs та Corvus.Quantum

Azure Event Hubs забезпечує керовану поверхню Kafka з вбудованою гео-надмірністю та підтримкою приватних кінцевих точок через Azure Private Link. У поєднанні з Azure Key Vault Managed HSM для зберігання ключів це знімає операційний тягар управління інфраструктурою Kafka, зберігаючи сумісність протоколу, що дозволяє стандартним клієнтам Kafka підключатися без змін.

Corvus.Quantum безпосередньо інтегрується з цим стеком, додаючи рівень постквантового встановлення ключів, автентифікацію продюсера ML-DSA та автоматизоване управління ротацією ключів. Платформа опрацьовує складність інтеграції KMS, життєвого циклу DEK та синхронізації ключів груп споживачів — інженерні команди інтегруються на рівні застосунку та успадковують засоби контролю безпеки, а не будують їх з нуля.

Локальне розгортання в ізольованому середовищі

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

Вибір HSM для ізольованих розгортань повинен відповідати щонайменше FIPS 140-3 Level 3 для даних рівня «Таємно». Мережева сегментація між мережею брокера та мережею споживача за допомогою однонаправленого шлюзу забезпечує односпрямований потік даних для потоків, де споживачі не повинні впливати на продюсерів.

Гібридне розгортання

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

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

Чому операційний досвід має значення

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

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

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

Резюме

Захищений конвеєр потокового передавання для військового командування будується з компонованих, добре відомих компонентів: DTLS/TLS 1.3 для транспорту, Kafka для брокера, AES-256-GCM для масового шифрування, ML-KEM-768 для постквантового встановлення ключів та схема конвертного шифрування на основі KMS для управління ключами. Жоден з цих компонентів не є екзотичним. Інженерна задача полягає в їх правильній інтеграції, експлуатації в умовах змагального середовища та забезпеченні того, щоб події життєвого циклу ключів — ротація, відкликання, відмова KMS — не створювали прогалин у покритті шифруванням.

Постквантова криптографія додає вимірювані, але керовані накладні витрати: менше 1 мс на сесію для встановлення ключів, менше 0,1 мс на повідомлення для підписання, амортизованого по пакетах. Бюджет затримки визначається мережею та брокером, а не криптографією. Інвестуйте зусилля з оптимізації відповідно.

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

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

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