Può essere giustificato utilizzare account utente generici e condivisi al fine di separare e ridurre i rischi?

Hai ragione, dare solo le autorizzazioni a ciascun utente che ne ha bisogno solo occasionalmente non è una buona opzione. Anche la condivisione di account privilegiati non è un'opzione.

Dato che non hai specificato il tuo ambiente, fornirò due risposte:

Linux / * nix

È possibile assegnare a ciascun amministratore la possibilità di inoltrarsi a un livello di privilegio più elevato sul proprio account operativo. Tipicamente, su Linux, lo fai usando sudo per eseguire comandi privilegiati. Tu dai tale autorizzazione a un utente aggiungendolo al gruppo / file sudoers (Es: link ).

L'impostazionepredefinitasullamaggiorpartedeisistemiLinuxèchiederenuovamentelapassworddell'utenteperconsentirglidieseguirecomandiamministrativiusandosudo.Tuttavia,potrestichiedereunapasswordperl'accountdiroot(nonl'opzionemiglioredalmomentocheèunapasswordcondivisa,mapotrebbeessereOKsealmenononautorizziillogindirootdiretto,assicurandotichesipossausaresolosehaancheunaccountoperativoconsudoprivilegiato).

Masevuoiunaprotezioneancoramigliorepuoichiedereunapassworddiversaperutente,comedescrittoin link .

Pertanto, utilizzando sudo ogni utente dovrà conoscere la propria password per accedere (come operatore) e anche confermare la password per passare a una modalità amministrativa quando necessario. Se si desidera aggiungere una protezione aggiuntiva, è anche possibile chiedere una seconda password per passare ai privilegi amministrativi (root o seconda password per utente). Ma ogni utente avrà il suo (e solo uno) utente e avrà una buona tracciabilità.

di Windows

È necessario assegnare a ciascun amministratore un account amministrativo e impostare l'UAC affinché richieda all'utente di immettere nuovamente la password durante l'esecuzione delle operazioni amministrative. Questo sarebbe l'equivalente di Linux con sudo. Tuttavia, non è possibile impostare una password diversa da richiedere, quindi l'utilizzo di due account per ciascun amministratore sembra l'unica opzione se si vuole veramente isolare gli account operativi e amministrativi. Dai un'occhiata a questa guida di Microsoft, dove raccomandano esattamente questo: link

Separating Administrative and User Accounts for Administrative Users For each user who fills a service administrator role, create two accounts: one regular user account to be used for normal tasks and data administration, and one service administrative account to be used only for performing service administration tasks. The service administration account should not be mail enabled or used for running applications that are used every day, such as Microsoft Office, or for browsing the Internet. Always give the two accounts different passwords. These precautions reduce the exposure of the accounts to the outside world, and they reduce the amount of time that administrative accounts are logged on to the system.

Potresti creare un login che crea una sessione con un determinato utente, che poi ottiene una sorta di cookie di tracciamento o cosa, ad esempio. Con questo, è ancora possibile rintracciare l'utente e le sue azioni.

Di solito lo fai usando un framework come Play! o primavera. Esempi per il gioco! può essere trovato qui e qui . Il processo è simile su diversi framework: l'utente accede, viene convalidato, ottiene una sorta di ID tracciabile. È quindi possibile creare un file di registro che tenga traccia delle azioni degli utenti o semplicemente verificarlo tramite l'ID, se un utente è autorizzato a svolgere un'attività specifica.

Una parola sui diversi ruoli:

I ruoli ci sono per un motivo. Mantenere i ruoli separati e solo per il loro dovere specifico aiuta a ridurre i problemi di tracciabilità e sicurezza. Un utente dovrebbe avere i diritti per un determinato lavoro. Questo è anche noto come POLP - Principio di privilegio minimo .

Se tutti i tuoi utenti hanno privilegi di amministratore E di operatore, il monitoraggio delle azioni degli utenti e la sicurezza diventano difficili da raggiungere.

Un semplice esempio potrebbe essere un collaboratore malevolo, semplicemente elimina o modifica i dati importanti e poi cancella tutti i file di registro che potrebbero rivelare la sua identità. Dal momento che ha tutti i diritti di cui ha bisogno, questo è molto facile da fare. Avere utenti "normali" e "amministratori" creerebbe una barriera, se l'utente non è un amministratore, potrebbe mancare i diritti per eliminare i file di registro, quindi potrebbe ancora essere in grado di eliminare i dati, ma ora l'amministratore puoi rintracciarlo.

Forse l'implementazione di più ruoli / gruppi che contengono SOLO i diritti di cui hanno bisogno per svolgere un determinato lavoro sarebbe altrettanto utile?

In questo caso, dipende da cosa vuoi ottenere.

L'idea alla base della segreazione, ad esempio non in esecuzione come root, ma come utente limitato per le attività quotidiane, è che se l'account viene compromesso per qualche motivo, il danno è contenuto nei diritti che ha l'account utente limitato. La segreazione NON protegge dagli utenti malintenzionati, allo stesso modo sudo non protegge da amministratori malintenzionati! Se un utente malintenzionato con troppi diritti desidera fare qualcosa di malevolo, quell'utente deve semplicemente passare all'account richiesto per le sue attività.

Quale segreazione è progettata per proteggere contro, è: Un esempio è se l'utente lascia accidentalmente un terminale connesso e un utente non autorizzato prende il controllo del terminale, o se sul terminale è installato un software o un virus malevolo a causa di una navigazione Web incurante, il virus o l'utente non autorizzato può eseguire qualsiasi l'account utente limitato può fare.

In base a ciò che hai descritto, interpreto l'operatore è solo più di "utente globale", ad esempio, il normale "utente" può accedere solo al proprio terminale, ma "operatore" può accedere a qualsiasi terminale come "utente".

In tal caso, consiglierei di assegnare l'operatore direttamente all'utente e quindi utilizzare una sorta di escalation dei privilegi nel caso in cui sia richiesto un account amministratore, ad esempio "sudo" o qualcosa di simile a questo.

Se vuoi avere sia la tracciabilità che la segreazione, ti consiglio di creare 2 account utente per ciascun utente. Uno con i normali diritti e uno con i diritti aumentati. Non vedo alcun rischio nel combinare account operatore e amministratore in un unico account, per quegli utenti che hanno sia l'accesso di operatore che di amministratore, in quanto questi account dovrebbero essere utilizzati solo per le attività di manutenzione in ogni caso, non per l'uso quotidiano.

In realtà, in questi casi, potrebbe anche essere preferibile lasciare che gli account operatore / amministratore siano account individuali e avere un account utente di gruppo / condiviso, come "Utente". Poiché gli account utente non hanno diritti speciali, non importa se qualcuno lo compromette.

Penso che ci siano più opzioni per scopi diversi:

1. Vuoi evitare che i tuoi utenti utilizzino la stessa password per il lavoro quotidiano e per le attività amministrative (per limitare le minacce alla sicurezza se la password comunemente usata viene rubata)?
2. Vuoi limitare i "power user" su alcuni sistemi mentre li attivi su altri?
3. Vuoi monitorare (verificare) gli utenti meglio?

In generale, penso che avere tutte le operazioni eseguite da un utente monitorato e gestito su un account unico abbia molti vantaggi, sia per semplificare (meno complessità significa di solito meno difetti), per avere una gestione coerente e per tracciare e attività.

Cioè, per il punto 3 rimuoverò definitivamente gli utenti condivisi.

Per i punti 1 e 2, avere più account per ogni utente è un'opzione, ma non è ottimale per il punto 3 e per la gestione e la semplificazione menzionate sopra.

In ogni caso, come detto da CristianTM, su Microsoft è la best practice: link
Su Linux potresti voler avere una password diversa, quella di root, da richiedere per attività privilegiate (e potresti avere la password di root centralizzata), ma non sarà di aiuto per il punto 2 da sola (potresti definire cosa sistemi che un utente può sudo e cosa no).

Tuttavia, il miglior design che posso pensare si basa sui concetti di host bastion e proxy di autenticazione; in fondo, l'idea sarebbe quella di creare diversi bastioni per accedere a diversi servizi privilegiati. I bastoni sono spesso autenticati con password indipendenti tramite OTP (molto più sicuro di password) e i servizi dietro di essi possono anche essere separati da una rete prospettica .
Concedendo l'accesso per alcuni utenti a un bastione / proxy (probabilmente 2 host almeno per ridondanza) configurati per accedere a un servizio specifico che autentica gli utenti tramite OTP, è possibile ottenere tutti i 3 punti sopra notevolmente (con una registrazione / auditing dedicata in questi server). Anche su Windows, è possibile definire che l'autenticazione per gli utenti su host bastion tramite RDP sia eseguita con OTP e non con la solita password.

Elimina gli account utente condivisi al più presto.

L'unica volta che è necessario un account utente condiviso, è quando più persone hanno bisogno di accedere a un sistema arcaico che supporta solo uno (o forse solo pochi) utenti.

Gli unici ruoli che vale la pena di sviluppare sono probabilmente i ruoli utente e di amministrazione (e forse diversi ruoli di amministrazione).

È probabile che il ruolo utente sia strongmente limitato, utile per accedere alle workstation, svolgere mansioni lavorative e cosa no. Devi scoprire qual è il minimo indispensabile per la popolazione di utenti generici e creare tale ruolo.

Il ruolo dell'operatore, non è sicuro di cosa viene usato esattamente, viene utilizzato per accedere a più sistemi per eseguire diverse "operazioni" diverse a seconda della descrizione. Tutti gli operatori si connettono a tutti questi sistemi? Alcuni di loro si collegano solo a pochi mentre altri si collegano a pochi altri e alcuni si collegano a tutti? Se c'è una differenza in chi si collega a cosa, abolire il ruolo e autorizzare gli utenti caso per caso (principio del privilegio minimo) per impedire agli utenti di ottenere accessi non autorizzati o non autorizzati a sistemi e risorse. Ciò migliorerà la tua sicurezza.

L'account Administrator deve essere suddiviso in alcuni gruppi / ruoli specifici per i sistemi (o gruppi di sistemi) che devono essere amministrati. Dovrebbero anche concentrarsi principalmente sugli obblighi amministrativi. Se ci si trova in un ambiente Windows AD, la disattivazione dell'accesso remoto imporrà agli utenti di utilizzare i propri account utente regolari per connettersi a sistemi remoti (con autorizzazioni generate dalle informazioni dell'account "operatore") e quindi utilizzare il proprio account amministratore (jsmith_a per esempio) per Elevazione UAC. I gruppi amministrativi devono essere concessi solo a questo account _a e solo i gruppi / ruoli per i sistemi che l'utente è autorizzato a amministrare. Ciò ha un duplice effetto di impedire che un account amministratore compromesso venga utilizzato per il controllo remoto su più sistemi e impedisce inoltre a un singolo account utente compromesso di apportare modifiche amministrative.

Questo creerà indubbiamente una "pista" per i tuoi "operatori e amministratori" e aumenterà il livello di responsabilità nel tuo ambiente. Considerare anche la scadenza della password dell'account amministratore (_a) più frequentemente di quanto la password dell'account utente sia scaduta. Una lunga cronologia delle password e un'età minima delle password di 1-3 giorni dovrebbero essere sufficienti per impedire che anche i rotatori di password più dedicati eseguano il ciclo delle loro password;) (non che ciò non compaia comunque nei registri ...)

hat è un buon punto di partenza.