Bloccare una macchina degli sviluppatori richiede più sforzo del suo valore? [chiuso]

Avendo lavorato come sviluppatore e nell'amministratore / supporto IT per un team di sviluppo, mi sono imbattuto in molti diversi tipi di ambiente, dal completamente bloccato al completamente no. Nella mia esperienza di supporto limitata penso che sia stato meno sforzo per supportare con una macchina meno bloccata e sicuramente ho sentito che era più facile, ma ovviamente questo potrebbe essere un errore. Mi piacerebbe sapere qual è la vista dal punto di vista del supporto IT, è davvero più difficile supportare gli sviluppatori che hanno macchine non bloccate?

Il problema più grande nel non bloccare una macchina degli sviluppatori è che qualsiasi software che sviluppano richiederà i privilegi di amministratore completi per funzionare. L'accesso degli sviluppatori dovrebbe essere lo stesso dell'ambiente in cui dovranno funzionare. Se devono essere "auto-supportabili" o "autoinstallabili", dai loro un altro account admin, ad esempio Bruce.admin, che devono usare quando fanno admin roba, ma non usato giorno per giorno.

Proprio come nessun amministratore UNIX decente degno del loro sale potrà mai usare un account root per il loro lavoro quotidiano non amministrativo.

La maggior parte degli sviluppatori è tecnicamente esperta e sa cosa sta facendo. Spesso hanno bisogno di installare molte app specializzate, ottenere l'autorizzazione per farlo e far scendere l'IT e aggiungerlo può essere molto frustrante, in particolare nelle grandi aziende, per entrambe le parti.

Ho scoperto che ciò che funziona meglio è consentire loro di fare ciò che vogliono per quanto riguarda l'installazione del software sui loro computer, ma se si trovano in problemi con qualcosa che non supportiamo, allora sono soli. La maggior parte degli sviluppatori ne è contenta e preferisce comunque essere in grado di prendersi cura della propria macchina.

Bloccare qualcuno nella contabilità per usare solo IE e open word va bene, ma se sei uno sviluppatore che deve installare 4 diversi tipi di browser e deve installare rapidamente un'app per risolvere un problema, può essere fastidioso.

La mia esperienza è che le aziende che hanno molte conoscenze tecniche, quindi i negozi di sviluppo, i fornitori IT ecc., Che si fidano dei loro dipendenti e lasciano che decidano ciò che vogliono installare sono molto più felici e disturbano l'IT di meno

Guarda questo post di Stackoverflow per un vivace dibattito sui vantaggi di bloccare le macchine degli sviluppatori. (Dichiarazione di non responsabilità: ho scritto la risposta accettata).

Dal punto di vista di amministratore di sistema, l'accesso ai sistemi di produzione è sensibile e si dovrebbe limitare tale accesso alle persone che ne hanno bisogno per svolgere il proprio lavoro (questo può includere sviluppatori con responsabilità di supporto di livello 3 per l'applicazione). I diritti di amministratore locale su un PC di sviluppo o server di sviluppo non compromettono in modo significativo la sicurezza dei sistemi di produzione.

Crea un'immagine che puoi usare per ricostruire le macchine con se necessario. L'installazione manuale di SQL Server dev edition, Visual Studio, Cygwin e MikTex e un sacco di altre app richiede molto tempo. Un'immagine con queste app di grandi dimensioni installate sarà ragionevolmente preziosa se devi reimmaginare molto le macchine.

Dal punto di vista dello sviluppo, trovo che posso risolvere la maggior parte dei problemi con la macchina e in genere ho bisogno dell'aiuto del personale di supporto di rete in occasioni abbastanza rare. Gli ambienti troppo restrittivi tendono a generare traffico di supporto agli sviluppatori spuri per svolgere attività che gli sviluppatori sono perfettamente in grado di svolgere da soli.

Un altro luogo in cui gli sviluppatori tendono a necessitare di molto lavoro di amministrazione è sui server di database che ospitano ambienti di sviluppo. La maggior parte degli sviluppatori è in grado di apprendere facilmente le attività DBA di routine e dovrebbe comunque acquisirne una conoscenza pratica (IMHO in linea di principio). Le politiche di accesso dell'amministratore eccessivamente restrittive sui server di sviluppo possono essere sottoposte a numerosi passaggi.

Una rete di sviluppo scratch è una buona idea se può essere organizzata: se necessario, puoi firewall questa dai tuoi server di produzione.

• Quando gli sviluppatori possono facilmente replicare la struttura di un ambiente di produzione, promuovono una cultura di test di implementazione in cui un test di integrazione può essere sintetizzato senza saltare attraverso i cerchi. Ciò tenderà a migliorare la qualità del rilascio e della distribuzione della produzione.

• Essere in grado di emulare un ambiente di produzione aumenta anche la consapevolezza della distribuzione della produzione e dei problemi di supporto. Incoraggia lo staff di sviluppo a pensare a come un'applicazione potrebbe essere supportata nella produzione, il che probabilmente incoraggerà le architetture costruite tenendo conto di ciò.

• Se questa rete ha un controller di dominio, puoi stabilire una relazione di fiducia in modo che confida nel controller di dominio principale e nei suoi account. Questa relazione di fiducia non deve essere reciproca, quindi non compromette la sicurezza dell'infrastruttura della rete di produzione. Ciò può consentire di avere una rete di sviluppo non attendibile, ma consentire comunque agli sviluppatori di accedere a risorse autenticate dal dominio come account Exchange o file server.

• Desideri che gli sviluppatori dispongano di un ragionevole margine di sperimentazione senza dover saltare attraverso i cerchi. Colpire ostacoli politici lungo il percorso di questo lavoro ha la tendenza a incoraggiare l'attacco di soluzioni di gesso politicamente opportune ma che generano debito tecnico a lungo termine (e spesso non riconosciuto). Come amministratore di sistema o di supporto, indovina chi arriva a raccogliere i pezzi ...

Aggiungerò che questo è molto meno un problema in un ambiente unix o linux; gli utenti possono personalizzare fortemente il proprio ambiente dal proprio .profile. Puoi compilare e installare le cose nella tua /home/bloggsj/bindirectory per la gioia del tuo cuore. I "diritti di amministratore locale" sono per lo più un problema di Windows, sebbene ci siano ancora alcune cose che richiedono l'accesso come root in Unix.

L'opzione più sensata che abbia mai visto (sono state su entrambi i lati - e lo sono ancora) è semplicemente roba sbloccata e anche non supportata . Dai loro la libertà, e se si sbagliano, tutto ciò che possono ottenere è un riposo con un'immagine standard .... In quella situazione, trovo un buon piano metterli su una qualche forma di rete "non affidabile".

Per quanto riguarda il (non) senso di bloccare i desktop degli sviluppatori: sono abbastanza sicuro che tutti i blocchi ostacolino solo la produttività, inoltre, qualsiasi sviluppatore abbastanza abile troverà facilmente i buchi ....

La risposta è davvero: non esiste una semplice risposta sì o no. Ma la sicurezza è importante tanto per i tuoi utenti dev quanto per chiunque altro.

Da un lato, sì, gli sviluppatori tendono ad essere tecnicamente più esperti. D'altra parte, il loro è spesso un lavoro stressante e le loro pietre miliari dello sviluppo avranno probabilmente la priorità sulle cure extra necessarie per mantenere il proprio sistema come ambiente sicuro. Questa non è una critica agli sviluppatori; è una chiara considerazione dei loro doveri quotidiani.

Se hai intenzione di dare agli sviluppatori un accesso completo e senza restrizioni ai loro sistemi, allora dovresti davvero considerare le seguenti misure aggiuntive:

• Fornire un altro sistema, bloccato tanto quanto i normali sistemi utente sono bloccati, per un normale utilizzo senza sviluppatori.
  • Mettono le loro macchine di sviluppo ad accesso completo in una VLAN speciale, con accesso solo alle risorse di sviluppo.
• Chiedi cosa succede se qualcosa impedisce a un sistema infetto di mettere in pericolo la base di codice. Una macchina backdoor potrebbe controllare il codice maligno o spazzare via la base di codice nelle mani di un hacker ostile? Adottare le misure appropriate per mitigare questo rischio.
• Allo stesso modo, chiedi cosa succede se qualcosa protegge i dati aziendali contenuti nei sistemi a cui gli sviluppatori hanno accesso.
• Effettuare regolarmente l'inventario del software e l'audit di sicurezza dei sistemi di sviluppo.
  • Fatti un'idea di cosa stanno eseguendo e usa queste informazioni per creare immagini di ridistribuzione del tuo sistema di sviluppo.
  • Prima o poi avrai uno sviluppatore che diventa negligente e installa cose che sono chiaramente pericolose o completamente non legate al lavoro. Inviando rapidamente avvisi quando ciò accade, farai sapere alla comunità degli sviluppatori che sì, qualcuno sta guardando e hanno la responsabilità di rispettare standard ragionevoli.
• Stai eseguendo scansioni malware regolari? In alcuni casi, gli sviluppatori si lamenteranno giustamente dell'imposta sulle prestazioni riscossa dai sistemi AV in accesso (quei sistemi AV che sono sempre attivi, che scansionano sempre ad ogni accesso ai file). Potrebbe essere preferibile passare a una strategia di scansione notturna e / o creare esclusioni di file / cartelle alla scansione in accesso. Assicurati però che i file esclusi vengano scansionati in qualche altro modo.
  • I tuoi sviluppatori abilitati all'amministrazione possono disattivare tutta la scansione AV? Come lo rileveresti e rimedieresti?

Se hai intenzione di bloccare i sistemi di sviluppo, dovresti considerare quanto segue:

• Hai la capacità di supporto per rispondere rapidamente alle loro richieste di supporto? Considera la percentuale media di pagamento dei tuoi sviluppatori e chiedi se meritano o meno uno SLA dei tempi di risposta più rapido. Probabilmente non ha senso tenere in attesa il tuo dev $ 120k (che è la chiave di un progetto multimilionario) mentre gestisci richieste di supporto da $ 60k / anno impiegati.
• Hai una politica chiara e inequivocabile su quali richieste di supporto farai e non servirai per i tuoi sviluppatori? Se iniziano ad avere la sensazione che il sostegno è arbitraria, si sarà finalmente sentire il dolore.

Ad ogni modo, devi ammettere che gli sviluppatori sono un caso speciale e hanno bisogno di un supporto extra di qualche tipo. Se non stai pianificando questo, i problemi probabilmente si stanno risolvendo proprio ora ... o lo saranno in futuro.

Come nota a margine, ho visto argomentazioni molto simili avere luogo con amministratori di sistema. In almeno due lavori diversi ho visto amministratori di sistema litigare in modo piuttosto aspro quando è stato suggerito che avrebbero dovuto bloccare loro stessi i sistemi, o almeno usare due accessi (uno con i privilegi di root / admin; uno senza). Molti amministratori di sistema ritengono che non debbano essere bloccati in alcun modo e hanno discusso strenuamente contro tali misure. Prima o poi qualche amministratore avverso al blocco avrebbe avuto un incidente di sicurezza e l'esempio avrebbe avuto un effetto educativo su tutti noi.

Ero uno di quei amministratori di sistema che correva sempre con i privilegi di amministratore. Quando ho apportato la modifica ai conti doppi e solo in caso di necessità, ammetto che è stato abbastanza frustrante durante i primi mesi. Ma il lato positivo del cloud era che avevo imparato molto di più sulla sicurezza dei sistemi che stavo amministrando, quando il mio account normale viveva con le stesse restrizioni che stavo ponendo agli utenti. Mi ha reso un amministratore migliore! Ho il sospetto che lo stesso vale per gli sviluppatori. E fortunatamente nel mondo di Windows, ora abbiamo UAC, che semplifica l'esecuzione come utente limitato e l'elevazione solo quando necessario.

Personalmente non penso che qualcuno dovrebbe essere al di sopra di qualche forma di pratiche di sicurezza. Tutti (amministratori di sistema, sviluppatori, alti dirigenti inclusi) dovrebbero essere soggetti a procedure di sicurezza e supervisione sufficienti per tenerli in guardia. Dire diversamente significa che i sistemi e i dati aziendali non valgono lo sforzo di protezione.

Mettiamola in un altro modo. Se Mark Russinovich può essere catturato da un rootkit , chiunque può farlo !

Laddove hai pochi sviluppatori, l'approccio per offrire loro server di sviluppo è una possibilità, ma se hai un intero piano di sviluppatori, sono assolutamente contrario a dare loro qualsiasi diritto di amministratore.

Il problema è che finirai con un intero piano di sviluppatori, ognuno che fa quello che fa, di solito la maggior parte non è nemmeno attenta alla sicurezza e vuole solo che la sua app funzioni. Quindi verrai colpito con una richiesta di: "Abbiamo completato la fase di sviluppo, per favore replica il nostro ambiente di sviluppo su test, pre-prod e prod".

Hanno anche l'abitudine di installare junk casuali (software mal confezionato), e quindi ti delegano per installarlo su una dozzina di server negli altri livelli.

Rendo la politica abbastanza semplice:

• Gli sviluppatori NON ottengono l'accesso alla radice, mai, per l'ambiente di sviluppo.
• Gli sviluppatori ottengono l'accesso root ai server VMware pre-sviluppo, ma NON supportano.
• Gli sviluppatori devono fornire pacchetti RPM che appartengono alla distribuzione del sistema operativo su cui verrà eseguita la loro app, oppure pacchetti RPM conformi a FHS e LSB.
• Nessuna delle loro applicazioni può essere eseguita come root
• L'utente non avrà accesso suo sudoall'utente dell'applicazione, che verrà bloccato per non avere accesso alla shell. (Questo è per contabilità / audit).
• Tutti i comandi che devono essere eseguiti con accesso privilegiato dovranno essere esplicitamente richiesti e approvati - a quel punto verrà aggiunto al sudoersfile.
  • Nessuno di questi comandi / script sarà scrivibile da loro.
  • Nessun riferimento di script (direttamente o indirettamente) da questi comandi sarà scrivibile da loro.

Soprattutto, far loro pensare a cosa sarà e non sarà permesso quando arriva il momento di spostare il progetto sul test e sopra i server.

Bloccare le macchine degli sviluppatori richiede più sforzo di quanto valga la pena. Danneggia gravemente la produttività poiché non si può fare praticamente nulla senza i diritti amministrativi. Naturalmente, alla fine il sistema si incasinerà, ma sicuramente il tuo reparto IT non fornisce supporto a tutti quegli strumenti di terze parti che vengono utilizzati nello sviluppo?

Quindi, come ha suggerito Vincent De Baere, il miglior modo di agire sarebbe semplicemente ripristinare il sistema da un'immagine, ovviamente, l'ambiente deve essere ripristinato dopo quello, ma questo non dovrebbe essere un problema IT. Se succede N volte puoi mettere una persona in una sorta di "lista nera" e, sì, abbandonare i suoi diritti amministrativi per un po '.

In entrambi i casi, l'ambiente dovrebbe essere impostato in modo tale da garantire che una macchina infetta (o altrimenti incasinata) non influisca su nessun'altra macchina o, diciamo, non invii spam o altro (ok, ora Sto solo dicendo cose ovvie, scusa).

Bene, può in parte dipendere dall'ambiente in cui si sta eseguendo (ad es. Linux contro Windows); tuttavia, supponendo un ambiente Windows, di solito è più un problema di quanto valga semplicemente perché alcuni dei software di sviluppo là fuori richiedono di avere autorizzazioni elevate per funzionare. Ad esempio, è noto che Visual Studio richiede le autorizzazioni di amministratore , in quanto tale, non vedo il vantaggio di far saltare qualcuno attraverso i cerchi per una parte richiesta del loro lavoro.

Tuttavia, se la società richiede che le cose siano bloccate, la tua scommessa migliore è probabile che dia a tutti gli sviluppatori macchine virtuali sui loro sistemi in cui possono impazzire. Mentre ad alcuni potrebbe non piacere così tanto, probabilmente ti darà il meglio di entrambi mondi (ad esempio desktop normale restrittivo e un ambiente completamente personalizzabile).

Aggiornamento - Sul lato Windows c'è qualcosa di più degno di nota, apparentemente Visual Studio che richiede i diritti di amministratore è un po 'datato e ora ci sono modi espliciti per impostare le autorizzazioni necessarie (file PDF). Tuttavia, non penso che questo cambi la mia opzione in quanto la maggior parte degli sviluppatori che conosco, incluso me stesso, tende ad usare strumenti aggiuntivi oltre a Visual Studio e sapere cosa tutti loro hanno bisogno in termini di autorizzazioni può essere difficile da prevedere.

Sono d'accordo con l'idea di utilizzare macchine virtuali su un desktop limitato-

A meno che non sia necessario, ritengo che la migliore installazione sia un desktop linux limitato con un vm gratuito per tutti in cima. Linux riduce le spese generali per me, un vm può non solo essere qualsiasi sistema operativo che vogliono, ma può anche essere ripristinato in istantanee o backup, e in generale il mondo sembra un po 'più luminoso quando non ci sono molte configurazioni diverse che richiedono supporto.

Io (come sviluppatore me stesso) preferisco avere il pieno controllo dei miei macchinari, vale a dire; in esecuzione come amministratore quando necessario.

È possibile fornire una formazione speciale agli sviluppatori prima che gli sia concesso il pieno accesso ai loro computer. Imposta alcune regole per loro, e forse potresti fare un controllo ogni tanto per vedere che seguono le migliori pratiche.

Per lo più avranno bisogno di saperne di più sull'infrastruttura IT da un punto di vista dell'amministratore IT / supporto IT, cose relative alla sicurezza e perché non svilupparsi con diritti elevati. (e come assicurarsi che tu non ...)

"Non fidarti ciecamente di noi quando ti diciamo che sappiamo tutto ciò che dobbiamo sapere sui computer" ;-)

Dovrai ancora supportarli con reti, roba di dominio e account, installazioni di software di strumenti non sviluppatori ecc.

La mia esperienza è con una popolazione di utenti che era quasi equamente divisa tra persone che avevano solo bisogno di una macchina bloccata e altre (sviluppatori, scienziati) che avevano bisogno dell'accesso di amministratore. Queste persone di fascia alta usavano molti software diversi, alcuni interni, altri no, ma molti avevano bisogno dell'amministratore per essere eseguiti, e il loro lavoro richiedeva loro di usare molti pacchetti, quindi era logico lasciare che la gente lo facesse da soli.

Abbiamo finito con i seguenti processi:

• La nostra immagine standard aveva gli strumenti di base: Windows, Office, Anti-virus, Acrobat, alcune utility.
• Abbiamo fornito un sacco di spazio su disco di rete: abbastanza per poter archiviare tutto sulla rete. L'unica eccezione era rappresentata dai file video in-process che dovevano rimanere locali.
• Il personale (in consultazione con i supervisori) aveva due possibilità: l'IT manteneva il proprio PC, eseguiva tutte le installazioni e le configurazioni OPPURE poteva avere accesso come amministratore per farlo da solo. In entrambi i casi, è stato eseguito il backup di tutti i dati sulla rete.
• Se l'IT avesse mantenuto il sistema e si fosse spento, lo avremmo riportato allo stato in cui si trovava, incluso l'aggiunta di software aggiuntivo necessario per l'installazione.
• Se avessero avuto accesso come amministratore e il sistema fosse morto, avremmo dato un'occhiata e tentato di risolverlo, ma il nostro impegno era di riportarli all'immagine standard e avrebbero dovuto prenderlo da lì. Se avessero dei dati locali, proveremmo prima a risolverli, ma il nostro SLA era solo quello di farli un PC standard funzionante il prima possibile.
• A chiunque fosse richiesto l'accesso come amministratore per sapere come assicurarsi che gli aggiornamenti di Windows funzionassero, per mantenere Anti-virus e anti-malware aggiornati.

Ci sarebbe piaciuto mettere tutte le persone con accesso come amministratore su un vlan "non attendibile", ma non ci siamo mai riusciti.