Військове й комерційне озера даних мають одну спільну основну ідею — дешеве масштабоване об'єктне сховище як фундамент аналітики, — але різко розходяться за кожним обмеженням, що має операційне значення. Забезпечення рівнів секретності, доступ з урахуванням компартментів, робота в ізольованому середовищі (air-gap) і критично важливі для місії SLA запитів — це не додаткові функції для оборонного розгортання, а несучі вимоги, що формують кожен рівень архітектури — від іменування бакетів сховища до налаштування рушія запитів. Архітектура, яка розглядає їх як запізнілу доробку — додаючи мітку секретності до наявних шаблонів комерційних озер даних, — у кращому разі не пройде аудитів безпеки, а в гіршому призведе до порушень вимог відповідності.
Ця стаття послідовно розглядає повне проєктування промислового військового озера даних: рівень сховища, конвеєр завантаження з джерел C2, ISR і логістики, керування метаданими військового каталогу даних, контроль доступу за компартментами та шаблони аналітичних навантажень. Кожен розділ присвячено проєктним рішенням, що відрізняють систему, придатну до оперативного розгортання, від еталонної архітектури, яка в технічному документі (whitepaper) виглядає правильно, але ламається у разі зіткнення з реальними секретними даними.
Що має робити військове озеро даних, чого не робить комерційне — забезпечення рівнів секретності, доступ з урахуванням компартментів, робота в ізольованому середовищі (air-gap), критично важливі для місії SLA
Найфундаментальніша відмінність між комерційним і військовим озером даних — не вибір технології, а модель загроз. Комерційне озеро даних захищає від зовнішніх зловмисників і витоку даних інсайдерами. Військове озеро даних має захищати й від тоншого збою: коли авторизований користувач звертається до даних, на які має допуск, але які не уповноважений бачити в поточному контексті. Аналітик сигнальної розвідки з допуском «Цілком таємно» не повинен мати змоги запитувати набір даних HUMINT, віднесений до компартмента, якщо не має відповідного коду компартмента. Офіцер логістики з допуском «Таємно» не повинен мати змоги бачити розвідувальні дані ISR, навіть якщо вони також мають гриф «Таємно». Рівень секретності та належність до компартмента — ортогональні виміри доступу, і обидва мають забезпечуватися на кожному рівні системи.
Робота в ізольованому середовищі (air-gap) усуває будь-яку залежність від керованих хмарних сервісів. Немає керованого (managed) Kafka, хмарного каталогу, сервісу керування ключами, яким оперує вендор. Кожен компонент — об'єктне сховище, потоковий брокер, рушій запитів, каталог метаданих, апаратне забезпечення керування ключами — має розгортатися локально з пакетів, які можна передати в ізольоване середовище на затверджених носіях. Це обмеження виключає архітектури, що передбачають кінцеві точки оновлення, доступні з інтернету, сервери перевірки ліцензій або служби збору телеметрії. Це також означає, що команда експлуатації відповідає за весь життєвий цикл оновлення та встановлення виправлень для кожного компонента без шляху, яким керує вендор.
Критично важливі для місії SLA стосуються і свіжості даних, і затримки запитів. Аналітик зі злиття даних ISR, який запитує найновіше завантаження даних сенсорів, не може погодитися на багатогодинне вікно пакетного завдання Spark. Офіцер логістики, що будує модель поповнення запасів, потребує результатів запитів за хвилини, а не за дні. Ці вимоги змушують ухвалювати архітектурні рішення, які комерційні озера даних часто відкладають: постійно ввімкнені рушії запитів, які вже скомпілювали плани запитів на основі актуальної статистики каталогу, сховище гарячого рівня для свіжих даних і потокове завантаження, яке робить нові дані доступними для запитів за секунди після надходження, а не в наступному пакетному вікні. Щоб глибше ознайомитися з базовими шаблонами, що застосовуються на описаних тут рівнях, див. наш посібник про шаблони інтеграції оборонних даних.
Четверта вимога, яку комерційні озера даних також задовольняють недостатньо, — це багатодоменна інтеграція даних: об'єднання в одному запиті даних треків C2, даних сенсорів ISR, логістичних записів і геопросторових опорних шарів через межі рівнів секретності (з відповідним контролем). У комерційному озері об'єднання між доменами — це зручність для інженерії даних. У військовому озері це основний аналітичний сценарій використання, і він має бути можливим без послаблення забезпечення рівнів секретності. Рушій запитів повинен уміти об'єднувати таблиці з різних доменів даних, прозоро застосовуючи до кожної сторони об'єднання фільтри секретності на рівні окремих таблиць.
Проєктування рівня сховища — об'єктне сховище (MinIO/Ceph для локального розгортання), багаторівневе сховище (гаряче/тепле/холодне), іменування об'єктів і партиціонування для військових доменів даних
Об'єктне сховище — фундамент будь-якої сучасної архітектури озера даних, а для ізольованих військових розгортань вибір звужується до двох перевірених на практиці платформ: MinIO та Ceph. MinIO реалізує повний AWS S3 API із шифруванням у стані спокою AES-256, політиками IAM на рівні окремих бакетів, а також версіонуванням і блокуванням на рівні об'єктів — усе без жодної хмарної залежності. Її продуктивність на сучасному обладнанні з NVMe перевищує продуктивність комерційних хмарних об'єктних сховищ для навантажень послідовного запису, що є домінантним шаблоном для завантаження даних сенсорів. Ceph надає об'єктне, блокове та файлове сховище з одного кластера через свій RADOS Gateway, що робить його придатним для середовищ, де та сама фізична інфраструктура сховища має обслуговувати і об'єктне навантаження озера даних, і блокові томи для віртуальних машин. Для окремого розгортання озера даних MinIO операційно простіша; Ceph — правильний вибір, коли кластер сховища має обслуговувати також блокові та файлові інтерфейси.
Ізоляція за рівнями секретності реалізується на рівні бакетів, а не об'єктів. Кожен рівень секретності має власний простір імен бакетів:
Структура зон — сира (raw), структурована (structured), підготовлена (curated) — розбиває дані за етапом обробки всередині кожного рівня секретності. Сира зона містить дані точно в такому вигляді, у якому їх отримано від вихідних систем, у рідному форматі (CoT XML, NIEM XML, двійкові потоки сенсорів, експорти логістики у CSV). Ніщо в сирій зоні не змінюється після запису: це незмінний аудиторський запис того, що було отримано. Структурована зона містить дані після нормалізації до Parquet у табличному форматі Delta Lake — схему примусово застосовано, поля зіставлено з канонічними іменами, додано метадані про походження. Підготовлена зона містить готові для аналітиків агрегати, попередньо об'єднані багатодоменні представлення та підсумкові таблиці, що уможливлюють швидкі інтерактивні запити, не змушуючи кожного аналітика самостійно виконувати ту саму логіку об'єднання.
Структура ключів об'єктів для структурованої зони кодує всі виміри партиціонування, потрібні для ефективного pushdown запитів:
Багаторівневим сховищем керують політики життєвого циклу MinIO. Гарячий рівень використовує вузли на базі NVMe та містить дані за останні 30 днів — достатньо свіжі, щоб аналітики часто запитували їх для поточного оперативного аналізу. Через 30 днів об'єкти переходять на теплий рівень на високощільних жорстких дисках, де залишаються доступними для запитів, але з більшою затримкою. Через 180 днів об'єкти переходять на холодний рівень на високощільному архівному сховищі з настроюваною затримкою отримання даних. Порогові значення рівнів настроюються для кожного домену та кожного рівня секретності — дані сенсорів ISR з активних районів операцій можуть мати коротший перехід із теплого рівня в холодний, ніж архівні логістичні дані.
Архітектура конвеєра завантаження — потоки систем C2 (CoT/NIEM), завантаження даних сенсорів ISR, ETL логістичних систем, потокові та пакетні шаблони завантаження
Рівень завантаження має одночасно обробляти три принципово різні профілі швидкості даних: потокові дані високої швидкості із систем C2 та ISR, що генерують тисячі подій на хвилину; структуровані дані середньої швидкості із систем логістики та планування, що генерують сотні записів на годину; і пакетні експорти низької швидкості зі застарілих систем, які щодня або щотижня передають файлові вивантаження. Ці профілі потребують різних шаблонів завантаження, які мають чисто взаємодіяти на межі зони приймання.
Apache Kafka — потокова магістраль для даних у реальному часі. Проєктування топіків дотримується тієї самої конвенції, прив'язаної до рівнів секретності, що й сховище: кожен топік має префікс із рівнем секретності, а ACL Kafka обмежують доступ продюсерів і консюмерів за рівнем секретності. Конвенція іменування топіків кодує тип джерела та ідентичність системи:
Адаптерні сервіси CoT/NIEM підписуються на сирі топіки C2, розбирають XML, зіставляють поля з канонічною схемою завантаження, додають метадані про походження (ID вихідної системи, часова позначка збору, рівень секретності, підрозділ-джерело) і публікують до нормалізованого топіка. Розбір CoT має обробляти як стандартні поля CoT, так і розширення елемента Detail, що використовуються окремими системами C2, — адаптер не повинен мовчки відкидати вміст розширень; він має або зіставляти відомі розширення з канонічними полями, або зберігати їх у структурованому стовпці розширень. Адаптери NIEM обробляють значно складніші схеми — модульна побудова NIEM означає, що екземпляр обміну NIEM може посилатися на типи з кількох основних і доменних схем NIEM, а адаптер має розв'язати всі посилання до зіставлення полів. Адаптер виводить сплощену структуру «один рядок на звіт», придатну для зберігання в Parquet.
Завантаження даних сенсорів ISR залежить від типу сенсора. Потоки відеоаналітики з БпЛА (UAV) формують записи подій виявлення — обмежувальна рамка (bounding box), клас виявлення, оцінка впевненості, часова позначка кадру, позиція сенсора — зі швидкістю, що може перевищувати 10 000 записів на хвилину для багатопотокової платформи. Їх потрібно завантажувати через Kafka із застосуванням схем Avro або Protobuf на боці продюсера, а не лише на боці консюмера. Приймачі SIGINT формують записи перехоплення випромінювачів із частотою, модуляцією, параметрами імпульсів, пеленгом і даними TDOA. Радіолокаційні потоки формують звіти про треки з позицією, швидкістю та метриками якості треку. Кожен тип сенсора має окремий адаптер, який нормалізує його рідний формат до канонічної схеми спостережень ISR, перш ніж запис потрапить до зони приймання. Для докладнішого розгляду архітектури злиття розвідувальних даних у реальному часі див. нашу доповнювальну статтю про багатоджерельну потокову обробку.
ETL для логістики зазвичай працює в пакетному режимі — більшість логістичних ERP-систем створюють періодичні експорти, а не потоки змін у реальному часі. Конвеєр ETL витягує дані з інтерфейсу експорту вихідної системи (скидання файлів через SFTP, запит до бази даних або отримання через REST API), перевіряє схему, застосовує зіставлення полів до канонічної логістичної схеми та записує файли Parquet до сирої зони приймання. Далі завдання Spark обробляє сирі файли в структуровану зону за розкладом, синхронізованим із ритмом експорту вихідної системи. Для логістичних систем, які підтримують захоплення змін даних (CDC) через потокову передачу журналу бази даних, переважним є потоковий шлях — він скорочує час між логістичною подією та її доступністю для аналітичних запитів із годин до хвилин.
Перевірка якості даних під час завантаження не є необов'язковою — це механізм, що не дає пошкодженим даним потрапити до структурованої зони та спотворити аналітику. Кожен адаптер завантаження має виконувати щонайменше: перевірку відповідності схемі, перевірки повноти походження, перевірки часової адекватності (часові позначки подій у правдоподібних межах), а для геопросторових даних — перевірку діапазону координат. Збої перевірки скеровуються до черги недоставлених повідомлень із повним початковим тілом повідомлення та структурованим записом про помилку, що вказує, яка саме перевірка не пройшла.
Каталог метаданих і виявлення даних — мітки секретності й застережень у метаданих, реєстр схем, відстеження родоводу даних, UX пошуку та виявлення даних для аналітиків
Каталог метаданих — це компонент, що робить озеро даних придатним для використання аналітиками, які його не будували. Без каталогу озеро даних — це набір непрозорих файлів Parquet в об'єктному сховищі, які вміють запитувати лише інженери, що писали адаптери завантаження. З добре наповненим каталогом будь-який аналітик із відповідним допуском може знаходити доступні набори даних, розуміти їхні схеми та походження й будувати запити до них — без залучення інженерної підтримки для кожного нового аналітичного питання. У посібнику з керування метаданими військового каталогу даних докладно розглянуто проєктування каталогу; цей розділ присвячено його інтеграції з архітектурою озера даних.
Apache Atlas — перевірений на практиці каталог із відкритим кодом для середовищ, що потребують розширюваних типів метаданих, відстеження родоводу та інтеграції з інструментами екосистеми Hadoop. Система типів Atlas дає змогу визначати власні типи сутностей метаданих як повноцінні об'єкти схеми, а не як вільнотекстові примітки, що є суттєвим для специфічних для оборони полів, які мають бути обов'язковими під час реєстрації набору даних:
- ClassificationLevel — перелічуваний тип: UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET. Обов'язковий для кожної сутності набору даних. Визначає маршрутизацію до бакета сховища та оцінювання політик контролю доступу.
- CaveatCodes — багатозначний список рядків. Фіксує застосовні застереження, такі як NOFORN, ідентифікатори компартментів та інструкції щодо поводження. Має заповнюватися під час завантаження або залишатися порожнім явним оголошенням — null не допускається.
- DataOwnerUnit — рядкове посилання на організаційний підрозділ, відповідальний за набір даних. Використовується для маршрутизації стюардства даних і для визначення точки контакту щодо запитів на доступ до даних.
- RetentionPolicy — посилання на застосовне правило зберігання, що визначає максимальну тривалість зберігання, процедуру безпечного видалення та орган, який затвердив термін зберігання.
- OriginatingSystem — ідентифікатор вихідної системи, що створила дані. Використовується для простеження родоводу та для скерування проблем якості даних назад до оператора вихідної системи.
Інтеграція реєстру схем з Apache Kafka гарантує, що схема кожного топіка зареєстрована й має версію до того, як будь-який продюсер почне запис. Confluent Schema Registry (розгортається локально без хмарного підключення) забезпечує дотримання правил сумісності схем Avro або Protobuf — сумісність BACKWARD для топіків, призначених для консюмерів, означає, що нові версії схеми можуть додавати необов'язкові поля без порушення роботи наявних консюмерів. Кожну версію схеми прив'язано до сутності каталогу Atlas для відповідного набору даних, що дає повну історію того, як структура набору даних змінювалася з часом.
Відстеження родоводу даних (data lineage) в Atlas фіксує ланцюг перетворень від сирого завантаження до підготовленої аналітичної таблиці. Хук Atlas у Spark автоматично генерує події родоводу, коли завдання Spark читає з одного зареєстрованого в Atlas набору даних і записує в інший. Інтеграція Trino з Atlas потребує власного слухача подій, який фіксує, до яких вихідних таблиць зверталися для отримання результату запиту. Граф родоводу, який Atlas будує з цих подій, дає аналітикові змогу простежити будь-яке значення в підготовленій аналітичній таблиці через кожен крок перетворення до початкового сирого запису в зоні приймання, а далі — до вихідної системи та події збору, що його породила. Цей ланцюг важливий в операційному сенсі — аналітикам часто потрібно оцінити, чи простежується певний аналітичний результат до надійного джерела, — і є вимогою відповідності для секретних даних.
Пошук і виявлення даних для аналітиків вимагають, щоб до каталогу можна було робити запити за атрибутами, якими аналітики реально користуються: домен даних (C2, ISR, логістика, геопросторові дані), охоплений часовий діапазон, рівень секретності та застереження (відфільтровані до того, що користувачеві дозволено бачити) і пошук за ключовими словами в описах наборів даних і назвах стовпців. API пошуку Atlas підтримує всі ці виміри, але рівень контролю доступу має гарантувати, що самі результати пошуку в каталозі фільтруються за допуском користувача та його належністю до компартментів: аналітик не повинен мати змоги виявити навіть існування набору даних, віднесеного до компартмента, до якого не має права доступу, хоча б запис каталогу й не розкривав вміст набору даних.
Контроль доступу за компартментами — контроль доступу на основі атрибутів (ABAC) для забезпечення компартментів, безпека на рівні рядків і стовпців у рушіях запитів, журналювання аудиту
Контроль доступу у військовому озері даних — це не єдина політика, а багаторівневий стек забезпечення, де кожен рівень перехоплює те, що може пропустити вищий. Рівні такі: політики бакетів на рівні сховища (хто може читати й записувати які бакети), політики видимості на рівні каталогу (хто може знаходити які набори даних), безпека рядків і стовпців на рівні рушія запитів (які рядки та стовпці користувач бачить у наборі даних, до якого має доступ) і журналювання аудиту (до чого зверталися, хто, коли та що було повернуто). Усі чотири рівні мають бути активні одночасно — будь-який окремо взятий рівень забезпечує лише частковий захист.
Контроль доступу на основі атрибутів (ABAC) — правильна модель для вимірів рівня секретності та компартментів, оскільки через вибухове зростання кількості ролей RBAC стає некерованим у масштабі. Політика ABAC оцінює доступ, обчислюючи функцію політики над атрибутами користувача та атрибутами ресурсу:
OPA розгортається як sidecar поряд із координатором Trino. Коли аналітик надсилає SQL-запит, плагін контролю доступу Trino викликає OPA для кожного посилання на таблицю в запиті, передаючи атрибути ідентичності автентифікованого користувача (від провайдера ідентифікації) і атрибути ресурсу таблиці (з каталогу). OPA повертає рішення «дозволити/заборонити», а для дозволених таблиць повертає предикат фільтра рядків і визначення масок стовпців, які слід застосувати до цієї таблиці в сеансі цього користувача. Trino прозоро впроваджує фільтри рядків і маски стовпців — запит аналітика виконується в тому вигляді, в якому його написано, але набір результатів містить лише ті рядки й стовпці, які аналітикові дозволено бачити.
Безпека на рівні рядків у Trino додає предикат до речення WHERE кожного запиту до захищеної таблиці. Для таблиці із записами різних рівнів секретності фільтр рядків обмежує запит рядками, рівень секретності яких перебуває в межах авторизованого діапазону користувача. Маскування на рівні стовпців замінює значення стовпців на NULL або рядковий літерал для стовпців, які користувачеві не дозволено бачити повністю, — наприклад, поле з ідентифікатором компартмента може бути видиме користувачам із відповідним дозволом на компартмент і маскуватися до NULL для користувачів без нього.
Журналювання аудиту має фіксувати кожну подію запиту з деталізацією, достатньою для відтворення того, що бачив користувач. Мінімальні поля запису аудиту такі: ідентичність автентифікованого користувача (не лише ім'я користувача, а повні атрибути від провайдера ідентифікації), часова позначка надсилання запиту, текст запиту, перелік таблиць, до яких зверталися, з їхніми рівнями секретності, кількість повернутих рядків для кожної таблиці, усі застосовані політики фільтрів рядків або масок стовпців і статус завершення запиту. Записи аудиту слід записувати в об'єктне сховище лише для додавання з увімкненим блокуванням об'єктів, що унеможливлює зміну чи видалення записів аудиту навіть адміністраторами сховища. Сховище журналу аудиту має мати найвищий рівень секретності, який може траплятися в будь-якому запиті, щоб самі записи аудиту не стали каналом передачі даних між рівнями секретності.
Шаблони навантажень запитів і аналітики — Trino/Presto для ad hoc SQL над об'єктним сховищем, Spark для пакетної аналітики, середовища ноутбуків для аналітиків
Військове озеро даних обслуговує два різні профілі навантаження запитами, які потребують різних рушіїв виконання, оптимізованих під різні функції вартості. Ad hoc запити аналітиків віддають пріоритет низькій затримці — аналітик, що готує оцінку для визначення цілей, потребує відповіді за секунди чи хвилини, а не за години. Завдання пакетної аналітики віддають пріоритет пропускній здатності — конвеєр інженерії даних, який обробляє весь історичний корпус записів сенсорів для аналізу закономірностей життєдіяльності (pattern-of-life), може погодитися на довший час виконання, якщо видає точні та вичерпні результати. Розгортання і Trino, і Spark над одним об'єктним сховищем обслуговує обидва профілі без компромісів.
Trino — рушій ad hoc запитів, який обирають для SQL-аналітики озера даних. Він читає файли Parquet і Delta Lake безпосередньо з об'єктного сховища через свій конектор Hive — без кроку завантаження даних і без ETL в окрему базу даних. Розподілений рушій виконання запитів Trino розбиває запит на фрагменти, що виконуються паралельно на робочих вузлах, а проміжні результати обмінюються мережею. Для типових запитів аналітиків — фільтрації свіжих записів сенсорів, об'єднання треків C2 із геопросторовими опорними шарами, агрегації споживання логістики за підрозділами та періодами часу — Trino видає результати за секунди чи хвилини на наборах даних, що охоплюють сотні гігабайтів файлів Parquet. Ключові параметри налаштування для розгортання військового озера даних такі: конфігурація відсікання партицій (Trino має проштовхувати предикати речення WHERE за стовпцями партицій до переліку об'єктів сховища, уникаючи повного сканування бакета), частота збору статистики (оптимізатор Trino, що ґрунтується на вартості, потребує точної статистики таблиць, щоб будувати ефективні плани об'єднання) і ліміти пам'яті робочих вузлів (великі запити з об'єднанням можуть перевищувати пам'ять на вузол; налаштування spill-to-disk запобігає збоям через нестачу пам'яті ціною збільшення затримки запитів).
Apache Spark — рушій пакетної аналітики для навантажень, що потребують обробки всього корпусу даних або складних ітеративних обчислень. Інтеграція Spark з Delta Lake забезпечує семантику запису ACID — пакетні завдання можуть записувати до таблиць Delta Lake з гарантіями «рівно один раз» (exactly-once), а паралельні читачі Spark і Trino в будь-який момент бачать узгоджений знімок таблиці завдяки протоколу MVCC Delta Lake. Типові навантаження Spark у військовому озері даних включають:
- Нічні завдання ETL, що обробляють файли сирої зони приймання за попередні 24 години в структуровану зону: розбір, перевірка, нормалізація та запис Parquet з метаданими партицій
- Аналіз закономірностей життєдіяльності (pattern-of-life) за тижні чи місяці історичних даних треків: виявлення регулярних шаблонів руху, частих подій перебування в одному місці та змін поведінки з часом
- Пакетні завдання зіставлення сутностей, що консолідують дубльовані записи з різних джерел для підготовленої головної таблиці сутностей
- Конвеєри підготовки навчальних даних для ML-моделей: вилучення ознак із сирих даних сенсорів, приєднання міток, експорт набору даних у формат, якого очікує фреймворк навчання
- Сканування якості даних, що виконують статистичне профілювання всієї структурованої зони для виявлення дрейфу схеми, аномалій розподілу значень і прогалин у метаданих про походження
JupyterHub надає середовище ноутбуків для аналітиків. Ноутбуки підключаються до Trino для SQL-запитів і до Spark для програмного оброблення даних, поєднуючи дослідницьку гнучкість Python зі структурованими можливостями запитів обох рушіїв. У секретному розгортанні сервер JupyterHub має бути ізольований у відповідному мережевому сегменті рівня секретності — кожен рівень секретності потребує власного екземпляра JupyterHub, підключеного до кластерів Trino і Spark у межах цього рівня. Ноутбуки, створені аналітиками, слід зберігати в підготовленій зоні озера даних (а не на локальному диску сервера JupyterHub), щоб на них поширювалися ті самі політики зберігання й аудиту, що й на інший вміст озера даних. Готові шаблони ноутбуків для типових сценаріїв багатодоменного об'єднання — трек C2, об'єднаний із виявленнями сенсорів ISR, споживання логістики, об'єднане з оперативними звітами, — скорочують час, який аналітик витрачає на шаблонне складання запитів, перш ніж дійти до свого аналітичного питання.
Якість даних і врядування — перевірки якості даних під час завантаження, керування майстер-даними для посилань на сутності, політики зберігання та знищення секретних даних
Врядування даними у військовому озері даних — це не вправа з документування, а операційна дисципліна, що визначає, чи можна довіряти аналітиці, яку видає озеро, під час ухвалення рішень. Аналітик, який виявляє, що оцінку для визначення цілей було засновано на даних, які не пройшли перевірок якості, але яким дозволили потрапити до підготовленої зони, втрачає довіру до всієї аналітичної платформи. Механізми врядування мають застосовуватися автоматично, не покладаючись на поінформованість аналітиків про стан якості даних.
Перевірки якості даних під час завантаження (описані в розділі про конвеєр завантаження) — це перший рубіж врядування. Другий рубіж — щоденне сканування якості даних у структурованій зоні за допомогою Apache Spark. Сканування виконує настроюваний набір перевірок для кожного зареєстрованого набору даних:
- Перевірки повноти — відсоток значень, відмінних від null, для обов'язкових полів; будь-який набір даних, у якому обов'язкове поле опускається нижче 95 % повноти, ініціює сповіщення стюарду даних
- Перевірки розподілу значень — статистичне профілювання числових стовпців виявляє раптові зсуви розподілу, які можуть вказувати на неточне калібрування сенсора, зміни системи координат або помилки ETL
- Перевірки референційної цілісності — зв'язки зовнішніх ключів між наборами даних (наприклад, ідентифікатори сутностей треків, на які посилаються записи сенсорів, мають існувати в головній таблиці сутностей C2) щодня перевіряються, щоб виявляти «осиротілі» посилання, спричинені проблемами послідовності завантаження
- Перевірки свіжості — для кожного набору даних визначено максимальну очікувану затримку завантаження; набори даних, які не отримали нових записів у межах цього вікна, ініціюють сповіщення, що може вказувати на збій вихідної системи або розділення мережі
Керування майстер-даними (MDM) для посилань на сутності — це механізм врядування, що запобігає поширенню неузгоджених ідентифікаторів сутностей у різних доменах даних. У військовому контексті основні сутності, що потребують MDM, такі: частини та з'єднання (з їхніми ієрархічними зв'язками та поточною організацією сил під завдання), одиниці обладнання (з моделлю, варіантом і закріпленим підрозділом), географічні об'єкти та споруди (із секретними й несекретними назвами) і особовий склад (із записами про допуск і призначення). Кожен із цих типів сутностей потребує золотого запису в головній таблиці сутностей, що слугує авторитетним еталоном для об'єднань між доменами даних. Без підтримуваної головної таблиці сутностей аналітики, які об'єднують записи сенсорів ISR із записами підрозділів C2, отримуватимуть збої об'єднання або неправильні результати щоразу, коли той самий підрозділ ідентифікується різними ідентифікаторами в різних вихідних системах, — поширена проблема в багатоджерельних військових середовищах даних.
Зберігання та знищення секретних даних використовує криптографічне стирання як стандартний механізм. Ключ шифрування даних (DEK) кожного рівня секретності зберігається в апаратному модулі безпеки (HSM). Коли політика зберігання ініціює знищення набору даних, HSM знищує DEK для відповідних об'єктів замість перезапису на рівні об'єктів потенційно петабайтів зашифрованих даних. Після знищення DEK зашифровані об'єкти обчислювально невідновлювані — вимога безпечного видалення виконується без операційного тягаря багатопрохідних процедур перезапису в петабайтному масштабі. Служба очищення, яка виконує знищення DEK, має заносити кожну подію очищення до незмінного журналу аудиту, що фіксує:
- Ідентифікатор набору даних і префікс шляху об'єктів, яких це стосується
- Кількість об'єктів, ключ шифрування яких було знищено
- Правило політики зберігання, що ініціювало знищення (за ID та версією правила)
- Ідентичність автоматизованої служби або людини-суб'єкта, яка авторизувала знищення
- Криптографічний хеш DEK на момент знищення (він доводить, що ключ існував до знищення, без збереження самого ключа)
- Часова позначка знищення DEK і запис атестації HSM, що підтверджує подію знищення
Каркас врядування ефективний лише тоді, коли його результати видимі людям, відповідальним за якість даних. Щоденна панель врядування, побудована з результатів сканування якості даних, метрик повноти реєстрації в каталозі, стану відповідності політикам зберігання та зведень журналу аудиту, дає стюардам даних видимість, потрібну для виявлення й усунення проблем до того, як вони поширяться на підготовлені набори даних, з якими працюють аналітики. Саму панель слід розгортати у відповідному мережевому сегменті рівня секретності, а її дані мають надходити виключно з цього сегмента — панель врядування для даних рівня «Таємно» не повинна отримувати метрики з несекретної інфраструктури моніторингу. Ставлення до врядування як до другорядного питання, що може ділити інфраструктуру зі службами нижчого рівня секретності, — поширена архітектурна помилка, яка створює і ризики щодо відповідності, і операційну сліпу зону для якості даних найчутливішого вмісту озера.