Архітектура data mesh для розвідувальних організацій оборонного сектору

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

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

Що таке data mesh і що ним не є

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

Порівняння з data lake є показовим. Data lake централізує і зберігання, і відповідальність: платформна команда збирає все, зберігає і будує конвеєри для споживачів. Це добре працює, коли платформна команда має достатньо доменних знань для підтримки кожного конвеєра. На практиці цього немає. Коли система збору SIGINT змінює вихідну схему, конвеєр центральної команди ламається, і ніхто не помічає цього, доки аналітик не повідомить про застарілі дані через три тижні. У data mesh команда домену SIGINT є власником конвеєра і контракту схеми — вона першою дізнається про зміну в системі збору.

Чому централізовані архітектури не працюють у розвідці

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

Друга — організаційні бар'єри. Організації оборонної розвідки структуровані навколо дисциплін збору — HUMINT, SIGINT, GEOINT, OSINT — кожна зі своєю культурою, інструментами та інституційними стимулами. Централізована платформа даних, що намагається стерти ці межі, зустрічає політичний опір і виробляє конвеєри, що погано задовольняють вимоги будь-якого домену.

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

Доменне володіння в розвідувальному контексті

В оборонному data mesh домени природно відображаються на дисципліни INT: HUMINT, SIGINT, GEOINT, MASINT та OSINT кожен складає окремий домен. Кожна доменна команда — комірка збору та аналізу, відповідальна за цю дисципліну — є власником продуктів даних, які вона публікує в mesh. Власність — не формальне позначення; вона несе конкретну відповідальність.

Доменна команда в оборонному data mesh відповідає за: визначення контракту схеми для кожного продукту даних; підтримку конвеєра збору від вихідних систем до продуктів даних; виконання SLA, прикріплених до кожного продукту (актуальність, доступність, повнота); реагування на проблеми якості даних, які повідомляють команди-споживачі; управління версіями схеми та циклами застарівання.

У класифікованому середовищі доменне володіння також означає управління метаданими секретності, прикріпленими до продуктів даних. Команда домену SIGINT визначає рівень секретності кожного продукту, застереження щодо розкриття та правила успадкування для похідних продуктів. Це значна відповідальність, але саме команда SIGINT унікально кваліфікована для її несення.

Продукти даних для розвідки

Концепція продукту даних є одиницею обміну в data mesh. Продукт даних — це не необроблене скидання даних або таблиця бази даних, а курована, задокументована та контрактно керована точка взаємодії. Визначальні характеристики: він доступний для виявлення (знаходиться в каталозі), адресований (запитується через стабільний інтерфейс), надійний (підтримується SLA з моніторингом), самоописовий (задокументована схема з семантикою полів) та сумісний (відповідає стандартам управління).

В організації оборонної розвідки продукти даних набувають конкретних форм. Команда домену SIGINT може публікувати продукт "поточна картина трас противника": колекція функцій GeoJSON активних трас, отриманих із сигнальної розвідки, оновлення кожні 15 хвилин, відповідно до схеми трас MIP4, класифікована на рівні ТАЄМНО. Аналітична комірка ELINT може публікувати продукт "база даних емітерів": версійований каталог відомих записів параметрів емітерів, оновлення протягом чотирьох годин після нового збору.

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

Федеративне управління

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

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

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

Самообслуговувана інфраструктура для класифікованих середовищ

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

Типовий стек платформи для класифікованого оборонного data mesh включає: рівень об'єктного зберігання (MinIO або Ceph для розгортань із повітряним зазором); реєстр схем для версійованого управління схемами; службу каталогу даних (Apache Atlas або власна реалізація) для виявлення та документування продуктів; рівень контролю доступу, інтегрований з постачальником ідентичності організації та PKI-інфраструктурою; та сервіс моніторингу для відстеження SLA. Кожен компонент повинен встановлюватися з локальних дзеркал пакетів та реєстрів контейнерів.

Служба каталогу в класифікованому середовищі стикається зі специфічною проблемою: видимість каталогу сама по собі має поважати секретність. Аналітик, допущений до рівня ТАЄМНО, не повинен мати можливості переглядати записи каталогу для продуктів рівня ЦІЛКОМ ТАЄМНО, навіть якщо базові дані недоступні.

Проблеми реалізації та шлях міграції

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

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

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

Для детального розгляду базової архітектури зберігання, на якій розміщуються доменні продукти даних, дивіться Архітектура data lake для оборони: проектування та операції. Для шаблонів злиття, що споживають продукти даних між INT-доменами, дивіться Злиття військових даних: архітектури та методи. Для конвеєрів збору, що заповнюють доменні продукти, дивіться Побудова конвеєра злиття оборонних даних, частина 1: джерела та схеми.