- JEA прилага принципа на най-малките привилегии в PowerShell отдалечена работа, намаляване на броя на акаунтите с повишени привилегии и ограничаване на командлетите, налични за всяка роля.
- Комбинацията от .psrc и .pssc файлове ви позволява да дефинирате възможности на ролите, ограничени крайни точки, виртуални акаунти и подробни преписи за пълен одит.
- В сравнение с подходи като GPO, AppLocker или генерични крайни точки, JEA предлага много по-детайлно управление и надежден RBAC модел за делегиране на задачи без разкриване на привилегировани идентификационни данни.
- Правилното му внедряване изисква внимателно проектиране на ролите, тестване и непрекъсната поддръжка, но осигурява значително повишаване на сигурността, без да се жертва производителността.
Използването на PowerShell за отдалечено взаимодействие стана почти задължително във всяка среда. Windows Модерно, но предоставянето на отдалечен достъп без контрол е все едно да оставите ключовете от центъра за данни на масата. Тук се намесва играта. Администрация с достатъчно средства (JEA), слой сигурност, който ви позволява да делегирате задачи, без да раздавате администраторски права наляво и надясно.
С JEA можете да настроите много ограничени точки за отдалечен достъп, където само определени потребители изпълняват команди които сте оторизирали, под акаунти с повече привилегии, но без да знаят истинските данни или да могат да се отклонят от сценарияИ всичко това беше записано в преписи и трупи подробни, които ви позволяват да проверите кой какво е направил, кога и откъде.
Какво е Just-Enough-Administration (JEA) и защо е важно?
Just-Enough-Administration е технология за сигурност, базирана на PowerShell. който имплементира делегиран модел на администриране с най-малките необходими привилегии. На практика JEA ви позволява да изложите отдалечени крайни точки, където е наличен само затворен набор от командлети, функции, скриптове и външни команди, дефинирани от вас.
Благодарение на този подход, можете драстично намаляване на броя на акаунтите с повишени привилегии На вашите сървъри можете да използвате виртуални акаунти или групово управлявани акаунти за услуги (gMSAs), които изпълняват привилегировани действия от името на стандартни потребители. Потребителят влиза с обичайните си идентификационни данни и чрез JEA сесията стартира команди, които се изпълняват зад кулисите с по-високи привилегии.
Друг ключов стълб на JEA е способността да да се определи точно какво може да прави всяка роляФайловете с възможности за роли определят кои командлети, персонализирани функции, външни команди или доставчици на PowerShell са видими. Останалото просто не съществува за потребителя: той не може да импровизира скриптове, свободно да навигира във файловата система или да осъществява достъп до услуги или процеси, които не сте посочили.
Освен това, всички JEA сесии могат да бъдат конфигурирани да генерират пълни преписи и одитни събитияЗаписването на команди, параметри, изход, грешки, потребителска идентичност и време за изпълнение не само помага за спазване на регулаторните изисквания, но е и безценно при разследване на инцидент със сигурността или оперативен проблем.
Рисковете от привилегированите акаунти и как JEA ги смекчава
Локални, домейн или администраторски акаунти на приложения с повишени разрешения предполагат един от най-сериозните вектори на риск във всяка организацияАко нападател получи едно от тези идентификационни данни, той може да се придвижи странично през мрежата, да повиши привилегиите си и да получи достъп до критични данни, ключови услуги или дори да свали цели системи.
Премахването на привилегии не винаги е тривиално. Класически пример е този на сървър, който хоства както DNS, така и домейн контролер на Active DirectoryDNS екипът се нуждае от локални администраторски права, за да отстранява проблеми с DNS услугите, но добавянето им към групата „Администратори на домейна“ ефективно им предоставя контрол над цялата гора и достъп до всеки ресурс на тази машина. Това е класически пример за жертване на сигурността за удобство при работа.
JEA разрешава тази дилема, като стриктно прилага принцип на най-малките привилегииВместо да правите DNS администратори администратори на домейни, можете да създадете специална DNS JEA крайна точка, която предоставя само командлетите, необходими за изчистване на кеша, рестартиране на услугата, преглед на лог файлове или подобни задачи. Това позволява на оператора да изпълнява работата си, без да се налага да преглежда Active Directory, да навигира във файловата система, да изпълнява произволни скриптове или да изпълнява потенциално опасни помощни програми.
Когато конфигурирате JEA сесии да използват виртуални акаунти с временни разрешенияХодът е още по-интересен: потребителят се свързва с непривилегировани идентификационни данни и от тази сесия може да изпълнява задачи, които обикновено изискват администраторски права. Това позволява много потребители да бъдат премахнати от локални или домейн администраторски групи, като същевременно се поддържат операциите, като същевременно значително се засилва повърхността за атака.
Концепции за сигурност, които са в основата на JEA
JEA не се е появила от нищото: Тя се основава на няколко добре установени принципа и модела за сигурност. които му придават съгласуваност и стабилност. Първият е гореспоменатият принцип на най-малките привилегии, който диктува, че както потребителите, така и процесите трябва да имат само разрешенията, необходими за техните функции.
Вторият основен стълб е моделът на Контрол на достъпа, базиран на роли (RBAC)JEA имплементира RBAC чрез файлове с възможности за роли, където дефинирате какво може да прави дадена роля в рамките на отдалечена сесия. Например, роля на помощен център може да изброява услуги, да преглежда събития и да рестартира конкретна услуга, докато роля на администратор на SQL Server може да изпълнява само командлети, свързани с... бази данни и малко повече.
La Техническата основа на JEA е PowerShell и неговата инфраструктура за отдалечено взаимодействиеPowerShell предоставя езика, командлетите и слоя за отдалечена комуникация (WinRM/WS-Management), а JEA добавя отгоре система от ограничени крайни точки, виртуални акаунти и подробен контрол върху това кои команди са налични.
Друга важна концепция е ограничена администрация, подобно на а назначен достъп в режим на киоск в Windows 11Вместо да предостави на оператора пълна обвивка, JEA конструира сесия, в която скриптовият език е ограничен (по подразбиране NoLanguage), създаването на нови функции или променливи е блокирано, циклите и условните оператори са забранени и е разрешено изпълнението само на одобрения набор от командлети. Това силно ограничава възможностите на атакуващ, който успее да получи достъп до тази сесия.
Ключови компоненти: .psrc и .pssc файлове
В основата на всяко JEA внедряване са два типа файлове: файлове за възможности на ролите (.psrc) и файлове за конфигурация на сесията (.pssc)Заедно те трансформират универсална обвивка в перфектно пригодена крайна точка за конкретни потребители.
Във файл с възможности за роля, който дефинирате точно кои команди са достъпни за ролятаСред най-важните елементи са:
- Видими команди (Cmdlets): списък с разрешени командлети, дори възможност за ограничаване на параметри.
- Видими функции: персонализирани функции, които се зареждат в сесията.
- ВидимиВъншниКоманди: специфични външни изпълними файлове, до които се осъществява достъп.
- Видими доставчициДоставчиците на PowerShell (например FileSystem или Registry), видими в сесията.
Конфигурационните файлове на сесията .pssc, от друга страна, Те описват крайната точка на JEA като такава и я свързват с ролите.Тук са декларирани елементи като следните:
- Дефиниции на ролисъпоставяне на потребители или групи за сигурност с възможности на ролите.
- Тип на сесията: където „RestrictedRemoteServer“ обикновено е настроено за защита на сесията.
- Директория за преписи: папка, където се съхраняват преписите от всяка сесия.
- ИзпълнявайКатоВиртуаленАкаунт и свързани опции, като например дали виртуалният акаунт се добавя към конкретни групи.
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 -Име JEASession Name -Път Path\File.psscОт този момент нататък, ако наличните конфигурации са изброени с Get-PSSessionConfiguration, новата точка на свързване ще изглежда готова за приемане на връзки.
Потребителите се свързват с тази крайна точка от своите компютри с Enter‑PSSession -ComputerName Server -ConfigurationName JEASession Name или с New-PSSession и след това Invoke-Command. При влизане, сесията автоматично прилага ограниченията, дефинирани в свързаната с потребителя възможност на ролята.
По време на сесията, PowerShell remoting използва WinRM с криптирани каналиИнтегрирано удостоверяване (обикновено Kerberos в домейна) и правилата на защитната стена, дефинирани за услугата. В основата на това, ако RunAsVirtualAccount е активиран, се създава временен виртуален акаунт, който се добавя към необходимите групи и се унищожава при приключване на сесията.
Накрая, след закриването на сесията на JEA, Преписите от одита и събитията се запазват Тези лог файлове оставят ясна следа от изпълнени команди, резултати и потребителски контекст. След това те могат да бъдат изпратени или съпоставени в рамките на SIEM система за предупреждения и по-нататъшен анализ.
PowerShell отдалечено взаимодействие, контрол на достъпа и втвърдяване
PowerShell Remoting, поддържан от услугата Дистанционно управление на Windows (WinRM) Протоколът WS-Management позволява централизирано изпълнение на команди и скриптове на отдалечени компютри. Той е мощен инструмент за автоматизация, масово управление на сървъри, отстраняване на грешки и дистанционна поддръжка.
По подразбиране, локални администратори и членове на групата „Потребители за отдалечено управление“ Те могат да използват стандартни крайни точки на PowerShell. В много среди тази възможност се използва, за да се позволи на потребители, които не са администратори, да изпълняват отдалечени задачи, което само по себе си не е опасно, но ако не се контролира правилно, отваря значителен път за злоупотреба.
За да се укрепи позицията по сигурност, общата стратегия включва Ограничете отдалечения достъп до PowerShell само до администраторски акаунти. Или, още по-добре, комбинирайте това ограничение с крайни точки на JEA, които предоставят на определени потребители само строго необходимия достъп. Това може да се постигне чрез:
- GPO, които определят кои групи могат да използват WinRM и крайните точки по подразбиране.
- Правила на защитната стена, които позволяват WinRM само от подмрежи или компютри за управление.
- Премахване на групата „Потребители за отдалечено управление“ от ACL на стандартните крайни точки.
Освен това, можете да изберете да Напълно блокиране на PowerShell за потребители, които не са администратори използвайки решения като AppLocker. По този начин предотвратявате изпълнението на злонамерени скриптове локално от стандартен потребител, но все пак позволявате на привилегировани акаунти да използват PowerShell за задачи за управление и автоматизация.
JEA спрямо други методи за ограничаване на PowerShell
Има няколко начина да ограничите какво могат да правят потребителите с отдалечено взаимодействие с PowerShell. JEA е по-тънък и по-гъвкав вариант в рамките на диапазон, който включва по-широки подходи, като например:
От една страна, използването на GPO за контрол на това кой влиза в крайните точки на PowerShell по подразбиранеMicrosoft PowerShell може да бъде ограничен до администратори или дори нерегистриран за всички, което налага използването на специфични крайни точки. Това е полезно за ограничаване на достъпа по начин на „груба сила“, но не решава проблема с гранулираността: който получи достъп, може да прави почти всичко.
От друга страна, има инструменти за контрол на приложенията, като например Политики за AppLocker или ограничаване на софтуераТези методи ви позволяват да откажете изпълнението на PowerShell.exe или pwsh.exe на стандартни потребители, по път, издател или хеш. Този подход е полезен за защита на работните станции и предотвратяване на стартирането на PowerShell от който и да е потребител, но представя ограничения, когато искате някой да изпълнява ограничени административни задачи от потребителския си акаунт.
Друг вариант са Ограничени крайни точки без достигане на пълен JEAМожете да създавате персонализирани конфигурации на сесии, които ограничават командлети, функции и модули, но без да разчитате толкова силно на ролевия модел, виртуалните акаунти или структурирания RBAC, които JEA предоставя. Това е един вид среден път, подходящ за прости сценарии, но по-малко мащабируем в големи среди.
JEA съчетава най-доброто от няколко свята: строго ограничение на командите, RBAC, контролирано изпълнение с повишени привилегии и цялостно регистриранеТова го прави препоръчителното решение, когато е необходимо да активирате отдалечено взаимодействие с PowerShell за потребители, които не са администратори, но без да им предоставяте пълна среда за управление.
Разширени функции: стартиране като друг акаунт и регистриране
Една от най-мощните възможности на JEA е изпълнявайте команди като друг, по-привилегирован акаунт, без да разкривате своите идентификационни данниТова решава типичния проблем „Ще ти дам паролата за тази услуга, за да можеш да направиш X“, който след това никога не се променя и в крайна сметка се превръща в огромен риск.
Доменните сценарии се използват често Групови управлявани сервизни акаунти (gMSA) Това позволява на крайните точки на JEA да изпълняват действия под централно управлявана идентичност на услугата, с автоматична ротация на паролата и без оператор да знае тайната. В други случаи се използват временни виртуални акаунти, локални за машината, създавани ad hoc, когато потребител се свърже, и унищожавани в края на сесията.
От гледна точка на одита, всяка JEA сесия може да бъде конфигурирана да генериране както на PowerShell транскрипти, така и на записи в дневника на събитията с богат набор от данниИнформацията, която обикновено се събира, включва:
- Пълна история на въведените команди и параметри.
- Генериран изход и съобщения за грешки.
- Времеви отпечатък на началото и края на сесията, както и нейната продължителност.
- Самоличност на влезлия потребител и присвоената му роля/капацитет.
Ако комбинирате тези следи с функционалностите на Регистриране на PowerShell модул и Сценарий Блокиране на регистриране чрез GPOИ като изпращате лог файловете до SIEM, получавате стабилна видимост за това какво се случва на вашите крайни точки за управление. Това е от решаващо значение както за съответствието (SOX одити, ISO 27001 и др.), така и за откриването и реагирането на инциденти.
Типични случаи на употреба на JEA в реални среди
JEA блести особено когато имате нужда Делегиране на много специфични задачи на екипи, които не би трябвало да са администраториНякои много често срещани примери в практиката са:
В областта на техническата поддръжка можете да предоставите услуги на техници от най-високо ниво JEA достъп за рестартиране на услуги, преглед на регистрационни файлове на събития и проверка на състоянието на процесите на сървъри, но без възможност за инсталиране на софтуер, промяна на критични конфигурации или достъп до Active Directory. Типична роля на помощен специалист може да включва командлети като Get-Service, Restart-Service за специфични услуги, Get-EventLog в режим само за четене и някои командлети за мрежова диагностика.
В екипите за операции или разработка можете да конфигурирате роли, фокусирани върху специфични задачи, като например администриране на IIS или поддръжка на уебсайтовеНапример, разрешаване на достъп до командлети за управление на пул приложения, рестартиране на уебсайтове, заявки към регистрационни файлове от ограничена директория и управление на сертификати за конкретни услуги, като същевременно се изключва всякаква възможност за рестартиране на целия сървър или промяна на политики за сигурност.
В хибридни и облачни среди, JEA често се използва за ограничаване на това, което всеки екип може да направи по отношение на виртуални машини, съхранение или мрежиМожете да разкриете крайни точки, които ви позволяват да управлявате само виртуалните машини на даден отдел, да променяте правилата на защитната стена на конкретен сегмент или да управлявате конкретен набор от сервизни акаунти, като държите достъпа отделен от останалата част от инфраструктурата.
В същото време, JEA се вписва много добре с Стратегии за управление на привилегирован достъп (PAM)където привилегированите сесии се предоставят временно, регистрират се и се приписват на лични самоличности, като се избягват споделени акаунти и се минимизира рискът, свързан с всяко привилегировано действие.
Страстен писател за света на байтовете и технологиите като цяло. Обичам да споделям знанията си чрез писане и това е, което ще направя в този блог, ще ви покажа всички най-интересни неща за джаджи, софтуер, хардуер, технологични тенденции и много други. Моята цел е да ви помогна да се ориентирате в дигиталния свят по лесен и забавен начин.