Розгортання в ізольованих середовищах для оборонного ПЗ: виклики та кращі практики

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

Розгортання та підтримка сучасного програмного забезпечення на ізольованих системах вимагає принципово іншого інженерного підходу порівняно з підключеними до інтернету середовищами. Зручні функції, на які покладаються команди розробників, — автоматичні менеджери пакетів, що завантажують залежності з публічних репозиторіїв, контейнерні образи з Docker Hub, CI/CD-конвеєри, що звертаються до зовнішніх SaaS-сервісів, — усе це неефективно в ізольованих середовищах. Програмне забезпечення повинне функціонувати без жодного з цих підключень, а процеси розробки та супроводу мають бути спроектовані з урахуванням цього від самого початку.

Що означає ізоляція та де вона необхідна

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

Захищені інформаційні приміщення (SCIF) — це фізично захищені кімнати або будівлі, де може оброблятися та обговорюватися секретна інформація рівня вище SECRET, зокрема SCI (Sensitive Compartmented Information). Обчислювальні системи в межах SCIF, що обробляють дані рівня SCI, мають бути ізольовані від мереж, не акредитованих для відповідного рівня класифікації.

Секретні оперативні мережі рівня SECRET та вище ізольовані від несекретних мереж. Передача даних між рівнями класифікації вимагає Cross-Domain Solution (CDS) — апаратно-програмної системи, що забезпечує виконання правил інформаційного обміну між мережами різних рівнів.

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

Розгортання ПЗ без інтернету: реєстри артефактів і дзеркала пакетів

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

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

Офлайн-дзеркала пакетів відтворюють публічні репозиторії пакетів для використання всередині ізольованого середовища. Для Python — внутрішнє дзеркало PyPI (за допомогою інструментів на кшталт bandersnatch або devpi); для npm — екземпляр Nexus, Artifactory або відкритий Verdaccio. Процес синхронізації затверджених образів із зовнішнього реєстру до внутрішнього Harbor має відбуватися через процес передачі затвердженими носіями.

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

Управління патчами: перевірені пакети та контроль змін

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

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

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

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

Ротація секретів в ізольованих середовищах

Секрети — TLS-сертифікати, облікові дані баз даних, API-ключі — мають термін дії та підлягають ротації. В ізольованих середовищах жодні автоматизовані механізми ротації не працюють, оскільки вони покладаються на мережеву зв'язність із центрами сертифікації та API управління секретами, що недоступні всередині ізольованого середовища.

Апаратні модулі безпеки (HSM) є коренем довіри для криптографічних операцій в ізольованих секретних середовищах. HSM (наприклад, Thales Luna або nCipher nShield) зберігає приватні ключі в захищеному від несанкціонованого доступу апаратному забезпеченні, виконує криптографічні операції без розкриття ключового матеріалу та забезпечує безпеку, валідовану за FIPS 140-2 Рівень 3 або 4.

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

CI/CD для ізольованих середовищ

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

GitLab Community Edition, розгорнутий локально, є стандартною self-hosted платформою git і CI/CD для ізольованих середовищ. GitLab CE забезпечує: хостинг git-репозиторіїв, робочі процеси з merge request, виконання CI/CD-конвеєрів (через GitLab Runners у тому ж середовищі), реєстр пакетів та реєстр контейнерів. Хмарне підключення не потрібне.

GitLab Runners необхідно налаштувати для роботи з внутрішніми дзеркалами пакетів (внутрішній PyPI, npm, Maven) замість зовнішніх репозиторіїв. Етапи конвеєра, що зазвичай звертаються до зовнішніх сервісів, мають бути переналаштовані для використання внутрішніх еквівалентів або вимкнені.