Consulente di amministrazione Linux remoto - Best Practice [chiuso]

Stiamo impegnando un consulente in India come amministratore Linux. Non lo conosciamo bene e ha bisogno dell'accesso root a tutti i nostri server per fare il suo lavoro (incluso un audit di sicurezza).

Qual è la migliore pratica per consentire a un consulente remoto di svolgere tale lavoro in modo tale da essere protetti da attività maligne?

Grazie in anticipo.

Non farlo . Inoltre, sei in pericolo di inettitudine quanto la malizia da ciò che ho visto nel modo tipico in cui le aziende gestiscono questo.

Vorrei dire che probabilmente ci sono grandi amministratori di sistema là fuori in India, ma il modo in cui molte aziende fanno le cose è terribile.

Se stai attraversando una carrozzeria, probabilmente stai vedendo un taglio abbastanza grande andare da loro e è improbabile che molti di loro abbiano controllato correttamente i loro dipendenti. Ne ho parlato con tre, uno dei quali ho lavorato e nessuno di loro ha fatto interviste tecniche.

Quindi, se devi assumere qualcuno da remoto, per l'amor di Dio, intervistalo tu stesso e assicurati che conosca il suo lavoro. L'amministrazione del sistema è troppo importante per consegnare ciecamente a qualcuno

Ora che ho gestito la parte di "inettitudine",

L'amministrazione è una frase piuttosto generica. E qualcuno con accesso root può fare qualsiasi cosa . Ora, personalmente penso che creare un account per l'amministratore e dargli la possibilità di elevarsi attraverso sudo sia un'idea migliore (che il tuo sistema di gestione della configurazione dovrebbe gestire se hai molti server). Detto questo, anche questo si basa su una certa fiducia. Ci sono così tante storie là fuori del danno puro che un amministratore di sistema scontento può fare. Cambia tutte le tue password? Sicuro che alla fine potresti entrare, ma non è banale, e probabilmente costerebbe più di quanto stai risparmiando.

Quindi, considera un locale. In caso contrario, considera qualcuno che ti sei controllato e che hai assunto direttamente .

Come è stato menzionato, non farlo.

L'unico modo in cui sarai in grado di proteggerti è facendo qualcosa del genere:

1. Insistere affinché il consulente utilizzi un sistema di gestione della configurazione di propria scelta.
2. Il consulente scriverà manifesti di gestione della configurazione per le azioni da completare.
3. Il consulente testerà i manifest su un sistema di test.
4. Quando è pronto, il consulente eseguirà il commit della configurazione in un repository di codice.
5. Tutte le modifiche vengono esaminate da un membro del personale o da un altro consulente che non ha assolutamente alcuna relazione con il primo e non ha modo di contattarli.
6. Una volta approvate, le modifiche vengono applicate al server da te o da un membro del tuo staff. Il consulente originale non dovrebbe avere accesso a nessuno dei tuoi sistemi.

Come dovrebbe essere chiaro, questo è un processo molto goffo e inefficiente, ma se insisti nell'accettare il lavoro di un individuo non fidato, questo è un modo per gestire le cose.

Come ho raccomandato, però, è molto meglio assumere un individuo conosciuto e di fiducia.

Qual è la migliore pratica per consentire a un consulente remoto di svolgere tale lavoro in modo tale da essere protetti da attività maligne?

Dal punto di vista legale: due diligence in anticipo e rigide sanzioni per violazione del contratto.

Si inizia con le solite buone pratiche di assunzione che si applicano anche quando si assumono personale locale (e / o fornitori di servizi) che includono il controllo dei fatti sul curriculum fornito, la richiesta di trascrizioni e numeri di certificazione dell'istruzione, il controllo e la chiamata dei loro riferimenti, colloquio, forse anche un controllo in background o uno screening di sicurezza ecc. ecc.

Quindi applica la carota : paga il valore equo, offri lavoro attraente, colleghi fantastici, buone condizioni di lavoro e benefici ecc. ( Se paghi le noccioline ottieni scimmie. )

E il bastone : violare i termini del contratto di lavoro / servizio e noi maleremo i nostri avvocati su di te e ti lasceremo in bancarotta!

Sfortunatamente entrambi i punti precedenti diventano sempre più difficili quando si attraversano confini e fusi orari.

Una volta deciso di assumere qualcuno:

• direttive e politiche chiare, le persone dovrebbero essere consapevoli di ciò che dovrebbero e potrebbero non fare.
• si applica il principio dell'accesso minimo, che rende difficile per le persone (accidentalmente o intenzionalmente) fare cose che non dovrebbero. Per l'amministratore di sistema tipico spesso ciò significa ancora pieno accesso, ma un revisore della sicurezza, ad esempio, non dovrebbe aver bisogno dell'accesso completo dell'amministratore, ma può semplicemente richiedere agli amministratori esistenti di eseguire uno script per suo conto che raccolga i dettagli di cui ha bisogno per fare il suo rapporto. Tale sceneggiatura può essere facilmente verificata in anticipo.
• fidarsi ma verificare. Chiedi semplicemente al personale esistente di controllare il lavoro di un nuovo falegname e, come sempre, di raccogliere informazioni di audit.
• ecc ecc.

Questa domanda descrive in dettaglio ciò che di solito chiedo ai miei clienti di stabilire per me l'accesso remoto, che potrebbe essere un punto di partenza anche per te.

C'è un metodo sistemico per proteggerti che mi viene in mente, che non ho visto menzionato.

Ospita le tue istanze Linux come VM su un hypervisor di virtualizzazione (VMware, Xenserver, Hyper-V, ecc.).

NON concedere all'amministratore remoto l'accesso amministrativo all'hypervisor. L'amministratore remoto otterrebbe l'accesso root solo alle macchine virtuali stesse.

Implementare un sistema di backup basato su hypervisor (Unitrends, Veeam, vSphere Data Protection, ecc.)

Conserva almeno un'istantanea al giorno di ogni VM Linux, andando indietro nel tempo che ritieni necessario.

NON concedere all'amministratore remoto l'accesso in scrittura ai repository di backup.

Se esegui queste operazioni, avrai istantanee di backup di ogni istanza di Linux su cui l'amministratore remoto non ha alcun controllo. Se l'amministratore remoto fa qualcosa di vizioso, intenzionalmente o accidentalmente, puoi sempre montare un backup prima che si verifichi il nodo per valutare cosa è successo e possibilmente ripristinare uno stato pulito.

Questo non sarà una prova contro un attacco del canale laterale dell'hypervisor, che potrebbe potenzialmente essere montato all'interno di una VM a cui l'attaccante ha accesso come root.

Se i backup non vanno abbastanza indietro nel tempo, questo non ti proteggerà.

Devi fidarti completamente di chi controlla l'hypervisor e l'infrastruttura di backup.

Se lo stai facendo nel cloud (AWS, Azure, ecc.), I dettagli dell'implementazione differiranno, ma il concetto generale sarebbe lo stesso.

In sostanza, dividi le responsabilità tra le parti che non sono partner commerciali tra loro, oltre ad assumere solo persone di cui ti fidi.

Dagli il suo account utente. Quindi scopri esattamente a cosa deve accedere e concedi solo quell'accesso, ma nient'altro. Ad esempio, se deve riconfigurare un server Web Apache, utilizzare un ACL per consentirgli l'accesso in scrittura ai file di configurazione di Apache e configurarlo sudoper consentirgli di riavviare il servizio Apache ma non eseguire altri comandi come root. Come sempre, conserva i backup di tutto ciò a cui gli stai dando accesso (in questo caso, i tuoi file di configurazione di Apache).