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

Brugen af ​​PowerShell-fjernstyring er blevet næsten uundværlig i ethvert moderne Windows- miljø, men at give fjernadgang uden kontrol er som at lægge datacenternøglerne på bordet. Det er her , Just-Enough-Administration (JEA) kommer ind i billedet , et sikkerhedslag, der giver dig mulighed for at delegere opgaver uden vilkårligt at uddelegere administratorrettigheder.

Med JEA kan du oprette meget begrænsede fjernadgangspunkter, hvor specifikke brugere kun udfører de kommandoer , du har godkendt, ved hjælp af konti med højere rettigheder, men uden at kende de faktiske legitimationsoplysninger eller være i stand til at afvige fra scriptet . Alt dette registreres i detaljerede transskriptioner og logfiler , så du kan kontrollere, hvem der gjorde hvad, hvornår og hvorfra.

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

Just-Enough Administration (JEA) er en PowerShell-baseret sikkerhedsteknologi , der 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 drastisk reducere antallet af konti med forhøjede rettigheder på dine servere ved at 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 udsteder via JEA-sessionen kommandoer, der udføres med højere rettigheder bag kulisserne.

En anden central søjle i JEA er muligheden for præcist at begrænse, hvad hver rolle kan gøre . Ved hjælp af rollefunktionsfiler definerer du, 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 transkripter og revisionshændelser , der registrerer kommandoer, parametre, output, fejl, brugeridentitet og udførelsestider. Dette hjælper ikke kun med at opfylde lovgivningsmæssige krav, men er også uvurderligt, 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 rettigheder repræsenterer en af ​​de mest alvorlige risikovektorer i enhver organisation . Hvis en angriber får adgang til en af ​​disse legitimationsoplysninger, kan de bevæge sig lateralt gennem netværket, eskalere rettigheder og få adgang til kritiske data, nøgletjenester eller endda ødelægge hele systemer.

Det er ikke altid ligetil at fjerne rettigheder. Et klassisk eksempel er en server, der er vært for både DNS og en Active Directory-domænecontroller . DNS-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 en typisk situation, hvor driftsmæssig bekvemmelighed ofres til fordel for sikkerhed.

JEA løser dette dilemma ved strengt at anvende princippet om mindste rettigheder . I stedet for at gøre DNS-administratorer til domæneadministratorer, kan du oprette et dedikeret JEA-slutpunkt til DNS, 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 kunne 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 tilladelser , bliver situationen endnu mere interessant: brugeren opretter forbindelse med legitimationsoplysninger uden privilegier, og alligevel kan brugeren fra den session udføre opgaver, der normalt kræver administratorrettigheder. Dette giver dig mulighed for at fjerne mange brugere fra lokale eller domæneadministratorgrupper, samtidig med at du opretholder driften, samtidig med at angrebsfladen forstærkes betydeligt.

Sikkerhedskoncepter, der ligger til grund for JEA

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

Den anden store søjle er den rollebaserede adgangskontrol (RBAC) -model . JEA implementerer RBAC gennem rollefunktionsfiler, hvor du definerer, hvad en specifik rolle kan gøre i en fjernsession. For eksempel kan en helpdesk-rolle muligvis liste tjenester, se hændelser og genstarte en specifik tjeneste, mens en SQL Server-administrationsrolle muligvis kun kan udføre databaserelaterede cmdlets og ikke meget andet.

Det tekniske fundament for JEA er PowerShell og dens fjerninfrastruktur . PowerShell leverer sproget, cmdlets og fjernkommunikationslaget (WinRM/WS-Management), og JEA tilføjer oveni et system af 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 tildelt adgang i Windows 11 i kiosktilstand . I 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, løkker og betingede indstillinger er forbudt, og kun det godkendte sæt cmdlets har tilladelse til at udføres. Dette begrænser alvorligt 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 omdanner de en generel shell til et perfekt defineret slutpunkt for specifikke brugere.

I en rollefunktionsfil definerer du præcis, hvilke kommandoer der er tilgængelige for rollen . Nøgleelementer omfatter:

• 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 beskriver derimod JEA-slutpunktet og forbinder det med roller . 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 implementeres i form af PowerShell-fjernstyrede slutpunkter, der er registreret på systemet . Disse slutpunkter oprettes og aktiveres ved hjælp af cmdlets som New-PSSessionConfigurationFile , Register-PSSessionConfiguration eller grafiske værktøjer som JEA Helper Tool, hvilket forenkler genereringen af ​​.pssc- og .psrc-filer uden besværet med kompleks syntaks.

JEA-sessionens livscyklus

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

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

Dernæst oprettes en eller flere rollefunktionsfiler (.psrc) , der viser de tilladte handlinger: cmdlets, funktioner, scripts, eksterne kommandoer, aliasser, udbydere og yderligere begrænsninger (specifikke parametre, tilladte stier osv.). For eksempel kan du tillade alle cmdlets startende med Get-, begrænse Restart-Service til Spooler-tjenesten og kun godkende FileSystem-udbyderen.

Dernæst genereres en .pssc-sessionskonfigurationsfil ved hjælp af New-PSSessionConfigurationFile. Denne fil 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 er forberedt, registreres slutpunktet ved hjælp af Register-PSSessionConfiguration -Name NombreJEASession -Path Ruta\Archivo.pssc . Fra det øjeblik, hvis de tilgængelige konfigurationer er angivet med Get-PSSessionConfiguration, vil det nye slutpunkt 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 JEASessionName eller med New-PSSession og derefter Invoke-Command. Ved login anvender sessionen automatisk de begrænsninger, der er defineret i brugerens rollefunktion.

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

Når JEA-sessionen afsluttes, gemmes de tilsvarende revisionsudskrifter og hændelser , hvilket efterlader et tydeligt spor af udførte kommandoer, resultater og brugerkontekst. Disse logfiler kan sendes til eller korreleres med en SIEM for advarsler og yderligere analyse.

PowerShell-fjernstyring, adgangskontrol og hærdning

PowerShell Remoting, understøttet af Windows Remote Management (WinRM) -tjenesten og WS-Management-protokollen, giver dig mulighed for centralt at udføre kommandoer og scripts på fjerncomputere. Det er et effektivt værktøj til automatisering, serveradministration i stor skala, fejlfinding og fjernsupport.

Som standard kan lokale administratorer og medlemmer af gruppen Fjernadministrationsbrugere 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 er i sig selv farligt, men hvis det ikke kontrolleres korrekt, åbner det en betydelig mulighed for misbrug.

For at styrke sikkerhedsstillingen er en almindelig strategi at begrænse PowerShell-fjernadgang til kun administratorkonti , eller endnu bedre, kombinere 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 blokere PowerShell helt for ikke-administratorbrugere ved hjælp af løsninger som AppLocker. Dette forhindrer standardbrugere i at køre skadelige scripts lokalt, samtidig med at privilegerede konti stadig kan bruge PowerShell til administrations- og automatiseringsopgaver.

JEA versus andre PowerShell-begrænsningsmetoder

Der er flere måder at indsnævre, hvad brugerne kan gøre med PowerShell-fjernstyring, og JEA passer ind som en finere og mere fleksibel mulighed inden for et interval, der inkluderer grovere tilgange såsom:

På den ene side er der brugen af ​​Group Policy Objects (GPO'er) til at kontrollere, hvem der får adgang til standard PowerShell-slutpunkterne . Du kan begrænse Microsoft.PowerShell til administratorer eller endda afregistrere det for alle og tvinge brugen af ​​specifikke slutpunkter. Dette er nyttigt til at begrænse adgangen "i stor skala", men det løser ikke granularitetsproblemet: den, der får adgang, kan gøre praktisk talt alt.

På den anden side findes der programstyringsværktøjer som AppLocker eller Software Restriction Policies , der giver dig mulighed for at nægte kørsel af PowerShell.exe eller pwsh.exe til standardbrugere, enten efter 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, hvilket ikke er nok til en fuld JEA-implementering . Du 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øring . Dette gør det til den anbefalede løsning, når du har brug for at aktivere PowerShell-fjernstyring for ikke-administratorer uden at give dem et fuldt administrativt miljø.

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

En af JEAs mest kraftfulde funktioner er muligheden for at udføre kommandoer som en mere privilegeret konto uden at afsløre sine egne legitimationsoplysninger . Dette løser det almindelige problem med "Jeg giver dig adgangskoden til denne tjeneste, så du kan udføre X", som derefter aldrig ændres og ender med at være en enorm risiko.

I domænebaserede miljøer bruges Group Managed Service Accounts (gMSA) almindeligvis til at give JEA-slutpunkter mulighed for at udføre handlinger under en centralt administreret serviceidentitet med automatisk adgangskoderotation og uden at nogen operatør nogensinde kender adgangskoden. I andre tilfælde bruges midlertidige virtuelle konti, der er lokale for maskinen, 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ændelseslogposter . De typisk indsamlede oplysninger 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.

Ved at kombinere disse spor med PowerShell Module Logging og Script Block Logging-funktioner via GPO , og ved også at sende logfilerne til en SIEM, får du robust indsigt i, 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 er især fremragende, når man skal delegere meget specifikke opgaver til teams, der ikke burde være administratorer . Nogle meget almindelige eksempler i praksis er:

I området for teknisk support kan du give teknikere på første niveau JEA-adgang til at genstarte tjenester, se hændelseslogfiler og kontrollere status for processer 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 på specifikke tjenester, Get-EventLog i skrivebeskyttet tilstand og nogle cmdlets til netværksdiagnostik.

I drifts- eller udviklingsteams kan du konfigurere roller, der er rettet mod specifikke opgaver såsom IIS-administration eller vedligeholdelse af websteder . For eksempel kan du tillade adgang til cmdlets til administration af programpuljer, genstart af websteder, logforespørgsler for en bestemt mappe og certifikatadministration for bestemte tjenester, samtidig med at du udelukker enhver mulighed for at genstarte hele serveren eller ændre sikkerhedspolitikker.

I hybrid- og cloud-miljøer bruges JEA ofte til at begrænse, hvad hvert team kan gøre på virtuelle maskiner , lagring eller netværk . Du kan eksponere endpoints, der giver dig mulighed for kun at administrere VM'erne i en bestemt afdeling, ændre firewallreglerne for et bestemt segment eller administrere et specifikt sæt servicekonti, så adgangen holdes adskilt fra resten af ​​infrastrukturen.

Samtidig passer JEA rigtig godt sammen med Privileged Access Management (PAM) strategier , hvor privilegerede sessioner tildeles midlertidigt, logges og tilskrives personlige identiteter, hvilket 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.