Bezpečná vzdálená komunikace PowerShellu s Just-Enough-Administration (JEA)

Používání vzdálené komunikace PowerShellu se stalo téměř nepostradatelným v jakémkoli prostředí. Windows Moderní, ale udělení vzdáleného přístupu bez kontroly je jako nechat klíče od datového centra na stole. A tady to přichází na řadu. Správa tak akorát (JEA), což je vrstva zabezpečení, která vám umožňuje delegovat úkoly, aniž byste museli vzdát administrátorská práva nalevo i napravo.

S JEA můžete nastavit velmi omezený počet vzdálených přístupových bodů, kde specifičtí uživatelé spouštějí pouze příkazy které jste autorizovali, pod účty s většími oprávněními, ale bez znalosti skutečných kvalifikací nebo možnosti odchýlit se od scénářeA to vše bylo zaznamenáno v přepisech a protokoly podrobné, které vám pak umožní auditovat, kdo co udělal, kdy a odkud.

Co je to administrativa s dostatečnými prostředky (JEA) a proč je důležitá?

Just-Enough-Administration je bezpečnostní technologie založená na PowerShellu. který implementuje model delegované správy s nejmenšími potřebnými oprávněními. V praxi vám JEA umožňuje zpřístupnit vzdálené koncové body, kde je k dispozici pouze uzavřená sada cmdletů, funkcí, skriptů a externích příkazů definovaných vámi.

Díky tomuto přístupu můžete drasticky snížit počet účtů se zvýšenými oprávněními Na vašich serverech můžete používat virtuální účty nebo skupinově spravované servisní účty (gMSA), které provádějí privilegované akce jménem standardních uživatelů. Uživatel se přihlásí pomocí svých běžných přihlašovacích údajů a prostřednictvím relace JEA spouští příkazy, které se provádějí v zákulisí s vyššími oprávněními.

Dalším klíčovým pilířem JEA je schopnost přesně definovat, co každá role může dělatSoubory s funkcemi rolí definují, které cmdlety, vlastní funkce, externí příkazy nebo poskytovatelé PowerShellu jsou viditelné. Zbytek pro uživatele jednoduše neexistuje: nemůže improvizovat skripty, volně se pohybovat v souborovém systému ani přistupovat ke službám nebo procesům, které jste neurčili.

Kromě toho lze všechny relace JEA nakonfigurovat tak, aby generovaly úplné přepisy a auditní akceZachycování příkazů, parametrů, výstupu, chyb, identity uživatelů a doby provádění nejen pomáhá splňovat regulační požadavky, ale je také neocenitelné při vyšetřování bezpečnostního incidentu nebo provozní poruchy.

Rizika privilegovaných účtů a jak je JEA zmírňuje

Lokální, doménové nebo aplikační administrátorské účty se zvýšenými oprávněními znamenají jeden z nejzávažnějších rizikových vektorů v jakékoli organizaciPokud útočník získá jeden z těchto přihlašovacích údajů, může se pohybovat laterálně po síti, zvyšovat oprávnění a získávat přístup ke kritickým datům, klíčovým službám nebo dokonce vyřadit celé systémy.

Odebrání privilegií není vždy triviální. Klasickým příkladem je server, který hostuje DNS i řadič domény Active DirectoryTým DNS potřebuje k řešení problémů se službou DNS oprávnění lokálního správce, ale přidání správce do skupiny Domain Admins mu v podstatě poskytuje kontrolu nad celou doménovou strukturou a přístup k jakémukoli zdroji na daném počítači. Toto je klasický příklad obětování zabezpečení ve prospěch provozního pohodlí.

JEA řeší toto dilema striktním uplatňováním princip nejmenších privilegiíMísto toho, abyste ze správců DNS udělali správce domény, můžete vytvořit vyhrazený koncový bod DNS JEA, který zpřístupňuje pouze rutiny potřebné pro vymazání mezipaměti, restartování služby, kontrolu protokolů nebo podobné úkoly. To umožňuje operátorovi vykonávat svou práci, aniž by musel prověřovat službu Active Directory, procházet souborový systém, spouštět náhodné skripty nebo potenciálně nebezpečné nástroje.

Při konfiguraci relací JEA pro použití virtuální účty s dočasnými oprávněnímiTento krok je ještě zajímavější: uživatel se připojuje s neprivilegovanými přihlašovacími údaji a z této relace může provádět úlohy, které obvykle vyžadují administrátorská práva. To umožňuje odebrat mnoho uživatelů z lokálních nebo doménových administrátorských skupin, zachovat provoz a zároveň výrazně posílit povrch pro útok.

Bezpečnostní koncepty, které jsou základem JEA

JEA se neobjevila z ničeho nic: Je založen na několika osvědčených bezpečnostních principech a modelech. které mu dodávají koherenci a robustnost. Prvním je výše zmíněný princip nejnižších privilegií, který říká, že uživatelé i procesy by měli mít pouze oprávnění nezbytná pro jejich funkce.

Druhým hlavním pilířem je model Řízení přístupu na základě rolí (RBAC)JEA implementuje RBAC prostřednictvím souborů s funkcemi rolí, kde definujete, co může konkrétní role dělat v rámci vzdálené relace. Například role helpdesku může vypisovat služby, zobrazovat události a restartovat konkrétní službu, zatímco role administrátora SQL Serveru může spouštět pouze cmdlety související s... databází a trochu víc.

La Technickým základem JEA je PowerShell a jeho infrastruktura pro vzdálenou komunikaci.PowerShell poskytuje jazyk, rutiny a vrstvu vzdálené komunikace (WinRM/WS-Management) a JEA navíc přidává systém omezených koncových bodů, virtuálních účtů a podrobné kontroly nad tím, které příkazy jsou k dispozici.

Dalším důležitým konceptem je omezená správa, podobně jako a přiřazený přístup v režimu kiosku ve Windows 11Místo poskytnutí plného shellu operátorovi JEA vytvoří relaci, kde je skriptovací jazyk omezen (ve výchozím nastavení NoLanguage), vytváření nových funkcí nebo proměnných je blokováno, smyčky a podmíněné výrazy jsou zakázány a povoleno je spouštění pouze schválené sady cmdletů. To výrazně omezuje možnosti útočníka, kterému se podaří získat přístup k dané relaci.

Klíčové komponenty: soubory .psrc a .pssc

Jádrem každého nasazení JEA jsou dva typy souborů: soubory s funkcemi rolí (.psrc) a konfigurační soubory relací (.pssc)Společně transformují univerzální shell na dokonale přizpůsobený koncový bod pro konkrétní uživatele.

V souboru s funkcemi role definujete přesně které příkazy jsou pro danou roli k dispoziciMezi nejdůležitější prvky patří:

• Viditelné rutinyseznam povolených cmdletů, dokonce i možnost omezení parametrů.
• Viditelné funkce: vlastní funkce, které jsou načteny v relaci.
• Viditelné externí příkazy: specifické externí spustitelné soubory, ke kterým je přistupováno.
• Viditelné poskytovatelePoskytovatelé PowerShellu (například FileSystem nebo Registry) viditelní v relaci.

Konfigurační soubory relace .pssc na druhou stranu Popisují koncový bod JEA jako takový a propojují ho s rolemi.Zde jsou deklarovány prvky, jako například následující:

• Definice rolímapování uživatelů nebo skupin zabezpečení na funkce rolí.
• Typ relace: kde 'RestrictedRemoteServer' je obvykle nastaveno pro zajištění relace.
• Adresář přepisů: složka, kde jsou uloženy přepisy jednotlivých relací.
• Spustit jako virtuální účetRunAsVirtualAccount a související možnosti, například zda je virtuální účet přidán do konkrétních skupin.

JEA se zhmotňuje ve formě Koncové body vzdálené komunikace PowerShellu registrované v systémuTyto koncové body se vytvářejí a povolují pomocí rutin, jako například Nový soubor konfigurace relace PSS, Konfigurace relace registru PSS nebo grafické nástroje jako JEA Helper Tool, které usnadňují generování souborů .pssc a .psrc bez větších problémů se syntaxí.

Životní cyklus relace JEA

Při nastavování kompletního prostředí JEA proces obvykle probíhá řadou logických kroků, které Transformují otevřený systém vzdálené komunikace na striktně řízený.Typická sekvence je:

Nejprve vytvoříte a bezpečnostní skupina nebo několik skupin které představují role, které chcete delegovat (například HelpdeskDNS, weboví operátoři, operátory SQL). Používání skupin není povinné, ale s růstem prostředí značně zjednodušuje administraci.

Pak se připraví jeden nebo více soubory s funkcemi rolí .psrc Tyto funkce uvádějí povolené akce: cmdlety, funkce, skripty, externí příkazy, aliasy, poskytovatele a další omezení (specifické parametry, povolené cesty atd.). Zde můžete například povolit všechny cmdlety začínající na Get-, omezit Restart-Service na službu Spooler a autorizovat pouze poskytovatele FileSystem.

Vygeneruje se následující konfigurační soubor relace .pssc pomocí New-PSSessionConfigurationFile. Definuje možnosti jako SessionType = RestrictedRemoteServer, cestu k TranscriptDirectory, zda se používají virtuální účty a blok RoleDefinitions, který propojuje skupiny s funkcemi rolí, například 'DOMAIN\HelpdeskDNS' = @{ RoleCapabilities = 'HelpdeskDNSRole' }.

S již připraveným souborem .pssc je koncový bod zaregistrován pomocí Register‑PSSessionConfiguration-Name Název JEASession-Cesta Cesta\Soubor.psscOd tohoto okamžiku, pokud jsou dostupné konfigurace uvedeny pomocí příkazu Get-PSSessionConfiguration, se nový bod připojení zobrazí jako připravený k přijímání připojení.

Uživatelé se k tomuto koncovému bodu připojují ze svých počítačů pomocí Enter‑PSSession -ComputerName Server -ConfigurationName Název JEASession nebo pomocí New-PSSession a poté Invoke-Command. Po vstupu relace automaticky aplikuje omezení definovaná v přidružené roli uživatele.

během relace Vzdálená komunikace PowerShellu používá WinRM se šifrovanými kanály.Integrované ověřování (obvykle Kerberos v doméně) a pravidla firewallu definovaná pro službu. Pokud je povolena funkce RunAsVirtualAccount, je na základě toho vytvořen dočasný virtuální účet, přidán do potřebných skupin a po ukončení relace odstraněn.

Nakonec, po ukončení zasedání JEA, Přepisy auditů a události jsou uloženy Tyto protokoly zanechávají jasnou stopu provedených příkazů, výsledků a uživatelského kontextu. Lze je poté odeslat do systému SIEM nebo v rámci něj korelovat pro účely upozornění a další analýzy.

Vzdálená komunikace PowerShellu, řízení přístupu a posílení zabezpečení

Vzdálená komunikace PowerShellu, podporovaná službou Vzdálená správa systému Windows (WinRM) Protokol WS-Management umožňuje centralizované spouštění příkazů a skriptů na vzdálených počítačích. Je to výkonný nástroj pro automatizaci, hromadnou správu serverů, ladění a vzdálenou podporu.

Výchozí, místní administrátoři a členové skupiny Remote Management Users Mohou používat standardní koncové body PowerShellu. V mnoha prostředích se tato funkce používá k tomu, aby uživatelé bez administrátorských práv mohli spouštět vzdálené úlohy, což samo o sobě není nebezpečné, ale pokud není správně kontrolováno, otevírá to značnou cestu ke zneužití.

Pro posílení bezpečnostní situace zahrnuje společná strategie Omezte vzdálený přístup k PowerShellu pouze na účty správce. Nebo ještě lépe, zkombinujte toto omezení s koncovými body JEA, které určitým uživatelům poskytují pouze nezbytně nezbytný přístup. Toho lze dosáhnout pomocí:

• Objekty GPO, které definují, které skupiny mohou používat WinRM, a výchozí koncové body.
• Pravidla firewallu, která povolují WinRM pouze z podsítí nebo počítačů pro správu.
• Odebrání skupiny uživatelů pro vzdálenou správu z ACL standardních koncových bodů.

Kromě toho si můžete zvolit Úplně zablokovat PowerShell pro uživatele bez oprávnění správce pomocí řešení, jako je AppLocker. Tímto způsobem zabráníte standardnímu uživateli ve spouštění škodlivých skriptů lokálně, ale zároveň povolíte privilegovaným účtům používat PowerShell pro úlohy správy a automatizace.

JEA versus jiné metody omezení PowerShellu

Existuje několik způsobů, jak omezit, co mohou uživatelé dělat se vzdálenou komunikací PowerShellu, a JEA se hodí jako tenčí a flexibilnější varianta v rámci rozsahu, který zahrnuje širší přístupy, jako například:

Na jedné straně, použití Objekt zásad skupiny pro řízení toho, kdo vstupuje do výchozích koncových bodů PowerShelluProstředí Microsoft PowerShell lze omezit pouze na administrátory, nebo dokonce odregistrovat pro všechny, čímž se vynutí použití konkrétních koncových bodů. To je užitečné pro omezení přístupu „hrubou silou“, ale neřeší to problém granularity: kdokoli získá přístup, může dělat prakticky cokoli.

Na druhou stranu existují nástroje pro správu aplikací, jako např. Zásady pro AppLocker nebo omezení softwaruTyto metody umožňují zakázat spuštění PowerShell.exe nebo pwsh.exe standardním uživatelům, a to buď pomocí cesty, vydavatele nebo hashe. Tento přístup je užitečný pro posílení pracovních stanic a zabránění jakémukoli uživateli ve spuštění PowerShellu, ale představuje omezení, pokud chcete, aby někdo prováděl omezené administrativní úlohy ze svého uživatelského účtu.

Další možností je Omezené koncové body bez dosažení plného JEAMůžete si vytvořit vlastní konfigurace relací, které omezují cmdlety, funkce a moduly, ale bez tolik se spoléhat na model role, virtuální účty nebo strukturovaný RBAC, který JEA poskytuje. Je to jakýsi střední postup vhodný pro jednoduché scénáře, ale méně škálovatelný ve velkých prostředích.

JEA v sobě spojuje to nejlepší z několika světů: přísné omezení příkazů, RBAC, kontrolované provádění zvýšených oprávnění a komplexní protokolováníDíky tomu je to doporučené řešení, když potřebujete povolit vzdálenou komunikaci PowerShellu pro uživatele bez administrátorských práv, ale bez poskytnutí kompletního prostředí pro správu.

Pokročilé funkce: spuštění pod jiným účtem a protokolování

Jednou z nejsilnějších schopností JEA je spouštět příkazy jako jiný, privilegovanější účet bez odhalení vašich přihlašovacích údajůTím se řeší typický problém „Dám ti heslo k této službě, abys mohl udělat X“, který se pak nikdy nezmění a nakonec představuje obrovské riziko.

Doménové scénáře se běžně používají Skupinové spravované servisní účty (gMSA) To umožňuje koncovým bodům JEA provádět akce pod centrálně spravovanou identitou služby, s automatickou rotací hesla a bez toho, aby jakýkoli operátor kdy znal tajné heslo. V jiných případech se používají dočasné virtuální účty lokální pro daný počítač, které se vytvářejí ad hoc při připojení uživatele a na konci relace se smažou.

Z auditního hlediska lze každou relaci JEA nakonfigurovat tak, aby generovat přepisy PowerShellu i záznamy v protokolu událostí s bohatým obsahemMezi obvykle shromažďované informace patří:

• Kompletní historie zadaných příkazů a parametrů.
• Vygenerovaný výstup a chybové zprávy.
• Časové razítko začátku a konce relace a také její trvání.
• Identita přihlášeného uživatele a přiřazená role/kapacita.

Pokud tyto stopy zkombinujete s funkcemi Protokolování modulu PowerShell a Scénář Blokování protokolování pomocí GPOA odesláním protokolů do SIEM získáte robustní přehled o tom, co se děje na vašich koncových bodech pro správu. To je zásadní jak pro dodržování předpisů (audity SOX, ISO 27001 atd.), tak pro detekci a reakci na incidenty.

Typické případy použití JEA v reálných prostředích

JEA září zejména tehdy, když potřebujete Delegování velmi specifických úkolů týmům, které by neměly být administrátořiMezi velmi časté příklady v praxi patří:

V oblasti technické podpory můžete poskytnout špičkovým technikům Přístup JEA pro restartování služeb, zobrazení protokolů událostí a kontrolu stavu procesů na serverech, ale bez možnosti instalovat software, upravovat kritické konfigurace nebo přistupovat k Active Directory. Typická role helpdesku může zahrnovat cmdlety jako Get-Service, Restart-Service pro konkrétní služby, Get-EventLog v režimu jen pro čtení a některé cmdlety pro diagnostiku sítě.

V provozních nebo vývojových týmech můžete konfigurovat role zaměřené na specifické úkoly, jako je správa IIS nebo údržba webových stránekNapříklad povolení přístupu k rutinám pro správu fondu aplikací, restartování webových stránek, dotazování protokolů z omezeného adresáře a správa certifikátů pro konkrétní služby, přičemž je vyloučena jakákoli možnost restartovat celý server nebo upravovat bezpečnostní zásady.

V hybridních a cloudových prostředích se JEA často používá pro omezit, co může každý tým dělat virtuální stroje, skladování nebo sítěMůžete zpřístupnit koncové body, které vám umožní spravovat pouze virtuální počítače daného oddělení, upravovat pravidla firewallu konkrétního segmentu nebo spravovat konkrétní sadu servisních účtů a udržovat přístup oddělený od zbytku infrastruktury.

Zároveň JEA velmi dobře zapadá do Strategie správy privilegovaného přístupu (PAM)kde jsou privilegované relace udělovány dočasně, zaznamenávány a přiřazovány osobním identitám, čímž se vyhýbá sdílení účtů a minimalizuje riziko spojené s každou privilegovanou akcí.