Linux: amministratori di sistema produttivi senza root (protezione della proprietà intellettuale)?

Esiste un modo per rendere produttivo un amministratore di sistema Linux esperto senza dargli accesso root completo?

Questa domanda viene dal punto di vista della protezione della proprietà intellettuale (IP), che nel mio caso è interamente codice e / o file di configurazione (ovvero piccoli file digitali che possono essere facilmente copiati). La nostra salsa segreta ci ha reso più efficaci di quanto suggerirebbero le nostre piccole dimensioni. Allo stesso modo, siamo morsi una volta, due volte timidi da alcuni ex dipendenti senza scrupoli (non amministratori di sistema) che hanno cercato di rubare la proprietà intellettuale. La posizione del top management è fondamentalmente: "Abbiamo fiducia nelle persone, ma per interesse personale, non possiamo permetterci il rischio di dare a una persona più accesso di quello di cui hanno assolutamente bisogno per fare il loro lavoro".

Dal punto di vista degli sviluppatori , è relativamente facile partizionare i flussi di lavoro e i livelli di accesso in modo tale che le persone possano essere produttive ma vedere solo ciò che devono vedere. Solo le persone migliori (effettivi proprietari dell'azienda) hanno la possibilità di combinare tutti gli ingredienti e creare la salsa speciale.

Ma non sono stato in grado di trovare un buon modo per mantenere questo segreto IP sul lato amministratore di Linux. Facciamo ampio uso di GPG per codice e file di testo sensibili ... ma cosa impedisce a un amministratore di (ad esempio) fare causa a un utente e saltare la sua sessione su tmux o GNU Screen e vedere cosa stanno facendo?

(Abbiamo anche accesso a Internet disattivato ovunque che potrebbe eventualmente entrare in contatto con informazioni sensibili. Ma nulla è perfetto e potrebbero esserci buchi aperti a amministratori di sistema intelligenti o errori sul lato amministratore della rete. O persino una buona vecchia USB. ovviamente numerose altre misure in atto, ma quelle vanno oltre lo scopo di questa domanda.)

Il meglio che posso inventare è fondamentalmente l'uso di account personalizzati con sudo , simile a quello descritto in amministratori di sistema Linux multipli che funzionano come root . In particolare: nessuno, tranne i proprietari dell'azienda, avrebbe effettivamente accesso diretto alla radice. Gli altri amministratori avrebbero un account personalizzato e la capacità di sudo in radice. Inoltre, verrebbe istituita la registrazione remota e i registri andrebbero su un server a cui solo i proprietari dell'azienda potevano accedere. Vedere la registrazione disattivata avrebbe innescato una sorta di avvisi.

Un intelligente amministratore di sistema potrebbe probabilmente trovare ancora dei buchi in questo schema. E a parte questo, è ancora reattivo piuttosto che proattivo . Il problema con il nostro IP è tale che i concorrenti potrebbero usarlo molto rapidamente e causare molti danni in tempi molto brevi.

Quindi ancora meglio sarebbe un meccanismo che limiti ciò che l'amministratore può fare. Ma riconosco che si tratta di un equilibrio delicato (in particolare alla luce della risoluzione dei problemi e della risoluzione dei problemi di produzione che devono essere risolti in questo momento ).

Non posso fare a meno di chiedermi in che modo altre organizzazioni con dati molto sensibili gestiscono questo problema? Ad esempio, amministratori di sistema militari: come gestiscono server e dati senza poter vedere informazioni riservate?

Modifica: nel post iniziale, intendevo affrontare preventivamente i commenti sulle "pratiche di assunzione" che stanno iniziando a emergere. Uno, questa dovrebbe essere una domanda tecnica , e le pratiche di assunzione dell'IMO tendono maggiormente verso le questioni sociali . Ma, due, dirò questo: credo che facciamo tutto ciò che è ragionevole per assumere persone: intervista con piùpersone in azienda; controlli di base e di riferimento; tutti i dipendenti firmano numerosi documenti legali, incluso uno che afferma di aver letto e compreso il nostro manuale che descrive in dettaglio i problemi di PI. Ora, è fuori dallo scopo di questa domanda / sito, ma se qualcuno può proporre pratiche di assunzione "perfette" che filtrano il 100% dei cattivi attori, sono tutto orecchi. I fatti sono: (1) Non credo che esista un processo di assunzione così perfetto; (2) le persone cambiano - l'angelo di oggi potrebbe essere il diavolo di domani; (3) il tentativo di furto di codice sembra essere piuttosto ordinario in questo settore.

Quello di cui stai parlando è noto come il rischio di "Evil Sysadmin". Il lungo e corto di esso è:

• Un amministratore di sistema è qualcuno che ha privilegi elevati
• Tecnicamente abile, a un livello che li renderebbe un buon "hacker".
• Interagire con i sistemi in scenari anomali.

La combinazione di queste cose rende sostanzialmente impossibile fermare azioni dannose. Anche l'auditing diventa difficile, perché non hai "normali" con cui confrontarti. (E francamente - un sistema guasto potrebbe anche avere un controllo rotto).

Ci sono un sacco di passaggi mitigativi:

• Separazione dei privilegi: non puoi impedire a un ragazzo con root di fare qualcosa sul sistema. Ma puoi rendere responsabile un team per la rete e un altro team responsabile dei "sistemi operativi" (o Unix / Windows separatamente).
• Limitare l'accesso fisico al kit a un team diverso, che non ha account di amministratore ... ma si occupa di tutto il lavoro "manuale".
• Separare la responsabilità "desktop" e "server". Configurare il desktop per impedire la rimozione dei dati. Gli amministratori desktop non hanno la possibilità di accedere ai sensibili, gli amministratori del server possono rubarlo, ma devono saltare attraverso i cerchi per farlo uscire dall'edificio.
• Controllo su un sistema ad accesso limitato - sysloge controllo a livello di evento, su un sistema relativamente antimanomissione a cui non hanno accesso privilegiato. Ma collezionarlo non è abbastanza, è necessario monitorarlo - e francamente, ci sono un sacco di modi per "rubare" informazioni che potrebbero non apparire su un radar di controllo. (Bracconiere vs guardacaccia)
• applica la crittografia "a riposo", quindi i dati non vengono archiviati "in chiaro" e per accedere è necessario un sistema attivo. Ciò significa che le persone con accesso fisico non possono accedere a un sistema che non è attivamente monitorato e che in uno scenario "anomalo" in cui un amministratore di sistema ci sta lavorando, i dati sono meno esposti. (ad es. se il database non funziona, i dati probabilmente non sono leggibili)
• Regola di due uomini: se stai bene con la tua produttività paralizzata e anche il tuo morale. (Scherzi a parte - l'ho visto fatto, e il persistente stato di lavoro e di osservazione rende le condizioni di lavoro estremamente difficili).
• Controlla i tuoi amministratori di sistema: potrebbero esistere vari controlli dei record a seconda del paese. (Verifica dei precedenti penali, in alcuni casi potresti persino scoprire di poter richiedere un'autorizzazione di sicurezza, che attiverà il controllo)
• Prenditi cura dei tuoi amministratori di sistema: l'ultima cosa che vuoi fare è dire a una persona "fidata" che non ti fidi di loro. E certamente non vuoi danneggiare il morale, perché ciò aumenta la possibilità di comportamenti maliziosi (o "non del tutto negligenza, ma una perdita di vigilanza"). Ma paga in base alla responsabilità e alle competenze. E considera i "vantaggi", che sono più economici dello stipendio, ma probabilmente valutati di più. Come caffè gratuito o pizza una volta alla settimana.
• e puoi anche provare ad applicare condizioni contrattuali per inibirlo, ma fai attenzione a quanto sopra.

Ma fondamentalmente, devi accettare che questa è una cosa di fiducia, non tecnica. I tuoi amministratori di sistema saranno sempre potenzialmente molto pericolosi per te, a causa di questa tempesta perfetta.

Tutto ciò che è stato detto finora qui è roba buona, ma c'è un modo "semplice" non tecnico che aiuta a negare un amministratore disordinato: il principio dei quattro occhi che richiede sostanzialmente che due amministratori di sistema siano presenti per qualsiasi accesso elevato.

EDIT: I due più grandi elementi che ho visto nei commenti stanno discutendo i costi e la possibilità di collusione. Uno dei modi più importanti che ho considerato per evitare entrambi questi problemi è l'utilizzo di una società di servizi gestiti utilizzata solo per la verifica delle azioni intraprese. Fatto correttamente, i tecnici non si conoscono. Supponendo che l'abilità tecnica che un MSP dovrebbe avere sarebbe abbastanza facile avere un segno di approvazione delle azioni intraprese .. forse anche semplice come un sì / no a qualcosa di nefasto.

Se le persone hanno davvero bisogno dell'accesso di amministratore a un sistema, allora c'è poco che puoi fare per limitare le loro attività su quella casella.

Ciò che la maggior parte delle organizzazioni fa è affidamento, ma verifica : potresti consentire alle persone di accedere a parti del sistema ma utilizzi account admin nominati (ad es. Non dai loro l'accesso diretto al root ) e quindi controlli le loro attività in un registro che non può interferire con.

C'è un atto di bilanciamento qui; potresti dover proteggere i tuoi sistemi ma devi anche fidarti delle persone per fare il loro lavoro. Se la società fosse precedentemente "morsa" da un dipendente senza scrupoli, ciò potrebbe suggerire che le pratiche di assunzione della società sono in qualche modo scarse e che tali pratiche sono state presumibilmente create dai "top manager". La fiducia inizia a casa; cosa stanno facendo per sistemare le loro scelte di assunzione?

Senza metterti in una folle svolta tecnica mentale per cercare di trovare un modo per dare un potere di amministratore di sistema senza dargli potere (è probabilmente fattibile, ma alla fine sarebbe in qualche modo imperfetto).

Dal punto di vista delle pratiche commerciali, esiste una serie di soluzioni semplici. Soluzione non economica, ma semplice.

Hai detto che i frammenti di IP di cui sei preoccupato sono divisi e solo le persone in alto hanno il potere di vederli. Questa è essenzialmente la tua risposta. Dovresti avere più amministratori e NESSUNO di essi dovrebbe essere un amministratore su sistemi sufficienti per mettere insieme il quadro completo. Ovviamente avrai bisogno di almeno 2 o 3 amministratori per ogni pezzo, nel caso in cui un amministratore sia malato o in un incidente d'auto o qualcosa del genere. Forse anche scagliandoli. supponiamo che tu abbia 4 amministratori e 8 informazioni. admin 1 può accedere ai sistemi che hanno i pezzi 1 e 2, admin 2 può arrivare ai pezzi 2 e 3, admin 3 può arrivare a 3 e 4 e admin 4 può arrivare a 4 e 1. Ogni sistema ha un amministratore di backup, ma no admin è in grado di compromettere il quadro completo.

Una tecnica utilizzata anche dai militari è la limitazione dei dati in movimento. In un'area sensibile potrebbe esserci un solo sistema in grado di masterizzare un disco o utilizzare un'unità flash USB, tutti gli altri sistemi sono soggetti a restrizioni. E la capacità di utilizzare quel sistema è estremamente limitata e richiede un'approvazione documentata specifica da parte dei superiori prima che a chiunque sia permesso di mettere qualsiasi dato su qualsiasi cosa possa portare alla fuoriuscita di informazioni. Allo stesso modo, si garantisce che il traffico di rete tra sistemi diversi sia limitato dai firewall hardware. Gli amministratori di rete che controllano i firewall non hanno accesso ai sistemi che stanno instradando, quindi non possono ottenere specificamente l'accesso alle informazioni e gli amministratori del server / workstation garantiscono che tutti i dati da e verso un sistema siano configurati per essere crittografati,

Tutti i laptop / workstation dovrebbero avere dischi rigidi crittografati e ogni dipendente dovrebbe avere un armadietto personale necessario per bloccare le unità / laptop alla fine della notte per garantire che nessuno arrivi in ​​anticipo / lasci tardi e ottenga l'accesso a qualcosa non dovrebbero.

Ogni server dovrebbe almeno essere nel proprio rack bloccato, se non nella propria stanza chiusa, in modo che solo gli amministratori responsabili di ciascun server possano accedervi, poiché alla fine della giornata l'accesso fisico vince su tutto.

Successivamente c'è una pratica che può ferire / aiutare. Contratti limitati. Se pensi di poter pagare abbastanza per attrarre nuovi talenti, l'opzione di mantenere un solo amministratore per un periodo di tempo predeterminato (IE 6 mesi, 1 anno, 2 anni) ti permetterebbe di limitare il tempo che qualcuno avrebbe per tentare di mettere insieme tutti i pezzi del tuo IP.

Il mio design personale sarebbe qualcosa sulla falsariga di ... Dividi i tuoi dati in qualsiasi parte, diciamo per avere un numero 8, hai 8 server git, ognuno con il proprio set di hardware ridondante, ciascuno gestito da un diverso set di amministratori.

Hard disk crittografati per tutte le workstation che toccheranno l'IP. con una specifica directory di "progetto" sull'unità che è l'unica directory a cui gli utenti sono autorizzati a inserire i propri progetti. Alla fine di ogni notte sono tenuti a disinfettare le loro directory di progetto con uno strumento di cancellazione sicuro, quindi i dischi rigidi vengono rimossi e rinchiuso (solo per sicurezza).

A ciascun bit del progetto è assegnato un diverso amministratore, quindi un utente interagisce solo con l'amministratore della stazione di lavoro a cui è assegnato, se la sua assegnazione di progetto cambia, i suoi dati vengono cancellati, gli viene assegnato un nuovo amministratore. I loro sistemi non dovrebbero avere funzionalità di masterizzazione e dovrebbero utilizzare un programma di sicurezza per impedire l'uso di unità flash USB per trasferire dati senza autorizzazione.

prendi ciò che vuoi.

Sarebbe simile alla sfida di assumere un bidello per un edificio. Il bidello ottiene tutte le chiavi, può aprire qualsiasi porta, ma il motivo è che il bidello ha bisogno che facciano il lavoro. Lo stesso vale per gli amministratori di sistema. Simmetricamente si può pensare a questo problema secolare e osservare i modi in cui la fiducia è garantita storicamente.

Anche se non esiste una soluzione tecnica netta, il fatto che non ce ne sia una non dovrebbe essere una ragione per cui non ne proviamo nessuna, un'aggregazione di soluzioni imperfette può dare risultati piuttosto grandi.

Un modello in cui si guadagna la fiducia :

• Dare meno autorizzazioni per cominciare
• Aumentare gradualmente le autorizzazioni
• Metti un honeypot e controlla cosa succede nei prossimi giorni
• Se l'amministratore di sistema lo segnala invece di tentare di abusarlo, è un buon inizio

Attuare diversi livelli di poteri amministrativi :

• Livello 1: può modificare il livello inferiore dei file di configurazione
• Livello 2: può modificare un livello leggermente superiore di file di configurazione
• Livello 3: può modificare un livello leggermente superiore di file di configurazione e impostazioni del sistema operativo

Crea sempre un ambiente in cui l'accesso totale da parte di una persona non è possibile :

• Sistemi divisi in cluster
• Dare poteri di amministrazione del cluster a diversi gruppi
• Minimo 2 gruppi

Utilizzare la regola di due uomini quando si apportano modifiche di base di alto livello :

• https://en.wikipedia.org/wiki/Two-man_rule
• Richiede un amministratore da cluster1 e cluster2 per le modifiche principali

Affidati e verifica :

• Registra tutto
• Registra il monitoraggio e gli avvisi
• Assicurarsi che tutte le azioni siano distinguibili

Scartoffie :

• Invitali a firmare i documenti per far sì che il sistema legale sia in grado di aiutarti citandoli in giudizio se ti feriscono, più incentivi a non farlo

È molto difficile proteggere gli host da quelli con accesso amministrativo. Mentre strumenti come PowerBroker tentano di farlo, il costo è aggiungere sia qualcos'altro che può rompere e aggiungere barriere ai tentativi di risolverlo. La vostra disponibilità del sistema SARA cadere quando si implementa qualcosa di simile in modo da impostare questa aspettativa già a partire dal costo di proteggere le cose.

Un'altra possibilità è vedere se la tua app può essere eseguita su host monouso tramite un provider cloud o in un cloud privato ospitato localmente. Quando uno si interrompe, invece di inviare un amministratore per risolverlo, lo butti via e costruisci automaticamente una sostituzione. Ciò richiederà un sacco di lavoro sul lato dell'applicazione per farli funzionare in questo modello, ma può risolvere molti problemi operativi e di sicurezza. Se fatto male, può creare alcuni significativi problemi di sicurezza, quindi fatti aiutare se segui questa strada.

Questa è la discussione di base: https://security.stackexchange.com/questions/7801/keeping-secrets-from-root-on-linux

Dividi la tua responsabilità avendo tecnici della sicurezza il cui compito è quello di effettuare configurazioni e installazioni di sistema, ma non ottengono credenziali o accesso alle macchine in produzione. Gestiscono anche la tua infrastruttura di controllo.

Ci sono amministratori di produzione che ricevono i sistemi ma non hanno le chiavi per avviare la macchina senza che i criteri SELinux siano attivi. La sicurezza non ottiene le chiavi per decrittografare i dati sensibili archiviati inattivi sul disco per quando vengono rimossi dal servizio una macchina rotta.

Utilizza un sistema di autenticazione centralizzato con un forte controllo come Vault e sfrutta le sue operazioni di crittografia. Distribuisci i dispositivi Yubikey per rendere le chiavi assolutamente private e illeggibili.

Le macchine vengono spazzate via in caso di rottura o gestite da operatori operativi e sicurezza insieme e se si sente la necessità di un controllo esecutivo.

Gli amministratori per natura del lavoro hanno accesso a tutto. Possono vedere tutti i file nel file system con le loro credenziali di amministratore. Quindi, avrai bisogno di un modo per crittografare i file in modo che gli amministratori non possano vederlo, ma i file sono ancora utilizzabili dai team che dovrebbero vederlo. Cerca in Vormetric Transparent Encryption ( http://www.vormetric.com/products/transparent-encryption )

Il modo in cui funzionerebbe è che si trova tra il filesystem e le applicazioni che vi accedono. Il management può creare la politica che dice "Solo l'utente httpd, che esegue il demone del server web può vedere i file non crittografati". Quindi un amministratore con le sue credenziali di root può provare a leggere i file e ottenere solo la versione crittografata. Ma il web server e tutti gli strumenti di cui ha bisogno li vedono non crittografati. Può persino fare il checksum del file binario per rendere più difficile aggirare l'amministratore.

Ovviamente dovresti abilitare il controllo in modo che, nel caso in cui un amministratore tenti di accedere ai file, un messaggio venga contrassegnato e le persone lo sappiano.

L'unico modo pratico è limitare chi può fare cosa con sudo. Potresti potenzialmente fare anche la maggior parte di ciò che vuoi con selinux, ma probabilmente ci vorrebbe un'eternità per capire la configurazione corretta che potrebbe renderlo poco pratico.

Accordi di non divulgazione. Assumere un amministratore di sistema, devono firmare un accordo di non divulgazione, se mantengono la promessa, li portano in tribunale. Ciò potrebbe non impedire loro di sottrarre segreti, ma eventuali danni che causano facendolo sono recuperabili in tribunale.

Gli amministratori di sistema militari e governativi devono ottenere autorizzazioni di sicurezza di diversi gradi a seconda della sensibilità del materiale. L'idea è che qualcuno che può ottenere un'autorizzazione ha meno probabilità di rubare o imbrogliare.

Un altro modo per ridurre il rischio (utilizzare accanto a quelli menzionati prima, non invece di) è quello di pagare un buon prezzo per i vostri amministratori di sistema. Pagali così bene che non vogliono rubare dal tuo IP e lasciarti.

Sto pensando che questa domanda potrebbe non essere possibile rispondere in modo completo senza ulteriori dettagli, come:

Quanti amministratori di sistema prevedi di mantenere "limitato"?

Cosa devono fare le persone per accedere a "sysadmin"?

Prima di tutto, fai attenzione a cosa puoi fare con sudo. Con sudo, puoi consentire permessi elevati per eseguire solo un singolo comando (o variazioni, come i comandi che iniziano con "mount -r" ma altri comandi non sono consentiti). Con le chiavi SSH, puoi assegnare credenziali che consentono a una persona di eseguire solo un determinato comando (come "sudo mount -r / dev / sdd0 / media / backup"). Pertanto, esiste un modo relativamente semplice per consentire a chiunque (che ha una chiave SSH) di essere in grado di eseguire alcune operazioni specifiche senza lasciargli fare assolutamente tutto il resto.

Le cose diventano un po 'più difficili se vuoi che i tecnici eseguano le correzioni di ciò che è rotto. Questo in genere può richiedere una maggiore quantità di autorizzazioni e forse l'accesso per eseguire un'ampia varietà di comandi e / o scrivere su una varietà di file.

Suggerisco di prendere in considerazione l'approccio di sistemi basati sul web, come CPanel (che viene utilizzato da numerosi ISP) o sistemi basati su cloud. Spesso possono far andare via i problemi su una macchina, facendo andare via l'intera macchina. Pertanto, una persona potrebbe essere in grado di eseguire un comando che sostituisce la macchina (o ripristina la macchina in un'immagine ben nota), senza necessariamente dare alla persona l'accesso alla lettura di molti dati o apportare piccole modifiche (come combinare una correzione minore con l'introduzione di una porta sul retro non autorizzata). Quindi, devi fidarti delle persone che creano le immagini, ma stai riducendo il numero di persone di cui ti devi fidare per fare le cose più piccole.

Alla fine, tuttavia, è necessario fornire una certa fiducia a un numero diverso da zero di persone che aiutano a progettare il sistema e che operano al più alto livello.

Una cosa che fanno le grandi aziende è fare affidamento su cose come i server SQL, che memorizzano i dati a cui è possibile accedere in remoto da un numero maggiore di macchine. Quindi, un numero maggiore di tecnici può avere accesso root completo su alcune macchine, senza avere accesso root ai server SQL.

Un altro approccio è quello di essere troppo grandi per fallire. Non pensare che i grandi militari o le corporazioni giganti non abbiano mai avuto incidenti di sicurezza. Tuttavia, sanno come:

• recuperare,
• limitare i danni (separando oggetti di valore)
• hanno contromisure, comprese le minacce di contenzioso
• hanno processi per aiutare a limitare l'esposizione indesiderata alla stampa e hanno piani su come influenzare la rotazione di eventuali storie negative che si sviluppano

Il presupposto di base è che il danno che si verifica è semplicemente un rischio e un costo del loro fare affari. Si aspettano che continuino a funzionare e gli sviluppi e i miglioramenti in corso nel corso degli anni limiteranno la quantità di danni che un singolo incidente può effettivamente influenzare il loro valore a lungo termine per un periodo di tempo.

Fare un controllo proattivo è molto difficile.

Soluzioni come http://software.dell.com/solutions/privileged-management/ (non lavoro per Dell e sono disponibili altre soluzioni simili) sono molto efficaci nel far valere la responsabilità di amministratore di sistema.

Posiziona la macchina di amministrazione principale nella stanza chiusa con due chiavi e assegnane solo una per ciascuno dei due amministratori. Gli amministratori lavoreranno sempre insieme, osservandosi a vicenda. Dovrebbe essere l'unica macchina che contiene la chiave privata per accedere come root.

Alcune attività potrebbero non avere bisogno dei diritti di root, quindi solo una parte del lavoro richiederebbe di andare in quella stanza per "programmare la coppia"

Puoi anche registrare attività di registrazione in quella stanza principalmente per assicurarti che nessuno lavori da solo (molto è facilmente visibile). Inoltre, assicurati che il posto di lavoro sia tale che lo schermo sia facilmente visibile per entrambe le persone (forse uno schermo TV di grandi dimensioni con caratteri grandi).