Perché le aziende non danno accesso di root ai dipendenti sulle loro macchine desktop? [duplicare]

Naviga le tue risposte
36

Perché le aziende in genere non danno ai loro dipendenti l'accesso di root ai loro computer desktop che vengono utilizzati solo da un singolo dipendente?

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

Il punto della gestione utenti di Unix non è 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): Poiché sto lavorando senza accesso root, tutti i miei file sono di mia proprietà; quindi, se sono ingannato ed eseguo uno script malvagio senza accesso root e pulisce solo tutti i file di mia proprietà, è altrettanto brutto come se avessi dato l'accesso come root e cancellato l'intero disco rigido.

    
posta Bananach 25.10.2018 - 11:08
fonte

8 risposte

56

Gli amministratori della sicurezza sono responsabili per la tua macchina e cosa succede 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 i controlli di sicurezza sulla macchina per proteggere la società, non solo i dati, la rete e gli altri nodi. Se l'utente locale ha accesso root, gli amministratori non hanno più il controllo su quei controlli. Questa è la premessa di base.

Sì, ci sono un sacco di motivi per cui root è necessario per fare cose cattive o per trasformare la macchina in un nodo malevolo e tutti questi sono buoni motivi 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.

    
risposta data 25.10.2018 - 11:33
fonte
25

Alcune ragioni in cima alla mia testa:

  • L'avvelenamento ARP o gli attacchi di rete inondazioni sulla rete richiederebbero in genere l'accesso come root a una macchina sulla rete.

  • La possibilità di installare programmi non autorizzati potrebbe aprire la società alla responsabilità legale se tali programmi sono illegali (ad esempio perché sono piratati o non autorizzati per l'uso a fini di lucro o altro).

  • Se l'azienda ha un qualche tipo di monitoraggio remoto dei dipendenti (o vuole la possibilità di avere tale monitoraggio anche se non è ancora sul posto), dare agli utenti l'accesso come root consentirebbe loro di ignorarli.

  • Non avere accesso root significa che non puoi rm -rf /bin , o un numero qualsiasi di altre cose distruttive, e nemmeno chiunque può accedere ai tuoi dettagli di accesso, quindi non c'è alcuna possibilità che la tua azienda abbia bisogno di aiutarti recuperare da quella situazione.

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

  • Dare agli utenti l'accesso come root è facile, se necessario; l'accesso a root in modo completo è difficile se diventa necessario.

  • Il generale principio di privilegio minimo è che non devi dare accesso a nessuno / a qualcosa che non fanno t bisogno attivamente.

  • Semplicemente non essersi spostati dai giorni dei server condivisi perché è un processo che ha funzionato e nulla ha rotto l'inerzia (l'ipotetico problema di scimmie e ladder ).

risposta data 25.10.2018 - 11:23
fonte
12

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

Parte del motivo è (come altri hanno accennato) che gli utenti non possono essere considerati attendibili per fare cose folli / 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 un certo numero di nostri server di produzione e almeno un certo livello di accesso all'hypervisor su cui sono distribuiti. Ma se mi incasino, sono la festa (o almeno un partito) con le competenze, le competenze e la responsabilità per risolverlo. Non è così tipico per l'utente finale: se Bobby l'utente esegue il bould della propria installazione di Windows che ha dati mission-critical e / o utilizzati per lavori mission-critical, Bobby non è quello che deve entrare nel suo / il suo giorno libero o il lavoro straordinario non retribuito per ripararlo. Per non parlare della risposta al come Bobby Bobby è riuscito a affondare quasi da solo la nave.

Quindi, parte del motivo per cui i dipartimenti IT limitano i privilegi degli utenti finali è che riduce la propria esposizione al rischio.

    
risposta data 25.10.2018 - 20:09
fonte
4

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

  • proteggere la macchina stessa (non sempre molto efficiente) e le altre macchine sulla rete da possibili attacchi usando quella macchina come relay (già coperta da altre risposte)
  • proteggere il team di supporto IT dagli attacchi a livello di amministratore che richiederanno molto lavoro da risolvere (già coperto da altre risposte)
  • mantenere tutte le macchine con (più o meno) la stessa configurazione per poter eseguire semplicemente installazioni remote da una singola macchina di amministrazione - la dimensione minima del team di supporto, la meno costosa per l'azienda
  • prevenire (o almeno provare a) gli utenti ad installare programmi non correlati al loro lavoro - un utente che gioca a un lavoro o progettare la sua cucina futura non è molto produttivo ...

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

    
risposta data 26.10.2018 - 08:38
fonte
2

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

Se ho accesso root a una scatola, in particolare un dominio unito a Windows, posso installare qualsiasi numero di trucchi diversi che potrei usare per compromettere qualsiasi altro utente della scatola. Dì, ad esempio, un keylogger.

Quindi tutto ciò che devo fare è persuadere un tecnico di supporto ad accedere per risolvere un "problema" appena prodotto (come rompere il segreto condiviso di kerberos), attendere che si elevi all'amministratore del dominio e ho appena compromesso il tutta la rete.

Il keylogger non verrà rilevato dallo scanner malware? Non se ho root non lo farò.

Ottieni ciò di cui hai bisogno per svolgere il tuo lavoro. Se il tuo lavoro ha bisogno di un accesso di root, lo ottieni - insieme al discorso di potere / responsabilità associato. Il mio compito è proteggere tutti gli altri da te.

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

    
risposta data 26.10.2018 - 23:53
fonte
1

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 probabilmente insicura sul suo desktop, la società non ha alcuna possibilità di assicurarsi che non vi sia alcun furto di dati e perdita di dati. Una gestione centralizzata da parte dei professionisti aiuta a proteggere i computer ed evitare la perdita accidentale dei dati.

    
risposta data 26.10.2018 - 11:25
fonte
0

In caso di una casella unix collegata a qualsiasi tipo di file server NFS old school (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ò solo 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 scambiati tra gli utenti secondo necessità, o l'accesso alle macchine del collega (ma non i loro dati!) È consentito occasionalmente, sembra uno scenario per singolo utente ma in realtà utilizza funzionalità multiutente per la gestione delle attrezzature scopi.

    
risposta data 26.10.2018 - 10:44
fonte
0

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

    
risposta data 28.10.2018 - 01:49
fonte

Leggi altre domande sui tag

Se "non puoi mai fidarti del cliente", perché aziende come Valve si affidano esclusivamente alla verifica lato client? È brutto che le telecamere utilizzino un indirizzo IP statico?