La segregazione dei doveri è un requisito?

Come il libro O'Reilly, i dettagli DevOpsSec nel capitolo 2, Separation of Duties (SoD) è un componente importante degli standard di sicurezza delle informazioni: ISO 27001, NIST SP 800-53, COBIT, ITIL, ecc. parte dei requisiti normativi per (almeno): FFIEC, Sarbanes-Oxley Section 404, SSAE 16, GLBA, MiFID II e PCI DSS.

Gli sviluppatori concordano sul fatto che gli ambienti di sola lettura come Immutable Infrastructure (cioè il "Movimento No-SSH") sono le migliori pratiche. Vedrai persino eroi degli sviluppatori come Martin Fowler che prescrivono direttamente il concetto di PhoenixServer, se non il completo ImmutableServer modello.

Tuttavia, in un'organizzazione dove sono instillate le Tre linee di difesa (3LoD) (ad esempio, società di servizi finanziari o ovunque che abbia una funzione di controllo interna e / o esterna), anche la funzionalità di sola lettura potrebbe non essere sufficiente per soddisfare i requisiti (e superare un controllo).

Il libro DevOpsSec formula le seguenti raccomandazioni oltre a Immutable Infrastructure e SoD (che raccomanda anche):

• Limita l'accesso ai dati e alla configurazione non pubblici.
• Rivedi attentamente il codice di registrazione per assicurarti che i registri non contengano dati riservati.
• Controlla e rivedi tutto ciò che gli sviluppatori fanno nella produzione: ogni comando che eseguono, ogni pezzo di dati che hanno guardato.
• Hai bisogno di un controllo dei cambiamenti in atto per tenere traccia delle eventuali modifiche codice o configurazione effettuata al di fuori della consegna continua conduttura.
• Potrebbe anche essere necessario preoccuparsi dell'esfiltrazione dei dati: assicurarsi che gli sviluppatori non possono rimuovere i dati dal sistema.

Un altro controllo di compensazione è Rotation of Duties (RoD), che spesso accompagna SoD. Se si fanno ruotare le persone ogni tanto e si evitano situazioni di collusione, questo può compensare e sostenere gli altri controlli forti. Un pezzo finale sarebbe l'integrità di due parti in cui un sistema completo di controllo e bilanciamento include la possibilità di impedire gli addetti ai lavori di fiducia attraverso il paradigma "No Dark Corners".

Ecco anche alcune nuove prospettive di Ben Tomhave, un esperto del settore su DevOps e sicurezza delle applicazioni - link

Come professionista della sicurezza delle informazioni, sono d'accordo con la valutazione del dipartimento di sicurezza IT. Le seguenti best practice sulla sicurezza spesso richiedono che le persone comprendano l'intento dietro tali pratiche, in questo caso una corretta separazione delle funzioni, SoD

Dato che gli sviluppatori della tua azienda non sembrano essere sufficientemente motivati / capiscono i benefici del SoD, vorrei spiegare loro come il rispetto dei SoD potrebbe trarne beneficio. Dai un'occhiata a cosa è successo all'OP in questo caso. Gli sviluppatori ragionevoli dovrebbero capire se non hanno accesso alla produzione, e assumendo che gli altri 2 elementi di AAA la sicurezza dell'autenticazione e della responsabilità sta lavorando, non possono essere biasimati se un problema sorge dal loro codice dopo lo sviluppo è stato completato.

Gli sviluppatori dovrebbero anche capire che, mentre essi possono essere responsabili e mai maliziosamente causare danni alle informazioni di dati finanziari / carta di credito in ambiente di produzione violando un principio CIA, altri sviluppatori non possono essere essere responsabile. Se si verifica un incidente con i dati finanziari sensibili in produzione, possono esserci multe significative per l'azienda insieme a una reputazione danneggiata che causa la perdita di entrate future , in base alle dimensioni dell'azienda , può mettere in dubbio la sopravvivenza del business, influire direttamente sulla carriera dello sviluppatore / mezzi di sussistenza.

Infine, vorrei approfondire su un punto dell'eccellente risposta fornita da @atdre che dovresti avere controlli di risposta agli incidenti correttivi per integrare i controlli di gestione dei cambiamenti. Se si rilevano modifiche non autorizzate apportate ai dati di produzione dai programmi di monitoraggio (ad es. TripWire), è necessario disporre di controlli di compensazione in atto per il ripristino del danno provocato (ad es. Utilizzo di un ripristino dai backup testati).