In ogni luogo in cui ho lavorato (come sviluppatore di contratti) gli sviluppatori hanno diritti di amministratore locale sui loro desktop.

I motivi sono:

1) Gli strumenti per gli sviluppatori sono spesso aggiornati molto regolarmente. Librerie grafiche, helper di codice, aggiornamenti visivi di studio; finiscono per ricevere aggiornamenti quasi settimanali che devono essere installati. Il supporto desktop di solito si stanca di ricevere 20 ticket ogni settimana per installare il software aggiornato su tutte le macchine di sviluppo, in modo da fornire solo i diritti di amministratore di devs per farlo da soli.

2) Gli strumenti di debug / test a volte necessitano dei diritti di amministratore per poter funzionare. Nessun accesso amministratore significa che gli sviluppatori non possono eseguire il proprio lavoro di codice di debug. 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 di solito tutti gli sviluppatori possono essere considerati affidabili per avere un accesso di livello superiore per poter fare il loro lavoro.

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

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

Se si tratta di fiducia (ad esempio, alcuni membri del tuo team di sviluppo potrebbero avere intenzioni malevole), sei comunque nei guai. È improbabile che gli amministratori di sistema che approvano / disapprovano determinati diritti saranno in grado di verificare quale sia il codice che hanno scritto in dettaglio. Ciò non significa nemmeno che dovresti dare al tuo team di sviluppo un accesso illimitato ai tuoi servizi di produzione, né che dovrebbero avere accesso amministratore su più macchine di quelle di cui hanno bisogno, naturalmente. È opportuno disporre di meccanismi per mitigare i rischi, ma è necessario disporre di un livello base di affidabilità per il funzionamento dell'organizzazione. Mettere il team di sviluppo su una rete fisica separata è un primo passo per attenuare i problemi di fiducia e possibili errori.

Un rischio tipico quando qualcuno con accesso amministratore deve 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 a volte per lo sviluppo. Anche all'interno della tua organizzazione, le persone IT o non IT dovrebbero utilizzare i servizi con SSL / TLS abilitati, se possibile, questo dovrebbe aiutare contro attacchi di intercettazione e MITM.

Posso pensare ad alcuni aspetti negativi quando non concedo agli amministratori l'accesso come amministratore (a meno che non ne abbiano davvero bisogno):

• Può creare una cultura "loro v.s. us" tra gli sviluppatori e gli amministratori di sistema della tua organizzazione. Questo esiste già in molti posti, ma generalmente non è una buona cosa. È probabile che ogni squadra consideri l'altro come un dolore. La sicurezza non è un problema puramente tecnico, ma anche un'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 in effetti. (Ho sempre trovato la possibilità di trovare soluzioni migliori dopo parlare di persona agli amministratori di sistema con cui dovevo 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 col mettere un discreto sforzo (e spesso riuscendo) a eludere le limitazioni imposte loro all'interno dell'organizzazione. Dovrebbero usare la loro creatività su ciò che dovrebbero fare invece.

• I sistemi IT sono complessi e il debug è un'arte oscura. Se è necessario eseguire il debug del prodotto contro la versione XYZ della libreria a.b.c_13 e a.b.c_24, potrebbe essere necessario che gli sviluppatori siano in grado di installare e disinstallare ciascuna versione, che a sua volta potrebbe richiedere l'accesso all'amministratore. Inseguire bug che dipendono dai numeri di versione è già fastidioso così com'è. Se devi aumentare un ticket e aspettare (forse ore o giorni) che qualcun altro installi / disinstalla la versione corretta, diventerà un incubo: aumenterà il problema culturale "loro contro noi" e, cosa più importante, costerà più per l'organizzazione. Puoi pensare a questo da una prospettiva di valutazione dei rischi / costi.

Il rischio è una funzione crescente dell'accesso

Esiste una semplice regola del calcolo del rischio che spiega la paura dei colleghi del team IT. Più accesso hai su qualsiasi sistema operativo più alti sono gli impatti di qualsiasi errore o attacco.
Ad esempio, se uno dei tuoi colleghi, diciamo Bob, viene attaccato tramite un attacco di phishing standard, poi l'account Bob è disponibile per i criminali informatici e venduto su Internet entro pochi minuti. Se l'account Bob ha privilegi di amministratore, allora questo account sarà usato per inviare SPAM su larga scala su Internet, poi rubare altri account con attacchi di phishing su larga scala e molto rapidamente (in pochi minuti) aprirà una back door alla tua rete (questo è possibile perché l'account Bob è un amministratore) permettendo un controllo remoto totale del PC di Bob ( attraverso strumenti come ssh , VNC , VPN ...). Questo attacco avviato da un PC interno, da un account privilegiato è in grado di rompere qualsiasi firewall, bloccare qualsiasi protezione anti-virus e anti-spam.

The evil is inside.

Anche i migliori amministratori di rete, amministratori di sistema o amministratori di sicurezza può lasciare questo PC danneggiato undecato per mesi (cfr Stuxnet ).

False riduzione del rischio

Se i tuoi colleghi sviluppatori sono bravi a gestire il sistema operativo su cui operano funziona, e ha un accesso fisico al computer, quindi questa differenza in il rischio è nullo.

Any engineer on any OS
can grant himself admin access
if he has a physical access to the computer.

Il blocco dell'accesso all'amministratore su qualsiasi sistema operativo è un approccio valido alla riduzione del rischio per utenti che non sono in grado di fare la differenza tra i privilegi di amministratore e normali privilegi dell'utente.   Ecco la domanda chiave che vorrei rivolgere ai tuoi colleghi del team di sviluppo   e agire sulla loro consapevolezza del rischio:

"What will you take care of if you are granted
admin privilege on your OS?"

Se sono abbastanza buoni da essere consapevoli del rischio, allora sono abbastanza buoni per ottenere l'accesso che vogliono. Quindi non vi è alcuna riduzione del rischio nel rifiuto loro questo accesso amministratore. Attenzione: c'è un rischio collaterale per la tua azienda nel suo insieme se rifiuti loro un accesso che possono facilmente ottenere: lo faranno nel modo sporco, si comportano come fuorilegge, non saranno in grado di chiedere aiuto, loro Dovrò coprire qualsiasi incidente.

Alcune cose che non sono state menzionate in risposte e commenti precedenti che sarebbero un argomento per gli sviluppatori che lavorano con privilegi minimi:

1. A seconda del settore in cui lavori, potrebbero esserci motivi legali o normativi che impediscono ai dipendenti di avere privilegi elevati sulle loro workstation. Permettere l'accesso amministrativo agli sviluppatori potrebbe mettere l'organizzazione a rischio di non essere conforme.

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

3. Se gli sviluppatori installano strumenti o librerie open source e li usano per lo sviluppo, potrebbero esserci restrizioni di licenza non intenzionali su come il software che producono viene infine distribuito, in particolare laddove i termini "copyleft" fanno parte della licenza. Non c'è niente di sbagliato nell'usare strumenti o librerie open source, dovrebbe essere solo intenzionale. Non vuoi scoprire al momento della consegna che ora devi rilasciare tutto il codice sorgente nella comunità perché i tuoi sviluppatori hanno usato un componente open source che aveva termini di licenza copyleft che non avevano realmente letto prima di essere 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 incendio" per privilegi elevati viene registrata e monitorata e viene ripristinata automaticamente al termine del tempo richiesto.

Dai loro i diritti di amministratore locale per la loro workstation e qualsiasi altra cosa vogliano. L'ambiente di sviluppo è sempre isolato dalla rete principale. È compito dell'IT assicurarti di fornire loro tutto ciò di cui hanno bisogno, assicurandosi che nulla nell'ambiente di sviluppo possa danneggiare la rete principale. Pianifica in anticipo e lavora con il management per acquistare l'attrezzatura / il software di cui hai bisogno per raggiungere questo obiettivo.

Hai qualche domanda a cui rispondere.

1. Quali applicazioni devono essere utilizzate quotidianamente da questi sviluppatori richiedono i privilegi di amministratore e c'è un modo per configurare queste applicazioni, quindi non è così?
2. Quali sono le ragioni per cui questi sviluppatori hanno bisogno di privilegi di amministratore per svolgere attività quotidiane banali e c'è un modo per evitarlo?
3. Queste macchine per sviluppatori sono collegate a Internet?

La domanda non dovrebbe essere quali sono i rischi, la domanda dovrebbe essere (a cui si può solo rispondere) quali sono le ragioni per cui gli sviluppatori hanno anche bisogno di 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 fare del male alla tua rete.

Se queste macchine sono connesse a Internet ... allora introdurrai una grande quantità di rischi a causa della loro capacità di eseguire qualsiasi cosa e installare qualsiasi cosa su queste macchine. Questi sviluppatori sono ben sviluppatori, non sono esperti di sicurezza, è solo una questione di WHEN che faranno un errore che espone la rete al 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 malware che ha sfruttato un exploit che era già stato risolto da Microsoft e ha infettato l'intera rete.

Dovrei aggiungere che il dipendente di Google che fa clic sul link non ha nulla a che fare con questa domanda, era necessario sottolineare che le persone faranno un errore e quindi limiteranno il tuo espositore.

I rischi per la sicurezza associati alla fornitura agli sviluppatori di installare i loro 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 i loro sviluppatori necessitavano dell'accesso amministratore per installare il software per svolgere il loro lavoro, allora risponderei con "Perché un mio personale non può installarlo per loro?". Avere un punto centralizzato per l'installazione del software garantisce che un reparto IT sappia esattamente quale software è su quale macchina.

2) Motivi legali - Forse uno dei tuoi sviluppatori ha un'etica meno che ammirevole e decide di installare un software piratato. Non solo il software è probabilmente pieno di malware, ma puoi aprire una scatola di worm per il contenzioso in caso di problemi con software piratato sul tuo computer. Un reparto IT è considerato responsabile di tali computer e, in quanto tale, è responsabile del loro controllo e garantisce che la licenza sia conforme alle TOS 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 non intenzionale di malware - menzionata in precedenza, ma potrebbe essere abbastanza innocente. L'aumento dei privilegi degli utenti in modo che possano installare il malware li rende vulnerabili ai 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à dannosa - Simile al punto 2, ma cosa dire che uno dei tuoi sviluppatori non installerà una backdoor o aprirà di proposito un'altra minaccia alla sicurezza sulla tua rete. Sareste sorpresi di quanti professionisti IT lo facciano per vendicarsi nel caso in cui vengano interrotti o il loro capo li faccia arrabbiare.

Tutto sommato, dovrei sconsigliarlo. Mentre le persone potrebbero obiettare che farebbe risparmiare tempo nell'impedire che continuino a insinuare l'IT nell'installare software, vorrei ribattere dicendo che "ci vuole meno tempo per farlo, piuttosto che correggere i buchi di sicurezza creati permettendo agli utenti di installare il proprio software" . Se si ritiene che ciò sia necessario, dovrebbero essere effettivamente inseriti in una rete che non ha accesso diretto al mondo esterno.

Una soluzione alternativa è installare una macchina virtuale, non connessa al dominio. Sarà piuttosto una seccatura ma è meglio che essere totalmente paralizzato dalle politiche.