it-swarm.it

Rischi di concedere agli sviluppatori diritti di amministratore sui propri PC

Devo convincere il mio dipartimento IT interno a concedere al mio nuovo team di sviluppatori i diritti di amministratore sui nostri PC. Sembrano pensare che ciò creerà alcuni rischi per la sicurezza della rete. Qualcuno può spiegare perché questo sarebbe? Quali sono i rischi? Cosa configurano i dipartimenti IT per gli sviluppatori che hanno bisogno di installare software sul proprio PC.

Questa domanda era Domanda sulla sicurezza IT della settimana.
Leggi l'8 giugno 2012 post di blog per maggiori dettagli o invia il tuo Domanda della settimana.

78
carolineggordon

In ogni luogo in cui ho lavorato (come sviluppatore di contratti) agli sviluppatori vengono assegnati i diritti di amministratore locale sui loro desktop.

Le ragioni sono:

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

2) Gli strumenti di debug/test a volte necessitano dei diritti di amministratore per poter funzionare. Nessun accesso da amministratore significa che gli sviluppatori non possono svolgere il proprio 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 agli sviluppatori di solito ci si può fidare di avere un accesso di livello superiore per poter svolgere il proprio lavoro.

63
Alan Barber

Ciò 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, è possibile eseguire una buona quantità di web Java utilizzando simili a Eclipse con artefatti Maven, tutti installati localmente (e in genere testati sulla porta 8080), senza richiedere molti diritti di amministratore (potrebbe essere necessario aprire determinate porte). Lo sviluppo di strumenti che richiedono un accesso più stretto all'hardware potrebbe risultare impossibile senza i diritti di amministratore. Detto questo, anche per lo sviluppo Web, è buona norma poter ricostruire una macchina di prova da zero ( in genere una macchina virtuale), che potrebbe richiedere diritti di amministratore.

Se si tratta di fiducia (ovvero alcuni membri del tuo team di sviluppo potrebbero avere intenzioni dannose), sei comunque nei guai. È improbabile che i amministratori di sistema che approverebbero/disapprovassero determinati diritti siano in grado di verificare in dettaglio cosa fa il codice che hanno scritto. Ciò non significa che dovresti dare al tuo team di sviluppo un accesso illimitato ai tuoi servizi di produzione, né che dovrebbero avere l'accesso come amministratore su più macchine di quante ne necessitino, ovviamente. È utile disporre di meccanismi per mitigare i rischi, ma è necessario un livello di fiducia di base affinché la tua organizzazione funzioni. 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 acquisire pacchetti sulla rete. Questo è un rischio che potresti dover accettare a seconda della natura di ciò che è sviluppato. A volte strumenti come Wireshark possono essere utili per lo sviluppo. 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 a evitare intercettazioni e attacchi MITM.

Mi vengono in mente alcuni svantaggi quando non si concede agli amministratori l'accesso dell'amministratore (a meno che non ne abbiano davvero bisogno):

  • Può creare una cultura "them v.s. us" tra sviluppatori e amministratori di sistema nella tua organizzazione. Questo esiste già in molti luoghi, 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 scoperto di essere in grado di trovare soluzioni migliori dopo parlare di persona agli amministratori di sistema con i quali avevo bisogno di risolvere i problemi piuttosto che rispondere a un biglietto 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 fare un discreto sforzo (e spesso riescono) a eludere le limitazioni imposte loro all'interno dell'organizzazione. Dovrebbero usare la loro creatività su ciò che dovrebbero invece fare.

  • I sistemi IT sono complessi e il debug è un'arte oscura. Se è necessario eseguire il debug del prodotto con la libreria XYZ versione a.b.c_13 e a.b.c_24, gli sviluppatori potrebbero dover installare e disinstallare ciascuna versione, che a sua volta potrebbe richiedere l'accesso come amministratore. Inseguire i 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 lo renderà un incubo: aumenterà il problema culturale "them vs us" e, cosa più importante, costerà più per l'organizzazione. Puoi pensarlo da una prospettiva di valutazione del rischio/costo.

28
Bruno

Il rischio è una funzione crescente di accesso

Esiste una semplice regola di calcolo del rischio che spiega la paura dei colleghi del team IT. Maggiore è l'accesso su qualsiasi sistema operativo, maggiore è l'impatto di qualsiasi errore o attacco.
Ad esempio, se uno dei tuoi colleghi, diciamo Bob, viene attaccato attraverso un attacco di phishing standard, l'account Bob è disponibile per i criminali informatici e viene venduto 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 backdoor al tuo rete (ciò è possibile perché l'account Bob è un account amministratore) che consente 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, bloccare qualsiasi protezione antivirus e antispam.

Il male è dentro.

Anche i migliori amministratori di rete, amministratori di sistema o amministratori della sicurezza potrebbero lasciare questo PC corrotto inosservato per mesi (cfr. Stuxnet).

Riduzione del falso rischio

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

Qualsiasi ingegnere su qualsiasi sistema operativo
può concedere a se stesso l'accesso come amministratore
se ha un accesso fisico al computer.

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

"Di cosa ti occuperai se ti viene concesso
privilegio di amministratore sul tuo sistema operativo? "

Se sono abbastanza bravi da essere consapevoli del rischio, allora sono abbastanza bravi da ottenere l'accesso che desiderano. Quindi non vi è alcuna riduzione del rischio nel rifiutare loro questo accesso da amministratore. Attenzione: c'è un rischio collaterale per la tua azienda nel suo complesso se rifiuti loro un accesso che possono facilmente ottenere: lo faranno nel modo sporco, si comporteranno come fuorilegge, non potranno chiedere alcun aiuto, loro dovrò coprire qualsiasi incidente.

10
dan

Concedi loro 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 assicurarsi di fornire loro tutto ciò di cui hanno bisogno durante l'installazione, assicurandosi che nulla nell'ambiente di sviluppo possa danneggiare la rete principale. Pianifica in anticipo e collabora con la direzione per acquistare le attrezzature/i software necessari per raggiungere questo obiettivo.

8
wrb

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

  1. A seconda del settore in cui si sta lavorando, potrebbero esserci motivi legali o regolatori che impediscono ai dipendenti di avere privilegi elevati sulle loro workstation. 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 verificarsi un rischio di errore durante la distribuzione in altri ambienti che non dispongono di tali privilegi. Gli sviluppatori potrebbero avere inavvertitamente aggiornato o aggiunto librerie ai loro computer locali che non esistono in altri ambienti e i componenti potrebbero avere dipendenze da versioni specifiche di tali librerie. Inoltre, gli account utente in cui i componenti verranno eseguiti in altri ambienti potrebbero non avere il database richiesto o altri accessi assunti dallo sviluppatore che lavora con privilegi elevati. Ho visto succedere molte volte in passato. A volte è ovvio il motivo per cui la distribuzione non è riuscita, a volte no, e devi ripristinare tutto fino a quando non riesci a capirlo.

  3. Se gli sviluppatori installano strumenti o librerie open source e li utilizzano per lo sviluppo, potrebbero esserci restrizioni involontarie della licenza 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 intenzionale. Non vuoi scoprire al momento della consegna che ora devi rilasciare tutto il tuo codice sorgente nella comunità perché i tuoi sviluppatori hanno usato nella licenza alcuni componenti open source che avevano termini rigorosamente copyleft che in realtà non avevano letto prima di installato.

Qualcosa che ho visto fare è far lavorare gli sviluppatori con il minimo privilegio, ma consentire loro di richiedere privilegi elevati per un periodo di tempo specificato. Quindi, questa richiesta di "chiamata di incendio" per privilegi elevati è stata registrata e monitorata e viene reimpostata automaticamente al termine del tempo richiesto.

8
Todd Dill

Hai qualche domanda a cui rispondere.

  1. Quali applicazioni devono utilizzare quotidianamente questi sviluppatori che richiedono privilegi di amministratore e c'è un modo per impostare queste applicazioni in modo che non sia così?
  2. Quali sono i motivi per cui questi sviluppatori hanno bisogno dei privilegi di amministratore per svolgere attività quotidiane banali e c'è un modo per evitarlo?
  3. Queste macchine sviluppatore sono connesse a Internet?

La domanda non dovrebbe essere quali sono i rischi, la domanda dovrebbe essere (alla quale puoi solo rispondere) quali sono i motivi per cui gli sviluppatori hanno persino 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 danneggiare la tua rete.

Se queste macchine sono connesse a Internet ... allora si presenterà 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 programmatori, non sono esperti di sicurezza, è solo una questione di QUANDO 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, scarica malware che sfrutta un exploit già riparato da Microsoft e infetta l'intera rete.

Dovrei aggiungere l'impiegato di Google facendo clic sul collegamento non ha nulla a che fare con questa domanda, è stato per sottolineare, la gente farà un errore in modo da limitare l'esposizione.

4
Ramhound

I rischi per la sicurezza associati alla fornitura agli sviluppatori della possibilità di installare i propri computer sono numerosi. Ecco perché dovrei 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 - concedere ai dipendenti solo l'accesso a ciò di cui hanno bisogno per completare il loro compito. Se qualcuno mi dicesse che il proprio sviluppatore ha bisogno dell'accesso di amministratore per installare il software per svolgere il proprio lavoro, 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) Ragioni legali - Forse uno dei tuoi sviluppatori ha un'etica inferiore all'ammirevole e decide di installare software piratato. Non solo quel software è probabilmente pieno di malware, ma poi si apre una lattina di worm per controversie legali nel caso in cui si venga sorpresi con software piratato sul computer. Un dipartimento IT è considerato responsabile di tali computer e, in quanto tale, è responsabile del loro controllo e della garanzia che la licenza sia conforme ai 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 involontaria di malware - menzionato prima, ma questo potrebbe essere abbastanza innocente. Elevare i privilegi dell'utente in modo che possano installare malware li rende suscettibili al malware aprendo un PDF ottenuto tramite e-mail o un'unità tramite download. Limitare l'accesso degli utenti in modo che non possano l'installazione del software consentirà di mitigare la minaccia del malware.

4) Attività dannosa - 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 di sicurezza sulla tua rete. Sareste sorpresi da quanti professionisti IT fanno questo per ottenere vendetta nel caso in cui vengano licenziati o il loro capo li faccia incazzare.

Tutto sommato, dovrei sconsigliarlo. Mentre le persone potrebbero obiettare che risparmierebbe tempo impedendo loro di infastidire sempre l'IT per installare il software, ma vorrei contrastare che con "ci vuole meno tempo per farlo rispetto a quanto fa per riparare i buchi di sicurezza creati consentendo agli utenti di installare il proprio software" . Se si ritiene che questo IS necessario, dovrebbero davvero essere messi su una rete che non ha accesso diretto al mondo esterno.

4
DKNUCKLES

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

2
Louis Somers