Rischi della delegazione di Kerberos

Ho passato ore e ore a cercare di imparare e comprendere l'autenticazione di Windows, Kerberos, SPN e la delega vincolata in IIS 7.5. Una cosa che non capisco è perché è "rischioso" lasciare abilitata la delega (cioè non disabilitare la delega per account sensibili) per amministratori, amministratori delegati, ecc. Qualcuno può spiegarmelo in termini semplici? Inquadra la tua risposta rispetto a un ambiente intranet.

Il mio ragionamento è che non dovrebbe essere un problema, perché la delega consente semplicemente a un server Web front-end, ad esempio, di agire per conto della persona autenticata da Windows quando comunica con altri server. Se la persona ha accesso, ha accesso, non capisco perché questo dovrebbe essere un problema.

Per favore, perdona la mia ignoranza. Sono principalmente uno sviluppatore, ma la mia azienda è molto snella in questi giorni e sono costretta a indossare anche il cappello dell'amministratore del server ... sfortunatamente, non si adatta molto bene, lol.

Due esempi:

1. La delega vincolata consente la rappresentazione senza le credenziali dell'utente o il token di autenticazione. Per un esempio, vedi questa risposta .

2. In uno scenario di delega non vincolata più tipico a base di carne e patate, sia che si tratti dell'autenticazione integrata di Windows o dell'autenticazione dei moduli, avere l' accesso di delega al token di autenticazione di un utente è molto potente. Ciò significa letteralmente che il token può essere utilizzato per rappresentare quell'utente per accedere a qualsiasi risorsa di rete. Chiunque sia coinvolto in quel processo, come uno sviluppatore, potrebbe usarlo in modo nefasto per ottenere accessi non autorizzati.

In entrambi gli esempi, se la casella è selezionata per "l'account è sensibile e non può essere delegato", questi non sono problemi di sicurezza. È anche possibile progettare un sistema / funzionalità in cui tali capacità esistono, ma sono strettamente controllate.

Quella casella dovrebbe essere selezionata per gli account amministrativi, come i membri del gruppo Enterprise Admins, perché (si spera) questi account raramente devono usare applicazioni che richiedono la rappresentazione. È anche una buona idea per i dirigenti senior che hanno accesso a informazioni riservate, come un CIO, un COO, un responsabile delle finanze / tesoreria, ecc.

Quindi la linea di fondo è che Microsoft ha fornito quella casella di controllo e l'avvertimento di accompagnamento per una ragione molto buona, e non dovrebbe essere ignorata o presa alla leggera a meno che non si possa dimostrare che un particolare scenario non ha un'esposizione al rischio indesiderata o un controllo compensativo. Questo di solito comporta il controllo da parte di alcune persone qualificate che non sono coinvolte nell'attuazione o nello sviluppo effettivo di un'applicazione o di un sistema.

Ho installato migliaia di clienti con delega la maggior parte dei non vincolati. Penso che sia importante notare che se non ti fidi della tua applicazione (diciamo distribuito su IIS) o stai dando le credenziali del nostro account di servizio delegato affinché gli altri possano usarlo liberamente, allora la delega vincolata è probabilmente una buona idea. Tuttavia, se non ti aspetti che nessuno abbia la possibilità di riscrivere la tua applicazione, mantieni al sicuro le credenziali del tuo account di servizio e ritieni che le tue app delegheranno solo ai servizi per cui sono state progettate, quindi lì di solito non c'è nulla di cui preoccuparsi. Ho visto alcuni clienti "attenti alla sicurezza" concentrarsi molto su questioni come questa mentre le loro risorse potevano essere impiegate meglio lavorando su minacce alla sicurezza reali ...