Управління безпековою постурою хмари для оборони: CSPM у засекречених середовищах

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

25 червня 2026 11 хв читання

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

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

Що охоплює CSPM і чому засекречена хмара його потребує

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

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

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

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

Базові рамки політики для оборонної хмари

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

DISA STIG Cloud Computing SRG. Керівництво з вимог безпеки для хмарних обчислень є авторитетним документом DISA, що визначає засоби контролю безпеки для всіх хмарних розгортань DoD. Воно накладає специфічні для DoD вимоги на NIST 800-53 та розподіляє відповідальність за засоби контролю між постачальником хмарних послуг, орендарем та їх спільним кордоном. SRG визначає вимоги на рівні віртуалізації, операційної системи, прикладного рівня та рівня хмарних послуг — усі вони мають бути охоплені в пакеті ATO DoD. Правила політики CSPM мають бути зіставлені з ідентифікаторами засобів контролю SRG, щоб знахідки могли бути безпосередньо пов'язані з вимогами ATO.

NIST SP 800-53 Rev 5. Базовий каталог засобів контролю для всіх федеральних систем. Для хмари найбільш релевантними сімействами засобів контролю є: Управління конфігурацією (CM) — запобігання та виявлення несанкціонованих змін конфігурації; Захист систем і комунікацій (SC) — шифрування в транзиті та в стані спокою, мережева сегментація; Аудит і підзвітність (AU) — журналювання, цілісність журналів та їх зберігання; та Контроль доступу (AC) / Ідентифікація та автентифікація (IA) — політика IAM та управління привілеями. Добре налаштоване розгортання CSPM зіставляє правила з конкретними ідентифікаторами засобів контролю (наприклад, CM-6, CM-7, AC-3, AU-2), щоб кожна знахідка містила посилання на відповідний засіб контролю.

Базовий рівень FedRAMP High. Хмарні послуги, що використовуються системами DoD на рівнях IL4 та IL5, повинні мати авторизацію FedRAMP High або еквівалентну. Базовий рівень FedRAMP High розширює 800-53 Rev 4/5 більш жорсткими значеннями параметрів — наприклад, вимагаючи багатофакторну автентифікацію для всіх привілейованих і непривілейованих облікових записів, а не лише привілейованих. Набори правил CSPM для FedRAMP High доступні для AWS, Azure Government та GCP і є відправною точкою для конфігурації CSPM на стороні орендаря в більшості оборонних розгортань.

Наступна таблиця ілюструє, як ключові категорії перевірок CSPM відображаються на три основні рамки:

Категорія перевірки CSPM	NIST 800-53 Rev 5	STIG SRG	FedRAMP High
Надмірність дозволів IAM	AC-3, AC-6, IA-2	SRG-APP-000033	AC-6 (1)(2)(5)
Публічний доступ до сховища	AC-3, SC-28	SRG-APP-000440	SC-28 (1)
Шифрування в стані спокою	SC-28	SRG-APP-000428	SC-28 (1)
Увімкнення аудит-журналювання	AU-2, AU-3, AU-12	SRG-APP-000089	AU-2, AU-12
Необмежений мережевий доступ	SC-7, AC-17	SRG-NET-000019	SC-7 (3)(4)(5)
Застосування MFA	IA-2 (1)(2)	SRG-APP-000149	IA-2 (1)(2)(3)(6)

Виявлення неправильних конфігурацій: що сканує CSPM

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

Неправильні конфігурації IAM є найпоширенішою категорією знахідок високого ступеня серйозності. Надмірно дозвільні рольові політики — зокрема, ті, що використовують шаблонні специфікатори ресурсів (Resource: "*") для чутливих дій або прикріплюють адміністративні політики до не-адміністративних принципалів — порушують принцип мінімальних привілеїв та створюють шляхи для бокового переміщення зловмисника, який скомпрометував будь-якого принципала з такими дозволами. Перевірки IAM у CSPM шукають: невикористовувані ролі та ключі доступу (застарілі облікові дані, що ніколи не були відкликані), шляхи підвищення привілеїв (рольові політики, що дозволяють принципалу змінювати власні дозволи), міжобліково-рекордні довірчі відносини та активність кореневого облікового запису.

Перевірки мережевого відкриття виявляють правила груп безпеки, мережеві ACL або правила брандмауера, що дозволяють вхідний доступ з необмежених діапазонів адрес (0.0.0.0/0 або ::/0) на чутливих портах — SSH (22), RDP (3389), портах баз даних та інтерфейсах управління. У засекреченій хмарі будь-яке відкриття інтерфейсів управління для широких мережевих діапазонів є знахідкою STIG Категорії I. Мережеві перевірки CSPM також верифікують, що журналювання потоків VPC увімкнено, що публічне призначення IP-адрес не активовано для ресурсів у приватних підмережах, і що відносини пірингу мережі є належними.

Прогалини в шифруванні в стані спокою є жорсткою вимогою FedRAMP High та STIG — кожен том, база даних та об'єктне сховище з даними DoD повинні бути зашифровані за допомогою алгоритму, валідованого відповідно до FIPS 140-2. Перевірки шифрування CSPM перелічують ресурси сховища (томи EBS, інстанси RDS, кошики S3, таблиці DynamoDB) та позначають ті, що не зашифровані або зашифровані невалідованим алгоритмом. Перевірки управління ключами верифікують, що ключі шифрування є ключами, керованими замовником (CMK), а не ключами, керованими постачальником, де це вимагається SSP, і що ротація ключів увімкнена.

Прогалини в журналюванні є особливо підступною неправильною конфігурацією, оскільки їх відсутність є невидимою до тих пір, поки після інциденту не знадобиться криміналістична реконструкція. Перевірки журналювання CSPM верифікують, що CloudTrail (або еквівалент) увімкнено в кожному регіоні та обліковому записі, що сховище журналів має увімкнену перевірку цілісності (наприклад, валідація файлів журналів CloudTrail), що термін зберігання журналів відповідає мінімальному необхідному (як правило, 1–3 роки для систем DoD), і що події управління — API-виклики, що змінюють конфігурацію — фіксуються зокрема. Прогалини в журналюванні безпосередньо порушують вимоги сімейства засобів контролю AU і можуть призводити до знахідок ATO, які важко компенсувати архітектурно.

Публічний доступ до сховища — об'єктні сховища з публічним доступом для читання або запису — залишається в наборах перевірок CSPM, оскільки продовжує з'являтися в реальних інцидентах. У оборонній хмарі неправильно налаштований кошик S3 або контейнер Azure Blob з публічним доступом представляє прямий шлях розкриття CUI або засекречених даних. Перевірки CSPM стосуються налаштувань блокування публічного доступу на рівні кошика, ACL кошика, політик кошика, що дозволяють неавтентифікований доступ, і публічного доступу на рівні облікового запису (AWS S3 Account Public Access Block).

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

CSPM Scan Summary — GovCloud Account: 123456789012
Scan Date: 2026-06-25T08:14:32Z  |  Framework: FedRAMP-High + STIG-SRG

Category                  Total  PASS   FAIL   WARN   SUPPRESSED
────────────────────────────────────────────────────────────────
IAM                         142   118     17      4          3
Network Security             89    82      5      2          0
Encryption at Rest           54    51      2      1          0
Audit Logging                31    28      3      0          0
Public Exposure              18    18      0      0          0
Key Management               22    20      1      1          0
────────────────────────────────────────────────────────────────
TOTAL                       356   317     28      8          3

Severity Breakdown (FAIL):
  Critical / Cat-I:   3  ← SLA: 15 days
  High     / Cat-II: 14  ← SLA: 30 days
  Medium   / Cat-III: 11  ← SLA: 90 days

Виявлення відхилень та застосування політик

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

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

Сканування, кероване подіями, знижує цю затримку до секунд, запускаючи цільові перевірки під час виявлення подій зміни конфігурації. AWS EventBridge може маршрутизувати події CloudTrail для конкретних API-викликів (CreateBucket, PutBucketAcl, AuthorizeSecurityGroupIngress, AttachRolePolicy) до функції оцінки CSPM, що перевіряє лише уражений ресурс одразу після зміни. Ця архітектура є необхідною для категорій перевірок з найвищим ризиком — IAM та відкриття мережі — де вікно між створенням неправильної конфігурації та її використанням може становити години, а не дні.

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

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

Обробка аварійних винятків є додатковим процесом для ситуацій, коли виправлення не може відбутися негайно. Якщо знахідка CSPM не може бути виправлена в межах SLA через технічне обмеження або операційну залежність, ISSO ініціює формальний робочий процес прийняття ризику: документує знахідку, визначає компенсуючі засоби контролю, отримує підпис AO на обмеженому в часі прийнятті та записує виняток у eMASS як відкритий пункт POA&M. Інструмент CSPM має відображати прийняті винятки, придушуючи знахідку з активних інформаційних панелей, зберігаючи її при цьому в історії аудиту, і має автоматично повторно відображати знахідку після закінчення терміну прийняття.

CSPM у повністю ізольованих середовищах IL4/IL5

Стандартна комерційна модель розгортання CSPM — SaaS-платформа, що підключається до хмарних API, агрегує знахідки у бекенді, розміщеному постачальником, і надає веб-панель — є принципово несумісною з вимогами IL5 та засекреченої хмари. Дані про конфігурації засекреченої хмари, інвентаризацію ресурсів, структури IAM та знахідки безпеки не можуть виходити за межу класифікації до комерційної хмари постачальника. Навіть на рівні IL4 (Контрольована несекретна інформація) багато програм застосовують консервативне поводження з даними, що унеможливлює використання SaaS-CSPM.

Це створює архітектурне обмеження, яке оборонні розгортання CSPM повинні вирішувати явно. Доступні підходи:

Розгортання движка CSPM на місці. Движки CSPM з відкритим кодом — Prowler (AWS), Steampipe з модулями відповідності, Checkov (статичний аналіз IaC) або Scout Suite — можуть бути розгорнуті повністю всередині засекреченого анклаву. Інструмент працює всередині межі, запитує хмарні API з-за межі, зберігає знахідки у внутрішній базі даних і генерує звіти, що ніколи не покидають межу класифікації. Цей підхід вимагає операційного управління самим інструментом CSPM (оновлення, підтримка сигнатур, управління пакетами правил), але забезпечує повний контроль і відсутність ризику витоку даних.

Авторизований комерційний CSPM на рівні впливу. Деякі комерційні продукти CSPM мають авторизацію FedRAMP High та пропонують режими розгортання в регіонах AWS GovCloud або Azure Government. Вони можуть бути прийнятними для навантажень IL4, коли обробка даних інструментом CSPM знаходиться в межах авторизованої межі. Програмам слід верифікувати, що авторизація FedRAMP конкретного продукту CSPM охоплює типи даних, що оцінюються, і що продукт працює в розгортанні, розміщеному в GovCloud, а не в комерційному регіоні з бекендом, що отримує дані GovCloud.

Компроміс між безагентним та агентним скануванням є значним у засекречених середовищах:

Безагентний CSPM запитує API постачальника хмарних послуг (AWS Config, Azure Resource Graph, GCP Asset Inventory) для переліку та оцінки хмарних нативних ресурсів. Він не вимагає встановлення програмного забезпечення на обчислювальні інстанси, не впливає на продуктивність навантажень і є простим в авторизації, оскільки периметр атаки обмежується лише облікованими даними API для читання. Однак він сліпий до стану конфігурації на рівні ОС — він може верифікувати, що до інстансу EC2 прикріплена правильна група безпеки, але не може верифікувати, чи правильно налаштований брандмауер ОС або чи виконується заборонена служба всередині інстансу.

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

Більшість зрілих розгортань CSPM на рівнях IL4/IL5 використовують безагентне сканування для засобів контролю, що видно через хмарні API, та окреме рішення на основі HBSS (Host-Based Security System) або агента на кінцевих точках — нерідко стандартний для DoD McAfee HIP/HBSS — для відповідності STIG на рівні хоста, інтегруючи обидва джерела даних в єдину інформаційну панель відповідності. Ця постура DevSecOps для оборонних конвеєрів, де CSPM вносить дані до тих самих записів відповідності, що й засоби контролю безпеки конвеєра, забезпечує найповніший пакет доказів ATO.

Інтеграція робочого процесу усунення порушень

Знахідки CSPM, що існують лише в інформаційній панелі інструменту CSPM, мають обмежену цінність для оборонної програми. Інституційний процес відстеження знахідок безпеки — це POA&M у eMASS, і знахідки CSPM повинні автоматично вноситися в цей процес, а не через ручне перенесення ISSO, що перевіряє інформаційну панель CSPM та вручну копіює знахідки в записи eMASS.

Архітектура інтеграції для засекречених програм зазвичай включає два етапи. По-перше, знахідки CSPM експортуються до авторизованої системи тікетингу або відстеження проблем програми — ServiceNow Government Cloud, Jira на засекреченому інстансі або спеціальний інструмент — де вони стають придатними до дій робочими елементами, призначеними команді хмарної платформи або команді застосунку, відповідальній за уражений ресурс. Кожен тікет містить ідентифікатор знахідки CSPM, ARN або еквівалент ураженого ресурсу, ступінь серйозності, посилання на застосовні засоби контролю відповідності, рекомендовану процедуру усунення та дату настання SLA, обчислену на основі часу створення знахідки та SLA-політики за ступенем серйозності.

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

Для засекреченої інфраструктури інтеграція тікетингу несе додаткові обмеження. Тікети, що містять конкретні деталі знахідок (назви ресурсів, IP-адреси, специфіку конфігурації), можуть потребувати розміщення в засекречених системах, якщо сама інформація є засекреченою. Програмам слід оцінити, чи досягають деталі знахідок CSPM рівня CUI або вище — як правило, так, особливо коли знахідки описують мережеве відкриття ресурсів із засекреченими іменами хостів — і відповідно маршрутизувати тікети. Незасекречені зведені показники (кількість знахідок, продуктивність SLA) можуть публікуватися в незасекречених системах.

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

ISSO подає запит на прийняття ризику з документуванням: конкретної знахідки, технічної або операційної причини, чому усунення не є негайно можливим, визначених компенсуючих засобів контролю, що знижують ризик у проміжному періоді, та запропонованого терміну прийняття (не більше 90 днів для знахідок Високого ступеня серйозності)
Команда безпеки перевіряє та валідує твердження щодо компенсуючих засобів контролю
AO перевіряє та підписує меморандум про прийняття ризику, офіційно приймаючи залишковий ризик
Знахідка вноситься як відкритий пункт POA&M у eMASS із прикріпленим підписаним меморандумом
CSPM придушує активне оповіщення про знахідку, зберігаючи її в історії аудиту з тегом номера запису про прийняття
Встановлюється нагадування за 30 днів до закінчення терміну прийняття для ініціювання відновлення або усунення

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

Безперервна звітність з відповідності

Процес ATO для систем DoD відповідно до Системи управління ризиками (RMF) вимагає вичерпного пакету доказів (BOE), що демонструє впровадження та ефективність засобів контролю безпеки. Для засобів контролю хмарної інфраструктури ці докази традиційно складалися з вручну згенерованих звітів сканування STIG та знімків екранів конфігурацій, підготовлених під час оцінки. CSPM дозволяє реалізувати принципово іншу модель: докази, що генеруються безперервно і доступні за вимогою, а не виробляються під час інтенсивного збору доказів перед кожною оцінкою.

Архітектура безперервної звітності CSPM з відповідності генерує три категорії результатів:

Автоматизовані пакети доказів ATO. Звіти відповідності CSPM, що експортуються щотижня та перед кожною подією оцінки, надають структуровані докази статусу впровадження засобів контролю. Звіти зіставлені з ідентифікаторами засобів контролю eMASS — звіт CSPM, відфільтрований за знахідками AU-2, демонструє стан конфігурації подій аудиту; звіт CM-6 демонструє виконання базового рівня конфігурації. Вони можуть бути передані до eMASS через REST API або завантажені як артефакти доказів. Роль ISSO переходить від генерації доказів до перевірки та сертифікації доказів, що система генерує автоматично.

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

Автоматизовані оновлення POA&M. Відкриті знахідки CSPM мають автоматично вноситися до POA&M eMASS як відкриті пункти. Коли знахідки усуваються і CSPM верифікує виправлену конфігурацію, відповідні пункти POA&M повинні оновлюватися доказами закриття. Це замикає цикл між інструментом безпеки та авторитетним записом впровадження засобів контролю — ISSO більше не потребує ручного перенесення інформації між системами, а AO завжди має точну картину відкритих знахідок та статусу їх усунення.

Зразок інтеграційного потоку від CSPM до eMASS ілюструє переміщення даних:

# CSPM → eMASS integration (illustrative)

CSPM Finding:
  id: CSPM-2026-06-25-0041
  check: aws-s3-bucket-encryption-enabled
  resource: arn:aws:s3:::dod-app-data-prod
  severity: High
  controls: [SC-28, SC-28(1), SRG-APP-000428]
  status: FAIL
  detected: 2026-06-25T09:14:22Z
  sla_due: 2026-07-25T09:14:22Z

eMASS POA&M Entry (auto-created):
  weakness_name: S3 bucket without encryption at rest
  control: SC-28(1) / SRG-APP-000428
  scheduled_completion: 2026-07-25
  milestone: Enable SSE-KMS with CMK on bucket dod-app-data-prod
  resources_required: Cloud platform team, 2h estimated
  status: Ongoing
  evidence_artifact: cspm-finding-CSPM-2026-06-25-0041.json

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

Ключовий висновок: Найпоширенішою причиною невдачі в оборонних розгортаннях CSPM є не вибір інструменту або охоплення політики — а повнота інтеграції. Інструмент CSPM, що сканує правильно, але не маршрутизує знахідки до eMASS, не забезпечує підзвітності за SLA та не генерує пакети доказів, готові для ATO, реалізує лише частину свого потенційного значення. Оборонним програмам слід вкладати стільки ж зусиль в архітектуру інтеграції (тікетинг, API eMASS, конвеєри звітності), скільки і в сам інструмент CSPM. Безперервне управління постурою — це процес і потік даних, а не просто сканер.

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

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

Послуги кіберзахисту → Послуги розробки

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

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

Що таке CSPM і чому оборонна хмара його потребує?

Управління безпековою постурою хмари (CSPM) — це категорія інструментів, що безперервно оцінює конфігурації хмарної інфраструктури відповідно до базових рівнів політики безпеки та рамок відповідності — виявляючи неправильні конфігурації, відхилення від політики та прогалини в засобах контролю в режимі реального часу. Оборонна хмара потребує CSPM, оскільки засекречені та державні хмарні навантаження мають суворі вимоги відповідності (DISA STIGs, NIST 800-53, FedRAMP High, базові рівні IL4/IL5), що змінюються з кожним оновленням STIG і можуть дрейфувати після операційних змін. CSPM замінює планові ручні аудити — що можуть проводитися лише раз на рік — безперервним автоматизованим скануванням, що виявляє неправильні конфігурації до того, як вони стають уразливостями або знахідками ATO.

Чим CSPM відрізняється від традиційного сканера вразливостей?

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

На які рамки відповідності відображає CSPM для середовищ DoD?

Основні рамки для DoD CSPM: DISA STIG Cloud Computing SRG, що визначає базовий рівень засобів контролю, специфічний для хмари, для всіх орендарів хмари DoD; NIST SP 800-53 Rev 5, що надає базовий каталог засобів контролю; базовий рівень FedRAMP High, що розширює засоби контролю 800-53 для авторизації хмари; а також специфічні для середовища накладки для IL4 та IL5. Інструменти CSPM зазвичай постачаються з пакетами правил для 800-53 і FedRAMP і можуть бути розширені кастомними правилами для засобів контролю STIG Cloud SRG, не охоплених загальними комерційними пакетами.

Які категорії неправильних конфігурацій несуть найвищий ризик в оборонній хмарі?

На основі вимог DISA STIG Cloud SRG та поширених знахідок ATO на рівнях IL4/IL5, найвищий ризик несуть: (1) неправильні конфігурації IAM — надмірно дозвільні рольові політики, шаблонні дозволи ресурсів, неактивні ключі доступу, що не ротуються; (2) публічний доступ до сховища — кошики об'єктного сховища з публічними ACL або політиками кошика, що дозволяють неавтентифікований доступ; (3) прогалини в шифруванні — томи або об'єктні сховища без шифрування в стані спокою або з шифруванням невалідованими алгоритмами FIPS; (4) прогалини в журналюванні — CloudTrail або еквівалент не увімкнені в кожному регіоні або обліковому записі, сховище журналів без перевірки цілісності; (5) мережеве відкриття — групи безпеки або правила брандмауера, що дозволяють вхідний доступ з 0.0.0.0/0 на управлінських портах. Ці п'ять категорій становлять більшість критичних знахідок в ATO хмари DoD.

Чи можуть інструменти CSPM працювати у повністю ізольованих або засекречених середовищах?

Так, але архітектуру розгортання необхідно суттєво адаптувати. Комерційні SaaS-продукти CSPM, що надсилають телеметрію до хмарної інфраструктури постачальника, не можуть використовуватися в середовищах IL5 або вище без ретельної оцінки — багато з них не авторизовані на таких рівнях впливу. Прийнятні підходи включають: розгортання на місці движків CSPM з відкритим кодом, таких як Prowler або Steampipe, в межах засекреченого анклаву; агентний CSPM, що виконує логіку сканування всередині анклаву без вихідної телеметрії; та авторизовані комерційні продукти CSPM з авторизацією FedRAMP High або IL4/IL5, що можуть бути розгорнуті в GovCloud або засекречених регіонах. Усі підходи вимагають, щоб бази даних вразливостей та правил оновлювалися через затверджені міждоменні механізми, а не через прямі інтернет-канали.

Що таке виявлення відхилень у контексті CSPM і чому це важливо після ATO?

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

Як ступінь серйозності знахідок CSPM має відповідати SLA усунення?

SLA усунення порушень CSPM для оборони мають відповідати структурі управління вразливостями DoD: Критично / STIG Категорія I — усунути протягом 15 днів або отримати офіційне прийняття ризику від AO; Високо / Категорія II — усунути протягом 30 днів; Середньо / Категорія III — усунути протягом 90 днів; Низько — задокументувати та відстежувати в POA&M до наступного циклу перевірки. Знахідки CSPM мають безпосередньо вноситися до POA&M програми в eMASS, і кожна знахідка повинна мати призначеного відповідального, цільову дату усунення та поточний статус. Прийняті винятки вимагають підпису AO та мають документувати залишковий ризик.

Що таке автоматизований запобіжник виправлення і коли він доречний в оборонному CSPM?

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

Як CSPM інтегрується з eMASS для безперервних доказів ATO?

eMASS — це система обліку DoD для авторизацій RMF. Результати CSPM можуть безперервно надходити до eMASS через кілька інтеграційних патернів: пряме передавання через API, де інструменти CSPM використовують REST API eMASS для передавання оновлень знахідок та змін статусу засобів контролю в режимі реального часу; інтеграція SIEM, де знахідки CSPM маршрутизуються через SIEM, що агрегує та експортує структуровані пакети доказів; та запланований експорт доказів, де звіти CSPM генеруються на визначеному інтервалі у форматах, сумісних із завантаженням доказів засобів контролю eMASS. Мета полягає в тому, щоб докази ATO для засобів контролю хмарної інфраструктури генерувалися автоматично з даних CSPM, а не збиралися вручну командою безпеки.

У чому різниця між безагентним та агентним скануванням CSPM для засекреченої хмари?

Безагентний CSPM використовує API постачальника хмарних послуг для переліку ресурсів та оцінки їх стану конфігурації без встановлення програмного забезпечення на самі ресурси. Він є легким, добре охоплює хмарні нативні ресурси та не впливає на продуктивність навантажень. Агентний CSPM встановлює сенсор на кожному обчислювальному інстансі, що збирає дані конфігурації на рівні ОС, стан запущених процесів та інформацію про цілісність файлів, яка не видна через хмарні API. Для засекреченої хмари безагентний підхід легше авторизувати і він має меншу поверхню атаки, але пропускає засоби контролю STIG на рівні ОС. Більшість зрілих розгортань CSPM у засекреченій хмарі використовують безагентне сканування для засобів контролю, що видно через хмарні API, та окреме рішення HBSS або на кінцевих точках для STIG на рівні хоста, інтегруючи обидва джерела даних в єдину інформаційну панель відповідності.