Quali processi o strumenti abilitano la segregazione dei compiti quando gli ingegneri implementano ed eseguono il codice?


18

In ambienti altamente regolamentati, come il settore dei servizi finanziari, la segregazione dei compiti è un meccanismo essenziale per evitare la collisione tra persone con responsabilità di sviluppo e privilegi di produzione.

Tradizionalmente questo ha significato che gli sviluppatori sviluppano il codice e poi lo passano alle operazioni, tuttavia in molti modelli operativi DevOps la separazione tra sviluppo e operazioni è, come minimo, offuscata:

  • Nell'ambito dell'ingegneria dell'affidabilità del sito di Google , o pratica SRE, esiste una funzione SRE separata all'interno di Google, tuttavia, gli sviluppatori vengono portati a sostenere gli SRE in tempi di elevato carico operativo.

  • Nel modello "Costruisci, esegui" non esiste una funzione operativa separata.

Dopo aver trascorso mesi a esaminare le cause profonde di un meccanismo di segregazione dei doveri, sembra esistere prevalentemente per soddisfare la sezione 404 di Sarbanes Oxley : valutazione della gestione dei controlli interni:

(a) Regole richieste. La Commissione prescrive norme che richiedono che ogni relazione annuale richiesta dalla sezione 13 (a) o 15 (d) del Securities Exchange Act del 1934 contenga una relazione di controllo interno, che deve:

(1) dichiarare la responsabilità della direzione per stabilire e mantenere una struttura e procedure di controllo interno adeguate per l'informativa finanziaria; e

(2) contiene una valutazione, alla fine dell'esercizio fiscale più recente dell'emittente, dell'efficacia della struttura di controllo interno e delle procedure dell'emittente per l'informativa finanziaria.

(b) Valutazione e comunicazione del controllo interno. Sulla valutazione del controllo interno richiesta dalla sottosezione (a), ogni impresa di contabilità pubblica registrata che redige o emette la relazione di revisione contabile per l'emittente deve attestare e riferire sulla valutazione effettuata dalla direzione dell'emittente. Un attestato rilasciato ai sensi della presente sottosezione deve essere redatto conformemente alle norme per gli incarichi di attestazione emessi o adottati dal Consiglio. Qualsiasi attestazione di questo tipo non deve essere oggetto di un incarico separato.

Sulla base dei commenti è importante mettere in evidenza un paio di ipotesi che sto formulando:

  • Prendo principalmente in considerazione i servizi finanziari del mercato di massa, vale a dire i volumi delle transazioni sono alti ma relativamente bassi. Ciò sarebbe in contrasto con i servizi finanziari commerciali che hanno un diverso profilo del valore delle transazioni.
  • L'offerta online di un istituto finanziario sarà composta da molti componenti che presentano diverse considerazioni sul rischio:
    • Sposta denaro : sposta denaro tra conti o trasferimenti tra conti di proprietari diversi. Un'operazione che deve prendere in considerazione i paesi contro il riciclaggio di denaro, la protezione dalle frodi e l'embargo per citarne alcuni.
    • Acquisizione del cliente - Meno "rischioso" in quanto ha bassi volumi di transazione rispetto a Move Money ma ha ancora bisogno di considerazione.
    • Internet Banking - Copre una vasta gamma di servizi con vari livelli di rischio, Move Money sarebbe considerato parte di questo.
  • Concepibilmente un approccio diverso potrebbe essere adottato per ciascuno a seconda del rischio, tuttavia, nell'interesse di mantenerlo semplice, sto lavorando a una soluzione che si applicherebbe ad alcune delle operazioni più rischiose.

TL; DR : E 'la responsabilità della gestione per garantire che adeguati controlli interni sono in atto che sono conformi alla Securities and Exchange Commissione regolamenti .

Sarbanes Oxley 404 è normalmente soddisfatto attraverso il completamento di una valutazione dei rischi top-down, parte della quale valuterà il rischio di collusione e proporrà strategie di mitigazione.

All'interno di un'azienda che utilizza la pratica e la cultura DevOps, in cui gli sviluppatori hanno regolarmente accesso sia al controllo delle fonti che alla produzione, come è possibile ottenere la Segregazione dei compiti o, più in generale, come mitigare il rischio di collusione.


L'idea principale alla base di un'organizzazione devops è quella di rendere tutti i membri del Team responsabili di ciò che accade nella produzione, non ci può essere separazione dei compiti. Ciò significa principalmente che questo tipo di organizzazione non può essere realmente utilizzato quando ci sono esigenze normative per questa separazione.
Tensibai,

@Tensbai Non sono d'accordo fondamentalmente con l'affermazione che DevOps è incompatibile con Segregation of Duties. Le leggi non sono prescrittive per quanto riguarda le modalità dei controlli, né i regolatori impongono un processo predefinito alle banche e ai servizi finanziari. Spetta in gran parte all'organizzazione identificare ciò che è appropriato ed essere totalmente trasparente con i regolatori e i loro revisori nominati. Ad esempio, ING e Barclays hanno adottato le pratiche DevOps per consentire loro di accelerare la capacità di offrire valore ai propri clienti.
Richard Slater,

Sì, si dedicano a soggetti non vincolati alla separazione normativa e hanno sfruttato l'automazione su una tradizionale organizzazione basata su silo per soggetti soggetti a restrizioni (che in realtà sono pochissimi). Hanno solo due tipi di organizzazioni a seconda del tipo di operazioni che il software eseguirà
Tensibai,

Non esiste una "Separazione normativa", gli statuti / le leggi e gli organi regolatori non impongono la separazione sugli istituti finanziari, ma impongono la responsabilità della direzione di disporre di "Controlli appropriati" per la gestione del rischio finanziario. Allo stesso modo in cui Agile ha portato lo sviluppo del software da lunghi cicli a piccoli cicli, DevOps sta portando le operazioni in piccoli cicli, DevOps nei servizi finanziari deve trovare un modo per portare la Segregazione dei compiti in piccoli cicli, ad esempio creando una pipeline di CD che applica "controlli appropriati" come la revisione tra pari e la promozione basata sull'approvazione.
Richard Slater,

1
@ Pierre.Vriens sì, l'ampia domanda è nel titolo, ho cercato di ampliarlo facendo alcune ipotesi. È probabile che i ruoli facciano parte della soluzione così come cose come Break-Glass e Privileged Account Management. Ruoli e responsabilità sono un concetto interessante in DevOps / Agile, in cui una volta avevi uno sviluppatore Java, uno sviluppatore F / E, un progettista, un PM, un ingegnere di costruzione, un responsabile del rilascio e un ingegnere di Ops: ora hai un gruppo di persone che possono indossare cappelli multipli - squadre interfunzionali composte da "ingegneri" che possono specializzarsi ma alla fine condividere la responsabilità.
Richard Slater,

Risposte:


8

La tua domanda non sembra fare ipotesi sulla piattaforma / sistema operativo in questione. Questo è il motivo per cui potrebbe avere senso aggiungere una risposta su come ciò viene generalmente fatto / affrontato in un ambiente mainframe, in cui gli "ingegneri" (come nel titolo della domanda) sono in realtà gruppi di persone erano dozzine (forse centinaia) di persone coinvolti. La mia risposta si basa sull'utilizzo del prodotto SCM in cui ho più familiarità (non sono sicuro che sia necessario per rivelare il nome del prodotto).


1. Architettura


Ecco i punti salienti di come risponderei alla tua domanda:

  • Tutto il codice (e relativi artefatti come eseguibili, ecc.) È archiviato in file che, insieme, è ciò che chiamiamo struttura della libreria .
  • Per ogni ambiente su ciascun sistema di destinazione (possibilmente remoto), esiste un server (un "task avviato" nel linguaggio mainframe), che si occupa di TUTTI (ripeti: TUTTI) gli aggiornamenti a qualsiasi cosa nella struttura della libreria. Ci sono alcune eccezioni (come i responsabili della sicurezza o il team di gestione dello spazio), ma a parte questo, nessuno (ripeti: nessuno) è autorizzato ad applicare aggiornamenti a qualsiasi file all'interno di quella struttura di libreria. In altre parole: il server ottiene l'autorità di aggiornamento esclusiva per l'intera struttura della libreria . Attenzione: le persone OPS andranno in rovina se entrerai per limitare il loro accesso (all'inizio resisteranno ...), quindi assicurati di essere coperto da alti dirigenti (CxO) per imporre quelle regole di accesso ...
  • Il software reale cambia il mio consiste in un singolo componente (una piccola correzione di codice nel mezzo della notte ...), oppure può anche essere centinaia o migliaia di fonti, file eseguibili o qualunque altro artefatto (durante un fine settimana di rilascio). Per renderle gestibili, le cose che dovrebbero essere spostate (più o meno) insieme, allo stesso tempo, sono raggruppate insieme in quello che viene chiamato un pacchetto di modifica del software .

Tenendo presente quanto sopra, qualsiasi tipo di aggiornamento da applicare dal server alla struttura della libreria, sarà possibile solo attraverso un flusso di lavoro ben definito, che chiamiamo il ciclo di vita di un pacchetto di modifica del software (SDLC se preferite). Per eseguire effettivamente i vari passaggi di quel flusso di lavoro, questo è ciò che serve per realizzarlo:

  • Solo il server eseguirà i passaggi richiesti (e preconfigurati).
  • Il server eseguirà solo un passaggio specifico (= aggiorna qualcosa da qualche parte nella struttura della libreria), dopo che le approvazioni richieste (da parte degli esseri umani) sono state raccolte per eseguire tale passaggio.
  • Le approvazioni possono essere fornite solo dagli utenti che hanno un ruolo che consente loro (= autorizzazione) di rilasciare tali approvazioni.


2. Ruoli e autorizzazioni


Il server assicurerà che l'utente che cerca di far accadere qualcosa (come "approva qualcosa") sia in grado di farlo solo se le autorizzazioni dell'utente sono appropriate. Quella parte è facile. Ma non vuoi usare il sistema SCM per amministrare tutte quelle autorizzazioni per tutti gli utenti coinvolti, ecco cosa appartiene al tuo sistema di sicurezza (non al sistema SCM!), In modo da poter adattare il tuo flusso di lavoro (nel tuo sistema SCM) per controllare quelle autorizzazioni ogni volta che è necessario. I passaggi seguenti forniscono ulteriori dettagli al riguardo.

Passaggio 1: configurare le autorizzazioni (nel sistema di sicurezza)

  • Definire le entità di sicurezza nel proprio sistema di sicurezza, con nomi ben definiti per tali entità. Alcuni esempi (aggiungine altri simili per soddisfare le tue esigenze):

    • PrmUnit, utilizzato per ottenere l'autorizzazione a richiedere un Promuovi per dire Test di unità .
    • PrmQA, Utilizzato per ottenere il permesso di richiedere un Promuovere dire Qa -testing (supponiamo che questo è il più alto livello di test).
    • PrdEnduser, utilizzato dagli utenti finali coinvolti in un certo livello di test, per indicare che sono soddisfatti dei risultati prodotti da un qualche tipo di test. E per questo motivo, quegli utenti finali concordano sul fatto che il cambiamento proceda nella struttura della biblioteca.
    • PrdRelmgnt, Utilizzato dai gestori di rilascio per autorizzare un attivazione della produzione (= ultimo / più alto livello nella struttura della libreria).
  • Definisci gruppi di utenti nel tuo sistema di sicurezza. Alcuni esempi (aggiungine altri simili per soddisfare le tue esigenze):

    • GrpDevs, che (diciamo) corrisponde ai tuoi sviluppatori (probabilmente più di solo 1).
    • GrpEnduser, che (diciamo) corrisponde ai tuoi utenti finali (almeno 1, preferibilmente con utenti più simili).
    • GrpRelMgnt, che (diciamo) corrisponde ai gestori delle versioni (almeno 1, preferibilmente qualche altro utente).
  • Concedere le autorizzazioni , anche utilizzando il proprio sistema di sicurezza, per consentire l'accesso a " entità di sicurezza " selezionate per " gruppi di utenti " selezionati. Per continuare l'esempio sopra, ecco cosa sembra appropriato (adattarsi alle proprie esigenze):

    • Il gruppo ha GrpDevsaccesso a (solo!) Entità di sicurezza PrmUnit.
    • Il gruppo ha GrpEnduseraccesso a (solo!) Entità di sicurezza PrdEnduser.
    • Il gruppo ha GrpRelMgntaccesso a (entrambi!) Entità di sicurezza PrmQAe PrdRelmgnt.

Passaggio 2: configurare il flusso di lavoro (nel sistema SCM)

Dopo che le autorizzazioni sono state configurate nel sistema di sicurezza (come nel passaggio 1), tutto ciò che resta da fare nel sistema SCM è configurare il modo in cui i vari passaggi del ciclo di vita corrispondono alle entità di sicurezza correlate nel sistema di sicurezza. Cioè, solo quegli utenti che hanno l'accesso appropriato all'entità di sicurezza richiesta, sono autorizzati a richiedere al server di eseguire il passaggio corrispondente nel flusso di lavoro.

Ecco alcuni esempi di come configureresti il ​​tuo sistema SCM per realizzare un po 'di magia:

  • Se un utente ha accesso a PrmUnit, allora tale utente è autorizzato a richiedere un Promuovi a Test di unità . Ovviamente, gli utenti del gruppo GrpDevssono gli utenti autorizzati per questo (nota: non, ad esempio, gli utenti del gruppo GrpRelMgnt).
  • Se un utente ha accesso a PrmQA, allora tale utente è autorizzato a richiedere un test di promozione al QA . Ovviamente, gli utenti del gruppo GrpRelMgntsono gli utenti autorizzati per questo (nota: non, ad esempio, gli utenti del gruppo GrpDevso del gruppo GrpEnduser).
  • Se un utente ha accesso a PrdEnduser, allora tale utente è autorizzato ad autorizzare la modifica andando avanti nella struttura della libreria (che di solito è un prerequisito per gli utenti del gruppo GrpRelMgntper poter anche rivedere una modifica). Ovviamente, gli utenti del gruppo GrpEndusersono gli (unici) utenti autorizzati per questo.
  • Se un utente ha accesso a PrdRelmgnt, allora tale utente è autorizzato ad autorizzare un'Attivazione in produzione (= l'ultimo / il livello più alto nella struttura della libreria).


3. Aspettatevi l'inaspettato e preparatevi


Quanto sopra è solo un progetto, che si spera aiuta a capire come alla fine è il server a occuparsi della separazione dei compiti ... purché tu abbia il CxO che ti copra per imporre alcune regole di accesso che non piaceranno a tutti.

Per completare l'immagine come spiegato sopra, il server crea una traccia di controllo (registrazione) di tutto ciò che sta accadendo nel sistema. In modo che in qualsiasi momento, sia sempre possibile rispondere a domande come

Che cosa è successo quando e perché e quale utente autorizzato l'ha effettivamente approvato ... in anticipo?

Ma probabilmente la parte più difficile è avere a disposizione strumenti di reporting adeguati (e sapere come usarli). Almeno per soddisfare (facilmente) le richieste dei revisori IT (le loro domande possono essere molto impegnative). Ma anche per indicare i registri di registro rilevanti nel tuo sistema SCM per rispondere a tutti i tipi di domande "Cosa è successo" in situazioni di crisi in cui (parte della) produzione è in calo.


PS: lascio al giudizio di tutti se la mia risposta è sì o no conforme a DevOps.


Sembra un'implementazione di base della valutazione del rischio dall'alto verso il basso, non capisco come possa rispondere alla domanda su come ciò possa essere implementato in modo devops in cui gli sviluppatori avrebbero i diritti di innescare il passaggio "distribuire". L'idea è che non puoi farlo in un'organizzazione Devops?
Tensibai,

@Tensibai "se" gli sviluppatori avrebbero l'autorizzazione (ruolo) di (ad esempio) l'approvazione finale per il prod (che in genere NON hanno in tali organizzazioni), tale server (attività avviata) avvierebbe la distribuzione. E secondo il titolo della domanda, penso che questa sia "una" possibile risposta. Tuttavia, ci si potrebbe chiedere se questo è ciò che chiameremmo un'organizzazione DevOps, ma so che ai revisori piace davvero questo tipo di segregazione dei compiti "configurabile" (ad esempio: a quattro occhi e variazioni di ciò). Forse Richard può aiutarci con il suo punto di vista su questo?
Pierre.Vriens

1
Concordo sul fatto che ai revisori piacerà assolutamente, mi è sfuggito il modo in cui ciò si collega / si adatta all'esplosione dell'accesso, che di solito non piace ai revisori quando l'elenco contiene più di 6-7 persone. Dire che non va bene è una risposta assolutamente valida IMHO.
Tensibai,

1
Grazie per aver dedicato così tanto tempo a una risposta. In realtà sto pensando di implementare una regola per 3 persone, in quanto uno sviluppatore scrive il codice, un altro sviluppatore rivede il codice e una terza persona preme il pulsante di rilascio per distribuire il codice. L'altra considerazione è che questo fa parte dell'adozione di Agile / DevOps in tutta l'azienda, i team di sviluppo sono piuttosto piccoli, con l'effetto netto di piccoli gruppi di persone che hanno accesso alla produzione a una fetta sottile della produzione, questo sembra essere favorevole dal punto di vista del rischio .
Richard Slater,

1
@ Pierre.Vriens Non posso votare due volte, grande estensione :)
Tensibai

5

Risposta basata sulla mia conoscenza del regolamento francese sui "Controlli interni", in qualche modo equivalente ai regolamenti SEC che lei indica, presumo che il collegamento qui a un testo giuridico francese non sarebbe davvero utile e non conosco una buona traduzione di esso.

In un modello ideale "Costruiscilo, eseguilo", tutti i membri del team saranno responsabili del cambiamento. La valutazione del rischio non può essere imposta da una separazione dei compiti e l'unico modo che conosco per conformarmi alla normativa è quello di avere un controllo periodico a breve ciclo delle transazioni insieme a un monitoraggio delle azioni inalterabile per tornare alla persona che ha rilasciato il rilascio .
Ciò significa che tutti i registri delle transazioni e delle azioni vengono trasferiti in un'area riservata a cui il team non ha accesso, una modifica di ciò che viene registrato "dovrebbe" essere catturata da test funzionali a cui la squadra non ha accesso e, peggio ancora, verrà catturata dall'audit e monitorato dal suo autore.

Ciò non è applicabile a tutti i prodotti, al momento della redazione in Francia di qualsiasi azienda autorizzata a emettere denaro (principalmente banche), deve garantire che ogni transazione venga registrata e quindi non può correre il rischio di perdere una transazione.
D'altra parte, non hanno alcun obbligo legale di tracciare alcuna offerta commerciale o valutazione del rischio quando qualcuno chiede un prestito, e quindi i prodotti che gestiscono questa selezione di clienti e calcolano le commissioni che saranno nell'offerta sono più facili da inserire in un post modello di audit a rilascio.

L'idea principale è che il modello di rilascio deve essere modificato in base agli obblighi di valutazione del rischio.

Una risorsa correlata è la norma ISO27001 .


Risposta interessante e molto pertinente in quanto molte banche europee operano davvero in Francia. C'è qualche possibilità che tu possa ampliare ciò che significa "Emettere denaro", ovvero che è solo incassare un bancomat o include trasferimenti di saldo. In questo caso il collegamento con gli statuti sarebbe utile in quanto fornisce un puntatore alle leggi pertinenti, indipendentemente dalla lingua in cui si trovano.
Richard Slater

@RichardSlater In breve, qualsiasi azienda che lavora con denaro, potrebbe essere una società di soli investimenti, nonché broker di prestito lungo le banche tradizionali. Soprattutto tutto ciò che ha un impatto finanziario da qualche parte è interessato (a parte poche eccezioni che l'autorità può dare sotto circostanze). La "lista" legale in francese è qui ma anche in francese non è sempre ovvio.
Tensibai,

Sto assumendo che il collegamento con lo standard ISO dovrebbe effettivamente essere ISO27001: 2013
Richard Slater

@Richard, in effetti, il link dal francese all'inglese non è stato aggiornato su Wikipedia. Aggiornerò più tardi (o, se lo desideri, sentiti libero di modificare)
Tensibai


0

IMHO, Developers & Operations potrebbero essere rappresentati da nient'altro che due soli repository git per lo stesso codice base , con modelli di autorizzazioni distinti ciascuno, in modo che i team non interferiscano affatto nel lavoro reciproco.

Chiamiamoli Dev.mygithub.co e ops.mygithub.co , solo come esempio.

L'idea è che gli sviluppatori sono liberi di creare / ramificare / fondersi con il loro contenuto di cuore - l'intelligenza sta fornendo la completa tracciabilità e questo è ciò che conta qui - nel frattempo, nei momenti in cui il quadro normativo implica uno sforzo di revisione, una richiesta pull può essere sollevata, per la fusione avviene in modo controllato.

Portando questo concetto al livello successivo, un ramo di sviluppo può essere propagato alla produzione di operazioni remote tramite l'ennesimo atto di Pull Request . Quest'ultima parte deve avvenire con le mani e gli occhi delle operazioni, dal momento che hanno la responsabilità di controllarlo nella produzione e scelgono il livello di revisione.

Tale schema consente flessibilità infinita, piena tracciabilità, capacità di individuare tempestivamente i problemi tramite una varietà di processi, separazione delle preoccupazioni e un'esperienza utente molto ragionevole nel processo !

NB Il modello sopra descritto può essere seguito anche se Ops & Dev si sovrappongono totalmente!


1
Sicuramente, questo stesso controllo potrebbe essere ottenuto attraverso richieste pull e hook post-commit che garantissero che gli sviluppatori potessero impegnarsi liberamente, tuttavia, i commit di unione potevano essere effettuati solo da un gruppo di persone approvato. Allo stesso modo, lo stesso hook post-commit potrebbe garantire che gli autori dei commit che componevano la richiesta pull non includessero la persona che faceva la richiesta pull.
Richard Slater,

@RichardSlater: il motivo per cui potresti desiderare di avere due repository distinti è che hai il duplice bisogno di consentire sia agli sviluppatori di unire - quando scambiano liberamente il codice in modalità sviluppatore - sia di impedire alla maggior parte degli sviluppatori di unire il codice quando è andare verso la produzione (modulo SysOps, ovvero il cosiddetto "gruppo di persone approvato").
fgeorgatos,

Ancora una volta puoi ottenerlo con hook post-commit e richieste pull, per non parlare di GitHub Enterprise che consente filiali protette.
Richard Slater,

0

più alto è più costoso:

  • siti e metodi di sviluppo e operazioni distinti per trasferire il lavoro dall'uno all'altro
  • distinti sistemi operativi e metodi e metodi come sopra
  • repository git / vcs distinti e ops e metodi correlati
  • distinti rami dev e op git / vcs (protetti) e metodi correlati

A seconda di ciò che fai, alcune soluzioni sono migliori di altre, ad esempio se hai la necessità di servire due team con ruoli distinti al loro interno e ognuno con la proprietà all'interno e fornire la completa tracciabilità, stai passando con il mouse sui primi tre.

In breve, tutto ciò che impone che un ragazzo o una ragazza non possa prendere la palla da solo e correre con essa, e attraversa un confine esplicito distinto tra dev & ops. Ora, a seconda del livello di rischio, tale limite potrebbe essere applicato o meno.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.