Ci sono molte buone risposte qui. Alla fine è una decisione personale e il processo organizzativo è anche una parte molto importante dell'intero processo.

Vorrei indicare un'altra, migliore soluzione gestibile. Disclaimer : questa è una soluzione che sto sviluppando.

privacyIDEA è un sistema di gestione a due fattori. O per dirlo in termini più generali è un sistema di gestione dell'autenticazione. Una possibilità è che puoi anche assegnare un token di autenticazione astratto " token a 4 occhi "a un account utente. In questo modo è possibile impostare che un determinato account utente o determinati comandi (sudo) necessitino dell'autenticazione da parte di due o più persone. Questi utenti potrebbero autenticarsi con password o con token hardware di password one time come yubikeys.

Il bello effetto collaterale è che ottieni un registro di controllo con firma digitale all'interno di privacyIDEA, in modo che tu possa sapere quali due persone hanno agito all'interno della tua regola dei due uomini.

How can two-man control be implemented with minimal overhead?

TL; DR Questo può essere ottenuto utilizzando un comando speciale sudo che richiede che una seconda persona approvi ciascun comando, combinato con una bella lista bianca per rendere più comodi i comandi più sicuri. È importante che ogni comando sia approvato dalla regola di due uomini oppure che la protezione sia facilmente sconfitta.

Opzioni di implementazione di regole a due:

Unconstrained root access

Abilita root accesso temporaneo

Un piccolo script di root potrebbe richiedere una seconda persona (Utente A) da autorizzare prima che sudo diventi disponibile per il sysadmin che agisce (Utente B)

1. Utente A: enable-sudo user-b
   (aggiunge automaticamente una voce a /etc/sudoers con un limite di tempo o una rimozione pianificata tramite% lavoro diat)

2. Utente B: sudo do stuff inizierà a funzionare a questo punto

Sfortunatamente, una User-back potrebbe essere facilmente aggiunta dall'utente B una volta che l'Utente A ha autorizzato l'accesso. Potrebbe essere semplice come aggiungere nuovamente user-b a /etc/sudoers o avviare un servizio separato.

Non è possibile applicare con sicurezza le regole di sicurezza una volta che qualcuno ha guadagnato root (poiché è "non vincolato"), quindi dovresti monitorare segretamente le possibilità di bypass più probabili e avvisare un altro sysadmin (più affidabile) se qualcosa inizia dispari dopo l'abilitazione di due persone di sudo .

• imprevisto at o cron lavoro
• processo in background inatteso ancora in esecuzione
• script di avvio imprevisto

E non dire loro esattamente quali misure di sicurezza stai usando. Ciò aiuterà contro le backdoor ovvie, specialmente se user-b non ha familiarità con le protezioni in atto, ma non ostacolerà un user-b che è determinato a causare problemi.

Regola a due uomini basata su comando

Crea la tua versione di sudo , che avverte la seconda persona di qualsiasi comando suggerito dalla prima persona, con la possibilità di approvare o rifiutare.

Non inserirò qui i dettagli di implementazione, ma sarebbe piuttosto semplice da implementare.

In questo caso, una backdoor dovrebbe essere nascosta all'interno di uno dei file forniti, ad esempio un aggiornamento software da installare.

Modifica di file con vim

La tua versione personalizzata di sudo non dovrebbe consentire l'avvio di comandi di modifica diretta dei file. Se qualcuno digita oursudo vi , quindi oursudo dovrà avviare uno script speciale per la modifica dei file.

1. Copia il file in una posizione /tmp (nome file generato casualmente per impedire attacchi con collegamenti simbolici)
2. Avvia vim con privilegi ridotti a un account non root (quindi user-b non può utilizzare la funzione "Salva con nome" in vim per ignorare questo wrapper)
3. Quando il salvataggio è completato, presenta un diff del file modificato in user-a .
4. Una volta approvato, copia il file approvato da /tmp nella posizione di destinazione.

Barriere fisiche

Richiedere l'accesso fisico per ottenere l'accesso root potrebbe aiutare a dare visibilità a ciò che user-b sta facendo. A seconda dell'ambientazione dell'ufficio, il team può avere un indizio su che cosa è user-b fino a, e / o user-b potrebbe essere meno comodo causando problemi in quell'ambiente. Dipende da quanto spesso è necessario tale accesso.

Problemi: root = non vincolato

Come puoi ricavare dalle idee che ho sollevato, non sembra esserci un fuoco sicuro per proteggere dalle installazioni di back-door. root è progettato per non permetterlo.

I comandi della white list si avvicinano (vincolano l'accesso root)

La cosa migliore è creare una whitelist di comandi disponibili. (che sudo ha la capacità di offrire) Questo crea un overhead significativo all'inizio, ma alla fine può diventare più pratico man mano che impari il comando che sono comunemente usati.

Deploying application updates

Le tue applicazioni non dovrebbero essere eseguite su accesso root. Quelli che devono passare attraverso un sistema di Code Review separato e quindi gli aggiornamenti dal commit VCS approvato possono essere inclusi.

Patching [packaged] software

Questo non può essere limitato, quindi suggerirei di utilizzare la regola a due mani Comando-base descritta sopra.

Troubleshooting

Gli strumenti sicuri possono essere consentiti tramite sudo , quindi utilizzare la regola a due uomini basata su comando per applicare la correzione.

La chiave è implementare il controllo a due mani solo per le operazioni che ne hanno veramente bisogno.

Attività di routine

Le attività di routine, come la distribuzione di una versione dell'applicazione o l'applicazione di patch di sicurezza possono essere programmate. Un amministratore sys può creare lo script, ma non può essere eseguito finché un secondo amministratore di sistema non lo ha revisionato e approvato. Attività comuni come il riavvio del server delle applicazioni o la distribuzione della versione più recente dell'applicazione possono avere uno script pre-approvato che viene utilizzato ripetutamente. Le attività non standard necessiteranno di uno script su misura.

Per fare ciò, è necessario un qualche tipo di sistema di gestione del flusso di lavoro. Potresti essere in grado di utilizzare un sistema di ticketing come Trac, creare un sistema personalizzato su qualcosa come JIRA e strumenti di gestione della configurazione come Puppet potrebbero avere caratteristiche che potrebbero aiutare. I due amministratori di sistema NON devono essere fisicamente locali; possono lavorare da remoto.

I sistemi dovrebbero essere progettati in modo tale che la manutenzione di routine sia automatizzata il più possibile - rotazione programmata dei registri, ecc.

Diagnostica

Gli amministratori di sistema possono avere accesso in sola lettura ai registri senza controllo a due mani, a condizione che i registri mascherino le informazioni riservate. Possono anche avere un account con privilegi ridotti per visualizzare le pagine di stato ed eseguire comandi come top o ps. Ciò consente a un singolo amministratore di sistema di diagnosticare i problemi e di lavorare in remoto. Potrebbero essere in grado di eseguire la riparazione inviando uno script come attività di routine. Tuttavia, in alcuni casi ciò non sarà possibile, quindi è necessario un accesso di emergenza.

Accesso di emergenza

A volte c'è un problema serio e hai solo bisogno di SSH come root. Per mantenere il controllo a due uomini hai bisogno di due persone a questo punto. In pratica, devono essere fisicamente vicini l'uno all'altro. Un modo semplice per implementare il controllo degli accessi è avere un account per ogni abbinamento, in cui ogni amministratore di sistema conosce metà della password. Potresti creare un sistema più intelligente con un modulo PAM personalizzato, forse anche richiedendo una smart card separata da entrambi gli amministratori di sistema.

Una volta effettuato l'accesso, è compito del sys-admins mantenere il controllo di due persone. Devono controllarsi a vicenda i comandi prima di emettere e bloccare il terminale se uno di loro deve uscire.

L'obiettivo dovrebbe essere che l'accesso di emergenza sia raramente necessario.

Ambienti di sviluppo

È solo necessario utilizzare il controllo a due mani per l'ambiente live. Un amministratore di sistema solitario può avere pieno accesso a un ambiente di sviluppo, a condizione che i dati in tempo reale non siano presenti. Possono provare un compito nell'ambiente di sviluppo, eseguire alcuni test, risolvere i bug. Solo quando hanno uno script funzionante lo inviano ad un altro amministratore di sistema per l'approvazione.

Conclusione

Se tutto ciò è fatto, credo che si possa implementare un strong controllo a due uomini con un sovraccarico di circa il 25%. Fare un successo dipende da varie cose (come la manutenzione automatica) che sono comunque buone pratiche. Se un sistema è così sensibile da richiedere il controllo di due persone, è una buona idea anche avere tutte le nozioni di base!

Non l'ho mai visto implementato in un ambiente commerciale o governativo. La cosa più vicina che ho visto è stata una piattaforma bancaria online in cui la maggior parte degli amministratori di sistema non disponevano normalmente di accesso root. Per eseguire un'attività, questa sarebbe prima pianificata in dettaglio, quindi approvata sul sistema di controllo delle modifiche. Per implementare la modifica, sys-admin ha ottenuto l'accesso root per un periodo limitato. Inoltre, vi erano un piccolo numero di amministratori di sistema senior che avevano accesso permanente alla radice, in caso di emergenza. Questa disposizione è molto migliore di quella che vedo in genere, anche se non è sufficiente al controllo a due uomini.

Esiste una tecnica crittografica molto pertinente qui, chiamata condivisione segreta :

Secret sharing (also called secret splitting) refers to methods for distributing a secret amongst a group of participants, each of whom is allocated a share of the secret. The secret can be reconstructed only when a sufficient number, of possibly different types, of shares are combined together; individual shares are of no use on their own.

Quindi una strategia da adottare è:

• Tutte le azioni amministrative richiedono l'autenticazione con una chiave crittografica.
• La chiave è suddivisa in n modi attraverso i tuoi n amministratori, con una soglia di due condivisioni per recuperare il segreto.
• Ogni amministratore deve mantenere la sua condivisione segreta da tutti gli altri.

Non conosco molte implementazioni di condivisione segreta là fuori. Vedi questa domanda per Riferimenti. Vorrei aggiungere questo:

• HashiCorp's Vault è un sistema distribuito client / server per l'archiviazione e il recupero di segreti (ad es. password che devono essere utilizzate da applicqtions). I contenuti del database del Vault sono crittografati con una chiave che non è memorizzata da nessuna parte, ma piuttosto suddivisa in un insieme di condivisioni segrete con numero e soglia configurabili. Per ricostituire la chiave hanno un processo che chiamano unsealing dove i proprietari del numero necessario di azioni devono inserisci la loro condivisione.

Quindi potrebbe essere in grado di cucinare qualcosa con Vault per raggiungere questo obiettivo. Le idee chiave sarebbero:

• Mantieni tutte le credenziali di amministratore all'interno di un'istanza di Vault che è solo non sigillata quando sono necessarie e sigillate immediatamente quando non lo sono;
• Script tutte le tue attività in modo che gli amministratori non vedano mai le credenziali effettive, solo le condivisioni delle loro chiavi principali di Vault.

L'unico modo in cui il controllo di due uomini può essere implementato in modo efficiente senza alcuna possibilità di bypassarlo, è di proteggere fisicamente la risorsa in questione (computer, dati multimediali ecc.) quindi è inaccessibile a meno che 2 persone, tramite la biometria, effettuino l'autenticazione al servizio .

NON consiglierei una regola di 2 uomini per il login come root o simile per un computer, preferirei piuttosto limitarmi in modo tale che il tipo di accesso sia disponibile solo sul posto su un terminale fisico, e quindi quel terminale fisico è semplicemente nascosto in una stanza chiusa (stanza del server o qualsiasi altra cosa) che richiede 2 uomini per l'autenticazione da sbloccare.

Il motivo è che altrimenti un uomo può malintenzionare una backdoor per consentire il controllo di un singolo uomo, oppure i due uomini possono collaborare per ridurre la sicurezza del sistema al controllo di un singolo uomo.

Limitando fisicamente il controllo a due uomini, non è possibile aggirare il sistema, anche se i due uomini collaborano per dare accesso al singolo individuo perché l'altro uomo pensa "è fidato" o qualcosa del genere.

(ovviamente, due mans potrebbero collaborare all'esecuzione di un comando malevolo o altro, ma il fattore importante qui è che non possono collaborare per fornire accesso permanente a un solo uomo)