Alice ed Eve lavorano per Bob. Alice è un'ottima lavoratrice che fa esattamente ciò che Bob le chiede di fare. Eve è una mente criminale determinata a distruggere l'azienda di Bob.

Alice ed Eve condividono entrambi lo stesso account.

Eve accede all'account e lo utilizza per sabotare un importante processo aziendale . Il registro di controllo cattura questa azione.

Come fa Bob a sapere chi ha sabotato la sua azienda? Deve sbarazzarsi del cattivo attore, ma non può licenziarli entrambi, perché la sua compagnia dipende dal lavoro che fanno. Potrebbe licenziarne uno solo, ma non ha modo di sapere quale sia il suo amico e quale sia il suo nemico.

Se Alice ed Eve avevano account separati, Bob poteva essere sicuro che Eve fosse quella che ha fatto il sabotaggio. Eve potrebbe anche evitare di fare il sabotaggio, se sa che il suo account verrà controllato e lei sarà catturata.

EDIT: aggiunta dai commenti:

Se Eve esce, ora devi reimpostare la password su ogni account a cui aveva accesso, invece di disabilitare semplicemente i suoi account personali. È molto più difficile da gestire e perderai gli account.

Inoltre, ti elimina la possibilità di avere un controllo granulare sull'accesso. Se Alice dovesse scrivere assegni ed Eve dovrebbe firmarli, essenzialmente non hai alcun modo tecnologico per imporlo se condividono lo stesso account.

Inoltre, rende più difficile per un dato individuo notare dannosi modifiche al loro ambiente. Alice sa quali file ci sono sul desktop di Alice. Qualsiasi nuovo file probabilmente solleverà una bandiera rossa per lei. Alice non sa quali file ci sono sul desktop condiviso di Alice ed Eve. È probabile che i nuovi file vengano accolti con un'alzata di spalle e supponendo che sia stato inserito da un altro utente, non da un malintenzionato.

Storia vera, accaduta sul posto di lavoro di un amico (giurisdizione: Germania):

Un collega dei suoi clienti ha insultato sgarbatamente tramite la sua e-mail aziendale. È stata licenziata per questo. È andata in tribunale. Lì, il suo avvocato ha informato il tribunale del fatto che i dipendenti condividevano le loro password (ad esempio, per aver risposto alla posta di un cliente in assenza di un certo collega).

Il giudice ha stabilito che c'era nessuna prova valida che la persona in questione fosse davvero quella che ha inviato le e-mail offensive. La persona doveva essere riassunta e compensata per il salario perso.

Morale: una funzione degli account utente è distinguere gli utenti l'uno dall'altro, per rendere la loro azione verificabile. Solo gli account privati ​​svolgono questa funzione.

Dovresti usare un account separato in tutti i contesti (sicurezza in alto).
L'esempio di Adonalsium ti mostra perché è obbligatorio. Ci sono alcune rare situazioni in cui è "non possibile" o "non utile" ...

Esempi: "non possibile" (protocolli / applicazioni precedenti) "non pertinente" (azioni anonime)

Se non è possibile, ma è necessario identificare, è necessario mitigare il rischia di aggiungere più informazioni possibili sulla fonte (ad esempio informazioni sulla connessione, tempo di connessione, ecc ...)

Puoi controllare la metodologia di valutazione del rischio ISO 27001, la gestione del rischio ISO 31000 come punto di partenza per rispondere alla tua domanda evitare gli account utente condivisi? "

La risposta tipica è responsabilità, tracciabilità, ecc. In altre parole, essere in grado di sapere chi ha fatto esattamente cosa.

Un account condiviso ha n potenziali persone che fanno qualcosa, ma tutto ciò che hai indica un account che fa quella cosa.

Questo problema viene solitamente risolto assicurandosi che qualcuno sia legalmente responsabile delle attività di questo account. Ciò può essere fattibile o meno e potresti non avere qualcuno che si assume la responsabilità delle azioni degli altri.

Questo problema si verifica spesso quando esternalizzi alcune attività di monitoraggio: l'account che esegue le attività di monitoraggio dovrebbe essere contrattualmente responsabile di tale azienda, che è responsabile delle sue azioni.

Se non è possibile assegnare una persona responsabile, spetta alla direzione prendere una decisione in base al rischio: non avere un servizio vs. sapere chi fa cosa con quell'account.

Le migliori pratiche non sono "definite" da nessuna parte, questo è il significato del termine. Una buona pratica è semplicemente un modo consolidato di fare cose che la maggior parte delle persone pensa sia il modo migliore.

Va ​​il contrario. Una volta che una "best practice" è dominante, di solito qualcuno in un comitato per gli standard decide di inserirla in qualche ISO o altra norma. Quindi rimane lì, di solito senza un ragionamento esplicito o un ragionamento circolare che sottolinea che questa è la migliore pratica.

Le ragioni di questa pratica particolare sono ugualmente pratiche. Se Alice e Bob condividono un account e accade qualcosa di brutto, entrambi indicheranno l'altra persona e non avrai modo di capire chi è stato. Con gli account personali, sostengono che sia stato compromesso, ma poi hai almeno un unico punto per indagare ulteriormente.

Esistono anche requisiti espliciti per la responsabilità in molti sottocampi come la conformità e giocare in questo.

Conosco solo un'eccezione a quella regola. C'è una sola macchina condivisa da più utenti e le seguenti affermazioni sono tutte vere:

• uno e solo uno di quegli utenti è responsabile di questa macchina in qualsiasi momento
• l'account può essere utilizzato solo sulla macchina locale - disabilitato tramite rete

Ciò può accadere su sistemi 7/7 24/24. In quel caso d'uso, si mantiene comunque un'imputabilità accettabile conoscendo l'utente che era presente in un momento specifico, a condizione di poter impostare la seconda regola di cui sopra. Ma in realtà, equivale ad avere un account senza password e utilizzando solo la sicurezza fisica.

Un altro problema non ancora menzionato è che se qualcuno riceve una notifica che è in corso un accesso al proprio account o è stato effettuato l'accesso in un momento in cui non è stato / non vi stava accedendo e non si aspettava che qualcun altro lo facesse , è molto più probabile che emetta un allarme di quanto lo sarebbe se pensassero che qualcuno che avevano autorizzato potrebbe aver avuto accesso all'account.

Dato che il numero di casi in cui potrebbe essere necessario che qualcuno autorizzi qualcun altro a eseguire un'azione particolare per suo conto, sarebbe estremamente utile se i servizi potessero includere un mezzo con cui gli account potrebbero autorizzare e revocare credenziali secondarie con diritti limitati. Ciò consentirebbe al sistema di segnalare quale credenziale è stata utilizzata per accedere a un account, consentendo così a qualcuno di distinguere meglio le attività previste da quelle impreviste.

Ecco alcuni punti elenco per una più facile comprensione e una rapida revisione.

Responsabilità

La responsabilità è un altro principio importante della sicurezza delle informazioni a cui si fa riferimento la possibilità di ricondurre azioni ed eventi indietro nel tempo agli utenti, sistemi o processi che li hanno eseguiti, per stabilire la responsabilità di azioni o omissioni.

Conformità

Se stai seguendo il percorso verso la conformità al GDPR o alla maggior parte delle normative, devi essere in grado di definire una linea a cui ogni account ha accesso.

Legale

In caso di controllo, è necessario essere in grado di individuare gli account che sono stati compromessi o che erano responsabili di un'azione.

Gestisci e proteggi

Per proteggere, gestire e monitorare l'account è più facile avere un accesso individuale separato per eliminare, modificare e rilevare un utilizzo anomalo.

Anche se non stai seguendo alcuna normativa dovresti comunque (consigliato) seguire il "b pratiche est "aiuta il processo di rete globale su larga scala.

Oltre al problema di controllo evidenziato da altre risposte, gli account utente condiviso sono intrinsecamente meno sicuri di un account utente singolo sulla stessa piattaforma .

Se più persone conoscono le credenziali per l'accesso, quell'account è meno sicuro. Ora hai molte più potenziali vittime di attacchi di ingegneria sociale. Ogni persona in più con accesso all'account è un altro vettore di attacco contro la sicurezza di quell'account. Come dice il proverbio, due possono mantenere un segreto se uno è morto.

Vorrei anche mettere in guardia contro l'uso di accessi condivisi da un punto di vista psicologico. Oltre alle preoccupazioni di auditing / colpevolezza, gli accessi condivisi significano anche intrinsecamente condividere sia la gloria che la colpa. Potresti disincentivare la responsabilità personale e l'etica del lavoro. Se si tratta di un profilo condiviso, ogni individuo si sentirà meno responsabile della sicurezza di quell'account. Dopo tutto, anche se fanno tutte le cose giuste (come usare un gestore di password ed evitare email di phishing), cosa succede se il loro collega non lo fa? Perché dovrebbero fare uno sforzo in più quando un'altra persona farà comunque la cosa sbagliata?

Inoltre, sospetto che gli accessi condivisi avranno password più deboli che proteggono l'account. Cercare di condividere una password complessa e gestirla correttamente tra più persone sarebbe scomodo. Probabilmente ti ritroverai con il minimo comune denominatore di debolezza della password ( CompanyName01 ?) O una password scritta fisicamente affinché tutti nell'area possano vederla.

Come affermato da molti, le ragioni principali sono responsabilità, tracciabilità, responsabilità ecc. Ci sono una serie di punti extra da considerare:

• Quanto sono segrete le informazioni a cui si accede? In un caso estremo, molti server FTP pubblici utilizzano (d) un account condiviso "anonimo". E l'account che usi per accedere ai server www pubblici (un account non autenticato) non è fondamentalmente lo stesso? E le password WPA2?
• Quando crei una politica aziendale, è molto più facile imporre "MAI MAI condividere account" che "beh, non dovresti mai condividere un account, ma in alcuni casi, come un leggi solo account per informazioni non così segrete per un periodo limitato tra due persone che lavorano insieme, potresti farlo, se il rischio reale è basso ".
• C'è anche un onere amministrativo sugli account condivisi . Un esempio già dato è la necessità di cambiare le password quando qualcuno se ne va.
• Alcuni account devono essere condivisi. Un esempio è root su Unix / Linux. Sì, imposterai molte restrizioni sull'uso di root in produzione, come sudo con registrazioni estese e monitoraggio della sicurezza, un vault per le password ecc., Ma è comunque è un account condiviso.