Domanda:
È comune consentire l'accesso e i diritti di amministratore del desktop locale e / o di Active Directory per gli sviluppatori nelle organizzazioni?
TroySteven
2018-07-16 07:06:12 UTC
view on stackexchange narkive permalink

Lavoro in un'azienda con uno staff di circa 1000+. Attualmente abbiamo personale di sviluppo della programmazione che lavora su progetti basati sul web (circa 50 persone).

Recentemente, a causa di problemi di sicurezza, il nostro reparto IT e sicurezza ha implementato una restrizione che non consente più l'accesso di amministratore locale sulle macchine. L'intera azienda esegue il sistema operativo Windows sia per le workstation che per i server. Sono completamente d'accordo con la decisione di rimuovere l'amministratore, onestamente pensavo fosse attesa da tempo (poiché l'azienda si occupa dei dati dei pazienti e richiede la conformità HIPAA). Purtroppo credo che abbiano preso la decisione troppo in là. Ho pensato che un sottogruppo o un gruppo AD sarebbe stato creato per gli utenti che avevano legittimamente bisogno dell'accesso di amministratore per svolgere il loro lavoro (EX il mio team di programmazione) qualcosa come un gruppo tecnico che manterrebbe l'accesso di amministratore. Tuttavia non è stato così, l'unico gruppo ha creato un gruppo di amministratori specifico per il personale di rete e dell'help desk.

Il problema principale è che, come sviluppatori web, eseguiamo programmi che richiedono l'accesso di amministratore locale e sfortunatamente non possiamo fare il nostro lavoro senza che vengano eseguiti come amministratori. I programmi di esempio includono Visual Studio per lo sviluppo web ASP.NET, MAMP per lo sviluppo locale, compositore, ecc. Credo che il motivo principale per cui questi programmi necessitano dell'accesso amministrativo è perché devono eseguire e modificare IIS locale, riga di comando, ecc.

Fondamentalmente c'è stato un breve preavviso di quando è stato rimosso l'accesso dell'amministratore locale. Dopo circa 2 giorni in cui il team di sviluppo è morto in acqua in termini di capacità di lavorare e io e gli altri team leader abbiamo praticamente urlato e urlato allo staff IT per trovare una soluzione che alla fine hanno concesso e hanno trovato un programma di terze parti funziona come un passaggio consentendo agli amministratori di creare la possibilità per alcuni programmi di essere eseguiti come amministratori anche se non abbiamo accesso come amministratore locale.

Sfortunatamente, questo programma che utilizziamo per l'accesso dell'amministratore locale è incredibilmente difettoso e inaffidabile e non proviene da una fonte attendibile e sembra che non ci siano molte alternative là fuori. (Preferirei non divulgare il programma che utilizziamo.)

La mia domanda è: è tipico non consentire ai programmatori / sviluppatori l'accesso di amministratore locale a un'azienda o società? E se è pratica comune farlo, come fanno gli sviluppatori a eseguire i programmi di cui hanno bisogno come amministratori locali?

Qualche informazione in più sul nostro ambiente di rete (non che si riferisca realmente alla domanda che pensavo di aggiungere):

  1. Usiamo AppBlocker per bloccare i programmi non in un elenco approvato
  2. Utilizziamo un blocco per la sicurezza della posta elettronica che esegue operazioni come la scansione e la conversione degli allegati in PDF, ecc.
  3. Abbiamo almeno 2 principali programmi antivirus su tutte le workstation.
  4. La rete e i suoi server sono molto separati, gli utenti hanno accesso solo a determinati server, cartelle e database a cui hanno legittimamente bisogno di accedere.
* Una politica aziendale che incoraggi l'attrito tra IT e sviluppo è una politica rischiosa. * Se c'è un gruppo di persone che potrebbe seriamente minare gli sforzi di sicurezza del dipartimento IT, saranno gli sviluppatori.Una buona politica aziendale mirerebbe a far sì che l'IT e lo sviluppo combinino le loro conoscenze collettive per rafforzare la sicurezza complessiva.Costringere l'IT a creare barriere per lo sviluppo è controproducente per questo risultato.Dato un incentivo sufficiente, le persone inizieranno a cercare soluzioni alternative creative.Soluzioni alternative creative da parte degli sviluppatori saranno dannose per la sicurezza generale.
Avere due programmi antivirus separati su un sistema quasi certamente farà più male che bene.Otterrai un aumento trascurabile nel rilevamento, raddoppiando la tua esposizione alle vulnerabilità nel software AV stesso, oltre a rallentare notevolmente i sistemi interessati.
Non è la stessa domanda ma molto correlata, io ero dall'altra parte (il lato IT delle cose, e le persone IT spesso non sono d'accordo con una politica così folle): https://security.stackexchange.com/questions/135359/computer-aziendali-per-sviluppatori-competenti-come-trattare-con-loro
Non credo che tu voglia davvero chiedere se è "tipico".Ma è piuttosto giustificabile e quali sono i costi / benefici?Nella mia esperienza è piuttosto comune per le grandi organizzazioni provare questo.I costi sono piuttosto alti e influiscono drasticamente sulla produttività degli sviluppatori, ma alle "persone della sicurezza" normalmente non interessa perché è circondato da un campo SEP (il problema di qualcun altro).Se vuoi sbarazzartene, è improbabile che tu vinca cercando di scoprire che questo non è tipico, ma piuttosto che è COSTOSO.Le aziende odiano costoso.
Ciò dipende in gran parte dal settore.Banche, militari, servizi pubblici: sono tutte molto più restrittive della maggior parte degli altri.L'ingegneria del software è un'abilità che puoi trasferire in qualsiasi settore, ma non è sempre un settore a sé stante
Hai / davvero / hai bisogno dell'accesso come amministratore per usare ASP.NET/IIS?Sviluppo questi progetti da 10 anni e non ho mai avuto bisogno dell'accesso amministrativo.Ho lavorato con sviluppatori che insistono su di esso (sulla stessa base di codice), ma di solito è perché hanno "strumenti" che hanno scritto (male) da soli.
@Jacco Non potrei essere più d'accordo.Lavoravo per un'organizzazione che faceva questo e ha creato esattamente l'attrito di cui parli.Quando Big Evil Corp ha cercato di implementarlo, i miei primi pensieri si sono concentrati sul saltare la recinzione.Qualsiasi sviluppatore mezzo esperto può inventare una mezza dozzina di modi per saltare questi tipi di recinzioni senza troppi sforzi.
@Jacco Per non parlare della dissonanza cognitiva tra non fidarsi di uno sviluppatore con la propria macchina e allo stesso tempo fidarsi di loro per sviluppare codice personalizzato da eseguire sui server dell'azienda e che elabora le informazioni sensibili dell'utente finale.Se non riescono a tenere un virus lontano dalla loro macchina senza protezioni, non penso che vorrei che sviluppassero le mie applicazioni che potrei essere multato per non aver eseguito correttamente.
Nota: se consenti a Visual Studio di eseguire "come amministratore", l'utente può eseguire il codice "come amministratore".Il codice con privilegi di amministratore può assegnare il privilegio SeDebug a qualsiasi token di sicurezza che desidera, e quindi lo sviluppatore ha il controllo totale della macchina.
Non esaminiamo nemmeno l'errore, ovvero l'aggiunta di più prodotti antivirus rende un sistema più sicuro.
Il modo in cui ho affrontato questo problema in passato è stato fare un appello piuttosto semplice a un capo / direttore che è al di sopra delle persone di sicurezza IT in anzianità.Funziona in questo modo: "Ho un problema, il che significa che non riesco a portare a termine alcun lavoro, ma ho identificato la soluzione e ho bisogno solo della tua approvazione per implementarla".Stranamente, la necessità per l'azienda di fare soldi * sempre * batte la minaccia esistenziale che gli addetti alla sicurezza IT inventano per giustificare le loro misure draconiane.TUTTAVIA: sii sempre gentile mentre lo fai: vuoi che il team di sicurezza IT sia dalla tua parte, a lungo termine.
In molte aziende gli sviluppatori raddoppiano anche come amministratori di sistema, quindi avranno naturalmente dei privilegi.
Hai provato a impostare gli endpoint WAAS per fornire al tuo utente / gruppo l'accesso a http: // +: 80 /?Google per "netsh http add urlacl" ...
Da notare che alcuni strumenti di sviluppo non funzioneranno se l'account non è admin.Questo tende ad essere più vero quanto più vecchi sono gli strumenti software.
Uno svantaggio per gli sviluppatori di software che operano come amministratori locali è che potrebbero non incontrare mai problemi con l'utente finale che si verificano solo quando non si dispone di tali diritti.L'ho visto personalmente accadere molte volte.
Sono un programmatore a contratto nel settore della difesa.Ogni azienda per cui lavoro ha un programma che darà i diritti di amministratore temporaneo durante la registrazione delle azioni intraprese per motivi di sicurezza.Per rispondere alla tua domanda: "è comune?"- sì, ma questa è davvero una domanda di sicurezza ben definita (senza offesa)
Se lasci che appdev gestisca le loro macchine, installeranno FTP non autentico, RSH, Webmin, Jenkins, Tomcat, ColdFusion, JBoss / WildFly, Splunkd, ElasticSearch, ecc. E non verranno mai aggiornati.Configureranno SimpleHTTPServer, SMB, AFP e / o NFS per consentire, volenti o nolenti, l'accesso in lettura e scrittura ai loro filesystem locali sulla rete (o parti di esso) e quindi lasceranno gli script della shell e il materiale chiave su quelle cartelle condivise.Faranno lo stesso con i database e qualsiasi altra cosa che possa collegarsi a un socket di rete.
A volte è richiesto per il debug.Ad esempio, quando si utilizza Visual Studio senza diritti di amministratore locale, non è possibile eseguire il debug di un processo avviato con un altro utente.Ma un'azienda può impostare un processo per richiedere diritti di amministratore locale temporanei sulla workstation per un utente specifico.
Qualsiasi sviluppatore che valga un cazzo otterrà l'accesso come root su una macchina a cui ha accesso fisico :)
@Neil Sì, è necessario essere un amministratore locale anche per aprire il gestore iis o per collegare un debugger a un processo di lavoro iis.
@Andy Oppure usa semplicemente IIS Express, e poi non lo fai.
@Navin in alcuni luoghi che ti porteranno un breve viaggio alle risorse umane per ottenere il tuo P45.Sì davvero !
@matwonk Ti preghiamo di informarci su come si è risolto il problema.
@Neil Tranne quando non è possibile utilizzare IIS Express, ad esempio quando è necessario distribuire un'app su un altro computer e collegarla alla workstation.
@Andy Questo suona più come problemi di integrazione, piuttosto che di sviluppo.Il 100% del tuo lavoro di sviluppo può essere svolto senza diritti di amministratore.
@Neil Non è un problema di integrazione;a meno che non si pensi che uno sviluppatore che esegue l'app su cui sta lavorando localmente per testarlo prima di impegnarsi è "integrazione".Ci sono molte altre cose che gli sviluppatori dovranno fare che richiedono un amministratore locale, e non avere un amministratore locale è un grave impedimento alla produzione, motivo per cui la maggior parte degli sviluppatori finisce con esso (e personalmente non lavorerei da qualche parte che non ho fatto't).
Poiché la società vede gli sviluppatori come un problema e non come una soluzione (a quanto pare il tuo capo non è stato ascoltato o ignorato), suggerisco di cercare altrove un ambiente più favorevole agli sviluppatori.E poiché siamo su Stackexchange, il nostro grande fondatore ha una [forte opinione] (https://www.joelonsoftware.com/2006/09/07/a-field-guide-to-developers/) su come la tua azienda ti tratta.
Un aneddoto: non ho mai lavorato per un'azienda che ha bloccato i propri dipendenti in questo modo che aveva una sorta di vera sicurezza competente.Qualsiasi azienda per cui ho lavorato ha fallito in modo fondamentale, rendendo estremamente difficile il lavoro per i propri dipendenti.Dirò anche che non lavorerò mai più per un'azienda come quella.Preferisco davvero fare un lavoro significativo che occuparmi di una perdita burocratica del tempo di tutti.
@atdre Assumi ingegneri competenti.Inoltre, se le cose sono impostate correttamente, niente di ciò di cui ti sei lamentato rappresenta un rischio reale.
@Brad: Dopo circa 300 dipendenti, è impossibile.Esistono prove evidenti che persino i professionisti della sicurezza informatica sono vittime di phishing generico e spear phishing.Quando metti un attore motivato finanziariamente, o uno stato nazionale, contro una persona, di solito è la persona che crolla.No, lo è sempre.Non esiste una "configurazione" adeguata di cui ho sentito parlare che riduca il rischio di espansione dell'accesso in un ambiente Windows Server Forest.Nemmeno Microsoft ne vende uno.
@atdre È del tutto possibile, devi solo organizzarti meglio.Quando lavoravo in un enorme negozio di software, ogni progetto era una "società virtuale" completamente separata in materia di IT, con i suoi server, il suo team e un'infrastruttura completamente isolata.Non c'era bisogno di mettere tutti sulla stessa rete tutto il tempo.Ha funzionato a meraviglia.Aveva anche il vantaggio di poter spostare un team ovunque senza comprometterne il lavoro o dover configurare l'accesso a un server centrale: quando uno dei nostri uffici è andato a fuoco, abbiamo affittato uno spazio in un cyber cafè e abbiamo continuato finché le cose non sono state risolte.
@atdre Inoltre, disponendo di infrastrutture completamente separate, potremmo eseguire aggiornamenti e configurazioni diverse in ogni team, se necessario.Poiché il team IT era anche suddiviso in "società virtuale", ogni professionista aveva anche molto meno da prendersi cura in ogni momento.
Idk, hai grandi idee ma non le ho mai viste implementate bene.Penso che sia meglio implementare JitJea a prescindere.Nessuno dovrebbe nemmeno avere un amministratore per lunghi (secondi), soprattutto non un amministratore locale di una workstation o un amministratore / gruppo di dominio per reti di grandi installazioni.
Nella mia vita lavorativa ho sempre avuto accesso come amministratore.Una società ha provato a rimuoverlo da noi, ma lo ha fermato abbastanza velocemente dopo aver realizzato che gli sviluppatori non solo si sono frustrati ma hanno semplicemente smesso di funzionare.Non perché non volessero, ma perché non potevano più lavorare. Quindi almeno dalla mia esperienza personale (in Germania) è abbastanza comune avere accesso amministrativo per gli sviluppatori.(So da ALCUNI sviluppatori che devono utilizzare VM (con diritti di amministratore) come compromesso per ambienti di sicurezza forti
Questa è in realtà una delle domande che pongo comunemente nei colloqui di lavoro, se la risposta è no, agli sviluppatori non sono consentiti i diritti di amministratore locale, quindi rifiuto cortesemente di procedere oltre.
Diciannove risposte:
#1
+114
Joe
2018-07-16 14:02:39 UTC
view on stackexchange narkive permalink

Ecco un punto dati di una società di software interessata alla sicurezza. So che questo è comune in organizzazioni simili.

Esistono diverse reti. Sono fisicamente separati e con intercapedine d'aria, corrono cavi di rete con codice colore diverso.

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

Oltre a questo, ogni sviluppatore ha una macchina di "ingegneria". Questo ha pieno accesso come amministratore e l'utente può fare quello che vuole. Tuttavia è connesso solo alla rete di ingegneria (nessun percorso per Internet).

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

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

+1, alcuni team di sviluppo nella nostra azienda utilizzano la stessa pratica.Anche se non separiamo la rete di sviluppo.Lo gestiamo utilizzando VLAN.
+1 È così che ha fatto anche il fornitore di Infosec / A / V per cui ho lavorato.Hanno preso la segmentazione della rete piuttosto seriamente: era un reato terminale collegare la macchina di sviluppo alla rete di produzione / infrastruttura interna, e ho dovuto chiamare più di uno sviluppatore per farlo.Tuttavia, penso che sia l'approccio migliore e più amichevole per gli sviluppatori al problema: "ecco il tuo laptop di sviluppo sulla tua rete di sviluppo e ti isoleremo da tutto ciò che potrebbe essere danneggiato dalle autorizzazioni avanzate di cui hai bisogno per svolgere bene il tuo lavoro."
La tua "rete di ingegneria" è davvero una rete di produzione?Hai davvero bisogno di avere due scatole, una per leggere documenti e un'altra per codificare?Se si tratta di una rete di sviluppo / test, sono confuso dalla preoccupazione, l'infiltrazione di attaccanti che ottengono codice?Esfiltrazione di codice (i tuoi sviluppatori lo aggireranno in circa 5 secondi)?Se fosse una rete di produzione, potresti probabilmente evitare di concedere agli ingegneri l'accesso ad essa (QA / ops distribuisce in prod).
Hm, le macchine di sviluppo che non hanno alcuna connessione Internet sembrano una restrizione piuttosto severa.
@Deduplicator in che modo?Puoi copiare materiale abbastanza facilmente tramite unità USB.Ti fa pensare a quello che vuoi veramente invece di fare clic a caso su spazzatura e installare tutto.La mancanza di accesso amministratore mi ha fatto organizzare i miei download in batch, quindi sono molto più selettivo con ciò che installo.
Le perdite di @NickT Sourcecode sono di solito una preoccupazione secondaria.O in molte organizzazioni, nessuna preoccupazione, perché il loro software è così specializzato che non ha valore per nessuno tranne che per loro / il loro cliente.Il pericolo che colpisce tutti è la diffusione involontaria di malware.Una macchina in esecuzione con privilegi di amministratore completi e che accede a Internet con software non controllato dal reparto IT è una calamita per il malware
@Nelson: Come puoi verificare che ciò che stai copiando sulla chiavetta USB sia sicuro?Mentre ovviamente è necessario consentire la copia dall'amministrazione all'ingegneria;consentireste di copiare _alla_ macchina di amministrazione?Perché se consenti entrambi, i dati scambiati su una chiavetta sono sicuri quanto i dati scambiati su un cavo di rete fisico (direttamente tra le due macchine), è solo un processo più lento.
@Flater anche se non è sicuro,
Questa non è una decisione da prendere alla leggera.Ci sarà un impatto considerevole sullo sviluppo.Non dico che sia impossibile, ma solo sottolineando alcune delle conseguenze.Da cose tecniche come i pacchetti nuget / npm (non avrai accesso in tempo reale ai feed pubblici e dovrai copiare tutto manualmente), ma anche problemi più banali (gli sviluppatori non possono più copiare / incollare da StackOverflow. E siamoreale qui, lo facciamo tutti, anche se siamo d'accordo sul fatto che controllare il codice è necessario (che imo, è), dover digitare manualmente il tutto non favorirà un lavoro efficiente).
Dover acquistare un secondo PC / laptop per i dipendenti sembra un modo piuttosto costoso per rendere le persone meno produttive
Francamente, vorrei consegnare la mia notifica nel momento stesso in cui questa politica è stata introdotta ... Non avere accesso a Internet su una macchina di sviluppo è solo una follia.
@Nelson Questo approccio diventa molto doloroso nella pratica.Al giorno d'oggi è comune utilizzare framework per accelerare lo sviluppo.Molti framework moderni dipendono da una serie di librerie e può essere complesso e soggetto a errori identificare le esatte dipendenze del framework che stai utilizzando, al fine di salvarli su un dispositivo USB.In questo modo perdi anche l'accesso a importanti strumenti di sicurezza.Alcuni gestori di pacchetti moderni possono controllare automaticamente se le tue dipendenze hanno avvisi di sicurezza e in tal caso aggiornarli.Se hai bisogno di farlo su una macchina diversa, allora quella macchina diventa la tua macchina di sviluppo di fatto.
@Nelson, In realtà, per migliorare la sicurezza, tutte le porte USB utilizzate nell'ambiente di progettazione dovrebbero essere disabilitate, poiché sono intrinsecamente insicure.Molto più utile e più sicuro sarebbe l'uso di un diodo dati per consentire il download controllato di aggiornamenti esterni.https://en.wikipedia.org/wiki/Unidirectional_network
Avevo dovuto lavorare in una configurazione in qualche modo simile quando lavoravo presso un appaltatore DoD.In quel caso la mia macchina di sviluppo principale era connessa alla rete principale, a Internet e aveva un amministratore locale.Le macchine di produzione sono state intercettate dal mondo dietro porte chiuse e massicciamente bloccate.Essere in grado di eseguire la maggior parte dei miei test di sviluppo / iniziali normalmente riduceva molto il dolore, ma a volte non era possibile creare un set di dati non classificato utilizzabile e dovevo fare tutto sul lato alto.Questo è stato miserabile perché era almeno una camminata di 20 piedi da un PC connesso a Internet e solo una copia cartacea xfer a dev.
Al mio posto di lavoro l'USB (e altri supporti rimovibili) è disabilitato (e consentito solo per una lista bianca di dispositivi di sviluppo per un periodo di tempo limitato per scopi di lavoro) ma abbiamo 2 account, uno di amministrazione per il lavoro di sviluppo con accesso a Internet non limitato / limitatoe un utente con autorizzazioni limitate che può navigare sul Web.Non sono necessarie 2 macchine.
La maggior parte dei posti in cui vedresti distribuzioni come questa sono ben oltre il concetto di macchine utente e ben rientrano nel concetto di account: tutti gestiscono VM o contabilità gestita a livello di rete con archiviazione condivisa.Il tuo PC amministratore può facilmente avere accesso RW a un NAS, o anche essere una destinazione VM VPN / SSH a cui è consentito eseguire un solo client per stanza (per impedire alle persone di lasciarlo connesso).Questo di solito è l'ideale in quanto l'IT può accedere all'amministratore da qualsiasi sistema, gli sviluppatori possono eseguire installazioni tramite esso, ma devono prima accedere da un account utente standard, identificando l'utente amministratore.
Bloccare l'accesso al web aperto è ovviamente una follia, ma in tutta onestà se vuoi sviluppare in un ambiente di amministrazione mantenendo la sicurezza, il tuo lato IT dovrebbe virtualizzare la tua suite in modo che possa avere accesso amministrativo sandbox.Ciò ti consente di svolgere tutto il lavoro amministrativo, limitandoti al controllo dell'accesso esterno dalla VM e impedendo a chiunque di ottenere un virus sullo storage condiviso.
#2
+70
Joel Coehoorn
2018-07-16 18:22:32 UTC
view on stackexchange narkive permalink

Nella mia esperienza, è comune per gli sviluppatori avere accesso amministrativo sulle proprie macchine. È anche comune che non abbiano accesso amministrativo sui propri computer. Tuttavia, in quest'ultima situazione, in genere vengono presi alcuni accordi in modo che possano svolgere il loro lavoro senza troppi attriti.

Una sistemazione molto comune è l'accesso a un Hypervisor sulla workstation (sia una versione di VMWare o Hyper-V fornita con Windows), insieme alle autorizzazioni specifiche necessarie per creare e distruggere VM all'interno dell'hypervisor secondo necessità ( Hyper-V / VMWare) , inclusa la creazione di VM in cui dispongono dei diritti di amministratore per il SO guest . In genere alcune di queste VM dureranno a lungo, anche se non vengono eseguite sempre, in cui raramente è necessario preparare un'intera VM da zero solo per fare quello che dovrebbe essere un test rapido per qualcosa che necessita di 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 preferisco fortemente che l'accesso a Internet dovrebbe essere consentito ... almeno per i tipi di sviluppo con i quali ho più esperienza. Ma l'accesso a Internet, se concesso, può e deve essere configurato almeno per forzare le VM in una vlan dedicata, separata 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 determinati vlan da macchine non autorizzate, comprese le VM devloper. Quindi puoi dare un piccolo tutorial agli sviluppatori su come impostare un tag vlan in una VM e far loro sapere quali tag vlan saranno consentiti sulla loro porta switch. Ho anche visto questo fatto rispettare tramite la formazione semplicemente come un editto politico, piuttosto che tramite misure tecniche, con forse occasionali controlli amichevoli per incoraggiare la conformità e assicurarsi che gli sviluppatori sappiano che è importante.

E, naturalmente, questo coincide con il fornire agli sviluppatori macchine sufficientemente potenti per eseguire più VM contemporaneamente.

Sembra una buona soluzione - una _molto_ buona soluzione - ma non ho abbastanza amministratore di Windows per sapere se funziona effettivamente in questo modo (privilegi o diritti specifici per avviare le VM senza avere privilegi di amministratore locale generale) - quindi IMOquesta risposta potrebbe essere molto migliorata con collegamenti ad alcuni documenti / white paper / articoli di libri di cucina / o simili che lo confermano.
AiliayulunCMT Meglio?
Sì, ottimo collegamento!Ben Armstrong è il ragazzo da cui andare!Più i dettagli sulla roba VLAN.
@davidbak Ho lavorato su una macchina con un hypervisor (VirtualBox) installato senza i diritti di amministratore
Le VM forniscono anche altri vantaggi per gli sviluppatori.Un computer fisico può ospitare diverse VM, che eseguono diverse versioni del sistema operativo o versioni del software sotto test.Poiché sono usa e getta, è più facile ripetere i test tornando a un punto di controllo scelto.
#3
+47
Justin
2018-07-16 08:37:52 UTC
view on stackexchange narkive permalink

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

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

Questo non risponde alla domanda.Non fornisce alcuna spiegazione se o perché questo sarebbe "tipico".
@TomK.Risponde alla vera domanda, che è "Perché la mia organizzazione sta rendendo la mia vita molto, molto difficile, apparentemente senza una buona ragione, e cosa posso fare al riguardo?".L'OP sta chiaramente cercando di adattare questa pratica (francamente bizzarra e paranoica) alla sua visione del mondo.Le persone stanno cercando di sottolineare come le loro organizzazioni abbiano bilanciato le persone paranoiche della sicurezza con le esigenze della vita reale degli sviluppatori.
@Steve - sfortunatamente questa è una visione tanto fuorviante quanto quella che si ottiene da alcune persone di estrema sicurezza.Non è paranoico proteggere le organizzazioni da minacce interne.In effetti per molti è la più grande minaccia alla loro esistenza.
#4
+32
Falco
2018-07-19 13:33:45 UTC
view on stackexchange narkive permalink

Nella mia esperienza, consentire e negare l'accesso di amministratore locale è comune, così come le soluzioni alternative sporche per quest'ultimo. - Quindi dovresti chiederti:

Quale minaccia per la tua rete è aggravata dai diritti di amministratore locale?

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

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

Addendum: dovresti concedi ai tuoi sviluppatori la possibilità di utilizzare i diritti di amministratore locale ogni volta che ne hanno bisogno. Ciò non significa che debbano essere sempre collegati con un account amministratore non protetto, ma dovresti fidarti di loro per usarlo in modo ragionevole ogni volta che ne hanno bisogno, senza chiedere il permesso ogni volta.

Perché gli sviluppatori dovrebbe avere i diritti di amministratore locale

I tuoi sviluppatori sono persone a cui affidi 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 plasmare una parte molto importante della tua azienda.

Innanzitutto 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 software su una versione precedente di un sistema operativo o con driver / SDK meno recenti).

Secondo c'è il vantaggio (a mio parere ancora maggiore) di mostrare ai tuoi sviluppatori come li apprezzi. Dimostri loro che ti fidi di loro con la loro macchina: tratti i tuoi sviluppatori come persone responsabili dell'IT che possono amministrare la propria macchina senza una babysitter. (In molte aziende in cui gli sviluppatori non hanno un 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 sanno meno del software rispetto al tuo sviluppatore capo senior , ma devono ancora elemosinare le cose di cui hanno semplicemente bisogno per svolgere il loro lavoro, il che può essere molto frustrante.)

@Downvoter ti interessa commentare come la mia risposta potrebbe essere migliorata, o perché pensi che sia completamente sbagliata?
In breve, questa risposta viola il principio del privilegio minimo e l'intero concetto di difesa in profondità.La ragione per limitare l'amministratore locale è aiutare a mitigare gli attacchi che riescono a superare e i bravi sviluppatori lo capiranno.Dove c'è una necessità dimostrabile, allora è una partita diversa, spesso può essere soddisfatta con un account amministratore locale separato in modo che l'uso di privilegi elevati sia temporaneo;ma l'OP dice che sono sviluppatori web, quindi ci dovrebbe essere pochissimo bisogno di diritti di amministratore locale.Vedi https://security.stackexchange.com/a/190182/17321
@JamesSnell Visual Studio necessita dei diritti di amministratore locale, il che è (imo) un motivo importante, poiché lo sviluppo senza Visual Studio non avviene.Non sono in disaccordo con il resto del tuo commento, solo la necessità di diritti di amministratore locale.
@JamesSnell Sono un grande sostenitore della difesa in profondità, ma semplicemente non vedo un account con restrizioni locali che protegga qualcosa di valore, tranne l'hardware locale.È possibile accedere a qualsiasi cosa di valore aziendale con i diritti utente https://xkcd.com/1200/
La difesa in profondità per me include un disco rigido crittografato, una password complessa sull'account locale, un modulo hardware sicuro ... Ma la restrizione dei diritti dell'utente locale su un laptop per utente singolo è solo un teatro di sicurezza
@Falco - il punto è che la macchina non può essere utilizzata come piattaforma per lanciare ulteriori attacchi ... leggi la domanda collegata.
@JamesSnell come viene protetta la macchina?Un utente malintenzionato con diritti utente sulla macchina è sufficiente per lanciare un attacco su vasta scala alla rete.Il laptop può già essere un host infetto senza alcun accesso amministrativo.
@Falco - riduce la superficie di attacco, non hai letto la risposta collegata?Inoltre ... https://www.theregister.co.uk/2018/07/25/developers_malware_vectors/
@JamesSnell ironicamente un IDE che potrebbero installare senza i diritti di amministratore locale ;-) Ma vedo il tuo punto: Sì, amplia la potenziale superficie di attacco, ma solo con un piccolo margine.E se i tuoi sviluppatori non ottengono un amministratore locale e non scaricano alcuni "strumenti di supporto" per aggirare questo problema, probabilmente avrai ancora più superficie di attacco.- Vorrei vedere un sondaggio se gli sviluppatori usano la loro macchina in modo più responsabile se sono considerati responsabili della responsabilità, invece di diffidare.
@Falco: non è una questione di fiducia.Gestisco i miei sistemi in questo modo.Limito i miei diritti quando non ne ho bisogno.
@JamesSnell Come ogni sviluppatore può farlo di sua spontanea volontà, se ti fidi di lui.Amministratore locale non significa "usa sempre root" ma "può usare root se necessario"
Forse dovrei modificare la mia risposta per renderlo chiaro: penso che gli sviluppatori dovrebbero utilizzare normalmente un account protetto, ma hanno la possibilità di abilitare l'amministratore locale se necessario senza la necessità di compilare un modulo e chiedere l'autorizzazione.E confido che utilizzino questo privilegio in modo ragionevole e parsimonioso
Non ho downvote, ma dovresti riformulare alcune parti poiché in particolare il tuo primo punto è fuorviante a prima vista: Minacce dai diritti di amministratore locale: il malware ha accesso alle password degli utenti memorizzate nella cache, inclusi gli amministratori di dominio, l'accesso ai dati di altri utenti,accesso a diversi token di sicurezza che possono essere utilizzati sulla rete per passare ai diritti di amministratore del dominio, ....Btw.sembra che malware come Emotet lo faccia già secondo i rapporti.Il tuo ultimo punto non è così corretto per gli sviluppatori inesperti / junior che ho visto scaricare e installare anche strumenti dall'aspetto non legittimo.
@H.Idden Hai ragione.La mia risposta funziona completamente partendo dal presupposto che gli individui presi di mira siano sviluppatori affidabili, ciascuno utilizzando la propria macchina con un singolo account utente.In questo caso non dovrebbero esserci password di dominio memorizzate nella cache o alcuna informazione che non sia legata all'utente.Quindi un malware che accede ai file degli utenti (come l'archivio delle password del browser) avrà già tutto ciò di cui ha bisogno senza i diritti di amministratore.- E ovviamente gli sviluppatori inesperti dovrebbero essere supportati dagli anziani.
#5
+30
Marcel
2018-07-16 10:54:05 UTC
view on stackexchange narkive permalink

Nella mia carriera, con aziende piuttosto piccole (meno di 100 persone), abbiamo sempre avuto diritti di amministratore locale. O abbiamo macchine desktop reali che sono gestite dall'IT, ma ne hanno i diritti, oppure ci è stato permesso di avere macchine virtuali di tutti i tipi che abbiamo gestito completamente da noi.

Se non avessimo accesso amministrativo locale , proveremmo tutti i tipi di cattive "soluzioni" che, come nel tuo caso, portano a una minore sicurezza. Questo è uno di quei casi in cui le restrizioni portano effettivamente all'opposto della loro intenzione.

Questo non risponde alla domanda.Non fornisce alcuna spiegazione se o perché questo sarebbe "tipico".
@TomK.Questo risponde alla domanda * parzialmente. * Se 10 persone su 10 dicono "Ho sempre avuto i diritti di amministratore", * insieme * questa è la risposta.Nessuna singola persona può rispondere canonicamente a una domanda globale come questa;ogni singola risposta è in una certa misura aneddotica, un "punto dati" come lo chiamava Joe.(Joe ha anche affermato "So che questo è comune in altre origanizzazioni", senza aggiungere "di cui sono a conoscenza".)
@PeterA.Schneider: Esatto, in genere nessuna singola persona può rispondere canonicamente a una domanda globale come questa solo con le sue ** esperienze **.Ma fortunatamente ci sono cose chiamate "migliori pratiche" che sono scritte e aperte al controllo.Altre possibilità sono studi o articoli.Il solo dire "Per me è così" non è sufficiente.
@TomK.Non c'è modo di sapere cosa sia tipico a parte un qualche tipo di sondaggio, quindi rispondere a quella parte della domanda non succederà.
@Andy corretto.Queste indagini o studi sono svolti da scienziati o spesso da consulenti che sviluppano - come ho detto - le migliori pratiche.Citare queste migliori pratiche o studi costituirebbe una risposta valida.
@TomK.Quei sondaggi o studi, se esistessero, sarebbero spazzatura.Come hai detto, sarebbe solo una raccolta di ciò che potrebbe essere "tipico" e solo perché qualcosa è tipico non significa che sia la strada giusta da percorrere.
#6
+28
Serge Ballesta
2018-07-16 15:30:29 UTC
view on stackexchange narkive permalink

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

  • sysadmins aveva 2 account, uno (non amministratore anche per la macchina locale) utilizzato per attività non amministrative (posta, edizione documenti, ecc.) e uno con privilegi di amministratore AD che avrebbe dovuto essere utilizzato solo per l'amministrazione AD
  • tutti gli altri utenti avevano un solo account non amministratore
  • agli sviluppatori (e ad alcuni utenti esperti ) veniva fornito un account locale con privilegi di amministratore della macchina locale. Doveva essere usato raramente quando era richiesta l'amministrazione locale.

Rifiutare i diritti di amministratore agli sviluppatori sarà una causa di perdita di produttività e ciò ha un costo immediato per qualsiasi organizzazione. La scelta di concedere i privilegi di amministratore sulla macchina locale all'account principale oa un account secondario dovrebbe dipendere dalla frequenza delle operazioni dell'amministratore:

  • Se più di diverse 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 ...

Sì, abbiamo fatto anche questo.Sebbene i nostri account amministratore AD avessero anche privilegi di amministratore locale su ogni macchina (che faceva parte del dominio / annuncio).
Oggi abbiamo avuto un incontro con il nostro team IT a riguardo e sono propenso a contrassegnare questa risposta come risposta semplicemente perché questa è la soluzione che hanno trovato per noi.
Considerazioni: quanto accesso a Internet per l'account AD.Sul posto di lavoro, il mio AD non ha praticamente accesso a Internet (esclusi gli aggiornamenti di Visual Studio).Devo usare il mio normale account per Internet / download / ecc.
#7
+13
John-M
2018-07-16 18:08:01 UTC
view on stackexchange narkive permalink

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 per lo sviluppo.

Sembra che la tua organizzazione sia al confine tra piccole e grandi , quindi ...

Sembra che sia ora che la tua organizzazione sviluppi pratiche di sviluppo più mature.

Per essere onesti, questo tipo di cambiamento non è qualcosa che gruppi di operazioni dovrebbe sorprendere i team di sviluppo con, come sembra sia stato fatto nel tuo caso.

La sicurezza e la produttività degli sviluppatori non devono necessariamente contrapporsi per la tua azienda. Puoi evitare del tutto questo conflitto eseguendo le tue attività di sviluppo su una rete che non ha accesso alle risorse sulla tua rete aziendale principale.

Non stai comunque facendo sviluppo contro le tue risorse di produzione, giusto?

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

Una pratica molto migliore è avere un intero ambiente di sviluppo che replichi parti 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 necessitano del pieno controllo delle macchine in questo ambiente di sviluppo. Non richiedono il controllo completo 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.), connessi o meno a Internet
  • Ambienti virtualizzati (inclusa 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) per qualsiasi condivisione che devi fare dentro e fuori dall'ambiente di sviluppo.

Ambienti di sviluppo dovrebbe essere protetto come la maggior parte delle reti. Non limitarti a lanciare tutto il tuo codice e le risorse di sviluppo online senza pensare al controllo degli accessi o alle misure di sicurezza di base.

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

Piuttosto che scrivere la mia risposta, voglio basarmi su questa.Nel mio lavoro, distinguiamo tra: 1) server di sviluppo, 2) altri server non di produzione (QA, TST ecc.) E 3) produzione.Gli sviluppatori possono avere accesso amministrativo per svolgere il lavoro di sviluppo, ma ci si aspetta che impacchettino il loro codice e altre risorse e ce li forniscano per la distribuzione in altri ambienti non di produzione, insieme a tutta la documentazione su eventuali modifiche del sistema operativo che devonoessere fatto.Non li voglio nemmeno su quei sistemi del gruppo 2 che introducono differenze da Prod, che vanifica lo scopo del gruppo 2.
Questa è la risposta corretta.Gli sviluppatori dovrebbero / devono avere accesso amministrativo alle loro workstation di sviluppo ma NON dovrebbero avere accesso a sistemi di produzione, db con dati sensibili ecc. Da tali workstation.
Nell'era del GDPR, tenere gli sviluppatori fuori dai sistemi di produzione è praticamente un obbligo legale.L'aspetto positivo delle leggi è che possono prevalere sulle politiche aziendali interne.
**

Non hai bisogno di un testo enorme e in grassetto per far leggere la tua risposta o il tuo punto di vista.

**
#8
+11
Tom K.
2018-07-16 19:40:43 UTC
view on stackexchange narkive permalink

Prima di tutto devi imparare che non importa cosa "è comune" o "tipico" perché: in genere queste situazioni vengono gestite in modo orribile . Stai facendo il caso migliore per questa affermazione.

Se l'accesso di amministratore locale è necessario per una persona (sia essa un appaltatore o un dipendente), allora è l'obbligo della sicurezza squadra / persona - chiunque sia responsabile di quella particolare area - per trovare una soluzione. Esistono molteplici soluzioni: la creazione di una VLAN isolata, le macchine virtuali e altre sono state nominate qui.

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

Se la soluzione che è stata implementata non funziona correttamente e quindi continua a impedirti di lavorare, parlane di nuovo con il team / persona di sicurezza. Se questo non funziona, parlane con il tuo capo o con il tuo contraente.

Quello che stai facendo in questo momento è bruciare soldi e nient'altro. Se gli altri partecipanti a questo gioco non lo hanno ancora capito, è un male. Ma va bene se lo fai.

In realtà, dal momento che hai osservato la risposta di Marcel: sembra che la * tua * risposta non risponda alla domanda e in realtà si rifiuti esplicitamente di farlo.Se vuoi incoraggiare il PO a porre una domanda diversa e più pertinente, considera di farlo in un commento.
C'è una differenza tra non rispondere alla domanda e dare una prospettiva diversa o provare a mostrare a OP il problema sotto un'altra luce.
#9
+8
James_pic
2018-07-16 18:01:03 UTC
view on stackexchange narkive permalink

Questo dipende fondamentalmente dal contesto e in particolare dal 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 Sistema operativo su di esso.

In alcune organizzazioni, tutto lo sviluppo deve essere svolto in un ambiente con intercapedine, in cui nessun dispositivo elettronico può essere inserito o estratto.

La maggior parte delle organizzazioni si trova da qualche parte tra questi due estremi. Più l'ambiente di sviluppo è bloccato, meno produttivi saranno i tuoi sviluppatori e più è probabile che tu perda i tuoi migliori talenti. La tua organizzazione deve valutare la probabilità e l'impatto di una workstation per sviluppatori compromessa e quanto è disposta a ridurre la produttività degli sviluppatori per mitigare questo rischio.

#10
+8
UEFI
2018-07-16 15:21:51 UTC
view on stackexchange narkive permalink

Ho visto due approcci che funzionano.

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

Se fai quello che fa la tua azienda ora, i tuoi sviluppatori lo sopporteranno per un mese circa, quindi inizieranno a cercare nuovi lavori.

3-4 persone, a tempo pieno ?!Sono molti soldi che penso potrebbero essere spesi meglio.E potresti voler approfondire il motivo per cui pensi che dare le autorizzazioni di amministratore agli sviluppatori sia la scelta migliore.
@Luc Molti strumenti di sviluppo fanno molto affidamento sui privilegi di amministratore locale.MS Visual Studio, ad esempio, non necessita di tutti i privilegi di amministratore locale per funzionare correttamente, ma necessita di determinati privilegi di amministratore.DEBUG_SE per il debug, gestione dei servizi per - buona - gestione dei servizi, creare diritti per i database e potrei andare avanti per anni.Ora rilevare il motivo per cui uno sviluppatore non è in grado di eseguire uno script di database, eseguire il debug di un'applicazione o installare un servizio può essere estremamente dispendioso in termini di tempo, ed è il tempo di detto sviluppatore o il tempo del personale dedicato.
È del tutto irragionevole che qualsiasi strumento di sviluppo necessiti di qualsiasi tipo di accesso amministrativo.Qualunque cosa pensino di averne bisogno, il team IT responsabile della configurazione e della manutenzione delle scatole degli sviluppatori dovrebbe essere in grado di riconfigurare il software o virtualizzare le interfacce appropriate in modo che gli strumenti funzionino senza compromettere la sicurezza dell'infrastruttura.
@R potresti voler leggere su "devops", scoprirai che gli sviluppatori moderni hanno motivi molto ragionevoli per desiderare l'accesso come amministratore.Per me personalmente, non avere il controllo della mia macchina è un'enorme bandiera rossa.Se avvisato in anticipo, declinerò la tua offerta di lavoro, altrimenti le mie prime due settimane saranno le ultime.
@R .. Avvio regolarmente un programma, quindi allego un debugger a quel programma in modo da poter leggere il suo stato interno, sospenderne l'esecuzione e fargli eseguire codice arbitrario.Ciò richiede l'accesso come amministratore.La mia produttività diminuirà se mi vieti di farlo.
@Luc È meglio dare agli sviluppatori l'accesso come amministratore perché è più economico.Significa che non dovrai impiegare 3-4 persone a tempo pieno per mantenere le macchine dello sviluppatore funzionanti e lamentarti della tua politica di sicurezza.
@UEFI: Invece dovrai solo assumere persone per ricreare l'immagine delle macchine degli sviluppatori ogni volta che installano virus e gestire tutto il tempo di sviluppo perso e la possibile perdita di risorse ... Ri: debugging, sicuramente dovrebbe esserci una politica configurabile per consentire non-utenti admin per eseguire il debug * dei propri processi *.
@R .. Quindi il mio browser web che esegue java-script dovrebbe essere in grado di accedere allo stato interno di un altro programma sul mio sistema, come il mio gestore di password?Non vedo problemi di sicurezza con quello ...
@UEFI: No, perché JS è un linguaggio incorporato che non viene eseguito nel dominio dei privilegi del tuo account utente.Funziona in un dominio di privilegi complesso implementato dal browser.È vero che sotto una vulnerabilità sandbox-escape nel browser, ci sarebbe un vettore per il debug di altri processi (ma ci sono già vettori migliori per attaccarti in caso di sandbox escape).In quanto tale, per l'hardening è utile che il criterio di collegamento del debugger sia configurabile e disattivato per gli utenti che non hanno interesse a usarlo.Ma non è un aspetto essenziale di nessun modello di privilegio.
#11
+8
Joshua
2018-07-18 23:19:13 UTC
view on stackexchange narkive permalink

Il problema che hai effettivamente è che l'IT competente sta tentando di applicare una regola testarda. Hai davvero solo una scelta, dare agli sviluppatori un accesso amministrativo efficace.

Continuo a vedere lo stesso consiglio ripetuto più e più volte, che si riduce a una seconda macchina che lo sviluppatore ha come amministratore ma non Internet. Se vuoi avere la sicurezza del formaggio svizzero, questa è la strada da percorrere. Gli elenchi di software installati sul tipico computer di uno sviluppatore sono generalmente più lunghi di uno schermo. Molti di questi hanno una sola opzione per il controllo degli aggiornamenti: Internet. Non puoi correggerli tramite WSU perché WSU non sa che esistono.

Ecco cosa gli argomenti non capiscono: violare gli account personali dello sviluppatore non è un punto di partenza; è il jackpot. Non c'è motivo di rivolgersi all'amministratore da lì. Il violatore ha la capacità di modificare la codebade per inserire backdoor. Ottenere l'amministratore sulla scatola dello sviluppatore non è molto più interessante.

Da cosa ti difendi quando vuoi negare l'amministratore? Qualcuno accede alla base di codice? No. Qualcuno lo usa come punto di lancio? 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. Questa potrebbe anche essere la definizione di eseguire software non approvato.

Ho sentito molte molte storie sulla politica secondo cui gli sviluppatori non ottengono l'amministratore, ma la pratica dell'IT che guarda dall'altra parte mentre gli sviluppatori rovesciano la politica di sicurezza. Ho sentito molti altri dell'IT senza nemmeno scoprirlo. Ho sentito alcuni manager degli sviluppatori dire agli sviluppatori di aggirare i controlli di sicurezza.

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

È molto più saggio fornire agli sviluppatori un amministratore locale su una casella connessa a Internet e al dominio locale ed essere preparati ad affrontare qualunque sia 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 togliere improvvisamente un amministratore come questo quasi sempre porta alla perdita di gli sviluppatori più importanti. Non lo vuoi.

Dato che vuoi parlare dei siti Windows, c'è un aneddoto che supera i dati della maggior parte delle persone. Microsoft fornisce ai suoi sviluppatori l'amministratore locale. Il produttore di Windows ha concluso che non c'è un vantaggio sufficiente nel non dare agli sviluppatori l'amministratore per renderlo utile. Pertanto, dovresti fare lo stesso.

Potete fornire un riferimento per questo?"Microsoft fornisce agli sviluppatori l'amministratore locale. Il produttore di Windows ha concluso che non ci sono benefici sufficienti nel non dare agli sviluppatori un amministratore per renderlo utile".
@Soenhay: https://blogs.msdn.microsoft.com/oldnewthing/20110927-00/?p=9543 e circa altri 50
#12
+7
Fabio says Reinstate Monica
2018-07-18 07:27:52 UTC
view on stackexchange narkive permalink

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

Ogni tanto organizzavano un evento sociale, come giocare a bowling. La partecipazione era gratuita, ma dovevi aggiungere il tuo nome a un elenco in un file Excel, posto in una cartella condivisa. Quella cartella era dedicata agli eventi sociali, nient'altro.

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

Questa è la procedura:

  • Apri il sito dell'azienda
  • Trova la sezione con alcuni moduli pronti per essere compilato
  • Trova e scarica il documento chiamato "Release Sheet"
  • Stampalo
  • Compila la tua richiesta e firmalo
  • Consegnalo alla segretaria
  • La segretaria porterà tutte queste richieste al manager la mattina del giorno successivo
  • Prima o poi il manager la firmerà
  • Te lo riporterà la segretaria
  • A questo punto puoi scansionarlo
  • Apri il sito utilizzato dall'IT per gestire i ticket
  • Crea un ticket che descriva (di nuovo) ciò di cui hai bisogno e allega il foglio di rilascio scansionato. Non dimenticare di impostare l'urgenza, da un'ora a due settimane.
  • Alla fine lo farà l'IT (si spera)

In media, ci vorrebbero 3-4 giorni per farlo. In alcuni casi, settimane. Davvero efficiente, eh? Ehi, hai chiesto l'accesso a una determinata cartella ma hai dimenticato di menzionare la sottocartella? HA! Hai vinto un altro round! E indovina cosa? Dato che stavano seguendo un processo di controllo qualità, stavano organizzando i documenti in molte cartelle diverse. Quando arrivava un nuovo collega, poteva facilmente passare settimane cercando di ottenere tutte le autorizzazioni di cui aveva bisogno.

Adesso.

  • Pensi che i gestori si siano presi la briga di controllare cosa stavano firmando? Certamente no. Hanno riconosciuto il foglio di rilascio e basta.
  • Pensi che le segretarie stessero controllando molto di più? Forse ci hanno provato, ma riescono davvero a capire le implicazioni di avermi dato il permesso di lettura / scrittura su una determinata cartella su una determinata macchina? Certamente no.
  • Pensi che l'IT se ne fregasse dell'urgenza? Certamente no.

Allora, a cosa ha portato questo approccio? Che se volevi rubare tutto ciò che l'azienda ha mai realizzato, dovevi solo portare un'unità USB e collegarla al tuo PC. Nessun accesso alla cartella "Documenti_riservati"? Chiedilo e lo firmeranno. E se è urgente? "Ciao, ho bisogno di quel documento ma non riesco ad 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 intralciare i partecipanti all'evento di bowling ( xkcd obbligatorio).

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

Ed è probabilmente per questo che la mia azienda ha deciso di bloccare le unità USB ... presumo che il loro prossimo passo sarà rimuoverle fisicamente e dare a tutti un mouse e una tastiera blutooth.
#13
+5
James
2018-07-16 13:00:36 UTC
view on stackexchange narkive permalink

Sì e no: i nostri sviluppatori senior hanno un account amministratore separato che consente loro di elevarsi quando necessario e installare applicazioni / aggiornamenti. Tuttavia, non sono autorizzati ad accedere al computer con l'account. Il loro account amministratore consente inoltre loro di accedere come amministratore ai normali computer di sviluppo per fornire un supporto più rapido rispetto al team IT.

Tutto questo è combinato con una lista bianca / nera dell'applicazione, criteri per password complesse, divieto di dispositivi rimovibili, proxy gateway, criteri DLP, regole AV rigorose e altro ancora. Le loro macchine vengono regolarmente controllate e la visibilità del team IT è elevata.

Personalmente, preferirei che gli sviluppatori non avessero accesso amministrativo locale. Potremmo indagare sulle app che richiedono UAC (scoprire le cartelle, i regkeys, ecc. Di cui ha bisogno) e mitigare 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 una fiducia a due vie. Utilizziamo anche più prodotti aziendali per applicare una moltitudine di regole, quindi c'è un certo sollievo in questo.

Questo non risponde alla domanda.Non fornisce alcuna spiegazione se o perché questo sarebbe "tipico".
#14
+4
Yannjoel
2018-07-16 16:25:55 UTC
view on stackexchange narkive permalink

Abbiamo risolto questo problema utilizzando una macchina virtuale .

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

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

Supponiamo solo che l'OP abbia bisogno dei privilegi di amministratore (locale) per eseguire un ambiente di sviluppo.I summenzionati Microsoft Visual Studio e SQL Management Studio, ad esempio, fanno molto affidamento sui privilegi di amministratore.L'altra cosa su cui quel software fa molto affidamento (in termini di aggiornamenti, aiuto in linea, controllo del codice sorgente e potrei continuare per secoli) è la connessione a _Internet_.Avere una VM senza connessione a Internet ma fornire i diritti di amministratore (locale) significa cambiare la roccia con un duro colpo.
#15
+4
Jimenemex
2018-07-16 19:50:06 UTC
view on stackexchange narkive permalink

Sono nella stessa barca dei tuoi sviluppatori di software. La nostra azienda è passata di recente da workstation con accesso amministrativo a macchine virtuali senza. Ha avuto un impatto così grave sul nostro flusso di lavoro che spesso mi sono ritrovato a non fare altro che leggere articoli per il reparto IT per eseguire qualcosa come amministratore per me.

La cosa che la direzione ha escogitato è stata una due macchine virtuali .

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

L'altra macchina virtuale aveva diritti di amministratore locale , ma era completamente disconnessa da Internet . In questo modo, non potremmo scaricare nulla su quella macchina. (Anche se potevamo ancora scaricarlo dall'altro e copiare il download sopra ..) Abbiamo ancora accesso ai siti interni e abbiamo inserito nella whitelist un paio di cose che Visual Studio utilizza (Nuget, Simboli, ecc.)

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

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

Funziona per un negozio Microsoft di base, ma cade quando si esegue lo sviluppo multipiattaforma (Python, Java, Go, NodeJS - tutti hanno i propri framework / repository di pacchetti / set di URL che devono essere inseriti nella whitelist e possono cambiare senza preavviso).Inoltre impedisce di provare qualcosa di nuovo, perché devi saltare i cerchi per ottenere gli URL inseriti nella whitelist solo per testare qualcosa che potresti non usare mai se il test non va bene.Vuoi provare Meteor?Buona fortuna, invia un ticket per ottenere gli URL inseriti nella whitelist e attendi 2 settimane
@ErinDrummond Molto vero e una delle principali insidie di questo approccio.
#16
+4
Tom
2018-07-19 13:07:48 UTC
view on stackexchange narkive permalink

Risposta breve : Sì, è comune avere accesso amministratore locale a gruppi selezionati, come sviluppatori o amministratori IT. Fondamentalmente, le persone il cui lavoro quotidiano è molto più facile con l'accesso amministrativo mentre il solito impiegato d'ufficio ne avrebbe bisogno al massimo una volta al mese e in genere molto meno.

Risposta lunga : Dipende ...

Per la popolazione di utenti in generale, non è necessario eseguire un'analisi completa dei rischi per capire che l'accesso amministratore ha molte potenzialità che le cose vadano male e pochi vantaggi per compensare tale rischio .

Tuttavia, per gli sviluppatori (e pochi altri gruppi), un'analisi dei rischi è assolutamente giustificata e una decisione adeguata in merito basata su fatti, circostanze, propensione al rischio e situazione di minaccia dell'azienda è ha chiesto per. Indicare le "migliori pratiche" e fare una mossa valida per tutti è una scappatoia tipicamente causata dalle persone responsabili della sicurezza delle informazioni che non hanno il tempo e / o le conoscenze per fare i conti e inventare una decisione sul 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 quello che scrivi, quello è uno sconosciuto. Potresti chiedere che venga eseguita un'adeguata analisi del rischio, aggiungendo la tua conoscenza esperta al costo della mitigazione lato dell'equazione, mettendo in cifre la perdita di produttività e altri effetti della misura attuale. Questo deve essere soppesato rispetto al rischio identificato dalle persone che si occupano della sicurezza delle informazioni.

Esistono anche altre misure correlate. Una tipica soluzione che a volte raccomando (sono un architetto della sicurezza delle informazioni di professione, quindi mi vengono poste queste domande regolarmente) è quella di separare la rete degli sviluppatori dalla rete ordinaria dell'ufficio per contenere l'area a più alto rischio. Rafforzare sufficientemente le macchine dello sviluppatore e insistere su firewall locali e protezione antivirus aggiornata e stai bene contro i tipici scenari di attacco. Se la tua azienda ha una certa visibilità all'esterno, potresti anche aggiungere ulteriore formazione di sensibilizzazione per gli sviluppatori in modo che non cadano preda così facilmente di attacchi mirati.

Ho supervisionato personalmente ambienti di sviluppo di entrambi i tipi e con un piccolo sforzo è possibile fare in modo che entrambi funzionino bene. Solo staccare la spina a un modo di lavorare consolidato significava gestirlo male e il contraccolpo di cui facevi parte era prevedibile. Ma quello che viene fatto è fatto ed è probabilmente intelligente non concentrarsi su questo e guardare al futuro.

#17
+3
DoubleD
2018-07-19 02:03:03 UTC
view on stackexchange narkive permalink

Segrega le tue reti

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

Una corretta segregazione impedisce modifiche non autorizzate, limita la diffusione di malware e impedisce l'esfiltrazione di dati.

Cosa succede dove?

Sviluppo

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

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

Test

La rete di test è dove viene testato il codice compilato e pronto per la spedizione. Gli sviluppatori possono disporre dei diritti di amministratore, ma gli amministratori di sistema regolari dovrebbero distribuire le applicazioni.

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

Gli sviluppatori spesso hanno bisogno dei log di sistema e dell'accesso per il debug, e questi sono gli unici motivi per cui dovrebbero avere i diritti di amministratore. Non dovrebbero essere coinvolti nell'installazione, configurazione e test a meno che non sia assolutamente necessario.

Produzione

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

Per ridurre al minimo i rischi di malware trasmesso da Internet e modifiche accidentali, gli account del le reti non dovrebbero avere accesso alla produzione se possibile, il che si traduce in permessi limitati 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, netops e gestione dei progetti. Avvicinati il ​​più possibile all'ideale; è davvero tutto ciò che possiamo fare.

Business

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

Email, navigazione sul Web e connettività dei partner portano tutti un una serie di rischi. Le tue reti di sviluppo, test e produzione dovrebbero essere isolate da questi rischi nella misura massima possibile.

Dettagli, dettagli, dettagli

È possibile che la tua organizzazione abbia esagerato. È più facile far oscillare completamente il pendolo che gestire la miriade di dettagli essenziali per un'architettura di rete flessibile e sicura.

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

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

I tuoi sviluppatori avranno bisogno di quattro account:

  • Account dev senza privilegi per accedere alle risorse su Internet (se non vogliono saltare avanti e indietro dalla rete aziendale, il che è oneroso)
  • Account dev privilegiato per configurare la workstation e il codice di test
  • Account di prova privilegiato per eseguire il debug di applicazioni
  • Account aziendale senza privilegi per e-mail, web, intranet

Se hai sviluppatori che eseguono lavori di convalida o controllo qualità, loro m Hanno anche 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 per il momento ciò è impossibile, questi ruoli dovrebbero essere separati oppure dovrebbe essere messo in atto un rigoroso processo di controllo delle modifiche.

#18
+2
symcbean
2018-07-16 16:41:06 UTC
view on stackexchange narkive permalink

Nonostante MS-Windows NT sia stato un sistema di sistema multiutente sin dal suo inizio, non è molto facile utilizzarlo in questo modo, e gli sviluppatori (incluso 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 di difficile accesso tramite l'interfaccia utente, difficile da controllare, mancanza di schemi / strumenti per applicare la separazione ....

In tutta onestà , anche su sistemi Unix / Linux, vedo molti sviluppatori che 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 gli implementatori separano i privilegi è ancora più controproducente per la sicurezza che fornire loro privilegi di amministratore (locali) completi .

D'altra parte , anche se so poco di sviluppo su MS-Windows, trovo sorprendente che sia richiesto il privilegio di amministratore locale per eseguire Visual Studio. E se l'unico motivo per cui hai bisogno dell'accesso come amministratore è per arrestare / avviare i servizi o riconfigurarli, non ho molta simpatia per te: è possibile fornire questa funzione agli utenti designati senza fornire loro il locale admin. Uno dei grandi cambiamenti in IIS7 è stata la capacità di amministratore delegato. Ed è sempre stato facile delegare la riconfigurazione di Apache, MySQL e PHP.

c'è stato un breve preavviso di quando è stato rimosso l'accesso dell'amministratore locale

Sembra come il problema è che il team di sicurezza aspira a un livello di competenza che non sono in grado di fornire (questo, nella mia esperienza, è molto comune). Non avrebbero dovuto imporre una modifica della politica senza eseguire un'adeguata valutazione dell'impatto e considerare le mitigazioni per eventuali danni alla produttività / sicurezza.

Abbiamo almeno 2 principali programmi antivirus su tutte le workstation

È un approccio molto ingenuo alla protezione dell'integrità di questi sistemi e dipinge un quadro di ciò con cui hai a che fare.

sembra che non ci siano molte alternative là fuori

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

Nel complesso sembra che tu sia in competizione con il tuo team di sicurezza locale. Non capiscono di cosa hai bisogno per fare il tuo lavoro, non capisci come raggiungere i loro obiettivi. E sembra che nessuna delle parti sia disposta a negoziare. Nessuno strumento disponibile in commercio risolverà questo problema.

Uno dei motivi per cui Visual Studio questi diritti di amministratore è abilitare il debug dei processi, di proprietà di altri utenti IIS viene eseguito tradizionalmente con un account di sistema.Non appena lo sviluppatore esegue il debug di un altro processo, potrebbe disabilitare i correttori di virus ecc. Le testine rimosse al 90% rallentano, il che non è raro da loro.Da qui la scelta tra non lasciare che gli sviluppatori usino il debugger e fidarsi degli sviluppatori .....
.... e poi mi sono ricordato perché evito di programmare su Microsoft Windows :)
Di fatto sbagliato.Visual Studio verrà eseguito senza privilegi di amministratore locale e in effetti è ** l'impostazione predefinita **.E se assegni i privilegi di debug agli account sviluppatore, ciò significa che Visual Studio non dovrà elevarsi alle autorizzazioni di amministratore così spesso.È del tutto evitabile?No, gli sviluppatori di driver avranno assolutamente bisogno dell'accesso come amministratore, ad esempio.
Visual Studio * verrà * eseguito senza privilegi di amministratore, ma in alcuni casi non verrà eseguito _properly_ senza privilegi di amministratore.Sì, non sono necessari tutti i privilegi di amministratore locale per funzionare correttamente, ma sono necessari determinati privilegi di amministratore.DEBUG_SE per il debug, gestione dei servizi per - buona - gestione dei servizi, creare diritti per i database e potrei andare avanti per anni.Ovviamente si potrebbe contattare il team di sicurezza e richiedere i determinati diritti di cui si ha bisogno su - diciamo - quotidianamente, ma sai come si chiama?Produttività-assassinio.
@mg30rg: DEBUG_SE in realtà significa "Eseguire il debug del processo di qualcun altro".
@Joshua E cosa pensi sia necessario per eseguire il debug di un servizio Windows in esecuzione con l'account di sistema, ad esempio?Questo scenario è tutt'altro che raro nello sviluppo di Windows.
@mg30rg: Vero, tuttavia se lo sviluppatore sta lavorando su codice che normalmente viene eseguito come amministratore, ha comunque l'amministratore.
@Joshua M-key, e per quanto riguarda lo sviluppo di ASP.Net?Per questo è necessario eseguire il debug di un processo avviato e in esecuzione nel servizio IIS in esecuzione con l'account Servizio di rete?
@mg30rg: Obsoleted da Kestrel.Ora funziona con il nome dello sviluppatore.
@Joshua Kestrel non è certo IIS.
#19
+2
Ian Kemp
2018-07-19 16:32:18 UTC
view on stackexchange narkive permalink

È tipico che l'accesso di amministratore locale venga negato agli sviluppatori in aziende in cui gli sviluppatori sono così inutili / dannosi da abusare di quei privilegi, o dove il dipartimento "IT e sicurezza" è gestito da idioti istupiditi che vedono tutti coloro che non sono nella loro cerchia ristretta come un'ovvia minaccia alla sicurezza per farli sembrare cattivi.

Considerando che il tuo dipartimento "IT e sicurezza" impone anche due programmi antivirus quando Windows ne viene fornito uno gratuito perfettamente funzionante, Sono abbastanza sicuro che tu possa determinare dove si trova il problema nella tua organizzazione e lavorare da lì.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...