Considerazioni sulla sicurezza in JEA

JEA consente di migliorare le condizioni di sicurezza, riducendo il numero di amministratori permanenti nei computer. JEA usa una configurazione di sessione di PowerShell per creare un nuovo punto di ingresso che consente agli utenti di gestire il sistema. Agli utenti che richiedono un livello di accesso al computer elevato ma non illimitato per eseguire attività amministrative è possibile concedere l'accesso all'endpoint JEA. Poiché JEA consente a questi utenti di eseguire comandi amministrativi senza avere accesso amministratore completo, è quindi possibile rimuovere tali utenti da gruppi di sicurezza con privilegi elevati.

Account Esegui come

Ogni endpoint JEA ha un account run-as designato con cui vengono eseguite le azioni dell'utente che si connette. Questo account è configurabile nel file di configurazione sessione, e l'account scelto ha un impatto significativo sulla sicurezza dell'endpoint.

Gli account virtuali sono il metodo consigliato per configurare l'account Esegui come. Gli account virtuali sono account locali temporanei creati per l'utente che si connette e possono essere usati solo per la durata della sessione JEA. Al termine della sessione l'account virtuale viene eliminato e non può più essere usato. L'utente che si connette non conosce le credenziali dell'account virtuale. L'account virtuale non può essere usato per accedere al sistema con altri mezzi, come Desktop remoto o un endpoint di PowerShell non vincolato.

Per impostazione predefinita, gli account virtuali sono membri del gruppo Amministrazione istrators locale nel computer. Questa appartenenza concede loro diritti completi per gestire qualsiasi elemento nel sistema, ma non diritti per gestire le risorse nella rete. Quando l'utente si connette ad altri computer dalla sessione JEA, il contesto utente è quello dell'account del computer locale, non dell'account virtuale.

I controller di dominio rappresentano un caso speciale, perché non è presente un gruppo Administrators. Gli account virtuali appartengono invece al gruppo Domain Admins e possono gestire i servizi directory nel controller di dominio. L'uso dell'identità del dominio resta limitato al controller di dominio in cui è stata creata la sessione JEA. Qualsiasi accesso alla rete sembra provenire dall'oggetto computer controller di dominio.

In entrambi i casi, è possibile assegnare l'account virtuale a gruppi di sicurezza specifici, soprattutto quando l'attività può essere eseguita senza privilegi di amministratore locale o di dominio. Se è già stato definito un gruppo di sicurezza per gli amministratori, concedere l'appartenenza all'account virtuale a tale gruppo. L'appartenenza a gruppi per gli account virtuali è limitata ai gruppi di sicurezza locali nei server workstation e membri. Nei controller di dominio gli account virtuali devono essere membri di gruppi di sicurezza del dominio. Dopo aver aggiunto l'account virtuale a uno o più gruppi di sicurezza, non appartiene più ai gruppi predefiniti (amministratori locali o di dominio).

La tabella seguente illustra le opzioni di configurazione possibili e le autorizzazioni risultanti per gli account virtuali:

Tipo di computer	Configurazione del gruppo di account virtuali	Contesto dell'utente locale	Contesto dell'utente di rete
Controller di dominio	Default	Utente di dominio, membro di <DOMAIN>\Domain Admins	Account del computer
Controller di dominio	Gruppi di dominio A e B	Utente di dominio, membro di <DOMAIN>\A, <DOMAIN>\B	Account del computer
Workstation o server membro	Default	Utente locale, membro di BUILTIN\Administrators	Account del computer
Workstation o server membro	Gruppi locali C e D	Utente locale, membro di <COMPUTER>\C e <COMPUTER>\D	Account del computer

Quando si esaminano i registri eventi di controllo della sicurezza e dell'applicazione, si noterà che ogni sessione utente JEA ha un account virtuale univoco. Questo account univoco consente di far risalire le azioni dell'utente in un endpoint JEA all'utente originale che ha eseguito il comando. I nomi degli account virtuali hanno il formato WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName>. Se ad esempio l'utente Alice del dominio Contoso riavvia un servizio in un endpoint JEA, il nome utente associato a eventi di gestione del controllo del servizio sarà WinRM Virtual Users\WinRM_VA_1_contoso_alice.

Gli account del servizio gestito del gruppo (gMSA) sono utili quando un server membro deve accedere alle risorse di rete nella sessione JEA. Un esempio è il caso in cui l'endpoint JEA viene usato per controllare l'accesso a un'API REST ospitata in un altro computer. È facile scrivere funzioni per chiamare le API REST, ma per l'autenticazione nell'API è necessaria un'identità di rete. L'uso di un account del servizio gestito del gruppo rende possibile il secondo hop, consentendo di mantenere il controllo sui computer che possono usare l'account. Le appartenenze al gruppo di sicurezza (locale o dominio) dell'account del servizio gestito del gruppo hanno definito le autorizzazioni valide per l'account del servizio gestito del gruppo.

Quando un endpoint JEA è configurato per usare un account gMSA, le azioni di tutti gli utenti JEA vengono registrate come se provenissero dallo stesso account del servizio gestito. L'unico modo per far risalire determinate azioni a un utente specifico è l'identificazione del set di comandi eseguiti in una trascrizione della sessione di PowerShell.

Le credenziali pass-through vengono usate quando non si specifica un account run-as . PowerShell usa le credenziali dell'utente connesso per eseguire comandi nel server remoto. Per usare le credenziali pass-through, è necessario concedere all'utente che si connette l'accesso diretto ai gruppi di gestione con privilegi. Questa configurazione non è consigliata per JEA. Se l'utente che si connette dispone già di privilegi di amministratore, può ignorare JEA e gestire il sistema usando altri metodi di accesso.

Gli account Esegui come standard consentono di specificare qualsiasi account utente in cui verrà eseguita l'intera sessione di PowerShell. Le configurazioni di sessione che usano account Esegui come fissi (con il parametro -RunAsCredential) non supportano JEA. Le definizioni del ruolo smettono di funzionare come previsto. Viene assegnato lo stesso ruolo a tutti gli utenti autorizzati ad accedere all'endpoint.

È consigliabile non usare RunAsCredential su un endpoint JEA perché rende difficile attribuire azioni a utenti specifici e per la mancanza di supporto per il mapping degli utenti ai ruoli.

ACL endpoint di WinRM

Come per i normali endpoint di comunicazione remota di PowerShell, ogni endpoint JEA ha un elenco di controllo di accesso (ACL) separato che controlla gli utenti che possono eseguire l'autenticazione con l'endpoint JEA. Se configurato in modo non corretto, gli utenti attendibili potrebbero non essere in grado di accedere all'endpoint JEA e gli utenti non attendibili potrebbero avere accesso. L'ACL WinRM non influisce sul mapping degli utenti ai ruoli JEA. Questo mapping è controllato dal campo RoleDefinitions nel file di configurazione sessione usato per registrare l'endpoint.

Per impostazione predefinita, quando un endpoint JEA ha più funzionalità di ruolo, l'elenco di controllo di accesso WinRM è configurato per consentire l'accesso a tutti gli utenti con mapping. Ad esempio, una sessione JEA configurata usando i comandi seguenti concede l'accesso completo a CONTOSO\JEA_Lev1 e CONTOSO\JEA_Lev2.

$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

È possibile controllare le autorizzazioni utente con il cmdlet Get-PSSessionConfiguration.

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

Per modificare l'accesso degli utenti, eseguire Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI per un prompt interattivo o Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> per aggiornare le autorizzazioni. Gli utenti devono avere almeno i diritti di chiamata per accedere all'endpoint JEA.

È possibile creare un endpoint JEA che non esegue il mapping di un ruolo definito a ogni utente che esegue l'accesso. Questi utenti possono avviare una sessione JEA, ma dispongono solo dell'accesso ai cmdlet predefiniti. È possibile controllare le autorizzazioni degli utenti in un endpoint JEA eseguendo Get-PSSessionCapability. Per altre informazioni, vedere Controllo e creazione di report in JEA.

Ruoli con privilegi minimi

Quando si progettano ruoli JEA è importante ricordare che gli account virtuale e del servizio gestito del gruppo eseguiti in background possono avere accesso illimitato alla gestione del computer locale. Le funzionalità di ruolo JEA consentono di limitare i comandi e le applicazioni eseguibili in tale contesto con privilegi. I ruoli progettati in modo non corretto possono consentire l'esecuzione di comandi pericolosi, che potrebbero permettere a un utente di oltrepassare i limiti JEA o di ottenere l'accesso a informazioni riservate.

Ad esempio, prendere in considerazione la voce relativa alla funzionalità di ruolo seguente:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

Questa funzionalità di ruolo consente agli utenti di eseguire qualsiasi cmdlet di PowerShell con il termine Process dal modulo Microsoft.PowerShell.Management. Gli utenti possono avere l'esigenza di accedere a cmdlet specifici, ad esempio Get-Process per identificare le applicazioni in esecuzione nel sistema e Stop-Process per terminare le applicazioni che non rispondono. Questa voce consente anche il cmdlet Start-Process, che può essere usato per avviare un programma arbitrario con autorizzazioni complete di amministratore. Non è necessario che il programma sia installato localmente nel sistema. Un utente connesso potrebbe avviare un programma da una condivisione file che concede all'utente privilegi di amministratore locale, esegue malware e altro ancora.

Di seguito viene illustrata una versione più sicura della stessa funzionalità di ruolo:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

Evitare di usare i caratteri jolly nelle funzionalità di ruolo. Assicurarsi di controllare regolarmente le autorizzazioni utente valide per vedere quali comandi sono accessibili a un utente. Per altre informazioni, vedere la sezione Controllare i diritti effettivi dell'articolo Controllo e creazione di report su JEA .

Indicazioni sulle procedure consigliate

Di seguito sono riportati i consigli sulle procedure consigliate per garantire la sicurezza degli endpoint JEA:

Limitare l'uso e le funzionalità dei provider di PowerShell

Esaminare il modo in cui vengono usati i provider consentiti per assicurarsi di non creare vulnerabilità nella sessione configurata.

Avviso

Non consentire il provider FileSystem . Se gli utenti possono scrivere in qualsiasi parte del file system, è possibile ignorare completamente la sicurezza.

Non consentire il provider di certificati . Con il provider abilitato, un utente potrebbe ottenere l'accesso alle chiavi private archiviate.

Non consentire comandi in grado di creare nuovi spazi di esecuzione.

Avviso

I *-Job cmdlet possono creare nuovi spazi di esecuzione senza restrizioni.

Non consentire il Trace-Command cmdlet.

Avviso

L'uso Trace-Command di porta tutti i comandi tracciati nella sessione.

Non creare implementazioni proxy personalizzate per i comandi con restrizioni.

PowerShell include un set di comandi proxy per scenari di comandi con restrizioni. Questi comandi proxy assicurano che i parametri di input non possano compromettere la sicurezza della sessione. I comandi seguenti hanno proxy con restrizioni:

• Exit-PSSession
• Get-Command
• Get-FormatData
• Get-Help
• Measure-Object
• Out-Default
• Select-Object

Se si crea una propria implementazione di questi comandi, è possibile consentire inavvertitamente agli utenti di eseguire codice vietato dai comandi proxy JEA.

JEA non offre protezione dagli amministratori

Uno dei principi fondamentali di JEA è che consente ai non amministratori di eseguire alcune attività amministrative. JEA non offre protezione dagli utenti che hanno già privilegi di amministratore. Gli utenti che appartengono a domain Amministrazione, Amministrazione istrators locali o altri gruppi con privilegi elevati possono aggirare le protezioni di JEA in altri modi. Ad esempio un utente può accedere con RDP, usare console MMC remote o connettersi agli endpoint di PowerShell non vincolati. Inoltre, l'amministratore locale in un sistema può modificare le configurazioni JEA per aggiungere altri utenti o modificare una funzionalità del ruolo per estendere l'ambito delle operazioni che un utente può eseguire nella sessione JEA. È importante valutare le autorizzazioni estese degli utenti JEA, per verificare se esistono altri modi per ottenere l'accesso con privilegi al sistema.

Oltre a usare JEA per la normale manutenzione quotidiana, è comune avere un sistema di gestione degli accessi con privilegi JIT. Questi sistemi consentono agli utenti designati di diventare temporaneamente un amministratore locale solo dopo aver completato un flusso di lavoro che documenta l'uso di tali autorizzazioni.