è possibile mantenere qualcosa di invisibile all'amministratore del server?

No, come regola generale non è possibile bloccare completamente gli amministratori e consentire loro comunque un accesso sufficiente per svolgere il proprio lavoro. Puoi sollevare alcune barriere che rendono difficile per un individuo abusare del loro accesso privilegiato (e rimanere inosservato) senza cospirare con gli altri.

La maggior parte delle aziende si occupa di questo tipo di sfide più o meno allo stesso modo: attenuano i rischi con procedure e controlli, applicati da contratti, tecnologia e auditing.

• assumi persone capaci e affidabili e offri loro incentivi sufficienti per continuare ad agire in quel modo (la carota: lavoro interessante, apprezzamento, denaro e bastone: clausole penali, accusa, ecc.)
• dopo l'installazione iniziale, l'accesso amministrativo è limitato (si pensi molto sudo al posto di una password di root conosciuta)
• usa gli strumenti in modo che gli amministratori non abbiano bisogno di un effettivo accesso alla linea di comando del sistema per eseguire compiti di amministratore comuni
• gestione degli account privilegiati, ogni escalation di privilegi segue la procedura e richiede un principio rigoroso a quattro occhi
• Nessun singolo individuo può contenere tutte le chiavi del regno
• fidati ma verifica, implementa il controllo indipendente
• separazione delle funzioni, un sysadmin non ha diritti DBA, né viceversa
• crittografia dei dati a riposo (rende difficile accedere ai dati critici bypassando i controlli di accesso interni nell'applicazione leggendoli direttamente dal disco)
• I controlli di accesso obbligatori SELinux possono davvero limitare "la potenza di root"
• e potrei persino immaginare un setup in cui ogni azione dell'amministratore è stata programmata, piuttosto che eseguita manualmente.

Quindi non esiste una singola misura, ma una combinazione delle misure che ho citato e di molte che ho saltato, può rendere difficile per un amministratore di sistema accedere ai dati che non dovrebbe, almeno non senza essere scoperto.

Se un utente ha accesso amministrativo completo (root su Linux, Administrator su Windows), lui (o lei) può fare tutto ciò che vuole, fino a includere modifiche ai permessi dei file e ai diritti di accesso se per qualche ragione c'è qualcosa che non fa Non ho già accesso a. Questo è inevitabile, perché è l'intero punto di avere accesso amministrativo completo in primo luogo.

La soluzione è non fornire all'utente un accesso amministrativo completo, ma solo per concedergli le autorizzazioni necessarie per la gestione di ciò che deve gestire; tuttavia, a seconda dei sistemi e delle attività che deve effettivamente eseguire, questo può diventare complicato e può variare in difficoltà da qualcosa di semplice come "posizionare l'utente in un gruppo specifico" per "personalizzare pesantemente le autorizzazioni del sistema di file e i criteri di sistema".

Se i dati e il codice dell'applicazione devono essere mantenuti riservati, suggerisco di gestire i dati in forma crittografata laddove possibile.

Certo, un amministratore potrebbe prendere misure contro questo, ma è comunque un approccio migliore rispetto al solo affidamento solo sulle autorizzazioni di sistema.

L'auditing delle azioni di un amministratore con auditd da parte di un altro team potrebbe essere più efficace che paralizzare un account amministratore e rendere difficili le attività quotidiane.

Potresti essere in grado di nascondere qualcosa da un amministratore di sistema se sei disposto a spendere un po 'di denaro facendo così (questo potrebbe non essere un grosso problema dal momento che il tuo scenario si riferisce ai segreti commerciali dell'impresa di investimento) e accettare alcuni altri rischi.

L'idea di base qui si basa sull'implementazione di un rootkit residente in BIOS che nasconde l'accesso a una specifica funzionalità nel sistema operativo. Dal momento che probabilmente hai server moderni, sarebbero dotati di UEFI, una nuova forma di BIOS. Il firmware UEFI supporta il caricamento di una parte di codice denominata Update Capsule.

Sui computer basati su Windows questa funzionalità è stata utilizzata da aziende come Lenovo per installare software persistente, come si può leggere qui e qui . Un articolo di Intel che descrive questa funzionalità su macchine basate su Linux può essere trovato qui .

La Capsule di aggiornamento conterrebbe il "rootkit", in questo caso una parte di codice personalizzata che verrebbe sempre caricata all'avvio dei server e che avrebbe alcuni componenti che aiutano a controllarsi a vicenda (per garantire che la parte UEFI non abbia stato sovrascritto, ecc.)

Esattamente quello che l'accesso al sistema operativo che questo codice dovrebbe bloccare dipende dalla natura dei segreti commerciali (sia che si tratti di un codice in esecuzione, valori in alcuni DB, o qualcos'altro).

Se questa sarebbe la soluzione giusta dipende da fattori come la natura esatta del tuo ambiente (che tu usi o meno VM, che tipo di errore abbia la configurazione che hai, ecc.)

E poi questo arriva anche con l'avvertenza che nulla è assolutamente infallibile. Quindi, per esempio, dovresti fidarti degli sviluppatori (o assumere qualche altra persona per verificare il codice sorgente, ad esempio per le backdoor). Inoltre, se l'amministratore del sistema ha accesso fisico all'hardware (i server effettivi) in cui risiedono i segreti commerciali, potrebbe essere in grado di aggirare questa impostazione.

Il computer di sviluppo e il computer di produzione sono gli stessi? In caso contrario, è possibile mantenere il codice sorgente su un computer (ad accesso altamente limitato), compilare utilizzando l'offuscazione del codice e utilizzare il codice compilato nel cluster di produzione, con il codice che richiede una PW prima di eseguirlo.

Se vuoi che qualcuno oltre a te gestisca i sistemi che contengono informazioni sensibili. Si riduce ad assumere l'Amministratore giusto di cui ci si può fidare e ha l'etica di non abusare dei propri poteri per proteggere i dati aziendali. Inoltre richiede di avere gli accordi per non divulgare tali informazioni e avere ripercussioni legali in caso di un errore etico.

Essendo stato Jr. Systems Administrator presso una società di sviluppo software, il mio compito era mantenere i sistemi critici. Molti di questi sistemi contenevano il codice sorgente, e-mail sensibili e dati finanziari dell'azienda. Avendo quel potere, ho fatto il mio lavoro per proteggere i dati da quelli che non avevano il permesso di vedere i dati. Essendo anche un amministratore di sistema, non guarderei i dati perché erano fuori dal mio lavoro. Se fosse necessario esaminare alcuni di questi dati per svolgere il mio lavoro, chiederei l'autorizzazione prima di farlo.

Ci sono poche cose che puoi fare

• concedere in modo restrittivo le autorizzazioni a sysadmin
• crittografare i dati riservati
• Accordo NDA con sysadmin
• memorizza i dati su un sistema remoto in cui solo le persone fidate hanno accesso