È sicuro memorizzare la cronologia delle revisioni sui server di produzione?

4

Attualmente usiamo sul mio posto di lavoro svn export <svn_repo> . Questo richiede molto tempo e ho giocato con l'idea di mantenere la cronologia delle revisioni sul server di produzione in modo da poter semplicemente recuperare gli aggiornamenti.

In pratica stavo pensando di avere una cartella checkout con il codice. Una volta che voglio distribuire ho semplicemente svn up e poi copio il contenuto (senza .svn) in una cartella release sullo stesso server. È sicuro? L'organizzazione con cui lavoro lavora con il governo, quindi la sicurezza è un problema molto grande .

    
posta Johan Hanssen Seferidis 05.02.2016 - 14:49
fonte

3 risposte

7

Mentre leggo questo post, sto tremando. Probabilmente perché ho mangiato troppi carboidrati dopo averli evitati per un po ', e sto vivendo un attacco di ipoglicemia ... ma probabilmente perché l'idea di questo mi terrorizza davvero.

Ricorda, questo è un sito di sicurezza delle informazioni. A volte la risposta che ottieni non è la risposta che vuoi .

  1. Dichiari di lavorare per il governo.
  2. Stai utilizzando il tuo vero nome su questo sito web. Un po 'di scavi mostra esattamente chi è il tuo datore di lavoro, tra le altre cose. Ulteriori ricerche, sono in grado di trovare ulteriori informazioni su altre cose.
  3. Stai pensando a una configurazione potenzialmente insicura, e questo mi porta a preoccuparmi del fatto che potresti essere in grado di toccare i server di produzione in questo modo e checkout / importazione dai server PRODUCTION che potrebbero essere stati colpiti dal malware in precedenza.

Potresti essere ben servito visitando un articolo su Wikipedia su Sicurezza operativa.

Perché questo può essere un problema?

Un ambiente di produzione è solitamente rivolto frontalmente, ovvero ciò che vedranno i tuoi clienti / clienti / utenti. Supponiamo che tu abbia i seguenti ambienti:

  1. sviluppo
  2. Test
  3. Produzione

Il controllo del codice dalla produzione, che avrebbe potuto essere modificato in caso di vulnerabilità sfruttata con successo - nelle tue applicazioni web o nel tuo server web stesso - e quindi eseguirne il debugging a livello locale, significa che potresti finiscono per infettare l'intera azienda.

Il tuo team di sviluppo di solito ha accesso a molte cose importanti. Ora che esegui il debug in locale, potresti riuscire a diffondere malware nascosti nella tua infrastruttura intera ! Sviluppo, test, produzione, ecc. Da lì, il tuo attaccante può fare praticamente tutto quello che vuole.

Hai bisogno di una chiara separazione delle preoccupazioni. Mettere il tuo repository sul tuo server di produzione è solo un problema. Se il tuo server di produzione viene violato, può essere in grado di mitigare il danno se è limitato a se stesso.

Tuttavia, non appena lo lasci sfuggire al suo piccolo ambiente chiuso, potresti trovarti in un mondo di guai. Tieni presente che gli aggressori stanno cercando qualsiasi piccola cosa che possano sfruttare. Questo è il motivo per cui credo sinceramente che non dovresti mettere il tuo SVN sul tuo server di produzione.

Esempio di diagramma Pwnage

Ho creato un diagramma schifoso in MS Paint per spiegarlo meglio. Supponiamo che una volta eseguito il debug, si verifichi un'infezione e inizi la propagazione.

    
risposta data 05.02.2016 - 20:53
fonte
6

Dipende da ciò che mantieni nel repository. Se questo repository contiene solo le stesse informazioni che sono già presenti sul server, un utente malintenzionato che compromette il server non acquisirà nuove informazioni durante l'analisi del repository.

Ma immagina che qualcuno abbia controllato alcune credenziali di autorizzazione (cioè la password, la chiave privata ...) o altre informazioni riservate non pubbliche. Anche se questo è stato rilevato e la modifica è stata ripristinata e non è mai stata pubblicata sul sito pubblico del server, è ancora all'interno del repository. E in questo caso l'attaccante potrebbe ottenere preziose informazioni che altrimenti non sarebbero disponibili sul server.

In sintesi, consiglierei di memorizzare solo le informazioni su un server che ha davvero bisogno di essere lì. Ciò significa che nessun repository di codice e nemmeno strumenti come compilatori o simili. Ognuno di questi potrebbe aiutare un utente malintenzionato a compromettere il server o ottenere ulteriori informazioni.

Once I want to deploy I simply svn up and then copy the contents (without .svn) to a release folder on the same server.

Perché non semplicemente sincronizzare i dati da un checkout locale del repository al server pubblico? rsync è tuo amico.

    
risposta data 05.02.2016 - 15:09
fonte
0

Capistrano utilizza una configurazione simile a quella che descrivi. Ma tutto si riduce a "la tua sicurezza è strong quanto il tuo anello più debole".

Quindi, se proteggi correttamente svn e webserver, ad es. usando l'autenticazione della chiave ssh, tale configurazione dovrebbe essere solida.

E poiché Capistrano utilizza l'inoltro dell'agente, non vi sono informazioni di autenticazione sul server SCM sul server web.

    
risposta data 05.02.2016 - 22:03
fonte

Leggi altre domande sui tag