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 che devono essere resi disponibili agli utenti che si connettono.
Determinare i comandi da consentire
Durante la creazione di un file delle funzionalità del ruolo, considerare prima di tutto i requisiti necessari agli utenti per eseguire l'accesso. Il processo di raccolta dei requisiti può richiedere del tempo, ma è importante. L'accesso a un numero limitato di cmdlet e funzioni potrebbe impedire agli utenti di svolgere il loro lavoro in maniera completa. Consentire agli utenti l'accesso a un numero eccessivo di cmdlet e funzioni, può permettere loro di eseguire più operazioni di quanto si voglia e creare problemi di sicurezza.
Il modo di procedere dipende dall'organizzazione e dagli obiettivi. Con i suggerimenti seguenti è possibile assicurarsi di essere nella giusta direzione.
- Identificare i comandi usati dagli utenti necessari per eseguire il loro lavoro. Questa operazione potrebbe comportare il controllo delle azioni del personale IT, degli script di automazione o l'analisi dei log e delle trascrizioni delle sessioni di PowerShell.
- Aggiornare l'uso degli strumenti da riga di comando per renderli equivalenti, se possibile, a quelli di PowerShell, per un miglior controllo e una migliore esperienza di personalizzazione di JEA. I programmi esterni non possono essere vincolati in modo granulare come le funzioni e i cmdlet nativi di PowerShell in JEA.
- Limitare l'ambito dei cmdlet per consentire solo parametri o valori di parametri specifici. È particolarmente importante se gli utenti devono gestire solo parte di un sistema.
- Creare funzioni personalizzate per sostituire comandi complessi o difficili da vincolare in JEA. Una funzione semplice che esegue il wrapping di un comando complesso o applica una logica di convalida aggiuntiva può offrire un controllo maggiore agli amministratori e agli utenti finali.
- Testare l'elenco con ambito dei comandi consentiti per utenti o servizi di automazione e apportare le modifiche necessarie.
Esempi di comandi potenzialmente pericolosi
È importante selezionare attentamente i comandi per assicurarsi che l'endpoint JEA non consenta all'utente di elevare le autorizzazioni.
Importante
Le informazioni essenziali richieste all'utente per successCommands in una sessione JEA prevedono spesso privilegi elevati.
L'elenco seguente contiene esempi di comandi che possono essere usati in modo dannoso se consentiti in uno stato non vincolato. L'elenco non è completo e deve essere usato solo come punto di partenza per l'analisi.
Rischio: concessione dei privilegi di amministratore utente di connessione per ignorare JEA
Esempio:
Add-LocalGroupMember -Member 'CONTOSO\jdoe' -Group 'Administrators'Comandi correlati:
Add-ADGroupMemberAdd-LocalGroupMembernet.exedsadd.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-ProcessNew-ServiceInvoke-ItemInvoke-WmiMethodInvoke-CimMethodInvoke-ExpressionInvoke-CommandNew-ScheduledTaskRegister-ScheduledJob
Creare un file delle 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 l'uso di funzioni e i cmdlet 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 . Nel caso in cui non si è certi se un comando è una funzione o un cmdlet, è possibile eseguire Get-Command <name> e verificare la proprietà CommandType nell'output.
VisibleCmdlets = @('Restart-Computer', 'Get-NetIPAddress')
In alcuni casi l'ambito di una funzione o di cmdlet specifico è troppo esteso 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. È necessario limitare i tenant alla gestione delle relative risorse. In questi casi, è possibile limitare i parametri offerti dal cmdlet o dalla funzione.
VisibleCmdlets = @{
Name = 'Restart-Computer'
Parameters = @{ Name = 'Name' }
}
Negli scenari più avanzati è necessario anche limitare i valori che un utente può usare per tali parametri. Le funzionalità del ruolo consentono di definire un set di valori o un modello di espressione regolare per determinare l'input consentito.
VisibleCmdlets = @(
@{
Name = 'Restart-Service'
Parameters = @{ Name = 'Name'; ValidateSet = @('Dns', 'Spooler') }
}
@{
Name = 'Start-Website'
Parameters = @{ Name = 'Name'; ValidatePattern = 'HR_*' }
}
)
Nota
I parametri comuni di PowerShell sono sempre consentiti, anche se si limita la disponibilità dei parametri. 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 le varie modalità descritte di seguito nel campo VisibleCmdlets.
Caso d'uso: consentire all'utente di eseguire
My-Funcsenza restrizioni sui parametri.@{ Name = 'My-Func' }Caso d'uso: consentire all'utente di eseguire
My-Funcdal 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-Funccon iParam1parametri eParam2. È possibile specificare qualsiasi valore per i parametri.@{ Name = 'My-Func'; Parameters = @{ Name = 'Param1'}, @{ Name = 'Param2' }}Caso d'uso: consente all'utente di eseguire
My-Funccon ilParam1parametro . SoloValue1eValue2possono essere forniti al parametro .@{ Name = 'My-Func' Parameters = @{ Name = 'Param1'; ValidateSet = @('Value1', 'Value2') } }Caso d'uso: consente all'utente di eseguire
My-Funccon ilParam1parametro . Qualsiasi valore che inizia concontosopuò essere fornito al parametro .@{ Name = 'My-Func' Parameters = @{ Name = 'Param1'; ValidatePattern = 'contoso.*' } }
Avviso
Per le procedure di sicurezza consigliate, non è consigliabile usare caratteri jolly quando si definiscono cmdlet o funzioni visibili. In alternativa, è necessario elencare in modo esplicito ogni comando attendibile per assicurarsi che nessun altro comando che condivide lo stesso schema di denominazione venga involontariamente autorizzato.
Non è possibile applicare ValidatePattern e ValidateSet allo stesso cmdlet o alla stessa funzione.
In caso contrario, ValidatePattern sostituirà ValidateSet.
Per altre informazioni su ValidatePattern, vedere il post sugli script Hey, Scripting Guy! e il contenuto dei riferimenti Espressioni regolari in PowerShell.
Consentire l'uso di comandi esterni e degli script di PowerShell
Per consentire agli utenti di eseguire 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 file eseguibili consentono di leggere lo stato corrente e di modificarlo specificando parametri diversi.
Si consideri ad esempio il ruolo di amministratore del 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 i comandi esterni vengono resi disponibili agli utenti in una sessione JEA, specificare sempre il percorso completo del file eseguibile. Si impedisce così l'esecuzione di programmi con nomi simili e potenzialmente dannosi presenti in un'altra posizione del sistema.
Consentire accesso ai provider di PowerShell
Per impostazione predefinita, non sono disponibili provider di PowerShell nelle sessioni JEA. In questo modo si riduce il rischio di divulgare informazioni sensibili e impostazioni di configurazione all'utente che esegue la connessione.
Se 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 eseguire semplici operazioni che richiedono l'accesso al file system, al Registro di sistema, all'archivio certificati o ad altri provider sensibili, è anche possibile scrivere una funzione personalizzata che interagisca 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. Per impostazione predefinita, è possibile accedere a qualsiasi provider. 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 delle funzionalità del ruolo per semplificare attività complesse per gli utenti finali. Le funzioni personalizzate sono utili anche quando è necessaria una logica di convalida avanzata per i valori dei parametri dei 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 per il campo VisibleFunctions in modo che possano essere eseguite dagli utenti JEA.
Il corpo (blocco di script) di funzioni personalizzate viene eseguito nella modalità di linguaggio predefinita per il sistema e non è soggetto ai vincoli di linguaggio di 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. Evitare di eseguire codice arbitrario quando si usano i parametri. Evitare l'indirizzamento diretto dell'input utente ai cmdlet, ad esempio Invoke-Expression.
Nell'esempio precedente si noti l'uso del nome del modulo completo Microsoft.PowerShell.Utility\Select-Object al posto della sintassi abbreviata Select-Object.
Le funzioni definite nei file delle funzionalità del ruolo sono comunque soggette all'ambito delle sessioni JEA, che include le funzioni proxy che JEA crea per vincolare i comandi esistenti.
Per impostazione predefinita, Select-Object è un cmdlet vincolato in tutte le sessioni JEA che non consente di selezionare proprietà arbitrarie in oggetti. Per usare Select-Object senza vincoli in funzioni, è necessario richiedere in modo esplicito l'implementazione completa, specificando il nome del modulo completo. Tutti i cmdlet vincolati in una sessione JEA hanno gli stessi vincoli quando vengono richiamati da una funzione. Per altre informazioni, vedere about_Command_Precedence.
Se si creano molte funzioni personalizzate, è opportuno inserirle in un modulo di script di PowerShell. Tali funzioni vengono rese visibili nella sessione JEA usando il campo VisibleFunctions, esattamente come per i moduli predefiniti e di terze parti.
Per il corretto funzionamento del completamento alla pressione del tasto TAB nelle sessioni JEA, è necessario includere la funzione predefinita tabexpansion2 nell'elenco VisibleFunctions.
Rendere disponibili le capacità del ruolo per una configurazione
Prima di PowerShell 6, affinché PowerShell trovi un file di funzionalità del ruolo, deve essere archiviato in una RoleCapabilities cartella in un modulo di PowerShell. Il modulo può essere archiviato in qualsiasi cartella inclusa nella variabile di ambiente $env:PSModulePath, tuttavia non deve essere posizionato in $env:SystemRoot\System32 o in una cartella in cui gli utenti non attendibili possono modificare i file.
L'esempio seguente crea un modulo di script di PowerShell denominato ContosoJEA nel percorso $env:ProgramFiles per ospitare il file delle capacità 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à del ruolo
È possibile modificare un file delle funzionalità del ruolo per aggiornare le impostazioni in qualsiasi momento. Ogni nuova sessione JEA avviata dopo l'aggiornamento delle funzionalità del ruolo includerà le funzionalità modificate.
Per questo motivo il controllo dell'accesso alla cartella delle funzionalità del ruolo è molto importante. Solo gli amministratori estremamente attendibili possono modificare i file delle funzionalità del ruolo. Se un utente non attendibile può modificare i file delle funzionalità del ruolo, può ottenere facilmente l'accesso ai cmdlet che consentono di elevare i 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 di funzionalità del ruolo e che contenga i moduli.
Come vengono uniti le funzionalità del ruolo
Agli utenti viene concesso l'accesso a tutte le funzionalità del ruolo corrispondenti contenute nel file di configurazione della sessione quando immettono una sessione JEA. JEA tenta di assegnare 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 parametri e i valori di parametro limitati in JEA.
Di seguito vengono definite le regole:
- Se un cmdlet viene reso visibile solo in un ruolo, è visibile all'utente con eventuali vincoli di parametro applicabili.
- Se un cmdlet viene reso visibile in più di un ruolo e ogni ruolo ha gli stessi vincoli sul cmdlet, il cmdlet sarà visibile all'utente con tali vincoli.
- Se un cmdlet viene reso visibile in più di un ruolo e ogni ruolo consente un set diverso di parametri, il cmdlet e tutti i parametri definiti in ogni ruolo saranno visibili all'utente. Se un ruolo non ha vincoli sui parametri, tutti i parametri saranno consentiti.
- 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.
- Se viene definito un set di convalida per lo stesso parametro del cmdlet in più di un ruolo, saranno consentiti tutti i valori da tutti i set di convalida.
- Se viene definito un modello di convalida per lo stesso parametro del cmdlet in più di un ruolo, saranno consentiti tutti i valori che corrispondono ai modelli.
- Se viene definito un set di convalida in uno o più ruoli e un modello di convalida è definito in un altro ruolo per lo stesso parametro del cmdlet, il set di convalida viene ignorato e si applica la regola (6) 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'
}
}
)
}
VisibleExternalCommands, VisibleAliases, VisibleProviders, ScriptsToProcess
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 sarà disponibile per l'utente JEA.
Accertarsi che il set combinato di provider da una funzionalità del ruolo e i cmdlet/funzioni/comandi da un'altra funzionalità non consentano agli utenti di accedere non intenzionalmente alle risorse di sistema.
Ad esempio, se un ruolo consente l'uso del cmdlet Remove-Item e un altro il provider FileSystem, c'è il rischio che un utente JEA possa eliminare file arbitrari nel computer. Altre informazioni sull'identificazione delle autorizzazioni effettive degli utenti sono disponibili nell'articolo Controllo in JEA.
