Aspekty zabezpečení JEA

FUNKCE JEA pomáhá zlepšit stav zabezpečení snížením počtu trvalých správců na vašich počítačích. FUNKCE JEA používá konfiguraci relace PowerShellu k vytvoření nového vstupního bodu pro uživatele pro správu systému. Uživatelům, kteří potřebují zvýšenou úroveň, ale ne neomezený přístup k počítači, aby mohli provádět úlohy správy, je možné udělit přístup ke koncovému bodu JEA. Vzhledem k tomu, že JEA umožňuje těmto uživatelům spouštět příkazy pro správu, aniž by měli úplný přístup správce, můžete tyto uživatele odebrat ze skupin zabezpečení s vysokou úrovní oprávnění.

Účet Spustit jako

Každý koncový bod JEA má určený účet spustit jako , pod kterým se provádějí akce připojujícího uživatele. Tento účet je konfigurovatelný v konfiguračním souboru relace a zvolený účet má významný vliv na zabezpečení koncového bodu.

Virtuální účty představují doporučený způsob konfigurace účtu spustit jako . Virtuální účty jsou jednorázové dočasné místní účty, které se vytvoří pro připojení uživatele, který se bude používat během doby trvání relace JEA. Jakmile dojde k ukončení relace, virtuální účet se zničí a už se nedá použít. Uživatel, který se připojuje, nezná přihlašovací údaje pro virtuální účet. Virtuální účet se nedá použít pro přístup k systému prostřednictvím jiných prostředků, jako je Vzdálená plocha nebo nevyučovaný koncový bod PowerShellu.

Ve výchozím nastavení jsou virtuální účty členy místní skupiny Správa istrators na počítači. Toto členství jim dává úplná práva ke správě čehokoli v systému, ale žádná práva ke správě prostředků v síti. Když se uživatel připojí k jiným počítačům z relace JEA, kontext uživatele je účet místního počítače, nikoli virtuální účet.

Řadiče domény jsou zvláštní případ, protože neexistuje místní skupina Správa istrators. Místo toho virtuální účty patří do doménových Správa a můžou spravovat adresářové služby na řadiči domény. Identita domény je stále omezena pro použití na řadiči domény, kde byla vytvořena instance relace JEA. Zdá se, že veškerý síťový přístup pochází z objektu počítače řadiče domény.

V oboupřípadechch Pokud už máte pro správce definovanou skupinu zabezpečení, udělte této skupině členství virtuálního účtu. Členství ve skupinách virtuálních účtů je omezené na místní skupiny zabezpečení na pracovních stanicích a členských serverech. Na řadičích domény musí být virtuální účty členy skupin zabezpečení domény. Po přidání virtuálního účtu do jedné nebo více skupin zabezpečení už nepatří do výchozích skupin (místních nebo doménových správců).

Následující tabulka shrnuje možné možnosti konfigurace a výsledná oprávnění pro virtuální účty:

Typ počítače	Konfigurace skupiny virtuálních účtů	Kontext místního uživatele	Kontext uživatele sítě
Řadič domény	Výchozí	Uživatel domény, člen <DOMAIN>\Domain Admins	Účet počítače
Řadič domény	Doménové skupiny A a B	Uživatel domény, člen <DOMAIN>\A, <DOMAIN>\B	Účet počítače
Členský server nebo pracovní stanice	Výchozí	Místní uživatel, člen BUILTIN\Administrators	Účet počítače
Členský server nebo pracovní stanice	Místní skupiny C a D	Místní uživatel, člen <COMPUTER>\C a <COMPUTER>\D	Účet počítače

Když se podíváte na protokoly auditu zabezpečení a událostí aplikace, uvidíte, že každá uživatelská relace JEA má jedinečný virtuální účet. Tento jedinečný účet vám pomůže sledovat akce uživatelů v koncovém bodu JEA zpět původnímu uživateli, který příkaz spustil. Názvy virtuálních účtů se řídí formátem WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> , například pokud uživatel Alice v doméně Contoso restartuje službu v koncovém bodu JEA, uživatelské jméno přidružené k událostem správce řízení služeb by mělo být WinRM Virtual Users\WinRM_VA_1_contoso_alice.

Účty služeb spravované skupinami (gMSA) jsou užitečné, když členský server potřebuje mít přístup k síťovým prostředkům v relaci JEA. Například když se koncový bod JEA používá k řízení přístupu ke službě REST API hostované na jiném počítači. Funkce, které volat rozhraní REST API, je snadné napsat, ale potřebujete síťovou identitu pro ověření pomocí rozhraní API. Použití účtu služby spravované skupiny umožňuje druhý segment směrování při zachování kontroly nad tím, které počítače můžou účet používat. Členství ve skupině zabezpečení (místní nebo doméně) gMSA definovalo platná oprávnění pro účet gMSA.

Když je koncový bod JEA nakonfigurovaný tak, aby používal gMSA, zdá se, že akce všech uživatelů JEA pocházejí ze stejného gMSA. Jediným způsobem, jak trasovat akce zpět konkrétnímu uživateli, je identifikovat sadu příkazů spuštěných v přepisu relace PowerShellu.

Předávací přihlašovací údaje se používají, když nezadáte účet spustit jako . PowerShell používá přihlašovací údaje připojujícího uživatele ke spouštění příkazů na vzdáleném serveru. Pokud chcete používat předávací přihlašovací údaje, musíte udělit přístup uživatelů k privilegovaným skupinám pro správu. Tato konfigurace se nedoporučuje pro JEA. Pokud už uživatel, který se připojuje, má oprávnění správce, může obejít JEA a spravovat systém pomocí jiných metod přístupu.

Účty Spustit jako úrovně Standard umožňují zadat libovolný uživatelský účet, pod kterým běží celá relace PowerShellu. Konfigurace relací používající pevné účty Spustit jako (s parametrem -RunAsCredential ) nejsou s podporou JEA. Definice rolí už nefungují podle očekávání. Každému uživateli autorizovanému pro přístup ke koncovému bodu je přiřazena stejná role.

U koncového bodu JEA byste neměli používat RunAsCredential , protože je obtížné trasovat akce zpět konkrétním uživatelům a nemá podporu pro mapování uživatelů na role.

Seznam ACL koncového bodu WinRM

Stejně jako u běžných koncových bodů vzdálené komunikace PowerShellu má každý koncový bod JEA samostatný seznam řízení přístupu (ACL), který určuje, kdo se může ověřit pomocí koncového bodu JEA. Pokud jsou nesprávně nakonfigurovaní, nemusí mít důvěryhodní uživatelé přístup ke koncovému bodu JEA a nedůvěryhodní uživatelé můžou mít přístup. Seznam ACL WinRM nemá vliv na mapování uživatelů na role JEA. Mapování se řídí polem RoleDefinitions v konfiguračním souboru relace použitém k registraci koncového bodu.

Pokud má koncový bod JEA ve výchozím nastavení více funkcí role, je seznam ACL WinRM nakonfigurovaný tak, aby umožňoval přístup všem mapovaným uživatelům. Například relace JEA nakonfigurovaná pomocí následujících příkazů uděluje úplný přístup k CONTOSO\JEA_Lev1 a CONTOSO\JEA_Lev2.

$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

Pomocí rutiny Get-PSSessionConfiguration můžete auditovat uživatelská oprávnění.

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

Pokud chcete změnit, kteří uživatelé mají přístup, spusťte buď Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI interaktivní výzvu, nebo Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> aktualizujte oprávnění. Uživatelé potřebují alespoň vyvolat práva pro přístup ke koncovému bodu JEA.

Je možné vytvořit koncový bod JEA, který nemapuje definovanou roli na každého uživatele, který má přístup. Tito uživatelé můžou spustit relaci JEA, ale mají přístup jenom k výchozím rutinám. Můžete auditovat uživatelská oprávnění v koncovém bodu JEA spuštěním Get-PSSessionCapabilitypříkazu . Další informace najdete v tématu Auditování a vytváření sestav v systému JEA.

Role s nejnižšími oprávněními

Při navrhování rolí JEA je důležité si uvědomit, že účty virtuálních a skupinově spravovaných služeb spuštěné na pozadí můžou mít neomezený přístup k místnímu počítači. Funkce rolí JEA pomáhají omezit příkazy a aplikace, které je možné spouštět v daném privilegovaném kontextu. Nesprávně navržené role můžou umožnit nebezpečným příkazům, které můžou uživateli umožnit přerušení hranic JEA nebo získání přístupu k citlivým informacím.

Představte si například následující položku schopností role:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

Tato funkce role umožňuje uživatelům spouštět jakoukoli rutinu PowerShellu s podstatným procesem z modulu Microsoft.PowerShell.Management. Uživatelé můžou potřebovat přístup k rutinám, jako Get-Process je vidět, jaké aplikace běží v systému, a Stop-Process zabíjet aplikace, které nereagují. Tato položka však také umožňuje Start-Process, který lze použít ke spuštění libovolného programu s úplnými oprávněními správce. Program nemusí být v systému nainstalovaný místně. Připojený uživatel může spustit program ze sdílené složky, která uživateli udělí oprávnění místního správce, spustí malware a další.

Bezpečnější verze této stejné funkce role by vypadala takto:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

Vyhněte se použití zástupných znaků v možnostech rolí. Nezapomeňte pravidelně auditovat efektivní uživatelská oprávnění, abyste zjistili, které příkazy jsou uživateli přístupné. Další informace najdete v části Kontrola platných práv auditování a vytváření sestav v článku JEA.

Doporučení osvědčených postupů

V následujících doporučených postupech se doporučuje zajistit zabezpečení koncových bodů JEA:

Omezení použití a možností zprostředkovatelů PowerShellu

Zkontrolujte, jak se povolené poskytovatele používají k zajištění, že v nakonfigurované relaci nevytáčíte ohrožení zabezpečení.

Upozorňující

Nepovolujte zprostředkovatele FileSystem . Pokud uživatelé můžou zapisovat do jakékoli části systému souborů, je možné zcela obejít zabezpečení.

Nepovolujte zprostředkovatele certifikátu . Když je poskytovatel povolený, může uživatel získat přístup k uloženým privátním klíčům.

Nepovolujte příkazy, které můžou vytvářet nové prostředí Runspace.

Upozorňující

Rutiny *-Job můžou vytvářet nové prostředí Runspace bez omezení.

Nepovolujte rutinu Trace-Command .

Upozorňující

Použití Trace-Command přináší do relace všechny trasované příkazy.

Nevytvávejte vlastní implementace proxy pro omezené příkazy.

PowerShell obsahuje sadu příkazů proxy pro scénáře s omezenými příkazy. Tyto proxy příkazy zajišťují, aby vstupní parametry nemohly ohrozit zabezpečení relace. Následující příkazy mají omezené proxy servery:

• Exit-PSSession
• Get-Command
• Get-FormatData
• Get-Help
• Measure-Object
• Out-Default
• Select-Object

Pokud vytvoříte vlastní implementaci těchto příkazů, můžete neúmyslně umožnit uživatelům spouštět kód zakázaný příkazy proxy serveru JEA.

JEA nechrání před správci

Jedním ze základních principů JEA je, že umožňuje nesprávcům provádět některé úlohy správy. JEA nechrání před uživateli, kteří už mají oprávnění správce. Uživatelé, kteří patří domain Správa s, místní Správa istrátory nebo jiné vysoce privilegované skupiny, můžou obejít ochranu JEA jinými způsoby. Můžou se například přihlásit pomocí protokolu RDP, používat vzdálené konzoly MMC nebo se připojit k nekontrénovaným koncovým bodům PowerShellu. Místní správce v systému může také upravit konfigurace JEA a přidat další uživatele nebo změnit schopnost role rozšířit rozsah toho, co může uživatel dělat v relaci JEA. Je důležité vyhodnotit rozšířená oprávnění uživatelů JEA, abyste zjistili, jestli existují další způsoby získání privilegovaného přístupu k systému.

Kromě použití JEA pro pravidelnou každodenní údržbu je běžné mít systém pro správu privilegovaných přístupů za běhu. Tyto systémy umožňují určeným uživatelům dočasně stát se místním správcem až po dokončení pracovního postupu, který dokumentuje jejich použití těchto oprávnění.