Autorizzazioni di Windows per gli sviluppatori?

Lavoro in un'azienda Fortune 500 come sviluppatore di software Windows in ricerca e sviluppo. L'IT aziendale si sta attualmente preparando per una distribuzione Win7 in tutta l'azienda e come parte di essa sta cercando di bloccare completamente i diritti di amministratore su tutti i box (comprese le nostre workstation di sviluppo).

Mi è stato affidato il compito di lavorare con loro per rendere la transizione il più agevole possibile. Fortunato me.

Mi piacerebbe sapere se ci sono risorse pubblicate o di altro genere rispettate che posso usare per:

1. capire dove tracciare una linea nella sabbia
2. backup della mia posizione.

Personalmente, la mia opinione è che siamo R&S e il nostro compito è quello di fare cose che sono "fuori dagli schemi". Quindi abbiamo bisogno dei diritti di amministratore. Tuttavia, dopo aver iniziato la mia carriera come amministratore di Windows, sono consapevole dei loro obiettivi e di ciò che devono raggiungere. Ciò di cui ho bisogno per capire e fare il backup è un modo per costruire l'ambiente in modo che sia l'IT sia la R&S possano convivere con esso e continuare a svolgere il proprio lavoro in modo produttivo.

Le VM di sviluppo con diritti di amministratore locale aiuteranno sicuramente molto, ma non in tutti i casi poiché ci interfacciamo con un sacco di hardware personalizzato.

Il CIO che spinge questi cambiamenti è sicuramente un tipo di "puro IT" con una conoscenza limitata del processo di sviluppo, quindi ho bisogno di alcuni riferimenti che sarebbero appropriati da condividere con qualcuno del genere.

Non sto cercando di raccogliere molte opinioni personali (molte delle quali sono già state condivise qui ), ho davvero bisogno di white paper, articoli di riviste, lavori accademici, ecc. Da usare per fare un caso forte ai dirigenti.

Poiché stai andando specificamente a Windows 7, dovresti spingere forte per essere amministratori nelle tue caselle. Ci sono due buoni motivi per impedire agli sviluppatori di essere amministratori:

• lo stesso motivo per cui impedisci a tutti gli altri di essere amministratori, in modo che il malware non faccia cose davvero orribili se succede
• quindi non scriveranno app che funzionano solo se sei un amministratore

Con UAC, nessuna di queste cose accadrà, poiché le app che avvierai non funzioneranno come admin a meno che tu non le abbia deliberatamente chiesto. Pertanto, vi è un rischio limitato di consentire di disporre di un account amministratore.

Alcuni boss hanno una terza ragione: non voglio che tu installi giochi o strumenti non autorizzati. Senza discutere i meriti di questa ragione, osserverò che di solito non è dichiarato. È necessario l'accesso come amministratore per installare le cose che si stanno scrivendo, configurare IIS, riconfigurare la macchina per vari tipi di test (ad esempio, modificare il file host) e i due "reali" motivi per evitare l'accesso come amministratore non si applicano più a Windows 7 Pertanto, dovresti essere un amministratore.

Onestamente penso che sarà un caso difficile da fare. Una volta che la direzione superiore ha preso una decisione, è piuttosto difficile farli cambiare. Se consentissero più privilegi sulla tua macchina, qualcun altro potrebbe essere in grado di accedere ed eseguire le azioni che questo intero piano è stato progettato per prevenire.

Questi possono aiutare:

• http://www.slate.com/id/2226279/pagenum/all/
• /server/232416/should-dev-be-admin-on-their-computer
• http://avecto.com/blog/2010/09/the-pros-and-cons-of-windows-7-application-control-with-applocker/

PS: buona fortuna!

Un'opzione è richiedere workstation di prova che consentano l'accesso amministrativo.

Un'altra opzione è fare esattamente come si dice. Quindi, quando arriverà il prossimo progetto, non farai progressi perché devi andare all'IT per ogni piccola modifica. Spiegalo al capo del progetto e organizzerà rapidamente i diritti di amministratore.

Una terza opzione è verificare se il proprio dipartimento è rappresentato nel progetto di migrazione di Win7. In tal caso, contattare il proprio rappresentante e chiedere se è possibile aggiungere diritti amministrativi all'elenco dei requisiti del proprio reparto.

Una quarta opzione è fare trading. Il progetto di migrazione in genere necessita di sviluppo per aggiornare il loro software per Win7. Potrebbe essere possibile condizionare un atteggiamento favorevole nei confronti dei diritti di amministratore nel nuovo ambiente.

Non riesco a immaginare di provare a sviluppare senza essere un amministratore locale, tuttavia penso che le esigenze varieranno a seconda delle attività di sviluppo e di quanto sia standardizzato il processo di sviluppo e la toolchain sul posto di lavoro.

Dalla mia esperienza, di solito ci sono membri dello staff di sviluppo senior che dovranno installare vari strumenti di sviluppo (a volte in orari dispari) per prototipare rapidamente o risolvere alcuni problemi critici. Quasi certamente hanno bisogno dell'accesso dell'amministratore locale per installare, eseguire il debug, lavorare con i servizi, ecc.

Il personale restante potrebbe essere in grado di cavarsela senza di essa, se il set di strumenti è abbastanza costante e in base a ciò che sviluppano / eseguono il debug / distribuiscono. Il mio suggerimento sarebbe quello di riunire un piccolo gruppo del personale di sviluppo senior con il livello più alto, spiegare il problema e le loro opzioni e farli prendere un paio di giorni per considerarlo, quindi tenere una riunione di pianificazione per determinare quale tipo di accesso il personale dovrebbe avere.

Da una prospettiva IT pura e da una prospettiva di sviluppo, molte aziende risolvono il problema in questo modo:

Metti tutte le caselle di sviluppo su una rete separata. La rete di sviluppo potrebbe essere completamente isolata (niente internet e nessuna intranet). In questo caso, gli sviluppatori dispongono di un box aziendale separato che viene utilizzato per la posta elettronica e le comunicazioni ufficiali, ovvero l'accesso a Internet e alla rete Intranet. Questa soluzione ha le sue sfide in quanto alcuni IDE (come Eclipse) e altri strumenti di sviluppo presuppongono che tu abbia una connessione live a Internet per ottenere aggiornamenti e plugin. Tuttavia la stragrande maggioranza degli strumenti di sviluppo sa che esistono reti isolate.

Un'altra variante di questo approccio è quella di avere la rete di sviluppo su una sottorete. Hai accesso indiretto a Internet e Intranet attraverso un rigoroso firewall DMZ, ma gli sviluppatori hanno ancora accesso come amministratore locale.

Valuta di dare agli sviluppatori due account.

Il primo è un normale account utente non privilegiato, che è quello da utilizzare per tutto il lavoro quotidiano (incluso lo sviluppo del software). L'altro è un account amministratore locale, che ha privilegi di amministratore solo su macchine specifiche. Dovrebbe essere necessario solo quando si installano cose o si modificano le impostazioni della macchina.

Assicurati che i servizi di tutti i giorni come il server proxy Internet, l'e-mail e così via riconoscano solo l'account normale, in modo che gli sviluppatori non possano semplicemente usare sempre l'amministratore locale. Ogni volta che sono richiesti i privilegi di amministratore, UAC apparirà e offrirà allo sviluppatore la possibilità di inserire i dettagli di accesso dell'amministratore locale per procedere.

Lo sviluppo del software è fondamentalmente diverso da qualsiasi altro uso di un computer e deve essere trattato come tale.

La capacità di scrivere il proprio codice e, soprattutto, di tracciare l'esecuzione del codice nel debug, richiede di disporre delle autorizzazioni sul proprio computer che, in qualsiasi altro contesto, costituirebbero un enorme rischio per la sicurezza locale. Sostituito in forma di morso di suono:

Le autorizzazioni necessarie per lo sviluppo del software non sono appropriate per gli utenti tipici.

Per svolgere il tuo lavoro, devi essere un amministratore locale. Ma essendo un amministratore locale e aggirando la politica di sicurezza, teoricamente stai mettendo a rischio il resto della rete. Quindi anche quella preoccupazione deve essere affrontata. Il modo in cui le aziende critiche per la sicurezza risolvono questo problema è imponendo due semplici regole:

1. I programmatori hanno accesso come amministratore locale sulla propria macchina di sviluppo.
2. Le macchine di sviluppo non sono connesse alla rete aziendale.

Il modo in cui viene riprodotta la seconda regola dipende dal dipartimento IT. A volte la macchina di sviluppo è isolata da sola senza rete in entrata o in uscita (vista in diversi appaltatori della Difesa), e talvolta la macchina è connessa a una rete "Ospite" o "DMZ" per consentire l'accesso a Internet (download di patch, accesso alla documentazione , ecc.) senza mettere a rischio la rete aziendale.

Ora, troverai qualche fonte ufficiale su questo? Immagino che dipende da chi vedi come ufficiale . L'opinione in merito è sostanzialmente unanime. Ma è così ben compreso che raramente viene affermato. È un po 'come chiedere: "La mia auto dovrebbe avere un freno di stazionamento? " Non troverai fonti autorevoli che parlano dell'argomento perché hanno cose migliori da fare e tutti sanno già quella risposta.

Puoi usare un ambiente virtuale?

Se non stai facendo cose pesanti per la grafica, allora eseguire MSVC in vmware o virtualbox va bene (se hai un sacco di ram), puoi avere l'amministratore nell'ambiente virtuale e la 'loro' installazione è bloccata