Esiste un sistema di autenticazione il cui protocollo notifica sempre il "conto di destinazione" della rappresentazione?

Question

Esiste un sistema di autenticazione il cui protocollo notifica sempre il "conto di destinazione" della rappresentazione?

Naviga le tue risposte

#1 da (2 voti)

2

Esistono molte forme di rappresentazione:

Sudo in * nix
Rappresentazione dell'applicazione ( send as in Exchange)
Qualsiasi utente privilegiato (helpdesk) che accede come utente in modo da non rivelare la password
Amministratore RunAs in Windows

Sto cercando un sistema di autenticazione, che a sua volta, definisce una sequenza di passaggi per:

registra tutti i tentativi di impersonificazione validi
Assicura la visualizzazione di tali tentativi al proprietario dell'account
Il proprietario dell'account accetta passivamente o li contrassegna come sospetti.

In un certo senso, questo potrebbe essere codificato come RFC, in modo simile a come viene segnalato lo spam UCE o alla segnalazione DMARC.

Il mio obiettivo è portare questa logica in un sistema di autenticazione proprietario, mantenere il formato di registrazione lo stesso e, se possibile, tracciare e aggiornare la disposizione di ogni tentativo.

Non sto cercando di rielaborare la ruota qui, e penso che qualche lavoro precedente dovrebbe esistere.

authentication logging audit user-tracking privilege-escalation

posta random65537 26.01.2017 - 16:53

fonte

1 risposta

Leggi altre domande sui tag authentication logging audit user-tracking privilege-escalation

Best practice per la gestione di token TOTP errati Se qualcuno trasferisce denaro da un conto bancario a una carta master prepagata, può rintracciare la carta principale

score 2 · Answer 1

Il problema qui è che tutte le forme di rappresentazione sono eseguite per diversi motivi:

sudo viene normalmente utilizzato per consentire a un utente con privilegi limitati di eseguire attività che richiedono normalmente privilegi di livello superiore
È possibile utilizzare la rappresentazione di Exchange per consentire a qualsiasi utente di qualsiasi livello di privilegio di inviare messaggi come un altro utente, ma senza consentire altre funzioni dell'account
La rappresentazione del helpdesk tende a consentire agli utenti con privilegi elevati (personale IT) di assumere il ruolo di utenti con privilegi più bassi (tutti gli altri) per scopi specifici (in questo caso, "privilegio" si riferisce solo all'accesso al sistema, non alla gerarchia aziendale ). Tuttavia, può anche essere utilizzato per consentire il monitoraggio delle attività in cui vi è il sospetto di un comportamento errato da parte di un dipendente, ad esempio.
RunAs è essenzialmente uguale a sudo in questo contesto

Di conseguenza, hanno tutti requisiti diversi per la registrazione e la notifica:

sudo: dovrebbe registrare l'account utente effettivo e le attività eseguite
Exchange: probabilmente è necessario registrare l'utente originale, ma le attività vengono registrate come parte del normale utilizzo e poiché l'autorizzazione è normalmente concessa all'utente legittimo, potrebbe implicare "questa azione è stata eseguita dal titolare dell'account principale" stato, anche se un utente impersonante lo ha effettivamente eseguito. Considera un segretario che invia una lettera per conto di un manager: il manager viene solitamente considerato il "mittente", anche se non ha premuto "Invia".
Helpdesk: la rappresentazione deve essere registrata, ma può essere difficile / impossibile registrare le attività specifiche eseguite. Ad esempio, potrebbero semplicemente mostrare a un utente come trovare una finestra di dialogo all'interno di un sistema complesso, in cui l'unico metodo di registrazione dovrebbe essere annotato dove i clic del mouse erano e potenzialmente prendere screenshot in quei momenti. Se il dipendente viene indagato, notificarlo può compromettere l'indagine.

A causa di questo problema, non è davvero un argomento che si presta alla standardizzazione in un RFC - ci sarebbero così tante esclusioni ed eccezioni che sarebbe quasi inutile, e praticamente impossibile costruire un sistema interoperabile.

I passaggi che hai delineato non avrebbero funzionato per alcuni degli esempi che hai:

sudo - chi vorresti notificare? L'account di root? Come fa chiunque ad accedervi? Attraverso sudo, in molti sistemi moderni!
Exchange: un uso comune è che le persone siano in grado di rispondere alle e-mail mentre il destinatario dell'email è in congedo. Se dovevano ottenere l'approvazione per ogni tentativo, quel caso d'uso cade. Andrebbe bene per altri casi d'uso, come avere una persona a preparare e-mail per conto di un'altra.
Helpdesk - un caso d'uso comune è quello di ordinare i problemi con l'accesso agli account. Se un utente non può accedere, non può accettare la rappresentazione come valida finché il problema non è