Управління привілейованим доступом в оборонних мережах: PAM з усвідомленням грифу

Управління привілейованим доступом (PAM) в оборонній мережі — це не та сама задача, що PAM розв'язує в комерційному підприємстві. Банк, що неправильно зробив PAM, втрачає дані клієнтів; оборонна організація, що неправильно зробила PAM, втрачає мережу — і операції, що на ній запущені. Акредитаційний орган це знає, і ланцюг аудиту це відображає. Ця стаття проходить через інженерні рішення, що відокремлюють оборонно-рівневе розгортання PAM від комерційного, спираючись на патерни, які ми бачили успішними (і провальними) всередині засекречених анклавів, SCIF-резидентних робочих процесів та OT-естейтів. Для ширшої картини див. наш повний гід з оборонної кібербезпеки.

1. Чому PAM в обороні інакший

Три властивості роблять оборонний PAM структурно інакшим від комерційного. По-перше, користувачі мульти-грифові: той самий людський оператор може мати акаунти в несекретній адміністративній LAN, у місії з грифом SECRET та в розвідувальному анклаві TOP SECRET, і PAM-платформа ніколи не повинна посередничати з обліковими даними через цей кордон. По-друге, найцінніші робочі процеси SCIF-резидентні — користувач, робоча станція, jump-host і vault усі всередині однієї акредитованої кімнати, і будь-який компонент, що живе поза SCIF, за визначенням є неправильною архітектурою. По-третє, очікування ланцюга аудиту значно суворіше, ніж у комерційному: акредитаційний орган не приймає "у нас є логи" — він очікує tamper-evident, відтворюваного, з обмеженою ретенцією запису кожної привілейованої дії, прив'язаного до допущеної особи, що переживає, коли мережа офлайн тижнями.

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

2. CyberArk / HashiCorp Vault / BeyondTrust / Delinea

CyberArk залишається incumbent для засекречених розгортань в оборонних організаціях країн-членів NATO. Його Privileged Session Manager (PSM) зрілий, FIPS 140-2 валідований, а Enterprise Password Vault має сертифікацію Common Criteria EAL4+ — обидва пункти, які акредитор перевірить першими. Вартість крута, а ліцензійна модель припускає підключення до інфраструктури оновлень CyberArk, що змушує до workflow офлайн-оновлень усередині air-gapped анклавів.

HashiCorp Vault (Enterprise) — вибір, коли навантаження API-driven, ефемерне і Kubernetes-суміжне. Його dynamic-secrets і PKI-движки відмінні для випуску короткоживучих X.509, що дедалі більше стає тим, як аутентифікуються сучасні оборонні навантаження. Vault Enterprise підтримує режим FIPS 140-2 і HSM-інтеграцію через PKCS#11. Його слабкість в оборонному контексті — брокеринг сесій — Vault — це секретний движок, а не сесійний проксі, тож інтерактивний адмін-workflow потребує окремого компонента (Boundary або сторонній бастіон), нашарованого зверху.

BeyondTrust (Password Safe + Privileged Remote Access) має найсильнішу OT/ICS-історію з чотирьох. Його jump-host модель була спроєктована для вендор-керованого віддаленого доступу в промислові заводи, що чисто відображається на робочі процеси депо-обслуговування та OEM-підтримки, які оборонні логістичні організації фактично запускають. FIPS 140-2 валідований; конвеєр запису сесій — найзріліший з будь-якого продукту в цій категорії.

Delinea (раніше Thycotic + Centrify) — легша опція, що часто обирається для суб-анклавів, де повний слід CyberArk надмірний. Secret Server FIPS 140-2 валідований; Server Suite покриває AD-bridging для Linux/Unix, від якого досі залежать старі оборонні естейти.

На всіх чотирьох іде перехід до FIPS 140-3 — валідації 140-2 залишаються прийнятними за перехідними правилами протягом акредитаційного циклу 2026 в більшості NATO-контекстів, але нові розгортання мають специфікувати 140-3 там, де вендор пропонує. Покриття Common Criteria нерівне; CyberArk і BeyondTrust мають найглибші розклади.

3. Брокеринг сесій із усвідомленням грифу

Найважливіше архітектурне рішення в оборонному PAM — чи платформа брокерить сесії через грифові кордони — і правильна відповідь завжди "ні." Кожен анклав отримує власний vault, власний session manager і власне аудит-сховище. Обліковий запис для SECRET-адмінського акаунта ніколи не існує в несекретному vault, навіть зашифрований, навіть "для break-glass." Якщо акредитація знайде один-єдиний запис вищеграфового облікового запису всередині нижчеграфового компонента, усе розгортання повертається на старт.

Крос-анклавна ескалація сесії — workflow, де оператор на несекретній стороні має дістатися до SECRET-хоста — розв'язується на межі cross-domain-solution (CDS), а не всередині PAM-платформи. Оператор аутентифікується всередині вищеграфового анклаву; CDS не пропускає облікові дані. PAM-платформа з кожного боку не знає про іншу. Це чисто відображається на модель військових мереж zero-trust, де кожен анклав — це власний trust-домен.

Для SCIF-резидентних робочих процесів vault, session manager та аудит-collector усі живуть всередині SCIF. Спокуса хостити management plane поза SCIF "для зручності адміністрування" — найпоширеніша архітектурна помилка, яку ми бачимо, і вона невідновна — акредитор не схвалить віддалений канал управління в SCIF-резидентне сховище облікових даних, незалежно від того, як воно зашифроване.

4. Just-in-Time (JIT) ескалація

JIT-ескалація — це дисципліна надавати привілейований доступ лише в той момент, коли він потрібен, на тривалість, що потрібна, і автоматично відкликати його після. В оборонних мережах вона замінює давній патерн "обслуговуюча команда має Domain Admin постійно, бо іноді він потрібен о 3 ранку" — а це саме той патерн, який експлуатує противник із persistent-доступом.

Архітектура має три компоненти. Перший — request-workflow — типово інтегрований з тікетинговою системою — де оператор просить ескалацію зі вказаною причиною та тривалістю. Другий — шлях схвалення: для рутинного обслуговування це може бути policy-автоматизовано; для break-glass у OT-системи або криптографічний ключовий матеріал — вимагає схвалення другого допущеного оператора (принцип чотирьох очей). Третій — механізм випуску: PAM-платформа карбує time-bounded обліковий запис — ефемерний SSH-сертифікат (типово 1–4 години), короткоживучий X.509 клієнтський серт для API-доступу або тимчасове членство в AD-групі, що закінчується за запланованим таймером.

Ефемерні SSH-сертифікати — найчистіший патерн для Linux/Unix адміністрування: запит оператора тригерить Vault (або еквівалент CyberArk) скарбувати сертифікат, підписаний SSH CA, на конкретні хости з 4-годинною дійсністю. Жоден довгоживучий публічний ключ не залишається на цільовому хості, і відкликання автоматичне, коли серт закінчується. Для Windows-адміністрування короткоживучі X.509 клієнтські серти у поєднанні зі зчитувачами смарт-карт досягають тієї ж властивості, використовуючи апаратний корінь довіри, вже присутній на більшості оборонних робочих станцій.

5. Сервісні акаунти та секрети

Рекомендовані вендором ритми ротації — 30 днів для сервісних акаунтів, 90 днів для секретів додатків, щорічно для коренів CA — це легка частина. Важка частина — ротація в air gap. Підключене підприємство ротує пароль сервісного акаунта, і новий обліковий запис поширюється через Active Directory, secrets-store, споживаючий додаток і моніторингову систему за секунди. Усередині air-gapped анклаву кожен із цих кроків ручний, запланований і ризиковий — а вікно обслуговування міряється однозначними годинами, часто вночі, часто з резервним оператором у режимі очікування.

Реалістична оперативна відповідь — пошарові ритми: облікові дані високої цінності (Domain Admin, корені CA, ключі розблокування KMS) ротуються на прискорених графіках із повною дисципліною change-control; середньої цінності (сервісні акаунти БД, application-principals) ротуються через автоматизовані PAM-workflow під час планових вікон обслуговування; низької цінності, але довгоживучі (legacy-app акаунти, embedded device паролі) інвентаризуються, ховаються в vault і ротуються за найповільнішим ритмом, який прийме реєстр ризиків.

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

6. PAM для OT / промислових установок

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

Перший — архітектура jump-host: кожне адміністративне підключення до OT-мережі завершується на твердненому бастіоні, що брокерить протокол (RDP, VNC, serial-over-IP), забезпечує запис сесії та ізолює робочу станцію оператора від керуючої мережі. Privileged Remote Access від BeyondTrust — еталонна реалізація; PSM for SSH від CyberArk та open-source Apache Guacamole патерн покривають той самий ґрунт за різних цінових точок.

Друге — проблема "пароль не міняли 15 років". PLC, HMI та historian-сервери постачалися від OEM зі стандартними або рідко-ротованими обліковими даними, і ротація ризикує "цеглування" пристрою або порушення вендорського контракту підтримки. Прагматична відповідь — заховати облікові дані в vault (щоб принаймні шлях доступу аудитувався і cleartext був вилучений з пам'яті оператора та post-it нотаток), відкласти ротацію до наступного запланованого вікна простою і задокументувати залишковий ризик у пакеті акредитації.

Третє — вендор-керований віддалений доступ. OEM-техніки повинні дістатися обладнання для гарантійної підтримки. PAM-платформа посередничає у цьому як повністю записана, time-bounded сесія, брокерована через jump-host — ніколи як постійний VPN-тунель в OT-мережу. Акаунт вендора JIT-випущений, сесія записана end-to-end, а допущений оператор з оборонної сторони схвалює й спостерігає.

7. Ланцюг аудиту та запис сесій

Ланцюг аудиту — артефакт, який акредитаційний орган цінує найбільше, і саме його оборонні PAM-розгортання найчастіше недобудовують. Три шари мають значення. Кейлоггінг захоплює буквальні команди, що оператор набрав у привілейованій сесії — безцінно для форензики, дорого по сховищу, з дисципліною ретенції. Відео-запис сесії захоплює відрендерені кадри RDP/VNC — необговорюваний для сесій SCADA/HMI, де взаємодія оператора графічна, а не текстова. Командний аудит захоплює структуровану подію ("користувач X підвищився до ролі Y на хості Z у час T за тікетом #N") — шар, що SOC фактично споживає в SIEM-кореляції та zero-trust верифікації.

Дисципліна довгої ретенції — те, де комерційні PAM-плейбуки відстають. Оборонні горизонти ретенції регулярно сягають 7–10 років, іноді довше для ядерно-суміжних або стратегічно-системних контекстів. Шар сховища має бути незмінним (WORM-клас або write-once object storage із замками ретенції), цілісність має бути криптографічно заякорена (підписані маніфести, hash-chained логи), а шлях отримання має працювати в 2034 з людьми та інструментами, доступними тоді — не сьогодні.

Узгодженість із GDPR та NIS2 має значення в EU оборонних контекстах. Запис сесії захоплює персональні дані (натискання клавіш оператора, іноді його обличчя на webcam-увімкненій сесії). Законна підстава під GDPR типово — "правовий обов'язок" плюс "законний інтерес" з задокументованими лімітами ретенції та контролями доступу. NIS2 підсилює це явними вимогами щодо реагування на інциденти та доступності аудиту, яким PAM-логування прямо служить.

8. Міграція та співіснування

Реалістичний таймлайн привести AD-only оборонний естейт до сучасного PAM — від двох до чотирьох років. Перший рік — discovery і vaulting: кожен привілейований обліковий запис інвентаризується, ховається в vault і приводиться під workflow check-out/check-in, без зміни того, як оператори ще працюють. Другий рік — брокеринг сесій: інтерактивні адмін-сесії переходять за PAM-проксі, починається запис, ланцюг аудиту виходить онлайн. Третій рік — JIT-ескалація і ротація: постійні привілеї конвертуються в time-bounded, ритми ротації забезпечуються. Четвертий рік, якщо потрібно, — чистка довгохвостових сервісних акаунтів і OT-облікових даних.

Співіснування з legacy AD-only патернами — норма, не виняток, упродовж більшості цього таймлайну. PAM-платформа брокерить доступ до AD-приєднаних хостів, ховає в vault AD-облікові дані і поступово замінює постійне членство Domain Admin на JIT-ескалацію через shadow-групи. Спроби перевести весь естейт за один вікенд провалювалися щоразу, як ми бачили їх спроби.

Тяжко здобутий урок: PAM-rollback гірший за повільний rollout. Щойно популяція операторів переведена на vault-брокеровані, JIT-ескальовані, повністю-аудитовані workflow, відкат до старого "Domain Admin постійно" патерну оперативно і культурно майже неможливий — аудиторський провал видимий, SOC звик залежати від телеметрії, а пакет акредитації оновлений. Частковий rollout, що тримається, кращий за повний rollout, який треба буде відкочувати. Плануйте фази так, щоб кожна була незалежно стабільною, і ставтеся до багаторічного ритму як до фічі, а не до баґу.