JEA-rollfunktioner

När du skapar en JEA-slutpunkt måste du definiera en eller flera rollfunktioner som beskriver vad någon kan göra i en JEA-session. En rollfunktion är en PowerShell-datafil med .psrc tillägget som visar alla cmdletar, funktioner, leverantörer och externa program som görs tillgängliga för anslutande användare.

Ta reda på vilka kommandon som ska tillåtas

Det första steget i att skapa en rollfunktionsfil är att överväga vad användarna behöver åtkomst till. Det kan ta en stund att samla in krav, men det är viktigt. Att ge användarna åtkomst till för få cmdletar och funktioner kan hindra dem från att få jobbet gjort. Om du tillåter åtkomst till för många cmdletar och funktioner kan användarna göra mer än du tänkt dig och försvaga din säkerhetsposition.

Hur du går till väga för den här processen beror på din organisation och dina mål. Följande tips kan hjälpa dig att se till att du är på rätt väg.

1. Identifiera de kommandon som användarna använder för att få sina jobb gjorda. Det kan handla om att undersöka IT-personal, kontrollera automatiseringsskript eller analysera PowerShell-sessionsavskrifter och loggar.
2. Uppdatera användningen av kommandoradsverktyg till PowerShell-motsvarigheter, där det är möjligt, för bästa gransknings- och JEA-anpassningsupplevelse. Externa program kan inte begränsas så detaljerat som interna PowerShell-cmdletar och funktioner i JEA.
3. Begränsa cmdletarnas omfång till att endast tillåta specifika parametrar eller parametervärden. Detta är särskilt viktigt om användarna bara ska hantera en del av ett system.
4. Skapa anpassade funktioner för att ersätta komplexa kommandon eller kommandon som är svåra att begränsa i JEA. En enkel funktion som omsluter ett komplext kommando eller tillämpar ytterligare valideringslogik kan ge ytterligare kontroll för administratörer och slutanvändares enkelhet.
5. Testa den begränsade listan över tillåtna kommandon med dina användare eller automationstjänster och justera efter behov.

Exempel på potentiellt farliga kommandon

Noggrant val av kommandon är viktigt för att säkerställa att JEA-slutpunkten inte tillåter att användaren höjer sina behörigheter.

Viktigt!

Viktig information som krävs för att användaren ska lyckasKommandon i en JEA-session körs ofta med förhöjd behörighet.

Följande lista innehåller exempel på kommandon som kan användas skadligt om de tillåts i ett obehindrat tillstånd. Detta är inte en fullständig lista och bör endast användas som en varnande startpunkt.

• Risk: Bevilja anslutande användaradministratörsbehörigheter för att kringgå JEA

  Exempel:

  Add-LocalGroupMember -Member 'CONTOSO\jdoe' -Group 'Administrators'
  

  Relaterade kommandon:

  • Add-ADGroupMember
  • Add-LocalGroupMember
  • net.exe
  • dsadd.exe

• Risk: Köra godtycklig kod, till exempel skadlig kod, sårbarheter eller anpassade skript för att kringgå skydd

  Exempel:

  Start-Process -FilePath '\\san\share\malware.exe'
  

  Relaterade kommandon:

  • Start-Process
  • New-Service
  • Invoke-Item
  • Invoke-WmiMethod
  • Invoke-CimMethod
  • Invoke-Expression
  • Invoke-Command
  • New-ScheduledTask
  • Register-ScheduledJob

Skapa en rollfunktionsfil

Du kan skapa en ny PowerShell-rollfunktionsfil med cmdleten New-PSRoleCapabilityFile .

New-PSRoleCapabilityFile -Path .\MyFirstJEARole.psrc

Du bör redigera den skapade rollfunktionsfilen så att endast de kommandon som krävs för rollen tillåts. PowerShell-hjälpdokumentationen innehåller flera exempel på hur du kan konfigurera filen.

Tillåta PowerShell-cmdletar och funktioner

Om du vill ge användare behörighet att köra PowerShell-cmdletar eller funktioner lägger du till cmdleten eller funktionsnamnet i fälten VisibleCmdlets eller VisibleFunctions . Om du inte är säker på om ett kommando är en cmdlet eller funktion kan du köra Get-Command <name> och kontrollera egenskapen CommandType i utdata.

VisibleCmdlets = @('Restart-Computer', 'Get-NetIPAddress')

Ibland är omfattningen för en specifik cmdlet eller funktion för bred för användarnas behov. En DNS-administratör kanske till exempel bara behöver åtkomst för att starta om DNS-tjänsten. I miljöer med flera klientorganisationer har klientorganisationer åtkomst till självbetjäningshanteringsverktyg. Klientorganisationer bör begränsas till att hantera sina egna resurser. I dessa fall kan du begränsa vilka parametrar som exponeras från cmdleten eller funktionen.

VisibleCmdlets = @{
    Name       = 'Restart-Computer'
    Parameters = @{ Name = 'Name' }
}

I mer avancerade scenarier kan du också behöva begränsa de värden som en användare kan använda med dessa parametrar. Med rollfunktioner kan du definiera en uppsättning värden eller ett mönster för reguljära uttryck som avgör vilka indata som tillåts.

VisibleCmdlets = @(
    @{
        Name       = 'Restart-Service'
        Parameters = @{ Name = 'Name'; ValidateSet = @('Dns', 'Spooler') }
    }
    @{
        Name       = 'Start-Website'
        Parameters = @{ Name = 'Name'; ValidatePattern = 'HR_*' }
    }
)

Kommentar

De vanliga PowerShell-parametrarna tillåts alltid, även om du begränsar de tillgängliga parametrarna. Du bör inte uttryckligen lista dem i fältet Parametrar.

I listan nedan beskrivs olika sätt att anpassa en synlig cmdlet eller funktion. Du kan blanda och matcha något av nedanstående i fältet VisibleCmdlets .

• Användningsfall: Tillåt att användaren körs My-Func utan några begränsningar för parametrarna.

  @{ Name = 'My-Func' }
  

• Användningsfall: Tillåt att användaren kör My-Func från modulen MyModule utan några begränsningar för parametrarna.

  @{ Name = 'MyModule\My-Func' }
  

• Användningsfall: Tillåt att användaren kör valfri cmdlet eller funktion med verbet My.

  @{ Name = 'My-*' }
  

• Användningsfall: Tillåt att användaren kör valfri cmdlet eller funktion med substantiv Func.

  @{ Name = '*-Func' }
  

• Användningsfall: Tillåt att användaren kör My-Func med parametrarna Param1 och Param2 . Valfritt värde kan anges till parametrarna.

  @{ Name = 'My-Func'; Parameters = @{ Name = 'Param1'}, @{ Name = 'Param2' }}
  

• Användningsfall: Tillåt att användaren kör My-Func med parametern Param1 . Endast Value1 och Value2 kan anges till parametern.

  @{
      Name       = 'My-Func'
      Parameters = @{ Name = 'Param1'; ValidateSet = @('Value1', 'Value2') }
  }
  

• Användningsfall: Tillåt att användaren kör My-Func med parametern Param1 . Alla värden som börjar med contoso kan anges till parametern.

  @{
      Name       = 'My-Func'
      Parameters = @{ Name = 'Param1'; ValidatePattern = 'contoso.*' }
  }
  

Varning

För bästa säkerhetsmetoder rekommenderar vi inte att du använder jokertecken när du definierar synliga cmdletar eller funktioner. I stället bör du uttryckligen lista varje betrott kommando för att säkerställa att inga andra kommandon som delar samma namngivningsschema oavsiktligt har behörighet.

Du kan inte använda både ValidatePattern och ValidateSet på samma cmdlet eller funktion.

Om du gör det åsidosätter ValidatePattern ValidateSet.

Mer information om ValidatePattern finns i det här Hey, Scripting Guy!-inlägget och referensinnehållet för PowerShell Regular Expressions.

Tillåta externa kommandon och PowerShell-skript

Om du vill tillåta användare att köra körbara filer och PowerShell-skript (.ps1) i en JEA-session måste du lägga till den fullständiga sökvägen till varje program i fältet VisibleExternalCommands .

VisibleExternalCommands = @(
    'C:\Windows\System32\whoami.exe'
    'C:\Program Files\Contoso\Scripts\UpdateITSoftware.ps1'
)

Använd om möjligt PowerShell-cmdletar eller funktionsekvivalenter för eventuella externa körbara filer som du auktoriserar eftersom du har kontroll över de parametrar som tillåts med PowerShell-cmdletar och -funktioner.

Med många körbara filer kan du läsa det aktuella tillståndet och sedan ändra det genom att ange olika parametrar.

Tänk till exempel på rollen som filserveradministratör som hanterar nätverksresurser som finns i ett system. Ett sätt att hantera resurser är att använda net share. Det är dock farligt att tillåta net.exe eftersom användaren kan använda kommandot för att få administratörsbehörighet med kommandot net group Administrators unprivilegedjeauser /add. Ett säkrare alternativ är att tillåta cmdleten Get-SmbShare , som uppnår samma resultat men har ett mycket mer begränsat omfång.

När du gör externa kommandon tillgängliga för användare i en JEA-session anger du alltid den fullständiga sökvägen till den körbara filen. Detta förhindrar körning av liknande namngivna och potentiellt skadliga program som finns någon annanstans i systemet.

Tillåta åtkomst till PowerShell-leverantörer

Som standard är inga PowerShell-leverantörer tillgängliga i JEA-sessioner. Detta minskar risken för att känslig information och konfigurationsinställningar avslöjas för den anslutande användaren.

Vid behov kan du tillåta åtkomst till PowerShell-leverantörerna med hjälp av VisibleProviders kommandot . Kör en fullständig lista över leverantörer Get-PSProvider.

VisibleProviders = 'Registry'

För enkla uppgifter som kräver åtkomst till filsystemet, registret, certifikatarkivet eller andra känsliga leverantörer kan du skriva en anpassad funktion som fungerar med providern för användarens räkning. De funktioner, cmdletar och externa program som är tillgängliga i en JEA-session omfattas inte av samma begränsningar som JEA. De kan komma åt valfri leverantör som standard. Överväg också att använda användarenheten när användarna behöver kopiera filer till eller från en JEA-slutpunkt.

Skapa anpassade funktioner

Du kan skapa anpassade funktioner i en rollfunktionsfil för att förenkla komplexa uppgifter för slutanvändarna. Anpassade funktioner är också användbara när du behöver avancerad valideringslogik för cmdlet-parametervärden. Du kan skriva enkla funktioner i fältet FunctionDefinitions :

VisibleFunctions = 'Get-TopProcess'

FunctionDefinitions = @{
    Name        = 'Get-TopProcess'
    ScriptBlock = {
        param($Count = 10)

        Get-Process |
            Sort-Object -Property CPU -Descending |
            Microsoft.PowerShell.Utility\Select-Object -First $Count
    }
}

Viktigt!

Glöm inte att lägga till namnet på dina anpassade funktioner i fältet VisibleFunctions så att de kan köras av JEA-användarna.

Brödtexten (skriptblocket) för anpassade funktioner körs i standardspråkläget för systemet och omfattas inte av JEA:s språkbegränsningar. Det innebär att funktioner kan komma åt filsystemet och registret och köra kommandon som inte har gjorts synliga i rollfunktionsfilen. Var noga med att undvika att köra godtycklig kod när du använder parametrar. Undvik att skicka användarindata direkt till cmdletar som Invoke-Expression.

I exemplet ovan ser du att det fullständigt kvalificerade modulnamnet (FQMN) Microsoft.PowerShell.Utility\Select-Object användes i stället för den kortfattade Select-Object. Funktioner som definieras i rollfunktionsfiler omfattas fortfarande av omfånget för JEA-sessioner, som innehåller de proxyfunktioner som JEA skapar för att begränsa befintliga kommandon.

Som standard Select-Object är en begränsad cmdlet i alla JEA-sessioner som inte tillåter val av godtyckliga egenskaper för objekt. Om du vill använda obehindrat Select-Object i funktioner måste du uttryckligen begära den fullständiga implementeringen med hjälp av FQMN. Alla begränsade cmdletar i en JEA-session har samma begränsningar när de anropas från en funktion. Mer information finns i about_Command_Precedence.

Om du skriver flera anpassade funktioner är det enklare att placera dem i en PowerShell-skriptmodul. Du gör dessa funktioner synliga i JEA-sessionen med hjälp av fältet VisibleFunctions på samma sätt som med inbyggda moduler och moduler från tredje part.

För att tabbavslut ska fungera korrekt i JEA-sessioner måste du inkludera den inbyggda funktionen tabexpansion2 i listan VisibleFunctions .

Gör rollfunktionerna tillgängliga för en konfiguration

Innan PowerShell 6 måste PowerShell hitta en rollfunktionsfil som den måste lagras i en RoleCapabilities mapp i en PowerShell-modul. Modulen kan lagras i valfri mapp som ingår i $env:PSModulePath miljövariabeln, men du bör inte placera den i $env:SystemRoot\System32 eller en mapp där ej betrodda användare kan ändra filerna.

I följande exempel skapas en PowerShell-skriptmodul med namnet ContosoJEA i $env:ProgramFiles sökvägen för att vara värd för fil för rollfunktioner.

# Create a folder for the module
$modulePath = Join-Path $env:ProgramFiles "WindowsPowerShell\Modules\ContosoJEA"
New-Item -ItemType Directory -Path $modulePath

# Create an empty script module and module manifest.
# At least one file in the module folder must have the same name as the folder itself.
$rootModulePath = Join-Path $modulePath "ContosoJEAFunctions.psm1"
$moduleManifestPath = Join-Path $modulePath "ContosoJEA.psd1"
New-Item -ItemType File -Path $RootModulePath
New-ModuleManifest -Path $moduleManifestPath -RootModule "ContosoJEAFunctions.psm1"

# Create the RoleCapabilities folder and copy in the PSRC file
$rcFolder = Join-Path $modulePath "RoleCapabilities"
New-Item -ItemType Directory $rcFolder
Copy-Item -Path .\MyFirstJEARole.psrc -Destination $rcFolder

Mer information om PowerShell-moduler finns i Förstå en PowerShell-modul.

Från och med PowerShell 6 lades egenskapen RoleDefinitions till i sessionskonfigurationsfilen. Med den här egenskapen kan du ange platsen för en rollkonfigurationsfil för rolldefinitionen. Se exemplen i New-PSSessionConfigurationFile.

Uppdatera rollfunktioner

Du kan redigera en rollfunktionsfil för att uppdatera inställningarna när som helst. Alla nya JEA-sessioner som startas efter att rollfunktionen har uppdaterats återspeglar de ändrade funktionerna.

Därför är det så viktigt att kontrollera åtkomsten till mappen rollfunktioner. Endast mycket betrodda administratörer bör tillåtas att ändra rollfunktionsfiler. Om en ej betrodd användare kan ändra rollfunktionsfiler kan de enkelt ge sig själva åtkomst till cmdletar som gör att de kan höja sina privilegier.

För administratörer som vill låsa åtkomsten till rollfunktionerna kontrollerar du att det lokala systemet har skrivskyddad åtkomst till rollfunktionsfilerna och innehåller moduler.

Så här sammanfogas rollfunktioner

Användare beviljas åtkomst till alla matchande rollfunktioner i sessionskonfigurationsfilen när de anger en JEA-session. JEA försöker ge användaren den mest tillåtande uppsättningen kommandon som tillåts av någon av rollerna.

VisibleCmdlets och VisibleFunctions

Den mest komplexa sammanslagningslogik påverkar cmdletar och funktioner, som kan ha sina parametrar och parametervärden begränsade i JEA.

Reglerna är följande:

1. Om en cmdlet endast görs synlig i en roll är den synlig för användaren med eventuella tillämpliga parameterbegränsningar.
2. Om en cmdlet görs synlig i mer än en roll och varje roll har samma begränsningar för cmdleten, är cmdleten synlig för användaren med dessa begränsningar.
3. Om en cmdlet görs synlig i mer än en roll och varje roll tillåter en annan uppsättning parametrar, är cmdleten och alla parametrar som definierats för varje roll synliga för användaren. Om en roll inte har begränsningar för parametrarna tillåts alla parametrar.
4. Om en roll definierar en verifieringsuppsättning eller ett verifieringsmönster för en cmdlet-parameter, och den andra rollen tillåter parametern men inte begränsar parametervärdena, ignoreras verifieringsuppsättningen eller mönstret.
5. Om en verifieringsuppsättning har definierats för samma cmdlet-parameter i mer än en roll tillåts alla värden från alla verifieringsuppsättningar.
6. Om ett verifieringsmönster har definierats för samma cmdlet-parameter i mer än en roll tillåts alla värden som matchar något av mönstren.
7. Om en verifieringsuppsättning definieras i en eller flera roller och ett verifieringsmönster definieras i en annan roll för samma cmdlet-parameter ignoreras verifieringsuppsättningen och regeln (6) gäller för de återstående verifieringsmönstren.

Nedan visas ett exempel på hur roller slås samman enligt dessa regler:

# Role A Visible Cmdlets
$roleA = @{
    VisibleCmdlets = @(
        'Get-Service'
         @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Client' }
        }
    )
}

# Role B Visible Cmdlets
$roleB = @{
    VisibleCmdlets = @(
        @{
            Name       = 'Get-Service';
            Parameters = @{ Name = 'DisplayName'; ValidatePattern = 'DNS.*' }
        }
        @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Server' }
        }
    )
}

# Resulting permissions for a user who belongs to both role A and B
# - The constraint in role B for the DisplayName parameter on Get-Service
#   is ignored because of rule #4
# - The ValidateSets for Restart-Service are merged because both roles use
#   ValidateSet on the same parameter per rule #5
$mergedAandB = @{
    VisibleCmdlets = @(
        'Get-Service'
        @{
            Name = 'Restart-Service';
            Parameters = @{
                Name = 'DisplayName'
                ValidateSet = 'DNS Client', 'DNS Server'
            }
        }
    )
}

VisibleExternalCommands, VisibleAliases, VisibleProviders, ScriptsToProcess

Alla andra fält i rollfunktionsfilen läggs till i en kumulativ uppsättning tillåtna externa kommandon, alias, providers och startskript. Alla kommandon, alias, provider eller skript som är tillgängliga i en rollfunktion är tillgängliga för JEA-användaren.

Se till att den kombinerade uppsättningen providers från en rollfunktion och cmdletar/funktioner/kommandon från en annan inte tillåter användare oavsiktlig åtkomst till systemresurser. Om en roll till exempel tillåter cmdleten Remove-Item och en annan tillåter providern FileSystem riskerar du att en JEA-användare tar bort godtyckliga filer på datorn. Mer information om hur du identifierar användarnas effektiva behörigheter finns i jea-granskningsartikeln.

Nästa steg

Skapa en sessionskonfigurationsfil