PowerShell säker fjärrstyrning med Just-Enough-Administration (JEA)

Användningen av PowerShell-fjärrstyrning har blivit nästan oumbärlig i alla miljöer Windows Modernt, men att bevilja fjärråtkomst utan kontroll är som att lämna datacentrets nycklar på bordet. Det är här spelet kommer in i bilden. Precis tillräckligt administration (JEA), ett säkerhetslager som låter dig delegera uppgifter utan att ge bort administratörsrättigheter åt höger och vänster.

Med JEA kan du konfigurera ett mycket begränsat antal fjärråtkomstpunkter där specifika användare bara kör kommandon som du har auktoriserat, under konton med fler behörigheter, men utan att känna till de verkliga meriterna eller kunna avvika från manusetOch allt detta dokumenterades i transkriptioner och loggar detaljerade som sedan låter dig granska vem som har gjort vad, när och varifrån.

Vad är Just-Enough-Administration (JEA) och varför är det viktigt?

Just-Enough-Administration är en PowerShell-baserad säkerhetsteknik vilket implementerar en delegerad administrationsmodell med minsta möjliga behörighet. I praktiken låter JEA dig exponera fjärrslutpunkter där endast en sluten uppsättning cmdlets, funktioner, skript och externa kommandon som du definierar är tillgängliga.

Tack vare detta tillvägagångssätt kan du drastiskt minska antalet konton med utökade rättigheter På dina servrar kan du använda virtuella konton eller grupphanterade tjänstkonton (gMSAs) som utför privilegierade åtgärder åt standardanvändare. Användaren loggar in med sina vanliga inloggningsuppgifter och kör, via JEA-sessionen, kommandon som körs bakom kulisserna med högre behörigheter.

En annan viktig pelare i JEA är förmågan att att exakt definiera vad varje roll kan göraRollfunktionsfiler definierar vilka cmdlets, anpassade funktioner, externa kommandon eller PowerShell-providers som är synliga. Resten finns helt enkelt inte för användaren: de kan inte improvisera skript, navigera fritt i filsystemet eller komma åt tjänster eller processer som du inte har angett.

Dessutom kan alla JEA-sessioner konfigureras för att generera fullständiga transkript och revisionshändelserAtt registrera kommandon, parametrar, utdata, fel, användaridentitet och exekveringstider hjälper inte bara till att uppfylla myndighetskrav utan är också ovärderligt vid utredning av säkerhetsincidenter eller driftsfel.

Risker med privilegierade konton och hur JEA minskar dem

Lokala, domän- eller programadministratörskonton med utökade behörigheter innebär en av de allvarligaste riskvektorerna i alla organisationerOm en angripare får tag på en av dessa inloggningsuppgifter kan de röra sig i nätverket, eskalera behörigheter och få åtkomst till kritisk data, viktiga tjänster eller till och med stänga av hela system.

Att ta bort privilegier är inte alltid trivialt. Ett klassiskt exempel är att en server som är värd för både DNS och en Active Directory-domänkontrollantDNS-teamet behöver lokala administratörsbehörigheter för att felsöka problem med DNS-tjänster, men att lägga till dem i gruppen Domänadministratörer ger dem effektivt kontroll över hela skogen och åtkomst till alla resurser på den maskinen. Detta är ett klassiskt exempel på att offra säkerhet för driftsbekvämlighet.

JEA löser detta dilemma genom att strikt tillämpa principen om minsta privilegiumIstället för att göra DNS-administratörer till domänadministratörer kan du skapa en dedikerad DNS JEA-slutpunkt som bara exponerar de cmdlets som behövs för att rensa cachen, starta om tjänsten, granska loggar eller liknande uppgifter. Detta gör att operatören kan utföra sitt jobb utan att behöva undersöka Active Directory, navigera i filsystemet, köra slumpmässiga skript eller köra potentiellt farliga verktyg.

När du konfigurerar JEA-sessioner att använda virtuella konton med tillfälliga behörigheterFlytten är ännu mer intressant: användaren ansluter med oprivilegierade inloggningsuppgifter och kan från den sessionen utföra uppgifter som normalt kräver administratörsrättigheter. Detta gör att många användare kan tas bort från lokala eller domänadministratörsgrupper, vilket upprätthåller driften samtidigt som attackytan avsevärt hårdgörs.

Säkerhetskoncept som ligger till grund för JEA

JEA uppstod inte från ingenting: Den är baserad på flera väletablerade säkerhetsprinciper och modeller. vilket ger den koherens och robusthet. Den första är den tidigare nämnda principen om minsta behörighet, som dikterar att både användare och processer endast ska ha de behörigheter som är nödvändiga för deras funktioner.

Den andra stora pelaren är modellen för Rollbaserad åtkomstkontroll (RBAC)JEA implementerar RBAC genom rollfunktionsfiler, där du definierar vad en specifik roll kan göra inom en fjärrsession. Till exempel kan en helpdesk-roll lista tjänster, visa händelser och starta om en specifik tjänst, medan en SQL Server-administrationsroll bara kan köra cmdlets relaterade till... databaser och lite mer.

La JEAs tekniska grund är PowerShell och dess fjärrstyrningsinfrastrukturPowerShell tillhandahåller språket, cmdlets och fjärrkommunikationslagret (WinRM/WS-Management), och JEA lägger till ett system med begränsade slutpunkter, virtuella konton och detaljerad kontroll över vilka kommandon som är tillgängliga.

Ett annat viktigt koncept är begränsad administration, liknar en Tilldelad åtkomst i Windows 11-kiosklägeIstället för att ge en operator ett fullständigt skal, konstruerar JEA en session där skriptspråket är begränsat (som standard NoLanguage), skapandet av nya funktioner eller variabler blockeras, loopar och villkor är förbjudna, och endast den godkända uppsättningen cmdlets tillåts köras. Detta begränsar kraftigt möjligheten för en angripare som lyckas få åtkomst till den sessionen.

Viktiga komponenter: .psrc- och .pssc-filer

Kärnan i varje JEA-distribution finns två typer av filer: rollfunktionsfiler (.psrc) och sessionskonfigurationsfiler (.pssc)Tillsammans omvandlar de ett generellt skal till en perfekt skräddarsydd slutpunkt för specifika användare.

I en rollfunktionsfil definierar du exakt vilka kommandon som är tillgängliga för rollenBland de viktigaste elementen är:

• SynligaCmdlets: lista över tillåtna cmdlets, även möjligheten att begränsa parametrar.
• SynligaFunktioner: anpassade funktioner som laddas i sessionen.
• Synliga externa kommandon: specifika externa körbara filer som nås.
• Synliga leverantörerPowerShell-leverantörer (till exempel FileSystem eller Registry) är synliga i sessionen.

Konfigurationsfilerna för .pssc-sessionen, å andra sidan, De beskriver JEA-slutpunkten som sådan och kopplar den till rollerna.Element som följande deklareras här:

• Rolldefinitionermappa användare eller säkerhetsgrupper till rollfunktioner.
• SessionType: där 'RestrictedRemoteServer' vanligtvis är inställt för att härda sessionen.
• Transkriptionskatalog: mapp där transkriptionerna från varje session lagras.
• Kör som virtuellt konto och relaterade alternativ, till exempel om det virtuella kontot läggs till i specifika grupper.

JEA materialiseras i form av PowerShell-fjärrstyrda slutpunkter registrerade i systemetDessa slutpunkter skapas och aktiveras med cmdlets som Ny PSSession-konfigurationsfil, Register-PSSessionConfiguration eller grafiska verktyg som JEA Helper Tool, vilket gör det enklare att generera .pssc- och .psrc-filer utan att kämpa så mycket med syntaxen.

JEA-sessionens livscykel

När man konfigurerar en komplett JEA-miljö följer processen vanligtvis en serie logiska steg som De omvandlar ett öppet fjärrstyrningssystem till ett strikt styrt.Den typiska sekvensen är:

Först skapar du en säkerhetsgrupp eller flera grupper som representerar de roller du vill delegera (till exempel HelpdeskDNS, webboperatorer, SQL-operatorer). Att använda grupper är inte obligatoriskt, men det förenklar administrationen mycket allt eftersom miljön växer.

Sedan förbereds en eller flera rollfunktionsfiler .psrc Dessa listar tillåtna åtgärder: cmdlets, funktioner, skript, externa kommandon, alias, providers och ytterligare begränsningar (specifika parametrar, tillåtna sökvägar etc.). Här kan du till exempel tillåta alla cmdlets som börjar med Get-, begränsa Restart-Service till Spooler-tjänsten och endast auktorisera FileSystem-providern.

Följande genereras sessionskonfigurationsfil .pssc med hjälp av New-PSSessionConfigurationFile. Den definierar alternativ som SessionType = RestrictedRemoteServer, TranscriptDirectory-sökvägen, om virtuella konton används och RoleDefinitions-blocket som länkar grupper till rollfunktioner, till exempel 'DOMAIN\HelpdeskDNS' = @{ RoleCapabilities = 'HelpdeskDNSRole' }.

Med .pssc-filen redan förberedd registreras slutpunkten med hjälp av Register-PSSessionConfiguration -Name JEASession Name -Path Path\File.psscFrån och med det ögonblicket, om de tillgängliga konfigurationerna listas med Get-PSSessionConfiguration, kommer den nya anslutningspunkten att visas redo att ta emot anslutningar.

Användare ansluter till den här slutpunkten från sina datorer med Enter-PSSession -DatornamnServer -KonfigurationsnamnJEASessionsnamn eller med New-PSSession och sedan Invoke-Command. Vid start tillämpar sessionen automatiskt de begränsningar som definierats i användarens associerade rollfunktion.

Under sessionen, PowerShell-fjärrstyrning använder WinRM med krypterade kanalerIntegrerad autentisering (vanligtvis Kerberos i domänen) och brandväggsregler som definierats för tjänsten. Om RunAsVirtualAccount är aktiverat skapas ett tillfälligt virtuellt konto, läggs till i nödvändiga grupper och förstörs när sessionen avslutas.

Slutligen, efter avslutandet av JEA-sessionen, Revisionsutskrifterna och händelserna sparas Dessa loggar lämnar ett tydligt spår av utförda kommandon, resultat och användarkontext. De kan sedan skickas till eller korreleras inom ett SIEM-system för varningar och vidare analys.

PowerShell-fjärrstyrning, åtkomstkontroll och härdning

PowerShell-fjärrstyrning, som stöds av tjänsten Windows-fjärrhantering (WinRM) WS-Management-protokollet möjliggör centraliserad exekvering av kommandon och skript på fjärrdatorer. Det är ett kraftfullt verktyg för automatisering, massserverhantering, felsökning och fjärrsupport.

Standard, lokala administratörer och medlemmar i gruppen Användare för fjärrhantering De kan använda vanliga PowerShell-slutpunkter. I många miljöer har den här funktionen använts för att tillåta icke-administratörer att köra fjärruppgifter, vilket inte är farligt i sig, men om det inte kontrolleras korrekt öppnar det upp en betydande väg för missbruk.

För att stärka säkerhetsställningen innefattar en gemensam strategi Begränsa fjärråtkomst till PowerShell endast till administratörskonton. Eller, ännu bättre, kombinera den begränsningen med JEA-slutpunkter som ger vissa användare endast den absolut nödvändiga åtkomst. Detta kan uppnås genom:

• GPO:er som definierar vilka grupper som kan använda WinRM och standardslutpunkterna.
• Brandväggsregler som endast tillåter WinRM från undernät eller hanteringsdatorer.
• Tar bort gruppen Användare för fjärrhantering från ACL:erna för standardslutpunkter.

Dessutom kan du välja att Blockera PowerShell helt för användare som inte är administratörer med hjälp av lösningar som AppLocker. På så sätt förhindrar du att en vanlig användare kör skadliga skript lokalt, men tillåter fortfarande privilegierade konton att använda PowerShell för hanterings- och automatiseringsuppgifter.

JEA kontra andra PowerShell-begränsningsmetoder

Det finns flera sätt att begränsa vad användare kan göra med PowerShell-fjärrstyrning, och JEA passar som ett tunnare och mer flexibelt alternativ inom ett spektrum som inkluderar bredare tillvägagångssätt såsom:

Å ena sidan, användningen av GPO för att kontrollera vem som anger standard PowerShell-slutpunkterMicrosoft PowerShell kan begränsas till administratörer, eller till och med avregistreras för alla, vilket tvingar fram användningen av specifika slutpunkter. Detta är användbart för att begränsa åtkomst på ett "brute force"-sätt, men det löser inte granularitetsproblemet: den som får åtkomst kan göra praktiskt taget vad som helst.

Å andra sidan finns det verktyg för applikationskontroll som t.ex. AppLocker eller programvarubegränsningspolicyerMed dessa metoder kan du neka körningen av PowerShell.exe eller pwsh.exe för vanliga användare, antingen via sökväg, utgivare eller hash. Den här metoden är användbar för att härda arbetsstationer och förhindra att användare startar PowerShell, men den har begränsningar när du vill att någon ska utföra begränsade administrativa uppgifter från sitt användarkonto.

Ett annat alternativ är Begränsade slutpunkter utan att uppnå fullständig JEADu kan skapa anpassade sessionskonfigurationer som begränsar cmdlets, funktioner och moduler, men utan att förlita dig lika mycket på den rollmodell, virtuella konton eller strukturerade RBAC som JEA tillhandahåller. Det är ett slags medelväg som är lämplig för enkla scenarier, men mindre skalbar i stora miljöer.

JEA kombinerar det bästa av flera världar: strikt kommandobegränsning, RBAC, kontrollerad körning av utökade privilegier och omfattande loggningDetta gör den till den rekommenderade lösningen när du behöver aktivera PowerShell-fjärrstyrning för icke-administratörer, men utan att ge dem en komplett hanteringsmiljö.

Avancerade funktioner: kör som ett annat konto och logga

En av JEA:s kraftfullaste funktioner är kör kommandon som ett annat, mer privilegierat konto utan att avslöja dina inloggningsuppgifterDetta löser det typiska problemet med "Jag ger dig lösenordet för den här tjänsten så att du kan göra X", vilket sedan aldrig ändras och i slutändan blir en stor risk.

Domänscenarier används ofta Grupphanterade tjänstkonton (gMSA) Detta gör det möjligt för JEA-slutpunkter att utföra åtgärder under en centralt hanterad tjänstidentitet, med automatisk lösenordsrotation och utan att någon operatör någonsin känner till hemligheten. I andra fall används tillfälliga virtuella konton som är lokala för maskinen, skapas ad hoc när en användare ansluter och raderas i slutet av sessionen.

Ur ett revisionsperspektiv kan varje JEA-session konfigureras för att generera både PowerShell-transkript och omfattande händelseloggposterDen information som vanligtvis samlas in inkluderar:

• Komplett historik över inmatade kommandon och parametrar.
• Genererad utdata och felmeddelanden.
• Tidsstämpel för sessionens början och slut, samt dess varaktighet.
• Identitet för den inloggade användaren och tilldelad roll/kapacitet.

Om du kombinerar dessa spår med funktioner för PowerShell-modulloggning och Script Blockloggning via GPOOch genom att skicka loggarna till ett SIEM-system får du gedigen insyn i vad som händer på dina hanteringsslutpunkter. Detta är avgörande för både efterlevnad (SOX-revisioner, ISO 27001, etc.) och incidentdetektering och -hantering.

Typiska JEA-användningsfall i verkliga miljöer

JEA lyser särskilt när du behöver Delegera mycket specifika uppgifter till team som inte borde vara administratörerNågra mycket vanliga exempel i praktiken är:

Inom det tekniska supportområdet kan du ge tekniker på toppnivå JEA-åtkomst för att starta om tjänster, visa händelseloggar och kontrollera processstatus på servrar, men utan möjlighet att installera programvara, ändra kritiska konfigurationer eller komma åt Active Directory. En typisk helpdesk-roll kan inkludera cmdlets som Get-Service, Restart-Service för specifika tjänster, Get-EventLog i skrivskyddat läge och vissa cmdlets för nätverksdiagnostik.

I drift- eller utvecklingsteam kan du konfigurera roller fokuserade på specifika uppgifter såsom IIS-administration eller webbplatsunderhållTill exempel att tillåta åtkomst till cmdlets för hantering av programpooler, omstart av webbplatser, fråga loggar från en begränsad katalog och certifikathantering för specifika tjänster, samtidigt som möjligheten att starta om hela servern eller ändra säkerhetspolicyer utesluts.

I hybrid- och molnmiljöer används JEA ofta för begränsa vad varje lag kan göra åt virtuella maskiner, lagring eller nätverkDu kan exponera slutpunkter som gör att du kan hantera endast en avdelnings virtuella maskiner, ändra brandväggsreglerna för ett specifikt segment eller hantera en specifik uppsättning tjänstkonton, och hålla åtkomsten separat från resten av infrastrukturen.

Samtidigt passar JEA mycket bra ihop med Strategier för Privileged Access Management (PAM)där privilegierade sessioner beviljas tillfälligt, loggas och tillskrivs personliga identiteter, vilket undviker delade konton och minimerar risken i samband med varje privilegierad åtgärd.

Relaterad artikel:

Hur man begränsar åtkomst till delade mappar i Windows steg för steg

Isaac

Passionerad författare om bytesvärlden och tekniken i allmänhet. Jag älskar att dela med mig av min kunskap genom att skriva, och det är vad jag kommer att göra i den här bloggen, visa dig alla de mest intressanta sakerna om prylar, mjukvara, hårdvara, tekniska trender och mer. Mitt mål är att hjälpa dig att navigera i den digitala världen på ett enkelt och underhållande sätt.