Funzionalità del ruolo JEA

Quando si crea un endpoint JEA, è necessario definire una o più funzionalità del ruolo per descrivere cosa un utente può eseguire in una sessione JEA. Una funzionalità del ruolo è un file di dati di PowerShell con l'estensione .psrc che elenca tutti i cmdlet, le funzioni, i provider e i programmi esterni resi disponibili per la connessione degli utenti.

Determinare quali comandi consentire

Il primo passaggio per la creazione di un file di funzionalità del ruolo consiste nel considerare gli elementi a cui gli utenti devono accedere. Il processo di raccolta dei requisiti può richiedere del tempo, ma è importante. Concedere agli utenti l'accesso a un numero eccessivo di cmdlet e funzioni può impedire loro di svolgere il proprio lavoro. Consentire l'accesso a troppi cmdlet e funzioni può consentire agli utenti di eseguire più di quanto previsto e indebolire la posizione di sicurezza.

Il modo in cui si procede a questo processo dipende dall'organizzazione e dai propri obiettivi. I suggerimenti seguenti consentono di assicurarsi di essere nel percorso corretto.

1. Identificare i comandi usati dagli utenti per svolgere il proprio lavoro. Ciò può comportare il sondaggio del personale IT, il controllo degli script di automazione o l'analisi delle trascrizioni e dei log delle sessioni di PowerShell.
2. Aggiornare l'uso degli strumenti da riga di comando agli equivalenti di PowerShell, ove possibile, per un'esperienza ottimale di controllo e personalizzazione JEA. I programmi esterni non possono essere vincolati in modo granulare come cmdlet e funzioni nativi di PowerShell in JEA.
3. Limitare l'ambito dei cmdlet per consentire solo parametri o valori di parametro specifici. Ciò è particolarmente importante se gli utenti devono gestire solo parte di un sistema.
4. Creare funzioni personalizzate per sostituire comandi complessi o difficili da limitare in JEA. Una funzione semplice che esegue il wrapping di un comando complesso o applica logica di convalida aggiuntiva può offrire un controllo aggiuntivo per gli amministratori e la semplicità dell'utente finale.
5. Testa l'elenco di comandi consentiti limitato con gli utenti o i servizi di automazione, e modificalo in base alle esigenze.

Esempi di comandi potenzialmente pericolosi

Un'attenta selezione dei comandi è importante per assicurarsi che l'endpoint JEA non consenta all'utente di elevare le autorizzazioni.

Importante

Informazioni essenziali necessarie per il successo dell'utente. I comandi in una sessione JEA vengono spesso eseguiti con privilegi elevati.

L'elenco seguente contiene esempi di comandi che possono essere usati in modo dannoso se consentiti in uno stato non vincolato. Questo non è un elenco completo e deve essere usato solo come punto di partenza con cautela.

• Rischio: Concessione dei privilegi di amministratore all'utente connesso per ignorare JEA

  Esempio:

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

  comandi correlati:

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

• Rischio: Esecuzione di codice arbitrario, ad esempio malware, exploit o script personalizzati per ignorare le protezioni

  Esempio:

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

  comandi correlati:

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

Creare un file di funzionalità del ruolo

È possibile creare un nuovo file delle funzionalità del ruolo di PowerShell con il cmdlet New-PSRoleCapabilityFile.

New-PSRoleCapabilityFile -Path .\MyFirstJEARole.psrc

È necessario modificare il file di funzionalità del ruolo creato per consentire solo i comandi necessari per il ruolo. La documentazione della Guida di PowerShell contiene molti esempi su come configurare il file.

Consentire cmdlet e funzioni di PowerShell

Per autorizzare gli utenti a eseguire i cmdlet o le funzioni di PowerShell, aggiungere il cmdlet o il nome della funzione ai campi VisibleCmdlets o VisibleFunctions. Se non si è certi che un comando sia un cmdlet o una funzione, è possibile eseguire Get-Command <name> e controllare la proprietà CommandType nell'output.

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

A volte l'ambito di un cmdlet o di una funzione specifica è troppo ampio per le esigenze degli utenti. Un amministratore DNS, ad esempio, potrebbe dover accedere solo per riavviare il servizio DNS. Negli ambienti multi-tenant i tenant hanno accesso agli strumenti di gestione self-service. Gli inquilini dovrebbero essere limitati alla gestione delle proprie risorse. Per questi casi, è possibile limitare i parametri esposti dal cmdlet o dalla funzione .

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

In scenari più avanzati, potrebbe anche essere necessario limitare i valori che un utente può usare con questi parametri. Le funzionalità del ruolo consentono di definire un set di valori o un modello di espressione regolare che determina l'input consentito.

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

Nota

I parametri di PowerShell comuni sono sempre consentiti, anche se si limitano i parametri disponibili. Non è consigliabile elencarli in modo esplicito nel campo Parametri.

L'elenco seguente descrive i vari modi in cui è possibile personalizzare un cmdlet o una funzione visibile. È possibile combinare liberamente qualsiasi delle seguenti opzioni nel campo VisibleCmdlets.

• Caso d'uso: Consentire all'utente di eseguire My-Func senza restrizioni sui parametri.

  @{ Name = 'My-Func' }
  

• Caso d'uso: Consentire all'utente di eseguire My-Func dal modulo MyModule senza restrizioni sui parametri.

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

• Caso d'uso: Consentire all'utente di eseguire qualsiasi cmdlet o funzione con il verbo My.

  @{ Name = 'My-*' }
  

• Caso d'uso: Consentire all'utente di eseguire qualsiasi cmdlet o funzione con il sostantivo Func.

  @{ Name = '*-Func' }
  

• Caso d'uso: Consentire all'utente di eseguire My-Func con i parametri Param1 e Param2. È possibile specificare qualsiasi valore ai parametri.

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

• Caso d'uso: Consentire all'utente di eseguire My-Func con il parametro Param1. È possibile specificare solo Value1 e Value2 al parametro .

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

• Caso d'uso: Consentire all'utente di eseguire My-Func con il parametro Param1. Qualsiasi valore che inizia con contoso può essere fornito al parametro .

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

Avvertimento

Per le migliori pratiche di sicurezza, non è consigliabile usare caratteri jolly quando si definiscono cmdlet o funzioni visibili. È invece consigliabile elencare in modo esplicito ogni comando attendibile per assicurarsi che non siano autorizzati involontariamente altri comandi che condividono lo stesso schema di denominazione.

Non è possibile applicare sia un ValidatePattern che ValidateSet alla stessa funzione o cmdlet.

In questo caso, il ValidatePattern esegue l'override dell'ValidateSet.

Per altre informazioni su ValidatePattern, vedere questo Hey, Scripting Guy! pubblicare e il contenuto di riferimento espressioni regolari di PowerShell.

Consentire comandi esterni e script di PowerShell

Per consentire agli utenti di eseguire file eseguibili e script di PowerShell (.ps1) in una sessione JEA, è necessario aggiungere il percorso completo a ogni programma nel campo VisibleExternalCommands.

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

Se possibile, usare i cmdlet o gli equivalenti di funzioni di PowerShell per tutti gli eseguibili esterni autorizzati perché si ha il controllo sui parametri consentiti con i cmdlet e le funzioni di PowerShell.

Molti eseguibili consentono di leggere lo stato corrente e quindi modificarlo fornendo parametri diversi.

Si consideri ad esempio il ruolo di amministratore di un file server che gestisce le condivisioni di rete ospitate in un sistema. Un modo per gestire le condivisioni consiste nell'usare net share. Tuttavia, consentire net.exe è pericoloso perché l'utente potrebbe usare il comando per ottenere privilegi di amministratore con il comando net group Administrators unprivilegedjeauser /add. Un'opzione più sicura consiste nell'consentire il cmdlet Get-SmbShare, che ottiene lo stesso risultato, ma ha un ambito molto più limitato.

Quando si rendono disponibili comandi esterni agli utenti in una sessione JEA, specificare sempre il percorso completo del file eseguibile. In questo modo si impedisce l'esecuzione di programmi denominati in modo simile e potenzialmente dannosi che si trovano altrove nel sistema.

Consentire l'accesso ai provider di PowerShell

Per impostazione predefinita, nelle sessioni JEA non sono disponibili provider di PowerShell. In questo modo si riduce il rischio che le informazioni riservate e le impostazioni di configurazione vengano divulgate all'utente che si connette.

Quando necessario, è possibile consentire l'accesso ai provider di PowerShell usando il comando VisibleProviders. Per un elenco completo dei provider, eseguire Get-PSProvider.

VisibleProviders = 'Registry'

Per attività semplici che richiedono l'accesso al file system, al Registro di sistema, all'archivio certificati o ad altri provider sensibili, è consigliabile scrivere una funzione personalizzata che funzioni con il provider per conto dell'utente. Le funzioni, i cmdlet e i programmi esterni disponibili in una sessione JEA non sono soggetti agli stessi vincoli di JEA. Possono accedere a qualsiasi provider per impostazione predefinita. Prendere in considerazione anche l'uso dell'unità utente quando gli utenti devono copiare file da o verso un endpoint JEA.

Creazione di funzioni personalizzate

È possibile creare funzioni personalizzate in un file di funzionalità del ruolo per semplificare attività complesse per gli utenti finali. Le funzioni personalizzate sono utili anche quando è necessaria la logica di convalida avanzata per i valori dei parametri del cmdlet. È possibile scrivere funzioni semplici nel campo 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
    }
}

Importante

Non dimenticare di aggiungere il nome delle funzioni personalizzate al campo VisibleFunctions in modo che possano essere eseguiti dagli utenti JEA.

Il corpo (blocco di script) delle funzioni personalizzate viene eseguito nella modalità di linguaggio predefinita per il sistema e non è soggetto ai vincoli del linguaggio JEA. Ciò significa che le funzioni possono accedere al file system e al Registro di sistema ed eseguire comandi che non sono stati resi visibili nel file delle funzionalità del ruolo. Prestare attenzione a evitare di eseguire codice arbitrario quando si usano parametri. Evitare il piping dell'input dell'utente direttamente in cmdlet come Invoke-Expression.

Nell'esempio precedente si noti che è stato usato il nome completo del modulo (FQMN) Microsoft.PowerShell.Utility\Select-Object anziché la Select-Objectabbreviata . Le funzioni definite nei file di funzionalità del ruolo sono ancora soggette all'ambito delle sessioni JEA, che include le funzioni proxy create da JEA per vincolare i comandi esistenti.

Per impostazione predefinita, Select-Object è un cmdlet vincolato in tutte le sessioni JEA che non consente la selezione di proprietà arbitrarie sugli oggetti. Per usare il Select-Object senza restrizioni nelle funzioni, è necessario richiedere in modo esplicito l'implementazione completa usando il FQMN completo. Qualsiasi cmdlet vincolato in una sessione JEA ha gli stessi vincoli quando viene richiamato da una funzione. Per altre informazioni, vedere about_Command_Precedence.

Se si scrivono diverse funzioni personalizzate, è più pratico inserirle in un modulo script di PowerShell. Tali funzioni vengono visualizzate nella sessione JEA usando il campo VisibleFunctions come si farebbe con i moduli predefiniti e di terze parti.

Per il corretto funzionamento nelle sessioni JEA del completamento delle schede, è necessario includere la funzione predefinita TabExpansion2 nell'elenco VisibleFunctions.

Rendere disponibili le funzionalità del ruolo per una configurazione

Prima di PowerShell 6, affinché PowerShell trovi un file di funzionalità del ruolo, deve essere archiviato in una cartella RoleCapabilities in un modulo di PowerShell. Il modulo può essere archiviato in qualsiasi cartella inclusa nella variabile di ambiente $Env:PSModulePath, ma non è consigliabile inserirlo in $Env:SystemRoot\System32 o in una cartella in cui gli utenti non attendibili potrebbero modificare i file.

L'esempio seguente crea un modulo script di PowerShell denominato ContosoJEA nel percorso $Env:ProgramFiles per ospitare il file delle funzionalità del ruolo.

# 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

Per altre informazioni sui moduli di PowerShell, vedere Informazioni su un modulo di PowerShell.

A partire da PowerShell 6, la proprietà RoleDefinitions è stata aggiunta al file di configurazione della sessione. Questa proprietà consente di specificare il percorso di un file di configurazione del ruolo per la definizione del ruolo. Vedere gli esempi in New-PSSessionConfigurationFile.

Aggiornamento delle funzionalità dei ruoli

È possibile modificare un file di funzionalità del ruolo per aggiornare le impostazioni in qualsiasi momento. Le nuove sessioni JEA avviate dopo l'aggiornamento della funzionalità del ruolo rifletteranno le funzionalità modificate.

Questo è il motivo per cui il controllo dell'accesso alla cartella delle funzionalità del ruolo è così importante. Solo gli amministratori altamente attendibili devono essere autorizzati a modificare i file delle funzionalità del ruolo. Se un utente non attendibile può modificare i file di funzionalità del ruolo, può facilmente concedere a sé stesso l'accesso ai cmdlet che permettono loro di elevare i propri privilegi.

Per gli amministratori che cercano di bloccare l'accesso alle funzionalità del ruolo, assicurarsi che il sistema locale abbia accesso in sola lettura ai file delle funzionalità del ruolo e ai moduli che li contengono.

Modalità di unione delle funzionalità del ruolo

Agli utenti viene concesso l'accesso a tutte le funzionalità del ruolo corrispondenti nel file di configurazione della sessione quando accedono a una sessione JEA. JEA tenta di fornire all'utente il set di comandi più permissivo consentito da uno dei ruoli.

VisibleCmdlets e VisibleFunctions

La logica di unione più complessa influisce su cmdlet e funzioni, che possono avere i relativi parametri e valori di parametro limitati in JEA.

Le regole sono le seguenti:

1. Se un cmdlet viene reso visibile solo in un ruolo, è visibile all'utente con eventuali vincoli di parametro applicabili.
2. Se un cmdlet viene reso visibile in più ruoli e ogni ruolo ha gli stessi vincoli nel cmdlet, il cmdlet è visibile all'utente con tali vincoli.
3. Se un cmdlet viene reso visibile in più ruoli e ogni ruolo consente un set diverso di parametri, il cmdlet e tutti i parametri definiti in ogni ruolo sono visibili all'utente. Se un ruolo non ha vincoli sui parametri, tutti i parametri sono consentiti.
4. Se un ruolo definisce un set di convalida o un modello di convalida per un parametro del cmdlet e l'altro ruolo consente il parametro ma non vincola i valori dei parametri, il set di convalida o il modello viene ignorato.
5. Se viene definito un set di convalida per lo stesso parametro del cmdlet in più ruoli, sono consentiti tutti i valori di tutti i set di convalida.
6. Se viene definito un modello di convalida per lo stesso parametro del cmdlet in più di un ruolo, sono consentiti tutti i valori che corrispondono a uno dei modelli.
7. Se un set di convalida viene definito in uno o più ruoli e un modello di convalida viene definito in un altro ruolo per lo stesso parametro del cmdlet, il set di convalida viene ignorato e la regola (6) si applica ai modelli di convalida rimanenti.

Di seguito è riportato un esempio di come i ruoli vengono uniti in base a queste regole:

# 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'
            }
        }
    )
}

ComandiEsterniVisibili, AliasVisibili, FornitoriVisibili, ScriptDaElaborare

Tutti gli altri campi nel file delle funzionalità del ruolo vengono aggiunti a un set cumulativo di comandi esterni consentiti, alias, provider e script di avvio. Qualsiasi comando, alias, provider o script disponibile in una funzionalità del ruolo è disponibile per l'utente JEA.

Prestare attenzione a assicurarsi che il set combinato di provider da una funzionalità del ruolo e cmdlet/funzioni/comandi da un altro non consenta agli utenti l'accesso involontario alle risorse di sistema. Ad esempio, se un ruolo consente il cmdlet Remove-Item e un altro consente il provider di FileSystem, si è a rischio che un utente JEA elimini file arbitrari nel computer. Ulteriori informazioni sull'identificazione delle autorizzazioni effettive degli utenti sono disponibili nell'articolo sulla verifica JEA.

Passaggi successivi

Creare un file di configurazione di sessione