Gli sviluppatori dovrebbero avere le autorizzazioni di amministratore sul proprio PC

Gli sviluppatori dovrebbero disporre delle autorizzazioni di amministratore sul proprio PC o è sufficiente fornire loro l'accesso per utenti esperti?

Alcuni commenti:

• Se vogliono provare qualche nuova applicazione che avrebbe bisogno di essere installata, potrebbero provarla su una macchina virtuale e in seguito chiedere all'amministratore di rete di installarla per loro. Pensi che funzionerebbe?
• C'è qualcosa che uno sviluppatore deve fare sul proprio PC che richiederebbe le autorizzazioni di amministratore?

Siamo un team di 5 sviluppatori e realizziamo applicazioni web

La risposta è si'. Gli sviluppatori dovranno cercare le configurazioni di sistema per testare gli elementi, installare il software (se non altro, per testare il processo di installazione di qualunque cosa stiano sviluppando), curiosare sul registro ed eseguire software che non funzionerà correttamente senza i privilegi di amministratore (solo per elencare alcuni elementi). Esistono molte altre attività integrali nel lavoro di sviluppo che richiedono i privilegi di amministrazione.

Tenendo presente che il personale di sviluppo non ha necessariamente l'accesso root ai sistemi di produzione, i diritti di amministratore su un PC locale non compromettono in modo significativo la sicurezza dei sistemi di produzione. Non esiste quasi alcun motivo operativo legittimo per limitare l'accesso dell'amministratore ai PC locali per il personale che ne ha bisogno per svolgere il proprio lavoro.

Tuttavia, il motivo più importante per fornire accesso amministrativo è che la creazione di un ambiente di sviluppo compromesso o di seconda qualità invia un messaggio al personale di sviluppo:

'Apprezziamo il tuo lavoro così poco che siamo pronti a compromettere in modo significativo la tua capacità di fare il tuo lavoro senza una buona ragione. In effetti, siamo abbastanza felici di farlo per coprirci il culo, assecondare i capricci della piccola burocrazia o perché semplicemente non possiamo essere disturbati. Questo è solo il caso migliore. Il caso peggiore è che siamo davvero il tipo di maniaci del controllo che lo vedono come il nostro perogativo per dirti come fare il tuo lavoro e cosa fai o non devi farlo. Accontentati di ciò che ti è stato dato e sii grato di avere un lavoro. "

Generalmente, fornire un ambiente di lavoro di seconda classe (figuriamoci fondamentalmente imperfetto) per lo staff di sviluppo è una ricetta per le conseguenze naturali di far incazzare il personale: incapacità di trattenere persone competenti, elevato turnover del personale, morale scarso e consegna di qualità scadente. Fare del proprio meglio per farlo - in particolare se c'è una sfumatura di assecondare il capriccio burocratico - è semplicemente irresponsabile.

Tieni presente che il turnover del personale non comporta solo costi di sostituzione del personale. Il costo più grave del turnover del personale è che la maggior parte di quelli che restano intorno saranno i deadwood che non possono ottenere un lavoro migliore. Nel tempo ciò degrada le capacità dei dipartimenti interessati. Se il tuo settore è sufficientemente vicino, puoi anche trovare una reputazione.

Un punto da notare è che i privilegi amministrativi sono molto meno un problema per lo sviluppo su sistemi unix-oid o mainframe rispetto a quelli su Windows. Su queste piattaforme un utente può fare molto di più nel proprio dominio senza bisogno di autorizzazioni a livello di sistema. Probabilmente vorrai comunque l'accesso root o sudo per gli sviluppatori, ma non avere questo ti rimetterà in piedi molto meno spesso. Questa flessibilità è una ragione significativa ma meno nota per la continua popolarità dei sistemi operativi derivati ​​da unix nelle scuole di informatica.

Gli sviluppatori dovrebbero avere il controllo completo e totale della macchina che stanno utilizzando. La maggior parte degli strumenti di debug richiede autorizzazioni di amministratore per collegarsi al runtime dell'applicazione che stanno creando.

Inoltre, gli sviluppatori scaricano e provano spesso nuove cose. L'aggiunta di ulteriori passaggi come la necessità di un amministratore di rete per arrivare e installare qualcosa per loro semplicemente frustra lo sviluppatore e renderà rapidamente la vita un inferno per la persona operante in rete.

Detto questo, dovrebbero essere un amministratore sulla LORO scatola, non sulla rete.

Sì e no.

Sì, consente di risparmiare molto tempo a disturbare il supporto del sistema.

No, i tuoi utenti non ce l'hanno, quindi non contare su di esso.

Sviluppiamo con autorizzazioni di amministratore e testiamo senza. Che funziona bene.

Amministratore locale sì, per tutti i motivi sopra indicati. Amministratore di rete no, perché saranno inevitabilmente coinvolti nelle attività di amministrazione della rete perché "possono". Gli sviluppatori dovrebbero sviluppare. L'amministrazione della rete è un lavoro completamente diverso.

Gli sviluppatori normalmente devono fare cose che la persona media non farebbe, e quindi dovrebbero normalmente avere account amministratore. Farli saltare attraverso cerchi imbarazzanti fa perdere tempo e li demoralizza. Potrebbero esserci delle eccezioni in situazioni di elevata sicurezza, ma se non puoi fidarti di qualcuno con un account amministratore, sicuramente non puoi fidarti del loro codice.

Dovrebbero anche avere un account disponibile con la stessa autorizzazione dei loro utenti (più di un account se il pool di utenti ha stati di autorizzazione diversi). Altrimenti, potrebbero semplicemente sviluppare qualcosa di interessante, distribuirlo e poi scoprire che non funzionerà per gli utenti.

Ci sono anche troppi modi per rovinare i computer con account admin (sì, l'ho fatto). Il dipartimento IT ha bisogno di una politica che reimmaginerà il computer di uno sviluppatore se non riesce a risolverlo rapidamente. In un posto presso il quale ho stipulato un contratto, ho dovuto firmare una copia di tale politica per ottenere il mio account amministratore.

Questa è una risposta piuttosto specifica per Windows. In Linux e in altri sistemi Unix-y, gli sviluppatori possono più spesso cavarsela solo con account utente, spesso non hanno bisogno di un altro account per il test (se hanno un account con cui possono fare a meno, sanno quando stanno usando il sudo, ma potrebbero averne bisogno con uno con le stesse autorizzazioni di gruppo) e possono causare incredibili danni al sistema operativo molto facilmente, quindi è necessario lo stesso criterio IT.

Sì, Half-Life 1 (e tutte le mod correlate: contrattacco, giorno della sconfitta, ecc.) Hanno bisogno dei diritti di amministratore (almeno per la prima manche, credo) per funzionare correttamente in Windows NT, 2000, XP, ecc. .

E che tipo di sviluppatore non gioca a Counter Strike all'ora di pranzo? (sicuramente uno schifoso)

Avendo sopportato il dolore di dover sviluppare senza i diritti di amministratore sulla macchina, la mia risposta può essere solo sì, è essenziale.

Assolutamente! In quale altro modo dovrei installare il download manager per scaricare film di notte?

A volte gli sviluppatori hanno davvero bisogno di installare cose o cambiare qualcosa nel sistema per testare qualche idea. Sarà impossibile se devi chiamare l'amministratore ogni volta che devi cambiare qualcosa.

Ho anche la mia osservazione personale sul fatto che alcuni amministratori tendano a stringere tutto ciò che è possibile per far sì che anche piccole cose dipendano da loro su base giornaliera, quindi ... cosa, assicurare il loro lavoro? incazzare gli altri utenti? Non ho risposta Ma il buon senso non si vede qui.

L'ultima volta che ho avuto un problema con il mio PC ho preso parte attiva al ripristino del sistema, facendo alcuni suggerimenti lavorando in team con l'amministratore, o almeno così pensavo ... L'amministratore si è rivelato molto arrabbiato e mi ha accusato di aver tentato di insegnare lui o ridefinire le regole. Suppongo che fosse solo il suo ego dato che non era stato visto così bene nella nostra stanza tra gli altri colleghi.

La risposta è che gli sviluppatori dovrebbero avere 2 macchine !!

• Uno di sviluppo che ha diritti di amministratore e sufficiente potenza, memoria, dimensioni dello schermo e portabilità e privilegi ADMIN, con software antivirus aziendale caricato ma configurabile dallo sviluppatore quando richiesto con criteri di autoreset.

• Uno aziendale con carico aziendale, criteri, privilegi di utente non amministratore, ecc ... Lo sviluppatore può utilizzarlo per applicazioni in modalità di rilascio di test di unità poiché alcuni sviluppatori hanno la cattiva abitudine di eseguire tutti i test di unità con privilegi di amministratore.

Se inverti la domanda, penso che diventa più facile rispondere; dovremmo rimuovere le autorizzazioni di amministratore dagli sviluppatori? Qual è il guadagno?

Ma in realtà, penso che la risposta dipenda dal tuo contesto, dal tuo ambiente. Le startup di piccole dimensioni avranno una risposta diversa all'agenzia governativa certificata ISO.

Sì, ma devono essere consapevoli delle limitazioni che i loro utenti dovranno affrontare quando eseguono software in un ambiente più limitato. Gli sviluppatori dovrebbero avere un facile accesso agli ambienti "tipici" con risorse e autorizzazioni limitate. In passato ho incorporato la distribuzione di build in uno di questi sistemi "tipici" (spesso una VM sulla mia workstation) come parte del processo di compilazione, in modo da poter sempre avere un'idea di come il software funzionava alla fine- macchina dell'utente.

I programmatori hanno anche la responsabilità di conoscere le regole rigide della scrittura di software per utenti non amministratori. Dovrebbero sapere esattamente a quali risorse di sistema sono sempre autorizzati (o vietati) di accedere. Dovrebbero conoscere le API utilizzate per acquisire queste risorse.

"Funziona sulla mia macchina" non è mai una scusa!

Come amministratore di sistema sono tutto per gli sviluppatori che dispongono dei diritti di amministratore locale sulle loro workstation. Quando possibile, non è una cattiva idea fare la maggior parte delle cose con un account standard a livello di 'utente' e quindi utilizzare un altro account 'admin' per apportare modifiche, installare app ecc. Spesso è possibile eseguire sudo o runas per ottenere ciò che si desidera senza nemmeno registrarsi su. È anche utile ricordarci quali sono gli ostacoli alla sicurezza che gli utenti finali dovranno superare quando rilasceranno alla produzione.

Inoltre, è consigliabile disporre di un sistema [clean] o VM (s) in modo da poter testare le cose correttamente e non entrare nello scenario "sembra / funziona bene sul mio sistema" a causa di modifiche al sistema.

Nessun utente esperto

Prima di tutto, Power User è fondamentalmente un amministratore - quindi " limitare " un utente a Power User non fornisce alcun aumento di sicurezza al sistema - potresti anche essere un amministratore.

Accedere interattivamente come un normale utente

In secondo luogo, ovviamente uno sviluppatore ha bisogno dell'accesso amministrativo alla propria macchina sviluppatore (e ai server, alle seconde caselle e così via) ma ovviamente nessuno dovrebbe accedere in modo interattivo come amministratore durante il normale sviluppo o test. Utilizzare un normale account utente per questa e la maggior parte delle applicazioni.

Non vuoi seriamente eseguire [inserire browser, plugin, messaggistica istantanea, client di posta elettronica e così via] come amministratore.

Normalmente non accedi nemmeno al tuo box Linux come root, anche se probabilmente hai accesso root quando ne hai bisogno.

Utilizzare un account amministratore personale separato

Fornire allo sviluppatore un account di amministratore personale separato sulla propria macchina (preferibilmente un account di dominio) che sia anche un amministratore valido su altri server / box di sviluppo / test a cui la persona necessita dell'accesso amministrativo.

Utilizzare "Esegui come" e in Vista + UAC per richiedere o richiedere prompt e immettere le credenziali amministrative per attività e processi solo quando necessario. La PKI con smartcard o simili può ridurre notevolmente la tensione nell'inserimento delle credenziali.

Tutti sono felici (o?;)

Quindi controllare l'accesso. In questo modo c'è tracciabilità e un modo semplice per scoprire chi sta usando le sessioni dei servizi terminal su un particolare server di sviluppo / test a cui devi accedere in questo momento ...

Certo, c'è sicuramente un lavoro di sviluppo che non richiederà mai i privilegi di amministratore locale - come la maggior parte dello sviluppo web in cui la distribuzione è testata su un server o una macchina virtuale separata e dove cassini o qualunque cosa sia usata per il debug locale funziona effettivamente come un normale utente.

Lavoro principalmente nel mondo * nix e il modello standard esiste per gli sviluppatori di lavorare in un normale account utente senza privilegi con la possibilità (tramite sudoo su) di aumentare i privilegi di amministratore come / quando necessario.

Non sono sicuro di quale sarebbe la disposizione equivalente di Windows, ma questa è, nella mia esperienza, l'impostazione ideale:

• Da un lato, avere i diritti di amministratore disponibili su richiesta fornisce allo sviluppatore pieno potere sulla sua workstation quando necessario.

• Dall'altro, il software Windows ha una lunga e lunga storia nell'ipotizzare che tutti gli utenti dispongano dei diritti di amministratore, al punto che molti programmi non verranno eseguiti per un utente non amministratore. Molti dei problemi di sicurezza di Windows derivano direttamente da questo requisito implicito che, per poter utilizzare il computer in modo affidabile, tutti gli utenti devono essere amministratori. Questo deve cambiare e il modo più efficace per garantire che il tuo software verrà eseguito per utenti non amministratori è che i tuoi sviluppatori lo eseguano da soli come utenti non amministratori.

[mi scuso l'inglese non è la mia lingua madre, facendo del mio meglio :)] Bene,

Esperienza personale (sono un dev c ++ / SQL):

Nel mio lavoro precedente ero amministratore del mio computer Windows. Avevo anche i diritti dbo (non dba) sui database, inclusi i database dell'ambiente di produzione. In 2 anni e mezzo con 8 persone con questi pazzi diritti ... non abbiamo mai avuto problemi. In realtà abbiamo risolto molti problemi aggiornando db manualmente. Potremmo fare molte cose molto velocemente per hotfix e sviluppatori.

Ora ho cambiato lavoro. Sono riuscito (piangendo molto) ad essere amministratore del mio computer Windows. Ma il server dev è un server red hat a cui ci connettiamo usando ssh. Cercare di installare Qt è stata una tortura, limiti di quote, limiti di spazio, diritti di esecuzione e scrittura. Alla fine abbiamo rinunciato e abbiamo chiesto all'amministratore di farlo per noi. 2 settimane dopo non è ancora installato nulla. Sto diventando molto veloce nella lettura dei giornali e nel colpire alt + tab.

Ho chiesto i diritti di amministratore, poiché solo lo sviluppatore del mio software usa questa macchina.

-> Risposta: "Se ci sono processi è per te di non fare quello che vuoi. Deve funzionare bene una volta dentro".

-> Sto cercando di spiegare a un manager non tecnico: "Non avrò alcun diritto di amministratore in alcun modo negli ambienti di produzione o UAT. Ma la mia macchina di sviluppo è diversa. Se dovessi costruire sedie invece di software, mi diresti che posso Non metti tutti gli strumenti che voglio nel mio laboratorio perché il mio laboratorio deve assomigliare al posto in cui verrà utilizzata la sedia? Offro un pacchetto eseguibile a uat. Le librerie e gli strumenti che ho usato per costruirli sono invisibili all'utente finale o al il tizio che installa il pacchetto ".

Sto ancora aspettando oggi. Ho trovato una soluzione, aprire un ambiente di sviluppo, andare dal tuo giudice online preferito, sfidare te stesso. quando qualcuno guarderà il tuo schermo, ti vedrà programmare. ;)

Puoi rispondere in due modi. Sì e no, o dipende. - Posso essere più vago ...

Dipende se è necessario che facciano il loro lavoro. In tal caso, concedi loro i poteri amministrativi sul proprio computer. In caso contrario, non farlo. Non tutto lo sviluppo del software richiede che un ingegnere disponga dei diritti di amministratore.

Sì e no dipende dalla tua visione. Alcuni ingegneri considerano il loro computer come il loro dominio e sono le regole del loro dominio. Altri non vogliono la responsabilità.

Ho lavorato presso un'azienda in cui non avevo i diritti di amministratore e ogni volta che dovevo fare qualcosa che richiedeva i diritti di amministratore, dovevo chiamare l'help desk e mi hanno concesso i diritti di amministratore temporaneo fino al riavvio. A volte questo era un dolore, ma era così che vivevo così. Ho anche lavorato in luoghi in cui ho pieno diritto di amministratore sul mio computer. Questo è stato fantastico, tranne per il tempo in cui ho installato alcuni software che nascondevano il sistema operativo e dovevo portare il mio computer all'help desk e far loro rivedere l'immagine del disco rigido ....

Personalmente ritengo che un ingegnere dovrebbe avere i diritti di amministratore del proprio computer, ma con la consapevolezza che se lo rovinano, una nuova immagine di base può essere ricaricata e perderanno tutto ciò che è stato fatto dalla linea di base originale. Tuttavia, non credo che tutti in un'azienda debbano avere i diritti di amministratore del proprio computer. Contabilità, assistenti amministrativi e altri dipartimenti non hanno davvero bisogno di avere quei diritti, quindi non dovrebbero essere concessi.

ht tp: //msdn.microsoft.com/en-us/library/aa302367.aspx

Nella mia esperienza, è sempre necessario un compromesso tra noi (programmatori) e loro (sicurezza). Lo ammetto (anche se odio farlo), c'è un merito nell'articolo di Microsoft sopra. Dato che sono stato programmatore per anni, ho sperimentato il dolore in cui dovevo solo installare un debugger diverso, solo per infastidire non posso. Mi ha costretto a pensare in modo creativo su come portare a termine il mio lavoro. Dopo anni di battaglie con il nostro team di sicurezza (e diverse discussioni), capisco il loro compito di proteggere tutte le aree, incluso il mio desktop. Mi hanno mostrato le vulnerabilità quotidiane che emergono, anche sulla più semplice app Quicktime. Riesco a vedere la loro frutrazione ogni volta che voglio installare una rapida utility o modificare il mio IIS locale per poter causare un grave problema di sicurezza. Non l'ho capito fino a quando non ho visto un altro sviluppatore essere inscatolato. Stava cercando di eseguire il debug e alla fine ha chiuso Symantec solo per ottenere (e poi DARE) un virus a centinaia di persone. E 'stato un casino. Parlando con uno dei "secheads" (ragazzi della sicurezza) di quello che è successo, ho potuto vedere che voleva solo dire "te l'avevo detto ...".

Ho imparato che le nostre teste (beh, almeno le mie) vogliono solo proteggere la nostra azienda. La buona notizia è che abbiamo trovato un compromesso e posso fare il mio lavoro e i secondi sono fantastici con la nostra rete sicura!

Credo

Sì, se desideri che i pentesters o alcuni abili utenti malintenzionati prendano piede sulla compromissione del tuo dominio.

vale a dire Compromettere un account di basso livello> Trova dove admin -> Mimikatz -> Elevate autorizzazioni -> Domain admin.

Quindi no, gli utenti normali non dovrebbero essere amministratori.

Inoltre Microsoft ha affermato che UAC non è un limite di sicurezza, quindi non utilizzarlo come tale. Sono disponibili vari bypass reali del controllo dell'account utente.

Se hanno bisogno dell'amministratore come parte del loro ruolo professionale, distribuisci account utente di dominio locale separati utilizzati per l'installazione del software (con autorizzazioni di amministratore solo sulla propria macchina), mai per uso generale o accesso a Internet. Questo dovrebbe avere una politica di password più rigorosa (ad esempio una lunghezza minima di 15 caratteri). La funzionalità di Runas dovrebbe essere usata per questo.

Qualsiasi ambiente in cui gli account utente normali sono admin è una ricetta per un disastro di sicurezza.

Caspita, questa domanda si aprirà sicuramente ad alcune risposte interessanti. In risposta cito spesso usato: "Dipende" :)

Nelle piccole aziende questo potrebbe essere semplicemente una questione di essere pragmatico. È probabile che anche gli sviluppatori siano i più esperti tecnicamente, quindi ha senso amministrare le proprie macchine.

Personalmente, sono un fan dell '"account amministratore" che può essere utilizzato quando necessario, ad esempio "Esegui come .." (Ho notato che questo approccio è stato molto simile in principio al controllo dell'account utente in seguito).

Se si sta sviluppando un software desktop non è una cattiva idea per gli sviluppatori lavorare entro i limiti che sperimenteranno i loro utenti finali, ovvero diritti limitati o limitati. Se si sviluppa il software con diritti limitati, è una buona probabilità che si verifichino gli stessi problemi che gli utenti target devono affrontare, dato lo stesso set di autorizzazioni.

Detto questo, se hai un buon laboratorio di test e / o un discreto team di QA questo potrebbe essere un punto controverso, specialmente se hai una pratica ALM quasi decente.

Quindi, alla fine, mi sviluppo senza controllo dell'account utente, principalmente perché mi fido di me stesso e delle mie capacità. In un ambiente di squadra, lo metterei ai voti. Nelle organizzazioni più grandi potresti non avere questa libertà .. Gli Enterprise Admins hanno spesso l'ultima parola :)

Nella mia azienda, sviluppatori, ingegneri e il mio capo (proprietario dell'azienda) hanno il privilegio di amministratore locale. Il mio capo ha anche il privilegio di amministratore di rete, nel caso in cui venissi colpito da quel bus ribelle (o uscissi). Tutti gli altri vengono bloccati.

Come amministratore di sistema, questa configurazione mi ha causato un po 'di dolore di tanto in tanto, soprattutto quando viene installato un software non approvato. Tuttavia, provenendo da un background di sviluppatori, capisco la necessità per gli utenti esperti di avere un maggiore controllo sul proprio ambiente e, come tale, sono disposto a sopportare la stranezza occasionale o il problema che potrebbe emergere. Eseguo backup di routine delle loro workstation - per ogni evenienza.

A proposito, ho avuto più problemi con il capo che armeggiava con le cose che con chiunque altro. Un po 'come la vecchia domanda, "Dove si trova un elefante? Ovunque voglia!" Ma in una piccola azienda in cui è essenzialmente il sistema di "backup", non c'è molta scelta.

Dipende dalle capacità dello sviluppatore e dal fatto che sia un consulente o meno.

Penso che sia ragionevole che uno sviluppatore esperto e affidabile abbia i diritti di fare tutto ciò che vuole con il suo PC, purché ciò non danneggi la sua produttività.

Nessuno su Windows XP dovrebbe usare un account amministratore per l'uso quotidiano e in Vista se devi essere un amministratore almeno avere UAC abilitato. Soprattutto gli sviluppatori web e altri sviluppatori che navigano sul web con Internet Explorer.

Quello che puoi fare è fare in modo che gli sviluppatori utilizzino il loro account utente normale, ma assegnano loro un secondo account che è un amministratore sul loro PC in modo che possano usarlo secondo necessità (Esegui come). So che hanno detto lo sviluppo web, ma per lo sviluppo di Windows il tuo software dovrebbe essere testato utilizzando un account utente normale, non come amministratore.