Assegnazione sicura delle autorizzazioni amministrative locali

6

Ho svolto ricerche sul metodo migliore per garantire in modo sicuro le autorizzazioni amministrative locali, ma mi sto davvero sforzando di conciliare le implicazioni di sicurezza, operative e di costo.

Ho ideato alcune opzioni:

  1. Crea un gruppo di sicurezza del dominio ( PC Admins ), aggiungi gli account utente di dominio richiesti e utilizza i Criteri di gruppo per aggiungere il gruppo di sicurezza del dominio al gruppo di sicurezza locale Administrators :
    • Pro:
      • centralmente gestiti.
      • verificabili.
      • Libero.
    • Contro:
      • Vulnerabile a furto di credenziali e attacchi di movimento laterale.
  2. Opzione n. 1 ma utilizzando account utente di dominio separati ( <original username>.admin ):
    • Pro: uguale a # 1
    • Contro: come il numero 1. L'autenticazione di un prompt UAC crea una cache di accesso che può essere sfruttata.
  3. Opzione n. 1 ma disabilitazione degli accessi memorizzati nella cache:
    • Pro:
      • centralmente gestiti.
      • verificabili.
      • Libero.
      • Non è vulnerabile alle furti di credenziali e agli attacchi di spostamento laterale in quanto non ci sono cache di accesso da sfruttare, ma le credenziali possono comunque essere acquisite con altri mezzi (keylogger, ecc.).
    • Contro:
      • Gli utenti non potranno accedere se c'è un problema con il dominio, c'è un problema con la connettività di rete, il PC è fuori sede, ecc.
  4. Distribuisci Microsoft LAPS e invii gli utenti con le credenziali di amministratore locale univoche:
    • Pro:
      • centralmente gestiti.
      • Non vulnerabile agli attacchi di furto di credenziali e di movimenti laterali.
      • Libero.
    • Contro:
      • non verificabile.
      • L'account utente amministrativo predefinito è un obiettivo facile.
  5. Aggiungi gli account utente di dominio richiesti al gruppo di sicurezza locale Administrators :
    • Pro:
      • Auditabile (in parte).
      • Non vulnerabile alle furti di credenziali e agli attacchi di spostamento laterale.
      • Libero.
    • Contro:
      • Non gestito centralmente.
  6. Implementa il MFA:
    • Pro:
      • centralmente gestiti.
      • verificabili.
    • Contro:
      • Non libero.
      • Ancora vulnerabili agli attacchi di furto di credenziali e di movimenti laterali (secondo link ).
  7. Implementare un sistema che utilizza i TOTP e / o solo temporaneamente concede le autorizzazioni amministrative come e quando necessario:
    • Pro:
      • centralmente gestiti.
      • verificabili.
      • Non vulnerabile agli attacchi di furto di credenziali e di movimento laterale?
    • Contro:
      • Non libero.

Esiste una best practice generale?

Non posso fare a meno di avere la sensazione che non ci sia una risposta tecnologica corretta e che questi rischi siano mitigati semplicemente cercando di garantire che nessuno possa o voglia (1) utilizzare un account utente amministrativo in un giorno giorno o (2) eseguire malware.

    
posta mythofechelon 14.11.2017 - 15:11
fonte

2 risposte

2

Usa utenti protetti

Quando un utente accede a una macchina Windows con il protocollo NTLM, il suo hash viene memorizzato nella memoria nel processo LSASS. Un utente malintenzionato può scaricare questa memoria per rubare queste credenziali.

Per ovviare a questo problema, una buona soluzione sta forzando l'autenticazione Kerberos per gli amministratori e mettendo al bando le credenziali in chiaro. Puoi farlo con un meccanismo chiamato utenti protetti.

/! \ È necessario Windows Server 2012 R2 per creare il gruppo di protezione Utenti protetti e gli host devono eseguire Windows 8.1 o versioni successive per fornire restrizioni lato client per gli utenti protetti.

Quando un account è membro di un utente protetto:

    La delega delle credenziali predefinite
  • e il digest di Windows (credenziali in chiaro) non vengono memorizzate nella cache anche se è abilitato il criterio Consenti di delegare le credenziali predefinite
  • L'hash NTLM non è memorizzato nella cache
  • La configurazione di Kerberos è migliorata
  • Sign-on offline (il verificatore di accesso memorizzato nella cache) non viene creato

La tua prima opzione è quella giusta

Create a domain security group (PC Admins), add the required domain user accounts, and use Group Policy to add the domain security group to the local security group Administrators.

Questo è esattamente quello che devi fare. E il tuo gruppo PC Admins sarà un membro del gruppo Protected Users.

Opzioni non valide

Deploy Microsoft LAPS

LAPS gestisce automaticamente la password di rid 500 (amministratore locale) sui computer aggiunti al dominio, quindi la password è:

  • univoco su ciascun computer gestito
  • generato in modo casuale
  • memorizzati nell'infrastruttura AD esistente

Tuttavia, gli account amministratore locali non devono essere utilizzati per amministrare i computer sulla rete . In una Active Directory, questi account devono essere considerati come account di backup, in caso di perdita della connessione di rete. Quindi LAPS non si adatta alle tue esigenze.

Inoltre, è vulnerabile al furto di credenziali ma non agli attacchi laterali.

Implement a system that uses TOTPs and/or only temporarily grants administrative permissions as-and-when needed

Per gli stessi motivi dell'AMF, è ancora vulnerabile agli attacchi di furto di credenziali e di spostamento laterale.

    
risposta data 09.08.2018 - 11:01
fonte
0
  1. Per quanto ne so, gli accessi memorizzati nella cache per l'account di dominio non sono vulnerabili agli attacchi di furto di credenziali e di movimenti laterali.

Security of cached domain credentials The term cached credentials does not accurately describe how Windows caches logon information for domain logons. In Windows 2000 and in later versions of Windows, the username and password are not cached. Instead, the system stores an encrypted verifier of the password. This verifier is a salted MD4 hash that is computed two times. The double computation effectively makes the verifier a hash of the hash of the user password. This behavior is unlike the behavior of Microsoft Windows NT 4.0 and earlier versions of Windows NT.

link

  1. Ma hai ancora bisogno di un modo per gestire gli account degli amministratori locali. Puoi disabilitarli o usare LAPS. L'utilizzo della stessa password di amministratore locale su tutti i computer è vulnerabile agli attacchi di furto di credenziali e di spostamento laterale.

  2. Dal mio punto di vista, gli utenti del tuo dominio non dovrebbero avere privilegi di amministratore locale. Il personale IT dovrebbe disporre di account speciali che si trovano nel gruppo degli amministratori locali. Gli account degli amministratori locali dovrebbero avere password diverse.

risposta data 15.11.2017 - 06:28
fonte

Leggi altre domande sui tag