Domanda:
Lascio un'azienda e ho troppe password / chiavi
throwaway
2019-10-04 05:00:43 UTC
view on stackexchange narkive permalink

Sono uno sviluppatore di software europeo e sto cambiando azienda. Per svolgere il mio lavoro, negli anni ho ricevuto (dal mio capo e dai colleghi) molti segreti condivisi non personali, come:

  • password degli account di root (es. AWS, Google Cloud, Azure, ...)
  • accesso ai server (password e / o chiavi SSH)
  • credenziali di account online aziendali (ad es. GitHub, piattaforme di e-learning, ...)
  • Chiavi API

Chiaramente, chiunque disponga di questo tipo di informazioni sarebbe in grado di fare cose sgradevoli, come accedere ai dati del cliente o persino eliminare i bucket S3. Inutile dire che una cosa del genere sarebbe enorme per una piccola azienda.

Per essere chiari: voglio lasciare il mio attuale datore di lavoro in buoni rapporti. Nonostante il mio contratto non richiedesse un periodo di preavviso per le dimissioni, ho proposto di rimanere un mese dopo il mio annuncio per preparare la squadra (documentare le cose, aiutare ad assumere qualcun altro, ecc.). Ho anche detto al mio capo e ai colleghi che sarebbero stati liberi di mandarmi un messaggio dopo il mio permesso se avessero avuto bisogno del mio aiuto.

Il mio capo inizialmente stava "bene" con le mie dimissioni; tuttavia negli ultimi giorni ha iniziato a comportarsi in modo strano nei miei confronti (saluti freddi, "dimenticandosi" di CC me in alcune email, ...). Forse queste cose sono solo nella mia testa, tuttavia vorrei proteggermi da qualsiasi tipo di problema futuro. E se un giorno un mio collega avesse distrutto accidentalmente un database? Per proteggersi, mi biasimerebbe perché avevo le password?

Questi dettagli di accesso sono memorizzati nella mia email aziendale (a cui perderei l'accesso dopo aver chiuso), sul mio computer (la politica è "porta il tuo laptop ") o il mio account Google (utilizzo" salva password "in Chrome). Queste non sono le migliori pratiche, ma tutti gli altri fanno lo stesso. Pulirò chiaramente il mio computer / account dopo aver smesso, ma non ci saranno prove che non abbia stampato o memorizzato tali segreti.

Come nota finale di confusione, non saranno in grado di ruotare chiavi / password a breve termine (ad esempio il giorno successivo alla mia dimissione). Alcune password non sono mai state modificate dalla creazione degli account, anche dopo che altri dipendenti se ne erano andati.

Cosa faresti?

Sono queste password condivise da tutti?O sono password specifiche per il tuo ID?Vale a dire che a) condividete tutti l'account "admin" e tutti conoscono la password ........... oppure b) avete il vostro account "throwaway_admin" e la vostra password * chenessun altro lo sa *?Se l'account "throwaway_admin" fosse cancellato alle 5:00 al momento della chiusura, sarebbe sufficiente?
Un buon punto a tua difesa, se necessario, è che anche i precedenti uscenti hanno ancora accesso poiché le password non sono mai state cambiate ...
@Harper Ho tantissimi account "admin" (ad es. Accesso root dell'account AWS, chiavi SSH di root dei server, chiavi API) e alcuni account "my name" (es. Account AWS IAM).Il mio problema riguarda il primo tipo di segreti, sarebbe facile cancellare / disattivare i singoli account nel mio ultimo giorno davanti al mio capo.Grazie!
@SolarMike hai ragione, inoltre nel mio paese questo tipo di reato è personale, quindi in tribunale devono dimostrare che un ipotetico bucket S3 è stato cancellato da me.Non voglio arrivare al dunque per dimostrare che non sono una testa di cazzo!
per quanto riguarda _ "la distruzione accidentale di un database" _ o altri problemi simili: se il tuo dba o il tuo addetto IT interno vale i suoi soldi, tutte le connessioni e le operazioni client inclusi i dettagli di chi, dove e quando sarebbero comunque archiviati in un registroquindi sarebbe difficile biasimarti, a meno che tu non riesca a bypassare i loro firewall e compromettere da remoto e catturare il loro sistema e pulire anche i log dei router e dei firewall;)
Dieci risposte:
Joe Strazzere
2019-10-04 05:13:46 UTC
view on stackexchange narkive permalink

Cosa faresti?

Vorrei fare un elenco di tutti questi accessi e mi offrirei di aiutare la persona che aveva il compito di cambiarli tutti. Man mano che ogni modifica della password veniva completata (dall'altra persona, utilizzando password a me sconosciute), la cancellavo dall'elenco.

Durante il mio ultimo mese, inviavo l'elenco aggiornato con ciascuno dei miei rapporti sullo stato, quindi l'elenco finale del mio ultimo giorno.

Se qualcuno fosse rimasto invariato, starei tranquillo, sapendo che ho dato loro un mese insieme a tutto ciò di cui avevano bisogno per portare a termine il lavoro.

Questa è una risposta ragionevole ma non riesce a proteggere sufficientemente il dipendente in partenza.Il timore di Throwaway non è che l'azienda possa subire danni per violazione della sicurezza dopo che se ne sarà andato, ma che incorreranno in danni per violazione della sicurezza * e daranno la colpa a lui *.Throwaway vuole dimostrare di non avere più accesso ai beni protetti dell'azienda.
@A.I.Breveleri: L'azienda ha scelto di fornire credenziali condivise ai propri dipendenti invece di utilizzare account utente specifici che possono essere disabilitati individualmente.È su di loro, non su OP.Se OP avvisa semplicemente l'azienda con largo anticipo della data di partenza che le password su queste credenziali (elencate da OP) devono essere cambiate;questo è sufficiente per coprire OP.Se le password non sono state modificate, l'azienda è responsabile delle conseguenze della mancata modifica di tali password.La risposta di Joe contiene già più diligenza di quella (minimamente) richiesta per coprire le spalle di OP, non è sufficiente.
Lascia che siano firmati quando le password vengono cambiate rispetto all'originale.
In qualche modo questo va quasi troppo lontano, eppure non abbastanza, IMO.Fornirei un documento con l'elenco, affermando che " eseguirà il miglior lavoro di pulizia dei gestori di password delle suddette credenziali e che non riterrà responsabile per la successiva perdita o utilizzo delle suddette credenziali"... chiedi a un avvocato di esaminarlo e fallo firmare a e .(IN BLOOOOD) ... lascia che sia il datore di lavoro a quel punto se le credenziali rappresentano un rischio così com'è, ma copriti il culo.
O, per lo meno, assicurati di aver inviato una dichiarazione scritta in cui dichiari di aver cancellato i crediti dalle tue cache, consiglia e confida che verranno tutti ruotati dopo la tua partenza ... E, probabilmente invia il tuo indirizzo personaleuna copia di questa email (forse senza l'elenco enumerato degli account per i quali avevi le credenziali).
Questa è una risposta ragionevole.* Non * è responsabilità dei PO occuparsi della sicurezza IT quando si lascia l'azienda.Un buon reparto IT dovrebbe sapere *** ESATTAMENTE *** chi ha accesso e per apportare le modifiche appropriate quando qualcuno se ne va.Fare un elenco non dovrebbe essere necessario, ma mostra buona fede.
Aggiungerei per dare la priorità a tutte le password che possono essere utilizzate da Internet.Conoscere la password di alcuni server che non sono accessibili da Internet è meno critico.
Harper - Reinstate Monica
2019-10-04 08:39:10 UTC
view on stackexchange narkive permalink

Sei davvero vulnerabile a questo tipo di accuse. Tuttavia, questo è in parte un pasticcio creato da te, perché finora non hai utilizzato buone pratiche di sicurezza. Lo sai, e non voglio dilungarmi.

In genere ci sono tre tipi di modelli di sicurezza per un sito web orientato ai servizi.

  • Un accesso (account / password) per l'account aziendale. Tutti gli utenti dell'azienda devono condividere la password e ognuno di loro può causare il caos. MailChimp è così, per esempio.
  • Un account / password principale per l'account aziendale. È possibile condividere solo la password, ma offrono anche la possibilità di creare singoli account secondari , un login / password per ogni dipendente. Ogni attività viene registrata nel suo account secondario PayPal funziona in questo modo: i miei dati di accesso per la società ABC sono ABCCo-Harper e ABCCo-HarperAdmin. (Il primo è riservato solo al punto vendita).
  • Il sito consente solo account di persone reali , quindi associa le aziende agli umani. Esempi sono una "Pagina" aziendale di Facebook, in cui un numero qualsiasi di persone sono amministratori, collaboratori o inserzionisti.

I server nei tuoi locali accettano sicuramente il modello "subaccount"; interrompi la condivisione di root e configura account amministratore con sudo.

Districare questo Web contorto

È troppo tardi per fare la cosa più importante: deviare dalla tua strada per selezionare fornitori con robuste architetture di password. Quando ho impostato i nostri sistemi aziendali, ero molto selettivo su questo; tuttavia, la metà dei nostri account è del tipo a password condivisa perché così pochi fornitori supportano account sub / reali.

Sui siti "solo per account umani reali", il sito ti ha già costretto a un modello di sicurezza competente . In questo momento: assicurati che le persone corrette nella tua azienda abbiano un account e promuovili in modo appropriato; almeno uno deve essere il grado più alto. Il tuo ultimo giorno: dì al sistema di dissociare il tuo account con la risorsa dell'azienda. Vai tranquillo.

Sui siti capaci di account secondari individuali, subito : imposta i subaccount per le persone corrette nella tua azienda, incluso te stesso, emettili password e dimentica le password che hai emesso. Assicurati che il personale appropriato abbia la password principale e chiedi loro di cambiarla immediatamente. Il tuo ultimo giorno : allontanati e non accedere nuovamente al tuo account secondario. Dovrebbero eliminarlo , ma se non lo fanno, chi se ne frega? Il journaling del sistema dimostrerà che non hai fatto nulla.

Su tutti gli altri siti, innanzitutto: assicurati che le persone interessate abbiano le password corrette.

Hai una varietà di password che non sono cambiate per troppo tempo. Cambiali. Ciò vale anche per qualsiasi password che hai memorizzato in un modo che sai essere stupido. Presumi che sia compromesso e cambialo ORA e dai loro la nuova password. Devi farlo ora, mentre c'è ancora un mese di tempo di recupero. Farlo nella tua ultima settimana è troppo tardi.

E ripulisci dietro di te; dopo averle reimpostate, elimina tutte le password da luoghi in cui non dovrebbero essere, come le email (!), i documenti Google e simili. Non sono sicuro di come mi sento riguardo ai gestori di password; sono lontani dal peggio e non dal modo meno brutto per affrontarlo.

E non fare nuovi guai; se qualcuno chiede una password, non mandarla via email / tweet / Facebook Messenger. Smettila. Scrivilo su carta, sigillalo in una busta e consegnalo a loro. La sicurezza fisica è il loro problema. Oppure chiamali al telefono e leggiglielo.

Distribuzione di nuove password

Ho a che fare con technophobe peli appuntiti, quindi creo le password su carta. Creo un documento MS-Word che elenca ogni account e A B C D E F G dove andrebbero le password. Che può essere distribuito elettronicamente. Poi ho un altro foglio che dice semplicemente A B C D E F G con uno spazio per una password per ciascuno, e che consegno a mano. Per i manager dai capelli appuntiti che difficilmente le useranno, ho messo le password principali in una busta dicendo "Password principali! Non aprire se non in caso di emergenza".

Per quanto riguarda la generazione delle password, alla fine ho finito di dischi AOL :) Quindi utilizzo un frammento di perl e / usr / lib / dict / words per generare una password di tipo CorrectHorseBatteryStaple ottimizzata per funzionare sulla maggior parte dei siti ed essere mobile-friendly (cioè non stai digitando turni più di caratteri).

Facendole reimpostare dietro di te

Quando si distribuiscono loro nuove password, inviare un'e-mail separata informandoli professionalmente che hai cambiato password, l'elenco degli account per cui hai cambiato password, e dichiara di aver fornito l'elenco delle password su carta (o comunque). CC questo al tuo indirizzo email personale fuori sede e BCC al tuo avvocato . Inutile dire che questa email NON deve contenere password .

Quindi, quando esci, invia loro un'altra e-mail nello stesso modo ricordando loro che stai per lasciare la società in data / ora e per favore cambia le password condivise dietro di te. Ancora una volta, CC al tuo personale e BCC al tuo avvocato.

In realtà, a questo punto, hai fatto tutto il possibile. Se hanno problemi, tu e il tuo avvocato sventolate quei documenti in tribunale, dimostrando che era loro responsabilità cambiare le password dietro di voi, e glielo avete detto . (Ovviamente neghi anche di fare qualsiasi cosa; ma mostrando la loro negligenza, riduci qualsiasi richiesta di risarcimento danni.)

Si spera, se fai come dico, li hai "riscaldati" all'idea di cambiare le loro password di tanto in tanto. Anche loro sanno che devono farlo; hai appena fatto il lavoro pesante per loro.

Ora, iscrivi un alleato in azienda per reimpostare le password dietro di te.

NON accedere in nessun caso a un account "per vedere se hanno cambiato la password". Non importa quanto sei curioso! Non dovresti nemmeno possedere altre password; dovresti averle eliminate da dove conservi le password. Sii accurato. Certamente se c'è un contenzioso, citeranno in giudizio il tuo laptop e un elenco di account da 1password, ecc. Se mostrano che hai conservato le password, ciò minerà la tua difesa che non sei stato tu.

Grazie per il tempo speso a scrivere una risposta così buona.Penso che funzionerà per la maggior parte delle persone nella mia posizione.Sono ancora nei guai perché mi resta solo 1 settimana e cambiare qualche password / chiave sarebbe una vera PITA (per cattive pratiche stabilite prima del mio arrivo, es. Una chiave API potrebbe essere condivisa tra più servizi, nessuno ricorda quale,cambiarlo e vedere cosa si rompe).L'altra mia paura è: se chiedo loro di cambiare tutto quello che so, sospetteranno (dato che nessuno ha un elenco chiaro di tutte le credenziali aziendali!) Che sto progettando di fare qualcosa di brutto con i segreti dimenticati (invariati)?
Dubito davvero che possano dedurre qualsiasi cattiva intenzione.Lo vedrebbero come una mossa CYA, che è esattamente quello che è! E probabilmente ti ignorerebbero.Devi solo fare la tua parte della consegna della password nel modo più responsabile possibile e lasciare una traccia cartacea che hai fatto, quindi hai quella traccia cartacea da sventolare in tribunale se sei una controversia.Oppure, in alternativa, esci, vanno come stanno le cose, * qualcun altro viene licenziato e loro dicono 'fumo santo, quel tizio ci spazzerà via, dove ci sono stati tutti quei biglietti usa e getta?'
@throwaway inoltre, la sicurezza è sempre scomoda.Natura della bestia.Prepararsi male lo rende molto più scomodo, che è il problema che devono affrontare oggi.
Keltari
2019-10-07 01:58:02 UTC
view on stackexchange narkive permalink

In qualità di manager IT con oltre 2 decenni sul campo, posso dirti che non c'è nulla di cui bisogno . Una corretta sicurezza IT significa che il dipartimento deve avere record di quali utenti o applicazioni hanno accesso a quali risorse. Quando qualcuno se ne va, o c'è un controllo, o semplicemente cambiando password / chiavi / ecc. In base a una pianificazione, questi record dovrebbero essere referenziati e aggiornati. Sfortunatamente, non tutti i dipartimenti IT lo fanno, il che li lascia inconsapevolmente vulnerabili.

Sebbene non sia necessario, fare un elenco di tutto ciò a cui hai accesso mostra la buona fede della tua azienda. Potrebbe non essere una cattiva idea dire loro di investire in un adeguato sistema di controllo delle password.

PeteCon
2019-10-04 18:58:19 UTC
view on stackexchange narkive permalink

In primo luogo, vorrei identificare le persone / persone che assumono il tuo ruolo. Se non riesci a trovare quella persona, rendila tuo manager.

Apri un account LastPass Corporate (altro accesso sicuro, addebitato direttamente all'azienda. Invita te stesso e la persona sostitutiva all'account. Aggiungi tutti i dettagli di accesso che hai protetto (in modo insicuro) nella tua email.

Tutti gli accessi che sono legati direttamente a te - modificali in modo che utilizzino i dettagli aziendali, ad esempio invece di registrarti come "fred.bloggs@example. com ", utilizza" systems@example.com ", che può quindi portare a una lista di distribuzione.

Man mano che aggiungi identità a lastPass, rimuovile da qualsiasi sistema a cui potrai accedere dopo essere uscito Disabilita anche tutti i dettagli di accesso personali (ad esempio i tuoi account utente AWS - NON eliminare gli account utente root :)) una volta che sai che non ne avrai più bisogno.

Conserva un record in Excel di tutte le modifiche apportate (ad es. "Account AWS 123456 - password modificata per Fred Bloggs" - non inserire alcuna informazione segreta lì dentro). Dai quel record al tuo manager quando esci, disassocia il tuo account personale da LastPass (se era collegato all'account aziendale) e invia un'e-mail al tuo manager suggerendo vivamente di cambiare la password principale di LastPass e tutti gli account all'interno.

Come qualcun altro ha detto in precedenza; non provare ad accedere ad alcun account "per vedere se la password è stata cambiata". Non vuoi che venga visualizzato alcun record di controllo dei tuoi accessi dopo che te ne sei andato.

Preferirei una soluzione in loco come KeePass2, invece di fornire le password a un servizio di terze parti come LastPass.
Kilisi
2019-10-04 16:36:56 UTC
view on stackexchange narkive permalink

Quando ti trovi in ​​questo tipo di posizione critica, la cosa professionale da fare è comporre un documento / manuale di passaggio di consegne per chi subentra nel ruolo.

Ciò includerebbe qualsiasi conoscenza specifica del ruolo , procedure dettagliate per qualsiasi cosa importante o specifica del lavoro e una sezione che include nomi utente e password.

Questo serve come riferimento per la persona successiva e diventa parte delle risorse dell'azienda. Ho visto i documenti di consegna che ho realizzato oltre un decennio fa ancora in uso diverse persone dopo, con loro che si sono semplicemente aggiornati o aggiunti nel corso degli anni. Un buon documento di consegna è una preziosa risorsa formativa e di riferimento.

Prenditi il ​​tuo tempo e fallo correttamente. Li faccio completi di screenshot, diagrammi e procedure suddivise fino alle basi come se i lettori fossero principianti.

sf02
2019-10-04 19:17:53 UTC
view on stackexchange narkive permalink

Cosa faresti? Grazie in anticipo!

Non fare nulla. Se hai ancora la possibilità di accedere a qualsiasi account dopo il tuo ultimo giorno, non farlo! Sì, l'azienda può subire una sorta di violazione della sicurezza e tu puoi essere accusato, ma finché smetti di accedere a quegli account non ci saranno prove di illeciti da parte tua.

Se sei uscito in buoni rapporti, non dovrebbero nemmeno considerarti un sospetto se si verifica una violazione della sicurezza. Ho lasciato alle aziende tali informazioni privilegiate e ho avuto l'autocontrollo per non tentare di utilizzarle. Fai lo stesso e non dovresti preoccuparti di nulla.

RandomUs1r
2019-10-04 22:26:49 UTC
view on stackexchange narkive permalink

Chiariamo alcune cose prima di fare una raccomandazione:

Quando lasci non dovresti più accedere alla tua rete aziendale tipicamente tramite il manuale del dipendente, un NDA, ecc ... una sorta di accordo, se non è presente a. il tuo datore di lavoro è stupido b. non dovresti più accedere alla causa dell'etica della rete.

Quindi, una volta che hai smesso di preoccuparti, non ne possiedi nulla, incluso il tuo account & email di lavoro.

Ora, se vuoi essere gentile ... crea un documento o meglio ancora un file Keepass e condividilo. Puoi controllare Keepass nel codice sorgente.

The Anathema
2019-10-08 19:39:43 UTC
view on stackexchange narkive permalink

Probabilmente è troppo tardi per questo, ma se puoi o in futuro, sfrutta una tecnologia come Active Directory / LDAP con un archivio chiavi centralizzato. La configurazione della tua azienda è semplicissima.

In questo momento, la soluzione migliore è trasferire tutto a qualcun altro. Se possibile, dovrebbero aggiornare tutte le password, chiavi e segreti e metterle in un archivio chiavi dietro la sicurezza.

Con tali tecnologie, avresti un insieme centralizzato di utenti, ruoli, gruppi e autorizzazioni. Con il giusto ecosistema, come Active Directory con Azure Key Vault, tutti i segreti possono essere centralizzati e nascosti dietro un criterio che definisce il giusto set di autorizzazioni.

Inoltre, ad esempio, è possibile utilizzare Active Directory per praticamente tutto. La posta elettronica, l'ambiente Azure, gli accessi al server, ecc. Tutto è un account di dominio e tutto è sempre nascosto da una cosa: il tuo login di dominio. Questo è elegante.

Quando un dipendente lascia il posto di lavoro, il suo account viene semplicemente disabilitato e quindi anche il suo accesso a ogni chiave e segreto è disabilitato. Il loro accesso a ogni server, controllo del codice sorgente o ambiente cloud è disabilitato. È molto pulito. Ci vuole solo un'architettura aziendale adeguata. Potrebbero esistere alcuni strumenti di migrazione, ma spostare tutte le chiavi sarebbe un po 'complicato, a seconda di come le hai memorizzate (Excel, blocco note, tovaglioli, ecc.)

Ertai87
2019-10-08 20:37:58 UTC
view on stackexchange narkive permalink

Non devi fare nulla. Nel sistema legale, c'è lo standard di "innocente fino a prova contraria". Ciò significa che se hanno una violazione della sicurezza e ti incolpano per questo, devono dimostrare in tribunale che sei stato tu a hackerarli usando le tue credenziali. Che, dati i loro spaghetti di sicurezza, probabilmente non saranno in grado di fare anche se li hai hackerati, quindi legalmente probabilmente non sei responsabile di nulla (IANAL).

Professionalmente, quello che dovresti fare sei tu dovrebbe dire loro "queste sono le cose a cui so di avere accesso" (potresti avere accesso ad altre cose che non conosci / hai dimenticato) ed enumerarne quante più possibile. Quindi invia quell'e-mail al tuo capo e / o al reparto infosec della tua azienda. Dopodiché, non c'è molto che puoi fare; è loro compito revocare le tue autorizzazioni e assicurarsi di non avere accesso dopo aver lasciato. Se scelgono di non farlo, è sulla loro testa, non sulla tua. Quanto alla tua responsabilità, eticamente (e probabilmente anche legalmente) non dovresti usare quelle credenziali che hai, anche se sono ancora valide, per qualsiasi motivo , dopo il tuo ultimo giorno in ufficio. Che sono sicuro che probabilmente era comunque il tuo piano e non aveva bisogno di essere riaffermato, ma questo è il lungo e il corto.

Davide Visentin
2019-10-04 12:05:36 UTC
view on stackexchange narkive permalink

Come nota finale di confusione, non saranno in grado di ruotare chiavi / password a breve termine (es. il giorno dopo la mia uscita). Alcune password non sono mai state cambiate da quando sono stati creati gli account, anche dopo che altri dipendenti se ne sono andati.

È sbagliato, non ha senso e devi esortarli a cambiare questa politica. Può sembrare una richiesta scortese, ma le conseguenze se qualcuno fa danni con quelle credenziali e ti accusa potrebbe essere molto peggio del rischio di bruciare ponti con l'azienda.

Scriverei una mail al capo come :

Caro capo, questa mail serve a ricordare che ho ancora accesso ai seguenti account:. Dato che me ne andrò, ti chiedo gentilmente di intraprendere azioni durante questo periodo di tempo per modificare le credenziali e assegnarle ad altre persone. Cordiali saluti

L'ultimo giorno (o pochi giorni prima), invierei un'altra mail affermando chiaramente che se le credenziali non verranno modificate, intraprenderò azioni legali per proteggermi.

Inoltre, BCC invia entrambe le mail al tuo avvocato.

"Prenderò azioni legali per proteggermi".Ad esempio?Sembra una minaccia piuttosto vuota.
Bene, lascia che sia il capo a decidere se vuole correre il rischio di scoprire se si tratta davvero di una minaccia vuota, o preferisce semplicemente cambiare le password.Tuttavia, se invii in BCC le email di cui sopra al tuo avvocato, puoi almeno dimostrare di aver chiesto di essere dissociato dagli account.
Penso che probabilmente non intendevi * fingere *, che è un falso amico con alcune (tutte?) Lingue romanze.In inglese, * fingere * significa * agire come se qualcosa fosse vero quando sai che non lo è *.Penso che probabilmente intendevi "* devi ** provare ** per convincerli a cambiare questa politica *".
@PeterTaylor hai ragione, grazie.L'ho riformulato.


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...