I diritti di "Utente" locale sono sufficienti o gli sviluppatori hanno bisogno di Amministratore locale o Power User durante la codifica?

Abbiamo un team di sviluppo offshore che ha una cattiva abitudine di installare software senza senso sui desktop aziendali (che non ha nulla a che fare con la loro funzione lavorativa) e quindi stiamo valutando la rimozione dei diritti di amministratore locale.

Amministratore locale o Power User locale è un requisito con VS2010? Come si esegue senza diritti elevati? In quali problemi ti imbatterai?

Un programmatore dovrebbe funzionare come utente limitato con accesso come amministratore. Cioè, il programmatore dovrebbe essere l'amministratore della macchina, ma durante il lavoro, dovrebbe sempre utilizzare un account utente limitato.

Se hai bisogno di diritti elevati per funzionare, per tutto tranne l'installazione del software, stai facendo qualcosa di molto sbagliato. Peggio ancora, se lavori come power user o disabiliti i prompt UAC o simili, stai ignorando i problemi che interesseranno gli utenti finali del tuo software, costringendoli a funzionare con gli stessi privilegi che hai fatto. Questo è sbagliato.

Questo è vero, indipendentemente dal sistema operativo in cui ti trovi. Anche se Windows sembra essere l'unico in cui si presenta.

Chiarire:

Quando dico che lo sviluppatore dovrebbe essere un utente limitato, intendo che dovrebbero avere diritti di amministratore completi per la macchina, ma quando testano il loro codice, dovrebbe essere fatto in un ambiente a utente limitato. Ad esempio, lo sviluppatore potrebbe utilizzare la macchina come utente abilitato all'amministrazione, ma esegue tutti i test in una macchina virtuale o in un account utente limitato. Su Linux, questo significa semplicemente che lo sviluppatore ha sudoaccesso; su Windows, ciò può significare un account a livello di amministratore con UAC e altre funzionalità di sicurezza completamente abilitate.

Questo è un problema politico o gestionale, non tecnico.

Prendi in considerazione l'idea di creare e comunicare una regola "non vogliamo che tu installi software non rilevante per la tua funzione lavorativa", in modo che il capo possa seguire di conseguenza.

A tale scopo, l'amministratore di sistema può richiedere a ciascun computer un elenco di programmi installati. Se lo fai su base regolare, puoi scrivere un piccolo programma per mostrare ciò che è stato installato, in modo da ottenere una rapida panoramica.

Detto questo, a meno che detti programmi non siano illegali o moralmente inaccettabili, allora perché questo è un problema in primo luogo?

Dipende da cosa ti aspetti che si sviluppino in modo indipendente.

Alcune cose come la configurazione IIS, il debug remoto, la modifica dell'accesso al GAC, la possibilità di eseguire il proprio MSI ne risentirebbero sicuramente. Se queste sono cose che ti aspetti che le risorse esternalizzate facciano in modo indipendente, non proverei senza molti test.

Se le persone esternalizzate stanno lavorando su un'app desktop che possono eseguire il debug a livello locale, è probabile che tu possa cavartela con pochi problemi.

Supponendo che stiano utilizzando il controllo del codice sorgente, è sempre possibile pianificare una re-immagine periodica delle macchine.

La maggior parte dei posti in cui ho lavorato occupano gran parte del primo caso e si aspettano un'elevata indipendenza, quindi tutti gli sviluppatori sono amministratori locali e la politica aziendale consente misure disciplinari se si installa software non approvato su qualsiasi macchina e causa problemi.

Ho bisogno dei diritti di amministratore per avviare Apache sulla porta 80 sul mio MacBook di sviluppo. A parte questo, non c'è motivo per cui non potrei essere su una macchina bloccata senza diritti di amministratore. E potrei usare una porta non standard, se ne avessi davvero bisogno. Dal punto di vista delle risorse aziendali, ha senso che gli sviluppatori non siano utenti privilegiati delle loro macchine.

Tuttavia, bloccare uno sviluppatore sulla propria macchina deve venire con un team di amministrazione reattivo e disponibile. Se non riesco a installare roba da solo, ho bisogno di qualcuno che possa farlo per me tritare e senza sottopormi a tre turni di scartoffie di approvazione al riguardo. Se l'impresa non è disposta a impegnarsi in questo, allora dovrebbe dare agli sviluppatori la piena corsa della loro scatola.

Preferisco il secondo, ovviamente, ma posso vedere la saggezza del primo.

Corro VS 2010 non come amministratore nella stragrande maggioranza delle volte. Ma se vuoi aggiungere o rimuovere un servizio, configurare IIS o armeggiare nel registro, avrai bisogno dei diritti di amministratore. Inoltre, alcuni degli strumenti di profilazione ti incoraggiano a riavviare VS come amministratore. Quindi penso che dare agli account offshore che non hanno poteri di amministratore impedirà loro di svolgere alcune (forse piccole) parti del loro lavoro.

Inoltre, con l'ascesa di UAC, sempre più app possono ora essere installate senza poteri di amministratore. Non inseriscono le cose in HKLM, non toccano nulla in System32, mettono l'exe da qualche parte sotto la cartella Users \ Whoever, e questo li rende molto più facili da rimuovere ma potrebbe non affrontare il punto originale che stanno installando " software senza senso "con cui presumo che tu intenda giochi, lettori musicali ecc.

Se vuoi davvero impedire le installazioni locali, forse la soluzione migliore è quella della vecchia visione di "la rete è il computer" dei primi giorni di Java. Tutti lavorano da un sistema di controllo della versione e devono effettuare il check-in o accantonare ogni notte prima di tornare a casa. L'e-mail vive nel cloud non sulla macchina di sviluppo. Ecc. Quindi, quando vuoi, puoi re-immaginare le loro macchine di sviluppo (ancora più facile se sono virtuali) e quelli che non avevano nulla in più installato non se ne accorgeranno nemmeno. Un po 'come pulire il frigorifero dell'ufficio durante il fine settimana.

Ma attenzione: non lavorerei in quell'ambiente. Installo programmi di utilità e aiutanti, e gioco occasionalmente e non accetterei gentilmente qualcuno che ha tentato di prevenire. Sono produttivo da morire. Se alcuni dei tuoi sviluppatori non sono produttivi, rimuovere le loro installazioni locali non li renderà più produttivi o dedicati. Risolvi quel problema alla radice e non ti dispiacerà che siano amministratori.

Suppongo che la rimozione dei diritti di amministratore dagli sviluppatori dovrebbe unirsi all'assegnazione di uno degli amministratori di sistema all'installazione di software per il team. Se entrambi non hai i diritti di amministratore e non puoi chiedere all'amministratore di installare roba per te, sei solo senza mani di fronte alle sfide che stai affrontando. È come se rinchiudessi in prigione la tua squadra offsore.

Dipende da cosa stai scrivendo il software.

Se il tuo software non ha bisogno di intromettersi nel tuo sistema, non sono necessari poteri di amministratore.

Una soluzione migliore: a scopo di installazione / test, è possibile utilizzare VM o computer di laboratorio di prova.

Ho visto due approcci a questo. Uno era far lavorare tutti dai computer portatili, che dovevano consegnare agli amministratori quando tornavano a casa. Una volta che l'amministratore lo aveva, si sarebbero attaccati a un CD che avrebbe ri-immagine la macchina. Una volta ridisegnato, è andato su uno scaffale, dove sarebbe stato disponibile per la persona successiva che ne aveva bisogno. Assicurati solo che tutte le macchine siano identiche, in modo da non finire con le persone che le percorrono tutte alla ricerca di una "buona".

L'altra cosa che ho visto è far avviare tutti da un server Citrix. Le macchine non dispongono di alcuna memoria locale, caricano semplicemente un'immagine standard dalla rete ed eseguono da quella. Funziona meglio se hai diversi "tipi" di utenti che richiedono diverse configurazioni (ad esempio, gli sviluppatori dell'interfaccia utente hanno un'immagine con Silverlight, gli sviluppatori WCF hanno IIS e SQL Server, ecc.)

MA, detto tutto ciò, penso che Thorbjorn [sic] abbia colpito l'unghia alla testa: questo è un problema di gestione e probabilmente non verrà affrontato adeguatamente con una soluzione tecnica.