Архітектура оборонного озера даних: від збору даних датчиків до запитів аналітиків

Сучасна оборонна організація генерує дані з такою швидкістю, що це руйнує традиційні припущення щодо баз даних. Одна ISR-платформа виробляє гігабайти зображень за одну місію. Колона з насиченими датчиками генерує тисячі позиційних звітів CoT за хвилину. Один сеанс збору SIGINT може виробляти терабайти необроблених даних I/Q до початку будь-якої обробки сигналів. Помножте ці обсяги на цілі об'єднані сили — сотні платформ, десятки типів датчиків, кілька рівнів класифікації — і проблема даних, що виникає в результаті, перестає бути проблемою бази даних. Це проблема озера даних.

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

Чому традиційні бази даних не справляються з оборонними даними у масштабі

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

NoSQL-бази даних вирішують проблему схем, але створюють нові: більшість із них не розроблені для аналітичних шаблонів запитів, яких вимагає розвідувальна робота (повне сканування таблиць, агрегування по мільйонах записів, пошук векторної схожості по вкладеннях документів). Бази даних часових рядів добре обробляють високочастотні потоки датчиків, але не справляються з ad-hoc аналітичними об'єднаннями. Шаблон оборонного озера даних вирішує всі ці прогалини шляхом розділення проблем збору, зберігання та запитів на незалежно масштабовані рівні.

Рівень збору: потокова передача проти пакетної обробки

Рівень збору — це точка входу вихідних даних в озеро. У оборонних середовищах домінують два різних підходи, і виробниче озеро потребує обох.

Потокова передача даних

Потоки датчиків у режимі реального часу — позиційні звіти, радарні треки, попередження радіоелектронної розвідки, чат-повідомлення, події відеоаналітики — надходять безперервно та повинні збиратися з низькою затримкою. Apache Kafka є домінуючим вибором з відкритим вихідним кодом для розгортань на власній інфраструктурі та ізольованих мережах (air-gapped). Топіки Kafka природно відображаються на джерела даних: один топік на тип датчика або канал. Списки контролю доступу (ACL) на рівні топіку забезпечують першу лінію захисту класифікації — секретний потік даних датчика потрапляє в секретний топік, і лише споживачі з відповідними обліковими даними можуть підписатися.

Для гібридних або хмарно-підключених розгортань Azure Event Hubs пропонує API-поверхню, сумісну з Kafka, з нативною інтеграцією в Azure Data Lake Storage Gen2 та Azure Synapse Analytics. Event Hubs Capture записує вхідні події безпосередньо в ADLS Gen2 у форматі Avro або Parquet, усуваючи потребу в окремому процесі-споживачі для вихідної зони приземлення. Операційне навантаження значно нижче, ніж при самостійно керованому Kafka, ціною зниженого контролю над політиками доступу на рівні топіку.

Реєстри схем — Confluent Schema Registry (для Kafka) або Azure Schema Registry — повинні бути обов'язковими для потокового збору. Реєстрація схем у точці входу запобігає поширенню деформованих повідомлень нижче за потоком та забезпечує версіоновані контракти для еволюції схем. Оновлення прошивки датчика, яке змінює назву поля або додає нові телеметричні поля, не повинне непомітно зламувати нижчу аналітику.

Пакетний збір

Не всі оборонні дані надходять у режимі реального часу. Щоденні зведені розвідувальні дампи, архівовані записи сигналів, бази даних історичних треків та імпортовані дані від союзних систем, як правило, надходять у вигляді масових передач за визначеним розкладом. Конвеєри пакетного збору простіші за потокові, але мають власні проблеми: файли можуть надходити у застарілих форматах (зображення NITF, STANAG 4607 GMTI, CSV-експорти зі застарілих систем C2), а розміри файлів можуть варіюватися від кілобайтів до сотень гігабайтів на передачу.

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

Рівень зберігання: від зони приземлення до структурованої зони

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

Вихідна зона приземлення

Вихідна зона приземлення є першим пунктом призначення для всіх вхідних даних — потокові події, записані як файли Avro або JSON-рядків, пакетні передачі, збережені у їхньому оригінальному форматі. Тут нічого не змінюється. Зона приземлення є криміналістичним записом: якщо помилка обробки пошкоджує набір даних нижче за потоком, зона приземлення є точкою відновлення. Зберігання здійснюється в об'єктних сховищах, сумісних з S3 — AWS S3, Azure Data Lake Storage Gen2, MinIO для розгортань на власній ізольованій інфраструктурі або Ceph для великомасштабних об'єктних сховищ на власних серверах.

Об'єкти в зоні приземлення іменуються за детерміністичною схемою ключів, яка кодує вихідну систему, рівень класифікації, тип даних та позначку часу надходження. Конвенція іменування на зразок raw/{classification}/{source}/{year}/{month}/{day}/{hour}/{uuid}.{ext} надає конвеєру перетворень надійну структуру партиціювання і дозволяє повторно обробляти конкретне часове вікно для одного джерела, не торкаючись непов'язаних даних.

Структурована зона: Parquet та Delta Lake

Структурована зона — це місце, де вихідні дані перетворюються на формат, який аналітичні рушії можуть ефективно запитувати. Поточним стандартом є стовпчасті файли Parquet, керовані форматом таблиць Delta Lake або Apache Iceberg. Стовпчастий формат Parquet значно зменшує обсяг введення-виведення для аналітичних запитів, що звертаються лише до частини полів — що є нормою для розвідувального аналізу. Запит для всіх повітряних треків у радіусі 50 км протягом шестигодинного вікна потребує лише стовпців широти, довготи, висоти, позначки часу та ідентифікатора треку, а не всієї схеми датчика з 80 полями.

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

Ізоляція за класифікацією

Межі класифікації повинні забезпечуватися на рівні зберігання, а не лише на рівні застосунку. Кожен рівень класифікації (Несекретно, Контрольована несекретна інформація, Конфіденційно, Таємно, Цілком таємно/SCI) вимагає фізично відокремлених сегментів або просторів імен сховища. Спільні сегменти з розмежуванням на основі шляхів є недостатніми — неправильно налаштована IAM-політика або програмна помилка в рівні контролю доступу може розкрити крос-класифікаційні дані, якщо об'єкти знаходяться в одному сегменті.

Кожен рівень класифікації використовує окремий ключ шифрування даних (DEK), керований апаратним модулем безпеки (HSM) або службою управління ключами з сертифікацією FIPS 140-2 Level 3. Шифрування застосовується на стороні сервера на рівні зберігання, щоб навіть фізичне вилучення носія не розкривало відкритий текст. Графіки ротації ключів визначаються для кожного рівня класифікації та повинні бути автоматизованими — ручна ротація ключів із частотою, необхідною для класифікованих даних, є операційно непрактичною.

Каталог даних та забезпечення класифікації

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

Apache Atlas (що зазвичай розгортається зі стеками екосистеми Hadoop) та AWS Glue Data Catalog (для хмарних або гібридних розгортань) є двома найбільш широко використовуваними варіантами. Обидва підтримують реєстрацію схем, відстеження походження та користувацькі атрибути метаданих. Рівень класифікації повинен бути обов'язковим атрибутом схеми — не необов'язковим тегом — щоб кожен набір даних у каталозі мав явну мітку класифікації, яку може забезпечити рівень запитів.

Видимість у каталозі також повинна відповідати політиці доступу: аналітик з допуском до рівня Таємно не повинен мати можливості переглядати записи каталогу для наборів даних рівня Цілком таємно, навіть якщо він не може запитувати базові дані. Для цього необхідно інтегрувати рівень авторизації каталогу з постачальником ідентифікації організації (Active Directory, LDAP або IdP, сумісний з SAML). Кожна подія доступу до каталогу повинна бути зафіксована в централізованому журналі аудиту разом із подіями запитів.

Рівень запитів: SQL, пакетна аналітика та векторний пошук

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

Ad-hoc SQL за допомогою Trino

Trino (раніше PrestoSQL) є стандартним вибором для ad-hoc SQL-запитів до великих наборів даних Parquet або Delta Lake. Архітектура конекторів Trino дозволяє одному запиту об'єднувати дані з кількох джерел — структурованої зони Delta Lake, живої операційної бази даних PostgreSQL та індексу Elasticsearch — в одному SQL-операторі. Для оборонної аналітики це означає, що аналітик може написати запит, який корелює історичні дані треків з озера з живими звітами про контакти з оперативної картини без експорту даних між системами.

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

Великомасштабна пакетна аналітика за допомогою Spark

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

Spark нативно інтегрується з Delta Lake і може безпосередньо читати Parquet із сховищ, сумісних з S3. У класифікованих середовищах завдання Spark повинні виконуватися в ізольованих кластерах або просторах імен відповідно до рівня класифікації, щоб завдання рівня Таємно не могло випадково звернутися до несекретного набору даних через неправильно налаштовану змінну шляху. Виконання завдань повинне журналюватися з тією самою детальністю аудиту, що й інтерактивні запити: власник завдання, рівень класифікації вхідних наборів даних, рівень класифікації вихідних наборів даних та позначка часу виконання.

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

Неструктуровані розвідувальні документи — звіти, транскрипти, перекладені перехоплення — погано вписуються в шаблони SQL-запитів. Аналітикам потрібен семантичний пошук: «знайти всі звіти, що стосуються порушення маршруту постачання поблизу цього орієнтиру», а не «знайти всі записи, де document_text LIKE '%маршрут постачання%'». Векторні вкладення, згенеровані мовною моделлю та збережені у векторній базі даних (pgvector на PostgreSQL або спеціалізований сервіс як Qdrant для розгортання на власній інфраструктурі), забезпечують такий тип семантичного пошуку.

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

Зберігання, видалення та журнал аудиту

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

Безпечне видалення класифікованих даних не може покладатися на стандартне видалення файлової системи або закінчення терміну дії об'єктів. Стандартне видалення позначає блоки зберігання як доступні для повторного використання, але не перезаписує їх. Для класифікованих даних необхідним підходом є криптографічне стирання, також відоме як crypto-shredding: кожен рівень класифікації використовує окремий DEK, і коли політика зберігання ініціює видалення, DEK ротується та попередня версія ключа знищується. Без DEK збережений шифротекст обчислювально неможливо відрізнити від випадкового шуму. Цей підхід масштабується на петабайтні набори даних без втрат продуктивності, характерних для процедур багаторазового перезапису.

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

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

Операційні міркування

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

Сумісність з ізольованими мережами (air-gap). Багато класифікованих розгортань не можуть підтримувати постійне підключення до інтернету. Усі компоненти стеку озера — Kafka, Spark, Trino, служба каталогу, векторне сховище — повинні розгортатися з локальних дзеркал пакетів та реєстрів контейнерів. Залежність від публічних репозиторіїв пакетів під час виконання є ризиком для безпеки та доступності в класифікованих середовищах.

Управління еволюцією схем. Оновлення прошивки датчиків, інтеграція нових платформ та зміна вимог до звітності з часом змінюватимуть схеми даних. Зміни схем у структурованій зоні повинні проходити процес управління змінами з оцінкою впливу на нижчестоячі системи: чи порушує зміна існуючі запити Trino? Чи вимагає вона ретроспективного заповнення (backfill) історичних даних? Засоби контролю еволюції схем Delta Lake (параметр mergeSchema) та вбудована версіонність схем Iceberg забезпечують технічні механізми, але процес управління навколо них є не менш важливим.

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