Considerazioni sulla sicurezza JEA

JEA consente di migliorare il comportamento 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 per consentire agli utenti di gestire il sistema. Agli utenti che necessitano di privilegi elevati, ma non illimitati, l'accesso al computer per eseguire attività amministrative può essere concesso 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 Run-As

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 della sessione e l'account scelto ha un impatto significativo sulla sicurezza dell'endpoint.

Gli account virtuali sono il modo consigliato per configurare l'account run-as . Gli account virtuali sono account locali temporanei creati per consentire all'utente di connettersi di usarli durante la durata della sessione JEA. Non appena la sessione viene terminata, l'account virtuale viene eliminato definitivamente e non può più essere usato. L'utente che si connette non conosce le credenziali per l'account virtuale. L'account virtuale non può essere usato per accedere al sistema tramite altri mezzi, ad esempio Desktop remoto o un endpoint di PowerShell non vincolato.

Per impostazione predefinita, gli account virtuali sono membri del gruppo Administrators 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 sono un caso speciale perché non esiste un gruppo Administrators locale. Gli account virtuali appartengono invece a Domain Admins e possono gestire i servizi directory nel controller di dominio. L'identità del dominio è ancora limitata per l'utilizzo sul controller di dominio dove è stata avviata la sessione JEA. L'accesso alla rete sembra invece provenire dall'oggetto computer del 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 su workstation e server membri. Nei controller di dominio gli account virtuali devono essere membri dei gruppi di sicurezza di 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 riepiloga le possibili opzioni di configurazione e le autorizzazioni risultanti per gli account virtuali:

Tipo di computer	Configurazione del gruppo di account virtuali	Contesto utente locale	Contesto utente di rete
Controller di dominio	Valore predefinito	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
Il server membro o la workstation	Valore predefinito	Utente locale, membro di BUILTIN\Administrators	Account del computer
Il server membro o la workstation	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 tenere traccia delle azioni dell'utente in un endpoint JEA fino a ritornare all'utente originale che ha eseguito il comando. I nomi degli account virtuali seguono il formato WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> Ad esempio, se l'utente Alice nel dominio Contoso riavvia un servizio in un endpoint JEA, il nome utente associato a qualsiasi evento di Gestione controllo dei servizi sarà WinRM Virtual Users\WinRM_VA_1_contoso_alice.

Gli account del servizio gestiti dal gruppo sono utili quando un server membro deve avere accesso alle risorse di rete nella sessione JEA. Ad esempio, quando un endpoint JEA viene usato per controllare l'accesso a un servizio API REST ospitato in un computer diverso. È facile scrivere funzioni per richiamare le API REST, ma è necessaria un'identità di rete per l'autenticazione con l'API. L'uso di un account del servizio gestito dal gruppo rende possibile il secondo hop mantenendo il controllo sui computer che possono usare l'account. Le appartenenze dei gruppi di sicurezza (locali o di dominio) del gMSA definiscono le autorizzazioni effettive per l'account gMSA.

Quando un endpoint JEA è configurato per utilizzare un gMSA, le azioni di tutti gli utenti JEA sembrano essere effettuate dallo stesso gMSA. L'unico modo per tracciare le azioni a un utente specifico consiste nell'identificare il set di comandi eseguiti in una trascrizione di sessione di PowerShell.

Le credenziali pass-through vengono utilizzate quando non si specifica un account run-as. PowerShell usa le credenziali dell'utente che si connette 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 run-as standard consentono di specificare qualsiasi account utente in cui viene eseguita l'intera sessione di PowerShell. Le configurazioni di sessione che usano account run-as fissi (con il -RunAsCredential parametro ) non sono in grado di supportare JEA. Le definizioni di ruolo non funzionano più come previsto. A ogni utente autorizzato ad accedere all'endpoint viene assegnato lo stesso ruolo.

Non è consigliabile usare RunAsCredential in un endpoint JEA perché è difficile tracciare le azioni a utenti specifici e non supporta il mapping degli utenti ai ruoli.

ACL dell'endpoint WinRM

Come per i normali endpoint remoti di PowerShell, ogni endpoint JEA ha un elenco di controllo di accesso separato (ACL) che controlla chi può 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 sulla mappatura degli utenti ai ruoli JEA. Il mapping è controllato dal campo RoleDefinitions nel file di configurazione della sessione usato per registrare l'endpoint.

Per impostazione predefinita, quando un endpoint JEA ha più funzionalità di ruolo, l'ACL WinRM è configurato per consentire l'accesso a tutti gli utenti mappati. 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 gli utenti che hanno accesso, 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 almeno richiamare i diritti per accedere all'endpoint JEA.

È possibile creare un endpoint JEA che non associa un ruolo definito a ogni utente che ha accesso. Questi utenti possono avviare una sessione JEA, ma hanno accesso solo ai cmdlet predefiniti. È possibile controllare le autorizzazioni utente 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 di servizio virtuali e gestiti da gruppi in esecuzione in background possono avere accesso illimitato al computer locale. Le funzionalità del ruolo JEA consentono di limitare i comandi e le applicazioni che possono essere eseguiti in tale contesto con privilegi. I ruoli progettati in modo non corretto possono consentire comandi pericolosi che possono consentire a un utente di uscire dai limiti JEA o di ottenere l'accesso alle informazioni riservate.

Si consideri ad esempio la seguente voce di funzionalità del ruolo:

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

Questa funzionalità del ruolo consente agli utenti di eseguire qualsiasi cmdlet di PowerShell con il sostantivo Process del modulo Microsoft.PowerShell.Management . Gli utenti potrebbero dover accedere ai cmdlet come Get-Process per vedere quali applicazioni sono in esecuzione nel sistema e Stop-Process per terminare le applicazioni che non rispondono. Tuttavia, anche questa voce consente Start-Process, che può essere usata per avviare un programma arbitrario con autorizzazioni di amministratore completo. Il programma non deve essere 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.

Una versione più sicura di questa stessa funzionalità del ruolo sarà simile alla seguente:

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

Evitare di usare caratteri jolly nelle funzionalità del 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 generazione di report su JEA.

Raccomandazioni sulle migliori pratiche

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.

Avvertimento

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

Non autorizzare il provider di certificato. 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.

Avvertimento

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

Non consentire questo Trace-Command cmdlet.

Avvertimento

L'uso di Trace-Command 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 protegge dagli amministratori

Uno dei principi fondamentali di JEA è che consente ai non amministratori di eseguire alcune attività amministrative. JEA non protegge dagli utenti che hanno già privilegi di amministratore. Gli utenti che appartengono a Domain Admins, amministratori locali o altri gruppi con privilegi elevati possono aggirare le protezioni di JEA in altri modi. Ad esempio, possono accedere con RDP, usare console MMC remote o connettersi a 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 utilizzare JEA per la normale manutenzione quotidiana, è comune disporre di un sistema di gestione degli accessi con privilegi just-in-time. 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.