Ubuntu per i dipendenti degli sviluppatori bancari [chiuso]

Esistono processi e metodi documentati su come eseguire computer Ubuntu personalizzati (dall'installazione all'utilizzo quotidiano) per banche e altre aziende che non desiderano che gli utenti scarichino file binari da ubicazioni forse non sicure?

In modo che apt-get, update ecc avvenga solo da poche posizioni di Internet o Intranet affidabili?

Aggiornamento: aggiunto questo dopo la prima risposta. Questi utenti sono supporto, utenti principianti di sistemi e sviluppatori del software di banca ... quindi alcuni di loro hanno bisogno dei privilegi di sudo. Esiste un modo pronto per monitorarli in modo che eventuali eccezioni vengano rilevate rapidamente (come l'aggiunta dell'elenco delle fonti) ma altre azioni come l'installazione di elementi dai repository noti non vengano segnalate.

Lo scopo è quello di essere sicuri, usare Ubuntu o un sapore, consentire ai bebèop e agli altri utenti sudo di essere il più produttivi possibile. (E ridurre la dipendenza da computer Windows e Mac)

.2. E le persone IT possono comunicare la politica agli utenti in modo che non possano fare alcune azioni come condividere una cartella, anche se sudo utente? Una soluzione completa?

Questa è un'ottima domanda, ma la sua risposta è molto difficile.

Innanzitutto, per iniziare @Timothy Truckle ha un buon punto di partenza. Avresti eseguito il tuo repository apt in cui il tuo team di sicurezza poteva verificare ogni pacchetto. Ma questo è solo l'inizio.

Successivamente vorrai implementare i gruppi. Mireresti ad avere gli utenti in grado di fare le cose di cui hanno bisogno senza molto aiuto dal supporto. Ma nel settore bancario vuoi davvero che le cose siano bloccate. In effetti in molte strutture aziendali vuoi bloccare le cose. Quindi la concessione ai normali utenti dei privilegi sudo a qualsiasi livello è probabilmente fuori.

Quello che probabilmente faresti è impostare le cose in modo che determinati gruppi non abbiano bisogno di autorizzazioni elevate per fare il loro lavoro.

Ancora una volta, nella maggior parte degli ambienti aziendali l'installazione di software è qualcosa che può farti licenziare, quindi è un no no. Se hai bisogno di software, chiami l'IT e loro lo fanno per te, oppure c'è una catena di richieste o qualcosa del genere.

Idealmente non avresti mai bisogno di un normale dipendente per installare nulla o mai bisogno di autorizzazioni elevate.

Ora per gli sviluppatori la domanda è un po 'diversa. Forse hanno bisogno di installare e forse hanno bisogno di sudo. Ma le loro scatole sono sulla "rete di pericolo" e non possono MAI collegarsi direttamente ai sistemi critici.

Il personale IT / di supporto avrà bisogno di sudo. Ma puoi limitare l'accesso sudo tramite comando, processo (scartoffie) o altri mezzi. Ci possono essere interi volumi su cose come il "principio 2 occhi" e su come implementarlo. Tuttavia, esistono registri di controllo che possono essere configurati per soddisfare la maggior parte delle esigenze.

Quindi, tornando alla tua domanda. La risposta di Timothy Truckle è corretta al 100%, ma la premessa per la tua domanda è disattivata. Proteggere un sistema operativo Linux è molto più sulla scelta delle impostazioni necessarie per il tuo caso d'uso specifico, e meno su un'idea generale su come proteggere le cose.

Imposta il tuo proxy repository debian all'interno della tua intranet.

Personalizza l'installazione di Ubuntu in modo che il tuo proxy repository debian sia l'unica voce /etc/apt/sources.list.

Et voilà: hai il pieno controllo del software installato sui tuoi client (purché nessun utente disponga delle autorizzazioni per superutente).

Aggiornamento: aggiunto questo dopo la prima risposta. Questi utenti sono supporto, utenti principianti di sistemi e sviluppatori del software di banca ... quindi alcuni di loro hanno bisogno dei privilegi di sudo. Esiste un modo pronto per monitorarli in modo che eventuali eccezioni vengano rilevate rapidamente (come l'aggiunta dell'elenco delle fonti) ma altre azioni come l'installazione di elementi dai repository noti non vengano segnalate.

Nella tua installazione personalizzata puoi modificare il /etc/sudoersfile in modo che gli utenti siano autorizzati a eseguire sudo apt updatee sudo apt installnessun altro comando che inizi con apt. Naturalmente, devi anche limitare sudo bash(o qualsiasi altra shell).

In quasi tutti i negozi che ho visto finora, gli sviluppatori avevano pieno accesso alle macchine di sviluppo, ma queste macchine avevano accesso solo a Internet e al repository di codice sorgente.

Il codice sorgente viene archiviato e compilato su macchine affidabili (di cui gli sviluppatori solitamente non dispongono o che necessitano di autorizzazioni amministrative), e quindi da lì distribuito per testare i sistemi che hanno accesso alla rete interna.

Il fatto che queste macchine siano utilizzate dagli sviluppatori o da un team di test separato dipende dalla tua organizzazione, ma in genere il confine tra macchine affidabili e non affidabili è tra macchine separate, con l'interfaccia verificabile tra loro (come il commit del codice sorgente).

I dipendenti della reception non hanno mai avuto privilegi di amministratore. Quando abbiamo distribuito il solitario su tutte queste macchine, i reclami su questa politica sono praticamente cessati.