Quando è accettabile una password di gruppo per una cerchia chiusa di utenti?

2

Sto sviluppando uno strumento per un'azienda, che richiede alcuni dati tecnici e crea report PDF.

Nello strumento ci sono diversi campi di testo, che vengono riempiti dal database. Se l'utente lo desidera, può modificare il contenuto dei campi di testo. Alla fine, preme un pulsante e alcuni rapporti vengono creati, archiviati e inviati al cliente.

Il mio capo ha fatto la proposta di utilizzare solo una password di gruppo per tutti, quindi ogni utente dello strumento conosce la password e deve semplicemente inserire il proprio nome utente.

Mi sono astenuto da ciò e gli ho detto che sarebbe stato conveniente, ma non sicuro principalmente per il furto di identità: qualcuno può semplicemente inserire un altro nome utente e inserire i campi di testo con una sciocchezza, che viene inviata al cliente, stampare un segnala 300 volte, crea il rapporto 500 volte, ecc.

Ne abbiamo discusso un po 'più a fondo e, dopo essersi reso conto che un utente malintenzionato potrebbe effettivamente arrecare qualche danno, almeno alla reputazione, abbiamo cercato di trovare uno scenario, dove tale password di gruppo sarebbe accettabile.

Questo mi ha incuriosito: ci sono ambienti o situazioni in cui una tale password di gruppo sarebbe accettabile? Oppure verrà sempre abbattuto con il "furto d'identità" -argomento?

    
posta hamena314 10.03.2016 - 11:39
fonte

2 risposte

1

This got me curious: are there environments or situations, where such a group password would be acceptable? Or will it always get shot down with the "identity theft"-argument?

Sì, vorrei sempre abbatterlo con l'argomento della rappresentazione.

Il secondo argomento contro di esso è: cosa succede se l'accesso deve essere revocato per un utente? Dovresti cambiare la password per tutti, il che è inopportuno.

Quindi quando è accettabile avere una password di gruppo? Direi quando:

    Le azioni
  • non devono essere collegate a un utente specifico. Idealmente, ciò significa che non ci sono utenti (in alternativa, si può provare a collegare gli utenti alle azioni in modi diversi, ad esempio indirizzi IP, ecc., Ma ciò sarà più difficile). Altrimenti, si avranno problemi quando succede qualcosa di brutto, dato che la colpa può essere facilmente spostata. Potresti avere persone che accusano gli altri di impersonarle, ecc.
  • e non è necessario revocare l'accesso per ogni utente o si dispone di diversi mezzi per farlo (accessibile solo dalla rete interna, ecc.).
  • e ovviamente tutti gli utenti dovrebbero avere gli stessi identici diritti. In caso contrario, un utente può semplicemente ottenere diritti che non dovrebbero avere utilizzando un nome utente diverso.

E anche allora, potresti ancora avere problemi. Ad esempio, le persone potrebbero non sentirsi responsabili di una password di gruppo come per una password per utente e potrebbero quindi rivelarla più facilmente, semplificando gli attacchi di social engineering.

Quindi penso che ci siano pochissime situazioni in cui questo ha senso, e anche allora, ci sono aspetti negativi e pochissimi aspetti positivi (le password per utente non sono molto più difficili da implementare o gestire, specialmente quando si ha un utente separato account comunque).

    
risposta data 10.03.2016 - 12:32
fonte
2

Non è accettabile se vuoi essere conforme a normative come Sarbanes-Oxley (SOX), che - tra le altre cose - impone che i singoli utenti debbano essere facilmente verificabili.

È abbastanza giusto (su un livello UNIX o Linux) avere un account di gruppo per un'applicazione che può essere assunto da un singolo utente, una volta che hanno effettuato il login (cioè usando sudo su sharedaccount), ma non dovrebbe essere possibile accedere direttamente con quell'account. In questo modo, è ancora possibile vedere (tramite i log di sistema) chi ha effettuato l'accesso, a che ora e chi ha assunto i privilegi forniti da tale account utente condiviso.

    
risposta data 10.03.2016 - 11:45
fonte

Leggi altre domande sui tag