Come mitigare il rischio di una violazione della sicurezza del servizio di integrazione continua?

Hai 2 punti che possono essere compromessi: accesso al repository git e al servizio CI. Stai usando CI SaaS, perché qual è la differenza se il tuo deploy server o la tua macchina della CI viene compromessa? Possono entrambi spingere il codice.

Se si dispone di un servizio CI remoto, è possibile anche creare un server di distribuzione e inviare tale build effettiva al servizio CI. E quando passa quella build, spingerlo alla produzione. In questo modo sai che hai testato la versione esatta che viene distribuita.

Condizioni di gara: CI passa il codice. Qualcuno controlla il nuovo codice in git. La distribuzione della macchina viene segnalata dall'elemento della configurazione e crea con il codice non testato e la spinge alla produzione.

Sembra che tu stia principalmente spostando il problema. Il server CI utilizzato per avere le credenziali per inviare nuove installazioni al server Heroku, ora è il server di distribuzione.

Quindi la grande domanda da parte mia è: qual è la differenza di sicurezza tra il servizio CI e il server di distribuzione? Uno è ospitato esternamente? C'è un motivo per cui ti fidi di uno più dell'altro. Sono le credenziali che danno accesso al server Heroku che danno maggior rischio.

Nel NUOVO framework, vorrei fare queste domande:

• Qual è la probabilità che il codice possa essere manomesso sul server Git?

• Esiste la possibilità che un "ping" illegittimo sul server di distribuzione causi problemi? La condizione di gara @roxOr menziona è un caso. C'è anche il pensiero che se un server CI viene manomesso, potrebbe essere attivato per inviare un ping che induca il server di distribuzione a inserire codice non funzionante sul server Heroku. O ... qual è il livello di autenticazione richiesto su questo ping? Può essere inviato da qualsiasi luogo da chiunque? Quindi l'attaccante non ha bisogno di attaccare il server CI per attivare una distribuzione errata.

• esiste la possibilità che il server di implementazione possa essere violato? questo è ora il tuo grande vantaggio: può ottenere la tua proprietà intellettuale (il codice) e distribuire qualsiasi malware desideri. Quindi ha bisogno della protezione più severa.

• Esiste un modo per un agente esterno di ottenere le credenziali utilizzate per accedere a Heroku e accedervi direttamente? Nel qual caso non importa come si distribuisce il codice, l'hacker può spingere il codice come preferisce.

• C'è una possibilità che il networking possa essere manomesso - un buon attacco potrebbe essere quello di forzare il reindirizzamento del server di deploy dal sito hub git legittimo a una fonte scelta dall'attaccante. Quindi, quando viene ricevuto un ping legittimo dal server CI, il server di distribuzione distribuisce il codice creato dall'utente malintenzionato anziché il codice testato.

Nessun sistema è mai "perfetto", quindi la grande domanda di solito si riduce a quale tipo di attacco ti aspetti e quale pensi che potrebbe essere il loro motivo. Dipendenti scontenti, spionaggio aziendale, punk casuali e criminali informatici che cercano di utilizzare il tuo sito come host di malware avranno ciascuno i propri obiettivi e ognuno avrà capacità diverse. Aiuta a riflettere su cosa vuoi proteggere prima di aggiornare la tua architettura.