PowerShell sikker fjernstyring med Just-Enough-Administration (JEA)

Brugen af ​​PowerShell-fjernstyring er blevet næsten uundværlig i ethvert miljø Windows Moderne, men at give fjernadgang uden kontrol er som at lægge datacenternøglerne på bordet. Det er her, spillet kommer ind i billedet. Lige nok administration (JEA), et sikkerhedslag, der giver dig mulighed for at delegere opgaver uden at give afkald på administratorrettigheder til højre og venstre.

Med JEA kan du oprette et meget begrænset antal fjernadgangspunkter, hvor specifikke brugere kun kører kommandoer som du har godkendt, under konti med flere rettigheder, men uden at kende de rigtige legitimationsoplysninger eller være i stand til at afvige fra manuskriptetOg alt dette blev nedskrevet i transskriptioner og logs detaljerede, der derefter giver dig mulighed for at revidere, hvem der har gjort hvad, hvornår og hvorfra.

Hvad er Just-Enough-Administration (JEA), og hvorfor er det vigtigt?

Just-Enough-Administration er en PowerShell-baseret sikkerhedsteknologi som implementerer en delegeret administrationsmodel med færrest nødvendige rettigheder. I praksis giver JEA dig mulighed for at eksponere eksterne slutpunkter, hvor kun et lukket sæt af cmdlets, funktioner, scripts og eksterne kommandoer, som du har defineret, er tilgængelige.

Takket være denne tilgang kan du reducere antallet af konti med forhøjede rettigheder drastisk På dine servere kan du bruge virtuelle konti eller gruppeadministrerede servicekonti (gMSA'er), der udfører privilegerede handlinger på vegne af standardbrugere. Brugeren logger ind med sine normale legitimationsoplysninger og starter via JEA-sessionen kommandoer, der udføres bag kulisserne med højere rettigheder.

En anden central søjle i JEA er evnen til at at præcist definere, hvad hver rolle kan gøreRollefunktionsfiler definerer, hvilke cmdlets, brugerdefinerede funktioner, eksterne kommandoer eller PowerShell-udbydere der er synlige. Resten findes simpelthen ikke for brugeren: de kan ikke improvisere scripts, frit navigere i filsystemet eller få adgang til tjenester eller processer, du ikke har angivet.

Derudover kan alle JEA-sessioner konfigureres til at generere fulde udskrifter og revisionsbegivenhederRegistrering af kommandoer, parametre, output, fejl, brugeridentitet og udførelsestider hjælper ikke kun med at opfylde lovgivningsmæssige krav, men er også uvurderlig, når man undersøger en sikkerhedshændelse eller driftsfejl.

Risici ved privilegerede konti og hvordan JEA afbøder dem

Lokale, domæne- eller programadministratorkonti med forhøjede tilladelser antyder en af ​​de mest alvorlige risikofaktorer i enhver organisationHvis en angriber får fat i en af ​​disse legitimationsoplysninger, kan de bevæge sig sidelæns gennem netværket, eskalere privilegier og få adgang til kritiske data, nøgletjenester eller endda nedbryde hele systemer.

Det er ikke altid ligetil at fjerne privilegier. Et klassisk eksempel er en server, der er vært for både DNS og en Active Directory-domænecontrollerDNS-teamet har brug for lokale administratorrettigheder for at kunne fejlfinde problemer med DNS-tjenester, men at tilføje dem til gruppen Domæneadministratorer giver dem effektivt kontrol over hele skoven og adgang til enhver ressource på den pågældende maskine. Dette er et klassisk eksempel på at ofre sikkerhed for driftsmæssig bekvemmelighed.

JEA løser dette dilemma ved strengt at anvende princippet om mindste privilegierI stedet for at gøre DNS-administratorer til domæneadministratorer, kan du oprette et dedikeret DNS JEA-slutpunkt, der kun eksponerer de cmdlets, der er nødvendige for at rydde cachen, genstarte tjenesten, gennemgå logfiler eller lignende opgaver. Dette giver operatøren mulighed for at udføre sit arbejde uden at skulle undersøge Active Directory, navigere i filsystemet, køre tilfældige scripts eller udføre potentielt farlige værktøjer.

Når du konfigurerer JEA-sessioner til at bruge virtuelle konti med midlertidige tilladelserFlytningen er endnu mere interessant: brugeren opretter forbindelse med uprivilegerede legitimationsoplysninger og kan fra den session udføre opgaver, der normalt kræver administratorrettigheder. Dette gør det muligt at fjerne mange brugere fra lokale eller domæneadministratorgrupper, hvilket opretholder driften, samtidig med at angrebsfladen forstærkes betydeligt.

Sikkerhedskoncepter, der ligger til grund for JEA

JEA opstod ikke ud af ingenting: Den er baseret på flere veletablerede sikkerhedsprincipper og -modeller. hvilket giver det sammenhæng og robusthed. Det første er det førnævnte princip om mindste privilegier, som dikterer, at både brugere og processer kun skal have de tilladelser, der er nødvendige for deres funktioner.

Den anden vigtige søjle er modellen for Rollebaseret adgangskontrol (RBAC)JEA implementerer RBAC gennem rollefunktionsfiler, hvor du definerer, hvad en specifik rolle kan gøre i en fjernsession. For eksempel kan en helpdesk-rolle liste tjenester, se hændelser og genstarte en specifik tjeneste, mens en SQL Server-administrationsrolle kun kan udføre cmdlets relateret til... databaser og lidt mere.

La JEAs tekniske fundament er PowerShell og dens fjerninfrastrukturPowerShell leverer sproget, cmdlets og fjernkommunikationslaget (WinRM/WS-Management), og JEA tilføjer oveni et system med begrænsede slutpunkter, virtuelle konti og detaljeret kontrol over, hvilke kommandoer der er tilgængelige.

Et andet vigtigt koncept er begrænset administration, svarende til en Tildelt adgang i Windows 11 kiosktilstandI stedet for at give en operator en fuld shell, konstruerer JEA en session, hvor scriptsproget er begrænset (som standard NoLanguage), oprettelsen af ​​nye funktioner eller variabler er blokeret, loops og conditionals er forbudt, og kun det godkendte sæt af cmdlets må udføres. Dette begrænser i høj grad muligheden for en angriber, der formår at få adgang til den pågældende session.

Nøglekomponenter: .psrc- og .pssc-filer

Kernen i enhver JEA-implementering er to typer filer: rollefunktionsfiler (.psrc) og sessionskonfigurationsfiler (.pssc)Sammen forvandler de en generel shell til et perfekt skræddersyet endpoint til specifikke brugere.

I en rollefunktionsfil definerer du præcis hvilke kommandoer der er tilgængelige for rollenBlandt de vigtigste elementer er:

• SynligeCmdlets: liste over tilladte cmdlets, endda muligheden for at begrænse parametre.
• Synlige Funktioner: brugerdefinerede funktioner, der indlæses i sessionen.
• SynligeEksterneKommandoerspecifikke eksterne eksekverbare filer, der tilgås.
• Synlige udbyderePowerShell-udbydere (f.eks. FileSystem eller Registry) er synlige i sessionen.

.pssc-sessionskonfigurationsfilerne, derimod, De beskriver JEA-slutpunktet som sådan og forbinder det med rollerne.Elementer som følgende erklæres her:

• Rolledefinitioner: knytter brugere eller sikkerhedsgrupper til rollefunktioner.
• SessionType: hvor 'RestrictedRemoteServer' normalt er indstillet til at hærde sessionen.
• Transskriptionskatalog: mappe hvor transskriptionerne af hver session er gemt.
• Kør som virtuel konto og relaterede muligheder, såsom om den virtuelle konto føjes til bestemte grupper.

JEA materialiserer sig i form af PowerShell-fjernstyringsslutpunkter registreret i systemetDisse slutpunkter oprettes og aktiveres med cmdlets som f.eks. Ny PSSession-konfigurationsfil, Register-PSSessionConfiguration eller grafiske værktøjer som JEA Helper Tool, der gør det nemmere at generere .pssc- og .psrc-filer uden at kæmpe så meget med syntaksen.

JEA-sessionens livscyklus

Når man konfigurerer et komplet JEA-miljø, følger processen normalt en række logiske trin, der De omdanner et åbent fjernstyringssystem til et strengt styret et.Den typiske rækkefølge er:

Først opretter du en sikkerhedsgruppe eller flere grupper der repræsenterer de roller, du vil delegere (f.eks. HelpdeskDNS, weboperatorer, SQL-operatorer). Brug af grupper er ikke obligatorisk, men det gør administrationen meget enklere, efterhånden som miljøet vokser.

Derefter forberedes en eller flere rollefunktionsfiler .psrc Disse viser de tilladte handlinger: cmdlets, funktioner, scripts, eksterne kommandoer, aliasser, udbydere og yderligere begrænsninger (specifikke parametre, tilladte stier osv.). Her kan du f.eks. tillade alle cmdlets, der starter med Get-, begrænse Restart-Service til Spooler-tjenesten og kun godkende FileSystem-udbyderen.

Følgende genereres sessionskonfigurationsfil .pssc ved hjælp af New-PSSessionConfigurationFile. Den definerer indstillinger såsom SessionType = RestrictedRemoteServer, TranscriptDirectory-stien, om virtuelle konti bruges, og RoleDefinitions-blokken, der forbinder grupper med rollefunktioner, for eksempel 'DOMAIN\HelpdeskDNS' = @{ RoleCapabilities = 'HelpdeskDNSRole' }.

Når .pssc-filen allerede er forberedt, registreres slutpunktet ved hjælp af Register-PSSessionConfiguration -Navn JEASession-navn -Sti Sti\Fil.psscFra det øjeblik, hvis de tilgængelige konfigurationer er angivet med Get-PSSessionConfiguration, vil det nye forbindelsespunkt se ud til at være klar til at modtage forbindelser.

Brugere opretter forbindelse til dette slutpunkt fra deres computere med Enter-PSSession -ComputerName Server -ConfigurationName JEASession-navn eller med New-PSSession og derefter Invoke-Command. Ved start anvender sessionen automatisk de begrænsninger, der er defineret i brugerens tilknyttede rollefunktion.

Under sessionen, PowerShell-fjernstyring bruger WinRM med krypterede kanalerIntegreret godkendelse (typisk Kerberos i domænet) og de firewallregler, der er defineret for tjenesten. Hvis RunAsVirtualAccount er aktiveret, oprettes der en midlertidig virtuel konto, som føjes til de nødvendige grupper og slettes, når sessionen slutter.

Endelig, efter afslutningen af ​​JEA-sessionen, Revisionsudskrifterne og begivenhederne gemmes Disse logfiler efterlader et tydeligt spor af udførte kommandoer, resultater og brugerkontekst. De kan derefter sendes til eller korreleres i et SIEM-system med henblik på advarsler og yderligere analyse.

PowerShell-fjernstyring, adgangskontrol og hærdning

PowerShell Remoting, understøttet af tjenesten Windows Fjernadministration (WinRM) WS-Management-protokollen muliggør centraliseret udførelse af kommandoer og scripts på eksterne computere. Det er et effektivt værktøj til automatisering, masseserveradministration, fejlfinding og fjernsupport.

Standard, lokale administratorer og medlemmer af gruppen Brugere til fjernadministration De kan bruge standard PowerShell-slutpunkter. I mange miljøer er denne funktion blevet brugt til at give ikke-administratorbrugere mulighed for at køre fjernopgaver, hvilket ikke i sig selv er farligt, men hvis det ikke kontrolleres korrekt, åbner det en betydelig mulighed for misbrug.

For at styrke sikkerhedsstillingen involverer en fælles strategi Begræns fjernadgang til PowerShell kun til administratorkonti. Eller, endnu bedre, kombiner denne begrænsning med JEA-slutpunkter, der kun giver visse brugere den strengt nødvendige adgang. Dette kan opnås gennem:

• GPO'er, der definerer, hvilke grupper der kan bruge WinRM, og standardslutpunkterne.
• Firewallregler, der kun tillader WinRM fra undernet eller administrationscomputere.
• Fjernelse af gruppen Brugere for fjernadministration fra ACL'erne for standardslutpunkter.

Derudover kan du vælge at Bloker PowerShell fuldstændigt for ikke-administratorbrugere ved hjælp af løsninger som AppLocker. På denne måde forhindrer du en standardbruger i at køre ondsindede scripts lokalt, men tillader stadig privilegerede konti at bruge PowerShell til administrations- og automatiseringsopgaver.

JEA versus andre PowerShell-begrænsningsmetoder

Der er flere måder at begrænse, hvad brugerne kan gøre med PowerShell-fjernstyring, og JEA passer som en tyndere og mere fleksibel mulighed inden for et område, der omfatter bredere tilgange såsom:

På den ene side brugen af GPO til at kontrollere, hvem der indtaster standard PowerShell-slutpunkterMicrosoft PowerShell kan begrænses til administratorer eller endda afregistreres for alle, hvilket tvinger brugen af ​​specifikke slutpunkter. Dette er nyttigt til at begrænse adgang på en "brute force"-måde, men det løser ikke granularitetsproblemet: den, der får adgang, kan gøre stort set alt.

På den anden side findes der applikationsstyringsværktøjer som f.eks. AppLocker eller softwarebegrænsningspolitikkerDisse metoder giver dig mulighed for at nægte standardbrugere adgang til PowerShell.exe eller pwsh.exe, enten via sti, udgiver eller hash. Denne tilgang er nyttig til at hærde arbejdsstationer og forhindre brugere i at starte PowerShell, men den har begrænsninger, når du ønsker, at nogen skal udføre begrænsede administrative opgaver fra deres brugerkonto.

En anden mulighed er Begrænsede slutpunkter uden at nå fuld JEADu kan oprette brugerdefinerede sessionskonfigurationer, der begrænser cmdlets, funktioner og moduler, men uden at være så afhængig af den rollemodel, virtuelle konti eller strukturerede RBAC, som JEA leverer. Det er en slags mellemvej, der er egnet til simple scenarier, men mindre skalerbar i store miljøer.

JEA kombinerer det bedste fra flere verdener: streng kommandobegrænsning, RBAC, kontrolleret udførelse af forhøjede rettigheder og omfattende logføringDette gør den til den anbefalede løsning, når du har brug for at aktivere PowerShell-fjernstyring for ikke-administratorer, men uden at give dem et komplet administrationsmiljø.

Avancerede funktioner: Kør som en anden konto og log

En af JEAs mest kraftfulde funktioner er udfør kommandoer som en anden, mere privilegeret konto uden at afsløre dine legitimationsoplysningerDette løser det typiske problem med "Jeg giver dig adgangskoden til denne tjeneste, så du kan bruge X", som derefter aldrig ændres og ender med at være en enorm risiko.

Domænescenarier bruges almindeligvis Gruppeadministrerede servicekonti (gMSA) Dette gør det muligt for JEA-slutpunkter at udføre handlinger under en centralt administreret serviceidentitet med automatisk adgangskoderotation og uden at nogen operatør nogensinde kender hemmeligheden. I andre tilfælde bruges midlertidige virtuelle konti, der er lokale for maskinen, og som oprettes ad hoc, når en bruger opretter forbindelse, og slettes ved afslutningen af ​​sessionen.

Fra et revisionsperspektiv kan hver JEA-session konfigureres til at generere både PowerShell-transkripter og omfattende hændelseslogposterDe oplysninger, der typisk indsamles, omfatter:

• Komplet historik over indtastede kommandoer og parametre.
• Genereret output og fejlmeddelelser.
• Tidsstempel for sessionens start og slut, samt dens varighed.
• Identitet af den indloggede bruger og tildelt rolle/kapacitet.

Hvis du kombinerer disse spor med funktionaliteter fra PowerShell-modullogning og Script Bloklogning via GPOOg ved at sende loggene til en SIEM-enhed får du et robust overblik over, hvad der sker på dine administrationsslutpunkter. Dette er afgørende for både compliance (SOX-revisioner, ISO 27001 osv.) og hændelsesdetektion og -respons.

Typiske JEA-anvendelseseksempler i virkelige miljøer

JEA skinner, især når du har brug for det Delegering af meget specifikke opgaver til teams, der ikke burde være administratorerNogle meget almindelige eksempler i praksis er:

Inden for det tekniske supportområde kan du give teknikere på topniveau JEA-adgang til genstart af tjenester, visning af hændelseslogfiler og kontrol af processtatus på servere, men uden mulighed for at installere software, ændre kritiske konfigurationer eller få adgang til Active Directory. En typisk helpdesk-rolle kan omfatte cmdlets som Get-Service, Restart-Service for specifikke tjenester, Get-EventLog i skrivebeskyttet tilstand og nogle cmdlets til netværksdiagnostik.

I drifts- eller udviklingsteams kan du konfigurere roller fokuseret på specifikke opgaver såsom IIS-administration eller vedligeholdelse af webstederFor eksempel at give adgang til cmdlets til administration af programpuljer, genstart af websteder, forespørgsler om logfiler fra en begrænset mappe og certifikatadministration for specifikke tjenester, samtidig med at enhver mulighed for at genstarte hele serveren eller ændre sikkerhedspolitikker udelukkes.

I hybrid- og cloud-miljøer bruges JEA ofte til begrænse, hvad hvert hold kan gøre ved det virtuelle maskiner, opbevaring eller netværkDu kan eksponere slutpunkter, der giver dig mulighed for kun at administrere en afdelings VM'er, ændre firewallreglerne for et bestemt segment eller administrere et bestemt sæt servicekonti, så adgangen holdes adskilt fra resten af ​​infrastrukturen.

Samtidig passer JEA rigtig godt sammen med Strategier for privilegeret adgangsstyring (PAM)hvor privilegerede sessioner tildeles midlertidigt, logges og tilskrives personlige identiteter, undgår delte konti og minimerer risikoen forbundet med hver privilegeret handling.

relateret artikel:

Sådan begrænser du adgangen til delte mapper i Windows trin for trin

Isaac

Passioneret forfatter om bytes-verdenen og teknologien generelt. Jeg elsker at dele min viden gennem skrivning, og det er det, jeg vil gøre i denne blog, vise dig alle de mest interessante ting om gadgets, software, hardware, teknologiske trends og mere. Mit mål er at hjælpe dig med at navigere i den digitale verden på en enkel og underholdende måde.