Qual è il miglior modo pratico per proteggere i nostri amministratori IT?

Sono d'accordo e vorrei ampliare la risposta di Odo. So che per la nostra organizzazione l'idea di un PAW dedicato è stata grande, ma la praticità di implementarne una basata su linee guida STIG attuali non era presente. Soprattutto per le PMI, avere una VLAN di accesso dedicata con quella macchina con account amministrativi specifici è un po 'più di quanto la maggior parte possa gestire. Abbiamo finito per implementare un ambiente simile a quanto suggerito da odo. Abbiamo più amministratori che eseguono varie attività su più siti, e quindi il vettore di minaccia per qualcuno per ottenere l'accesso amministrativo ai nostri DC è stato significativo. Penso che troverai comunque se consideri davvero i tuoi ruoli, ci sono solo una manciata di amministratori che in realtà richiedono autorizzazioni di dominio completo per i tuoi DC. Abbiamo finito per creare (per mancanza di una parola migliore) un gruppo di amministrazione di elevazione che i nostri amministratori IT giornalieri usavano sulle workstation quotidiane. Questi account non hanno privilegi amministrativi sui server e sono stati effettivamente negati i privilegi di accesso tramite oggetti Criteri di gruppo. A causa delle restrizioni nel nostro ambiente, non siamo in grado di utilizzare alcun dispositivo mobile nel nostro edificio e non abbiamo il budget per i token, quindi l'AMF non era realmente un'opzione. Abbiamo finito per utilizzare gli oggetti Criteri di gruppo di Servizi terminal (penso che ora siano chiamati RDS) per consentire o negare l'accesso remoto agli account in base al loro livello di privilegio. Ad esempio, gli amministratori elevati non sono in grado di accedere da remoto a nessuna workstation e gli amministratori di dominio non sono in grado di accedere da remoto a nessun server (si dovrebbe anche menzionare che qualsiasi membro di DA / EA viene negato dal login sulle workstation di tutti i giorni). Ciò aiuta in modo significativo a impedire a un utente malintenzionato di rubare credenziali utilizzate quotidianamente e provocare il caos sul sistema. Ci sono alcune linee guida piuttosto utili su questo da un certo numero di fonti diverse, io (noi) generalmente usiamo i modelli STIG per creare la nostra linea di base. Alcuni importanti da notare quale tocco sopra sono Deny Log on per account di dominio altamente privilegiati ( V-63877 ) e negare l'accesso tramite RDS per account di dominio con privilegi elevati ( V-63879 ). I tuoi amministratori dovrebbero elevare un prompt UAC utilizzando i loro account con privilegi, ma garantisce che se il loro laptop o workstation è suddiviso, l'hacker necessiterà di più set di credenziali per realizzare qualsiasi cosa.

L'uso di un server VDI / Jump non è un'idea così terribile, è una tecnica piuttosto comune - se si imposta con una sorta di autenticazione a più fattori (che non è sul laptop), allora almeno una compromessa il laptop non può semplicemente connettersi alla tua rete di gestione.

Separerei gli account operativi meno privilegiati degli amministratori delegati (per le attività quotidiane) da account con privilegi più elevati come domini / admin di database (che vengono utilizzati durante le modifiche nell'architettura di dominio / database - attività molto più rari).

Sì, potrebbe richiedere la regolazione fine, i ruoli personalizzati e così via, ma durante il processo capirai meglio il tuo panorama relativo all'RBAC.

Per la maggior parte degli account privilegiati raccomanderei password condivise (cioè metà della password memorizzata in warbox) combinata con 2FA.