È comune consentire l'accesso all'amministratore locale per gli sviluppatori nelle organizzazioni?

Ecco un punto dati da una società di software che ha un interesse per la sicurezza. So che questo è comune in organizzazioni simili.

C'è un numero di reti. Sono fisicamente separati e dotati di airgapp, utilizzano cavi di rete con diversi colori.

Ogni dipendente ha una macchina di 'amministrazione', che può connettersi a Internet (tramite un proxy) per fare e-mail, ecc. Tutti gli utenti sono severamente bloccati e il dispositivo e il controllo degli accessi sono rigorosi.

Oltre a questo, ogni sviluppatore ha una macchina 'ingegneristica'. Questo ha un accesso amministratore completo e l'utente può fare quello che vuole. Tuttavia è collegato solo alla rete di ingegneria (nessuna via verso Internet).

Nella maggior parte dei contesti di sviluppo software questo potrebbe essere visto come estremo, ma in organizzazioni che hanno requisiti contrastanti di elevata sicurezza e libertà di sviluppo, questa è una soluzione comune.

Per rispondere alla tua domanda, sì è comune consentire agli amministratori l'accesso all'amministratore, ma questo non significa sempre l'accesso amministrativo a una macchina che potrebbe causare problemi di sicurezza delle informazioni.

Secondo la mia esperienza, è comune per gli sviluppatori avere l'accesso amministrativo sulle proprie macchine. È anche comune per loro non avere l'accesso di amministratore sulle proprie macchine. Tuttavia, in quest'ultima situazione alcuni alloggi sono generalmente realizzati in modo che possano svolgere il loro lavoro senza troppi freni.

Una sistemazione molto comune è l'accesso a Hypervisor sulla workstation (indipendentemente dalla versione di VMWare o Hyper-V fornita con Windows), insieme alle autorizzazioni specifiche necessarie per creare e distruggere le VM all'interno di tale hypervisor, se necessario, ^{( Hyper-V / VMWare )} , inclusa la creazione di macchine virtuali in cui hanno diritti di amministrazione per il SO guest. In genere alcune di queste macchine virtuali durano a lungo, anche se non vengono eseguite continuamente, dove raramente si tratta di dover preparare un'intera VM da zero solo per fare ciò che dovrebbe essere un test rapido per qualcosa che richiede l'amministratore privilegi.

L'Hypervisor può o non può essere configurato per consentire l'accesso a Internet per le sue VM; L'ho visto in entrambi i modi, anche se personalmente mi piace strongmente che l'accesso a Internet dovrebbe essere permesso ... almeno per i tipi di sviluppo con cui ho più esperienza. Ma l'accesso a internet, quando concesso, può e deve essere configurato almeno per forzare le VM in un vlan dedicato, separato dal resto della rete aziendale. Non sono sicuro che sia possibile applicare direttamente tramite Hyper-V o VMWare, ma è possibile utilizzare 802.1x sulle porte per molti switch di rete per impedire l'accesso a determinate vlans da macchine non autorizzate, incluse le macchine virtuali devianti. Quindi puoi dare un piccolo tutorial agli sviluppatori su come impostare un tag vlan in una VM e far sapere loro quali tag vlan saranno permessi sulla loro porta switch. Ho anche visto questo rafforzato attraverso la formazione semplicemente come un editto politico, piuttosto che tramite misure tecniche, con forse l'occasionale audit amichevole per incoraggiare la conformità e assicurarsi che gli sviluppatori sappiano che è importante.

E, naturalmente, questo coincide con la fornitura agli sviluppatori di macchine sufficientemente potenti per eseguire più macchine virtuali contemporaneamente.

Lavoro per una società di gestione degli investimenti abbastanza grande (circa 6000 dipendenti) e gli sviluppatori sono uno dei gruppi che approviamo per l'accesso all'amministratore locale. Diciamo loro di non installare alcun software, poiché questo è gestito dalla conformità desktop / software locale.

Abbiamo anche un gruppo di sviluppatori AD che consente ai membri di modificare la politica di esecuzione sulle loro macchine senza richiedere l'amministratore locale.

Nella mia carriera, con aziende piuttosto piccole (meno di 100 persone), abbiamo sempre avuto diritti di amministratore locale. Disponiamo di macchine desktop reali che sono gestite dall'IT, ma ne abbiamo i diritti, oppure ci è stato concesso di avere macchine virtuali di ogni tipo che siamo completamente gestite da noi.

Se non avessimo accesso all'amministratore locale, proveremmo ogni sorta di "soluzioni" sbagliate che, come nel tuo caso, portano a una minore sicurezza. Questo è uno di quei casi in cui le restrizioni portano effettivamente al contrario delle loro intenzioni.

In un reparto piuttosto piccolo di un'organizzazione più grande (~ 100 in reparto, ~ 3500 in organizzazione completa) abbiamo scelto una soluzione in mezzo :

• gli amministratori di sistema hanno 2 account, uno (non amministratore anche per il computer locale) che è stato utilizzato per attività non amministrative (posta, edizione di documenti, ecc.) e uno con privilegi di amministratore AD che dovrebbe essere utilizzato solo per l'amministrazione di Active Directory
• tutti gli altri utenti avevano un solo account non amministratore
• devs (e alcuni power user ) sono stati forniti un account locale con i privilegi di amministratore della macchina locale. Doveva essere usato raramente quando era richiesta l'amministrazione locale.

Rifiutare i diritti di amministratore per gli sviluppatori sarà una causa di perdita di produttività e questo ha un costo immediato per qualsiasi organizzazione. La scelta di concedere i privilegi di amministratore sul computer locale all'account principale o ad un account secondario dovrebbe dipendere dalla frequenza dell'operazione dell'amministratore:

• Se più di più volte al giorno, consiglierei di utilizzare l'account principale.
• Se meno di una volta alla settimana, utilizzerei un account secondario.

Scegli il tuo se ti trovi tra ...

Secondo la mia esperienza, consentire e negare l'accesso all'amministratore locale è comune, tanto quanto i workaround sporchi per quest'ultimo. - Quindi dovresti chiederti:

Quale minaccia alla tua rete è peggiorata dai diritti di amministratore locale?

A cui la risposta deve essere: NONE - L'accesso alle risorse nella rete deve essere limitato per utente, completamente estraneo al fatto se questo utente ha root locale, admin o masterOfTheUniverse accesso sulla sua macchina. Se l'utente ha il diritto di far esplodere la tua rete, un virus locale non ha nemmeno bisogno di un accesso amministratore, può semplicemente usare l'account utente per far esplodere la tua rete. - E se l'account utente non può accedere a qualcosa sulla tua rete, i diritti di amministratore locale non cambieranno nulla in merito.

Devi affidarti ai tuoi sviluppatori per gestire la propria macchina in modo responsabile e, con una ragionevole configurazione di sicurezza nella tua azienda, i diritti di amministratore locale dovrebbero essere pericolosi solo per una cosa: la macchina locale. Quindi l'unico rischio che accetti dando un amministratore locale è che uno sviluppatore rompa la sua stessa macchina (cosa che può già fare con una tazza di caffè).

Addendum: devi concedere ai tuoi sviluppatori la possibilità di utilizzare i diritti di amministratore locale ogni volta che ne hanno bisogno. Questo non significa che dovrebbero essere connessi con un account amministratore non protetto tutto il tempo, ma dovresti aver fiducia che lo utilizzino in modo ragionevole ogni volta che ne hanno bisogno, senza chiedere il permesso ogni volta.

Perché gli sviluppatori dovrebbero avere i diritti di amministratore locale

I tuoi sviluppatori sono persone a cui affidare la progettazione delle operazioni principali della tua attività. La maggior parte delle aziende oggi dipende molto dal proprio software, quindi gli sviluppatori sono una risorsa vitale per dare forma a una parte molto importante della tua azienda.

Prima di tutto c'è il vantaggio di una maggiore produttività, perché lo sviluppatore può semplicemente configurare, installare e testare tutto ciò di cui ha bisogno sulla sua macchina locale. Potrebbe aver bisogno di determinati software, strumenti di supporto o configurazioni insolite per sperimentare determinati aspetti del suo software (ad esempio, eseguire il suo software su una versione precedente di un sistema operativo o con driver / SDK meno recenti).

In secondo luogo c'è il vantaggio (a mio parere ancora più grande) di mostrare ai tuoi sviluppatori come li apprezzi. Mostrate loro che vi fidate di loro con la loro stessa macchina - trattate i vostri sviluppatori come persone sicure responsabili dell'IT che possono amministrare la propria macchina senza una baby-sitter. (In molte aziende in cui gli sviluppatori non ottengono l'amministratore locale, dovranno chiedere supporto tecnico o sicurezza per ogni installazione / configurazione di cui hanno bisogno e in molti casi queste persone di supporto tecnico conoscono meno il software rispetto al principale sviluppatore principale , ma devono ancora elemosinare per le cose di cui hanno semplicemente bisogno per svolgere il proprio lavoro, il che può essere molto frustrante.)

Nella mia esperienza di lavoro per organizzazioni più grandi, non è assolutamente comune per gli sviluppatori avere pieni diritti su qualcosa di diverso dalle risorse specifiche dello sviluppo.

Sembra che la tua organizzazione si trovi al confine tra piccoli e grandi, quindi ...

Sembra che sia giunto il momento per la tua organizzazione di sviluppare alcune pratiche di sviluppo più mature.

Per essere onesti, questo tipo di cambiamento non è qualcosa su cui i gruppi operativi dovrebbero sorprendere i team di sviluppo, come sembra sia stato fatto nel tuo caso.

La sicurezza e la produttività degli sviluppatori non devono opporsi l'un l'altro per la tua azienda. È possibile evitare completamente questo conflitto eseguendo le attività di sviluppo su una rete che non ha accesso alle risorse sulla rete aziendale principale.

In ogni caso, non stai sviluppando lo sviluppo rispetto alle tue risorse di produzione, giusto?

Se lo sei, non dovresti essere - introduce un rischio significativo per le tue risorse, in particolare per la loro disponibilità.

È molto più pratico avere un intero ambiente di sviluppo che replica porzioni chiave di funzionalità e set di dati (senza esporre qualcosa come informazioni private su persone reali nella tua azienda). Questo ambiente replicato rende la separazione abbastanza semplice. I tuoi sviluppatori hanno bisogno del pieno controllo delle macchine in questo ambiente di sviluppo. Non hanno bisogno del pieno controllo delle risorse al di fuori dell'ambiente di sviluppo.

Esistono diversi modi per implementare un ambiente di sviluppo separato:

• Hardware completamente separato (workstation, server, dispositivi di rete, ecc.), connesso a Internet o no
• Ambienti virtualizzati (compresa la rete virtuale); ospitato sul tuo hardware o con un provider di servizi cloud e con o senza accesso a Internet
• Una combinazione dei due approcci sopra

Puoi anche implementare una sorta di bridge (se non stai già utilizzando un servizio di qualche tipo già) per qualsiasi condivisione devi eseguire all'interno e all'esterno dell'ambiente di sviluppo.

Gli ambienti di sviluppo dovrebbero essere protetti come la maggior parte delle reti. Non limitarti a lanciare online tutto il tuo codice e le risorse di sviluppo senza pensare ad accedere al controllo o alle misure di sicurezza di base.

Ho anche visto alcuni posti fare un ulteriore passo avanti e scrivere tutto il loro codice in un unico ambiente, quindi creare / distribuire tutto in un altro ambiente completamente separato per i test di integrazione.

Prima di tutto devi sapere che non importa cosa sia "comune" o "tipico" perché: in genere tali situazioni vengono gestite in modo orribile . Stai facendo il meglio per questa affermazione.

Se l'accesso all'amministratore locale è necessario per una persona (che si tratti di un appaltatore o di un dipendente), allora l'obbligo del team di sicurezza / persona - chi è responsabile di quella particolare area - di trovare una soluzione. Esistono molteplici soluzioni: creare una VLAN isolata, macchine virtuali e altre sono state nominate qui.

Non ha alcun senso informarsi sulla configurazione di altre organizzazioni solo per sentire "abbiamo anche diritti di amministratore sulle nostre macchine". Non troverai un'infrastruttura esattamente uguale alla tua. L'unica cosa che conta è che il team di sicurezza / persona pianifichi una soluzione sicura che viene poi implementata dal reparto IT in questa particolare organizzazione.

Se la soluzione che è stata implementata non funziona correttamente ed è quindi ancora in grado di rendere impossibile lavorare, richiamalo di nuovo con il team di sicurezza / persona. Se questo non funziona, portalo al tuo capo o al tuo contrato.

Ciò che stai facendo in questo momento sta bruciando denaro e nient'altro. Se gli altri partecipanti a questo gioco non lo hanno capito, ora è male. Ma è buono se lo fai.

Questo dipende fondamentalmente dal contesto e, in particolare, dal tuo modello di minaccia.

In alcune organizzazioni, è comune dare agli sviluppatori il controllo completo sulla loro workstation di sviluppo, al punto da consentire loro di installare il proprio sistema operativo su di esso.

In alcune organizzazioni, tutto lo sviluppo deve essere fatto in un ambiente con aria compressa, che nessun dispositivo elettronico può essere portato dentro o fuori.

La maggior parte delle organizzazioni cade da qualche parte tra questi due estremi. Più l'ambiente di sviluppo è bloccato, meno gli sviluppatori saranno produttivi e più è probabile che tu perdi il tuo talento migliore. La tua organizzazione deve valutare la probabilità e l'impatto di una workstation per sviluppatori compromessa e quanto sono disposti a ridurre la produttività degli sviluppatori per mitigare questo rischio.

Ho visto due approcci che funzionano.

1. Offri agli amministratori l'accesso alle loro macchine. Questo è l'approccio più semplice e più comune. Di solito è la scelta migliore
2. Crea un team nell'organizzazione il cui intero lavoro è per garantire che gli sviluppatori possano lavorare senza l'accesso di amministratore. Questa squadra di solito sarà di 3-4 persone. Scoprirai che i requisiti hardware degli sviluppatori aumentano notevolmente man mano che utilizzerai container e / o VM, quindi budget per l'acquisto di nuovo hardware per tutti gli sviluppatori. Quando esci, inizia con un team di early adopter, quindi sposta gradualmente tutti gli sviluppatori su una macchina senza accesso da amministratore. Questo processo richiederà almeno sei mesi.

Se fai ciò che la tua azienda sta facendo ora, i tuoi sviluppatori lo tollereranno per un mese circa, quindi inizieranno a cercare nuovi posti di lavoro.

Il problema che hai effettivamente è che l'IT competente sta tentando di imporre una regola a una testa di ossa. Hai solo una scelta, concedi agli sviluppatori un accesso amministrativo efficace.

Continuo a vedere lo stesso consiglio ripetuto all'infinito, che si riduce a una seconda macchina che lo sviluppatore ha amministratore ma senza internet. Se vuoi avere la sicurezza del formaggio svizzero, questa è la strada da percorrere. Gli elenchi di software installati sul computer di un tipico sviluppatore sono generalmente più lunghi di uno schermo. Molti di questi hanno solo un'opzione per controllare gli aggiornamenti - internet. Non è possibile eseguire la patch tramite WSU perché WSU non sa che esistono.

Ecco cosa non comprendono gli argomenti: la violazione degli account personali dello sviluppatore non è un punto di partenza; è il jackpot. Non c'è motivo di andare per l'amministratore da lì. Il breacher ha la capacità di modificare il codebade per inserire backdoor. Guadagnare l'amministratore nella casella dello sviluppatore non è molto più interessante.

A cosa ti stai difendendo quando vuoi negare l'amministrazione? Qualcuno sta accedendo al codebase? No. Qualcuno lo usa come punto di partenza? Se la tua LAN di produzione non è protetta dalle tue scatole di sviluppo stai facendo qualcosa di sbagliato. Gli sviluppatori che installano cose che non dovrebbero? No. Lo sviluppatore ha un compilatore ed esegue l'output del codice dal compilatore. Potrebbe anche essere la definizione di esecuzione di software non approvato.

Ho sentito molte storie sulla politica secondo cui gli sviluppatori non ottengono l'admin, ma la pratica dell'IT guarda dall'altra parte mentre gli sviluppatori hanno rovesciato la politica di sicurezza. Ho sentito molti altri IT che non hanno mai scoperto. Ho sentito alcuni dei responsabili dello sviluppo dire agli sviluppatori di ignorare i controlli di sicurezza.

Prima o poi, le organizzazioni imparano a dare solo l'amministratore degli sviluppatori. La maggior parte di quelli che probabilmente non finiscono per averlo fatto senza saperlo davvero.

È molto più saggio dare semplicemente l'amministratore locale di devs su una casella connessa a Internet e al dominio locale ed essere pronti ad affrontare qualunque possa essere la conseguenza. Proteggi invece la produzione. Ci sono meno persone che dovrebbero accedere alla produzione con un alto livello di privilegio, quindi il blocco è più facile e le organizzazioni competenti imparano a farlo.

Ma improvvisamente portare via admin come questo porta quasi sempre alla perdita degli sviluppatori più importanti. Non vuoi quello.

Poiché vuoi parlare di siti Windows, esiste un aneddoto che supera i dati della maggior parte delle persone. Microsoft fornisce i suoi sviluppatori admin locale. Il produttore di Windows ha concluso che non vi è un vantaggio sufficiente a non concedere agli amministratori di devs per renderlo utile. Pertanto, dovresti fare lo stesso.

Ho lavorato per qualche tempo per un'azienda che crede davvero nella sicurezza (o almeno così pensano).

Di tanto in tanto organizzano un evento sociale, come giocare a bowling. L'iscrizione è gratuita, ma è necessario aggiungere il proprio nome a un elenco in un file Excel, inserito in una cartella condivisa. Quella cartella era dedicata agli eventi sociali, nient'altro.

Quindi, vuoi giocare a bowling? Vuoi aggiungere il tuo nome a quella lista? Ohhhhhhhhhh, caro ... Non è che possano permettere a tutti di modificare quel file, vero? Devi chiedere le autorizzazioni appropriate.

Questa è la procedura:

• Apri il sito della società
• Trova la sezione con alcuni moduli pronti per essere compilati
• Trova e scarica il documento chiamato "Foglio di rilascio"
• Stampa
• Compilalo con la tua richiesta e firmalo
• Consegnalo alla segretaria
• La segreteria prenderà tutte queste richieste al gestore la mattina del giorno successivo
• Prima o poi il gestore lo firmerà
• Il segretario te lo riporterà
• A questo punto puoi scansionarlo
• Apri il sito utilizzato dall'IT per gestire i ticket
• Creare un ticket che descriva (di nuovo) ciò che è necessario e allegare il foglio di rilascio scansionato. Non dimenticare di impostare l'urgenza, da un'ora a due settimane.
• Alla fine l'IT lo farà (si spera)

In media, ci vorranno 3-4 giorni per farlo. In alcuni casi, settimane. Davvero efficiente, eh? Ehi, hai chiesto l'accesso a una certa cartella ma hai dimenticato di menzionare la sottocartella? HA! Hai vinto un altro round! E indovina cosa? Dal momento che stavano seguendo alcuni processi di controllo qualità, stavano organizzando documenti in molto di cartelle diverse. Quando è arrivato un nuovo collega, potrebbe facilmente trascorrere settimane cercando di ottenere tutte le autorizzazioni necessarie.

Ora.

• Pensi che i manager si siano presi la briga di controllare cosa stavano firmando? Certamente no. Hanno riconosciuto il foglio di rilascio, ed è stato così.
• Pensi che i segretari stessero controllando molto di più? Forse ci hanno provato, ma possono davvero capire le implicazioni di darmi il permesso di lettura / scrittura su una determinata cartella su una determinata macchina? Certamente no.
• Pensi che l'IT gli abbia dato qualcosa per l'urgenza? Certamente no.

Quindi, a cosa è servito questo approccio? Che se volevi rubare tutto ciò che la compagnia avesse mai fatto, dovevi semplicemente portare un'unità USB e collegarla al PC. Nessun accesso alla cartella "Confidential_Documents"? Chiedilo, lo firmeranno. E se è urgente? "Ciao, ho bisogno di quel documento ma non posso accedervi, puoi darmi la tua password?"

Quindi, questo "modello di sicurezza" era incredibilmente lento, goffo e frustrante, e non proteggeva affatto le loro proprietà, ma almeno nessuno poteva facilmente confondere i partecipanti con l'evento di bowling ( obbligatorio xkcd ).

Per favore, non essere quella compagnia. Come altri hanno detto: non chiedere se è comune (lo è), basta chiedere se ha senso. E la risposta è: no, non è così, a meno che alla tua azienda piaccia bruciare denaro.

Sì e no - i nostri sviluppatori senior hanno un account amministratore separato che consente loro di elevare quando necessario e installare applicazioni / aggiornamenti. Non sono tuttavia autorizzati ad accedere al computer con l'account. Il loro account di amministratore consente inoltre agli amministratori l'accesso ai normali computer di sviluppo per fornire un supporto più rapido rispetto al team IT.

Tutto questo è combinato con un'applicazione white / blacklist, policy per password complesse, divieto di dispositivi rimovibili, proxy gateway, criteri DLP, regole AV stringenti e altro ancora. Le loro macchine sono regolarmente controllate e la visibilità del team IT è elevata.

Personalmente, preferirei che gli sviluppatori non avessero accesso all'amministratore locale. Potremmo esaminare le app che hanno bisogno di UAC (trovare le cartelle, i regkeys ecc. Di cui ha bisogno) e attenuare il prompt UAC, ma ciò richiede tempo e ricerca e non tutte le aziende hanno le risorse per farlo. Quindi, li incontriamo a metà strada e ci aspettiamo fiducia a due vie. Usiamo anche diversi prodotti aziendali per far rispettare una moltitudine di regole, quindi c'è un po 'di sollievo in questo.

Abbiamo risolto questo problema utilizzando un computer virtuale .

Ogni sviluppatore ha un account utente normale senza diritti di amministratore. All'interno di quell'account utente c'è una macchina virtuale senza accesso a Internet. All'interno della macchina virtuale lo sviluppatore può eseguire la sua applicazione con diritti di amministrazione.

In questo modo possiamo separare l'accesso a Internet e i dati importanti dall'utilizzo dei diritti di amministrazione, ottenendo comunque un modo per eseguire i programmi necessari in un ambiente chiuso.

Sono nella stessa barca degli sviluppatori di software. La nostra azienda è passata di recente da workstation con accesso di amministratore a macchine virtuali senza. Ha avuto un impatto notevole sul nostro flusso di lavoro talmente tanto che mi sono ritrovato a non fare nulla se non leggere articoli per il reparto IT per eseguire qualcosa come amministratore per me.

La cosa che la gestione ha creato era un approccio due macchine virtuali .

Una delle nostre macchine virtuali era una macchina aziendale di base con email, accesso Web e Microsoft Suite. Questo ha soddisfatto la necessità di comunicare.

L'altra macchina virtuale disponeva di diritti di amministratore locale , ma era completamente disconnesso da Internet . In questo modo, non abbiamo potuto scaricare nulla su quella macchina. (Anche se siamo ancora in grado di scaricarlo dagli altri e copiare il download su ..) Abbiamo ancora accesso ai siti interni e abbiamo autorizzato un paio di cose sugli usi dello studio visivo (Nuget, Simboli, ecc.)

Questo approccio ha lasciato il reparto IT soddisfatto in termini di sicurezza, e ci ha anche restituito l'accesso amministrativo.

L'unica cosa negativa è che non possiamo usare i nostri due monitor per una sola macchina poiché avevamo bisogno che ogni macchina fosse sul proprio monitor, ma di solito usavamo solo uno schermo per il codice e l'altro per la navigazione web comunque.

Risposta breve : Sì, è normale avere l'accesso amministratore locale a gruppi selezionati, come sviluppatori o amministratori IT. In sostanza, le persone il cui lavoro giornaliero è molto più semplice con l'accesso come amministratore, mentre il solito impiegato avrebbe bisogno al massimo una volta al mese e in genere molto meno.

Risposta lunga : dipende ...

Per la popolazione di utenti generale, non è necessario eseguire un'analisi completa dei rischi per capire che l'accesso all'amministratore ha un sacco di potenziale per le cose che vanno male e piccoli vantaggi per compensare tale rischio.

Tuttavia, per gli sviluppatori (e alcuni altri gruppi), un'analisi dei rischi è sicuramente giustificata e viene richiesta una decisione appropriata in base ai fatti, alle circostanze, alla propensione al rischio e alla situazione delle minacce dell'azienda. Indicare le "migliori pratiche" e fare una mossa annullata di taglia unica è una fuga tipicamente causata dalla persona responsabile della sicurezza delle informazioni che non ha il tempo e / o la conoscenza necessari per eseguire i numeri e inventare una decisione di trattamento del rischio basata sui fatti.

Ciò non significa necessariamente che siano sbagliati . Un'analisi completa potrebbe benissimo portare alla stessa conclusione.

Al punto che sei, da ciò che scrivi, che è uno sconosciuto. Potresti chiedere una corretta analisi dei rischi, aggiungendo le tue conoscenze specialistiche al costo del lato di mitigazione dell'equazione, mettendo in numeri la produttività persa e altri effetti della misura attuale. Questo deve essere valutato rispetto al rischio che le persone che identificano la sicurezza delle informazioni.

Esistono anche altre misure correlate. Una soluzione tipica che a volte raccomando (sono un architetto della sicurezza delle informazioni di professione, così mi viene posta questa domanda su base regolare) è quella di separare la rete di sviluppatori dalla rete ordinaria dell'ufficio per contenere l'area a rischio più elevato. Indurisci sufficientemente le macchine sviluppatore e insisti sui firewall locali e sulla protezione antivirus aggiornata e stai bene contro i tipici scenari di attacco. Se la tua azienda ha un po 'di esposizione esterna, potresti anche aggiungere un ulteriore addestramento di sensibilizzazione per gli sviluppatori in modo che non cadano in preda facilmente agli attacchi mirati.

Ho supervisionato personalmente gli ambienti di sviluppo di entrambi i tipi e con un piccolo sforzo entrambi possono essere fatti per funzionare bene. Staccare la spina su un modo di lavorare stabilito era di gestirlo male e la reazione di cui eri parte era prevedibile. Ma ciò che è fatto è fatto ed è probabilmente intelligente non focalizzarsi su quello e guardare al futuro.

Nonostante MS-Windows NT sia stato un sistema di sistema multiutente sin dal suo inizio, non è davvero facile gestirlo in questo modo, e gli sviluppatori (incluso quello di Micosoft) tendono ancora a ignorare l'idea della separazione dei privilegi. Questo tipo di controllo degli accessi è scarsamente documentato, tende a non essere presente nella formazione, spesso difficile da accedere tramite l'interfaccia utente, difficile da controllare, mancanza di schemi / strumenti per applicare la separazione ....

In tutta onestà, anche su sistemi Unix / Linux, vedo che molti sviluppatori non riescono a utilizzare la separazione dei privilegi in modo appropriato sia per gli utenti reali che per i servizi. Ma su qualsiasi piattaforma, porre barriere nel modo in cui implementare i privilegi di separazione è ancora più controproducente per la sicurezza che dare loro i privilegi di amministratore (locali) completi .

D'altra parte, mentre so poco sullo sviluppo su MS-Windows, trovo sorprendente che sia richiesto il privilegio di amministratore locale per eseguire Visual Studio. E se l'unica ragione per cui hai bisogno dell'accesso come amministratore è arresto / avvio di servizi o riconfigurazione, quindi non ho molta simpatia per voi: è possibile fornire questa funzione agli utenti designati senza dare loro l'amministratore locale. Uno dei grandi cambiamenti in IIS7 è stato amministratore delegato capacità. Ed è sempre stato facile delegare la riconfigazione di Apache, MySQL e PHP.

there was short notice of when the local admin access was removed

Sembra che il problema sia il team di sicurezza che aspira a un livello di competenza che non sono in grado di fornire (questo, nella mia esperienza, è molto comune). Non dovrebbero aver imposto un cambiamento di politica senza effettuare una corretta valutazione d'impatto e considerare le attenuazioni per eventuali danni alla produttività / sicurezza.

We have at least 2 major antivirus programs on all workstations

Questo è un approccio molto ingenuo per proteggere l'integrità di questi sistemi e dipinge un'immagine di ciò che stai affrontando.

there doesn't seem to be much for alternatives out there

Entrare in una discussione a riguardo probabilmente non sarà molto produttivo a questo punto.

Nel complesso sembra che tu sia in concorrenza con il tuo team di sicurezza locale. Non capiscono cosa devi fare per il tuo lavoro, non capisci come raggiungere i loro obiettivi. E sembra che nessuna parte sia disposta a negoziare. Nessuno strumento off-the-shelf lo aggiusterà.

Segrega le tue reti

Dovresti avere ambienti relativamente isolati per sviluppo, test, produzione e business. Ciò consente ai tuoi sviluppatori di avere privilegi laddove ne hanno bisogno.

La corretta segregazione impedisce modifiche non autorizzate, limita la diffusione del malware e impedisce l'esfiltrazione dei dati.

Che cosa succede dove?

sviluppo

La rete di sviluppo è il luogo in cui avviene la codifica. Gli sviluppatori dovrebbero avere i diritti amministrativi nel caso volessero testare frammenti di codice o eseguire qualcosa senza impacchettarlo per la distribuzione su test / prod.

I computer eseguono IDE, archivi di origine e app / framework prerequisiti per le tue app. Uno strumento di collaborazione dedicato o altre app specifiche per lo sviluppo sono ragionevoli.

Test

La rete di test è dove viene collaudato il codice compilato e pronto per la spedizione. Gli sviluppatori possono avere diritti di amministratore, ma i normali amministratori di sistema dovrebbero implementare le applicazioni.

Le implementazioni dovrebbero riflettere ciò che gli amministratori manterranno in produzione per le app interne. Dovrebbero essere pacchetti pronti per il cliente per le app esterne (inclusa la procedura guidata di installazione e le firme digitali, anche se utilizzando una firma separata a scopo di test per prevenire rilasci accidentali).

Gli sviluppatori spesso hanno bisogno di registri di sistema e accesso di debug, e questi sono gli unici motivi per cui dovrebbero avere diritti di amministratore. Non dovrebbero essere coinvolti con l'installazione, la configurazione e le prove a meno che non sia assolutamente necessario.

Produzione

La rete di produzione è dove fornisci servizi a clienti e partner. Dal momento che dovrebbe esistere un processo di distribuzione formale, non vi è alcun motivo per collegarsi alle reti di sviluppo / test.

Per ridurre al minimo i rischi di malware trasmessi da Internet e modifiche accidentali, gli account delle reti di sviluppo / test / dovrebbero non avere accesso alla produzione se possibile, il che si traduce in autorizzazioni limitate con argomenti occasionali nella pratica.

Idealmente, questa rete sarebbe completamente isolata, ma in pratica ciò è impossibile in un mondo in cui i server di produzione devono interfacciarsi con i sistemi di vendita, fatturazione, pianificazione, netop e gestione dei progetti. Avvicinati il più possibile all'ideale; è davvero tutto ciò che possiamo fare.

Affari

Questa è la rete di comunicazione principale per l'azienda.

L'email, la navigazione sul Web e la connettività con i partner portano tutti una serie di rischi. Le reti di sviluppo, test e produzione dovrebbero essere isolate da questi rischi nella massima misura possibile.

Dettagli, Dettagli, Dettagli

È possibile che la tua organizzazione sia andata in mare. È più facile far oscillare il pendolo fino in fondo rispetto alla miriade di dettagli essenziali per un'architettura di rete flessibile e sicura.

Gli sviluppatori possono avere accesso amministrativo alle loro macchine, con un rischio minimo per l'azienda, se:

1. Esistono account separati e non privilegiati per l'accesso a Internet
2. Gli account univoci vengono utilizzati in ogni ambiente
3. Esistono regole firewall / ACL restrittive tra gli ambienti
4. Sono disponibili misure di sicurezza standard come firewall, proxy Web, IDS / IPS, ecc.

I tuoi sviluppatori avranno bisogno di quattro account:

• Account di sviluppo non privilegiato per accedere alle risorse su Internet (se non vogliono saltare avanti e indietro dalla rete aziendale, che è onerosa)
• Account di sviluppo privilegiato per configurare workstation e codice di prova
• Account di prova privilegiato per eseguire il debug delle applicazioni
• Account aziendale non privilegiato per email, web, intranet

Se hai sviluppatori che svolgono attività di validazione o controllo qualità, potrebbero anche aver bisogno di account non privilegiati nell'ambiente di test.

Gli sviluppatori non dovrebbero avere accesso alla rete di produzione e nessun privilegio amministrativo sulla rete aziendale. Se questo è impossibile per il momento, allora questi ruoli dovrebbero essere separati, altrimenti dovrebbe essere messo in atto un rigoroso processo di controllo delle modifiche.

È tipico che l'accesso all'amministratore locale sia negato agli sviluppatori in aziende in cui gli sviluppatori sono così inutili / maliziosi che abusano di tali privilegi o dove il reparto "IT e sicurezza" è gestito da idioti idioti incapaci di vedere tutti non nella loro cerchia ristretta come una evidente minaccia alla sicurezza per farli sembrare cattivi.

Considerando che il reparto "IT e sicurezza" impone anche due programmi anti-virus quando Windows viene fornito con uno perfettamente gratuito, sono abbastanza sicuro di poter determinare dove si trova il problema nella tua organizzazione e di lavorare da lì.