Le migliori pratiche di sicurezza per lo sviluppo e il rilascio del software?

Gli sviluppatori non dovrebbero mai avere accesso diretto all'ambiente di produzione. Dal punto di vista dell'audit, questo è un grande no-no in quanto ciò pone rischi di frode. Inoltre, se uno sviluppatore commette un errore, può eliminare i sistemi critici che potrebbero avere un impatto elevato sulla tua attività.

La migliore pratica è di avere 4 ambienti separati, Sviluppo, Test, Accettazione e Produzione. Gli sviluppatori possono avere accesso ai test e in alcuni casi all'accettazione, ma MAI alla produzione. Questo è chiamato il principio DTAP:

1. The program or component is developed on a Development system. This development environment might have no testing capabilities.

2. Once the developer thinks it is ready, the product is copied to a Test environment, to verify it works as expected. This test environment is supposedly standardized and in close alignment with the target environment.

3. If the test is successful, the product is copied to an Acceptance test environment. During the Acceptance test, the customer will test the product in this environment to verify whether it meets their expectations.

4. If the customer accepts the product, it is deployed to a Production environment, making it available to all users of the system.

Come detto, se un auditor vede o addirittura ottiene il minimo indizio che uno sviluppatore può avere accesso a un ambiente di produzione, quasi certamente fallirà. Se si desidera eseguire controlli, è meglio farlo da una persona / organizzazione indipendente. Se desideri impostare più processi e normative, dai un'occhiata al COBIT framework.

Assicurati di definire KPI e SLA per avere una forma di potere per far rispettare i tuoi regolamenti.

quindi sono d'accordo con ciò che @lucaskauffman e @terrychia hanno detto finora, ma qui ci sono alcuni suggerimenti che potrebbero esserti utili per migliorare il controllo sull'ambiente di sviluppo. Alla fine dovresti cercare di raggiungere il livello di controllo che menziona Lucas, ma potrebbe essere difficile vendere direttamente così che ci siano alcuni passaggi intermedi che potresti intraprendere.

• Inizia spostando gli sviluppatori dall'accesso in lettura-scrittura alla produzione in sola lettura. Introdurre un processo di controllo delle modifiche in modo che le modifiche ai dati di produzione siano messe in scena e applicate in modo controllato, non da singoli sviluppatori. Se gli sviluppatori devono provare le cose, introducono un ambiente di pre-produzione e provano le cose là fuori.
• Rimuovi l'accesso degli sviluppatori al server. Gestione delle modifiche per tutte le modifiche al codice, gli sviluppatori non dovrebbero avere accesso diretto in scrittura al server di produzione, una delle cose carine su git è che è facile avere una copia del codice quindi spero che non ci debbano essere circostanze in cui il codice diretto le modifiche sarebbero apportate a prod.
• Una volta che le persone lavorano in questo modo, idealmente non dovresti avere persone che lavorano su dati in tempo reale, dovrebbero lavorare su dati campione anonimizzati che riducono i rischi di perdere le informazioni sui clienti. Esistono strumenti per anonimizzare i dati, ma anche qualcosa di semplice come uno script che sostituisce i nomi con Mr Mouse e simili potrebbe aiutare a ridurre l'impatto di qualcuno che toglie una copia del database con loro.
• se riesci ad arrivare fino a questo punto, quindi guarda a fare ulteriori passi avanti (ad esempio modelli di stile COBIT / ITIL)

Il punto fondamentale di tutto questo è che richiederà un buon livello di buy-in dalla tua gestione. tutti questi passaggi costano denaro e rallentano il processo di sviluppo / test a breve termine (a lungo termine probabilmente salveranno l'intera azienda).

Ottenere quel buy-in può essere complicato se la direzione non vede il problema. Suggerirei di cercare storie horror di sviluppatori incontrollati. ambienti, o meglio ancora se ci sono stati problemi in quello in cui stai lavorando, usali come esempi di cose che potrebbero essere evitate aggiungendo un po 'più di processo alle cose.

Per l'amor di dio. Mai esegue test o debug su sistemi e dati di produzione .... Soprattutto dal momento che si tratta di un volume elevato e di un sistema critico ...

Imposta un ambiente di sviluppo adeguato che duplichi un sottoinsieme dei dati di produzione con cui lavorare ... Qualsiasi nuova versione deve essere accuratamente testata dal QA prima di essere trasferita sui sistemi di produzione. Ciò riduce notevolmente il rischio di codici errati che danneggiano dati importanti.

La maggior parte dei membri del team non ha bisogno di accedere all'ambiente di produzione. È possibile e necessario configurare un sistema per la distribuzione automatica del codice dopo che è stato controllato nel VCS e testato ...