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

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

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

Стратегічний ризик залежності від єдиного хмарного провайдера

Геополітичний ризик є найбільш специфічним для оборони ризиком у залежності від хмарного провайдера. Відносини між оборонними організаціями та хмарними провайдерами опосередковані політичними та правовими структурами, які можуть змінюватися. Законодавство ЄС про суверенітет даних (GDPR, виключення з міркувань національної безпеки, EUCS) створює постійну правову невизначеність щодо довгострокової законності зберігання оборонних даних на інфраструктурі провайдерів зі штаб-квартирами в США.

Операційний ризик від збоїв є більш нагальним питанням. Великі хмарні провайдери зазнають значних збоїв: збої AWS us-east-1 у 2021 та 2023 роках порушили роботу значної частини комерційного інтернету на години. Для оборонних систем з вимогами до доступності залежність від єдиного хмарного провайдера без резервних можливостей є операційно неприйнятною.

Ціновий тиск є комерційним ризиком зі стратегічними наслідками. Хмарні провайдери можуть підвищувати ціни при продовженні контрактів; витрати на перехід при глибоко пов'язаних архітектурах ускладнюють реагування. Досвід DoD із конкурсами на хмарні контракти JEDI та JWCC відображав усвідомлення цього ризику.

Патерни мультихмарного розгортання

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

Первинно-вторинне аварійне відновлення запускає виробничі навантаження на первинному провайдері з теплим резервним середовищем у вторинного провайдера. Вторинне середовище підтримується в достатній готовності для прийняття навантажень у межах визначеного RTO (Objective Recovery Time) у разі відмови первинного. Цей патерн простіший операційно, але вимагає регулярного тестування відмовостійкості.

Хмарно-нейтральний IaC: Terraform та Crossplane

Terraform (від HashiCorp, нині BSL-ліцензований продукт з відкритою fork-версією OpenTofu) є стандартним інструментом Infrastructure-as-Code для хмарно-нейтрального розгортання ресурсів. Провайдери Terraform існують для всіх основних хмарних платформ (AWS, Azure, GCP, OVHcloud та десятків інших), і синтаксис конфігурації Terraform є хмарно-нейтральним.

Для мультихмарних архітектур система модулів та робочих просторів Terraform дозволяє інстанціювати одну й ту саму інфраструктуру застосунка на різних провайдерах: модуль Terraform для «тривимірного веб-застосунку» може мати специфічні для провайдера реалізації (одну для AWS, одну для Azure, одну для OVHcloud), що надають однаковий інтерфейс.

Crossplane є CNCF-graduated проектом, що надає площину управління на основі Kubernetes для розгортання хмарних ресурсів. Де Terraform є CLI-інструментом, що управляє станом інфраструктури у декларативному файлі, Crossplane працює як Kubernetes-контролер і управляє хмарними ресурсами як власними ресурсами Kubernetes. Система Crossplane Composition дозволяє абстрагувати хмарні ресурси.

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

Переносимість даних: відкриті формати та S3-сумісне сховище

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

S3-сумісне об'єктне сховище є практичним стандартом для хмарно-нейтрального зберігання даних. API Amazon S3 став стандартом де-факто для об'єктного сховища, S3-сумісні API надаються Azure Blob Storage, GCP Cloud Storage, OVHcloud Object Storage та локальними рішеннями на кшталт MinIO (широко використовується в ізольованих середовищах).

Стандартний SQL на базі PostgreSQL-сумісних керованих баз даних уникає залежності від пропрієтарних сервісів баз даних. PostgreSQL-сумісні керовані сервіси доступні на всіх основних хмарних платформах. Застосунки, що використовують стандартний SQL та протокол PostgreSQL, можуть мігрувати між провайдерами з мінімальними змінами конфігурації.

Складність відповідності: контроли класифікації у кількох провайдерів

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

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

Практичний підхід полягає у побудові хмарно-нейтрального рівня відповідності: набір модулів Terraform/Crossplane та політик контролерів допуску Kubernetes, що реалізують необхідні контроли відповідності незалежно від того, який хмарний провайдер розгортає базові ресурси.