Безпечне віддалене керування PowerShell за допомогою Just-Enough-Administration (JEA)

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

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

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

Just-Enough-Administration — це технологія безпеки на основі PowerShell. що реалізує модель делегованого адміністрування з найменшими необхідними привілеями. На практиці JEA дозволяє надавати доступ до віддалених кінцевих точок, де доступний лише закритий набір командлетів, функцій, скриптів та зовнішніх команд, визначених вами.

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

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

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

Ризики привілейованих облікових записів та як JEA їх зменшує

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

Позбавлення привілеїв не завжди є тривіальним. Класичним прикладом є сервер, на якому розміщено DNS та контролер домену Active DirectoryКоманді DNS потрібні права локального адміністратора для усунення неполадок служби DNS, але додавання їх до групи адміністраторів домену фактично надає їм контроль над усім лісом і доступ до будь-якого ресурсу на цьому комп’ютері. Це класичний приклад жертвування безпекою заради зручності роботи.

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

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

Концепції безпеки, що лежать в основі JEA

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

Другим важливим стовпом є модель Контроль доступу на основі ролей (RBAC)JEA реалізує RBAC через файли можливостей ролей, де ви визначаєте, що може робити певна роль у віддаленому сеансі. Наприклад, роль служби підтримки може перераховувати служби, переглядати події та перезапускати певну службу, тоді як роль адміністратора SQL Server може виконувати лише командлети, пов'язані з... бази даних і трохи більше.

La Технічною основою JEA є PowerShell та його інфраструктура віддаленої взаємодіїPowerShell надає мову, командлети та рівень віддаленого зв'язку (WinRM/WS-Management), а JEA додає зверху систему обмежених кінцевих точок, віртуальних облікових записів та детального контролю над доступними командами.

Ще однією важливою концепцією є обмежене адміністрування, схожий на a Призначений доступ у режимі кіоску Windows 11Замість того, щоб надати оператору повну оболонку, JEA створює сеанс, де мова сценаріїв обмежена (за замовчуванням NoLanguage), створення нових функцій або змінних блокується, цикли та умовні оператори заборонені, а також дозволено виконувати лише затверджений набір командлетів. Це суттєво обмежує можливості зловмисника, якому вдається отримати доступ до цього сеансу.

Ключові компоненти: файли .psrc та .pssc

В основі будь-якого розгортання JEA лежать два типи файлів: файли можливостей ролей (.psrc) та файли конфігурації сеансу (.pssc)Разом вони перетворюють універсальну оболонку на ідеально налаштовану кінцеву точку для конкретних користувачів.

У файлі можливостей ролі, який ви визначаєте які саме команди доступні для роліСеред найважливіших елементів:

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

З іншого боку, файли конфігурації сеансу .pssc Вони описують кінцеву точку JEA як таку та пов'язують її з ролями.Тут оголошуються такі елементи, як наступні:

• Визначення ролейзіставлення користувачів або груп безпеки з можливостями ролей.
• Тип сеансу: де «RestrictedRemoteServer» зазвичай встановлено для посилення захисту сеансу.
• TranscriptDirectory: папка, де зберігаються стенограми кожного сеансу.
• RunAsVirtualAccount та пов’язані параметри, наприклад, чи додається віртуальний обліковий запис до певних груп.

JEA матеріалізується у формі Кінцеві точки віддаленого доступу PowerShell, зареєстровані в системіЦі кінцеві точки створюються та активуються за допомогою командлетів, таких як Новий файл конфігурації сеансу PSS, Реєстрація конфігурації сеансу PSS або графічні інструменти, такі як JEA Helper Tool, які спрощують створення файлів .pssc та .psrc без особливих труднощів із синтаксисом.

Життєвий цикл сеансу JEA

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

Спочатку ви створюєте a група безпеки або кілька груп що представляють ролі, які ви хочете делегувати (наприклад, HelpdeskDNS, веб-оператори, оператори SQL). Використання груп не є обов'язковим, але воно значно спрощує адміністрування в міру зростання середовища.

Потім готують один або декілька файли можливостей ролей .psrc У них перелічено дозволені дії: командлети, функції, скрипти, зовнішні команди, псевдоніми, постачальники та додаткові обмеження (певні параметри, дозволені шляхи тощо). Тут, наприклад, можна дозволити всі командлети, що починаються з Get-, обмежити Restart-Service службою Spooler та авторизувати лише постачальника FileSystem.

Генерується наступне файл конфігурації сеансу .pssc за допомогою New-PSSessionConfigurationFile. Він визначає такі параметри, як SessionType = RestrictedRemoteServer, шлях TranscriptDirectory, чи використовуються віртуальні облікові записи, а також блок RoleDefinitions, який пов'язує групи з можливостями ролі, наприклад, 'DOMAIN\HelpdeskDNS' = @{ RoleCapabilities = 'HelpdeskDNSRole' }.

Коли файл .pssc вже підготовлено, кінцеву точку реєструють за допомогою Register‑PSSessionConfiguration-Name JEASession Name-Path Path\File.psscЗ цього моменту, якщо доступні конфігурації відображатимуться в списку за допомогою Get-PSSessionConfiguration, нова точка підключення виглядатиме готовою до отримання підключень.

Користувачі підключаються до цієї кінцевої точки зі своїх комп'ютерів за допомогою Введіть PSSession -ім'я комп'ютера Server -ім'я конфігурації JEASession Name або за допомогою New-PSSession, а потім Invoke-Command. Після входу сеанс автоматично застосовує обмеження, визначені у пов'язаній з користувачем можливості ролі.

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

Зрештою, після закриття сесії JEA, Розшифровки та події аудиту зберігаються Ці журнали залишають чіткий слід виконаних команд, результатів та контексту користувача. Потім їх можна надсилати до системи SIEM або співвідносити всередині неї для сповіщень та подальшого аналізу.

Віддалений доступ, контроль доступу та посилення захисту PowerShell

Віддалене керування PowerShell, що підтримується службою Віддалене керування Windows (WinRM) Протокол WS-Management дозволяє централізовано виконувати команди та скрипти на віддалених комп'ютерах. Це потужний інструмент для автоматизації, масового управління серверами, налагодження та віддаленої підтримки.

За замовчуванням, локальні адміністратори та члени групи користувачів віддаленого керування Вони можуть використовувати стандартні кінцеві точки PowerShell. У багатьох середовищах ця можливість використовувалася, щоб дозволити користувачам без прав адміністратора запускати віддалені завдання, що само по собі не є небезпечним, але якщо це не контролювати належним чином, це відкриває значні можливості для зловживань.

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

• Об'єкти групової політики, що визначають, які групи можуть використовувати WinRM, та кінцеві точки за замовчуванням.
• Правила брандмауера, які дозволяють WinRM лише з підмереж або комп’ютерів керування.
• Видалення групи користувачів віддаленого керування зі списків контролю доступу (ACL) стандартних кінцевих точок.

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

JEA порівняно з іншими методами обмеження PowerShell

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

З одного боку, використання Групова політика для керування тим, хто входить до кінцевих точок PowerShell за замовчуваннямДоступ до Microsoft PowerShell можна обмежити адміністраторами або навіть скасувати для всіх, що примусово призведе до використання певних кінцевих точок. Це корисно для обмеження доступу методом «грубої сили», але не вирішує проблему деталізації: той, хто отримує доступ, може робити практично все.

З іншого боку, існують інструменти керування додатками, такі як Політики AppLocker або обмеження використання програмного забезпеченняЦі методи дозволяють заборонити виконання PowerShell.exe або pwsh.exe для звичайних користувачів, або за шляхом, видавцем, або за хешем. Такий підхід корисний для захисту робочих станцій та запобігання запуску PowerShell будь-яким користувачем, але він має обмеження, коли ви хочете, щоб хтось виконував обмежені адміністративні завдання зі свого облікового запису користувача.

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

JEA поєднує найкраще з кількох світів: суворе обмеження команд, RBAC, контрольоване виконання підвищених привілеїв та повне ведення журналуЦе робить його рекомендованим рішенням, коли вам потрібно ввімкнути віддалений доступ PowerShell для користувачів, які не є адміністраторами, але без надання їм повного середовища керування.

Розширені функції: запуск від імені іншого облікового запису та ведення журналу

Одна з найпотужніших можливостей JEA – це виконувати команди від імені іншого, більш привілейованого облікового запису, не розкриваючи свої облікові даніЦе вирішує типову проблему «Я дам тобі пароль для цієї служби, щоб ти міг зробити X», яка потім ніколи не змінюється і зрештою створює величезний ризик.

Доменні сценарії зазвичай використовуються Групові керовані облікові записи служб (gMSA) Це дозволяє кінцевим точкам JEA виконувати дії під централізовано керованим ідентифікатором служби, з автоматичною ротацією пароля та без будь-якого оператора, який би дізнався секрет. В інших випадках використовуються тимчасові віртуальні облікові записи, локальні для машини, які створюються ad hoc, коли користувач підключається, та знищуються в кінці сеансу.

З точки зору аудиту, кожен сеанс JEA може бути налаштований таким чином, щоб генерувати як транскрипти PowerShell, так і розширені записи журналу подійІнформація, яка зазвичай збирається, включає:

• Повна історія введених команд та параметрів.
• Згенерований вивід та повідомлення про помилки.
• Часова позначка початку та закінчення сеансу, а також його тривалість.
• Ідентифікація користувача, що ввійшов у систему, та призначена роль/повноваження.

Якщо поєднати ці сліди з функціональністю Журналування модуля PowerShell та Script Блокування логування через GPOА надсилаючи журнали до SIEM, ви отримуєте чітке уявлення про те, що відбувається на ваших кінцевих точках управління. Це критично важливо як для відповідності вимогам (аудити SOX, ISO 27001 тощо), так і для виявлення інцидентів та реагування на них.

Типові випадки використання JEA в реальних умовах

JEA сяє особливо тоді, коли вам це потрібно Делегування дуже специфічних завдань командам, які не повинні бути адміністраторамиДеякі дуже поширені приклади на практиці:

У сфері технічної підтримки ви можете надати послуги технічним спеціалістам найвищого рівня Доступ JEA для перезапуску служб, перегляду журналів подій та перевірки стану процесів на серверах, але без можливості встановлювати програмне забезпечення, змінювати критичні конфігурації або отримувати доступ до Active Directory. Типова роль служби підтримки може включати такі командлети, як Get-Service, Restart-Service для певних служб, Get-EventLog у режимі лише для читання та деякі командлети мережевої діагностики.

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

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

Водночас, JEA дуже добре поєднується з Стратегії управління привілейованим доступом (PAM)де привілейовані сесії надаються тимчасово, реєструються та приписуються особистим особам, уникаючи спільних облікових записів та мінімізуючи ризик, пов'язаний з кожною привілейованою дією.