Consenti agli utenti amministratori di accedere come altri utenti

11

Pensi che sia una buona pratica implementare una possibilità per consentire a un utente amministratore di accedere come un altro utente, ignorando la password? Questo potrebbe essere implementato da una password principale o da una funzione all'interno dell'amministrazione utenti, "Accedi come questo utente".

Gli amministratori chiedono che tale funzione sia in grado di provare a riprodurre un problema segnalato o di verificare se le sovvenzioni sono ok, ad esempio.

security problem-solving

— Dan McGrath
fonte

9

In generale, non è una buona idea in ingegneria della sicurezza consentire alle persone di accedere come account condiviso (o account di altre persone, del resto) anche se le loro autorizzazioni sono identiche. L'autenticazione dovrebbe essere un processo separato dall'autorizzazione. Se le attività vengono eseguite con account utente separati, ne sono responsabili .

— xmm0

1

+1 a Mehrdad Afshari. Mi arrabbio ogni volta che sento persone che parlano di admin in questo modo.

— Dan McGrath,

2

@Mehrdad Afshari e @Dan McG, tutto ciò è positivo e vero, ma cosa proponi di fare quando un amministratore ha bisogno di accedere a un account utente in una situazione quotidiana? Chiedere all'utente di inserire le proprie credenziali? Accade molto spesso che per verificare o riprodurre un problema, è necessario verificare con le impostazioni di un utente specifico, soprattutto quando gli account sono legati a diritti complessi e altre impostazioni che non possono essere riprodotte 1: 1 con un account neutro.

— Pekka,

4

Lo stai guardando nel modo sbagliato. Se l'amministratore deve verificare l'impostazione degli utenti, dobbiamo sviluppare strumenti migliori per ottenere queste informazioni diagnostiche dall'utente. Ad esempio: se la tua app su Windows si arresta in modo anomalo, vuoi che un po 'di amministratore di MS in Redmond RDPing nel tuo account utente controlli gli articoli o vuoi un metodo altamente automatizzato per inviare loro le informazioni richieste (a discrezione dell'utente) ?

— Dan McGrath,

2

@Dan: il cliente potrebbe non essere disposto a pagare per questo.

15

No. Niente affatto. Ciò viola la segregazione del dovere.

Provoca anche il caos nel fare affidamento sui registri per mostrare le azioni dell'utente.

Se hai davvero bisogno di controllare cose come questa, l'amministratore dovrebbe anche avere un account di test fittizio impostato come gli utenti. In questo modo possono confermare le sovvenzioni, ecc. Prima funzionano correttamente sull'utente di prova.

Inoltre, gli utenti amministratori non dovrebbero sempre avere tutti i diritti di un utente. Ad esempio, un utente potrebbe avere validi motivi per visualizzare i numeri di carta di credito in un sistema. Un amministratore non dovrebbe; questi dati non fanno parte del loro lavoro. Ancora una volta, ciò si riduce alla separazione dei compiti.

Riduci al minimo la tua esposizione minimizzando la concessione di diritti inappropriati. Ciò dovrebbe includere anche gli amministratori ...

— Dan McGrath
fonte

2

Sebbene tu abbia punti validi, non credo che la risposta sia così chiara: in alcuni casi è la soluzione migliore.

— sleske,

11

Dal punto di vista della sicurezza e dei principi di programmazione chiari, non è una buona idea. Ma può essere un'enorme comodità nel lavoro quotidiano per l'amministratore, motivo per cui lo sono se implementato bene.

Per me, un'implementazione ok dovrebbe soddisfare i seguenti requisiti:

Il sistema accede come l'utente in questione, ma ignora l'autenticazione della password se si è effettuato l'accesso come amministratore.
Il sistema è consapevole attraverso un flag che questo non è l'utente x, ma un amministratore ha effettuato l'accesso come utente x. Qualsiasi funzione di registrazione rifletterebbe la differenza.
Non è possibile "interrompere" dal login dell'utente al livello di amministratore.

Questo può effettivamente migliorare la sicurezza perché l'amministratore non deve cercare e utilizzare le credenziali degli utenti, cosa che in realtà spesso accade per i motivi menzionati dall'OP: qualcosa deve essere verificato, testato, ecc ... sull'account dell'utente .

— Pekka
fonte

8

Come sempre ... dipende. Non esiste una risposta semplice ed entrambi i sistemi vengono utilizzati nella pratica (ad es. Windows: L'amministratore non può accedere come utente senza reimpostare la password rispetto a Linux: L'amministratore può accedere come utente locale utilizzando su).

Chiaramente, non consentire all'amministratore di accedere come un altro utente è l'opzione più sicura, quindi devi decidere se il comfort aggiuntivo (essere in grado di eseguire il debug di problemi che si verificano solo per un determinato utente) supera il rischio. Se decidi di implementare tale opzione, assicurati che ci sia una registrazione rigorosa, in modo che un amministratore (o qualcuno che ha ottenuto una password di amministratore) non possa nascondere le sue tracce.

In alternativa, è possibile utilizzare il modello utilizzato da Windows: un amministratore non può accedere come un altro utente, ma un amministratore può reimpostare la password di un utente. In questo modo, un amministratore può accedere, ma l'utente sarà sempre sapere che qualcuno accede suo conto.

— Heinzi
fonte

Nitpick: sudonon effettua l'accesso come utente locale, ma esegue solo un processo come utente ("Esegui come utente" di Window). Per accedere come utente locale, utilizzare su. Altrimenti, sono d'accordo.

— sleske,

@sleske: certo, grazie per averlo individuato. Fisso.

@sleske: non necessariamente, guarda sudo -i.

— liori

L'idea di una "shell di accesso" ha più a che fare con il shcomportamento dell'eseguibile che con le autorizzazioni concesse. su - usere sudo -u user shconcedere lo stesso accesso; la differenza è che shesegue diversi script di avvio.

— jpaugh,

3

Bene, phpBB3 ha una funzionalità "Prova le autorizzazioni dell'utente" per gli amministratori, il che è davvero utile. Inoltre, non ti consente davvero di interferire con quell'account degli utenti, ma di ottenere l'esperienza che hanno, in base alle loro autorizzazioni.

Ma in realtà l'accesso come qualcun altro presenta una serie di problemi, come altri hanno già detto.

— back2dos
fonte

1

Sì, tale funzionalità può essere problematica, ma a volte non c'è altro modo, quindi potrebbe essere necessario.

Qualche esempio:

Su Unix / Linux, questa funzionalità esiste ( su - <username>che fornisce lo stesso risultato dell'accesso dell'utente, ma non richiede password per il root)
anche l'applicazione su cui lavoro ha questo, ed è essenziale per il debug di problemi con le impostazioni personali di un utente (di cui la nostra app ha molte)

Come sottolineato, se impostazioni complesse dipendono dall'utente che ha effettuato l'accesso (variabili di ambiente, percorsi, impostazioni personali in un'applicazione), spesso non esiste un altro modo pratico per eseguire il debug del problema di un utente.

Per quanto riguarda la registrazione / il controllo: l'uso di questa funzionalità dovrebbe ovviamente essere registrato. A parte questo, dovrai fidarti del tuo amministratore per non abusarne. Ma questo è valido per gli amministratori in generale.

Se devi restringere maggiormente i tuoi amministratori, hai bisogno di un sistema MAC (controllo di accesso obbligatorio), con un amministratore "vero". Questo è possibile, ma molto più complicato, quindi è un compromesso.

— sleske
fonte