Суверенна хмара для міністерств оборони: резидентність даних, площини керування, національна архітектура

Автор: Інженерна команда Corvus Intelligence · Про команду →

25 червня 2026 Оновлено: 25 червня 2026 12 хв читання

Кожне міністерство оборони, що перенесло робочі навантаження в хмару, зрештою стикається з тим самим напруженням: комерційні гіперскейлери дають можливості — керовані бази даних, платформи ШІ/МН, глобальні мережі, — яким жоден національний постачальник не може дорівнятися, втім ті самі гіперскейлери — іноземні корпорації, що підлягають юридичним процедурам свого уряду, експортному контролю і вимогам розвідувальної спільноти. Термін «суверенна хмара» описує спробу розв'язати це напруження, не приймаючи жодної крайності: ані повної залежності від гіперскейлера, ані технологічно замороженого національного мейнфрейму. Архітектура, що з цього виходить, ніколи не буває простою, а компроміси рідко очевидні, поки їх уже не ухвалили в продакшені.

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

1. Що таке хмарний суверенітет для міністерства оборони

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

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

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

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

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

2. Примусове забезпечення резидентності даних

Технічні засоби контролю резидентності даних діють на трьох шарах: резидентність ключів шифрування, примусове застосування політики розташування даних, аудит і перевірка. Потрібні всі три; будь-який один недостатній.

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

Локальний HSM (Thales Luna, Utimaco SecurityServer або еквівалент) для найвищих рівнів класифікації, з фізично захищеним HSM і аудитом за політикою фізичної безпеки міністерства
KMS національного хмарного постачальника на апаратному HSM у країні для нижчих рівнів класифікації, де керовані сервіси ключів прийнятні
Конвертне шифрування: ключі шифрування даних (DEK) генеруються для кожного об'єкта чи тому і шифруються ключами шифрування ключів (KEK), що зберігаються в HSM, — HSM ніколи не тримає необроблені дані, лише матеріал ключів
Журналювання доступу до ключів, окреме і незалежне від журналу аудиту системи зберігання, щоб спроби несанкціонованого доступу до ключів були видимі, навіть якщо шар зберігання скомпрометовано

Примусове застосування політики розташування даних вимагає, щоб сервіси зберігання — об'єктне сховище, блокові томи, екземпляри баз даних, — були обмежені доступними зонами в межах країни на рівні конфігурації платформи, а не лише декларацією політики. У розгортанні OpenStack це означає налаштування правил прихильності до доступних зон у Cinder і Swift, що запобігають розміщенню реплік поза визначеною зоною. У розгортанні гіперскейлера це означає використання політик контролю сервісів (AWS) або визначень Azure Policy, що відхиляють будь-яке створення ресурсів зберігання в регіонах за кордоном, застосоване на рівні керувального облікового запису чи групи керування, щоб окремі команди робочих навантажень не могли їх перевизначити.

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

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

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

3. Проєктування національної площини керування

Площина керування хмарної платформи — набір сервісів, що керують оркестрацією, ідентифікацією та секретами, — це місце, де живе найвпливовіший ризик суверенітету. У середовищі Kubernetes компоненти площини керування — це API-сервер, кластер etcd, планувальник, контролер-менеджер і admission-вебхуки, що примусово застосовують політику під час створення робочих навантажень. Якщо будь-який із цих компонентів працює на інфраструктурі, якою керує операційний персонал іноземного гіперскейлера, цей персонал має технічну можливість (навіть якщо це заборонено договором) змінювати конфігурації робочих навантажень, витягувати секрети з etcd або порушувати планування за вказівкою свого уряду.

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

API-сервер Kubernetes і etcd. Розгорніть самокерований дистрибутив Kubernetes — kubeadm для максимальної гнучкості, k0s для спрощеної експлуатації або Talos Linux для підходу з незмінною ОС, — на baremetal або віртуальних машинах на гіпервізорах під контролем міністерства. Кластер etcd потребує трьох або п'яти вузлів для кворуму, що працюють на виділеному обладнанні, не спільному з вузлами робочих навантажень. Дані etcd мають бути зашифровані в стані спокою за допомогою плагіна KMS-провайдера, під'єднаного до національного HSM. Резервуйте знімки etcd в зашифроване об'єктне сховище в межах країни з автоматизованим тестуванням відновлення.

# Example kube-apiserver flag for national KMS encryption provider
--encryption-provider-config=/etc/kubernetes/encryption-config.yaml

# encryption-config.yaml (excerpt)
resources:
  - resources: [secrets, configmaps]
    providers:
      - kms:
          name: national-hsm-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          cachesize: 1000
          timeout: 3s
      - identity: {}

Провайдер ідентифікації. Keycloak — стандартний OIDC/SAML-провайдер ідентифікації з відкритим кодом для розгортань суверенної хмари. Розгорніть Keycloak на виділеній національній інфраструктурі, інтегрованій з наявним каталогом міністерства (Active Directory або LDAP через конектори федерації Keycloak). Налаштуйте API-сервер Kubernetes на використання Keycloak як OIDC-автентифікатора:

# kube-apiserver OIDC flags
--oidc-issuer-url=https://keycloak.national.mil/realms/defense
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/keycloak-ca.crt

Доступність Keycloak тепер є критичним шляхом для автентифікації кластера. Розгортайте в режимі високої доступності (щонайменше три екземпляри Keycloak за внутрішнім балансувальником навантаження з розподіленим кешем стану сесій) і задокументуйте аварійну процедуру аварійного доступу до API-сервера, коли Keycloak недоступний, — зазвичай локальний kubeconfig із сертифікатом клієнта для аварійного доступу cluster-admin, що зберігається у фізично захищеному місці.

Керування секретами. HashiCorp Vault (або його форк з відкритим кодом OpenBao), розгорнутий на національній інфраструктурі, забезпечує шар керування секретами. Vault автоматично розпечатується за допомогою національного HSM, усуваючи ручний процес розпечатування, який інакше був би єдиною точкою відмови для відновлення площини керування. Журнал аудиту Vault — кожне читання і запис секрету, — передається в реальному часі в національний SIEM, за межами радіусу ураження скомпрометованого розгортання Vault.

4. Оцінка залежності від гіперскейлерів

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

Високий ризик суверенітету — слід замінити або експлуатувати незалежно:

Керовані площини керування Kubernetes (EKS, AKS, GKE) — API-сервер і etcd експлуатують працівники гіперскейлера з привілейованим доступом; замініть самокерованим Kubernetes на примітивах IaaS
Керовані провайдери ідентифікації (AWS IAM, Azure Active Directory як основний IdP) — авторитетні твердження ідентичності роблять сервіси під іноземним керуванням; замініть Keycloak або еквівалентом на національній інфраструктурі
Керовані сховища секретів (AWS Secrets Manager, Azure Key Vault із HSM під контролем гіперскейлера) — матеріал ключів зберігається в іноземних HSM; замініть самокерованим Vault на національному HSM
Глобальні CDN і периферійні мережі — трафік маршрутизується через точки присутності за кордоном; вимкніть або обмежте лише периферійними вузлами в межах країни

Середній ризик суверенітету — прийнятний із додатковими засобами контролю:

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

Нижчий ризик суверенітету:

Обчислення IaaS (віртуальні машини) без керованих агентських фреймворків — гіперскейлер надає апаратне забезпечення; міністерство експлуатує програмний стек і контролює все шифрування
Блокове зберігання з ключами, що керує клієнт, із національного KMS — гіперскейлер утримує зашифровані блоки, які неможливо розшифрувати без ключа, що його має міністерство

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

5. Архітектурні патерни: суверенна зв'язана проти повітряно ізольованої суверенної

Існують два основні архітектурні патерни для розгортань суверенної хмари зі суттєво різними профілями вартості, можливостей та операційної складності.

Суверенна зв'язана топологія використовує доступну зону центру обробки даних гіперскейлера в країні як шар IaaS, причому міністерство експлуатує власну площину керування (Kubernetes, Keycloak, Vault) поверх примітивів обчислень і зберігання гіперскейлера. Гіперскейлер забезпечує цикли оновлення обладнання, експлуатацію центру обробки даних і фізичну безпеку; міністерство забезпечує програмну експлуатацію, керування ключами шифрування та всі компоненти площини керування.

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

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

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

Компроміси значні. Капітальні витрати суттєво вищі, ніж у суверенній зв'язаній топології. Цикли закупівель серверів і мережевого обладнання довгі — типово 12-24 місяці від вимоги до операційної спроможності. Оновлення обладнання потребує нових циклів закупівель. Вимоги до операційного персоналу значно більші: експлуатація OpenStack, Ceph, Kubernetes і Keycloak у продакшені потребує команди з глибокою експертизою за всіма чотирма компонентами, яку дуже важко укомплектувати на рівнях державної оплати праці. А розрив у можливостях відносно гіперскейлерів зростає з часом, оскільки вони інвестують величезні кошти в керовані ШІ/МН, аналітику даних і безсерверні платформи.

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

6. Суверенний стек з відкритим кодом

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

OpenStack — це шар IaaS: Nova для обчислень, Neutron для віртуальних мереж, Cinder для блокового зберігання, Swift для об'єктного зберігання, Glance для керування образами, Keystone для ідентифікації сервісів і каталогу. OpenStack має 15-річну історію продакшен-експлуатації в телекомунікаціях, державному секторі та наукових обчисленнях. Операційна складність реальна — розгортання OpenStack потребують виділеної платформної команди й ретельного керування змінами, — але екосистема операторів, інтеграторів і документації доросла. Інструменти розгортання Kolla-Ansible роблять початкове розгортання керованим; постійне операційне виклик — керування оновленнями, яке слід ретельно планувати в оборонному середовищі, де процеси контролю змін повільні.

Ceph — розподілений бекенд зберігання. Він забезпечує блокове зберігання (RBD) для томів Cinder, об'єктне зберігання (RGW) для сумісних з Swift API і спільну файлову систему (CephFS) для робочих навантажень, що потребують семантики POSIX. Архітектура Ceph розподіляє дані по всіх вузлах кластера з налаштовуваними коефіцієнтами реплікації, забезпечуючи стійкість до відмов окремих вузлів чи дисків без пропрієтарних масивів зберігання. Операційна складність зосереджена на тюнінгу продуктивності — Ceph потребує ретельного вибору обладнання (NVMe SSD для журналів OSD, високосмугової мережі між вузлами) і постійного моніторингу продуктивності, щоб уникнути каскадів «повільних OSD», які можуть погіршити продуктивність кластера під важким записом.

Keycloak — провайдер ідентифікації. Він підтримує OIDC, SAML 2.0, OAuth 2.0 і федерацію LDAP/AD, що робить його точкою інтеграції для всієї автентифікації в суверенному стеці: автентифікація API-сервера Kubernetes, федерація ідентичності OpenStack Keystone, JWT-автентифікація Vault і автентифікація людських користувачів. Адміністративний UI і REST API Keycloak надають операційні інструменти для керування користувачами, групами та реєстрації клієнтів (застосунків). Модель розгортання високої доступності — кілька екземплярів Keycloak зі спільним розподіленим кешем Infinispan і спільною базою даних PostgreSQL — добре задокументована й перевірена в продакшені.

Kubernetes — шар оркестрації контейнерів. Розгорнутий з kubeadm або Talos Linux на обчислювальних екземплярах OpenStack Nova, Kubernetes забезпечує шар планування робочих навантажень, виявлення сервісів і керування конфігураціями, якими споживають команди застосунків. Ключова архітектурна вимога для суверенного стека: дистрибутив Kubernetes має бути сумісним з upstream, а не керованим варіантом гіперскейлера, щоб площина керування лишалася під контролем міністерства. Для мережі контейнерів Cilium — улюблений CNI для оборонних середовищ через примусове застосування політик на основі eBPF і глибоку спостережуваність без sidecar-проксі. Для інтеграції зберігання драйвер Ceph CSI забезпечує зв'язок між PersistentVolumes Kubernetes і Ceph RBD.

Операційну складність цього стека не слід недооцінювати. Експлуатація OpenStack, Ceph, Kubernetes і Keycloak у продакшені потребує фахової експертизи за всіма чотирма компонентами, яку важко найняти й утримати в державних організаціях. Реалістично міністерству, що розгортає цей стек, потрібна або велика внутрішня платформна команда (20+ інженерів для розгортання середнього масштабу), або контрактований суверенний інтегратор із глибокою експертизою за всіма чотирма компонентами. Альтернативу — зниження операційної складності через ухвалення керованого сервісу гіперскейлера для деяких компонентів — слід оцінювати проти вимог суверенітету, які вона компрометує. Про засоби контролю безпеки, що мають працювати поверх цього стека, дивіться нашу статтю про CSPM для оборонної хмари.

7. Баланс між суверенітетом і сучасними хмарними можливостями

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

Переносимість IaC через абстракцію провайдерів Terraform — найпрактичніший механізм керування цим напруженням. Стратегія — визначити всю інфраструктуру в модулях Terraform, незалежних від провайдера, — внутрішніх абстракціях, що приймають узгоджені входи й дають узгоджені виходи незалежно від того, чи основним провайдером є OpenStack, AWS чи Azure. Інтерфейс модуля для «обчислювального кластера» однаковий, чи розгортає він в OpenStack Nova, чи в AWS EC2; змінюється лише прив'язка до провайдера. Ця абстракція зберігає опцію мігрувати робочі навантаження між суверенним національним стеком і суверенною зв'язаною зоною гіперскейлера без переархітектури інфраструктури застосунку.

# Example provider-agnostic compute module interface
module "compute_cluster" {
  source        = "internal/modules/compute-cluster"
  name          = "sensor-processing"
  instance_type = "c5.4xlarge"  # resolved per provider
  count         = 3
  subnet_id     = module.network.private_subnet_id
  security_groups = [module.security.workload_sg_id]
  user_data     = file("cloud-init/sensor-processor.yaml")
}

# Bind to provider via workspace variable
# terraform.tfvars.national:  provider = "openstack"
# terraform.tfvars.govcloud:  provider = "aws-govcloud"

Альтернативи керованих сервісів для найбільш стратегічно важливих розривів у можливостях:

Навчання ШІ/МН: локальні кластери GPU, що працюють на Kubeflow або MLflow, закуплені у постачальників із прийнятною позицією ланцюга постачання; суверенний зв'язаний перелив на GPU-екземпляри гіперскейлера в країні для завдань навчання, що перевищують локальні потужності
Аналітика даних: Apache Spark на Kubernetes (через оператор Spark) замінює керовані аналітичні сервіси; ClickHouse або Apache Druid для робочих навантажень аналітичних запитів у реальному часі
Керовані бази даних: оператори для PostgreSQL (CloudNativePG), Redis (Redis Operator) і Kafka (Strimzi) дають операційний досвід, подібний до керованого сервісу, на самокерованому Kubernetes
Спостережуваність: Prometheus, Loki і Grafana забезпечують стек метрик, журналювання та візуалізації без пропрієтарних залежностей керованої спостережуваності

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

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

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

Обговоріть ваш проєкт

Ми проєктуємо і будуємо архітектури суверенної хмари для міністерств оборони — від розгортання національної площини керування та примусового забезпечення резидентності даних до експлуатації стека з відкритим кодом і переносимості IaC.

Сервіси захищеної хмари → Замовити брифінг

Цей аналіз підготували інженери Corvus Intelligence, які створюють програмне забезпечення критичного призначення для оборонних і державних організацій. Дізнайтеся про нашу команду →

Часті запитання

Що таке хмарний суверенітет для міністерства оборони?

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

Що таке примусове забезпечення резидентності даних у контексті оборонної хмари?

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

Що таке національна площина керування і чому вона важлива?

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

Які компоненти гіперскейлерів створюють найбільший ризик для суверенітету?

Найризикованіші компоненти гіперскейлерів для міністерства оборони: керовані площини керування Kubernetes (EKS, AKS, GKE), де API-сервер і etcd працюють на інфраструктурі гіперскейлера, а його операційний персонал має привілейований доступ; керовані провайдери ідентифікації, де авторитетне твердження ідентичності роблять сервіси під контролем гіперскейлера; глобальні CDN і шари кешування на периферії, що маршрутизують трафік через точки присутності за кордоном; функції міжрегіональної реплікації, які можуть копіювати дані в доступні зони поза схваленою юрисдикцією; і керовані сховища секретів, матеріал ключів яких зрештою зберігається в HSM під контролем гіперскейлера. Компоненти IaaS гіперскейлера — чисті обчислення, блокове зберігання і віртуальні мережі без керованої площини керування — створюють значно нижчий ризик для суверенітету, бо міністерство експлуатує програмний стек поверх них і незалежно контролює всі ключі шифрування.

Яка різниця між суверенною зв'язаною та повністю національною хмарою?

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

Які компоненти з відкритим кодом формують ядро стека суверенної хмари?

Канонічний стек суверенної хмари з відкритим кодом складається з: OpenStack для IaaS (обчислення через Nova, об'єктне зберігання через Swift, блокове зберігання через Cinder, мережа через Neutron, керування образами через Glance, ідентифікація через Keystone); Ceph як розподілений шар зберігання, що підтримує томи Cinder і об'єктне сховище Swift; Kubernetes як шар оркестрації контейнерів, розгорнутий з upstream-дистрибутивом (а не керованим варіантом гіперскейлера), щоб API-сервер і etcd залишалися під контролем міністерства; і Keycloak як провайдер ідентифікації як для людських користувачів (через OpenID Connect і SAML), так і для робочих навантажень (через облікові дані клієнта OAuth 2.0). Разом ці чотири компоненти дають повний стек хмарної платформи без пропрієтарних залежностей. Операційна складність істотно вища, ніж при використанні керованих сервісів гіперскейлерів, і міністерство має підтримувати експертизу для експлуатації та патчіння кожного компонента, — але гарантії суверенітету абсолютні, бо вихідний код кожного компонента можна аудитувати, і жоден іноземний постачальник не має привілейованого операційного доступу.

Як Terraform підтримує переносимість між суверенними хмарними середовищами?

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

Які ключові ризики суверенної хмари для міністерства оборони?

Основні ризики: розрив у можливостях (національні хмарні постачальники та стеки з відкритим кодом часто відстають від гіперскейлерів на кілька років у керованих сервісах ШІ/МН, безсерверних платформах і глобальній мережевій продуктивності — це обмежує дорожню карту сучасних можливостей); операційна складність (внутрішня експлуатація OpenStack, Ceph, Kubernetes і Keycloak потребує глибокої експертизи, яку важко найняти й утримати в державі); ризик ланцюга постачання в апаратурі (сервери, мережеве обладнання та системи зберігання від ненаціональних постачальників несуть власні ризики суверенітету ланцюга постачання — навіть повністю національну хмару можуть скомпрометувати на апаратному рівні); і хибний суверенітет (хмара, що задовольняє резидентність даних на папері, але має операційний персонал гіперскейлера з привілейованим доступом чи використовує іноземні HSM для керування ключами, дає слабші гарантії, ніж її архітектурна документація). Управління ризиками вимагає розглядати суверенітет як спектр із кількома незалежно перевірюваними вимірами, а не як бінарну сертифікацію.

Як слід розділяти таємні й нетаємні робочі навантаження в суверенній хмарі?

Таємні й нетаємні робочі навантаження слід розділяти на фізичному рівні — окремі кластери Kubernetes на окремих пулах вузлів без спільного etcd, без спільної площини керування і без спільної мережевої інфраструктури між рівнями класифікації. Логічне розділення в межах одного кластера (ізоляція namespace, NetworkPolicy) недостатнє для робочих навантажень різних рівнів класифікації, бо вразливість площини керування або втеча контейнера може перетнути межі namespace. На практиці це означає окремі орендарі OpenStack із фізично окремими кластерами зберігання Ceph для кожного рівня класифікації, окремі realm Keycloak або повністю окремі провайдери ідентифікації та окремі конвеєри CI/CD з окремими ключами підпису, щоб компрометація конвеєра збірки нетаємного рівня не могла ввести зловмисні образи в таємний рівень. Передача даних між рівнями (cross-domain) має проходити через офіційно оцінене рішення між доменами, а не через мережеву зв'язність.

Якою має бути дорожня карта можливостей міністерства оборони щодо суверенної хмари?

Реалістична дорожня карта можливостей суверенної хмари для міністерства оборони має три фази. Фаза 1 (роки 1-2) закладає основу: розгорнути національний шар IaaS (OpenStack або еквівалент), мігрувати робочі навантаження з комерційної хмари на інфраструктуру в країні, впровадити засоби контролю резидентності даних і національне керування ключами, розгорнути національну площину керування Kubernetes. Фаза 2 (роки 2-4) будує шар платформи: розгорнути Keycloak для федерованої ідентифікації, впровадити IaC на основі Terraform з абстракцією провайдера, створити внутрішній реєстр контейнерів із засобами контролю ланцюга постачання (підпис образів, сканування вразливостей) і встановити суверенну зв'язану топологію з зоною гіперскейлера в країні для пікових навантажень і відмовостійкості. Фаза 3 (роки 4+) націлена на паритет можливостей: створити або закупити суверенні керовані сервіси баз даних і аналітики, розгорнути локальну інфраструктуру навчання ШІ/МН, впровадити архітектуру нульової довіри на всіх рівнях і створити фреймворк безперервної автоматизації відповідності, що охоплює всі компоненти суверенного стека.