Pensi che sia una buona pratica implementare una possibilità per consentire a un utente amministratore di accedere come un altro utente, bypassando la password? Ciò potrebbe essere implementato da una password principale o una funzione all'interno dell'amministrazione utente, "Accedi come questo utente".
Gli amministratori stanno chiedendo una funzione di questo tipo per poter provare a riprodurre un problema segnalato o per controllare se le sovvenzioni sono ok, per esempio.
No. Affatto. Ciò viola la segregazione del dovere.
Causa anche il caos di affidarsi ai log per mostrare le azioni degli utenti.
Se hai davvero bisogno di controllare cose come questa, l'amministratore dovrebbe anche avere un account di prova fittizio che sono impostati come gli utenti. In questo modo possono confermare le concessioni, ecc. Il lavoro è corretto prima sull'utente del test.
Inoltre, gli utenti amministratori non dovrebbero sempre avere tutti i diritti che un utente ha. Ad esempio, un utente potrebbe avere validi motivi per visualizzare i numeri delle carte di credito in un sistema. Un amministratore non dovrebbe; questi dati non fanno parte del loro lavoro. Ancora una volta, questo si riduce alla segregazione del dovere.
Riduci al minimo la tua esposizione riducendo al minimo la concessione di diritti inappropriati. Questo dovrebbe includere anche amministratori ...
Da un punto di vista dei principi di sicurezza e di programmazione pulita, non è una buona idea. Ma può essere una enorme convenienza nel lavoro di tutti i giorni per l'amministratore, ed è per questo che sono d'accordo se implementato bene.
Per me, un o.k. l'implementazione dovrebbe soddisfare i seguenti requisiti:
Il sistema ti accede come utente in questione, ma ignora l'autenticazione della password se hai effettuato l'accesso come amministratore.
Il sistema è consapevole tramite un flag che questo non è un utente x, ma un amministratore ha effettuato l'accesso come utente x. Qualsiasi struttura di registrazione rifletterebbe la differenza.
Non c'è modo di "uscire" 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, che in realtà è spesso il caso per i motivi indicati dall'OP: Qualcosa deve essere controllato, testato, ecc. sull'account dell'utente.
Come sempre ... dipende. Non esiste una risposta facile ed entrambi i sistemi vengono utilizzati nella pratica (ad esempio 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 che consente all'amministratore di accedere come un altro utente è l'opzione più sicura, quindi devi decidere se il conforto aggiuntivo (essere in grado di eseguire il debug dei 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ò ottenere l'accesso, ma l'utente sarà sempre sapere che qualcuno ha effettuato l'accesso al suo account.
Bene, phpBB3 ha una "verifica delle autorizzazioni dell'utente" - funzionalità per gli amministratori, che è davvero utile. Inoltre, in realtà non ti lascia interferire con l'account di quell'utente, ma ottieni solo l'esperienza che hanno, in base alle loro autorizzazioni.
Ma in realtà l'accesso come qualcun altro ha una serie di problemi, come altri hanno menzionato.
Sì, questa funzionalità può essere problematica, ma a volte non c'è altro modo, quindi potrebbe essere necessario.
Alcuni esempi:
su - <username> , che dà lo stesso risultato dell'accesso come utente, ma non richiede alcuna password per root) Come sottolineato, se le impostazioni complesse dipendono dall'utente loggato (vars 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 / auditing: l'uso di questa funzionalità dovrebbe ovviamente essere registrato. Oltre a questo, dovrai fidarti del tuo amministratore per non abusarne. Ma questo è valido per gli amministratori in generale.
Se è necessario limitare ulteriormente gli amministratori, è necessario un qualche tipo di sistema MAC (controllo accesso obbligatorio), senza un amministratore "vero". Questo è possibile, ma molto più complicato, quindi è un compromesso.
Leggi altre domande sui tag security problem-solving