Domanda:
Perché le aziende non concedono l'accesso root ai dipendenti sui loro computer desktop?
Bananach
2018-10-25 14:08:17 UTC
view on stackexchange narkive permalink

Perché le aziende in genere non concedono ai propri dipendenti l'accesso root alle loro macchine desktop che vengono utilizzate solo da un singolo dipendente?

Se ciò che posso fare sulla mia macchina rappresenta una minaccia per il resto della rete , non è di per sé un difetto di sicurezza? Perché i diritti che ho sulla mia macchina influenzano ciò che posso fare agli altri sulla rete?

Non è il punto della gestione degli utenti Unix proteggere i file dell'utente A sulla macchina X dall'accesso dell'utente B sulla macchina X?

Se si tratta di proteggere l'utente da se stesso (ad esempio, dall'installazione di qualcosa con accesso root che cancellerà il disco rigido): dato che lavoro senza accesso root, tutti i miei file sono di mia proprietà; quindi, se vengo ingannato ed eseguo uno script malvagio senza accesso root e cancella solo tutti i file di mia proprietà, è altrettanto dannoso come se gli avessi dato accesso root e avesse cancellato l'intero disco rigido.

Cosa intendi per accesso root?Intendi non fornire la password di root per poter sudo, o intendi non consentire agli utenti di accedere a root?
Cosa ti fa dire che è tipico?Ho avuto accesso come root sulla mia macchina locale in ogni lavoro che ho avuto.
Sarebbe molto più facile rispondere a questa domanda se avessi un caso d'uso per il motivo per cui pensi che dovresti averlo.
Stai chiedendo informazioni sui sistemi * NIX in particolare o su tutti i PC di lavoro (ad esempio, diritti di amministratore su una macchina Windows)?
Non credo che non possano proteggere la rete dalla tua macchina.Ma quello che alla fine vogliono è proteggere ** i file aziendali ** sulla tua macchina da cose malvagie (che potrebbero includere te).
Dipende dal tuo ruolo e dalle possibili esigenze.Come sviluppatore ho sempre avuto accesso come root poiché ne avrei avuto bisogno più volte al giorno
@Bergi Perché memorizzano file importanti su un WS di un impiegato umile?Se il dipendente ne ha bisogno per il proprio lavoro, * anche * ha bisogno di accedervi, se no perché sono anche lì?Avere o meno l'accesso come root dovrebbe essere completamente irrilevante.Per quanto ne so, non dare accesso root probabilmente evita ad alcune persone di "rompere" i loro sistemi quando cercano di installare / aggiornare qualcosa, a costo di dover affrontare ogni tipo di installazione / aggiornamento.Per una macchina per sviluppatori che dovrebbe contenere solo codice, compilatori, cuda, ecc. Non vedo il vantaggio di non dare il root.
Sono uno sviluppatore di software e ho accesso root alla mia macchina e ad alcuni server per i quali ho un motivo particolare, ma non ad altre macchine.Anche se qui non c'è una forte attenzione alla sicurezza.
Che ruolo ha il dipendente?Stai chiedendo perché a * tutti * i dipendenti non viene concesso l'accesso come root?
Ho visto entrambi, le organizzazioni più grandi tendono a non consentire il root senza ottenere prima il permesso, mentre la maggior parte delle organizzazioni medio-piccole non si preoccupa abbastanza di limitarlo.
Questo è molto insolito.
Otto risposte:
#1
+56
schroeder
2018-10-25 14:33:09 UTC
view on stackexchange narkive permalink

Gli amministratori della sicurezza sono responsabili della tua macchina e di ciò che accade sulla tua macchina. Questa responsabilità viola il modello di sicurezza di base per una macchina Unix a utente singolo perché l'amministratore (una parte assente) è root sul tuo macchina, non lo sei. Unix non è realmente impostato per questo modello.

Gli amministratori devono essere in grado di installare controlli di sicurezza sulla tua macchina per proteggere l'azienda, non solo i dati, la rete e gli altri nodi. Se l'utente locale disponeva dell'accesso root, gli amministratori non hanno più il controllo su tali controlli. Questa è la premessa di base.

Sì, ci sono tantissime ragioni per cui root è necessario per fare cose cattive o per trasformare la macchina in un nodo dannoso e tutte queste sono buone ragioni per non fornire l'accesso come root. E sì, ci sono molti modi per aggirare queste limitazioni e molti modi in cui l'utente locale potrebbe fare cose cattive. Ma alla fine, l'utente locale e il proprietario del rischio non possono competere per il controllo o la responsabilità sulla macchina.

Il primo paragrafo mi confonde.I sistemi operativi Unix sono multiutente, non singolo utente, ed è proprio per questo che sono impostati per questo modello.Il fatto che oggi la maggior parte delle macchine sia destinata a un singolo utente, si traduce solo nel non avere più utenti normali, ciascuno con la propria directory home, in una singola macchina.Questa è l'unica differenza, giusto?Il modello di sicurezza di base è rimasto multiutente, con root sempre presente per un possibile amministratore separato.
La macchina in questione * ha * un solo utente (l'OP).Ovviamente Unix è multiutente, e questo è il modello che viene violato, perché su una macchina per utente singolo, quell'utente necessita di alcuni diritti di amministratore.
@schroeder solo perché nessun altro si siede alla scrivania e digita non significa che non ci siano altri utenti della macchina.Se si tratta di un ambiente di lavoro, la macchina deve essere gestita da un amministratore, quindi NON è una macchina monoutente.
@schroeder Ho votato favorevolmente la tua risposta, non siamo in disaccordo.Penso solo che sarebbe bene far notare all'utente che solo perché non vede un'altra persona che usa il computer non significa che non ci sia un altro utente.
Aggiungo che alcuni reparti IT danno accesso sudo o root ad * alcuni * dei loro utenti.Il criterio principale per questo sembra essere che si fidino degli utenti che (a) hanno un effettivo bisogno della struttura (b) ci si può fidare di non abusare della struttura, (c) sono onesti su ciò che hanno fatto se commettono errorie (d) conoscere i propri limiti e non tentare di fare cose che non capiscono.La combinazione di questi criteri esclude molte persone.Ovviamente, questo tipo di fiducia non può essere assegnato dalla direzione o dalle risorse umane, ma solo dall'IT a persone che conoscono.
#2
+25
me_and
2018-10-25 14:23:34 UTC
view on stackexchange narkive permalink

Alcuni motivi che mi vengono in mente:

  • L'avvelenamento da ARP o gli attacchi di inondazione di rete sulla rete richiedono generalmente l'accesso root a una macchina sulla rete.

  • Essere in grado di installare programmi non autorizzati potrebbe esporre l'azienda a responsabilità legali se tali programmi sono essi stessi illegali (ad esempio perché sono piratati o non concessi in licenza per uso a scopo di lucro o altro).

  • Se l'azienda ha un qualsiasi tipo di monitoraggio remoto dei dipendenti (o vuole la possibilità di avere tale monitoraggio anche se non è ancora in atto), dare agli utenti l'accesso root consentirebbe loro per aggirarlo.

  • Non avere accesso come root significa che non puoi rm -rf / bin , o qualsiasi altra cosa distruttiva, e né può chiunque abbia accesso ai tuoi dati di accesso, quindi non c'è alcuna possibilità che la tua azienda abbia bisogno di aiutarti a riprenderti da quella situazione.

  • Se la tua azienda potrebbe ridistribuire la tua macchina se te ne vai , potrebbero sentirsi più a loro agio nel farlo con fare una completa cancellazione e reinstallazione se non hai mai avuto accesso come root.

  • Dare alle persone l'accesso come root è facile, se necessario; rimuovere l'accesso root in modo completo è difficile se diventa necessario.

  • Il principio generale del privilegio minimo è che non dovresti concedere a nessuno / a nulla l'accesso non hanno bisogno attivamente.

  • Semplicemente non essere passati dai giorni dei server condivisi perché è un processo che ha funzionato e niente ha rotto l'inerzia (l'ipotetico problema di scimmie e scale).

Il secondo punto non è molto forte perché è sicuramente possibile violare le leggi sulla licenza con il software che esegui dalla tua home directory.
Di solito è prassi normale che un computer venga cancellato e ricreato quando viene ridistribuito a un altro membro del personale.Lasciare tutte le cose di un precedente membro dello staff nella loro home directory sembra che potrebbe essere più una responsabilità. Penso a questi punti, il principio del privilegio minimo è la ragione più convincente per farlo, ma quel principio giustifica anche il dare loro accesso root non appena ne hanno una legittima necessità.
@BenMillwood: non è possibile se l'amministratore configura un criterio di restrizione software
Il tuo primo punto è un po 'fuori base.È banalmente facile rovinare una LAN dallo spazio utente, non hai nemmeno bisogno di intenti, per non parlare di privilegi elevati.Diavolo, non hai nemmeno bisogno di un computer, puoi entrare nella maggior parte degli edifici per uffici con 15 piedi o meno di cat5 e rovinare la giornata di qualcuno collegando le due porte sbagliate.Esiste una categoria di attacchi dannosi diretti che l'accesso root può consentire, ma consente pochissimi errori idioti maldestri che non vengono replicati banalmente dallo spazio utente per tutto il tempo.
@paj28 I sistemi in stile Unix * hanno * anche una "politica di restrizione del software", e sarebbe di qualche utilità su un sistema del genere?(ad esempio, i sistemi in cui è possibile "eseguire script" e in cui l'amministratore è denominato "root", come richiesto dalla domanda)
Sì, per essere chiari non sto cercando di affermare che questi sono tutti * buoni * argomenti per la cosa semplicemente che sono argomenti che potrebbero essere usati per giustificare la politica.
@EthanKaminski - Sì, hanno cose simili, sia prodotti commerciali che scripting su misura.Con una configurazione stretta non è possibile eseguire i propri script.È qualcosa di rilevante per te o stai solo chiedendo di essere contrarian?
#3
+12
Jared Smith
2018-10-25 23:09:54 UTC
view on stackexchange narkive permalink

Questa risposta non intende contraddire le risposte esistenti, ma piuttosto integrarle perché è troppo lungo per un commento.

Parte del motivo è (come altri hanno accennato) che gli utenti non possono fidarsi di non fare cose sciocche / dannose. Ma un'altra parte è di chi è la responsabilità di sistemare le cose quando ciò accade?

Sono uno sviluppatore full-stack e devops part-time con accesso root non solo alle mie macchine di sviluppo ma a una parte della nostra produzione server e almeno un certo livello di accesso all'hypervisor su cui sono distribuiti. Ma se sbaglio, sono il partito (o almeno un partito) con le capacità, le competenze e la responsabilità per rimediare. Non così del tipico utente finale: se Bobby l'utente borks la sua installazione di Windows che ha avuto dati mission-critical e / o è stata utilizzata per un lavoro mission critical, allora Bobby non è quello che deve entrare sul suo / il suo giorno libero o lavoro straordinario non pagato per aggiustarlo. Per non parlare della risposta all'ottone come Bobby è riuscito ad affondare la nave quasi da solo.

Quindi parte del motivo per cui i reparti IT limitano i privilegi degli utenti finali è che riduce i propri esposizione al rischio.

Come poteva Bobby avere dati mission critical non recuperabili sulla sua macchina?Come potrei essere più di una mezz'ora per ripristinare la sua macchina?Entrambi mi sembrano difetti nel design.Inoltre, come affermato nella mia domanda, non dargli l'accesso come root non gli impedisce di cancellare i dati su cui lavora effettivamente
@Bananach Non ho mai detto irrecuperabile e non ho mai detto che il reimaging era * difficile *, ma di chi è il compito di recuperare i dati e ridistribuire la macchina?Non Bobby's ...
#4
+4
Serge Ballesta
2018-10-26 11:38:52 UTC
view on stackexchange narkive permalink

AFAIK, ci sono 4 ragioni principali per non concedere l'accesso come amministratore agli utenti standard sui loro desktop:

  • proteggere la macchina stessa (non sempre molto efficiente) e le altre macchine sulla rete da possibili attacchi che utilizzano quella macchina come un relay (già coperto da altre risposte)
  • proteggere il team di supporto IT da attacchi a livello di amministratore che richiederanno molto lavoro per essere risolto (già coperto da altre risposte)
  • mantieni tutte le macchine con (più o meno) la stessa configurazione per essere in grado di eseguire semplicemente distribuzioni remote da una singola macchina di amministrazione: più piccola è la dimensione del team di supporto, meno costoso per il azienda
  • impedire (o almeno provare a) agli utenti di installare programmi estranei al proprio lavoro: un utente che gioca ai videogiochi al lavoro o che progetta la sua futura cucina non è molto produttivo ...

Ma non può proteggere i dati sulla macchina né più in generale i dati accessibili all'utente, essere sulla macchina locale o su un server. È qui che i backup vengono in soccorso.

Sottolineerei l'aspetto della manutenzione.Se l'IT sa cosa c'è su ogni macchina, avrà molto più tempo a capire cosa c'è che non va o con gli aggiornamenti.Ho conosciuto reparti IT che hanno detto "puoi avere root ma poi non hai supporto".(Ho messo radici ;-).)
#5
+2
Bob
2018-10-27 02:53:06 UTC
view on stackexchange narkive permalink

La tua macchina non è utilizzata solo da te. Viene utilizzato anche dal tuo team di supporto desktop.

Se ho accesso root a una casella, in particolare una casella Windows associata a un dominio, posso installare un numero qualsiasi di trucchi diversi che potrei usare per compromettere qualsiasi altro utente la scatola. Supponiamo, ad esempio, un keylogger.

Quindi tutto ciò che devo fare è convincere un tecnico dell'assistenza ad accedere per risolvere un "problema" appena creato (come rompere il segreto condiviso di Kerberos), aspettarlo per passare ad amministratore di dominio e ho appena compromesso l'intera rete.

Il keylogger non verrà rilevato dallo scanner di malware? No, se ho il root non lo farà.

Ottieni ciò di cui hai bisogno per fare il tuo lavoro. Se il tuo lavoro richiede l'accesso come root, lo ottieni, insieme al discorso di potere / responsabilità associato. Il mio lavoro è proteggere tutti gli altri da te.

Se vuoi veramente eseguire il root sulla tua workstation personale, considera il BYOD, ma se lo rompi, lo aggiusti.

Sebbene ciò rifletta le pratiche di lavoro in molte reti, manca di diversi vettori di attacco.Quando il modello di minaccia include utenti malintenzionati, * non * immetterei mai le credenziali di root su una macchina dell'utente finale, solo le macchine archiviate in ambienti controllati (ad es. Sale macchine bloccate).Se l'utente finale ha accesso fisico alla macchina, può aggirare le protezioni di autorizzazione a livello di sistema operativo, i vettori di attacco hardware sono banali da distribuire e l'hash della password di root che colpisce le cache locali è problematico.L'eccezione è una password di root specifica della macchina non condivisa da nessun'altra macchina.
#6
+1
user189852
2018-10-26 14:25:05 UTC
view on stackexchange narkive permalink

L'azienda deve proteggere le cose. Devono proteggere il loro segreto commerciale, ma devono anche proteggere cose come i dati degli utenti. Se ogni dipendente ha un'altra configurazione potenzialmente insicura sul proprio desktop, l'azienda non ha alcuna possibilità di assicurarsi che non si verifichi alcun furto di dati e nessuna perdita di dati. Una gestione centralizzata da parte di professionisti aiuta a mantenere i computer protetti ed evitare la perdita accidentale di dati.

#7
  0
rackandboneman
2018-10-26 13:44:24 UTC
view on stackexchange narkive permalink

Nel caso di un box unix connesso a qualsiasi tipo di file server NFS della vecchia scuola (v2 o v3), l'accesso root locale consente effettivamente a un utente di interferire con i file di altri utenti, poiché l'autorizzazione è parzialmente implementata lato client con questi protocolli, mentre l'autenticazione è sotto il controllo dell'utente locale in questo modo. Significa che qualcuno può semplicemente fare su un account utente esistente o creato con lo stesso uid e avere accesso ai file appartenenti a quell'uid su NFS.

Inoltre, è "usato solo da un singolo dipendente" il definitivo o il solito modo di lavorare lì? Se le macchine fanno parte di un dominio di autenticazione comune, occasionalmente scambiate tra gli utenti secondo necessità, o l'accesso alle macchine dei colleghi (ma non i loro dati!) È occasionalmente consentito, questo sembra un puro scenario per utente singolo ma in realtà utilizza funzionalità multiutente per la gestione delle apparecchiature scopi.

#8
  0
user208145
2018-10-28 04:49:27 UTC
view on stackexchange narkive permalink

Da una licenza software POV, non voglio che gli utenti possano installare software volenti o nolenti. Ad esempio, un utente desidera installare Sublime Text, un editor di testo che consente di utilizzarlo gratuitamente per un tempo limitato. Lo rimuove e lo reinstalla dopo il tempo assegnato. Ciò violerebbe l'EULA.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...