Perché estrarre l'aggiornamento dal server di produzione piuttosto spingendoli dal server di sviluppo?

La preoccupazione principale non è dare agli sviluppatori l'accesso in scrittura ai sistemi di produzione. Ciò va bene con il principio di dare a qualcuno la minima quantità di privilegi necessari per eseguire un'attività.

Dare agli sviluppatori accesso in scrittura ai sistemi di produzione comporta alcuni rischi. Le macchine per gli sviluppatori sono utilizzate per navigare in rete. È previsto perché gli sviluppatori devono consultare la documentazione, scaricare il software, utilizzare StackOverflow, ecc. Esiste una leggera possibilità che vengano compromessi dal malware. Questo naturalmente comporta un disastro se lo stesso sviluppatore ha accesso in scrittura alla produzione. In secondo luogo, dare l'accesso in scrittura alla produzione agli sviluppatori potrebbe aprirli alla tentazione di spingere direttamente alla produzione, ignorando cose come avere sistemi di revisione, assicurando che tutti i commit superino i test unitari ecc. Questo potrebbe portare a un codice sciatto che si apre ulteriormente l'applicazione per il compromesso.

Nel caso in cui il server di sviluppo sia compromesso, sarebbe più facile accedere alla produzione (lo sviluppo a volte ha requisiti di sicurezza inferiori).

Questo è anche lo spirito di Segregation of Duties. Si tratta di un metodo di sicurezza classico per gestire il conflitto di interessi, la comparsa di conflitti di interesse e le frodi. Limita la quantità di potenza detenuta da qualsiasi individuo. Gli sviluppatori non sono mai ammessi alla produzione in quanto vi sarebbe un rischio di frode (dal punto di vista di un audit finanziario). Il codice non dovrebbe mai essere estratto dalla produzione senza revisione (principio dei quattro occhi).

Ci sono delle eccezioni a questa regola in caso di emergenza, ma queste sono usate solo in circostanze estreme quando c'è rischio di continuità aziendale. E anche allora questi account saranno pesantemente controllati sull'utilizzo durante e dopo che lo sviluppatore ha avuto accesso. Questi account sono normalmente sempre bloccati e possono essere sbloccati solo dopo l'approvazione formale del business e l'approvazione da parte dell'ufficio sicurezza e del responsabile IT responsabile.

Precisazione della domanda

La maggior parte delle risposte finora fa presupporre che il passaggio citato nella domanda si riferisca a modifiche originate dalle workstation dei singoli sviluppatori.

Al contrario, il passaggio si riferisce alla propagazione del cambiamento tra un server di sviluppo e un server di produzione. L'autore avrebbe dovuto usare una terminologia più appropriata per il caso d'uso più comune: propagare le modifiche da un server "testing" o "staging" a un server di produzione. Anche il fraseggio nel passaggio citato è imbarazzante, ma l'essenza è che il processo di propagazione del cambiamento dovrebbe sempre essere avviato dal server di produzione - cioè, le modifiche vengono "tirate" dal server di sviluppo , non "spinto" dal server di sviluppo / testing / staging.

La motivazione

La logica è semplice: nei casi più , ha molto più senso dare a un ambiente di produzione l'accesso a un server di sviluppo (o di testing / staging) rispetto al contrario. Se il server di produzione è compromesso, la probabilità di danno aggiuntivo derivante dall'attaccante "scavalcando" il server di sviluppo è minima (almeno se vengono rispettate le best practice e non c'è nulla di "sensibile" sul server di sviluppo, particolarmente nel modo di credenziali ad altri sistemi o dati "reali"). Inutile dire che le credenziali per altri sistemi interni, dati reali dei clienti, ecc., Non dovrebbero mai essere propagate a un server di sviluppo.

A correlati a parte

Nei casi in cui un problema spinoso richiede assolutamente l'accesso ai dati di produzione, è necessario prestare particolare attenzione alla "sandbox" dei dati in un sistema isolato e offline con accesso estremamente limitato. I dati su un tale sistema dovrebbero essere distrutti immediatamente dopo la risoluzione del problema. Per i problemi che richiedono l'accesso ad altri sistemi da riprodurre, come un server Web che richiede l'accesso a un'istanza data warehouse, è necessario compiere ogni sforzo per "deridere" qualsiasi funzionalità fornita dalla dipendenza ed eliminare la necessità di connettere i sistemi .

Eccezione alla regola

Un'eccezione alla "regola" che l'autore descrive è quando il server di sviluppo si trova all'interno del firewall e il server di produzione si trova nella DMZ. In questi casi, potrebbe essere che il server di produzione non possa avviare la comunicazione con il server di sviluppo (rendendo così impossibile la strategia "pull"), ma il server di sviluppo è in grado di avviare la comunicazione con il server di produzione. In tali topologie, in cui questa iniziazione a senso unico è sottoprodotta, potrebbe essere necessario spostare i cambiamenti dallo sviluppo alla produzione.

In tali casi, le credenziali necessarie per connettersi dallo sviluppo alla produzione dovrebbero essere altamente protette e non dovrebbero mai essere archiviate sul server di sviluppo (ad es., sotto forma di una chiave SSH senza password). Inoltre, chiunque sia autorizzato a connettersi al server di sviluppo e avviare un push alla produzione dovrebbe essere costretto ad accedere al proprio account su entrambi i sistemi (gli account non dovrebbero mai essere condivisi tra gli utenti, così facendo compromette la responsabilità).

Se per completare la propagazione è richiesto l'accesso a livello di root su entrambi i sistemi, dovrebbe essere implementata un'implementazione sudo, se possibile, in quanto tale meccanismo migliora enormemente la responsabilità.

Contemplare cosa succede se qualcuno contraffa il tuo server di sviluppo. Se il prod server è configurato per accettare l'aggiornamento, è completamente di proprietà.

Se vengono apportate modifiche, piuttosto che spinte. è più difficile da falsificare.