In ogni luogo in cui ho lavorato (come sviluppatore a contratto) agli sviluppatori vengono concessi diritti di amministratore locale sui loro desktop.

Le ragioni sono:

1) I set di strumenti degli sviluppatori vengono spesso aggiornati molto regolarmente. Librerie grafiche, helper del codice, aggiornamenti di Visual Studio; finiscono per avere aggiornamenti che escono quasi settimanalmente che devono essere installati. Il supporto desktop di solito si stanca di ricevere 20 ticket ogni settimana per installare software aggiornato su tutte le macchine di sviluppo in modo da dare agli sviluppatori i diritti di amministratore per farlo da soli.

2) A volte gli strumenti di debug / test hanno bisogno diritti di amministratore per poter funzionare. Nessun accesso amministratore significa che gli sviluppatori non possono eseguire il loro lavoro di debug del codice. Ai manager non piace.

3) Gli sviluppatori tendono ad essere più attenti alla sicurezza e quindi hanno meno probabilità di eseguire / installare malware pericolosi. Ovviamente, succede ancora, ma tutto sommato di solito ci si può fidare degli sviluppatori per avere un accesso di livello superiore per poter svolgere il proprio lavoro.

Questo dipende in parte dal tipo di software che il team di sviluppo dovrebbe sviluppare. Alcuni tipi di software sono più facili da sviluppare senza diritti amministrativi rispetto ad altri.

Ad esempio, puoi fare una discreta quantità di sviluppo Java basato sul web utilizzando artisti del calibro di Eclipse con artefatti Maven, tutti installati localmente (e tipicamente testato sulla porta 8080), senza bisogno di molti diritti di amministratore (potrebbe essere necessario aprire alcune porte). Lo sviluppo di strumenti che necessitano di un accesso più ravvicinato all'hardware può rivelarsi impossibile senza i diritti di amministratore Detto questo, anche per lo sviluppo web, è buona norma essere in grado di ricostruire una macchina di test da zero (tipicamente una VM), che potrebbe richiedere i diritti di amministratore .

Se si tratta di fiducia (cioè alcuni membri del tuo team di sviluppo potrebbero avere intenti dannosi), sei comunque nei guai. È improbabile che gli amministratori di sistema che approverebbero / disapproverebbero determinati diritti saranno in grado di controllare cosa fa il codice che hanno scritto nei dettagli. Ciò non significa né che dovresti dare al tuo team di sviluppo un accesso illimitato ai tuoi servizi di produzione, né quello dovrebbero avere accesso come amministratore su più macchine del necessario, ovviamente. È positivo disporre di meccanismi per mitigare i rischi, ma per il funzionamento dell'organizzazione è necessario un livello di fiducia di base. Mettere il team di sviluppo su una rete fisica separata è un primo passo per mitigare i problemi di fiducia e possibili errori.

Un rischio tipico di avere qualcuno con accesso amministratore è quello di essere in grado di catturare i pacchetti sulla rete. Questo è un rischio che potresti dover accettare a seconda della natura di ciò che è stato sviluppato. Strumenti come Wireshark possono essere utili per lo sviluppo a volte. Anche all'interno della tua organizzazione, le persone IT o non IT dovrebbero utilizzare i servizi con SSL / TLS abilitato, se possibile, questo dovrebbe aiutare contro le intercettazioni e gli attacchi MITM.

Posso pensare ad alcuni aspetti negativi quando non si fornisce agli sviluppatori l'amministratore accesso (a meno che non ne abbiano davvero bisogno):

• Potrebbe creare una cultura "loro contro noi" tra sviluppatori e amministratori di sistema nella tua organizzazione. Questo esiste già in molti posti, ma generalmente non è una buona cosa. È probabile che ogni squadra consideri l'altra come un dolore. La sicurezza non è un problema puramente tecnico, ma anche di interazione umana. Penso che una buona comunicazione umana dovrebbe aiutare gli obiettivi generali della tua organizzazione in generale, non solo dal punto di vista della sicurezza. (Ho sempre trovato di essere in grado di trovare soluzioni migliori dopo aver parlato di persona con gli amministratori di sistema con cui avevo bisogno di risolvere i problemi piuttosto che rispondere a un ticket senza volto.)

• La natura umana è tale che le persone diventano creative quando sono limitate, ma non necessariamente nel modo giusto. Potresti scoprire che gli sviluppatori finiscono per impegnarsi (e spesso riuscendo) a eludere i limiti loro imposti all'interno dell'organizzazione. Dovrebbero invece usare la loro creatività su ciò che dovrebbero fare.

• I sistemi IT sono complessi e il debugging è un'arte oscura. Se è necessario eseguire il debug del prodotto rispetto alla versione della libreria XYZ a.b.c_13 e a.b.c_24, gli sviluppatori potrebbero dover essere in grado di installare e disinstallare ciascuna versione, che a sua volta potrebbe richiedere l'accesso come amministratore. Inseguire bug che dipendono dai numeri di versione è già fastidioso così com'è. Se devi alzare un ticket e aspettare (forse ore o giorni) che qualcun altro installi / disinstalli la versione giusta, sarà un incubo: aumenterà il problema culturale "loro contro noi" e, soprattutto, costerà più all'organizzazione. Puoi pensare a questo da una prospettiva di valutazione del rischio / costo.

Il rischio è una funzione crescente dell'accesso

Esiste una semplice regola di calcolo del rischio che spiega la paura dei tuoi colleghi del team IT. Maggiore è l'accesso a qualsiasi sistema operativo maggiore è l'impatto di qualsiasi errore o attacco.
Ad esempio, se uno dei tuoi colleghi, diciamo Bob, viene attaccato tramite un attacco di phishing standard, l'account Bob è disponibile per i cyber -criminale e venduta su Internet in pochi minuti. Se l'account Bob ha privilegi di amministratore, questo account verrà utilizzato per inviare SPAM su larga scala su Internet, quindi per rubare altri account con attacchi di phishing su larga scala e molto rapidamente (in pochi minuti) aprirà una porta di servizio alla tua rete (questo è possibile perché l'account Bob è amministratore) consentendo un controllo remoto totale del PC di Bob (tramite strumenti come ssh , VNC , VPN ...). Questo attacco avviato da un PC interno, da un account privilegiato è in grado di rompere qualsiasi firewall, interrompere qualsiasi protezione antivirus e antispam.

Il male è dentro .

Anche i tuoi migliori amministratori di rete, amministratori di sistema o amministratori di sicurezza possono lasciare questo PC danneggiato senza essere scoperto per mesi (vedi Stuxnet ).

Falsa riduzione del rischio

Se i tuoi colleghi sviluppatori sono bravi a gestire il sistema operativo su cui lavorano e hanno un accesso fisico al computer, questa differenza di rischio è nulla.

Alcune cose che non sono state menzionate nelle risposte e nei commenti precedenti che sarebbero un argomento per gli sviluppatori che lavorano con il minimo privilegio:

1. A seconda del settore in cui stai lavorando , potrebbero esserci ragioni legali o normative che impediscono ai dipendenti di avere privilegi elevati sulle loro postazioni di lavoro. Consentire l'accesso amministrativo agli sviluppatori potrebbe mettere l'organizzazione a rischio di non conformità.

2. Quando i componenti vengono sviluppati con privilegi elevati, potrebbe esserci il rischio di errori durante la distribuzione ad altri ambienti che non dispongono di tali privilegi. Gli sviluppatori potrebbero aver inavvertitamente aggiornato o aggiunto alle loro macchine locali librerie che non esistono in altri ambienti e i componenti potrebbero avere dipendenze da versioni specifiche di tali librerie. Inoltre, gli account utente con i quali i componenti verranno eseguiti in altri ambienti potrebbero non disporre del database richiesto o di un altro accesso assunto dallo sviluppatore che lavora con privilegi elevati. L'ho visto accadere molte volte in passato. A volte è ovvio il motivo per cui la distribuzione non è riuscita, a volte no, e devi ripristinare tutto finché non riesci a capirlo.

3. Se gli sviluppatori installano strumenti o librerie open source e usano quelli per lo sviluppo, potrebbero esserci restrizioni di licenza involontarie su come il software che producono viene eventualmente distribuito, in particolare dove i termini "copyleft" fanno parte della licenza. Non c'è niente di sbagliato nell'usare strumenti o librerie open source, dovrebbe essere intenzionale. Non vuoi scoprire al momento della consegna che ora devi rilasciare tutto il tuo codice sorgente nella comunità perché i tuoi sviluppatori hanno utilizzato alcuni componenti open source che avevano termini rigorosi di copyleft nella licenza che non avevano letto prima di loro installato.

Qualcosa che ho visto fare è far lavorare gli sviluppatori con privilegi minimi, ma consentire loro di richiedere privilegi elevati per un periodo di tempo specificato. Quindi, questa richiesta di "chiamata antincendio" per privilegi elevati è stata registrata e monitorata e viene reimpostata automaticamente alla fine del tempo richiesto.

Gli dai i diritti di amministratore locale sulla loro workstation e su qualsiasi altra cosa desiderino. L'ambiente di sviluppo è sempre isolato dalla rete principale. È compito dell'IT assicurarti di fornire loro la configurazione di cui hanno bisogno, assicurandoti che nulla nell'ambiente di sviluppo possa danneggiare la rete principale. Pianifica in anticipo e collabora con la direzione per acquistare l'attrezzatura / il software di cui hai bisogno per farlo.

Hai alcune domande a cui rispondere.

1. Quali applicazioni devono utilizzare quotidianamente questi sviluppatori richiedono privilegi di amministratore ed esiste un modo per configurare queste applicazioni in modo che non sia così?
2. Per quali motivi questi sviluppatori necessitano dei privilegi di amministratore per svolgere attività quotidiane banali e c'è un modo per evitarlo?
3. Queste macchine per sviluppatori sono connesse a Internet?

La domanda non dovrebbe essere quali sono i rischi, la domanda dovrebbe essere (a cui puoi solo rispondere) quali sono le ragioni per cui gli sviluppatori devono anche avere un account amministratore. Puoi crearli con un account "power user" e dare loro la possibilità di fare esattamente ciò di cui hanno bisogno, ma anche limitare la loro capacità di danneggiare la tua rete.

Se queste macchine sono connesse a Internet. ... allora introdurrai una grande quantità di rischio a causa della loro capacità di eseguire qualsiasi cosa e installare qualsiasi cosa su queste macchine. Questi sviluppatori sono bravi sviluppatori, non sono esperti di sicurezza, è solo questione di QUANDO commetteranno un errore che espone la rete a malware.

Dai un'occhiata a Google per esempio. Un dipendente di Google fa clic su un collegamento contenuto in una finestra di MSN Messenger, ha scaricato un malware che ha sfruttato un exploit già corretto da Microsoft e ha infettato l'intera rete.

Devo aggiungere il dipendente di Google facendo clic su sul link non aveva nulla a che fare con questa domanda, era per sottolineare, le persone FARANNO un errore, quindi limita il tuo espositore.

I rischi per la sicurezza associati al fornire agli sviluppatori la possibilità di installare i propri computer sono numerosi. Ecco perché vorrei obiettare (parlando come amministratore di sistema)

1) Potenziale violazione delle migliori pratiche di sicurezza - Una delle 8 regole di sicurezza è la regola del privilegio minimo - solo dare ai dipendenti l'accesso a ciò di cui hanno bisogno per completare il loro compito. Se qualcuno mi dicesse che il loro sviluppatore ha bisogno dell'accesso amministrativo per installare il software per svolgere il proprio lavoro, allora risponderei con "Perché uno dei miei collaboratori non può installarlo per loro?". Avere un punto centralizzato per l'installazione del software garantisce che un reparto IT sappia esattamente quale software si trova su quale macchina.

2) Motivi legali - Forse uno dei tuoi sviluppatori ha un'etica meno che ammirevole e decide di installare software piratato. Non solo il software è probabilmente crivellato di malware, ma puoi aprire una lattina di worm per contenzioso nel caso in cui dovessi essere scoperto con software piratato sul tuo computer. Un reparto IT è considerato responsabile di tali computer e, in quanto tale, è responsabile del controllo e della garanzia che la licenza sia conforme ai Termini di servizio di ciascun software. Sebbene sia conveniente per gli sviluppatori in quanto possono installare il proprio software e non disturbare il reparto IT, si crea molto più lavoro per il reparto IT.

3) Installazione involontaria di malware - menzionato prima, ma questo potrebbe essere abbastanza innocente. L'elevazione dei privilegi degli utenti in modo che possano installare malware li rende suscettibili al malware aprendo un PDF infetto ricevuto tramite e-mail o un'unità tramite download. Limitare l'accesso degli utenti in modo che non possano installare software aiuterà a mitigare la minaccia del malware.

4) Attività dannose - Simile al punto 2, ma cosa c'è da dire che uno dei tuoi sviluppatori non installerà una backdoor o aprirà di proposito un'altra minaccia alla sicurezza sulla tua rete. Saresti sorpreso di quanti professionisti IT lo facciano per vendicarsi se vengono licenziati o il loro capo li fa incazzare.

Tutto sommato, avrei dovuto sconsigliarlo. Mentre le persone potrebbero obiettare che si risparmierebbe tempo impedendo loro di infastidire sempre l'IT per installare software, io ribattei che "ci vuole meno tempo per farlo che per riparare i buchi di sicurezza creati consentendo agli utenti di installare il proprio software" . Se si ritiene che sia necessario, dovrebbero davvero essere inseriti in una rete che non ha accesso diretto al mondo esterno.

Una soluzione alternativa consiste nell'installare una macchina virtuale, non connessa al dominio. Sarà una vera seccatura, ma è meglio che essere completamente paralizzati dalle politiche.