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

Bruk av PowerShell-fjernstyring har blitt nesten uunnværlig i ethvert miljø. Windows Moderne, men å gi fjerntilgang uten kontroll er som å legge datasenternøklene på bordet. Det er her spillet kommer inn i bildet. Akkurat nok administrasjon (JEA), et sikkerhetslag som lar deg delegere oppgaver uten å gi fra deg administratorrettigheter til venstre og høyre.

Med JEA kan du sette opp et svært begrenset antall eksterne tilgangspunkter der spesifikke brukere bare kjører kommandoer som du har autorisert, under kontoer med flere rettigheter, men uten å kjenne de virkelige legitimasjonene eller kunne avvike fra manusetOg alt dette ble registrert i transkripsjoner og logger detaljerte som deretter lar deg revidere hvem som har gjort hva, når og hvorfra.

Hva er Akkurat nok administrasjon (JEA), og hvorfor er det viktig?

Just-Enough-Administration er en PowerShell-basert sikkerhetsteknologi som implementerer en delegert administrasjonsmodell med færrest nødvendige rettigheter. I praksis lar JEA deg eksponere eksterne endepunkter der bare et lukket sett med cmdleter, funksjoner, skript og eksterne kommandoer definert av deg er tilgjengelige.

Takket være denne tilnærmingen kan du redusere antallet kontoer med utvidede rettigheter drastisk På serverne dine kan du bruke virtuelle kontoer eller gruppestyrte tjenestekontoer (gMSAs) som utfører privilegerte handlinger på vegne av standardbrukere. Brukeren logger seg på med sin vanlige legitimasjon og, gjennom JEA-økten, starter kommandoer som utføres bak kulissene med høyere rettigheter.

En annen viktig søyle i JEA er evnen til å å presist definere hva hver rolle kan gjøreRollefunksjonsfiler definerer hvilke cmdleter, tilpassede funksjoner, eksterne kommandoer eller PowerShell-leverandører som er synlige. Resten finnes rett og slett ikke for brukeren: de kan ikke improvisere skript, navigere fritt i filsystemet eller få tilgang til tjenester eller prosesser du ikke har spesifisert.

Videre kan alle JEA-sesjoner konfigureres til å generere fullstendige transkripsjoner og revisjonshendelserÅ registrere kommandoer, parametere, utdata, feil, brukeridentitet og utførelsestider bidrar ikke bare til å oppfylle regulatoriske krav, men er også uvurderlig når man undersøker en sikkerhetshendelse eller driftsfeil.

Risikoer knyttet til privilegerte kontoer og hvordan JEA reduserer dem

Lokale, domene- eller programadministratorkontoer med utvidede tillatelser innebærer en av de mest alvorlige risikovektorene i enhver organisasjonHvis en angriper får tak i en av disse påloggingsinformasjonene, kan de bevege seg sidelengs gjennom nettverket, eskalere rettigheter og få tilgang til kritiske data, viktige tjenester eller til og med ta ned hele systemer.

Det er ikke alltid like enkelt å fjerne privilegier. Et klassisk eksempel er en server som er vert for både DNS og en Active Directory-domenekontrollerDNS-teamet trenger lokale administratorrettigheter for å feilsøke problemer med DNS-tjenesten, men å legge dem til i gruppen Domeneadministratorer gir dem effektivt kontroll over hele skogen og tilgang til alle ressurser på den maskinen. Dette er et klassisk eksempel på å ofre sikkerhet for driftsmessig bekvemmelighet.

JEA løser dette dilemmaet ved å strengt anvende prinsippet om minste privilegiumI stedet for å gjøre DNS-administratorer til domeneadministratorer, kan du opprette et dedikert DNS JEA-endepunkt som bare eksponerer cmdletene som trengs for å tømme hurtigbufferen, starte tjenesten på nytt, gjennomgå logger eller lignende oppgaver. Dette lar operatøren utføre jobben sin uten å måtte undersøke Active Directory, navigere i filsystemet, kjøre tilfeldige skript eller kjøre potensielt farlige verktøy.

Når du konfigurerer JEA-økter til bruk virtuelle kontoer med midlertidige tillatelserFlyttingen er enda mer interessant: brukeren kobler seg til med uprivilegerte påloggingsinformasjoner, og fra den økten kan vedkommende utføre oppgaver som vanligvis krever administratorrettigheter. Dette gjør at mange brukere kan fjernes fra lokale eller domeneadministratorgrupper, noe som opprettholder driften samtidig som angrepsflaten blir betydelig herdet.

Sikkerhetskonsepter som ligger til grunn for JEA

JEA oppsto ikke fra ingenting: Den er basert på flere veletablerte sikkerhetsprinsipper og -modeller. som gir den sammenheng og robusthet. Det første er det nevnte prinsippet om minste privilegium, som dikterer at både brukere og prosesser bare skal ha de tillatelsene som er nødvendige for funksjonene deres.

Den andre hovedpilaren er modellen for Rollebasert tilgangskontroll (RBAC)JEA implementerer RBAC gjennom rollefunksjonsfiler, der du definerer hva en bestemt rolle kan gjøre i en ekstern økt. For eksempel kan en brukerstøtterolle liste opp tjenester, vise hendelser og starte en bestemt tjeneste på nytt, mens en SQL Server-administrasjonsrolle bare kan kjøre cmdleter relatert til... databaser og litt til.

La JEAs tekniske grunnlag er PowerShell og dens fjernstyringsinfrastrukturPowerShell sørger for språket, cmdlets og laget for ekstern kommunikasjon (WinRM/WS-Management), og JEA legger i tillegg til et system med begrensede endepunkter, virtuelle kontoer og detaljert kontroll over hvilke kommandoer som er tilgjengelige.

Et annet viktig konsept er begrenset administrasjon, ligner på en Tildelt tilgang i Windows 11-kioskmodusI stedet for å gi en operator et fullstendig skall, konstruerer JEA en sesjon der skriptspråket er begrenset (som standard NoLanguage), opprettelsen av nye funksjoner eller variabler er blokkert, løkker og betingelser er forbudt, og bare det godkjente settet med cmdleter tillates å kjøres. Dette begrenser i stor grad muligheten til en angriper som klarer å få tilgang til den sesjonen.

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

Kjernen i enhver JEA-distribusjon er to typer filer: rollefunksjonsfiler (.psrc) og sesjonskonfigurasjonsfiler (.pssc)Sammen forvandler de et universalskall til et perfekt skreddersydd endepunkt for spesifikke brukere.

I en rollefunksjonsfil definerer du nøyaktig hvilke kommandoer som er tilgjengelige for rollenBlant de viktigste elementene er:

• SynligeCmdlets: liste over tillatte cmdleter, til og med muligheten til å begrense parametere.
• Synlige funksjoner: tilpassede funksjoner som lastes inn i økten.
• Synlige eksterne kommandoer: spesifikke eksterne kjørbare filer som er tilgjengelige.
• Synlige leverandørerPowerShell-leverandører (for eksempel FileSystem eller Registry) er synlige i økten.

.pssc-øktkonfigurasjonsfilene, derimot, De beskriver JEA-endepunktet som sådan og knytter det til rollene.Elementer som følgende er deklarert her:

• Rolledefinisjonertilordne brukere eller sikkerhetsgrupper til rollefunksjoner.
• SessionType: der «RestrictedRemoteServer» vanligvis er satt til å herde økten.
• Transkripsjonskatalog: mappe der transkripsjonene av hver økt er lagret.
• Kjør som virtuell konto og relaterte alternativer, for eksempel om den virtuelle kontoen legges til i bestemte grupper.

JEA materialiserer seg i form av PowerShell-fjernstyrte endepunkter registrert i systemetDisse endepunktene opprettes og aktiveres med cmdleter som Ny PSSessionConfigurationFile, Register-PSSessionConfiguration eller grafiske verktøy som JEA Helper Tool, som gjør det enklere å generere .pssc- og .psrc-filer uten å slite så mye med syntaksen.

JEA-øktens livssyklus

Når man setter opp et komplett JEA-miljø, følger prosessen vanligvis en rekke logiske trinn som De forvandler et åpent fjernstyringssystem til et strengt styrt system.Den typiske sekvensen er:

Først lager du en sikkerhetsgruppe eller flere grupper som representerer rollene du vil delegere (for eksempel HelpdeskDNS, weboperatorer, SQL-operatorer). Bruk av grupper er ikke obligatorisk, men det gjør administrasjonen mye enklere etter hvert som miljøet vokser.

Deretter blir én eller flere forberedt rollefunksjonsfiler .psrc Disse viser tillatte handlinger: cmdleter, funksjoner, skript, eksterne kommandoer, aliaser, leverandører og ytterligere restriksjoner (spesifikke parametere, tillatte stier osv.). Her kan du for eksempel tillate alle cmdleter som begynner med Get-, begrense Restart-Service til Spooler-tjenesten og bare autorisere FileSystem-leverandøren.

Følgende genereres sesjonskonfigurasjonsfil .pssc ved hjelp av New-PSSessionConfigurationFile. Den definerer alternativer som SessionType = RestrictedRemoteServer, TranscriptDirectory-banen, om virtuelle kontoer brukes og RoleDefinitions-blokken som kobler grupper til rollefunksjoner, for eksempel 'DOMAIN\HelpdeskDNS' = @{ RoleCapabilities = 'HelpdeskDNSRole' }.

Når .pssc-filen allerede er klargjort, registreres endepunktet ved hjelp av Register-PSSessionConfiguration -Navn JEASesjonsnavn -Sti Sti\Fil.psscFra det øyeblikket av, hvis de tilgjengelige konfigurasjonene er oppført med Get-PSSessionConfiguration, vil det nye tilkoblingspunktet se ut som klart til å motta tilkoblinger.

Brukere kobler seg til dette endepunktet fra datamaskinene sine med Enter-PSSession -Datamaskinnavnserver -Konfigurasjonsnavn JEASession-navn eller med New-PSSession og deretter Invoke-Command. Ved oppstart bruker økten automatisk restriksjonene som er definert i brukerens tilknyttede rollefunksjon.

Under økten, PowerShell-fjernstyring bruker WinRM med krypterte kanalerIntegrert autentisering (vanligvis Kerberos i domenet) og brannmurreglene som er definert for tjenesten. Hvis RunAsVirtualAccount er aktivert, opprettes en midlertidig virtuell konto som legges til i de nødvendige gruppene og slettes når økten avsluttes.

Til slutt, etter avslutningen av JEA-sesjonen, Revisjonsutskriftene og hendelsene lagres Disse loggene etterlater et tydelig spor av utførte kommandoer, resultater og brukerkontekst. De kan deretter sendes til eller korreleres i et SIEM-system for varsler og videre analyse.

PowerShell-fjernstyring, tilgangskontroll og herding

PowerShell-fjernstyring, støttet av tjenesten Windows-fjernadministrasjon (WinRM) WS-Management-protokollen tillater sentralisert utførelse av kommandoer og skript på eksterne datamaskiner. Det er et kraftig verktøy for automatisering, masseserveradministrasjon, feilsøking og fjernstøtte.

Misligholde, lokale administratorer og medlemmer av gruppen for fjernadministrasjonsbrukere De kan bruke standard PowerShell-endepunkter. I mange miljøer har denne funksjonaliteten blitt brukt til å la ikke-administratorbrukere kjøre eksterne oppgaver, noe som ikke er iboende farlig, men hvis det ikke kontrolleres riktig, åpner det en betydelig mulighet for misbruk.

For å styrke sikkerhetsstillingen innebærer en felles strategi Begrens ekstern PowerShell-tilgang kun til administratorkontoer. Eller, enda bedre, kombiner denne begrensningen med JEA-endepunkter som bare gir visse brukere den strengt nødvendige tilgangen. Dette kan oppnås gjennom:

• GPO-er som definerer hvilke grupper som kan bruke WinRM og standardendepunkter.
• Brannmurregler som bare tillater WinRM fra delnett eller administrasjonsdatamaskiner.
• Fjerner gruppen Brukere for ekstern administrasjon fra tilgangskontrollistene til standard endepunkter.

I tillegg kan du velge å Blokker PowerShell fullstendig for brukere som ikke er administratorer ved hjelp av løsninger som AppLocker. På denne måten forhindrer du at en standardbruker kjører ondsinnede skript lokalt, men lar fortsatt privilegerte kontoer bruke PowerShell til administrasjons- og automatiseringsoppgaver.

JEA versus andre PowerShell-begrensningsmetoder

Det finnes flere måter å begrense hva brukere kan gjøre med PowerShell-fjernstyring, og JEA passer som et tynnere og mer fleksibelt alternativ innenfor et spekter som inkluderer bredere tilnærminger som:

På den ene siden bruken av GPO for å kontrollere hvem som går inn i standard PowerShell-endepunkterMicrosoft PowerShell kan begrenses til administratorer, eller til og med uregistreres for alle, noe som tvinger frem bruken av spesifikke endepunkter. Dette er nyttig for å begrense tilgang på en "brute force"-måte, men det løser ikke granularitetsproblemet: den som får tilgang kan gjøre praktisk talt hva som helst.

På den annen side finnes det verktøy for applikasjonskontroll som f.eks. AppLocker eller retningslinjer for programvarebegrensningDisse metodene lar deg nekte kjøring av PowerShell.exe eller pwsh.exe for standardbrukere, enten etter sti, utgiver eller hash. Denne tilnærmingen er nyttig for å herde arbeidsstasjoner og forhindre at brukere starter PowerShell, men den gir begrensninger når du vil at noen skal utføre begrensede administrative oppgaver fra brukerkontoen sin.

Et annet alternativ er Begrensede endepunkter uten å nå full JEADu kan opprette tilpassede øktkonfigurasjoner som begrenser cmdleter, funksjoner og moduler, men uten å stole like mye på rollemodellen, virtuelle kontoer eller strukturert RBAC som JEA tilbyr. Det er en slags mellomvei som passer for enkle scenarier, men mindre skalerbar i store miljøer.

JEA kombinerer det beste fra flere verdener: streng kommandobegrensning, RBAC, kontrollert utførelse av forhøyede rettigheter og omfattende loggingDette gjør den til den anbefalte løsningen når du trenger å aktivere PowerShell-fjernstyring for ikke-administratorer, men uten å gi dem et komplett administrasjonsmiljø.

Avanserte funksjoner: kjør som en annen konto og logg

En av JEAs kraftigste funksjoner er utfør kommandoer som en annen, mer privilegert konto uten å avsløre legitimasjonen dinDette løser det typiske problemet med «Jeg gir deg passordet for denne tjenesten slik at du kan gjøre X», som deretter aldri endres og ender opp med å være en stor risiko.

Domenescenarier brukes ofte Gruppeadministrerte tjenestekontoer (gMSA) Dette lar JEA-endepunkter utføre handlinger under en sentralt administrert tjenesteidentitet, med automatisk passordrotasjon og uten at noen operatør noen gang kjenner til hemmeligheten. I andre tilfeller brukes midlertidige virtuelle kontoer lokalt for maskinen, som opprettes ad hoc når en bruker kobler seg til og slettes på slutten av økten.

Fra et revisjonsperspektiv kan hver JEA-økt konfigureres til å generere både PowerShell-transkripter og omfattende hendelsesloggoppføringerInformasjonen som vanligvis samles inn inkluderer:

• Fullstendig historikk over kommandoer og parametere som er angitt.
• Genererte utdata og feilmeldinger.
• Tidsstempel for start og slutt på økten, samt dens varighet.
• Identiteten til den innloggede brukeren og tildelt rolle/kapasitet.

Hvis du kombinerer disse sporene med funksjonaliteter til PowerShell-modullogging og Script Blokklogging via GPOOg ved å sende loggene til et SIEM-system får du robust innsikt i hva som skjer på administrasjonsendepunktene dine. Dette er avgjørende for både samsvar (SOX-revisjoner, ISO 27001 osv.) og hendelsesdeteksjon og -respons.

Typiske JEA-brukstilfeller i virkelige miljøer

JEA skinner spesielt når du trenger det Delegere svært spesifikke oppgaver til team som ikke burde være administratorerNoen svært vanlige eksempler i praksis er:

Innenfor teknisk support kan du gi teknikere på toppnivå JEA-tilgang for å starte tjenester på nytt, vise hendelseslogger og sjekke prosessstatus på servere, men uten mulighet til å installere programvare, endre kritiske konfigurasjoner eller få tilgang til Active Directory. En typisk brukerstøtterolle kan inkludere cmdleter som Get-Service, Restart-Service for spesifikke tjenester, Get-EventLog i skrivebeskyttet modus og noen cmdleter for nettverksdiagnostikk.

I drifts- eller utviklingsteam kan du konfigurere roller fokusert på spesifikke oppgaver som IIS-administrasjon eller vedlikehold av nettstederFor eksempel å gi tilgang til cmdleter for administrasjon av applikasjonsutvalg, omstart av nettsteder, spørring av logger fra en begrenset katalog og sertifikatadministrasjon for spesifikke tjenester, samtidig som det utelukker enhver mulighet til å starte hele serveren på nytt eller endre sikkerhetspolicyer.

I hybrid- og skymiljøer brukes JEA ofte til begrense hva hvert lag kan gjøre med virtuelle maskiner, lagring eller nettverkDu kan eksponere endepunkter som lar deg administrere bare de virtuelle maskinene i en avdeling, endre brannmurreglene for et bestemt segment eller administrere et bestemt sett med tjenestekontoer, og dermed holde tilgangen atskilt fra resten av infrastrukturen.

Samtidig passer JEA veldig godt sammen med Strategier for privilegert tilgangsstyring (PAM)der privilegerte økter gis midlertidig, logges og tilskrives personlige identiteter, unngår delte kontoer og minimerer risikoen forbundet med hver privilegerte handling.

Relatert artikkel:

Hvordan begrense tilgangen til delte mapper i Windows trinn for trinn

Isaac

Lidenskapelig forfatter om verden av bytes og teknologi generelt. Jeg elsker å dele kunnskapen min gjennom å skrive, og det er det jeg skal gjøre i denne bloggen, vise deg alle de mest interessante tingene om dingser, programvare, maskinvare, teknologiske trender og mer. Målet mitt er å hjelpe deg med å navigere i den digitale verden på en enkel og underholdende måte.