Securing Active Directory

Active Directory costituisce tuttora lo scrigno dove vengono depositate le chiavi del regno; in AD risiedono le identità degli utenti e le identità dei Domain Admins. Controllare active directory permette di controllare l’accesso all’insieme delle risorse aziendali e di conseguenza ai dati aziendali; per questo è necessario “securing active directory”.

E’ evidente l’importanza di proteggere active directory, anche in ottica di smartworking e modern workplace.

Lo scorso 3 novembre 2020 ho partecipato al Be Connected Day (BeConnected day | Italy | BeConnectedDay.it) ed ho tenuto una sessione relativa alla protezione di AD, Securing Active Directory per l’appunto.

Nella sessione, di carattere introduttivo all’argomento, parlo della necessità di assumere un’ottica di Zero Trust e come questa motivi una necessaria mindset modification in termini di approccio al tema della sicurezza informatica.

Le best practice in termini di sicurezza di AD impongono un approccio basato su tiering, ovvero non semplicemente separazione dei ruoli amministrativi ma anche segmentazione di AD secondo aree di maggiore o minore protezione, senza possibilità di accedere da una zona all’altra salvo necessità.

Nel video viene mostrata con quale facilità (disarmante) un attaccante può compromettere le difese ed ottenere rapidamente i privilegi di domain admin se non vengono rispettate le best practice (una volta compromesso un utente dell’organizzazione); c’è una demo, breve ma efficace, che spiega come sia possibile, con strumenti di hacking alla portata di tutti (nel video viene mostrato l’utilizzo di Mimikatz per accedere a LSASS, ottenere l’hash della password di un domain admin ed utilizzare la tecnica Pass-the-Hash per accedere ad un domain controller con i privilegi di domain admin).

Per riassumere quanto spiegato nel video dal punto di vista delle best practice di “securing active directory”:

• è necessario assumere il clean source principle, secondo cui tutti gli elementi della catena di protezione devono avere lo stesso livello di protezione dell’elemento da proteggere
• è necessario segmentare AD in livelli di protezione (tiers) ed ogni livello potrà essere acceduto soltanto da workstation sicure (ovvero, secondo il clean source principle, con lo stesso livello di protezione degli elementi da proteggere)
  • tipicamente si costituiscono 3 livelli (tier0, tier1 e tier2)
  • nessun accesso può essere fatto da tier0 verso gli altri livelli (nel video capirete perchè), mentre il contrario è sempre possibile (una workstation in tier2 deve accedere ad un DC in tier0 per autenticarsi; il domain controller è lì per quello!)
  • da quanto sopra ne consegue un principio determinante, ovvero No Cross Boundaries, ovvero è necessario utilizzare le utenze e le worksation ammnistrative (vedi sotto) soltanto nel livello di protezione appropriato
  • tier0 controlla tutti gli altri livelli, ma i livelli inferiori non possono controllare i livelli superiori
• è necessario separare le utenze amministrative dalle utenze per daily operations (questo lo state sicuramente già facendo)
  • ma è anche necessario separare differenti utenze ammninistrative, secondo il tier di appartenenza (ad esempio potrei avere un’utenza domain admin per amministrare tier0 MA se dovessi amministrare anche un server SQL DOVREI avere anche un amministratore tier1)
• è necessario separare le workstation per daily operations dalle workstation amministrative (e dotarsi di una workstation ammministrativa per ogni tier da amministrare)
  • queste workstation amministrative sono le Privileged Administrative Workstation (ulteriori dettagli nel video)

Tralascio di parlare della Red Forest, appena accennata nel video ed estremamente complicata da implementare (ora neppure più best practice).

Di seguito i link al video ed al PDF presentato nell’evento:

https://yooda.sharepoint.com/:b:/s/YoodaInternetPortal/EY-vybkbsoJPnO1ujtVALSIBR2QhDPqmqFqXMVwTBSnSMw?e=PbNS1a